Кинерет Ифра написала о пустых состояниях.

— 1. Пользователь не создал то, что должно отображаться на экране. Например, не добавил товаров в избранное;
— В заголовке напишите, чего он ещё не сделал: «Вы ещё не добавили ничего в избранное». В тексте добавьте мотивации: «Сохраните товар, который привлёк ваше внимание, чтобы вернуться к нему потом». Кнопка может вести на первый шаг в нужном направлении, например: «Посмотреть бестселлеры»;
— 2. Пользователь не сделал чего-то, что приводит к появлению здесь данных. Пустое состояние не сильно отличается от первого. В тексте стоит объяснить, как наполняется этот экран: «После того как пригласите пользователей, вы сможете отслеживать здесь их активность»;
— 3. Пользователь всё сделал, но для появления данных нужно время. Предложите вернуться позже и объясните, как работает система: «Нужны 24 часа после старта рекламной кампании, чтобы собрать достоверные данные»;
— 4. Пользователь всё удалил, и это часть рабочего процесса, например, пустой инбокс или список задач. Похоже на первый тип, но в этом случае стандартное пустое состояние будет выглядеть неуместно. Можно похвалить пользователя за продуктивность;
— 5. Содержимое экрана недоступно из-за выбранного тарифа. Кроме отображения кнопки перехода на нужный тариф (или начала бесплатного периода) стоит написать о ценности, как именно функция может быть полезна;
— 6. Ничего не найдено без фильтров. Возьмите ответственность на себя: «Мы не нашли то, чего вы искали». Предложите исправить или изменить введённый текст, покажите результаты поиска по похожим запросам, предложите расширенный поиск, предложите сообщить, когда появится то, чего пользователь искал;
— 7. Ничего не найдено с фильтрами. Предложите убрать некоторые фильтры, покажите то, что почти подходит, предложите сообщить, когда появится.

In English. #empty_state #writing

В RetailRocket написали об а/б-тестировании.

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

#ab_testing

Аврора Харли написала о принципе общей области.

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

In English. #layout

Вот это, блин, реально полезный UX!

Дмитрий Якушин написал о дизайн-токенах.

— Набор дизайн-токенов позволяет сделать визуально согласованный и при этом гибкий дизайн (легко поменять один оттенок на другой);
— Дизайн-токен — псевдоним определённого значения той или иной переменной: цвета, шрифта, размера элемента, тени, отступа, скругления;
— Цвет #677178 можно назвать color-grey-600 и использовать в макетах так, а можно создать токены color-text-secondary и color-component-badge-bg-neutral, которые будут ссылаться на color-grey-600;
— В тёмной теме color-text-secondary может ссылаться на другой цвет, что упрощает создание макетов для других тем;
— Говорящие названия упрощают их использование, особенно новыми участниками команды;
— Есть черновая версия стандарта дизайн-токенов от W3C;
— В составном токене (миксине) может быть больше одной переменной. Например, в токене типографики: название шрифта, кегль, высота строки, межбуквенный интервал;
— color-green-600 — глобальная переменная (примитив, палитра, референсный токен) с абстрактным названием без контекста. Число обычно отражает количество света в цвете;
— color-text-success — дизайн-токен, который ссылается на переменную color-green-600 и имеет контекст использования: для текстовых сообщений об успехе;
— Есть компонентные токены, которые относятся к конкретным компонентам, например, color-component-badge-bg-info для фона информационного бейджика;
— Распространены стили названия: color_text_primary для веба, сolorToken.textPrimary для мобильных платформ;
— Полная структура названия: префикс, группа (color), тип (text, component), элемент (badge), модификатор (background), вариант (info), состояние (hover);
— Некоторых частей может не быть: если токен не относится к компоненту, если к проекту не подключено нескольких библиотек с токенами (прификс их идентифицирует);
— В именах токенов размеров лучше не использовать цифры, чтобы не было путаницы с фактическими значениями: xx-small, x-small, small, medium, large, x-large, xx-large;
— Категории: colors, font family, font size, line height, border color, grid, border radius, spacing, box shadow, duration/transition, shadows, z-index, size.

#figma #design_system

Илья Кретов написал об интерфейсном тексте и типографике. Некоторые советы:

— Сокращайте использование кавычек. Например, названия разделов можно писать с заглавной буквы или выделять полужирным начертанием: «Ищите треки в разделе Коллекция»;
— Разделяйте узким пробелом разряды числа, сумму и знак рубля, числа и среднее тире в диапазоне;
— Чтобы написать −25%, используйте знак минуса (а не дефис) и не отделяйте его от числа пробелом;
— Написанный только заглавными буквами текст слишком эмоционален, кричит. Лучше использовать его максимум в кнопках или бейджах;
— Связывайте текст кнопки с заголовком: «Подключить услугу? [Подключить]». Если любите Conversational Design, когда вместо «Подключить» пишут «Да, хочу!», убедитесь, чтобы кнопка была рядом с заголовком, иначе смысл может потеряться;
— Пишите эмоционально нейтрально: «Вы не можете продолжить без регистрации» → «Для продолжения необходимо авторизоваться»;
— Учитывайте адаптивность. Самая важная информация должна вмещаться на самые маленькие экраны;
— Текст на экране должен быть понятен без контекста. Лучше строить его на именительном падеже: «Какого настроения соберём плейлист? [Весёлого] [Грустного]» → «Под какое настроение соберём плейлист? [Весёлое] [Грустное]».

Копия статьи. #writing #typography

Евгения Береснева написала о разделе с часто задаваемыми вопросами (FAQ).

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

#writing #support

Кэлвин Френч-Оуэн написал о категориях пользователей и учёте их потребностей при планировании продукта.

— Продукт должен быть удобным покупателю, быть удобным пользователю не обязательно. Можно ориентироваться на практиков (покупатели и пользователи в одном лице) и руководителей (покупатели и отчасти пользователи);
— Продавать практикам помогает эстетика и хороший UX. Возможность совместного использования ускоряет распространение знания о продукте между специалистами;
— Руководителям важнее всего отчётность: насколько эффективно работают подчинённые, есть ли проблемы;
— Также им важна стандартизация. Когда все работают одинаково, повышается безопасность, можно экономить на масштабах. Нужна настройка ролей и доступов с учётом корпоративной иерархии, сложная модель данных, позволяющая настроить продукт под требования конкретного покупателя;
— Узнайте, что нужно тому, кто принимает решение о покупке. Продаёте начальникам отделов? Насколько им важен отполированный интерфейс для обычных специалистов?
— Если продукт покупают руководители, вкладывайтесь в отчётность, интеграции с почтой и Слаком, ежемесячные сводки;
— Если практики — в инвайты, вход через волшебные ссылки и G Suite, самообслуживание, автоматический биллинг, объединение пользователей. Устраните все барьеры при регистрации.

In English. #product

Станислав Хрусталёв написал о входе в приложение по номеру телефона.

— Объедините вход и регистрацию. При вводе номера проверяйте, есть ли такой пользователь, и ведите на нужный сценарий;
— Вынесите ввод номера на отдельный экран. Не смешивайте с другими элементами неавторизованной зоны, чтобы не размывать фокус;
— Заголовок формы должен быть достаточно большим и содержать призыв к действию;
— Добавьте пояснение, что произойдёт дальше («Отправим сообщение с кодом»), чтобы управлять ожиданиями пользователя. Можно подчеркнуть ответственное отношение к приватности («Обещаем хранить его в тайне») или скорость входа («Займёт всего минуту»);
— Не дублируйте заголовок в плейсхолдере поля. Покажите в нём формат номера телефона, чтобы смысл поля был понятен с первого взгляда. Цифры лучше показать нулями или девятками;
— Активируйте поле автоматически при открытии экрана, отображайте цифровую раскладку клавиатуры (без возможности её поменять);
— Если принимаете только российские номера, +7 можно отобазить по умолчанию;
— Если пользователь вышел, но не удалил приложение, его номер можно сохранить и предложить при повторном входе. Если удалил приложение, номер можно запомнить по Device ID;
— Поле ввода можно промаркировать как phone number, чтобы пользователь мог подставить сохранённый на устройстве номер;
— Чтобы снизить количество ошибок, форматируйте введённый номер и ограничивайте количество символов (в зависимости от кода страны);
— При удалении номера по символам, автоматически удаляйте символы форматирования;
— Переходить к подтверждению лучше по нажатию на кнопку. Разместите её в нижней части экрана, не перекрывайте клавиатурой. Иногда кнопку «Получить код» размещают в кастомизированном меню над клавиатурой;
— Код по смс удобнее звонка, так как с автоподстановкой его можно ввести одним нажатием. Пуш ещё удобнее — приложение само может его обработать;
— На экране подтверждения стоит написать, что смс отправлено (и на какой номер). Но это сообщение должно быть визуально вторичным;
— Отправитель смс — название бренда. Код — в начале сообщения, чтобы не надо было его открывать. В текст добавьте пояснение, что это за код и что его не надо никому сообщать;
— Проверять код можно автоматически при вводе нужного количества символов.

#log_in #sign_up

Кейт Моран и Тейлор Дайкс написали о сравнительных таблицах.

— Когда альтернатив множество, выбирая товар, люди ориентируются на одну основную характеристику. С этим помогают фильтры. Когда товаров 5–7, люди учитывают достоинства каждого конкретного варианта. Здесь хорошо работают сравнительные таблицы;
— Если вы предлагаете не более 5 альтернатив (модели Apple Watch, варианты подписки), подойдёт статическая таблица. В ней можно контролировать отображение информации, редактировать формулировки;
— В динамической таблице пользователь сам выбирает, какие товары сравнить;
— Если в ней может оказаться больше 5 вариантов, предусмотрите способы сократить количество, например, добавив фильтры;
— Главная проблема динамической таблицы — неполнота данных о параметрах товаров;
— Стандартная компоновка: столбцы для товаров, строки для параметров;
— Фиксируйте заголовки столбцов при прокрутке;
— Связывайте абстрактные значения параметров с чем-то понятным: аккумулятор на 3350 мАч — хватит 1,2 раза зарядить iPhone 6;
— Объясняйте термины и непонятные параметры. Можно добавить всплывающие подсказки и ссылки на статьи;
— Если параметров много, дайте пользователю возможность управлять отображением: прятать отдельные группы параметров в аккордеон, отображать только отличающиеся параметры. В статические таблицы можно добавить краткий и полный вариант отображения;
— Сравнительные таблицы неэффективны, если варианты не взаимоисключающие (вместо сравнения двух платьев лучше оба добавить в корзину), простые (мало параметров), дешёвые или заменяемые (нет смысла тратить время на изучение таблицы), уникальные и трудно сравниваемые (разные параметры).

In English. #ecommerce #table

Роб МакКоган написал о влиянии типографики на восприятие и поведение.

— Более контрастный цвет повышает разборчивость текста и делает его более убедительным;
— Более сложный для восприятия шрифт (Brush Script против Arial) усложняет чтение и стимулирует критичное отношение к написанному, что помогает заметить подвох. Если таким набрано задание, оценка времени его выполнения будет больше (в эксперименте — почти в 2 раза);
— Есть ассоциативная связь между словами и формой. Слово «Кики» — угловатая форма, «Буба» — обтекаемая. Используя подходящую или неподходящую форму, можно создать гармонию или конфликт;
— Когда шрифт соответствует смыслу, такой текст читают быстрее. Например, Truck и шрифт Impact, Flower и шрифт Snell Roundhand;
— Если типографика оптимизирована, человек меньше устаёт и лучше потом решает задачи на сообразительность;
— При рецензировании научных материалов положительные оценки чаще получали статьи с иллюстрациями, подготовленными графическими дизайнерами (а не учёными).

In English. #typography

Никита Самутин написал, как тимлиду справиться с потоком дел и повысить свою ценность в компании.

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

#management

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

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

#style

Бенджамин Брэндалл написал об отмене подписки в разных сервисах и выделил хорошие практики.

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

In English. #offboarding

Позабавило сегодня. В компании «Ю-эксперт», которая занимается проектированием интерфейсов, написали об ошибках в форме запроса консультации.

Среди прочих выделили:

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

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

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

4. Непонятное сообщение об отправке заявки. Например, английский текст, когда остальной интерфейс на русском, или что-то на технарском вроде «Ответ записан».

Плюс ещё 3 ошибки.

Заканчивается статья ссылкой на форму запроса бесплатного аудита юзабилити в компании «Ю-эксперт». И сколько же ошибок в этой форме? Ноль? А вот и нет: все перечисленные выше, то есть 4 из 7 обозначенных в статье.

#form

Блейр Фикс объяснил, почему эффекта Даннинга — Крюгера не существует.

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

In English. #psychology

Паша Злобин написал о сервисах для а/б-тестирования.

— Google Optimize закрыт с сентября 2023 года;
— Сервисы из России: Varioqub (проект Яндекса, интегрируется с Метрикой), UX Rocket, Sigma;
— У первых двух есть бесплатные тарифы;
— Паша показал процесс настройки а/б-теста в первых двух (попробовать Сигму без подписания договора нельзя);
— В комментариях подсказали, что пользователи из России могут на собственном сервере поднять опенсорсный GrowthBook (есть бесплатный тариф).

#tool #ab_testing

Дарья Хуторянская написала о UX-аудите.

— Это оценка, насколько продукт или отдельные фичи, удовлетворяют потребности пользователей и решают задачи бизнеса;
— Аудит не нужен, если продукт активно растёт, привлекает пользователей и инвестиции (лучше заняться новыми фичами и сбором обратной связи, чтобы укрепиться на рынке) или если налажено отслеживание метрик, которые показывают, что продукт в порядке;
— Если продукт для дизайнера новый, он смотрит на него незамыленным взглядом (это плюс), но должен быстро в нём разобраться (это минус), чтобы не скатиться в поверхностную оценку UI;
— 1-й шаг. Определите задачи бизнеса и потребности пользователей. С этим поможет серия экспертных интервью с владельцем продукта. Если есть время, поговорите с пользователями, контактирующими с ними специалистами компании (персональные менеджеры, продажи, поддержка), изучите отзывы и обращения в поддержку;
— Задачи бизнеса должны попадать в категории: 1) рост выручки и прибыли компании, 2) удержание и возвращение клиентов, 3) снижение издержек;
— 2-й шаг. Изучите данные о поведении пользователей: конверсию в завершение сценария (пути тех, кто не доходит, могут указать на проблемы), время решения задачи (можно сравнить, когда сценарии будут доработаны), поисковые запросы (что люди ищут и не могут найти), используемые устройства, DAU, MAU (востребованность фичи от месяца к месяцу);
— Если таких данных не собирают, заведите задачу на подключение аналитики. Что-то можно выгрузить из баз данных и логов активности;
— 3-й шаг. Если фич много, выберите те, что приносят больше всего пользы бизнесу, из них выберите 3−5 самых востребованных у пользователей;
— Каждую оцените по эвристикам (есть разные фреймворки). Так вы не упустите и UX, и UI-составляющие фичи. Если эвристика соблюдается, ставьте 1, если нет, ставьте 0 и добавляйте комментарий, почему так;
— 4-й шаг. Презентуйте результаты команде (в сложном продукте может понадобиться серия часовых встреч), обсудите, зафиксируйте конкретные задачи, которые пойдут в работу, заведите эпики для будущих доработок.

#audit

Илья Бирман написал о вертикальном масштабе графика.

— Тафти рекомендует подбирать его так, чтобы в среднем угол наклона графика был примерно 45°;
— График нужен для сравнения данных, выявления тенденций и закономерностей;
— Даже сжимая график по вертикали, мы не снижаем его разрешение, а повышаем. Если средний угол наклона — 45°, лучше видны пологие участки и резкие перепады.

#data_visualization