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.

Александр Ревенок написал о таком методе исследования как Fake door.

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

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

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

Николай Романов написал, как выстроить лендинг, чтобы его прокручивали до конца.

— Не обманывайте ожиданий: не лейте воду и не меняйте тему;
— Анимацию перехода от одной информации к другой синхронизируйте с прокруткой страницы. Так пользователь будет чувствовать контроль;
— Меняйте ритм повествования. Например, блоком с крупным текстом можно разбавить блоки с заголовками, текстом и картинками;
— Кроме прокрутки предлагайте другие способы взаимодействия: нажать или навести курсор, чтобы узнать детали. Но важно не переборщить: не больше 2–3 механик для лендинга до 20 экранов;
— Иногда лучше немного анимировать статичные картинки, чтобы они привлекали внимание.