UX Notes

2022-12-28 23:22:32 Андрей Маркелов написал о шкалах в дизайне графиков.

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

Смотрите также, как делать подписи для таймсерий. #data_visualization Открыть/Комментировать

2022-12-26 09:15:28 Станислав Хрусталёв продолжает собирать открытую базу знаний по UX/UI e-commerce.

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

Все материалы полностью бесплатны, без пэйволлов и скрытых продаж. Совет: сами статьи объемные, лучше открывать с ПК.

Канал Станислава. Открыть/Комментировать

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

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

#process #writing Открыть/Комментировать

2022-12-24 21:00:04 Евгений Паршин написал о Riskiest Assumption Test (RAT).

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

2022-12-22 14:01:00 Школа визуальной культуры BBE (ex. Bang Bang Education) открывает новый курс по методологии Journey Mapping с Никитой Ефимовым — директором по продукту в Звук Бизнес, автором Feature Canvas.

Никита более 18 лет участвует в создании ПО в разных ролях: разработчик, менеджер продуктов, проектировщик пользовательских интерфейсов, в том числе, мобильных приложений с дополненной реальностью.

Journey Mapping — инструмент исследования пользователей, который помогает развивать продукт и улучшать клиентский опыт.

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

Присоединяйтесь к курсу с новогодней скидкой 35% и внедряйте технику journey mapping в свои рабочие процессы и команды.

#промо Открыть/Комментировать

2022-12-22 12:59:55 В uxtrends написали об измерении эффективности дизайна.

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

#metrics Открыть/Комментировать

2022-12-21 19:43:38 В tubik написали о единообразии в интерфейсе.

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

#consistency #principles Открыть/Комментировать

2022-12-19 14:01:01 В разных категориях приложений есть паттерны, которые принято использовать в UX/UI-дизайне. Например, в корзине приложения доставки есть одна бутылка молока, а нужно две. Тогда вы нажимаете на кнопку «+» рядом с количеством товара, и цифра меняется. Такая функция везде работает одинаково.

С одной стороны, это привычно и понятно, а с другой — интерфейсы приложений становятся всё более стандартными. Дизайнеры приходят к вопросу: как сделать дизайн не как у всех, но чтобы пользователю было удобно?

Ребята из команды приложения «Самокат» придумали способ. На вебинаре Яндекс Практикума лид-дизайнер CX Дмитрий Журавлев рассказал, как переделывать паттерны, не нарушая пользовательский путь. Посмотреть запись можно тут.

А если вам интересно научиться самим создавать полноценные интерфейсы — регистрируйтесь на вводную часть курса по UX/UI-дизайну. Там можно прожить один день день из жизни дизайнера интерфейсов: узнать, как он рассуждает и какие задачи решает. А ещё — спроектировать несколько экранов приложения.

#промо Открыть/Комментировать

2022-12-18 15:42:33 Андрей Кононов написал о проектировании сложной функциональности на примере заказа товаров в сетевом магазине.

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

2022-12-16 20:53:36 Даниил Видишев написал, как работать с мелкими багами, появляющимися при реализации дизайна.

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

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