Статистика ВК сообщества "UX Notes"

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

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

В Heads and Hands написали о приоритизации фич по модели Кано.

— Все фичи можно разделить на базовые, желаемые и восхищающие. Первые определяют жизнеспособность продукта, а остальные — его конкурентоспособность;
— Базовые фичи должны быть в продукте по умолчанию. Люди к ним привыкли, раздражаются и перестают пользоваться продуктом, если их нет. Например, отправка и получение электронных писем;
— Желаемые — повышают уровень сервиса и помогают выделиться среди конкурентов. Чем лучше они развиты, тем выше люди оценивают продукт и тем больше готовы платить. При этом они не перестанут пользоваться продуктом, если их нет. Например, облачное хранилище для документов из электронных писем;
— Восхищающие — вызывают вау-эффект и запускают сарафанное радио (92% клиентов доверяют ему больше, чем рекламе), люди не ожидают их увидеть. Например, встроенный сканер документов;
— Чтобы понять, какие фичи к какой категории стоит отнести, можно опросить представителей целевой аудитории (пример анкеты есть в статье);
— В первую очередь надо инвестировать в базовые фичи и доводить их до идеала. Далее надо выбрать и развивать несколько желаемых фич, чтобы продукт стал конкурентоспособным. Потом можно переходить к восхищающим;
— Важно помнить: восхищающие фичи завтра могут стать желаемым, а через несколько лет — базовым.

Роман Местер написал о коридорном тесте.

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

Илона Саркисова завершила серию статей о Customer Journey Map рассказом о том, что делать, если пользователь не является покупателем.

— Пользователями могут быть сотрудники организации. Им не нужно узнавать о продукте и покупать его, так как его навязывает работодатель;
— Классическая CJM им не подходит, но чтобы создать удобный продукт, полезно хоть как-то картировать их опыт;
— Полезен сам процесс создания карты — помогает активировать эмпатию;
— Сначала сформулируйте, для чего нужна карта и что она будет иллюстрировать;
— Для b2b-продуктов может быть непросто определить, чей опыт картировать, так как в работу могут быть вовлечены разные роли, действия которых взаимозависимы;
— Рамки, когда начинается и заканчивается картируемый опыт, зависят от цели проекта. Найдите очевидные моменты начала и окончания и немного отступите от них, чтобы проверить, нет ли ещё важных шагов;
— Состав информации на карте (слои) тоже зависит от целей проекта и должен помогать фокусироваться на главном;
— Процесс картирования: Инициирование → Исследование → Визуализация → Синхронизация (ключевой этап);
— Процесс несколько сместился от создания документа отчётности к созданию практического инструмента. Главным стал не итог, а путь к нему. Авторы карты превращаются в своего рода координаторов, а карта — в трамплин для коллективного осмысления пользовательского опыта (Джим Калбах);
— Поэтому важно правильно инициировать: определить участников, продать им эту активность, спланировать работу до, во время и после воркшопа;
— При визуализации не сковывайте себя типовыми шаблонами, при необходимости меняйте их под себя, а также упрощайте (избегайте больших текстов, визуального шума), выделяйте важное, устраняйте двусмысленность, группируйте всё, что связано;
— Ещё Илона рассмотрела разные виды карт: Service Blueprint, User Experience Map, User Stories Map, Empathy Map.

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

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

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

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

[id168282386|Андрей Яремко] поделился мнением о разделении на UX и UI.

— UI — как выглядит интерфейс, его логика и опыт взаимодействия пользователя с этим интерфейсом;
— UX — вообще не про дизайн, а про деньги и степень ограничения пользователя;
— Разделение UX и UI излишне, одно без другого никому не нужно. В чём ценность дизайнера, который отвечает только за красоту, когда есть множество UI-китов, с которыми любой UX-дизайнер соберёт макет?
— Опыт взаимодействия с интерфейсом — это про удобство. Но это не то же, что опыт взаимодействия с продуктом. Последнее — про деньги и внедрение в продукт ограничений и неудобств;
— Если посмотреть патенты Match Group (Tinder) или Amazon, улучшение пользовательского опыта связано не с интерфейсом, а с искусственным интеллектом, сегментированием аудитории, логикой ранжирования и подбора товаров, новыми способами заработать;
— UX пересекается с UI, формируя для последнего требования к интерфейсу и логике работы системы. Например, хороший UX в онлайн-игре формируется не балансом или интерфейсом, а наличием системы региональных серверов, обеспечивающих хороший пинг;
— UX — баланс между ограничениями и неудобствами пользователя и оптимизацией доходов.

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

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

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

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

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

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

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

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

Энтони Ценг написал об адаптации таблиц под маленькие экраны.

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

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

— Здоровье — очень интимная тема, что повышает требования к навыкам интервьюеров. Лучше, если это будут профессиональные социологи;
— Врачи — довольно закрытая социальная группа. Это мешает исследовать их реальное, а не декларируемое поведение. Но они готовы помогать своим. Надо формировать базу лояльных врачей;
— Дизайнеры не могут отталкиваться от собственного опыта. Методика исследования и эксперты здесь критически важны;
— Интерфейсы врача и пациента принципиально отличаются, основываются на разных сценариях. При этом интересы врача приоритетнее;
— Уровень технической грамотности врача не обязан быть высоким, их не за это ценят и не будут увольнять за неспособность освоить интерфейс. Привлекайте врачей не только к тестированию, но и к экспертной оценке интерфейсов;
— Работа врача строго регламентирована. Предложения изменить процесс часто оказываются неуместными. С одной стороны, так проще проектировать, с другой — сложнее сделать инструмент удобным;
— Интерфейс могут использовать люди в стрессе. Появляются требования к размерам элементов и шрифта, контрастности, отсутствию визуального шума;
— У врачей повышенные требования к информации, необходимой для принятия решения. Находите точки принятия решений и совместно определяйте, какая информация необходима.