Джон Шраг: Сила точных целей

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

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

Несколько признаков хороших целей

О хороших целях знают все члены команды

Если кто-то не знает, какова цель работы, то он основывается только на своих предположениях.

Всегда можно проверить, достигнута ли цель

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

Хорошие цели конкретны, точны

Точные цели содержат числа, диапазоны значений, условия использования и т. п. Сравните: «Функциональность X должна быть такой, чтобы пользователи ее быстро нашли и смогли использовать без особого труда» и «За одну минуту новички должны найти функционал X и признать — это то, что нужно для завершения задачи. Саму задачу они должны выполнить самостоятельно еще за 3 минуты».

Хорошие цели реальны и достижимы

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

Хорошие цели практичны

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

Хорошие цели не зависят от интерфейсных решений

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

Хорошие цели — поддержка для бизнеса

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

Типы целей проектирования

Обнаруживаемость (discoverability). Как быстро пользователи должны найти функционал? Сколько неверных путей допустимо при поиске? Нормально ли, что нужно просмотреть помощь, чтобы найти нужное?

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

Предотвращение ошибок (error avoidance). От каких ошибок пользователя нужно уберечь? Сколько минут во время выполнения одной задачи пользователь может пытаться решить возникшую проблему?

Исправление ошибок (error recovery). Сколько времени должно уйти у пользователя, чтобы обнаружить ошибку? Насколько быстро он должен ее исправить? Много ли усилий нужно затратить на ее исправление?

Эмоции (emotional response). Какие эмоции должен вызывать продукт у пользователей? А какие не должен?

Выполнение задач (task completion). Какие задачи пользователи должны суметь выполнить? Сколько времени и информации им для этого понадобится? Какое максимальное количество ошибок они могут совершить при выполнении задачи?

Предпочтения (preference). При сравнении разных продуктов или интерфейсов — должны ли пользователи предпочитать один другому? При каких обстоятельствах, какие целевые группы и для каких задач?

Запоминание (retention). Много ли информации после изучения системы должны усвоить пользователи? Как долго они должны это помнить, если не будут пользоваться продуктом?

Эффективность (efficiency). Как быстро пользователи могут выполнить определенный объем работы? Задачи какого типа? Есть ли ограничения на объем информации? В каких условиях (прерывание, шум, вибрация и т. п.) проходит работа?

Взаимодействие (engagement). Должны ли пользователи постоянно находиться в работе, в «состоянии потока», используя вашу программу?

Обратная связь (responsiveness). Нужно ли пользователю при работе с продуктом получать мгновенный ответ в режиме реального времени? Какие виды обратной связи нужно предусмотреть? Подразумевает ли задача устойчивость интерфейса к прерываниям?

Пример из практики Д.Шрага: цели для Alias ImageStudio

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

Моя компания многие годы разрабатывала программы, которые предназначены, в первую очередь, для промышленных и автомобильных дизайнеров и позволяет им создавать и обрабатывать компьютерные модели. Мы решили разработать новую, более легкую для освоения программу, позволяющую делать «простую визуализацию (рендеринг)». Пользователи сумеют создать 3D-модель в любой программе и потом изготовить фотореалистичный рендеринг с помощью нашей.

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

Сформулировав вопрос, мы тут же нашли интересные ответы, как-то: «Любой человек [целевой пользователь — прим. пер.] сможет работать с программой в первый же день» или «Любой человек сможет выполнить 5 задач в один день».

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

Во время юзабилити-тестирования мы попросили участников сделать качественный рендеринг модели, используя прототип системы. После мы не подсказывали им, только если они совсем не запутывались и не могли сами ничего сделать.

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

Цели мы использовали, чтобы выявить самые важные проблемы, мешающие пользователям быстро завершить свой первый рендеринг в нашей программе. Однако чем ближе разработка двигалась к завершению, тем яснее становилось: есть несколько проблем, которые нельзя решить «косметическими» исправлениями интерфейса.

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

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

1. Пользователи просмотрят ролик в первые 15 минут работы с программой.
2. Пользователи смогут запомнить информацию, иллюстрированную видео, и применить ее в деле.
3. Пользователи смогут найти и просмотреть ролики еще раз, если это потребуется.

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

• мог применять ее (использовать программу верно в описанном случае),
• сталкиваясь с новым понятием, не переспрашивал, что это такое, а вспоминал, что видел это в ролике и стремился просмотреть его еще раз.

Мы провели тестирование так же, как в прошлый раз. Сразу после старта программа предлагала пользователю просмотреть видеоролики. Если участник не включал в ближайшие 15 минут ни одного видео, мы отмечали, что первая цель не достигнута. Затем, прежде, как продолжить, мы просили его найти и просмотреть ролик — чтобы проверить вторую и третью цели. Если участник посмотрел видео при старте, но никогда после к нему не возвращался, в конце тестирования мы просили его найти ролик снова, чтобы получить данные для третьей цели.

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

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

Об авторе Джон Шраг (John Shrag) работал дизайнером интерфейсов последние 12 лет, большую часть времени занимался продуктом Alias, приобретенным компанией Autodesk в 2006 году. Джон специализировался на разработке интерфейсов для специалистов творческих профессий, он помог создать 3D-элементы для графических и промышленных дизайнеров, типографов, автомобильных стилистов, аниматоров, кинопроизводителей и архитекторов.

Опубликовано: UX User Experience 2008 Volume 7, Issue 1