25223
Чат читателей: @uxnoteschat В соцсетях: vk.com/ux_notes и fb.com/uxnotes Вакансии: @uxwork Автор: @zGrav Est. 2016. Реклама на канале: https://uxnotes.ru/ads
Станислав Хрусталёв продолжает собирать открытую базу знаний по UX/UI e-commerce.
В базе — советы по проектированию строки поиска, каталога, страниц товаров, корзины, чекаута и многого другого. Всего — 25 больших чек-листов, в которых собрано более 2600 гайдлайнов с примерами и анти-примерами. База продолжает пополняться.
Все материалы полностью бесплатны, без пэйволлов и скрытых продаж. Совет: сами статьи объемные, лучше открывать с ПК.
Канал Станислава.
Евгений Паршин написал о Riskiest Assumption Test (RAT).
— Это быстрая проверка идей, провал которых может похоронить весь продукт целиком;
— Для проверки идеи не обязательно нужен MVP. Проверить спрос можно с помощью лендинга с рассказом о продукте и формой заявки;
— Надо 1) выделить рискованные гипотезы — предположения, из-за которых с высокой вероятностью продукт не выживет, 2) оценить степень их значимости, 3) протестировать самые опасные;
— С помощью RAT можно проверить спрос, ценность продукта для пользователя, юнит-экономику и правильность выбранного сегмента;
— Найти рискованные гипотезы можно через исследования, брейнштормы, самостоятельные рассуждения. Например, можно посмотреть на Lean Canvas и спросить себя: что может пойти не так, что мы ошибочно приняли за истину?
— Каждую гипотезу можно оценить по способности похоронить продукт, количеству ресурсов, необходимых для проверки гипотезы, сложности тестирования, времени проверки.
В uxtrends написали об измерении эффективности дизайна.
— Бенчмаркинг — оценка продукта, позволяющая оценить степень достижения поставленных целей (оценка эффективности продукта), или сравнение с конкурентами по определённым показателям (сравнительный конкурентный анализ);
— Конкурентный анализ подходит для начальной фазы проектирования, чтобы определить требования;
— Оценивать эффективность можно перед началом и после окончания цикла проектирования, чтобы сравнить новую версию дизайна с предыдущей. В этом поможет анализ метрик, количественное пользовательское тестирование, опрос;
— Сначала определите объект исследования. В зависимости от целей и KPI им может быть продукт, аудитория, определённая функциональность (или свойство) продукта. Выберите измеряемые показатели: вовлечённость пользователей, удовлетворённость, принятие (использование функции), удержание, эффективность выполнения задач;
— Выберите метод сбора данных, учитывая необходимое для него время, стоимость, наличие инструментов и навыков. Лучше не проводить исследование, чем получить неверный результат;
— Опросы помогают измерить поведенческие параметры: простоту выполнения задач, коэффициенты удовлетворённости и лояльности;
— Соберите первый массив данных. Он пригодится для сравнения с показателями конкурентов и отраслевыми стандартами;
— После переработки продукта соберите следующий массив данных. Пользователи могут негативно реагировать на изменения, дайте им время привыкнуть, прежде чем проведёте повторный опрос;
— Новый массив данных можно сравнить с предыдущим и сделать выводы о принятых дизайн-решениях. Так результаты работы над продуктом можно привязать к показателям компании и посчитать их окупаемость;
— В идеале бенчмаркинг становится частью дизайн-процесса. Поэтому важна стоимость выбранных методов сбора данных, так как заниматься ими придётся постоянно.
#metrics
В разных категориях приложений есть паттерны, которые принято использовать в UX/UI-дизайне. Например, в корзине приложения доставки есть одна бутылка молока, а нужно две. Тогда вы нажимаете на кнопку «+» рядом с количеством товара, и цифра меняется. Такая функция везде работает одинаково.
С одной стороны, это привычно и понятно, а с другой — интерфейсы приложений становятся всё более стандартными. Дизайнеры приходят к вопросу: как сделать дизайн не как у всех, но чтобы пользователю было удобно?
Ребята из команды приложения «Самокат» придумали способ. На вебинаре Яндекс Практикума лид-дизайнер CX Дмитрий Журавлев рассказал, как переделывать паттерны, не нарушая пользовательский путь. Посмотреть запись можно тут.
А если вам интересно научиться самим создавать полноценные интерфейсы — регистрируйтесь на вводную часть курса по UX/UI-дизайну. Там можно прожить один день день из жизни дизайнера интерфейсов: узнать, как он рассуждает и какие задачи решает. А ещё — спроектировать несколько экранов приложения.
#промо
Даниил Видишев написал, как работать с мелкими багами, появляющимися при реализации дизайна.
— Они бывают визуальными (не те цвета, отступы, анимация) и функциональными (у кнопки нет тултипа). Они не мешают пользователям достигать целей, поэтому получают низкий приоритет;
— В итоге их становится слишком много, чтобы можно было легко исправить, продукт начинает отличаться от макетов, растёт поток обратной связи от пользователей;
— Оформляйте баги правильно: пишите конкретно, что и где надо исправить (карточка пользователя, изменить стиль заголовка с 24 на 28 px), группируйте их с помощью тегов или папок, прикладывайте скриншот проблемы и ссылку на макет;
— Объясняйте команде ценность дизайна;
— Документируйте дизайн: подробно описывайте работу элементов (здесь стоит упомянуть мою статью о функциональной спецификации), прикладывайте референсы анимаций, показывайте в макетах пошаговые сценарии;
— Проводите ревью вёрстки, когда она уже почти готова (вряд ли получится выделить для этого отдельный статус задачи в Джире). Фронтендер может показать наработки на коротком созвоне;
— Если перечисленные выше процессы работают, можно внедрить автотесты на pixel perfect UI.
Смотрите также статьи Алисии Суски и Сэма Айронса о дизайн-долге и канал Даниила. #process
Андрей Маркелов написал о дизайне сложных таблиц.
— Шрифты с моноширинными цифрами можно использовать, если в таблице числа не смешаны с буквами (рядом с числом может стоять единица измерения);
— Но лучше использовать полностью моноширинные шрифты, например, очень компактный Ubuntu Mono;
— Числа выравнивайте по правому краю, но текстовые заголовки столбцов с числами — по левому;
— Чтобы повысить читаемость, можно выделить визуальные границы колонок, разорвав разделительную линию;
— Если колонки стоят очень плотно, для отделения разрядов вместо обычного пробела лучше использовать тонкий («thin space», U+2009);
— Единицы измерения обычно пишут в названиях колонок через запятую, но тогда колонка становится шире. Можно располагать их под названием на отдельной строке и выделять цветом;
— Иногда группы колонок полезно сворачивать: для экономии места, для показа результирующей колонки;
— Базовую числовую таблицу можно обогатить инфографикой, цветами и диаграммами. Например, в дополнение к начальной и конечной цене можно показать график её колебания. Вклад каждой облигации в стоимость портфеля можно подсветить градацией зеленого и красного;
— Стоит ввести двойные строки. Например, полезно видеть не только стоимость облигации, но и процент, который она занимает в портфеле.
#table
Навык визуализации данных — плюс к вашему резюме
Строить графики в презентациях, конечно, круто. Но для больших данных и задач бизнеса нужны современные BI-инструменты: DataLens, Tableau, Datawrapper и другие. Они упрощают и ускоряют работу, а в перспективе — помогают компании экономить ресурсы.
Освойте эти инструменты в Практикуме и добавьте навык визуализации в своё резюме уже через 3 месяца.
Курс «Визуализация данных и введение в BI-инструменты» подходит:
- финансовым и продуктовым аналитикам, а также аналитикам данных;
- маркетологам;
- менеджерам и руководителям команд;
- продуктовым и графическим дизайнерам.
Начать обучение можно бесплатно. Вы узнаете, зачем и кому нужна визуализация данных, как работать с BI-инструментами и как будет устроена ваша учёба в Практикуме.
После регистрации вы получите доступ к теории и практике в формате симулятора и изучите темы:
- Введение в науку о данных — Data literacy.
- Визуализация данных в бизнесе и работа с заказчиками.
- Основы визуализации и выбор графиков.
- Инструменты для визуализации и сценарии их применения.
- Сторителлинг и презентация в работе с данными.
- Интерактивные дашборды и Tableau.
Попробуйте курс в любой удобный момент.
#промо
Анна Кейли написала о всплывающих окнах (попапах).
— Попап появляется поверх содержимого страницы;
— Может быть немодальным и модальным. Во втором случае содержимое страницы становится недоступным для взаимодействия, пока попап не будет закрыт;
— Лайтбокс — эффект, когда всё кроме попапа затемняется;
— Не отображайте попап сразу после открытия сайта. Часто содержимое попапа можно разместить вне попапа. Исключение: согласие использовать куки и подтверждение возраста;
— Не отображайте его и сразу после входа в личный кабинет. Обычно люди заходят в них с какой-то целью, и попап будет помехой. Дайте немного времени выполнить текущую задачу;
— Если хотите рассказать о функциях, которые помогут с текущей задачей, используйте всплывающие подсказки и небольшое немодальное окно;
— В таком же окне лучше разместить форму сбора имейлов, причём, стоит продумать момент её появления. Например, после прочтения статьи в блоге или при просмотре товарной категории, для которой вы можете предложить промокод;
— Не отображайте попап, когда пользователь выполняет критически важную задачу;
— Если у вас на сайте есть несколько попапов, проверьте, что они не появляются одновременно или один за другим;
— Старайтесь не использовать попапы для сообщений об ошибках или предупреждений о том, как их избежать. Люди могут закрывать их, не читая;
— Не отображайте попап, если пользователь только открыл желаемый контент (например, статью). Попап в этом случае можно заменить ненавязчивым баннером в верхней части страницы;
— Так же можно рассказать о доступности мобильного приложения.
#modal #popup
Павел Шерер опубликовал 3-ю статью цикла о функциональной архитектуре.
— Если не выделять общие функции продукта, есть риск получить копипаст одной и той же функциональности (в лучшем случае) или несколько разных реализаций интерфейса и логики. Это усложняет поддержку и дальнейшее развитие продукта;
— Общие функции не всегда лежат на поверхности, часто их выявление становится отдельной задачей;
— Как это делать: в небольших проектах можно просто спрашивать себя, не используется ли эта конкретная функция где-то ещё;
— Можно составить матрицу функциональных свойств объектов — список всех сущностей и возможных действий с ними, основанный на информационной архитектуре;
— Примеры общих функций: показ системных сообщений, отправка запроса по API, обработка ответа по API, валидация полей форм, показ сообщений форм, отправка данных формы и обработка ответа (может использовать функции API), проверка наличия сети, обновление экрана, отправка данных для аналитики;
— Функции могут зависеть друг от друга. При иерархической зависимости уровень диктует порядок проектирования и реализации. Например, подтверждение номера телефона нельзя реализовать без а) обработки запроса на сервере и б) отправки смс;
— Если отправка смс используется только здесь (не является общей), разработать её можно вместе с функцией подтверждения номера телефона;
— Функция обработки запроса на сервере — общая. При этом она зависит от функций «валидация данных» и «очистка параметров», значит, спроектировать и реализовать надо сначала их;
— Есть линейная (параллельная) взаимосвязь. Например: регистрация через имейл и регистрация через соцсети;
— Также функции бывают клиентские и серверные — в зависимости от того, где они выполняются.
Канал Павла. #functional_architecture
Александра Савельева начала цикл статей о проектировании b2b-продуктов. Первая посвящена особенностям их пользователей.
— Бизнес-клиенты (специалисты и предприниматели) обычно воспринимают информацию о продукта для бизнеса критически, не реагируют на пустые рекламные приёмы. Если обещаете выгоду, указывайте конкретные параметры и показывайте примеры;
— Процесс принятия решения может занимать месяцы, есть процесс согласования. Нужна узкоспециализированная информация, которая поможет защитить выбор этого продукта перед коллегами. Призывы купить здесь и сейчас не работают;
— Пользователей можно разделить на типы: 1) Владелец небольшого бизнеса; 2) Офис-менеджер; 3) Специалист; 4) Начальник; 5) Эксперт по закупкам;
— У них есть свои особенности. Например, офис-менеджер может плохо разбираться в теме, поэтому будет искать спецификации продукта, чтобы сравнить с изначальным запросом;
— Потребность в информации может зависеть от этапа в цикле покупки: 1) Осознание проблемы; 2) Поиск решений; 3) Обсуждение; 4) Торг и покупка; 5) Поддержка; 6) Модификация; 7) Замена;
— Например, чтобы удержать клиента на этапе модификации, надо анонсировать обновления системы, предлагать дополнительные модули, показывать, что сервис развивается и отвечает требованиям рынка.
Канал Александры.
Майкл Крич сделал обзор фреймворков для эвристической оценки интерфейсов.
— Можно использовать 10 эвристик Якоба Нильсена, но потом столкнуться с проблемами интерфейса, не учтёнными этим фреймворком;
— Эвристическая оценка — анализ предмета (в данном случае интерфейса) экспертами на соответствие установленным принципам. Это субъективное, качественное исследование;
— Из тех фреймворков, что на слуху, есть ещё 10 принципов хорошего дизайна Дитера Рамса. Майкл проанализировал ещё 8 фреймворков;
— Суммарно они рассматривают следующие качества интерфейса: 1) Лёгкость выполнения задач при первом знакомстве; 2) Скорость работы после обучения; 3) Приятность в использовании; 4) Количество совершаемых при работе ошибок, их серьёзность; 5) Полезность, соответствие потребностям пользователя; 6) Насколько легко вернуться к его использованию после длительной паузы;
— Ни один из рассмотренных фреймворков не охватывает все 6 качеств. Только два (Bastien and Scapin, ISO 9241) — рассматривают 5 качеств;
— Из названных: принципы Рамса больше подходят для улучшения удовлетворённости (качество 3); эвристики Нильсена — для повышения лёгкости обучения (качество 1).
#principles
Ксения Горбатенко написала о метрике CSAT.
— Customer Satisfaction Score показывает впечатление клиента от взаимодействия в моменте: от сайта, ассортимента компании и так далее;
— Используется гораздо чаще родственной метрики CES;
— Нет единого стандарта оценочной шкалы. Чаще всего шкала 5-балльная: очень недоволен, недоволен, нейтрален, доволен, очень доволен. Варианты оценки можно заменить на эмодзи;
— Есть несколько вариантов обработки оценок: 1) считать среднюю, 2) вычислять % оценок 4 и 5 от общего количества оценок. Во втором случае 76,5% — среднее значение для западных компаний. Если получилось меньше, надо что-то менять;
— Нет одного стандартного вопроса. Пример вопроса: «Насколько вы довольны сервисом?»;
— Важно помнить, что если человеку нравится конкретный сервис, это не значит, что он в целом лоялен компании;
— Метрику можно считать на каждой стадии взаимодействия клиента с компанией и видеть, где «болит».
#metrics
В Яндекс Практикуме началась Чёрная пятница: скидка 20% от Яндекса при оплате учёбы в рассрочку или в кредит — всем, кто пройдет вводную часть курса до 30 ноября.
В Практикуме всё обучение строится на практике:
• Практикующие IT-специалисты помогают решать более сложные задачи.
• Эксперты делятся содержательной обратной связью.
• Теория изучается в интерактивном тренажёре, где сразу проверяется через тесты или небольшие упражнения.
Такой подход помогает специалистам систематизировать свои знания и решать более сложные задачи.
Участвуйте в акции и меняйте свою жизнь вместе с Практикумом.
https://practicum.yandex.ru/friday/
#промо
Даша Почекуева написала об особенностях дизайна в телемедицине и снижении средней длительности консультаций.
— Частые кейсы: консультация без осмотра, второе мнение (есть сомнения в диагнозе после очного приёма), совет о коронавирусе, нет возможности прийти на очный приём;
— Врач в телемедицине не может поставить диагноз, а может только предположить в формате «На основании представленной информации можно предположить стоматит»;
— Всё конфиденциально. Дизайнеру недоступны материалы консультаций, статистика диагнозов и так далее. Можно узнать количество сообщений и фото, но не их содержание;
— Остаются глубинки, опросы, анализ Яндекс Метрики;
— Сервис должен помогать врачу принимать пациентов быстрее, но это не может быть целью. Цель: сократить время настолько, насколько возможно без потери качества;
— Метрики: средняя длительность консультации, скорость написания заключения (обычно происходит после консультации), удовлетворённость врача (без врачей не будет сервиса);
— Добавили возможность подстраивать соотношение областей с чатом и формой заключения;
— Внедрили в чат шаблоны. Простые: приветствие, прощание, вопрос об удобном формате консультации. Сложные: рекомендации пациентам. Все шаблоны врач может переделать под себя;
— Сбор анамнеза через бота, пока пациент ждёт очереди, не взлетел. Пациенты проходили его редко, не всегда успевали ответить на все вопросы;
— Средняя длительность консультации уменьшилась на 8%: 26,45 → 24,65 минут. Средняя оценка пациентов выросла;
— Добавили автоматические рекомендации пациентам и направления на анализы на основе диагноза. Форма заключения отслеживает рекомендации неэффективных препаратов вроде арбидола;
— Среднее время, в течение которого пациент получает заключение: 353 → 103 минуты. Почти 77% отдают его в течение часа;
— Удовлетворённость врачей можно отслеживать через встречи с медицинским блоком, опросы, развёрнутую обратную связь по работе продукта (минимум раз в квартал);
— По важным фичам можно проводить тесты и глубинки;
— Средняя оценка врачей: 7,8 → 8,8 из 10.
Канал Даши. #health #metrics
Константин Полуянов написал о процессе проектирования интерфейса: как организовать информацию по задаче, чтобы она не вызывала ступор, как поэтапно детализировать макеты и не тонуть среди множества вариантов реализации.
— На старте проекта дизайнер перегружен информацией. Надо раскладывать её по кучкам в разные артефакты;
— Impact Mapping — фиксация целей, проверка измеримости, необходимости и возможности достижения каждой отдельной цели;
— Customer Journey Mapping — детальное описание процессов, проработка точек контакта на разных информационных уровнях;
— Event Storming — инвентаризация пользовательских действий, экранов для вывода информации и взаимодействующих систем через разметку процесса ключевыми событиями;
— User Story Mapping — формализация функциональных требований;
— Журнал проектирования — структурированное хранение и контроль входящей информации;
— Непонимание всего пользовательского пути мешает учесть все детали, приходится возвращаться и переделывать одни и те же макеты. Помогает Breadboards — выписывание названий экранов и доступных на них элементов взаимодействия. Важно связывать экраны с пользовательскими историями;
— Иногда надо пойти глубже и представить, как будут выглядеть макеты из дальней части пути. Fat Marker Sketches — изображение макетов толстым маркером без высокой детализации;
— Чтобы от возможных вариантов интерфейсных решений голова не шла кругом, стоит придерживаться алгоритмов создания макета. Например, подход Epicenter Design — в первую очередь размещать на макете его основную ценность. Или алгоритм Игоря Штанга «Содержание → Структура → Конструкция → Стиль»;
— Чтобы UI был пригоден для реальной эксплуатации, надо стремиться к максимальной полноте и точности отображаемых данных. Данные выгодно привязывать к пользовательским историям (и как следствие — определённым моментам времени);
— Удобно сохранять часто используемые примеры данных: названия регионов, ИНН, ОГРН и прочие;
— Реальные данные могут сильно повлиять на предлагаемый интерфейс.
#process
Алиса Шефер и Саша Липатова написали, как UX-редакторам встроиться в дизайн-процесс.
— Знакомьтесь с командами не только дизайнеров, но и аналитиков, тестировщиков и маркетологов, которые работают над вашим продуктом. Повторять знакомство можно раз в квартал: люди приходят и уходят, меняются зоны ответственности редакторов;
— Задачи на текст надо ставить одновременно с задачами на дизайн, а если задача небольшая, то хотя бы за неделю до дедлайна. Так можно успеть погрузиться в контекст и собрать вводные, а не просто поправить формулировки;
— Чем полнее задача описана, тем лучше. Смотрите в статье шаблоны с вопросами, что писать в задачах на текст а) целого сценария, б) экрана или попапа, в) письма, пуша или смс;
— Создайте таблицу ответственности (например, в виде модифицированной матрицы RACI), чтобы коллеги легко могли понять, к кому из редакторов обратиться с конкретным вопросом или задачей;
— Разработайте и обновляйте гайды, глоссарии и редполитику. Опишите процесс работы над задачами и отличия разных редакторских ролей: основатель проекта, партнёр, ревьюер. Чтобы эти документы оставались актуальными, бронируйте на них 1 час в день;
— Чтобы новые продакты или тимлиды не забывали подключать редакторов к задачам, проводите 15-минутные онбординги с рассказом о процессе, базе знаний и гайдах;
— Соберите всех пишущих (и UX-редакторов, и копирайтеров из отдела маркетинга) в один чат, чтобы всегда можно было обсудить какие-то изменения в тексте и не копить недопонимание.
#process #writing
Школа визуальной культуры BBE (ex. Bang Bang Education) открывает новый курс по методологии Journey Mapping с Никитой Ефимовым — директором по продукту в Звук Бизнес, автором Feature Canvas.
Никита более 18 лет участвует в создании ПО в разных ролях: разработчик, менеджер продуктов, проектировщик пользовательских интерфейсов, в том числе, мобильных приложений с дополненной реальностью.
Journey Mapping — инструмент исследования пользователей, который помогает развивать продукт и улучшать клиентский опыт.
На курсе вы научитесь:
— применять инструмент для анализа потребностей и поведения пользователей: точки соприкосновения с продуктом, возможные барьеры, цели и эмоции;
— проводить глубинные интервью, задавать правильные вопросы;
— превращать CJM в понятные схемы, которые помогут отследить прогресс и метрики, чтобы принимать решения не случайно, а на основе данных.
Присоединяйтесь к курсу с новогодней скидкой 35% и внедряйте технику journey mapping в свои рабочие процессы и команды.
#промо
В tubik написали о единообразии в интерфейсе.
— Чтобы справляться с быстрым темпом современного мира и большим объёмом информации, люди стремятся снизить когнитивную нагрузку и выбирают простоту. В этом помогает единообразие (одна из эвристик Якоба Нильсена);
— Единообразие — способность вести себя или действовать одинаково;
— Единообразие одинаковых элементов интерфейса помогает быстрее освоиться новым пользователям, меньше путаться и ошибаться, снижает когнитивную нагрузку, работает на силу бренда;
— Визуальное единообразие — похожие элементы выглядят одинаково. Посты с разными типами контента всё равно должны быть похожи на посты;
— Функциональное единообразие — похожие элементы ведут себя одинаково. На любой пост можно нажать, чтобы его прочитать;
— Внутренняя согласованность — различные части интерфейса или бренда выглядят и работают как единая система. Ключевые кнопки раскрашены в цвет бренда;
— Внешняя согласованность — элементы интерфейса ведут себя так же как и в других продуктах такого типа. Подчёркнутый синий текст ведёт себя как ссылка;
— Как сделать дизайн единообразным и согласованным: придерживайтесь узнаваемых шаблонов (обычно красный цвет показывает что-то негативное, зелёный — позитивное), системно подходите к использованию шрифтов, цветов и изображений, придерживайтесь фирменного стиля во всех каналах коммуникации, не забывайте о единообразии в тексте (терминология, стиль, tone of voice);
— Даже непоследовательное использование регистра (написание с заглавной только первого слова в кнопке или каждого слова) может вызывать дискомфорт.
#consistency #principles
Андрей Кононов написал о проектировании сложной функциональности на примере заказа товаров в сетевом магазине.
— В сети магазинов у товара могут быть разные статусы: доступен в выбранном магазине, в другом магазине того же города, на региональном складе, недоступен. Как должен работать интерфейс заказа, если в корзине товары с разными статусами?
— Чтобы собрать базовые ограничения, поговорите со стейкхолдерами. Причины серьёзных интерфейсных сложностей обычно находятся за пределами интерфейса;
— Изучите прошлые наработки компании, а также конкурентов, чтобы найти возможные решения. Проанализируйте их;
— Допустимый вариант: разделение корзины на несколько заказов с отдельными способами доставки и оплатой. Рекомендуемые: разделение корзины с единой оплатой или единый заказ с единой доставкой, которой дольше ждать. Последний вариант может стать опцией;
— Составьте карту сценариев с действиями пользователя и ответами системы. В первую очередь опишите основной;
— Составьте логическую карту интерфейса. Это позволит синхронизироваться с другими участниками проекта и ничего не упустить на следующих шагах;
— Пользователь может быть авторизован и нет, активировать промокод, получать заказ не лично, вернуться к оформлению через несколько дней, когда статусы товаров из корзины могли измениться;
— Создайте черновой прототип решения и покажите команде. Так можно увидеть проблемы на ранней стадии, попытаться убедить стейкхолдеров пересмотреть базовые ограничения;
— Может выясниться, что если на одной странице будет несколько заказов, пользователь может оформить один, а остальные не заметить;
— Для пользовательского тестирования полезно сделать высокодетализированный прототип, моделирующий реальное оформление заказа с выбором размера товара, количества, способа получения и так далее;
— На модерируемом тесте можно уточнить, почему какие-то шаги вызвали сложности, как респондент воспринял тот или иной элемент интерфейса.
Освоить веб-разработку с нуля за 10 месяцев — реально, если правильно выстроить программу и усердно заниматься. Упорство зависит от вас, а о программе позаботился Яндекс Практикум.
— Программа основана на реальных требованиях работодателей к младшим специалистам.
— Интерактивный тренажёр помогает освоить теорию и закрепить её в тестах.
— Практика идёт на учебных проектах для портфолио.
А ещё на курсе много работы с опытными специалистами:
— наставники-разработчики разбирают сложные темы на живых вебинарах.
— команда поддержки отвечает на вопросы по теории в тренажёре.
— код-ревьюеры проверяют проекты и подсказывают, как их улучшить.
— кураторы помогают с организацией и расписанием.
— карьерный центр учит работать с резюме, мотивационными письмами, портфолио и собеседованиями.
Наших выпускники находят работу в новой сфере. Они берут проекты на фрилансе, устраиваются в стартапы и крупные компании — Яндекс, ВТБ, МТС, Перекрёсток, Playrix, Сбер и другие.
Протестируйте формат курса бесплатно →
#промо
Александра Савельева продолжает цикл статей о проектировании b2b-продуктов. Новая статья рассказывает, что должно быть на страницах таких продуктов.
— Давайте как можно больше информации, её внимательно читают. Так одни клиенты не уйдут, а другие не будут задавать одинаковые вопросы. Делайте это порционно: сначала основное, затем детали;
— Можно разместить призыв задать вопрос, если какой-то информации на странице не хватило;
— Если есть исследования, показывайте, как внедрение продукта влияет на метрики. Например, Slack на 24% ускоряет выход нового сотрудника на максимальную эффективность;
— Показывайте идентификаторы товаров, чтобы опытные клиенты быстро их находили;
— Рассказывайте о соответствии стандартам: требованиям безопасности, доступности и так далее;
— Предлагайте пакетные решения, а также альтернативные варианты и дополнения. Но дополнения должны того стоить, чтобы не подорвать доверие;
— Если добавляете видео, предупреждайте о продолжительности, добавляйте субтитры для тех, кто смотрит без звука. Видео должно быть лаконичным и без громкой музыки;
— Показывайте таблицы сравнения с продуктами конкурентов. Но только непредвзятые, чтобы не подорвать доверие специалистов. Например, в такой таблице на собственном сайте Скетч по многим параметрам превосходит Фигму, но специалисты увидят подвох;
— Сохраняйте страницы архивных продуктов. С них клиент может начать поиск актуальных аналогов;
— Можно добавить калькулятор, но только достаточно лёгкий для освоения. Спроектировать такой будет целым вызовом;
— Предоставьте несколько способов найти информацию: с помощью обычной навигации, каталога, поиска;
— Показывайте цены, это самый главный критерий для принятия решения.
Канал Александры.
Юлия Салах написала о мелочах, которые помогут улучшить дизайн.
— Тени чисто чёрного или серого цвета создают эффект грязи. Используйте в интерфейсе цветные тени, например, с примесью синего;
— Для текста лучше использовать не чисто чёрный цвет, а тёмно-серый (можно добавлять примеси);
— Выравнивайте элементы по сетке, используйте систему отступов и правило близости;
— Следите за внутренним радиусом скругления. Обычно берут половину от внешнего радиуса, но иногда для гармонии его надо увеличить;
— Если не противоречит стилистике, острые углы лучше немного скруглять (на 1–2 пикселя), так как в природе идеально острых углов не бывает;
— Иконки размещайте в собственных фреймах. Автоматическое центрирование подходит не всем иконкам. Некоторые надо немного сдвигать, чтобы сохранялось ощущение, будто они центрированы.
Канал Юлии.
Станислав Хрусталёв написал об онбординге в мобильных приложениях.
— Фокусируйтесь не на функциях продукта, а на ценности, которую они несут пользователям. Это могут быть и преимущества компании (бесплатная доставка), и информация об акциях и промокодах;
— Экранов не должно быть много, выделите ключевые ценности;
— На последнем разместите призыв к действию, чтобы переход от онбординга к взаимодействию с продуктом был бесшовным;
— Занимайте онбордингом весь экран (речь о мобильных приложениях);
— В процессе можно собрать первичную информацию о потребностях пользователя и персонализировать последующее взаимодействие;
— Покажите очевидный способ перехода на следующий экран (например, кнопку), но и перемещение свайпами (и тапами по правой и левой стороне экрана) тоже можно реализовать;
— Кнопка должна располагаться в одном и том же месте;
— Переход между экранами может происходить автоматически в формате сторис. Но важно подобрать правильный тайминг и дать возможность приостановить переход;
— Сопровождайте текст визуализацией, чтобы облегчить восприятие и заинтересовать. Она не должна быть слишком абстрактной. Ей может стать часть интерфейса приложения;
— Отображайте Page Control, чтобы управлять ожиданиями о количестве слайдов. Обычно его размещают в нижней части экрана и центрируют по горизонтали;
— Доступ к уведомлениям и геолокации стоит запрашивать, когда есть контекст и потребность, а не в самом начале;
— На экране с пояснением, зачем нужен тот или иной доступ, стоит предусмотреть возможность пропустить и принять решение о доступе потом;
— Кнопка пропуска онбординга должна быть заметной, но не акцентной. Обычно её располагают в правом верхнем углу.
Канал Станислава. #onboarding
Можно ли войти в IT без кодинга — но с теми же зарплатами, перспективами и интересными проектами? Станьте UX/UI-дизайнером, чтобы создавать интерфейсы сайтов и приложений, которыми будут пользоваться каждый день.
Примерьте профессию на бесплатном интенсиве 12, 13, 14 декабря в 17:00. За три дня вы успеете поработать в программе для дизайнеров Figma и собрать первый блок для сайта — с фидбеком от профи.
В результате вы:
— погрузитесь в профессию UX/UI-дизайнера,
— создадите первую работу и получите обратную связь от эксперта,
— получите полезные призы и подарки,
— пообщаетесь с действующим дизайнером в закрытом чате.
Вы узнаете о профессии из первых рук и получите оценку своей работы от действующего дизайнера. За регистрацию дарим гайд «300 полезных ресурсов для дизайнеров».
Зарегистрироваться: https://go.contented.ru/jtPQeA
#реклама
В Everest написали о формах поиска билетов на сайтах авиакомпаний.
— Поиск билетов — один из самых частотных сценариев на сайте авиакомпании. Форму поиска лучше располагать по центру и не совмещать с рекламными каруселями, чтобы те не отвлекали;
— Рядом можно расположить ссылки на следующие по популярности функции: регистрация, управление заказом, статус рейса;
— Полезно определять город вылета по локации пользователя. Если вылетов из его города нет, можно показывать ближайший. Если аэропорт временно не работает, показывать его недоступным и пояснением;
— Пользователи могут вводить неофициальные топонимы (Питер), хорошо бы это учитывать и находить искомые города;
— В списке городов можно показывать сначала популярные, а потом все остальные в алфавитном порядке;
— Только Utair понятно подсказывает, что в полях «Откуда» и «Куда» нельзя указать один и тот же город: «Укажите разные города»;
— Лучше не заполнять по умолчанию поле с датой вылета. Пользователи обычно фокусируются на заполнении пустых полей и могут его пропустить;
— Чтобы искать билет в один конец, на сайте Аэрофлота надо оставить пустым поле с датой возвращения. Возможность явно это указать пользователям привычнее: переключатель «Только туда — Туда и обратно» или кнопка «Обратный билет не нужен»;
— Если пользователь выбрал вариант «Туда и обратно», но дату возвращения не указал, можно искать билеты в один конец;
— Можно добавить крестик для быстрого сброса даты «Обратно»;
— Люди могут искать билеты сильно заранее, удобно иметь возможность выбрать год и месяц в календаре, а не пролистывать его помесячно. Используйте календарь, показывающий сразу 2 месяца;
— В календаре стоит выделять дни, когда рейсы есть. Удобно, если там будет примерная стоимость доступных билетов;
— Ни одна авиакомпания не разрешает выбрать больше билетов для младенцев (без отдельного места), чем выбрано билетов для взрослых, но только Уральские авиалинии отображают подсказку: «Младенцев не может быть больше, чем взрослых»;
— Полезно объяснять, что «младенцы» располагаются на руках у взрослых, без отдельного места.
#form
Почему мы вообще пишем о статье Лены Бородиной? Мало ли других примеров не очень удачных исследований?
Потому что статья Лены об оценке дизайна предлагается как история успеха, удачный кейс, на который нужно ориентироваться. Но успех выглядит не так. И мы категорически против того, чтобы образец бредовой работы выдавался за годный отраслевой стандарт.
⛔️Это не история успеха. Это история подгонки результата под ожидания заказчика.
И когда читаешь, спотыкаешься просто на каждом тезисе.
"Когда команда дизайнеров предлагала новые концепции ключевым заказчикам, они отзывались по-разному" - а почему концепции предлагались стейкхолдерам, а не пользователям? Почему исследователи не начали с тестирования концепций дизайна? Это более болезненно для дизайнеров, но позволяет отсеять неподходящие варианты, не затрачиваясь на их воплощение.
Почему методов оценки дизайна всего три: юзабилити-тест, айтрекинг и методика «5 секунд» от Microsoft? Почему не интервью, не фокус-группа и не количественное исследование? В рюкзаке моем сало и спички, и Тургенева десять томов.
Каким образом айтрекинг помогает объективно измерить отношение к дизайну? Как написали в комментариях: если человек долго смотрит на элементы дизайна, это он хорошо или плохо относится? Тот же вопрос относительно юзабилити-теста – а выполнение сценариев как поможет оценить дизайн?
Почему была выбрана методическая химера под названием «пятисекундный тест от Microsoft»? Цитируем: «человеку показывают скриншот экрана всего 5–10 секунд, а потом просят оценить и описать только внешний вид продукта. За такое короткое время никто не успевает вникнуть в функциональность и даже прочитать названия всех разделов — это как раз помогает нам собрать первое впечатление от увиденного, а не прочитанного или понятого».
В экспериментальной психологии есть понятие «экологическая валидность» - возможность обобщить данные эксперимента на реальную ситуацию. Нет никакого смысла изучать то, что в природе не встречается. В какой реальной жизненной ситуации ваш пользователь будет смотреть на сайт в течение 5-10 секунд? Ни в какой. Как правило, он смотрит на сайт дольше 5 секунд. А если он смотрит 5 секунд – то это «отказ», человек попал на сайт случайно и закрыл его.
Насколько идея оценивать дизайн отдельно от функциональности соответствует реальности? Клиенты Газпромбанка предпочитают любоваться на дизайн, ничего не делая на сайте? Тем более, что, судя по результатам, оценить дизайн отдельно от удобства не получилось. Самым частотным словом, которое называли пользователи, описывая дизайн, было слово «УДОБНЫЙ» (!).
Количество респондентов. Идея «сначала взять небольшую выборку и проверить распределение, а если данные не подойдут, просто добрать людей» - категорически не ок. Даже в симуляторе GoPractice написано, что так делать нельзя. Вы не можете добирать выборку до тех пор, пока результаты станут статистически значимыми. Потому что это тупо подгонка под желаемый результат.
Выборка и ее соответствие ЦА. Как-то вышли на 70 человек. Но почему среди них были жители Стокгольма и «разумеется, и специалисты UX-отрасли», если тестировался дизайн приложения российского банка? Что помешало отсеять тех, кто не является целевой аудиторией, и тех, кто смотрит на сайт с профессиональной точки зрения?
Почему оценивались именно тройки характеристик, а не отдельные характеристики? В результате, например, «тройка» из двух слов (буквально так) «красивый» и «много всего» получила положительно-отрицательную оценку.
Но стейкхолдеры эти результаты приняли. Ведь 75% характеристик, которые называли пользователи – были положительными.
Это, видимо, и была основная задача исследования – принятие стейкхолдерами. По крайней мере, о других задачах, которые ГПБ хотел решить с помощью редизайна, ничего не было сказано.
Как лучше было бы действовать и почему именно так – об этом следующий пост.
Герман Герасимов показал анимированные способы адаптации таблиц под экран телефона.
— Прокрутка таблицы с фиксацией шапки и первого столбца;
— То же самое, только остальные столбцы не прокручиваются свободно, а переключаются по одному свайпом. Полезна возможность выбрать нужный столбец в списке, чтобы быстро к нему перейти;
— Можно превратить строки таблицы в карточки;
— Карточки по умолчанию могут быть свёрнуты и показывать только основные данные, и разворачиваться при необходимости;
— Также полное содержимое карточки может открываться на отдельном экране;
— Неочевидный вариант: слайдер карточек. Автор предлагает необычный способ выбора нескольких карточек.
#table
Перед тем, как приступить к написанию любой главы, я составляю перечень тезисов, которые хотел бы в ней раскрыть. Иногда перечни эти кажутся мне более понятными и удачными, чем сами главы. Вот, например, на основе какого списка я писал главу о правках:
— Если работа делалась неделю, то клиент не может её всю проверить за час. Он придёт с новым пакетом комментариев на следующий день после первого;
— Если работа была сделана не так, как хотел клиент, на самом фундаментальном уровне, то гигантское количество правок будет играть роль костылей, так никогда до конца и не исправляющих ситуацию и плодящих всё новые костыли. Проще либо переделать работу заново, либо заплатить фрилансеру и расстаться, чтобы время не тратить;
— Работа может быть изначально не предназачена для внесения правок. Когда делаешь всё в последний момент и жертвуешь последовательностью ради быстрого результата;
— Можно контролировать «коридор вариативности» в работе. Нельзя слишком ограничивать вариативность, т.к. это не позволит получить результат, который точно понравится клиенту. Также нельзя слишком её увеличивать, т.к. чем меньше ограничений, тем сложнее работать;
— Клиенты не заинтересованы в бесконечных правках, им нужен результат;
— Не бывает мелких правок. Любой комментарий нужно фиксировать в письменном виде. Многие фрилансеры делают 8 из 10 правок, а остальные пропускают то ли случайно, то ли нарочно;
— Если клиенту трудно что-то выбрать, это общая проблема, с которой можно помочь позитивными штуками, а не негативными типа «выбирай уже скорее или соглашайся с тем, что есть» или «нужно больше вариантов — плати больше денег»;
— Я не ограничиваю клиентов в правках и выстроил процесс так, чтобы итерационно прийти к совместному результату;
— При этом, если правки явно выходят за границы коридора вариативности, то нужно отказываться от них, при этом добавляя в список «работ на потом», которые оцениваются отдельно. Важно, чтобы эти заметки не терялись и клиент видел, что исполнитель всё услышал и зафиксировал и в будущем готов воплотить в жизнь, но не в рамках текущего договора;
— Есть исключения, когда правки настолько незначительные, что можно пренебречь их оценкой и сразу внедрить, даже если они выходят за границы коридора вариативности;
— Любой результат работы, даже идеальный, спровоцирует дать обратную связь, улучшающую его, такова природа вещей.
В Antro написали о лучших практиках входа и регистрации в интернет-магазинах.
— Пользователи входят не только для того, чтобы что-то купить. Они могут проверять статус заказа, искать сделанную ранее покупку, чтобы порекомендовать её и так далее;
— Располагайте кнопку входа в правом верхнем углу страницы;
— При наведении на неё курсора можно рассказывать о преимуществах личного кабинета;
— Показывайте, что пользователь авторизован. СберМегаМаркет отображает только количество баллов, Озон — имя пользователя, Яндекс Маркет — фото. Это удобно, если одним устройством пользуются несколько человек;
— Совмещайте вход и регистрацию;
— Не давайте в одно и то же поле вводить номер телефона, логин и адрес электронной почты. Такое поле нельзя автоматически заполнить, не получится установить подходящий тип клавиатуры для мобильных, нельзя использовать маски, подсказки и сообщения об ошибках будут громоздкими;
— Для входа отправляйте код — вместо входа по паролю. 78% пользователей запрашивают восстановление пароля в течение 90 дней;
— Не деактивируйте кнопки, если какие-то поля не заполнены. Не все люди знают, что в вебе так бывает (в офлайне кнопки обычно не перестают нажиматься, даже если нажатие ни к чему не приводит). Лучше при нажатии отображайте сообщения об ошибках для некорректно заполненных полей;
— Предлагайте несколько способов входа и регистрации. Если телефон разряжен или сейчас стоит другая симкарта, пользователю может быть удобен вход через электронную почту;
— Маркируйте поле для автозаполнения, чтобы можно было подставить номер телефона или имейл;
— Давайте очищать поле одним нажатием.
#sign_up #log_in #ecommerce
Барт Гиссенс написал, почему курсор в операционных системах наклонён на 45°.
— В демо Дугласа Энгельбарта курсор был в виде стрелки вверх (кстати, посмотрите его The Mother of All Demos);
— Графический интерфейс операционной системы впервые реализовали в Xerox PARC;
— Из-за низкого разрешения экранов того времени не получалось создать пиксельный вертикальный курсор нормального размера. Поэтому решили его повернуть, чтобы одна грань была вертикальной, а другая — наклонённой под 45°.
#icons