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

Автор

Артеменко Ксения

Источник

http://kseniaartemenko.com/ux/polzovatelskie-trebovaniya-k-interfejsu.html

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

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

Шаг 1. Придумать пользователя и его жизненную историю

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

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

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

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

Шаг 2. Написать пользовательские сценарии

У нас уже есть список задач, которые решает пользователь, чтобы достичь своей цели. Они типизированы, среди общего их числа выделены приоритеты. Для каждой задачи пишем сценарий: Пользователь сделал -> Система ответила.

Пользователь начинает, запрашивает что-то, а Система отвечает. Пошагово. Только без контекстов (ссылки, кнопки, функционал – в топку), они пока не нужны. Каждый глагол – это фактически экран, который возникает при совершении взаимодействия с системой. Такие экраны могут повторяться.

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

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

Шаг 3. Создать список страниц

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

Шаг 4. Составить структуру навигации

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

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

Шаг 5. Описать все страницы интерфейса

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

Итого: список документов «на выходе»

- описание Пользователей и список жизненных историй
- список пользовательских сценариев
- список страниц интерфейса
- структура навигации
- требования к интерфейсу (описание страниц)

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

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

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