« Дональд Норман. Почему неправильно заниматься исследованием пользователей в начале проекта | | Создатель Gmail, Пол Бакхайт о том, где лучше работать: "Не в деньгах счастье?" »

Простой и понятный дизайн приложений с помощью вариантов использования (use cases) по Роберту Хукману

На заметку будущим переводчикам: автор книги - голландского происхождения, поэтому фамилию Hoekman следует произносить "Хукман".

Книгу Роберта Хукмана "Designing the obvious" хочется похвалить отдельно. Очень маленькая и очень полезная книжка, описывающая приемы работы над современными (читай: динамическими, интерактивными, веб-два-нольными) приложениями.

Воды в книге практически нет. Только приемы и методы, полезность которых доказана на деле. Автор не отклоняется от темы, не ударяется в лирику, не пытается создать очередной 500-страничный фолиант "про все". На каждую тему (методику, прием работы) отводится 2-3 странички, не больше. В чем-то эта книжка очень напоминает Getting Real от 37signals: она не про то, как научиться чему-то в академическом смысле, а как быстрее отбросить всякие книжки и взяться за дело.

Среди прочих приемов Роберт описывает "варианты использования" - use cases. Вам наверняка не раз приходилось слышать этот термин. Помните, что писал на эту тему Алистер Коуберн?

"Варианты использования не стоит применять для описания пользовательского интерфейса, несмотря на то, что их форма и позволяет это делать. Существует две основные причины, по которым их не стоит использовать для этого. Во-первых, вариант использования - это документ, описывающий требования к системе, а дизайн пользовательского интерфейса производится опытными специалистами, которым нужно сначала объяснить, что и как должна делать система. Во-вторых, дизайн интерфейса - очень непостоянная материя, он часто меняется. Если описывать интерфейс с помощью вариантов использования, то получится, что это описание нужно будет очень часто менять, гораздо чаще, чем это может делать любая команда разработчиков (по крайней мере, из тех, что я видел). Для описания пользовательского интерфейса можно найти более удобные формы описания: диаграммы переходов между состояниями, Константайновские "варианты задач", скриншоты и т.д."

Хукман считает, что варианты использования могут быть разными:

  • это либо высокоуровневые описания ситуаций использования программы (например, "Мэри заходит на сайт target.com, чтобы составить список мебели для домашнего офиса),
  • либо детальные описания того, что происходит на экране, включая взаимодействие пользователя с элементами интерфейса. И это, с точки зрения классического понимания вариантов использования, полная ересь.

И использует их так, как ему это удобно:

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

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

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

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

Собственно, вчера я работал над вариантом использования, который описывает, как пользователь может оставить на сайте персональные рекомендации относительно продукта. Сначала у меня получилось что-то вроде:

Написать рекомендацию
Шаг 1. Пользователь кликает по ссылке Написать рекомендацию и сразу же под ней появляется форма. Тех. приписка: эта форма находится в скрытом DIV, который загружается вместе со страницей.
Шаг 2. Пользователь заполняет форму.
Шаг 3. Пользователь кликает ОК, чтобы отправить рекомендацию, и форма исчезает.

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

Замечательно, теперь у меня есть вариант использования из четырех шагов, в котором говорится, что пользователь нажмет на кнопку, заполнит форму, кликнет ОК, чтобы отправить рекомендацию, или Закрыть, чтобы форму убрать. Теперь у меня есть кнопка, которая служит сразу двум задачам, пользователь получает форму немедленно после клика (его не направляют на другую страницу и не перегружают ту, на которой он находится), словом, все взаимодействие сделано "настолько просто, насколько это возможно, но не проще" (Альберт Эйнштейн). Отличный вариант использования.

Стоп. А что, если пользователь решит не заполнять форму?

Пишем исключения

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

Надо дополнить наш вариант использования - описать поведение системы в том случае, если пользователь решит не заполнять форму. В итоге получается следующее:

Написать рекомендацию
Шаг 1. Пользователь кликает по ссылке Написать рекомендацию и тут же внизу появляется форма. Тех. приписка: эта форма находится в скрытом DIV, который загружается вместе со страницей. Надпись на кнопке меняется: теперь на ней написано Закрыть.
Шаг 2. Пользователь заполняет форму.
Шаг 3. Пользователь кликает ОК, чтобы отправить рекомендацию, и форма исчезает. Над формой появляется сообщение о том, что рекомендация была успешно отправлена.
Шаг 4. Пользователь нажимает кнопку Закрыть, и форма исчезает.

Исключения
Шаг 3а. Пользователь нажимает Закрыть, не заполняя форму. Тех. приписка: это напоминает обычное закрытие диалога, то есть форма очищается от данных и убирается с экрана. Однако поскольку в нашем случае это скрытый DIV, то данные можно сохранять и показывать их пользователю, если он повторно нажмет на ссылку Написать рекомендацию.

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

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

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

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

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

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

Написать вариант использования проще, чем создать интерактивный прототип в HTML, который должны оживлять JavaScript и CSS. И зачастую такого варианта использования вполне достаточно, чтобы объяснить другому человеку (скажем, разработчику), как решить данную задачу в приложении, которое мы разрабатываем.

Доработка вариантов использования

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

Роберт Хукман называет этот процесс японским термином "кайдзен" и вкусно описывает, как любовно он вычитывает, правит и до-придумывает детальки своих вариантов использования:

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

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

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

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

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

Да, это действительно стоящее изменение. Жаль, что я не подумал об этом до того, как отослать вариант использования разработчику.

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

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

А может, без них еще лучше?

Поднимите руки, кто использует в работе варианты использования? То-то.

Некоторые считают, что время надо тратить исключительно на то, что имеет прямое отношение к коду программного продукта. Работать над чем-то другим однозначно плохо. Вместо того, чтобы изучать пользовательскую аудиторию, надо делать продукты, для которых вы сами будете целевой аудиторией. Сначала рисуете скетч, а потом сразу переходите к HTML.

Именно такой подход практикуют маленькие, но широко известные 37signals.com. Такой подход характерен для стартапов и небольших команд. Однако, в большинстве случаев, система разрастается, в команде появляются новые люди, поэтому интерфейс и взаимодействие приходится как-то документировать, чтобы сохранить единообразие и целостность системы.

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

Для тех, кто не станет заказывать книжку с Амазона, поделюсь находкой - Хукман опубликовал довольно большой кусок текста книги в виде статьи (отличия в тексте совсем небольшие) на сайте InformIT

kirsa January 30, 2008 4:49 PM

Комментарии

Сделать комментарий




Запомнить меня?