Джастин Вин написала о заблокированных кнопках. Они показывают, что действие пользователю почему-то недоступно (нет прав, не введены обязательные данные, не выполнены какие-либо условия).

— Если человеку не важно знать, что есть какое-то недоступное ему действие, заблокированную кнопку лучше скрыть. Например, кнопку добавления комментария, если комментирование пользователю недоступно;
— Добавьте объяснение, почему действие недоступно (рядом или во всплывающей подсказке);
— Если условия, при которых кнопка окажется заблокированной, маловероятны, можно её не блокировать и показывать сообщение об ошибке при необходимости.

https://ux.pub/reshenie-problem-neaktivnyh-knopok/

Мариана Варгас привела примеры тёмных паттернов из популярных сервисов.

1. Замаскированная реклама — имитирует контент или навигацию. Например: реклама в ленте Ютуба, похожая на видео;
2. Тараканья ловушка — упрощение попадания в определённую ситуацию и затруднение выхода из неё. Например: создание и удаление профиля в Спотифае и Инстаграме;
3. Заманить и подменить — пользователь хочет сделать одно, но вместо этого делает что-то другое. Например: в ленте Реддита нажатие на картинку в рекламном посте открывает рекламируемый сайт, а не увеличивает картинку, как обычно;
4. Принудительное продолжение — списание денег с карты без предупреждений после окончания пробного периода. Например: Skillshare;
5. Подтверждение с укором — пользователя стыдят за выбор, который он собирается сделать. Например: подтверждение отключения уведомлений в Wish;
6. Предотвращение сравнения цен. Например: в АлиЭкспрессе конкретные цены видны в результатах поиска, а в карточке товара отображается ценовой диапазон. Чтобы узнать цену, надо выбрать количество, цвет и способ доставки;
7. Скрытые затраты — неожиданное увеличение цены на последнем этапе оформления заказа из-за налогов, доставки и прочего. Например: broadway.com.

https://habr.com/ru/company/alconost/blog/548600/

Пора начинать в этом разбираться, так как рано или поздно такие приёмы запретят на законодательном уровне: https://vc.ru/design/221548

Кирилл Шерстобитов написал о тестировании User Flow продукта.

Если продукт уже работает:

— Можно дать респондентам задание и по итогам прохождения задать вопросы из анкеты оценки юзабилити (System Usability Scale). Полезно таким же способом проверить конкурентов и сравнить результаты. Опрос даёт количественные оценки и прямую речь респондентов;
— Провести удалённое немодерируемое тестирование. Респонденты выполняют задание под запись экрана, а потом дают обратную связь. Тестирование помогает увидеть, с какими проблемами сталкиваются люди, но не позволяет уточнить у них непонятные моменты;
— Провести модерируемое тестирование. Интервьюер очно или удалённо наблюдает за респондентом и может задать уточняющие вопросы. Более трудоёмкий способ, требующий определённой квалификации.

Если продукт ещё в разработке, для каждого шага сценария можно провести First Click Test: показать дизайн или эскизы респондентам, дать задание и посмотреть, куда они нажмут. Тест даёт количественные данные, можно понять, какой шаг вызывает затруднения.

https://vc.ru/design/200804

Михаил Руденко написал о сложностях стартапов-маркетплейсов.

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

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

https://blog.buro.cx/nie-nachinaitie-startap-s-markietplieisa/

Леван Джамелашвили проанализировал тёмные паттерны в интерфейсе отмены подписки на «Яндекс Плюс».

1. На всех шагах мастера отмены подписки есть манипуляция с помощью визуальной иерархии и акцентного цвета.

Обычно интерфейсы облегчают пользовательский путь в рамках конкретного сценария, делая акцентными кнопки, которые скорее всего пользователь нажмёт. Люди к этому привыкли. Пользователь, который отменяет подписку, скорее всего подтвердит отмену на каждом шаге мастера. Но в интерфейсе Яндекса выделена кнопка «Оставить подписку».

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

3. На пятом шаге пользователя обманывают текстом «Ваша подписка закончится прямо сейчас». На самом деле, подписка сохранится до момента следующей оплаты. Конкретно в этом случае подписка сохранялась ещё на месяц.

От себя добавлю, что само по себе разделение процесса отписки на 5 шагов — тоже тёмный паттерн.

https://designpub.ru/630a057c60dd

Антонина Хисаметдинова рассказала, как сообщать пользователям об ошибках.

Хорошее сообщение об ошибке:
— Снижает нагрузку на техническую поддержку и персонал;
— Помогает пользователю пройти по воронке конверсии;
— Обучает работе с сервисом;
— Позволяет сохранить доверие к сервису в трудную минуту.

Если ошибка связана с глобальным сбоем:
— Сообщите, когда примерно устраните сбой: 15 минут, час, 5 часов, сутки;
— Сообщите, работают ли другие важные сервисы компании. Например, при сбое в личном кабинете банка полезно понимать, работают ли его карточки;
— Подскажите альтернативные способы выполнить целевое действие. Например, если не работает ЛК банка, баланс можно проверить с помощью смс;
— Если это профессиональный инструмент, с которым пользователь работает каждый день, сообщите о сбое.

Если ошибся пользователь:
— Разместите сообщение об ошибке в фокусе его внимания. Например, рядом с кнопкой «Войти» в форме входа;
— Сократите текст сообщения, переместите суть в самое начало;
— Подскажите, как исправить ошибку;
— Сохраните данные, которые пользователь ввёл.

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

https://habr.com/ru/company/jugru/blog/353668/

В Usethics написали о клик-тесте скриншотов (First Click Test).

Удалённое немодерируемое юзабилити-тестирование — простой способ проверить идею интерфейса. Но без участия модератора респондент не узнает об ограничениях прототипа и качество исследования будет зависеть от его реалистичности.

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

Процесс взаимодействия надо разбить на задачи, выполняемые в один или 2−3 клика. Обычно результат — карта кликов для каждого экрана.

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

Важно:
— Чтобы изображения были хорошего качества;
— Добавить экраны, которые вы не тестируете, но которые помогают респондентам понять процесс взаимодействия.

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

#user_testing

Юля Кондратьева написала об исследовании звуковых сигналов медицинского оборудования.

Для кардиомониторов, систем вентиляции лёгких и подобного есть стандарт по звукам. В мелодиях зашифрованы конкретные фразы, например, Car-di-ac A-larm звучит как C4 E4 G4 — G4 C5 (музыканты поймут), количество слогов и нот совпадает.

Проблема в том, что мелодии никто не тестировал. Звук раздражает пациентов, особенно, если работает несколько аппаратов (дьявольский тритон). Медикам в целом всё равно — они привыкли.

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

Тесты показали:
— Респонденты быстрее определяют смысл таких мелодий и меньше ошибаются;
— Проще определяют направление звука. Актуально, когда врач находится в палате с несколькими пациентами.

https://habr.com/ru/post/537434/

Фейфей Лиу из Nielsen Norman Group написала об изменении дизайна для глобальной аудитории:

— Иногда простого перевода недостаточно, нужна локализация;
— Даже люди, говорящие на одном языке, могут сильно отличаться. Например, у сайта Apple есть отдельные франкоязычные версии для пользователей из Франции и из канадской провинции Квебек;
— Культурные отличия можно оценить по шкалам Хофстеде: 1) Степень принятия неравномерного распределения власти; 2) Индивидуализм — коллективизм; 3) Мужественность — женственность; 4) Степень страха перед неопределённостью; 5) Долгосрочная — краткосрочная ориентация; 6) Потакание желаниям — сдержанность;
— На сайте Hofstede Insights можно сравнить страны по этим шкалам. Например, США схожи с Австралией и отличаются от Японии. Если отличия заметны, стоит задуматься о локализации;
— Тем больше нужна локализация, чем чаще люди пользуются продуктом, чем сложнее контекст использования (на ходу, в мобильном), если продукт создан для взаимодействия групп людей, если локальные конкуренты в чём-то сильно отличаются (например, в Индии и Китае предпочитают одноразовые пароли в интернет-магазинах);
— Но объём локального рынка должен окупить инвестиции в локализацию, так как она дороже перевода;
— Вы можете сильно отличаться от пользователей на локальном рынке, исследуйте аудиторию, тестируйте на ней продукт.

https://ux.pub/izmenite-svoy-dizayn-dlya-globalnoy-auditorii-issledovanie-kross-kulturnogo-ux-dizayn/

Брет Виктор в 2011-м написал о взаимодействии с тачскринами, а Константин Рисков перевёл (с сокращениями и дополнениями).

«Вы комбинируете разные захваты, когда откручиваете крышки на банках. Скорее всего, вы этому не учились и даже не осознавали, что и как делаете. Это ли не интуитивно понятный интерфейс?

Мы живём в трёхмерном мире. Наши руки предназначены для перемещения и вращения предметов в трёх измерениях, чтобы брать их и размещать над, под, рядом и внутри друг друга. На Земле нет более ловких существ, чем мы.

В следующий раз, когда будете делать бутерброд, обратите внимание на свои руки: на бесчисленные маленькие хитрости пальцев, манипулирующих ингредиентами, посудой и всеми другими задействованными предметами. Затем сравните свой опыт со скольжением пальца по поверхности тачскрина».

«Имея в своём распоряжении всё тело, неужели вы всерьёз полагаете, что будущее взаимодействия заключается в одном пальце?»

https://habr.com/ru/company/dododev/blog/551474/

Пейдж Лаубхаймер из Nielsen Norman Group написал о прилипающих шапках.

Прилипающая (постоянно отображающаяся) шапка — фиксация шапки сайта в определённом месте экрана во время прокрутки содержимого страницы. Ещё есть непостоянно отображающаяся шапка, которая скрывается при прокрутке страницы вниз и появляется при прокрутке наверх.

1. Размеры такой шапки должны быть минимально возможными, особенно на мобильных. Конечно, текст в ней должен оставаться читаемым, а области нажатия быть достаточно большими.

2. Делайте её непрозрачной и отделяйте от остального содержимого страницы (фоном или рамкой). В том числе отображающиеся в ней подменю.

3. Минимум анимации. Анимировать можно замену большой шапки на более компактную прилипающую. Она должна происходить со скоростью прокрутки страницы. Также шапка должна оставаться в определённом месте экрана, а не прилетать туда с задержкой вслед за прокруткой страницы (Stalker Menu).

4. В идеале при появлении непостоянно отображающейся шапки у пользователя должно быть ощущение, будто она появляется синхронно с содержимым страницы. При прокрутке наверх для верхней шапки можно использовать анимацию Slide In длительностью примерно 300−400 мс.

5. Подумайте, что будет в шапке? Насколько вероятно, что эти элементы потребуются во время посещения вашего сайта? Прилипающая шапка нужна не всегда.

https://ux.pub/5-sposobov-uluchsheniya-lipkoy-shapki-sticky-header-ot-nielsen-norman-group/

В «Собаке Павловой» написали об аудите интерфейса.

Пирамида требований к интерфейсу: выполнимость → надёжность → удобство → восприятие. Она помогает спланировать исследование и приоритизировать найденные недоработки.

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

Далее надо пройтись по сценариям и проверить, соответствует ли интерфейс требованиям:

1. Выполнимость. Интерфейс позволяет пользователю выполнить базовые задачи в рамках экрана и сценария в целом. Это касается даже профессиональных интерфейсов. Кажется, что там точно всё работает (если бы что-то сломалось, кто-то рассказал бы), но нет.

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

3. Удобство. В интерфейс заложены эффективные паттерны взаимодействия.

4. Восприятие. Интерфейс устанавливает положительную связь с пользователем с помощью UI, текста, голоса бренда, анимации, иллюстраций.

#audit

Николай Крылов сделал подробный конспект книги Роберта Фитцпатрика «Спроси маму».

— Мнения бесполезны;
— Любые прогнозы — ложь, причём чересчур оптимистичная;
— Некоторые проблемы не являются проблемами;
— Идеи и запросы функций надо анализировать, а не слепо реализовывать;
— Если вы рассказали о своей идее, окружающие постараются пощадить ваши чувства;
— Если вы будете настойчиво говорить о своей идее, любой скажет, что она великолепна;
— В любом разговоре задавайте хотя бы один вопрос, который приводит вас в ужас;
— «Ну да…» и «Да ну…» звучат надёжнее, чем «Вау». Нельзя построить бизнес, опираясь на восторженные отклики;
— Двигайтесь от общего к частному и углубляйтесь в детали, пока не получите мощный сигнал;
— У вас всегда должны быть готовы 3 самых важных вопроса;
— Знакомиться с клиентами и их проблемами лучше в коротких беседах, чем в долгих формальных переговорах;
— Если кажется, что собеседник делает одолжение, разговаривая с вами, возможно, беседа слишком формальна;
— Говорите об идее как можно меньше, но направляйте беседу в нужное русло;
— Если после встречи непонятно, что будет дальше, встреча была бесполезной;
— Проводите встречи до тех пор, пока слышите на них новое;
— Пока не настроитесь на поиск чётко сформулированных, непротиворечивых проблем и целей, ваш клиентский сегмент останется размытым;
— Если не понимаете, где искать собеседников, продолжайте делить выбранный сегмент на меньшие подгруппы, пока не поймёте;
— Если неясно, что вы хотите узнать, не стоит заводить разговор;
— Заметки бесполезны, если ими не пользоваться.

https://vc.ru/books/95793

Джон Анкарстрем раскритиковал, как сейчас работает адаптивный дизайн.

Обычно он работает так: пользователь меняет ширину окна браузера, а сайт в ответ делает редизайн. Всё, что человек успел запомнить о расположении ссылок и блоков, вылетает в трубу.

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

Подходящую ширину придётся искать для каждого нового сайта, так как дизайнеры почти никогда не указывают одну и ту же ширину в медиазапросах.

Можно отключить медиазапросы в браузере, но чаще всего по умолчанию будет отображаться мобильная версия (подход Mobile First).

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

https://habr.com/ru/company/macloud/blog/554650/

Ричард Янг написал об оценке затрат на взаимодействие.

— Затраты на взаимодействие — ментальные и физические усилия, прилагаемые для достижения цели;
— Чем больше сценариев охватывает продукт, тем сложнее его информационная архитектура и навигация;
— Уменьшайте затраты на взаимодействие в основных сценариях;
— Можно выделить красные маршруты (Red Route Analysis) — сценарии, которыми часто пользуется большинство пользователей. Заказ машины в Убере — красный маршрут, добавление способа оплаты — обычный;
— У всех систем есть свой уровень сложности. Хороший дизайн — когда большая часть сложности ложится на систему, а не на пользователя;
— Ментальные затраты на взаимодействие увеличиваются из-за сложной навигации, непонятных инструкций, непривычных паттернов взаимодействия;
— Важные компоненты ментальных затрат — нагрузка внимания и памяти. Внимание рассеивают всплывающие баннеры, визуальные эффекты и движения, не связанные с пользовательской задачей;
— Если айтрекинг показал множество саккад, не относящихся к текущей задаче, в интерфейсе могут быть отвлекающие факторы;
— Время принятия решения увеличивается вместе с количеством вариантов и сложностью выбора (закон Хика). Выделяйте наилучший для пользователя вариант;
— Пользователи с высокой мотивацией (благодаря маркетинговым усилиям или уникальности продукта) с большой вероятностью достигнут цели даже с высокими затратами на взаимодействие. Если продукт типовой и у конкурентов удобнее, клиенты купят у них.

https://deadsign.ru/ux/interaction-design-is-more-than-just-user-flows-and-clicks/

Роман Кирьяков рассказал о подготовке к тестированию посадочной страницы.

Тесты похожи на коридорные: исследователи узнают у респондентов, как они понимают продукт и как пользовались бы им в реальной жизни.

Программа тестирования помогает структурировать информацию, сохранять фокус тестирования, формировать правильные ожидания у заказчика исследования, получать релевантные данные.

Она включает блоки:

1. Проблемная ситуация — описание проблемы, которую хотят решить с помощью тестирования. Если сформулировать её неправильно, вся остальная программа будет некорректна. Пример: есть лендинг о страховке квартиры, конверсия на нём низкая, но мы не понимаем, в чём именно причина.

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

3. Задачи. Например:
— Понять, какой информации людям не хватает;
— С какими сложностями они сталкиваются при оформлении страховки;
— Как понимают информацию на странице.

4. Выборка — требования к респондентам. Когда в тестировании участвует только целевая аудитория, шансы получить полезную обратную связь возрастают.

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

https://www.it-agency.ru/academy/landing-page-ux/

Роман Шамин написал, как дизайнеры могут облегчить жизнь фронтам.

— Создавайте дизайн-систему и стройте дизайн из ограниченного набора стилей, переиспользуемых компонентов и последовательных правил компоновки;
— Оформляйте изменения дизайн-системы как фичи;
— Разделяйте большие фичи на небольшие задачи, которые можно дизайнить, верстать и выкатывать по очереди;
— Уважайте мнение технической команды, объясняйте им свои дизайн-решения, утверждайте у них макеты;
— Если нарисованное трудно реализовать, обсуждайте с командой и ищите выход вместе;
— Все знания о фиче собирайте в одном месте (например, на большом артборде в Фигме), все идеи объясняйте текстом и графикой: показывайте стрелками флоу и так далее;
— Будьте в курсе технологий. Например, если приложение использует геолокацию, здорово понимать, что она может быть отключена на устройстве пользователя.

https://teletype.in/@romanshamin/what-frontend-want-from-design

Илья Бирман написал о бессмысленных действиях в интерфейсе.

В Файндере несколько лет назад появилась команда New Folder with Selection (⌃⌘N). Если выделить несколько файлов или папок и вызвать её, она создавала новую папку, перемещала в неё всё выделенное и давала назвать папку.

Когда эта функция появилась, она работала только если изначально было выделено хотя бы два файла. Если просто курсор стоит на файле, «завернуть» его в папку этой командой было нельзя. Видимо, программист решил, что группировать один файл «нет смысла». В более поздних версиях Макоса нелепое ограничение убрали.

Не надо запрещать пользователям бессмысленные действия, если сами по себе они безвредны.

— Можно не писать код этого возможно бессмысленного запрета;
— Запрета в лучшем случае никто не заметит, в худшем он будет мешать работать;
— Если люди совершают это бессмысленное действие, возможно, дизайнеры упустили какой-то сценарий.

https://ilyabirman.ru/meanwhile/all/meaningless-actions/

Михаил Озорнин поделился частью гайдлайна о передаче макетов разработчикам. Например:

Другие состояния:
— Понятно, как сделать все остальные состояния: переключенные вкладки, переключатели, чекбоксы и радиокнопки (если они влияют на компоновку интерфейса);
— Отрисованы или описаны (если этого достаточно) все варианты дропдаунов, селектов и других выпадаек;
— Кроме самих этих состояний описаны переходы между ними;
— Уровень «Хорошо»: если блоки меняются значительно, то лучше не пытаться описать отдельные выпадайки, а нарисовать блоки целиком, чтобы было меньше путаницы.

Загрузка:
— Понятно, как загружаются элементы экрана, в какой последовательности, как отображается процесс загрузки;
— Как должен вести себя продукт, если загрузка медленная, элементов много или загрузка не удалась.

Пустое состояние:
— Понятно, как выглядит пустое состояние всех блоков и элементов, когда в них нет данных;
— Уровень «Хорошо»: пустые состояния систематизированы, используются типовые решения.

http://mikeozornin.ru/blog/all/what-is-a-good-handoff/

Александра Вельянинова сделала для Райффайзенбанка методичку о тексте в интерфейсе. Отдельные интересные рекомендации:

— Без вранья. Формулируйте аккуратно и не обманывайте ожиданий пользователя даже в мелочах. «Нужен адрес, и мы найдём счета на оплату» → «Нужен адрес, чтобы поискать счета на оплату»;
— В объяснении ставьте действия в том порядке, в котором человек будет их выполнять. «Создайте шаблон, выбрав подходящую операцию из списка» → «Выберите операцию и создайте на её основе шаблон»;
— Очеловечивая текст, не переигрывайте. Когда в последний раз вы получали «Ах да» от друга в чате?
— Без лишних восторгов, особенно в неподходящем контексте. «Ура! Теперь штрафы будут приходить в приложение [Супер!]» → «Теперь штрафы будут приходить в приложение [Хорошо]»;
— Не оценивайте чувства пользователя. «Не волнуйтесь, сейчас разберёмся» → «Сейчас разберёмся, уже смотрю, что произошло»;
— Пишите гендерно нейтрально. «Я согласен с политикой обработки данных» → «Я соглашаюсь с политикой обработки данных»;
— Заголовки проще воспринимать в именительном падеже. «Какую карту хотите? Цифровую. Пластиковую» → «Какая карта подойдёт? Цифровая. Пластиковая»;
— Не проговаривайте текстом функции знакомых элементов. Плейсхолдер в поле поиска: «Поиск по названию или ИНН» → «Поставщик или ИНН».

https://www.figma.com/proto/0JyAj15IhSa3cnf4tl2vmr/Raiffeisen-Verbal-Guide?node-id=15825:39622&scaling=scale-down