UX Notes

Дмитрий Сергушкин написал, как сделать таблицы удобнее.

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

In English. #table

Егор Камелев написал об автофокусе на первом поле формы.

— Автоматически помещать фокус на первом поле формы рекомендуют, чтобы открывший её пользователь сразу, без лишних действий, смог ввести данные;
— Это хорошее базовое правило, которое можно применять по умолчанию. При этом не стоит забывать о нюансах, из-за которых от него стоит отступить;
— Если форма — не единственное содержимое страницы и находится где-то внизу, автофокус прокрутит страницу к форме и помешает изучить страницу;
— В мобайле автофокус приведёт к появлению экранной клавиатуры, что затруднит ознакомление с формой в целом;
— Бывают формы, которые часть пользователей может заполнять не с первого поля;
— Либо этому первому полю может предшествовать информация о регионе с контролом его изменения. И это изменение значительно меняет форму.

#form

Светлана Юдина написала о Product score — комплексной оценке UX и UI в продуктах.

— Продакты мыслят цифрами, поэтому UX-проблемы часто ускользают из их поля зрения;
— Product score даёт числовую оценку качества пользовательского опыта;
— В Сравни этим проактивно, без запросов от продуктовых команд, занимается внутренняя UX-лаборатория;
— Периодическая оценка позволяет отслеживать изменения в продукте, сравнить продукты между собой и находить конкретные места для улучшения;
— UX оценивают с респондентами (по 6 на сегмент), которые на проде со своими реальными данными проходят полный флоу оформления покупки или использования услуги;
— Исследователь вмешивается только если респондент зашёл в тупик, чтобы посмотреть весь флоу;
— Он фиксирует количество пройденных этапов и места, где респондент споткнулся, а также оценивает критичность этих проблем: низкая, средняя, высокая;
— В конце респондент по 5-бальной шкале оценивает удобство сервиса и скорость прохождения сценария;
— Всё это складывается в оценку UX от 0 до 100% (хитрые формулы смотрите в статье);
— Дизайнер из другой команды с чеклистом по 5-бальной шкале оценивает UI по параметрам: понятность и логичность, типографика и текст, анимация, графика, консистентность;
— Он может также предложить рекомендации по улучшению UI;
— Оценка UX оставляет 75% от итоговой, оценка UI — 25%;
— Product score и рекомендации передают команде, бизнес-оунерам и партнёрам, так как часть флоу иногда проходит в интерфейсах партнёров.

#metrics

С прошлого анонса в @uxwork кроме вакансий вышли ещё материалы:

— О красных и зелёных флагах во время интервью с кандидатами;
— О разных форматах оплаты при работе с заказчиками (почасовка, фикс, абонемент) и примере пути фрилансера от одного формата к другому;
— О поиске работы в сравнении с поиском спутника жизни в дейтинговом сервисе.

Карен Ананян написал о подходе Stretch, Scale, Switch при проектировании адаптивных состояний.

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

#adaptive

Энтони Ценг написал о сегментированных переключателях в формах.

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

In English. #chips #toggle #segmented_control

Антон из X5 Tech написал о скелетонах.

— Это такая загрузка экрана, когда сначала отображаются серые прямоугольники, а потом вместо них появляется контент;
— Их важно анимировать, чтобы всё это не было похоже на баг;
— Прижилась пульсация (мерцание) и волна (единое для всех блоков смещение градиента, background: fixed);
— Плюс скелетона в предварительном представлении структуры экрана и возможности отображать контент по мере его загрузки;
— Каждый прямоугольник скелетона — обёртка для контента и заглушка на время загрузки;
— Но что должно быть внутри обёртки: атом, молекула или организм в терминах атомарного дизайна?
— Отдельными блоками скелетона может быть то, что запрашивается с сервера отдельными запросами;
— Скелетировать можно всю страницу (высоконагруженные проекты, у значимой доли пользователей плохой интернет), её части (тяжёлые блоки с таблицами, статистикой) или отдельные элементы (результат множества запросов, сложного вычисления и так далее);
— Будьте последовательны. Если где-то есть скелетоны, спиннеры в раскрывающихся списках смотрятся странно;
— Заглушки должны соответствовать размеру контента (в первую очередь высоте), чтобы при загрузке ничего не скакало, а также его внешнему виду, чтобы не сильно контрастировать с контентом;
— Если в карточках может быть разный состав контента, ради простоты можно сделать для всех карточек одну усреднённую заглушку;
— Высокая детализация требует затрат, которые не всегда оправданы. Например, вкладки могут быть одним прямоугольником. Обычно это один компонент на странице, его заглушка воспринимается как заголовок, да и показывать заглушки отдельных табов непросто;
— Но иногда повышение детализации имеет смысл и помогает сразу привлечь внимание к определённой части страницы;
— Повторяющиеся элементы вроде ячеек с текстом в таблице можно скелетировать красиво, сделав заглушки разной ширины (90, 75, 85, 80, 65% от ширины ячейки) и сохранив выравнивание.

#loader

Юрий Герыш написал о работе с Chrome DevTools.

— Открыть их можно через меню (пункт «Инструменты разработчика») или нажав правой кнопкой мыши в любом месте страницы (пункт «Просмотр кода страницы»);
— Экспорт изображений в формате SVG: скопируйте содержимое тега <svg> из кода страницы и вставьте в Фигму;
— Если картинка в формате PNG, можно поискать её SVG-версию на сайте: добавьте к адресу картинки «?svg», например: «https://habr.com/img/habr-logo-ru.png?svg»;
— Меняя код CSS (вкладка Styles), можно быстро прикидывать стилевые правки;
— В Styles можно видеть и менять правила, определяющие внешний вид страницы;
— На вкладке Computed отображаются текущие свойства выбранного элемента, которые получились после применения всех правил. Например, сколько в пикселях составила ширина, которую задали в процентах;
— Меняя HTML, можно править текст, дублировать и удалять элементы;
— Так можно проверить поведение элементов в корнер-кейсах. Например, что будет, если название слишком длинное;
— Просмотр адаптивных состояний: можно задать размер окна браузера. Есть пресеты размеров популярных устройств;
— Чтобы выбирать Инспектором элементы, свёрстанные с помощью Shadow DOM (изолирование стилей элемента), включите в настройках «Show user agent shadow DOM»;
— Просмотр состояний элементов (hover, active): список состояний отображается на вкладке Styles с нажатым «:hov», либо можно выделить элемент через Инспектор и в контекстном меню нажать «Force state».

#review #chrome_devtools

Женя Белодед поделился процессом и находками из исследования касс самообслуживания.

— Для сокращения воровства в «Пятёрочке» касса выводит изображение со своей камеры прямо в интерфейс и так показывает, что за покупателем наблюдают;
— Удобно, когда кнопки «Каталог», «Пакеты» и «Позвать на помощь» доступны всегда. В любой момент можно взять пакет, если не рассчитал вместимость рюкзака, и позвать консультанта, если возникли вопросы;
— С верхней частью экрана взаимодействовать неудобно. Все важные элементы лучше размещать в нижней, а список товаров формировать снизу вверх;
— Длинный список товаров должен прокручиваться автоматически, чтобы последние отсканированные позиции были видны сразу;
— Большой экран устройства скорее усложняет использование, надо искать способы оптимизации «пробега» пальца и глаза;
— Обозначение товаров 18+ и 16+ в списке помогает консультантам быстрее в нём ориентироваться, когда надо подтвердить возраст покупателя;
— Компактнее и удобнее объединять одинаковые товары в одну строку, указывая количество штук;
— Если показывать старую и новую цену для товаров со скидкой и акционных, экономия станет наглядной, снизится стресс от покупки;
— В сложных ситуациях помогают интерфейсные подсказки о действиях пользователя в кассе и вне её;
— Как справляться с косыми взглядами охранников: «Придумал историю, что возрастная мама хотела бы начать пользоваться кассой самообслуживания, но боится, что не разберётся и будет выглядеть глупо. Поэтому попросила сына записать видеоинструкцию, чтобы разобраться дома. С такой легендой охранники были спокойны, а консультанты без проблем всё показывали и комментировали прямо на камеру».

Копия на Хабре. #retail #self_checkout

Виктория Друзенко написала о прокачке UI.

— Навыки UI-дизайна могут просесть, если долго работать с дизайн-системой на одном продукте;
— UI Daily может не подойти, так как макеты там оторваны от контекста, и надо тратить время на его додумывание;
— Переделывайте макеты из своих старых проектов. Подойдут даже макеты с предыдущего спринта;
— Так вы увидите свой прогресс, можете пересмотреть решения и улучшить UX, не будет ограничений со стороны заказчиков и разработки, а результат можно положить в портфолио;
— Анализируйте чужой дизайн, выделяя удачные и неудачные решения, предлагайте альтернативы;
— Публикуйте свои наблюдения там, где другие дизайнеры могут их увидеть и обсудить, это даст обратную связь;
— Так вы научитесь давать обратную связь, прокачаете насмотренность;
— Вовлекайте коллег, знакомых дизайнеров, менторов;
— Помимо того, что так веселее, будет больше обратной связи, можно перенять чужой опыт, сложнее слиться с прокачки;
— Перерисовывайте понравившиеся макеты;
— Так ваша база UI-решений будет расти. Вы будете не только знать разные визуальные ходы, но и уметь их воспроизвести;
— Можно попробовать новые инструменты для оптимизации работы. Если надо перерисовать экран, стоит подумать, как сделать это быстрее и качественнее.

#visual #upskilling

Егор Камелев написал, как минимизировать количество правок, подготовиться к оставшимся и работать с ними, чтобы легче сдавать проекты.

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

#client

Фёдор Миронов написал, как использует Crowdin для перевода текста в интерфейсе.

— Если передавать переводчикам просто текстовые строки без сведений, где они используются и как выглядят, будут ошибки и неестественные формулировки;
— Надо хорошо постараться, чтобы в процессе перевода не было бардака, особенно если работает несколько переводчиков;
— Crowdin хранит идентификаторы строк (ключи), все переводы, их статусы, теги принадлежности к платформам;
— При загрузке текста из Фигмы делает скриншоты и отмечает, где находится текстовая строка, что позволяет переводчику понимать контекст;
— Переводчики могут начинать работу сразу, не дожидаясь готовности макета и вёрстки;
— Плагин Crowdin в Фигме синхронизирует текст и позволяет дизайнеру просматривать переводы прямо в Фигме;
— Перед передачей макетов в разработку дизайнер запускает плагин и создаёт ключи;
— С помощью Select Matching Layers выделите повторяющиеся текстовые слои и переименуйте их, указав предполагаемые ключи. Плагин найдёт дубликаты и свяжет повторяющийся текст с одним ключом;
— Не используйте один ключ для заголовков и текста на кнопках. Они могут совпадать на английском (Transfer/Transfer), а на русском отличаться (Перевод/Перевести). У каждой текстовой роли в интерфейсе должна быть отдельная строка;
— Если в строке есть переменные данные (суммы, даты, имена), не разбивайте строку на части, а используйте переменные. Строка останется целостной и понятной для перевода. Это важно, если порядок слов в переводах может отличаться.

#localization #сrowdin

Сэм Либерти написал об ошибках внедрения геймификации.

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

In English. #gamification

У меня есть канал UX Work. Раньше там были вакансии, которые мне показались интересными. А теперь их будут разбавлять заметки с тезисами избранных материалов о карьере в UX-дизайне: поиск работы и найм (он же наём), прохождение собеседований и вайтбордов, грейды, прокачка, управление командой и так далее.

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

Подписывайтесь на @uxwork!

Андрей написал, почему творчество нельзя подменять креативностью.

— Креативные методологии (фреймворки для быстрого создания новых идей) — узкий инструмент с кучей ограничений, и подменять им творчество нельзя;
— Все они работают примерно так: некий объект раскладывается на составляющие → проводится работа с этими частями (что-то убрать, поменять, добавить, набор операций ограничен) → собирается новый объект;
— Их подают как последовательность действий, переключающих мозг на дивергентное мышление, что даже полезно;
— Постфактум можно увидеть, как эти действия привели к созданию каждой успешной идеи, но просто выполняя эти действия нельзя быть уверенным, что они приведут к успешной идее. Успех зависит от кучи других факторов;
— Творчество начинается с повторения, выработки навыков;
— Затем действия складываются в системы: технологии и методологии. Уже не нужна директивность, задачи объединены в последовательности, которыми человек и оперирует;
— Владея несколькими методологиями, можно выбирать более подходящие и комбинировать их. Это профессиональный кругозор;
— Затем становится доступна творческая деятельность: изобретение новых инструментов, подходов, идей. Это работа уровня RnD-отделов компаний;
— Креативные методологии позволяют получить много поверхностных идей, не сильно в них погружаясь. Годится для маркетинга, но в других сферах работает плохо;
— Создаётся иллюзия, что творчество — это легко и быстро. Но это одна из самых тяжёлых деятельностей: на час брейншторма можно потратить больше сил, чем на полный рабочий день;
— Если заниматься этим постоянно в рамках операционной деятельности, можно выгореть;
— Ломается нормальный процесс набора опыта. Люди занимаются чем-то другим вместо расширения профессионального кругозора, изучения предметной области и системных вещей;
— А ведь только это может привести к прорывным идеям, когда большая часть из них уже сгенерирована и реализована, и требования к продуктам уже не такие, как раньше.

#process

Картинка из UX Notes образца 2014 года, когда телеграм-канала ещё не было, а был паблик в ВК

Рамазан Нурулаев написал о дизайне таблиц для цеха.

— Тонкие шрифты — мимо. Числа должны читаться даже в маске сварщика. Для цифр — моноширинный шрифт;
— Почти всегда нужна тёмная тема;
— Минимум цветов. Новый цвет — только чтобы привлечь внимание к критичным вещам;
— Системная цветовая индикация, которую нельзя изменить: зелёный — всё хорошо, жёлтый — обратить внимание, красный — что-то случилось;
— Есть дополнительные цвета, которые можно назначить выбранным статусам (или переназначить под себя);
— Рекомендации по выбору цвета есть в сторибуке: «фиолетовый для специальных режимов работы»;
— Пользователи попросили добавить легенду во все формы, где есть цветовая индикация;
— Заголовки столбцов были менее контрастными, чем их содержимое, но они плохо считывались. Сделали их контрастнее, а чтобы отделить от цифр, поменяли шрифт;
— Таблицы почти никогда не прокручивают (особенно, по горизонтали), поэтому они должны быть максимально компактными, но не сливаться в кашу;
— 40 px основная высота строки, 56 px — увеличенная, 32 px — компактная. Надо учитывать, что в них могут быть иконки и кнопки;
— Нужна возможность настраивать их под себя: скрывать столбцы, закреплять, менять их порядок;
— Иногда можно заменить заголовки столбцов на более компактные: «Положение плавки» → «Плавка»;
— Чтобы уменьшить визуальный шум, кнопки действий отображаются при наведении на строку. Пользователь примерно понимает, какие действия ему надо совершить;
— Чтобы было понятно, какие ячейки можно редактировать, в них есть кнопка редактирования. Ячейки с отредактированными данными подсвечиваются жёлтым.

#table #industrial

Виктория Друзенко написала о тексте плейсхолдера в поле поиска.

— Если это основная функция, можно написать призыв к действию: «Введите запрос»;
— Если лишь часть данных доступна для поиска, перечислите их: «Трек, альбом, исполнитель»;
— Если поиск ограничен определённым разделом, обозначьте его: «Поиск по каталогу»;
— Если к запросам в поле поиска нет жёстких требований, обозначьте направление: «Куда отправимся»;
— Если вариантов поиска много, и пользователь не знает, как можно сформулировать запрос, напишите примеры: «Искать от холестерина, омега 3, Витамин Д»;
— Если нужен минимализм или поиск не основная функция: «Поиск», «Найти».

#search #writing

Павел Шерер написал о терминах UX и CX и кто кого включает.

— Они связаны, но UX — фундамент. Если вы улучшите форму оплаты, NPS может не сдвинуться, потому что претензии к колл-центру останутся. И наоборот: идеальный CX-чеклист не спасёт, если кнопка «Оплатить» лагает;
— Дон Норман: «UX — все аспекты взаимодействия конечного пользователя с компанией, её услугами и продуктами»;
— ISO 9241-210:2019: «UX — восприятия и реакции человека, возникающие до, во время и после использования системы»;
— То есть это доставка, колл-центр, утилизация, компенсация за некачественную услугу и вообще всё, что потом назвали CX;
— Customer — тот, кто платит. User — любой, кто взаимодействует. CX-сценарии с платящими клиентами — подмножество более широкого множества UX-сценариев;
— Исторически сервис-дизайн и CJM выросли из UX-исследований;
— В плане методологий почти всё берётся из изначальных UX-практик;
— Кто-то считает, что CX важнее, так как фокусируется на том, что приносит компании деньги, помогает растить LTV. Хороший UX тоже влияет на метрики: снижает churn rate и увеличивает retention, что также влияет на выручку.

#definition #cx