Как работают принципы дизайна в digital

В первой статье мы рассмотрели принципы дизайна и то, из каких этапов состоит действие человека. В этой поделимся, как это применяется при работе с цифровыми решениями. Далее рассказ пойдёт от лица UI/UX-дизайнера INOSTUDIO — Данила Шклярского.

Есть такой термин — “User Experience Design”. Он означает пользовательский опыт, который дизайнер создаёт для того, кто будет использовать продукт. Автор книги «Дизайн привычных вещей» Д. Норман — основоположник концепции User Experience Design. Он подсказывает, как дизайнерам использовать все эти знания в своей работе.

Я беру схему из 7 этапов действия и адаптирую под систему.

Проблема пользователя. Цель меняю на проблему пользователя, которую мне, дизайнеру, необходимо правильно определить и решить.

Потребность к действию. Здесь пользователь уже собирается совершить какое-то действие. И мне нужно понимать, как он это будет делать. Исходя из этого, я строю пользовательский сценарий.

Уточнение действия. На этом этапе я должен понять, с каким элементами интерфейса (означающими) пользователь встречается.

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

Восприятие действия. Это то, как пользователь понимает, что действие произошло.

Интерпретация системы. Это то, как пользователь понимает, в каком состоянии находится система.

Сравнение. Этот этап подсказывает пользователю, решил ли он свою проблему.

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

Так вот после прочтения книги «Дизайн привычных вещей» меня осенило. Что если я соберу эти вопросы в разные группы и попробую их разбить на этапы? Вот как я это сделал.

Проблема пользователя

• Определить проблему
• Определить ЦА (целевую аудиторию)
• Сопереживать пользователю

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

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

Например, дизайнер создаёт снаряжение для скалолазов. Он должен учитывать, что у скалолаза одна рука будет занята, так как он будет ей держаться за скалу. Значит, дизайнеру надо учитывать положение альпиниста при проектировании использования крепежа скалолазного оборудования.

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

Начинается этап разрыва выполнения.

Потребность к действию

• Построение пользовательского сценария
• Учёт ожиданий пользователя
• Описание информации или контента, который должен быть виден сразу

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

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

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

Уточнения действий

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

Например, у нас есть конкретный сценарий решения проблемы пользователя. И мы не должны создавать дополнительные элементы, которые будут его отвлекать, «уводить в сторону».

Исполнение действия

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

Дальше начинается этап разрыва оценки.

Восприятие действия

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

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

Интерпретация системы

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

Сравнение

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

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

Посмотрим на пример сценария взаимодействия пользователя с системой.

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

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

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

Мы обсудили, какие существуют принципы дизайна, как они помогают создавать хороший пользовательский опыт, задавать ему направление взаимодействия с продуктом. И возникает логичный вопрос, а как придумывать новые идеи, если все решения переиспользуются? Поделюсь двумя интересными методиками.

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

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

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

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

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

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

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

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