UX – Requirements to interface

Как получается удобный для пользователя веб-интерфейс?

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

Зачем?
— Чтобы с нуля сделать интерфейс, удобный дня пользователя.
— Чтобы проверить готовый интерфейс на «профпригодность».

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

Какие у него возможности, желания и потребности? А какая цель (а не задача)?
Затем надо понять, а как именно пользователь осуществляет свою цель. И разбить цель – на задачи, которые решает пользователь в процессе достижения своей цели. И так – для каждого пользователя, для каждой цели. Получится список задач пользователей, которые можно типизировать; при этом удобно выделить приоритеты от имени ваших пользователей.

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

По этому шагу рекомендую презентацию Татьяны Татьяны Табаковой — о выявлении интернет-потребностей.

Шаг 2. Написать пользовательские сценарии
У нас уже есть список задач, которые решает пользователь, чтобы достичь своей цели. Они типизированы, среди общего их числа выделены приоритеты. Для каждой задачи пишем сценарий: Пользователь сделал -> Система ответила.
Пользователь начинает, запрашивает что-то, а Система отвечает. Пошагово. Только без контекстов (ссылки, кнопки, функционал – в топку), они пока не нужны. Каждый глагол – это фактически экран, который возникает при совершении взаимодействия с системой. Такие экраны могут повторяться.

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

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

Шаг 3. Создать список страниц
Дайте страницам человекопонимаемое название экранам: такое, как будет использоваться в дальнейшем, в интерфейсе.
Посмотрите на список экранов – и увидите, что некоторые встречаются чаще, чем другие, и требуются в различных сценариях, но с одинаковой важностью; или же есть несколько экранов, с которых начинается сценарий – это ключевые страницы, которые будут «опорой» вашего интерфейса. А еще есть шаблонные экраны, на основе которых можно реализовать несколько схожих по функционалу и назначению страниц – это типовые страницы.
Соберите в список все страницы; маркируйте ключевые и типовые.

Шаг 4. Составить структуру навигации
Есть список страниц, есть список сценариев: и там, и там есть приоритеты. Теперь надо определить последовательность исполнения сценариев, поставить акцент на важные сценарии (посмотрите, где находится вход в каждый из пользовательских сценариев).

Можно поколдовать с концепцией: вынести в иерархии важные «хотелки», дополнить второстепенными. Удобно сделать в программе Flying Logic. Полный список страниц, их вложенность удобно отобразить в Excel’е — в итоге получится структура навигации интерфейса: все страницы должны быть перечислены, ключевые сценарии должны исполняться в первую очередь.
Профит: сразу видно структуру меню.

Шаг 5. Описать все страницы интерфейса
По-другому: напишите требования к странице. Что Пользователь хочет узнать на этой странице (информация)? А что сделать (действие)?
Эти данные как раз можно вычленить из списка составленных ранее пользовательских сценариев – всех сценариев, которые затрагивают эту страницу (_глаголы_)
Учитывайте контекст, в котором существует страница, и сценарии, при которых пользователь попадает на эту страницу.
Хороший интерфейс разрешает соответствующие информационные запросы пользователя и даёт инструменты для совершения действий (кнопки, ссылки и так далее). И, чем лучше прототип решает две эти задачи, тем больше интерфейс отвечает ожиданиям Пользователя.
Вот он — функционал : )

Итого: список документов «на выходе»
— Описание Пользователей и список жизненных историй
— Cписок пользовательских сценариев
— Список страниц интерфейса
— Структура навигации
— Требования к интерфейсу (описание страниц)

Как этими документами пользоваться

1) Для того, чтобы спроектировать интерфейс системы, нужно:
Используя требования к интерфейсу, создать макеты для всех ключевых и типовых страниц (в зависимости от ресурсов, можно детально описать, что выполняет тот или иной блок, какой функционал в него заложен (информирование или действие)
Для формирования меню пригодится понадобится структура навигации.
Все остальные страницы, которые попали в шаблонные – отрисовать на примере уже созданных макетов
Связать страницы нового интерфейса, пользуясь структурой навигации.

2) Чтобы проверить прототип интерфейса, достаточно:
Убедиться, что все сценарии, присутствующие в списке сценариев, соотвествуют потребностям Пользователей интерфейса и в полной мере реализуются с помощью системы;
Все страницы, описанные в списке страниц, присутствуют в системе;
Каждая из страниц системы удовлетворяет ожиданиям Пользователей, описанным в требованиях к интерфейсу.

 Посмотреть:

Справочно — читать накипевшее:

Перед написанием поста, искала немного другие требования. Нашла несколько интересных материалов. Думаю, они не повредят.

Статья Павла Коноплицкого (2008 год, #uxrussia: почему _для пользователя_).  А также, кратко о различных требованиях и о прототипировании — тут, тут, и тут.