Об авторе

Поиск по сайту:

GUI.ruПерепроектируйте это немедленно!

Проектировать взаимодействие это вам не орешки щелкать

Алексей Копылов
02.06.2009Алексей Копылов

Комментариев:

4

Скоростная фиксация сценариев использования

Краткое резюме

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

Данная статья основывается на докладе, который был прочитан мной на конференции «Интернет и бизнес 2008» в апреле прошлого года.

Проблема

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

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

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

  1. Быть быстрым и дешевым в использовании;
  2. Обеспечивать генерацию большого количества сценариев;
  3. Давать возможность выявлять недостающие сценарии, которые забыли учесть.

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

  • У проектировщиков нет возможности провести этап исследований с привлечением реальных пользователей;
  • Процесс проектирования и разработки является итеративным (например, является вариантом Agile метода разработки);
  • Пользовательский интерфейс не слишком сложный;
  • Приложение, для которого проектируется пользовательский интерфейс не слишком критично к ошибкам пользователей.

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

Методика фиксации

По сути, методика является упрощенным вариантом известной методики построения аффинных диаграмм.

Далее основные действия приведены по шагам.

Шаг 1: генерация микро-сценариев

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

Фиксировать микро-сценарии удобнее всего с помощью липких листочков (типа «Post-IT») приклеивая их на больших кусках ватмана, либо с помощью ментальных карт (типа «MindManager» от компании «Mindjet»). В обоих случаях достаточно записывать на карточку название микро-сценария, проговаривая вслух с участниками его внутреннюю структуру.

В процессе генерации подзадач возникает желание объединять их в задачи. Очень просто и естественно это делается при использовании техники ментальных карт – отдельные ветки можно перетаскивать из одного места в другое и прикреплять к другим задачам. Всегда есть возможность создать новую группу со сценарием задачи и переместить внутрь нее все подходящие подзадачи. При использовании липких листочков приходится переклеивать их из одного места ватмана в другое. Для обозначения групп при работе с ватманом удобно применять листочки другого цвета. Группы задач и подзадач могут быть разной степени вложенности – от двух до пяти. На рисунке ниже представлено готовое дерево сценариев с уровнем вложенности равным пяти.

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

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

Шаг 2: поиск недостающих микро-сценариев

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

Шаг 3: фильтрация и расстановка приоритетов

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

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

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

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

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

Комментарии (4)

RSS feed for comments on this post | TrackBack URI

1

Отличная статья, спасибо!
Только вот не совсем понял, по какой причине вы предлагаете производить первоначальную генерацию сценариев “методом “снизу-вверх”, начиная с низкоуровневых операций?

2

Сергей, снизу вверх более удобно так как конкретно мыслить всегда гораздо проще (=быстрее) и более естественно для людей. Да и мозговые штормы хороши для генерации конкретных вещей - легко всего за час втроем сгенерировать/зафиксировать штук 100 микросценариев вокруг некоей деятельности.

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

3

Мысль понял.

> конкретно мыслить всегда гораздо проще (=быстрее) и более естественно для людей.
Думаю, что это индивидуально. Лично мне привычнее размышлять на высоких уровнях абстракции (формализуя эти размышления в документе об образе и границах проекта), а потому уже постепенно спускаться к деталям (user stories, use case, usage scenarios, wireframes), оглядываясь на рамки, зафиксированные ранее (которые, естественно можно раздвинуть при необходимости).

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

P.S. Ещё мне не совсем понятна терминология, то что вы назвали “сценариями” очень похоже на use case, в процессе первого прочтения я даже хотел предложить заменить представленные на рисунках “Деревья” на UML-диаграммы прецедентов.

4

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

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

Оставить комментарий