Как использовать эвристические оценки для улучшения продуктового дизайна

Быстрая альтернатива пользовательскому тестированию

Обычно мы оцениваем успешность продукта или на основе пользовательского тестирования, или используя глобальные теоретические принципы. Последний метод и называется эвристикой.

Помните Архимеда, который открыл закон вытеснения, принимая ванну? От восторга он выкрикнул: «Эврика!» — отсюда и появилось название метода. Знал ли Архимед, какие последствия вызовут его действия, когда он залезал в наполненную ванну? Рассчитывал ли он количество воды в этой самой ванне, массу своего тела и количество вытесненной жидкости перед своим экспириенсом? Конечно, нет. Но имеющиеся знания помогли ему сделать логичный вывод на основе уже прожитого опыта.

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

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

Как эвристика используется в оценке продуктового дизайна

Эвристические разборы проводят эксперты в области дизайна, накопившие достаточный опыт. При этом они используют так называемые эвристики — оценки юзабилити. Каждый эксперт применяет свой набор эвристик, но самыми популярными считаются стандарты Якоба Нильсена — доктора физических наук, специалиста в области интерфейсов и автора нескольких книг по веб-дизайну.

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

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

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

Эвристики Якоба Нильсена

Видимость состояния системы

Представьте себе, что вы скачиваете файл. На вашем экране появляется значок загрузки, который постепенно заполняется — вы спокойны, потому что видите, что нужный процесс начался. Можно убрать из интерфейса этот значок, загрузка при этом будет происходить, но вы этого не увидите. У вас сразу возникнут вопросы: «На каком этапе находится загрузка? Сколько еще ждать? И вообще, началась ли она?» Вы испытаете беспокойство и раздражение.

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

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

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

Соответствие между системой и реальным миром

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

страницы электронной книги перелистываются смахиванием, как и бумажные страницы;
покупка в интернет-магазине обозначается значком магазинной тележки или корзинки;
сайты СМИ похожи на страницы печатных изданий — крупное название, верстка, напоминающая газетную, анонс главных тем в начале страницы.

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

Пользовательский контроль и свобода

Допустим, вы работаете в графическом редакторе и сохраняете файл. Потом вы решаете, что хотите внести в него изменения, но уже поздно — оказывается, сохраненный файл изменениям не подлежит, нужно было оставить его в черновиках. Ваши мысли: «Как так? Почему меня об этом никто не предупредил?» Если бы перед сохранением вы увидели уведомление о последствиях, то поступили бы по-другому и не испытали бы раздражения.

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

Последовательность и стандарты

Существуют стандартные сценарии взаимодействия пользователя с интерфейсом, например:

чтобы перейти на главную страницу сайта, нужно нажать на лого в верхнем левом углу;
чтобы начать заполнение текстового поля, нужно кликнуть на него;
чтобы свернуть приложение в iPhone, нужно смахнуть вверх.

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

Эта эвристика относится и к единообразию внутри продукта. Если вы используете определенные шрифты, иконки и цвета кнопок, не нужно от них отходить. Для этого создаются гайдлайны и библиотеки элементов — файлы с утвержденными дизайн-элементами продукта.

Предотвращение ошибок

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

Предупреждайте возможные ошибки пользователей:

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

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

Узнавание, а не запоминание

Идеальный интерфейс — тот, взаимодействия с которым не замечают. Если пользователь начинает задумываться, как совершить то или иное действие — значит, разработчики интерфейса плохо выполнили свою задачу.

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

Как пример — оформление заказа на маркетплейсе. Если вы переходите в корзину, то видите, какие именно товары и в каком количестве уже там лежат. Вам не нужно вспоминать, что именно вы хотели купить, и откуда взялась эта сумма заказа. На этой же странице можно разместить и информацию о доставке, чтобы пользователь сразу видел ее стоимость и сроки.

Гибкость и эффективность использования

Несмотря на то, что существуют определенные паттерны поведения, все равно у каждого пользователя будет свой опыт взаимодействия с интерфейсами. Например, кто-то копирует текст клавишами CTRL+C, а кто-то вызывает для этого контекстное меню, кто-то регулирует яркость монитора через настройки, а кто-то — через функциональные клавиши. Поведение пользователя зависит от его индивидуального опыта и предпочтений.

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

Опытные пользователи не должны чувствовать раздражения из-за того, что некоторые задачи они могли бы решить быстрее, используя уже накопленный опыт. А новички не должны теряться, потому что не понимают, как взаимодействовать с интерфейсом.

Эстетичный и минималистичный дизайн

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

Интерфейс выполняет утилитарную функцию — подвести пользователя к цели, и он не должен отвлекать. Каждый элемент дизайна должен отвечать на вопрос — зачем он здесь?

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

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

Помощь пользователям в распознавании, диагностике и устранении ошибок

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

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

Каждый «ошибочный» сценарий нужно проработать отдельно. Если ошибку можно решить сразу — продумать подсказку, если нет — придумать решение, которое позволит все исправить: например, разместить ссылку на чат с поддержкой.

Помощь и справочные материалы

Конечно, лучше всего создать интерфейс, к которому не будет никаких вопросов. Но такое случается только в идеальном мире, поэтому нужно дать пользователям необходимые подсказки, если они будут испытывать трудности.

К этому пункту относятся туториалы, всплывающие подсказки, странички с часто задаваемыми вопросами, базы знаний, гайдлайны. Также в поле зрения пользователя всегда должны быть контакты службы поддержки или иконка онлайн-чата. Чтобы не загружать поддержку, можно создать бота, который будет отвечать пользователям на самые распространенные вопросы и проводить простейшую диагностику ресурса.

Объем справочных материалов зависит от вашей целевой аудитории — чем она шире, тем тщательнее нужно осветить всю функциональность продукта. При этом хороший способ проверить ваши справочные материалы — дать их на оценку пользователю, который никак не связан с вашим ресурсом и его тематикой. Если он легко поймет задачи и функции продукта, то справочные материалы можно публиковать.

Как провести эффективный эвристический разбор

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

Стоит ли использовать эвристику для оценки любого продукта

Как и у всех методов тестирования, у эвристики тоже есть достоинства и недостатки.

Плюсы:

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

Минусы:

Оценки основаны на эмпирическом опыте эксперта, а его опыт может не подойти вашему продукту.
Эвристики рассматривают юзабилити в глобальном смысле, но удобство ресурса нужно оценивать в тесной связке с его конкретными задачами и целевой аудиторией.

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