Что вкладывалось в термин UX

Термин «user experience design» появился в начале 90-х. Его придумал Дон Норман с коллегами из Apple (так по крайней мере он говорит).

Дон Норман — американский учёный, бывший вице-президент Apple, основатель Nielsen Norman Group и актор книг по UX.

В одном из интервью Дон рассказал, что именно вкладывалось в термин UX. Видео не новое, но если не смотрели, то советую посвятить ему полторы минуты времени.

⏱ 93 секунды

#UX

https://youtu.be/jWC6hqg04fg

Смежный навык: UX-копирайтер
Есть ряд смежных навыков, знания по которым пригодятся практически всем, кто задействован в разработке ИТ-продуктов.
Навскидку могу назвать: психология потребления, маркетинг, умение понятно говорить, копирайтерство.

Сегодня про UX-копирайтерство.
Писать понятно в интерфейсе всегда было важно, но сейчас под каким-то новым углом это подсветили и отдельная роль появилась — UX-копирайтер.
Не все команды могут себе позволить держать UX-копирайтера в штате.
Если хочется писать в продукте и о продукте так, чтобы пользователи понимали — надо развивать навык.

Вот вам небольшая подборка статей про UX-копирайтерство, качните же себя на выходных:

🤘 Редактор в UX: тру стори, риал лайф — живая статья о UX-редактуре от лид-редактора в UX Яндекс.Денег.

👏 Кто такие UX-копирайтеры, что они умеют и так ли нужны в компании — классная заметка в блоге скрам-студии Сибирикс.

👍 Пишем как Google: Чек-лист для копирайтера — перевод статьи, в которой про UX-копирайтинг рассказано очень просто и с примерами.

✍️ Почему UX-писатель — не копирайтер? — некоторые детали о профессии от UX-писателя из Собака Павлова.

А ещё рекомендую #нормканал про UX-копирайтерство, который ведёт Владимир Лалош — продуктовый редактор в МТС: @editboat

Рекомендация канала добровольная. Мне за неё, к сожалению, не платили и никакой взаимопиар не предлагали 🙂

В проектной работе надо уметь договариваться

Проектным дизайнерам тяжело: даже самых крутых дизайнеров просят поиграть с цветами и сделать что-то поинтереснее. Ловилаваш без хороших юристов не всякий способен сдать.
Хуже чем дизайнерам только проектным менеджерам. Надо за всех отдуваться, уметь убеждать и находить компромисс.

Не так тяжело программистам: даже лютый программист-говнокодер может чувствовать себя на проектной работе вполне сносно. Особенно на всяких микропроектах, где нет технического контроля. Заказчики редко смотрят код и вообще общаются с программистами — примерно, раз в никогда.

В целом, в проектной работе умение общаться с заказчиком, договариваться и аргументированно отстаивать свою точку зрения порой гораздо важнее, чем прямые профессиональные качества.
Если для вас переговоры или сдача итогов своей работы руководителю всякий раз — маленькая смерть, то лучше себя прокачать. Новые перспективы откроются.

Кто-то, конечно, скажет: "Правильно, цена же у Яндекса от количества машин зависит!".
Но большинство подумают — нагребалово какое-то.

Вышла в свет третья статья из цикла "UX таблиц, с которыми работают" про управление данными и экспорт.

На очереди:
👉 чек-лист для создания удобных таблиц.
👉 статья про UX необратимых процессов.
👉 статья про UX форм, с которыми работают.

Не переключайтесь :)

https://medium.com/@grekov/ux-tablic-s-kotorimi-rabotaut-chast-3-upravlenie-i-export-110fe6de533f

Готовлю статью про UX необратимых процессов. Веб-клиент почтовика Outlook мне помогает с примерами по процессу Удаления.

Если при написании письма нажать "Отменить" (или esc), то Outlook запускает необратимый процесс удаления и просит пользователя подтвердить это.

Посты в телегу нельзя делать с несколькими картинками, поэтому про процесс удаления написал небольшую заметку в Телеграфе: https://telegra.ph/UX-neobratimyh-processov--pro-udalenie-04-17
С помощью корректировки текста на кнопках можно существенно улучшить эту форму.

Кстати, завтра UX-марафон про UX-тексты. Кто чувствует потребность — можно записаться, формат вебинара (2000 рублей).

😎 Продуктовый забивака
Сейчас научу плохому. Откровение, которое кому-то поможет иначе смотреть на мир продуктовой разработки.

Важное качество для тех, кто работает в продуктовой разработке — забивать на всякие мелочи, которые не влияют на метрики.
Например, есть форма заказа товара и на этой форме в определённом браузере кнопка "Заказать" слишком крупная/мелкая/кривая. В общем, кнопка не такая, какая она должна быть. Это все видят.
Но при этом существенных проблем ни у кого не возникает, все заказывают, конверсия такая же, как и в других браузерах, где всё ок с кнопкой.

🤓 Менеджер продукта незабивака (или аналитик, или дизайнер, или кто угодно): не будет спать спокойно, пока эта кнопка не будет поправлена. Будет вставлять задачу во все планы — это же баг, это же видят пользователи, это же быстро поправить.

😎 Забивака: забьёт и сделает что-то другое, что положительно влияет на метрики.

Забивака — улучшает метрики. Незабивака — успокаивает свои нервы.

Правило такое: когда что-то делаем, надо сделать максимально качественно, но если где-то "вылезло" и не портит метрики — забей.
Если в резюме написано "Внимателен к мелочам", то надо понять, а может ли забить.

В следующий раз расскажу почему важно быть проектным жопорвашкой.

Терминология не академическая, уж простите 🤷‍♂️

Проектный жопорвашка
🤓 Сейчас научу хорошему.
Если в продуктовой разработке важно уметь забить на мелочи, то в проектной разработке важно замечать мелочи и не забивать на них.

Проект = фронт + бюджет + срок.
Не забивать на мелочи в проекте важно, потому что внешние метрики проекта сильно от них зависят. Метрики такие: выполнить фронт работ и оставить заказчика довольным.

Выполненный фронт позволит закрыть текущий проект, а довольный заказчик — это отзывы и новые проекты.
Если заказчик видит, что на мелочи "забивают" или просто пропускают, то он думает: "Что же там тогда, если поглубже копнуть!?"
А если заказчик начинает усиленно копать, то проект начинает двигаться по формальной стороне — закрыть фронт. В итоге всем тяжело: у разработчика — тяжёлый заказчик, у заказчика — тяжёлый проект, которому он уделяет повышенное внимание, и "неумеха" разработчик, которому надо пальцем показывать.

Проектные мелочи — это не только, когда кнопки ровные во всех браузерах и ничего не едет.
Это:
* тексты без опечаток и ошибок,
* внимание к мнениям заказчика, которые он высказывает,
* умение увидеть, что фронт работ некорректный (глупости в ТЗ), обосновать это и улучшить,
* своевременное информирование заказчика о ходе работ,
* обещать = сделать.


Гарантийный срок не панацея
Некоторые очень сильно верят в силу фразы: "Если в процессе работы что-то найдётся, то есть гарантийный срок, в который мы поправим". Я её и сам много раз говорил.
В розовом мире после этих слов должно произойти безапелляционное принятие работ.
Но с прожжёнными заказчиками, которым итог действительно важен, так не работает. Пока проект не сдан — заказчик ТРЕБУЕТ, а исполнитель шустрит. Когда начинается гарантийный срок — заказчик ПРОСИТ, а исполнитель планирует исправление или и вовсе "это не баг". Это все понимают.

Будьте внимательны!

Чек-лист создания таблиц, с которыми работают
Как вы знаете, у меня есть цикл статей про UX-таблиц, с которыми работают.
Но статьи — это теория, а хотелось сделать что-то более практичное: инструмент, который поможет всем желающим создавать удобные для повседневной работы таблицы.

Поскольку, я верю в силу чек-листов — сделал "Чек-лист создания таблиц, с которыми работают".
Доступно для всех.

Формат чек-листа: Гугл-Таблицы (Эксель от Гугл). Кому будет полезно — берите за основу.

В чек-листе 65 требований и ссылки на теоретическую базу.
Требования касаются как дизайна, так и разработки/тестирования.

#UX #инструменты

Животные в шаринге у Гугла
Если пошарить гугловский документ через общедоступную ссылку, то смотрящие будут маркироваться животными или овощами (картинка ниже).

Зачем это Гуглу, если вполне можно было вывести счетчик: Смотрят 15?
Животные — это душевно и приятно. Аватары-животные дают ощущение, что кто-то живой смотрит файл.
К тому же, забавно полистать список животных — там есть вполне экзотические и даже сказочные.
Например, есть Рыба-капля. Самая грустная рыба в Мире: у неё почти нет мышц и если её достать из воды, то выглядит она очень-очень грустно (ссылка на фото).

В общем, иногда полезно сделать в продукте что-то душевное вместо сухой реализации. Только перед этим надо продукт сделать, который будет окупать создание приятных мелочей.

Среди животных Гугла я не обнаружил Крота-звездорыла. Он выглядит не менее оригинально, чем Рыба-капля. Фото не для слабонервных.

С удовольствием посмотрел лекцию Курпатова "Зачем мозгу учиться и как это делать правильно?"

Это про UX :)
- Знания + Опыт определяют наши мысли.
- Слова ничему не учат, а могут лишь мотивировать к обучению и опытам.
- Насмотренность важна.

Это если вкратце. Но Курпатов подробно рассказывает, что да почему, с примерами и шутками-прибаутками.

Хотя Лебедев запретил Курпатова.

А если серьёзно, то по теме представления ошибок в интерфейсе рекомендую познакомиться со статьями Собаки Павловой.
В статьях полно примеров и всё доходчиво написано.

Первая — про то, как представлять ошибки в программе (технические проблемы):
https://sobakapav.ru/publications/error-design-guide1

1. Глобальные сбои
Каким должно быть сообщение об ошибке, если сервис недоступен по техническим причинам? Такое случается со всеми продуктами — от онлайн-игр до сложных биржевых сервисов.

2. Специфические баги
Для разработчиков это часть ежедневной работы. Для пользователей все иначе. Некорректная или нестабильная работа пугает их и сбивает с толку.

3. Внешние проблемы
Ни одна программа не существует без материальной оболочки: смартфонов, компьютеров, машин, датчиков и приемников. Все они тоже могут работать некорректно.


Вторая — она всем ближе, про то, что делать, когда ошибается пользователь:
https://sobakapav.ru/publications/error-design-guide2

1. Поместите сообщение в фокусе внимания
2. Покажите, где именно возникла ошибка
3. Используйте понятные формулировки без лишних слов
4. Подскажите, как исправить ошибку
5. Сохраняйте работу пользователя

#нормстатья #UX

З - Забота
Если в дестоп-Фигме нажать ctrl+S, то Фигма ласково говорит всплывахой, что она всё итак сохраняет автоматически.

А ведь могли бы просто не реагировать. Сделали реакцию на привычные для пользователя горячие клавиши, не смотря на то, что само сочетание ничего ровным счётом не делает.
#UX

Микрософт, видимо, нанял политика для написания текстов релизов. Взял в UX Club

Каналы про UX
Иногда я рекомендую абсолютно добровольно телеграм-каналы (ни реклама, ни взаимопиар). Сегодня у меня относительно большая подборка каналов про UX/UI и прочие удобства. Аж 9 штук, порядок условный.

Я подписан на все — иначе не советовал бы. Каналы довольно уравновешены в плане сообщений и за каждым стоит профессиональный автор.

Прежде чем подписаться — почитайте 3-5 заметок в канале. Если интересно — подписывайтесь.

👉 UI & UX делишки — @yakovlevv_com
Из названия канала ясна тематика. Статьи авторские, тем и интересен.

👉 lil words make magic — @uxwords
Про текст в интерфейсе. Интересные примеры плохих/хороших UX-текстов.

👉 Собака лает — @pavlova_cc
Телега «Собаки Павловой». Пишут бодро и интересно, если не брать во внимание странные опросов.

👉 UX Boost — @uxboost
Собственно, ещё один авторский канал про UX.

👉 Адовый UX — @uxfromhell
Примеры плохих интерфейсов и истории про них.

👉 Хуикс — @Who_X
Канал с весьма специфичной манерой подачи материала. Текста многовато, но идеи добротные.

👉 UX Notes — @uxnotes
Автор достаёт самую мякоть из статей про UX/UI и делится этим, ссылаясь на статью.

👉 UX Horn — @uxhorn
Ссылки на наиболее популярные статьи по теме UX.

#нормканал

Как относиться к комментариям от заказчика

Максим Ильяхов (один из авторов книги "Пиши, сокращай") достаточно доходчиво проиллюстрировал, как редакторам стоит относиться к комментариям заказчика.
Но всё, что там написано актуально и для дизайнеров, и для всех, кто сдаёт какие-то итоги кому-то.

Вот, что пишет:

👉 Когда автор [дизайнер, проектировщик] называет комментарии клиента правками, подразумевается, что клиент знает, как правильно, а текст [дизайн, прототип] нужно исправить.

👉 Но клиент может не разбираться в работе автора. Он не всегда знает, как правильно. Он обратился к вам, чтобы вы ему это показали.

👉 Комментарии клиента — это не правки, а замечания. Клиент что-то заметил и просит вас обратить на это внимание.

👉 Правки обязательно принять и исправлять. Замечания можно обсуждать, согласовывать, даже снимать.

👉 Человек, который принимает правки, — безвольный карандаш [кисть] в руках клиента. Специалист работает с замечаниями.

👉 Больше никогда не вносите правки.

Моя добавка.
Текста много. Совсем не Пиши, сокращай.
А смысл такой:
Не нужно кидаться учитывать в работе все комментарии заказчика. Нужно хорошенько подумать и понять, что не устраивает заказчика, обсудить с ним и предложить лучшие варианты.

Я много раз принимал работу исполнителей (и дизайн, и текст, и прототипы и т.п.).
Как заказчик замечу — никогда не хочется говорить, как именно нужно сделать. Хочется, чтобы исполнитель сам улучшал.
Но некоторые исполнители ждут очень чётких замечаний: "Что именно не нравится? Скажите — я поправлю!"
Вроде бы, всё верно говорит. Но всегда внутри вопрос: "Кто из нас профессионал в этом деле?".
Как я тебе могу сказать про блюры, тени, сетку, композиции и прочее, если я заказчик, который может только ощутить и сказать:
"Здесь выглядит как-то коряво/некрасиво/несовременно".

P.S. На мобильном сториз Ильяхова можно полистать прям в Телеграм. Жмите на картинку, которая ниже и листайте — удобно.

#совет

UX перешёл черту

Круто, когда продукт заботится о пользователе.

Забота будет по-настоящему оценена, если фундаментом для неё будет некая циклическая боль. Продукт, который снимает циклическую боль — заботливый продукт.

Но почему некоторые продукты вызывают своей заботой Вау-эффект и сарафан (пользователи советуют продукт другим пользователям), а забота других продуктов особых эмоций не вызывает?

Поразмышлял в статье с кучей примеров.

#UX