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

— Там пользователи читают справа налево, поэтому текст и числа на арабском выровны по правому краю, а привычная компоновка элементов отзеркалена по горизонтали;
— Слова или предложения на английском (или другом языке, на котором читают слева направо) выравнивают по правому краю, но порядок букв не трогают (то есть название PayPal так и будет отображаться);
— Если на английском целый абзац, его выравнивают по левому краю;
— Имеет смысл на 10% увеличивать кегль для текста в заголовках и на кнопках, так как в арабском языке и иврите нет заглавных букв;
— Числа (и номера телефонов), записанные западными арабскими цифрами (1235) пишутся слева направо, а восточными — справа налево. Исключение: цифры как часть контрола по оценке рейтинга будут располагаться в соответствии с направлением чтения;
— В направлении чтения надо разворачивать иконки, где показано движение (мотоциклист будет ехать справа налево, звук из источника лететь влево), символ текста, есть метафоры направлений назад и вперёд (стрелки «Назад» и Undo будут указывать вправо), ползунки для выбора значения в фильтрах;
— Не надо разворачивать: иконки с направлением движения по часовой стрелке и против часовой, объектами реального мира (в том числе у которых ручка справа — они просто ориентированы на правшей), логотипы и универсальные знаки (вроде галочки Check). А также аудио- и видеоплееры.

#localization

Джейсон Ван написал о мышлении новичка.

— Это состояние, когда человек открыт для нового, даже если ему знаком процесс или предмет, с которым он взаимодействует;
— Человеческая природа такова, что мы быстро привыкаем к повседневным вещам и уже через эти привычки воспринимаем окружающий мир. У людей обычно нет вопросов к привычным вещам;
— Это возможность для дизайнеров: сложившийся порядок вещей может быть не оптимальным или вовсе неправильным;
— Мышление эксперта противоположно мышлению новичка: все границы очерчены, а решения известны и ограничены. Кстати, об этом писал Генри Форд: «Но таковы уж все умные люди: они так умны и опытны, что точно знают, почему нельзя сделать то-то и то-то, и везде видят ограничения и препятствия. Поэтому я никогда не нанимаю на работу чистокровного специалиста. Если бы я хотел уничтожить конкурентов, я предоставил бы им полчища специалистов. Получив массу „полезных“ советов, мои конкуренты не смогли бы даже приступить к работе»;
— Мышление новичка полезно для инноваций, но его надо тренировать: осознавать, что привыкли использовать мышление эксперта, отбрасывать предубеждения и задавать вопросы, почему что-то работает именно так;
— Обращайте внимание, когда люди при взаимодействии с продуктом немного расстраиваются, но считают, что всё нормально. Возможно, они просто привыкли.

In English. #thinking

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

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

#prioritization

Я не читала книгу «Спроси маму», потому что считала, что она для новичков в интервьюировании. Но она попалась мне в фикспрайсе (там кстати клевые книги продают, прикиньте да) и я решила, что это судьба.

Вобщем, книга реально для самых маленьких, а ещё она сама маленькая и читается за 3 часа.
Короче, вот основные тезисы (но прочитать стоит целиком ради смешных примеров):

⭐️ говорите с людьми об их жизни: проблемах, заботах, целях, ограничениях

⭐️ не пытайтесь продать свою идею, вообще о ней не говорите, просто задавайте вопросы о жизни респондентов

⭐️ начинать интервью с фразы «мы разрабатываем приложение для N и хотим задать вопросы об этом» - такое себе.

⭐️ люди начинают врать, чтобы вас не обидеть, как только вы даёте повод (выпрашиваете похвалу, спрашиваете о будущем или продаёте им идею)

⭐️ спрашивайте о фактах в прошлом, а не мнение о будущем

⭐️ мнения бесполезны

⭐️ люди знают о проблемах но не знают как их решать

⭐️ некоторые проблемы фактически не являются проблемами, а люди просто ноют. Уточняйте насколько важна проблема.

⭐️ наблюдая мы видим реальные проблемы, а не то как люди о них говорят

⭐️ если потенциальные клиенты не пытались найти решение проблемы самостоятельно, они не обратят внимания на ваше решение

⭐️ люди не будут вам помогать без понятной на то причины

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

⭐️ переходите к конкретике и уточняйте ответы вида «я всегда…», «я бы поступил так…», «я бы мог…»

⭐️ если вам предлагают решение, копайте зачем оно и как без него сейчас. Возможно, вполне неплохо.

⭐️ спрашивайте об эмоциях

⭐️ не надо быть воодушевлённым своей идеей, вас будут жалеть и врать

⭐️ меньше говорите

⭐️ задавайте вопросы, которые могут до основания разрушить вашу идею

⭐️ идея может оказаться 💩, но это хорошая новость

⭐️ интервью - не панацея от рисков выпустить 💩

⭐️ отбросьте формализм: пусть интервью превратится в «случайную» беседу в рандомном месте (в курилке, после собрания, на кухне)

⭐️ «добро пожаловать на интервью, спасибо что согласились уделить нам время» - такое себе. Не душните

⭐️ в живую всегда лучше


Ещё там кучка советов для стартаперов, но нам-то до них какое дело, правильно, мы тут пиксели двигаем

Юлиана Пономарёва написала, как презентовать команде результаты исследования.

— В «Контуре» есть внутреннее агентство, которое помогает командам без UX-исследователей: погружается в контекст настолько, чтобы провести качественное исследование, но не настолько, чтобы принимать решения;
— Обычно это начальные и средние стадии развития продукта, и команде ценна каждая мелочь, которую получается узнать о пользователях;
— Результаты исследования оформляли в виде лонгрида и презентовали на встрече (1–1,5 часа): гипотезы, выборка, результат проверки гипотез, что говорили пользователи (с цитатами, нарезками аудио, описанием их специфики), выводы, рекомендации, что ещё стоит поисследовать;
— Перед презентацией полезно докрутить формулировки с основным заказчиком исследования — помогает закрыть боль с недостаточным погружением в процессы, предметную область и принятые в команде термины;
— Команды работали с результатами самостоятельно и возвращались к исследователям уже потратив много лишних ресурсов. У исследователей возникало ощущение работы в стол;
— Изменили цель встречи: максимально полная передача контекста → принятие решений о дальнейших шагах. Лонгрид → доска в Miro; дословные транскрипты → резюме; много текста → скриншоты, стикеры, emoji; длинный монолог исследователя → рассказ на 15–20 минут с информацией, необходимой для принятия решений;
— Добавили 30 минут работы со списком всех обнаруженных проблем, идей и связанных с ними рекомендаций. Задача: по каждому пункту зафиксировать решение или дальнейшие шаги;
— Команды стали быстрее принимать решения на основе исследований, исследователи стали видеть результаты своей работы;
— Важно выбирать структуру и состав ребят на встрече (надо знать, кто за что отвечает), отталкиваясь от цели и тех решений, которые сейчас важно принять.

#research

Алисия Суска написала о дизайн-долге.

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

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

Опубликованы видео со 2-й конференции по цифровой доступности (о пользовательском опыте людей с разными нарушениями).

1. Евгений Арнапольский — незрячий пользователь программ экранного доступа (скринридеров). Проводя аналогии между физическим и цифровым миром, рассказал об ассистивных технологиях, а также на примерах Госуслуг, Вконтакте, Сбермаркета и других сервисов показал барьеры в интерфейсах.

2. Денис Редькин — пользователь с нарушением моторики. Как устроено его рабочее место, каким образом он управляет ноутбуком и мобильным телефоном, как играет в компьютерные игры, какие способы управления усложняют, а какие наоборот упрощают ему жизнь.

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

4. Геннадий Тихненко — пользователь с нарушением слуха. С какими барьерами сталкиваются глухие и слабослышащих люди в физическом и цифровом мире, какие решения сейчас есть на сайтах и в приложениях.

5. Алексей Цаплин — слабовидящий пользователь, использующий одновременно увеличение и программу экранного доступа. С какими трудностями он сталкивается на примерах Пятёрочки, Самоката, Вконтакте и других.

#accessibility

Костя Малков выписал главные мысли и примечательные цитаты из книги Кена Косиенды «Творческий отбор. Как создавались лучшие продукты Apple во времена Стива Джобса».

«Каждая функция iPhone начиналась с демо. Разработчики буквально должны были демонстрировать свои идеи. Они не могли рассказывать об идеях. Нужно было их показать. Причём демоверсия должна быть максимально точной и конкретной. Без демо не о чем спорить, нечего обсуждать — это абстрактные разговоры ни о чём. Демо — это возможность дать конкретную обратную связь на конкретные вещи, из которой становятся понятны следующие шаги. И конкретика этой обратной связи куда важнее того, от кого эту обратную связь получаешь (даже если это твои коллеги, а не реальные пользователи).

Итерации от демо к демо — это процесс превращения чего-то неосязаемого, непонятного в конкретное и работающее так, как надо. Каждая демка должна быть в чём-то лучше предыдущей. Важно создавать демки быстро, чтобы быстро принимать решения по поводу следующих шагов, будь то шаг вперёд или назад. Этот путь (демо > обратная связь > следующее демо) и есть творческий отбор.

Накидывание идей на белой доске, споры и обсуждения ощущаются как работа. Но это не так. Это всё абстрактные идеи, которые не дают конкретной обратной связи, каким должен быть следующий шаг. Поэтому меньше мозговых штурмов и больше демок».

#process

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

— Основная навигация в них обычно скрыта: пользователю сложнее понять, где в иерархии сайта он находится, а также сложнее перемещаться через главное меню;
— Хлебные крошки делают жизнь пользователя проще;
— Размещайте в них полный путь к текущему товару или хотя бы ключевые уровни иерархии;
— Чтобы они не были слишком длинными: а) избегайте чрезмерной категоризации (то, что должно быть фильтром, может быть ошибочно реализовано как категория), б) уберите из них ссылки на главную страницу (на неё можно попасть, нажав на логотип) и текущий товар, в) сократите названия категорий;
— Если строка с хлебными крошками всё ещё слишком длинная, дайте прокручивать её по горизонтали. Для большинства пользователей это естественно (особенно, если начало или конец строки будут обрезаться и тем самым намекать на возможность прокрутки);
— Добавьте отступы, чтобы строка с хлебными крошками не сливалась с другими элементами в верхней части страницы;
— Их оформление должно отличаться от других элементов на странице. Используйте подчёркивание и стандартные разделители > и / между уровнями иерархии.

In English. #breadcrumbs #mobile

Станислав Хрусталёв написал об избранном.

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

#favorites

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

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

#review

Тоня Сергеева написала, что делать с цифрами в тексте.

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

#writing

Тарас Бакусевич написал, как улучшить визуализацию данных.

— Всегда начинайте гистограммы с нулевого базового уровня. Иначе воспринимаемая разница в высотах прямоугольников будет отличаться от реальной разницы показанных ими значений;
— Для линейных диаграмм можно адаптировать масштаб оси Y, чтобы график не был слишком плоским (пусть он занимает 2/3 диапазона оси Y);
— Будьте осторожны с двухосными диаграммами, на которых отображается два ряда данных в разном масштабе. Люди часто ошибаются при их чтении;
— Ограничивайте количество секторов на круговой диаграмме. Оставьте 5—7 сегментов, а самые маленькие сгруппируйте в «Другое»;
— Перемещайте подписи из легенды прямо на диаграмму, но не на сами графические элементы диаграммы (понизит их читаемость);
— Упорядочивайте элементы диаграммы по значениям, а не по подписям (в алфавитном порядке), чтобы легко можно было увидеть самое большое значение, второе, самое маленькое и так далее;
— Чем тоньше кольцевая диаграмма, тем сложнее её читать.

In English. #data_visualization

Энтони Мёрфи написал о пользовательских исследованиях и сборе историй.

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

In English. #research #interview

Альтернативные решения по организации хлебных крошек (в мобильных версиях интернет-магазинов) из опубликованной ранее статьи Эдварда Скотта:

— Чтобы уменьшить длину хлебных крошек, можно не отображать в них некоторые категории (уровни иерархии);
— Но тогда пользователи могут а) неправильно понять, как организован сайт и где они находятся, б) перейти на более высокий уровень иерархии, чем хотели бы, и увидеть менее релевантные товары;
— Также в хлебных крошках можно отображать только текущую категорию;
— Но это не позволяет а) понять, как организован сайт, б) перейти больше чем на один уровень иерархии за раз;
— Такое решение даёт удобную возможность вернуться на шаг назад, но создаёт проблемы тем, кто попадает на страницу товара нелинейно. Ссылка вернёт их в родительскую категорию? Сохранятся ли применённые фильтры и сортировки?
— Ссылки в хлебных крошках можно переносить на следующие строки;
— Но так пользователям сложнее прицеливаться в нужную ссылку, а верхняя часть страницы визуально перегружается. Решение актуально для сайтов с неглубокой иерархией, где вероятность переноса невелика.

In English. #breadcrumbs

Станислав Хрусталёв написал о каталоге товаров.

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

#catalog #ecommerce

Ксения Морозова пересказала ключевые мысли из книги Дона Нормана «Дизайн привычных вещей».

Например, об ограничителях:

Знания определяют точность действий. Но не все они удерживаются в нашей памяти. Часть хранится в окружающем мире и в его ограничителях. И нет необходимости заучивать абсолютно всё со стопроцентной точностью.

Такие ограничители (физические, смысловые, культурные, логические) стоит активно использовать в дизайне. Важно помнить, что надписи и пометки хороши не везде. Точнее почти везде они необходимы, но как дополнительный элемент, обеспечивающий запоминание. Норман заявляет: «Если без надписей не обойтись — меняйте дизайн!». (Забавный пример такого дизайна.)

Очевидное назначение предмета предлагает пользователю возможности, а ограничители помогают выбрать среди множества вариантов правильные.

#book

Энтони Ценг написал о боковой панели меню.

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

In English. #sidebar #menu

В «Атвинте» написали о дашбордах.

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

#dashboard

Кейт Моран написала о пользовательском тестировании контента.

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

In English. #user_testing #writing