Юля Трусова написала, как работать с пушами, чтобы они меньше раздражали.

— Выбирайте из пользователей тех, кому сообщение реально может быть полезно. Например, пуш о функции «Черновик» в Авито стоит направить тем, кто размещает много объявлений;
— Если пуш может приходить часто, напишите несколько вариантов текста, чтобы он не наскучил;
— Проверяйте сообщения на логичность в разных обстоятельствах. О вакансиях рядом с домом лучше сделать 2 варианта пуша: а) в радиусе 5 км для Москвы и Санкт-Петербурга, б) в радиусе 1 км для всех остальных;
— Не лезьте в жизнь людей. Сообщение от сервиса недвижимости с советом переехать или купить свою квартиру будет звучать грубо, так как сделать это непросто;
— Для каждого сообщения настраивайте кулдаун — время, в течение которого пользователь не получит его повторно. Выбирайте такое время, чтобы не надоесть. Также можно ограничить общее количество сообщений, приходящих от сервиса;
— Используйте в сообщениях переменные, так они станут персональными и более убедительными. Например: «Пользуется спросом. Объявление «1-к. квартира, 47,4 м…» из вашего избранного посмотрели 456 раз за неделю»;
— Проверяйте, что любые значения переменных работают на цель сообщения. Если вместо числа 456 будет 2, пользователь не решит поторопиться с решением по поводу этой квартиры;
— Если несколько одинаковых событий произошли одновременно, присылайте общий пуш;
— Новые эмодзи могут отображаться только в последних версиях систем. Чтобы все пользователи увидели эмодзи, используйте только те, которые появились до 2019 года;
— Используйте знак рубля и неразрывные пробелы.

#push

Тесс Гадд написала об аккордеонах.

— Вариант, когда в аккордеоне можно открыть только одну секцию одновременно, подходит для форм, которые надо заполнять последовательно;
— Возможность параллельного открытия нескольких секций полезна, когда пользователю не нужно фокусироваться на одной секции и нужен полный контроль. Например, при отображении разных групп параметров фильтрации;
— Согласно исследованию Nielsen Norman Group, чаще всего пользователи ожидают увидеть в аккордеоне иконку шеврона (стрелка, направленная вниз);
— В раскрытой секции стрелка шеврона должна быть направлена вверх;
— Следствие из правила, что не стоит выносить в аккордеон важную информацию: если аккордеон не используется для навигации, по умолчанию все его секции лучше скрывать;
— Часто аккордеон применяют для а) отображения второстепенной информации в карточке товара вроде условий возврата, доставки и размерной таблицы, б) списка часто задаваемых вопросов;
— Заголовок секции и шеврон оба должны быть кнопками, раскрывающими и скрывающими секцию. Не должно быть так, что шеврон раскрывает секцию, а заголовок ведёт на какую-то страницу.

#accordion

Андрей Шапиро написал о схематизации опыта с помощью CJM, Service Blueprint и собственной гибридной нотации.

— Строгой нотации CJM нет. Из-за этого её труднее использовать для синхронизации работы людей с разным уровнем подготовки. Зато инструмент пластичен: карту можно организовать так, как того требует ситуация;
— CJM рассматривает точки контакта (взаимодействия) человека и проектируемой или анализируемой системы;
— Важно различать точки контакта и каналы. Каналы — средства, через которые происходит взаимодействие. Например, «Подтверждение брони» (точка контакта) может происходить в интерфейсе приложения и в электронной почте. Каналы стоит отражать в CJM только если одно и то же взаимодействие возможно в нескольких каналах;
— Информационные слои CJM могут быть любыми. Чаще всего Андрей анализирует в точках контакта действия, возникающие артефакты, барьеры, инсайты действующего лица;
— В табличных CJM каждая строка — информационный слой. Такие CJM можно вести хоть в Гугл Таблицах, за счёт чёткой структуры их легко заполнять на воркшопах, но в них сложно показывать нелинейные сценарии;
— В проволочных CJM точки контакта соединены линиями, удобно показывать ветвления сценария взаимодействия, а информационные слои размещены в виде текстовых блоков рядом с точками контакта;
— С помощью Service Blueprint показывают взаимодействие нескольких действующих лиц и участвующих сервисов;
— На одном уровне показывают видимые клиенту взаимодействия (например: заказ, выдача товара), на другой — скрытые, но участвующие в оказании услуги (комплектация заказа). Дополнительные уровни: артефакты, действия клиента, вспомогательные процессы;
— CJM и SB делят действия одного или нескольких лиц на шаги и привязывают к этим шагам какие-то наборы данных. В CJM шаги отражают путь конкретного героя (клиента). SB охватывает весь процесс формирования ценности для клиента.

#cjm #sb

В SimbirSoft написали о проектировании форм. Об этом было уже много публикаций, поэтому я выбрал не самые распространённые советы:

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

7. Не располагайте в форме ссылки на другие страницы. Пользователь может перейти по ссылке и не вернуться к форме.

8. Не используйте плейсхолдеры без необходимости. Если в плейсхолдере есть полезная для заполнения поля информация, она пропадёт после заполнения, и пользователь не сможет себя перепроверить. Если информация бесполезна, она только помешает отличать заполненные поля от незаполненных.

10. Не используйте раскрывающиеся списки, если выбрать можно всего из трёх вариантов.

12. Подстраивайте размер полей под предполагаемое содержимое.

13. Оставляйте кнопки формы активными. Если пользователь заполнит не все поля, их можно выделить при нажатии на кнопку отправки формы. О неактивных кнопках есть хорошая статья.

#form

20 самых популярных постов в 2021 году:

1. Как тестировать User Flow: четыре метода и лайфхак для бесплатного UI-тестирования — статья Кирилла Шерстобитова. Анонс в ВК получил 89 лайков и 71 репост.

2. Пользователям плевать на дизайн: как устроен «хороший UX» на самом деле — статья «Атвинты». 67/65.

3. Прототипирование стартапов — запись моего доклада. 59/71.

4. Фак юикс — конспект доклада Ильи Бирмана. 63/58.

5. Fintech Design Conf 2020 — записи докладов мероприятия. 61/58.

6. Аудит интерфейса: как его проводить и почему это проектирование наоборот — статья «Собаки Павловой». 60/59.

7. Avito Design Talk 2020 — записи докладов мероприятия. 56/59.

8. 15 советов для улучшения UX форм регистрации и входа в систему — перевод статьи Эрика Кеннеди. 56/55.

9. Fintech Design Conf 2021 — записи докладов мероприятия. 50/57.

10. Как выглядит хороший макет — статья Михаила Озорнина. 47/48.

11. Отображение ошибок в интерфейсе (часть 2, часть 3) — статьи Насти Овсянниковой. 49/42.

12. Фиксируем результаты UX-тестирования интерфейса на бегу: экономим время и обходимся без объёмных документов — статья «Собаки Павловой». 49/42.

13. «Я потерял веру в UX»: основатель агентства о том, как корпорации усложняют интерфейсы ради увеличения прибыли — перевод статьи Марка Херста. 48/39.

14. Схематизация опыта с CJM и Service Blueprint: практика гибридной нотации — статья Андрея Шапиро. 52/34.

15. Четыре фазы разработки интерфейса: что обсуждать с заказчиком, когда нет даже картинок — статья Ахнафа Кунакулова и Антона Илларионова. 50/35.

16. Интерфейсные тексты: как дизайнеру начать писать грамотнее — перевод статьи Дэвида Холла. 41/43.

17. Тёмный паттерн: как Яндекс манипулирует пользователями — статья Левана Джамелашвили. 53/31.

18. Информационная архитектура: краткий экскурс — статья Павла Шерера. 43/41.

19. Как создавать полезные для бизнеса дашборды: алгоритм, принципы вёрстки, инструменты, архитектура — статья Романа Бунина. 44/37.

20. M-commerce: 11 нюансов навигации в мобильной версии интернет-магазина — статья KISLORODа. 44/37.

Брайан Миллар написал об экстремальных пользователях.

— Они отличаются от среднего пользователя;
— Они могут показать, как будет вести себя основная масса потребителей через несколько лет, или обладают особыми потребностями, которые не удовлетворяет ни один из существующих продуктов;
— Можно многое узнать, поговорив с продвинутыми пользователями смартфонов, но ещё больше — от тех, кто принципиально ими не пользуется или даже получает информацию из папочек;
— На экстремальных пользователях можно проверить самые прорывные идеи, которые не воспримет обычная фокус-группа;
— Экстремальные пользователи помогут а) увидеть ограничения и узкие места вашего продукта, б) выявить его неочевидные особенности, в) узнать, что вызывает неприятие;
— Опыт таких пользователей поможет улучшить продукт: найти решения, подходящие экстремальным пользователям, и сделать его лучше для обычных пользователей.

Кстати, включил реакции, чтобы следующий топ UX Notes можно было определить на основе лайков и дизлайков в Телеграме, а не лайков в ВК. Но работают они только в последних версиях Телеграма.

Антон Жиянов написал о работе с почтовыми адресами.

— Определяйте индекс автоматически. Стоит добавить: если продукт умеет определять индекс по адресу, размещайте сначала поле для ввода адреса, а затем — для ввода индекса;
— Храните адрес вместе с индексом: иногда адреса отличаются только индексом. Например, в Устьянском районе Архангельской области 5 раз встречаются деревни Бережная с разными индексами;
— Храните номер дома как строку, а не число. Иногда новые дома получают номера, начинающиеся с нуля. «Электросталь пр-т Ленина 4» и «Электросталь пр-т Ленина 04» — 2 разных адреса;
— Давайте возможность ввести адрес вручную. Жизнь богаче любого адресного справочника. Если адреса в справочнике нет, предупреждайте о возможной ошибке, человек может просто перепутать номер дома;
— Не делайте поля для ввода улицы или дома обязательными. В России много адресов без улицы или дома;
— Чтобы избежать путаницы, не склеивайте номера домов с литерами. «Звёздный 23З» → «Звёздный 23 лит З», «23Ч» → «23 лит Ч»;
— Автоматически определяйте город: по координатам в приложении или IP-адресу в браузере. Так можно избежать назойливого вопроса о городе при открытии сайта и показать правильную стоимость доставки;
— Если клиент получает заказ на почте, показывайте адрес и часы работы почтового отделения;
— Если заказ доставит курьер, определяйте ближайшее метро.

Смотрите также дополнение в блоге «Дадаты».

Джаскаран Сингх написал о расположении кнопок «Ок» и «Отмена» в диалоговом окне.

— Плюсы «Ок — Отмена»: логический порядок расположения вариантов (сначала основное, затем дополнительное) совпадает с порядком чтения, если человек читает слева направо; с помощью клавиатуры можно быстрее перейти к кнопке «Ок», которая нужна пользователям чаще;
— Плюсы «Отмена — Ок»: основная кнопка находится там же, где заканчивается движение пользовательского взгляда; «Отмена» возвращает пользователя назад, а «Ок» перемещает дальше, поэтому такое расположение кнопок соответствует логике отображения прошлого слева, а будущего справа;
— Несмотря на плюсы разных вариантов, надо придерживаться стандартов платформы: в Windows «Ок — Отмена», в интерфейсах Apple «Отмена — Ок»;
— Если у вас веб-приложение, узнайте или (если статистики нет) предположите, какая платформа у большинства ваших пользователей;
— Придерживайтесь выбранного порядка расположения кнопок во всех интерфейсах своего продукта.

#layout #button #popup

Татьяна Чернявская написала о взаимной супервизии.

— Она позволяет развиваться, когда не помогают обычные практики вроде общения с более опытными коллегами, чтения книг и статей, посещения конференций. Обычно с этим сталкиваются синьоры и лиды, но практика может пригодиться и мидлам;
— Подходит специалистам в разных областях. Например, Татьяна занимается UX-исследованиями;
— Суть взаимной супервизии в том, что два профессионала изучают проекты друг друга и обмениваются обратной связью. От супервизии, практикуемой в психотерапии, отличается тем, что процесс двусторонний;
— Не используется для оценки профессионального уровня участников;
— Помогает получить свежий взгляд на свою работу и найти в чужой практике приёмы, которые захочется взять на вооружение, увидеть знакомые процессы в новом свете, прокачать профессиональную насмотренность, лучше понять применяемые в компании методологии, а также сплотиться с коллегами;
— Проще всего проводить внутри компании (из-за NDA);
— Специалисты должны быть примерно одного уровня, это не наставничество;
— Им должно быть комфортно общаться друг с другом;
— Чтобы получить больше инсайтов, для супервизии лучше выбрать самый сложный, а не лучший из реализованных проектов (задачу);
— Стоит учитывать, что полный цикл супервизии может занять 4–5 часов;
— Оптимально проводить её не чаще раза в квартал, желательно выбирать разные проекты и менять напарников;
— В самом начале супервизии надо выбрать проекты и обговорить, почему выбраны именно они, на что смотреть в ходе супервизии и в каком формате давать обратную связь, чтобы всем было комфортно;
— Изучая проект напарника, стоит отметить его сильные стороны, что получилось хорошо, какие были допущены ошибки, а также приёмы, которые хотелось бы взять на вооружение;
— Затем надо провести встречу и обменяться обратной связью. По предварительной договорённости инсайтами и полученными знаниями (или их частью) можно поделиться с командой;
— Татьяна проводит личную ретроспективу, но благодаря взаимной супервизии увидела недостатки, которые не замечала за собой и которым не придавала значения.

Александра Савельева написала для начинающих статью о метриках.

— Метрики дают фактические знания, помогают более осознанно развивать продукт и трезво оценивать эффективность работы дизайнера. Цифры — отличный аргумент в споре;
— Считать их нет смысла, если продуктом пользуется 100 человек, так как каждый такой пользователь сильно влияет на показатели;
— Большое количество «Пользователей в день» или «Заказов в день» не всегда означает успех. Поток новых пользователей может быть вызван рекламой;
— Метрики можно разделить на а) метрики бизнеса (количество пользователей и заказов в день, выручка), которые зависят от сезона, инфляции, мировых трендов и рекламы, б) метрики продукта, которые обычно измеряются в процентах и не зависят от количества пользователей;
— Пример типичной продуктовой метрики — конверсия с одной страницы на другую. Важно знать её для всех магистральных сценариев;
— Важная продуктовая метрика — retention — показывает, какой процент пользователей возвращается в течение выбранного периода времени;
— Выбор периода зависит от продукта. В приложении для знакомств важен ретеншн в короткие периоды, в сервисе для путешествий — от месяца до года, так как большинство путешествует не каждую неделю;
— Дизайнеру лучше ориентироваться на метрики продукта. Выручка и количество пользователей зависят не только от его работы.

Илья Бирман написал, как подойти к созданию дизайн-системы, чтобы она принесла пользу благодаря систематизации, но не мешала развивать продукт.

— Иногда о создании дизайн-системы задумываются просто из-за моды;
— Сначала соберите в один документ компоненты и стили, которые давно используются в вашем продукте и доказали свою нужность и универсальность. Может оказаться, что это всего несколько кнопок, иконок, стилей текста и один попап;
— Детально проработайте их поведение (с длинным текстом, в тёмном режиме, на маленьком экране). Вместе с разработчиками внедрите везде их эталонную реализацию;
— Если после этого перекрашивание кнопок и замена шрифта во всём продукте занимает больше минуты, к следующему шагу переходить рано;
— Развивайте библиотеку, постепенно переводя продукт с несистемных компонентов на системные. В одном месте есть кнопка с иконкой — добавьте иконки в библиотечные кнопки, тестируйте, внедряйте;
— Заниматься развитием библиотеки самой по себе неэффективно. Развивайте её вместе с продуктом, когда строите в нём что-то новое;
— Может оказаться, что до каких‑то частей продукта систематизация не дойдёт ещё несколько лет. Значит вы просто их не трогаете, потому что они не важные.

Станислав Хрусталёв собрал чеклист, как использовать QR-коды для создания позитивного клиентского опыта. Вот часть рекомендаций:

— Если это возможно и уместно, QR-коды использовать стоит, значительная часть людей к технологии готова;
— Сопровождайте код пояснением: что клиент должен сделать и что получит взамен. Также можно уточнить, что для считывания кода надо навести на него камеру телефона (или использовать специальное приложение, как в Ашане);
— Размещайте в QR-кодах лого компании, с брендированием они выглядят профессиональнее;
— Если код будет на офлайновом носителе, при выборе размера учитывайте дистанцию, с которой его будут считывать;
— Размещайте коды на поверхностях, с которыми клиенты не контактируют. Поверхность может начать стираться, и код перестанет работать;
— Убедитесь, что в месте его размещения хороший мобильный интернет или есть вайфай, иначе полезность такого кода устремится к нулю;
— QR-код на десктопной версии сайта может вести на мобильное приложение компании, чтобы пользователь мог легко зайти в магазин приложений со своего телефона (используйте deep linking). Такой же код на мобильной версии сайта вызывает вопросы;
— Чтобы у клиента не рябило в глазах, не размещайте рядом несколько разных кодов для разных целевых действий. Сделайте один код, за которым будет страница с меню из нескольких действий;
— Проверяйте, что целевая страница оптимизирована для просмотра на телефонах.

Bang Bang Education опубликовали киноальманах «Лепота» на Ютубе — бесплатно и без регистрации.

3:00 Fuckyou Digital
5:27 CLAN
8:30 Алексей Ивановский
11:05 Оля Панькова, Владимир Шипилов
13:40 Дима Корниенко, Ваня Корниенко
16:50 Макси Шилов
19:40 Алена Лебедева
21:35 Регина Турбина
23:30 Ждан Филиппов
25:45 Владислав Деревянных и «Восход»
28:50 Вова Аюев
32:00 Денис Башев
34:25 Роман Ерохнович
37:00 Mishka Luganski
39:20 Олег Пащенко
41:50 Сергей Гуров
45:35 Electric Red
48:15 Holystick
51:00 Саша Ермоленко
54:00 Александр Загорский
56:50 Антон Горбунов
59:35 Дима Родионов
1:02:00 Sila Sveta
1:04:35 Just Be Nice
1:07:15 Александр Сметанка
1:09:10 Кирилл Глущенко
1:13:00 Жи-Ши
1:15:45 Татьяна Егошина
1:17:50 Сергей Серов, Катерина Терехова
1:20:10 White Russian Studio
1:23:15 ONY
1:25:30 Андрей Зубрилов
1:28:10 Анатолий Беликов
1:32:45 MAGIC CAMP
1:35:20 Антон Шнайдер
1:37:40 Александр Васин и группа «Ижица» (есть отдельное видео)

Гонсалу Диас написал, почему надо отказаться от бесконечного скрола.

— Он эффективен для просмотра большого объёма информации с небольших устройств, так как устраняет трение: пользователю не надо ничего нажимать, чтобы получить новый контент;
— Он идеален для соцсетей: контента много, а пользователь не особо вовлечён и ничего конкретного не ищет;
— С ним пользователи могут теряться на сайте, медленнее находить что-то конкретное, им недоступен подвал. Об особенностях бесконечного скрола писали Михаил Букин и Кристиан Холст;
— Но основная проблема заключается в эксплуатации синдрома упущенной выгоды (FoMO), истощении человека стимулами и накоплении ненужного контента;
— Разделение на страницы — наиболее понятный способ организовать информацию, востребованный в электронной коммерции. Количество элементов на каждой странице ограничено, пользователи это понимают и могут оценить объем просмотренного и оставшегося контента, вспомнить, где видели понравившийся товар;
— Размещение в конце списка с контентом кнопки «Загрузить ещё» предполагает, что пользователь не обязательно захочет ещё. Плюс, появляется доступ к подвалу;
— Соцсети должны взять на себя ответственность за информационную перегрузку и уходить от высокоскоростного контента к идеально подобранному персонализированному, анонсы которого пользователь просмотрит в две прокрутки;
— Сейчас, в мире бесконечного количества информации, мы можем разве что следить за своими привычками и использовать ограниченные возможности своего внимания в первую очередь для достижения своих целей.

Владимир Белов написал о тултипах (всплывающих подсказках).

— Тултипы помогают обучать пользователей и объяснять интерфейс;
— Тултип отображается при наведении курсора на элемент интерфейса. Если рядом находятся несколько элементов с тултипами, отображайте его, когда пользователь задерживает курсор на одном из элементов;
— Их стоит использовать с кнопками без текста, так как метафоры иконок могут быть непонятными;
— В них можно показывать сочетания клавиш для взаимодействия с элементами интерфейса, требования к вводимому паролю, дополнительную информацию (но только если она не занимает половину экрана);
— Также — полный текст, который в интерфейсе отображается сокращённым (например, слишком длинное слово в узкой ячейке таблицы);
— С их помощью можно объяснять, почему кнопка у пользователя заблокирована;
— Чтобы появление тултипа было приятным, достаточно стандартного transition 0.3s;
— Чтобы добавить подсказку к тексту, на который пользователи редко наводят курсор, можно рядом разместить иконку (i) или (?) с тултипом. Например, так можно пояснить подпись к полю, включающую незнакомый термин.

Ещё о тултипах писал Викалп Кошик.

Сэм Айронс написал о дизайн-долге — дизайнерском аналоге технического долга: как классифицировать, измерить и погасить.

— Это накопленные проблемы с дизайном, решение которых отложили на потом;
— Варианты разумного дизайн-долга: а) Преднамеренный: команда понимает, что дизайн не очень, но решает его реализовать и планирует доработки на следующие итерации; б) Непреднамеренный: команда реализует хороший дизайн, но со временем он перестаёт быть таковым, так как меняются обстоятельства;
— Безрассудный преднамеренный дизайн-долг отличается от разумного тем, что команда делает «быстро и грязно», не оценивая трудозатраты на доработки и не планируя их (хакатоны, инновационные спринты);
— Безрассудный непреднамеренный дизайн-долг появляется из-за некомпетентности и отсутствия опыта;
— Кто создаёт продукт, тот и должен его обслуживать, в том числе устранять дизайн-долг;
— Время на обслуживание надо закладывать в план. В Atlassian на это уходит четверть рабочего времени;
— Можно выявлять отдельные баги в UI (неправильный отступ, опечатка) или UX (проблема с сообщением об ошибке, стандартное пустое состояние);
— Можно искать способы: а) Снизить сложность сценария, уменьшив количество ответвлений или пользовательских действий, необходимых для его прохождения; б) Уменьшить количество отдельных сценариев, которые надо последовательно пройти в продукте для достижения цели; в) Упростить концептуальную модель, сократив количество сущностей и связей между ними;
— Появление дизайн-долга можно предотвращать, внедряя лучшие практики вроде проведения исследований, поиска нескольких решений, вовлечения клиентов в процесс, сквозного тестирования существующих продуктов, анализа клиентских отзывов и так далее;
— Возвращайтесь к компромиссным решениям и планируйте их доработки. Принимая такие решения, старайтесь сразу включать доработки в план;
— Сделайте дизайн-долг прозрачным: ведите бэклог, измеряйте его размер;
— Зафиксируйте обязательства по регулярному погашению долга;
— Стандартизируйте процедуры выявления и погашения долга (Брейден Ковиц упоминал день исправления UI-багов).

Егор Камелев и Эдвард Чечик написали (отдельно друг от друга) о проектировании тултипов. О всплывающих подсказках недавно было, так что эта заметка дополнит и на какое-то время закроет тему.

— Тултип может отображаться также при фокусе на элементе интерфейса с помощью клавиатуры, длительном нажатии на него (на мобильных устройствах) и разглядывании (в VR-шлеме с трекингом взгляда);
— В нём можно показывать обратную связь, например, что нажатие на контрол привело к копированию текста в буфер обмена;
— Примеры дополнительной информации, которую часто показывают в тултипах: числовые значения для отдельных частей графика или диаграммы; значение, выбираемое с помощью ползунка; ответ на вопрос «что это за непонятное число»;
— Стрелка тултипа указывает на связанный с ним элемент интерфейса. Полезно, когда таких элементов много рядом;
— Не размещайте в тултипе важную информацию;
— Поповер ≠ тултип. Поповер появляется при нажатии на элемент и может включать несколько абзацев текста, ссылки и кнопки;
— Если вы не используете фреймворк вроде Бутстрапа, то при создании тултипа надо будет ответить на не самые очевидные вопросы (примеры ниже);
— Если два элемента стоят рядом, и пользователь сместил фокус с одного на другой, как должны вести себя тултипы (например, меняются мгновенно, игнорируя правило задержки)?
— Где должен появиться тултип, если связанный с ним элемент находится близко к краю экрана?
— Максимальный объём текста в тултипе и максимальная ширина контейнера?
— Как отделить тултип от остального интерфейса? Цвет (в Бутстрапе по умолчанию белый текст на чёрном фоне), прозрачность, тень;
— Не стоит уменьшать размер текста в тултипе и усложнять его читаемость (борьбы за пространство в этом сценарии нет), да и в целом добавлять ради него новый стиль.

Александра Савельева написала об уровнях развития цифрового продукта (о них писал также Аарон Уолтер в книге «Эмоциональный веб-дизайн»).

— Функциональный продукт (решает задачи) → Надёжный (работает стабильно) → Удобный (им легко пользоваться) → Приносящий удовольствие (вызывает улыбку);
— Каждый продукт стоит на своей ступеньке;
— Нельзя перескакивать через уровни. Даже написанное лучшими UX-редакторами сообщение об ошибке не спасёт, если приложение ошибается слишком часто;
— Функциональные продукты: выполняют специфические задачи, иногда не имеют графического интерфейса и почти никогда не нуждаются в дизайнере;
— Надёжные: многие профессиональные и излишне сложные продукты, у которых просто нет более удобных конкурентов; стартапы на этапе проверки гипотезы;
— Удобные: большинство продуктов;
— Приносящие удовольствие: продукты на конкурентных рынках;
— Чтобы разработка не упрощала ваши задумки до полной неузнаваемости макетов, надо понимать, на каком уровне находится ваш продукт;
— Если продукт на низком уровне, в макетах должно быть что-то бюджетное для разработки. Это повысит их шансы на реализацию.

В «Собаке Павловой» написали о подготовке макетов профессиональных интерфейсов к тестированию.

— Их пользователи чаще сталкиваются с ситуациями, для которых нет чёткого сценария;
— Такие интерфейсы могут включать векторы взаимодействия: 1) Педагогический (новичок ищет подсказки в интерфейсе); 2) Непосредственный (опытный пользователь работает без подсказок, знает популярные идиомы); 3) Невидимый (эксперт использует шорткаты);
— Они ориентированы на специалистов, знакомых с терминами и неочевидными идиомами, проходящих обучение;
— На макетах проблематично тестировать 3-й вектор взаимодействия, но он есть не во всех профессиональных продуктах;
— Если респондент не справился с задачей, это не всегда ошибка проектирования. Заказчик интерфейса может планировать изменение текущего процесса и рассчитывать на дальнейшее обучение;
— Соберите макеты в прототипы, в которых можно протестировать отдельные сценарии и ситуации. Вместить все ситуации в один прототип не получится;
— Одно задание — один рабочий процесс или ситуация;
— Все элементы, относящиеся к сценарию, должны быть интерактивны. Если пользователь нажал на неактивный элемент, можно обсудить, почему он это сделал;
— В прототипе можно выделить несколько основных процессов, но охватить всё многообразие возможностей не получится. Отчасти помогут Framer, Axure и Anima, но тестирование профессиональных продуктов на этапе макетов всегда немного условно.

Эдвард Чечик написал о панелях свойств (боковых панелях), которые часто можно встретить в профессиональных продуктах.

— Вкладки в верхней части панели позволяют разделить её на отдельные секции;
— Панели часто делятся на блоки — группы свойств, которые пользователь может скрывать и раскрывать;
— Обычно редактируемый объект меняется сразу после изменения его свойств на панели, но если изменение требует времени — после нажатия на кнопку подтверждения;
— Также отдельные кнопки обычно используют для загрузки файлов и экспорта;
— Часто ползунки сопровождаются числовыми полями;
— Некоторые числовые поля позволяют менять единицы измерения;
— Многие особенности панели свойств обусловлены необходимостью экономить место: частое использование раскрывающихся списков (вместо групп радиокнопок), модальные окна с дополнительными возможностями, расположение подписей к полям сбоку (расположение сверху увеличивает скорость заполнения всей формы, но на панели свойств этого не требуется), частое использование сегментированного переключателя (segmented control) с иконками;
— Иногда подписи располагаются под полями, состоят из одной буквы или иконки;
— При неправильном заполнении поля приложение не отображает сообщение об ошибке и может удалить некорректный ввод. Ожидается, что пользователь профессионального продукта знает, какие значения вводить;
— Визуализируйте редактируемые свойства. Пример: блок Constraints в Фигме;
— Дайте скрыть и показать панель свойств, если пользователю потребуется больше места на экране.

In English.