Станислав Хрусталёв написал об онбординге в мобильных приложениях.

— Фокусируйтесь не на функциях продукта, а на ценности, которую они несут пользователям. Это могут быть и преимущества компании (бесплатная доставка), и информация об акциях и промокодах;
— Экранов не должно быть много, выделите ключевые ценности;
— На последнем разместите призыв к действию, чтобы переход от онбординга к взаимодействию с продуктом был бесшовным;
— Занимайте онбордингом весь экран (речь о мобильных приложениях);
— В процессе можно собрать первичную информацию о потребностях пользователя и персонализировать последующее взаимодействие;
— Покажите очевидный способ перехода на следующий экран (например, кнопку), но и перемещение свайпами (и тапами по правой и левой стороне экрана) тоже можно реализовать;
— Кнопка должна располагаться в одном и том же месте;
— Переход между экранами может происходить автоматически в формате сторис. Но важно подобрать правильный тайминг и дать возможность приостановить переход;
— Сопровождайте текст визуализацией, чтобы облегчить восприятие и заинтересовать. Она не должна быть слишком абстрактной. Ей может стать часть интерфейса приложения;
— Отображайте Page Control, чтобы управлять ожиданиями о количестве слайдов. Обычно его размещают в нижней части экрана и центрируют по горизонтали;
— Доступ к уведомлениям и геолокации стоит запрашивать, когда есть контекст и потребность, а не в самом начале;
— На экране с пояснением, зачем нужен тот или иной доступ, стоит предусмотреть возможность пропустить и принять решение о доступе потом;
— Кнопка пропуска онбординга должна быть заметной, но не акцентной. Обычно её располагают в правом верхнем углу.

#onboarding

Анна Кейли написала о всплывающих окнах (попапах).

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

In English. #modal #popup

Юлия Салах написала о мелочах, которые помогут улучшить дизайн.

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

#visual

Александра Савельева продолжает цикл статей о проектировании b2b-продуктов. Новая статья рассказывает, что должно быть на страницах таких продуктов.

— Давайте как можно больше информации, её внимательно читают. Так одни клиенты не уйдут, а другие не будут задавать одинаковые вопросы. Делайте это порционно: сначала основное, затем детали;
— Можно разместить призыв задать вопрос, если какой-то информации на странице не хватило;
— Если есть исследования, показывайте, как внедрение продукта влияет на метрики. Например, Slack на 24% ускоряет выход нового сотрудника на максимальную эффективность;
— Показывайте идентификаторы товаров, чтобы опытные клиенты быстро их находили;
— Рассказывайте о соответствии стандартам: требованиям безопасности, доступности и так далее;
— Предлагайте пакетные решения, а также альтернативные варианты и дополнения. Но дополнения должны того стоить, чтобы не подорвать доверие;
— Если добавляете видео, предупреждайте о продолжительности, добавляйте субтитры для тех, кто смотрит без звука. Видео должно быть лаконичным и без громкой музыки;
— Показывайте таблицы сравнения с продуктами конкурентов. Но только непредвзятые, чтобы не подорвать доверие специалистов. Например, в такой таблице на собственном сайте Скетч по многим параметрам превосходит Фигму, но специалисты увидят подвох;
— Сохраняйте страницы архивных продуктов. С них клиент может начать поиск актуальных аналогов;
— Можно добавить калькулятор, но только достаточно лёгкий для освоения. Спроектировать такой будет целым вызовом;
— Предоставьте несколько способов найти информацию: с помощью обычной навигации, каталога, поиска;
— Показывайте цены, это самый главный критерий для принятия решения.

#b2b

Андрей Маркелов написал о дизайне сложных таблиц.

— Шрифты с моноширинными цифрами можно использовать, если в таблице числа не смешаны с буквами (рядом с числом может стоять единица измерения);
— Но лучше использовать полностью моноширинные шрифты, например, очень компактный Ubuntu Mono;
— Числа выравнивайте по правому краю, но текстовые заголовки столбцов с числами — по левому;
— Чтобы повысить читаемость, можно выделить визуальные границы колонок, разорвав разделительную линию;
— Если колонки стоят очень плотно, для отделения разрядов вместо обычного пробела лучше использовать тонкий («thin space», U+2009);
— Единицы измерения обычно пишут в названиях колонок через запятую, но тогда колонка становится шире. Можно располагать их под названием на отдельной строке и выделять цветом;
— Иногда группы колонок полезно сворачивать: для экономии места, для показа результирующей колонки;
— Базовую числовую таблицу можно обогатить инфографикой, цветами и диаграммами. Например, в дополнение к начальной и конечной цене можно показать график её колебания. Вклад каждой облигации в стоимость портфеля можно подсветить градацией зеленого и красного;
— Стоит ввести двойные строки. Например, полезно видеть не только стоимость облигации, но и процент, который она занимает в портфеле.

#table

Даниил Видишев написал, как работать с мелкими багами, появляющимися при реализации дизайна.

— Они бывают визуальными (не те цвета, отступы, анимация) и функциональными (у кнопки нет тултипа). Они не мешают пользователям достигать целей, поэтому получают низкий приоритет;
— В итоге их становится слишком много, чтобы можно было легко исправить, продукт начинает отличаться от макетов, растёт поток обратной связи от пользователей;
— Оформляйте баги правильно: пишите конкретно, что и где надо исправить (карточка пользователя, изменить стиль заголовка с 24 на 28 px), группируйте их с помощью тегов или папок, прикладывайте скриншот проблемы и ссылку на макет;
— Объясняйте команде ценность дизайна;
— Документируйте дизайн: подробно описывайте работу элементов (здесь стоит упомянуть мою статью о функциональной спецификации), прикладывайте референсы анимаций, показывайте в макетах пошаговые сценарии;
— Проводите ревью вёрстки, когда она уже почти готова (вряд ли получится выделить для этого отдельный статус задачи в Джире). Фронтендер может показать наработки на коротком созвоне;
— Если перечисленные выше процессы работают, можно внедрить автотесты на pixel perfect UI.

Смотрите также статьи Алисии Суски и Сэма Айронса о дизайн-долге. #process

Андрей Кононов написал о проектировании сложной функциональности на примере заказа товаров в сетевом магазине.

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

#process

В tubik написали о единообразии в интерфейсе.

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

In English. #heuristic

В uxtrends написали об измерении эффективности дизайна.

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

#metrics

Евгений Паршин написал о Riskiest Assumption Test (RAT).

— Это быстрая проверка идей, провал которых может похоронить весь продукт целиком;
— Для проверки идеи не обязательно нужен MVP. Проверить спрос можно с помощью лендинга с рассказом о продукте и формой заявки;
— Надо 1) выделить рискованные гипотезы — предположения, из-за которых с высокой вероятностью продукт не выживет, 2) оценить степень их значимости, 3) протестировать самые опасные;
— С помощью RAT можно проверить спрос, ценность продукта для пользователя, юнит-экономику и правильность выбранного сегмента;
— Найти рискованные гипотезы можно через исследования, брейнштормы, самостоятельные рассуждения. Например, можно посмотреть на Lean Canvas и спросить себя: что может пойти не так, что мы ошибочно приняли за истину?
— Каждую гипотезу можно оценить по способности похоронить продукт, количеству ресурсов, необходимых для проверки гипотезы, сложности тестирования, времени проверки.

#product #research

Алиса Шефер и Саша Липатова написали, как UX-редакторам встроиться в дизайн-процесс.

— Знакомьтесь с командами не только дизайнеров, но и аналитиков, тестировщиков и маркетологов, которые работают над вашим продуктом. Повторять знакомство можно раз в квартал: люди приходят и уходят, меняются зоны ответственности редакторов;
— Задачи на текст надо ставить одновременно с задачами на дизайн, а если задача небольшая, то хотя бы за неделю до дедлайна. Так можно успеть погрузиться в контекст и собрать вводные, а не просто поправить формулировки;
— Чем полнее задача описана, тем лучше. Смотрите в статье шаблоны с вопросами, что писать в задачах на текст а) целого сценария, б) экрана или попапа, в) письма, пуша или смс;
— Создайте таблицу ответственности (например, в виде модифицированной матрицы RACI), чтобы коллеги легко могли понять, к кому из редакторов обратиться с конкретным вопросом или задачей;
— Разработайте и обновляйте гайды, глоссарии и редполитику. Опишите процесс работы над задачами и отличия разных редакторских ролей: основатель проекта, партнёр, ревьюер. Чтобы эти документы оставались актуальными, бронируйте на них 1 час в день;
— Чтобы новые продакты или тимлиды не забывали подключать редакторов к задачам, проводите 15-минутные онбординги с рассказом о процессе, базе знаний и гайдах;
— Соберите всех пишущих (и UX-редакторов, и копирайтеров из отдела маркетинга) в один чат, чтобы всегда можно было обсудить какие-то изменения в тексте и не копить недопонимание.

#process #writing

Андрей Маркелов написал о шкалах в дизайне графиков.

— Построение графика начинается с выбора осей. Чаще всего это 2 оси. В основе оси — шкала (линия с делениями);
— Вертикальная ось не всегда должна быть слева. В финансовых системах её располагают справа (ближе к более актуальной части графика). А ещё текущую цену выделяют цветом и пунктирной линией от края графика;
— Легче всего читается толщина графика от 1,3 до 1,6 пикселей;
— Вертикальную шкалу нужно подстраивать под значения графика в видимой области. Нижняя точка должна быть чуть ниже минимума на графике, а верхняя точка — чуть выше максимума;
— Шаг вертикальной шкалы выбирается делением на несколько равных частей, чтобы расстояние между делениями было не слишком широким и не слишком узким (от 40 до 90 пикселей). В идеале должны получаться круглые числа;
— Двухсекционная шкала, в которой используется сразу два масштаба, помогает видеть, например, какой отображается год на месячной шкале (используется в терминале Блумберга);
— Шорткаты позволяют быстро посмотреть график за конкретный период. Например, W — за неделю, YTD — от начала года до сегодня. Обычно они размещаются над графиком;
— В финансовых системах графики часто смотрят в процентах. За 100% принимается самая левая точка графика в зоне видимости. Остальные деления пересчитываются в проценты относительно этой отметки;
— Логарифмическая шкала строится так, что рост в N раз будет занимать одинаковую высоту в любом месте графика. Можно сравнивать рост цены в 2 раза полвека назад и в прошлом году, и видеть одинаковое изменение.

Смотрите также, как делать подписи для таймсерий. #data_visualization

Сеара Кроушоу написала о перетаскивании: первая, вторая часть перевода.

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

In English. #drag_and_drop

20 самых популярных постов UX Notes в 2022 году в Телеграме.

Перед прошлым Новым годом я включил реакции, и теперь могу составить топ по обратной связи от читателей в Телеграме. Будет интересно потом сравнить его с аналогичным топом в ВК. Указанное количество лайков = лайки минус дизлайки.

1. Сергей Шандарин написал о поиске работы дизайнером за рубежом (после 24 февраля). 52 лайка

2. Иван Звяхин поделился чеклистом для самостоятельной проверки интерфейса. 52 лайка

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

4. Маргарита Романова написала о поиске работы продуктовым дизайнером в Европе. 43 лайка

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

6. Читатели рассказали в комментариях о своих телеграм-каналах. 39 лайков

7. Эдвард Скотт написал о хлебных крошках в мобильных версиях интернет-магазинов. 39 лайков

8. Игорь Штанг написал о современной русской пунктуации на примере упаковки умной розетки Яндекса. 38 лайков

9. В Purrweb написали об адаптации интерфейса для стран Ближнего Востока. 38 лайков

10. Илья Бирман написал о кнопке «Подробнее» в карточках. 38 лайков

11. Ксения Беляева написала о дизайн-ревью, когда дизайнер проверяет, как разработчик воплотил его дизайн. 37 лайков

12. Энтони Ценг написал, на что можно заменить большое меню, состоящее из нескольких колонок. 37 лайков

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

14. Чем отличаются униширинные и моноширинные шрифты. 35 лайков

15. Игорь Штанг написал, что делать с текстом в скобках (например). 35 лайков

16. Станислав Хрусталёв написал о лучших практиках работы с корзиной. 34 лайка

17. Андрей Насонов написал о модальных окнах. 34 лайка

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

19. Эдвард Скотт написал о частых ошибках в дизайне интернет-магазинов одежды. 33 лайка

20. Барт Гиссенс написал, почему курсор в операционных системах наклонён. 33 лайка

А вот 20 самых популярных постов, если считать по лайкам в ВК.

Только 5 статей попали и в вкшный и в телеграмный топ:
— Чеклист для самостоятельной проверки интерфейса Ивана Звяхина;
— Heads and Hands о приоритизации фич по модели Кано;
— Ксения Беляева о дизайн-ревью;
— «Собака Павлова» о специфике проектирования медицинских интерфейсов;
— Чеклист проектирования сложных продуктов Натальи Стурза.

2 автора оказались в обоих топах, но с разными материалами:
— Илья Бирман а) о дизайн-системах, б) кнопке «Подробнее» в карточках;
— Энтони Ценг а) об адаптивных таблицах, б) замене большого меню.

А Игорь Штанг оказался единственным автором с двумя материалами в телеграмном топе:
— О современной русской пунктуации;
— Что делать с текстом в скобках.

Интересный феномен, когда кто-то прилагает дополнительные усилия, чтобы сделать хуже.

Например, в телевизоре миллион способов «обработать» (ухудшить) изображение, хотя все, что от него требуется — просто показать цифровой сигнал ровно в том виде, в котором он поступает на порт. Все, лучше уже не сделаешь.

Или Твиттер, они пыжились, придумывали алгоритм «умного» кропа изображения. А в итоге лучший кроп — это не кропать картинку вообще. Если я прикладываю изображение, наверное, я хочу, чтобы его увидели целиком, а не какую-то часть? Если бы мне нужен был кроп, я бы кропнул.

«Алгоритмические» ленты в ту же степь. Лучшая алгоритмическая лента — обратная сортировка по дате. Если бы мне был не интересен какой-то контент, я бы от него отписался, не? А если я подписался, значит я хочу его видеть, епт.

Иногда, чтобы сделать хорошо, достаточно просто ничего не делать.

Андрей Маркелов написал о линиях в дизайне графиков.

— Важно правильно выбрать толщину линии. Толщина в 1,3 пикселя даёт лёгкую воздушность. Стоит добавить скругление изломов;
— Если отображаются 2 графика, для облегчения восприятия к первому добавляют градиент: 15% прозрачность в верхней точке и 0% у горизонтальной оси;
— Линиям добавляют обводку, равную толщине линии, чтобы избежать шума на стыках;
— Сканер позволяет узнать значение параметра в любой точке графика. Это вертикальная линия, накладывающаяся поверх графика и следующая за курсором. В месте пересечения с графиком ставится точка и отображается значение параметра. Под сканером отображается дата (или то, что находится на горизонтальной оси). Сканер хорошо работает для нескольких графиков;
— В финансовых системах используются индикаторы — миниграфики под основным графиком. Например, столбчатая диаграмма, показывающая спред или объём торгов, или график RSI;
— Японские свечи — особая столбчатая диаграмма. Прямоугольник показывает изменение цены (её значение при открытии и закрытии торгового дня), а линия показывает минимальное и максимальное значение, которого достигала цена в течение дня.

#data_visualization

Александра Савельева написала об обновлении устаревших таблиц в большом продукте.

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

#table #process

Олег Королев написал о количественных исследованиях с помощью опросов.

— Их можно разделить на разовые (статистическая проверка гипотез) и регулярные (отслеживание динамики оценки);
— Регулярные: NPS, CSAT, CSI (помогает понять, насколько клиентам важны характеристики используемого продукта), CES (насколько сложно было взаимодействовать с компанией при решении своей задачи);
— Опросы наиболее эффективны на этапе исследования, тестирования и сбора обратной связи после разработки;
— С ними нельзя выявить глубинные мотивы и проверить сложные гипотезы и сценарии. Опросы не будут 100% истиной, так как люди лгут, забывают о своём опыте и часто только предполагают, как могли бы поступить;
— Чтобы провести разовый опрос, надо обозначить проблему и определить цели. На этапе исследования: проверить гипотезы о целевой аудитории, узнать её характеристики (в том числе, какими конкурирующими продуктами пользуются), отношение к услуге;
— Для расчёта размера выборки есть калькуляторы. По опыту, почти никогда не нужно больше 400 ответов на сегмент;
— От целевой аудитории зависит канал общения, а от него — формат вопросов. В почте допустимы длинные заходы, 5–7 вопросов (в том числе открытые), пояснения в скобках. В чате лучше использовать шкалы и вопросы с вариантами ответов;
— Закрытые вопросы лучше задавать в начале опроса. Они помогают быстро сегментировать респондентов. Но не спрашивайте, условно, про семейное положение, если эта информация не повлияет на продукт;
— Вопросы могут отличаться для разных категорий клиентов. Пользователей, которые зарегистрировались, но не используют продукт, можно спросить о целях, актуальности продукта для них и почему они его не используют;
— И для разных ситуаций. При раннем оттоке можно спросить о самой большой проблеме при взаимодействии, что компания может сделать, чтобы исправить ситуацию;
— При анализе ответов можно посмотреть сочетание ответов на несколько вопросов, чтобы понять зависимость одних ответов от других;
— Если вы можете узнать что-то о клиентах из аналитики или CRM, не спрашивайте об этом в опросе.

#research #survey

Маргарита Романова показала, как без больших трудозатрат повысить интерактивность прототипов в Фигме.

— Выделение строки таблицы, отображение раскрывающегося списка действий со строкой, изменение статуса строки — с помощью интерактивных компонентов;
— Для раскрывающегося списка настройка Absolute position позволяет игнорировать Auto layout компонента, в котором он находится;
— Для Auto layout таблицы настройте Canvas stacking: First on top. Так верхние строки расположатся в слоях выше, и нижние строки не будут перекрывать раскрывающиеся списки действий;
— Отображение в таблице большого количества тултипов;
— Component properties позволяет работать с текстом, не переходя на конкретный слой с текстом. Функция Expose properties from Nested instances позволяет редактировать текст тултипа прямо в свойствах инстанса родительского компонента;
— Чтобы редактировать текст тултипов, которые отображаются с помощью интерактивного компонента, для состояния компонента без тултипа надо добавить тултип с нулевой прозрачностью.

#figma #prototype #table

Кирилл Улитин написал о цвете в интерфейсе: о контрасте и конфликте разных информационных слоёв цвета.

— Цветовые пространства RGB и производные от него HSB и HSL не адаптированы для человеческого восприятия. Изменение оттенка даёт цвета, неравномерные по контрасту. Цветовые модели LCH и HSLuv призваны это исправить;
— Контраст зависит от способа воспроизведения: на электронно-лучевых экранах контрастнее жёлтый на чёрном, на светодиодных — чёрный на белом;
— Алгоритм расчёта контраста в WCAG 2.1 иногда ошибается. В новую версию стандарта доступности вошёл алгоритм APCA. Можно использовать инструменты Huetone и Accessible Palette;
— Алгоритмы проверяют цвета в идеальных условиях и не учитывают пользовательский контекст: тип матрицы экрана, яркость, режимы вроде Night Shift или корректирующие очки;
— Цвет может обеспечивать узнаваемость бренда;
— Apple в руководстве по интерфейсному дизайну говорит о том, что конфликт разных информационных слоёв цвета нежелателен: красное сообщение о критической проблеме будет менее эффективным, если красный используется в приложении для некритичных ситуаций;
— При этом в новой версии macOS Big Sur разработчикам дана возможность настраивать основной цвет интерфейса приложения;
— Когда цвет бренда (например, красный) совпадает со статусными цветами в интерфейсе (сообщения об ошибках) надо вводить дополнительный цвет для элементов интерфейса, отличающийся от брендового (например, Microsoft Office 365), или добиваться цветовой разницы от 30 до 40 единиц (например, МойОфис).

#color #accessibility