Даже самые блестящие специалисты допускают ошибки. Это правило особенно очевидно в командной работе. Так или иначе, по мере выполнения проекта накапливаются мелкие допущения, неверные, но принятые из лучших побуждений решения, — а в результате многие часы работы превращаются в негативный опыт пользователя. «Умные» команды устраняют все ошибки до того, как продукт попадет в руки пользователя, используя методику, которая называется разработкой прототипов пользовательского интерфейса. В сочетании с тестированием удобства использования продукта (юзабилити тестирование), прототипы не дают команде сбиться с верного курса.
Зачем создавать прототипы?
Разработка прототипа — средство, позволяющее проанализировать идеи, прежде чем потратить на них время и деньги. Все опытные мастера и инженеры создают образцы своих изделий до того, как начинают что-либо строить. Архитектор создаёт модель из бумаги или картона, либо с помощью виртуальных инструментов. Авиаинженеры используют аэродинамическую трубу. Строители мостов разрабатывают модели для исследования нагрузки. Разработчики ПО и веб-дизайнеры создают модели, имитирующие взаимодействие пользователя с их разработками.
Самая веская причина для создания прототипа — экономия времени и ресурсов. Ценность прототипа заключается в том, что он является внешней оболочкой — как декорации на съёмочной площадке в Голливуде, где построены только фасады зданий. По сравнению с реальным продуктом прототипы просты и недороги в разработке. Таким образом, при минимальном вложении средств можно обнаружить ошибки создателей и юзабилити проблемы, и улучшить пользовательский интерфейс до того, как сделаны значительные инвестиции в окончательную разработку и технологии.
Рассматривая потребности конкретного проекта, можно найти и иные причины для создания прототипа, нежели экономия денег. Может, его цель заключается в изучении новой модели интерфейса? В изменении одной из частей существующей разработки? В исследовании новой технологии? Необходимо с самого начала чётко представлять, что и зачем вы делаете. Если вы приступаете к выполнению задачи с чётко определёнными целями, ваши усилия будут более целенаправленными и эффективными.
Причины создания прототипов подразделяются на три основные категории:
- Проверка идеи. В некоторых командах существуют разногласия, в каком направлении следует развиваться проекту. При помощи прототипа можно показать, что та или иная идея имеет практическую ценность. Прототип может доказать, что концепция работает, продемонстрировать её свойства визуально или интерактивно, и/или подтолкнуть участников команды обдумать проблему с иной точки зрения.
- Изучение дизайна. При разработке интерактивных продуктов единственным способом изучить, как что-либо будет использоваться, является создание экспериментальной модели и взаимодействие с ней. Иногда такая модель нацелена на изучение удобства использования продукта, позволяющее последовательно оценить элементы прототипа. Иногда это просто способ чётко и ясно разъяснить разработчику, как что-то должно работать или выглядеть. Часто разработчик просто экспериментирует в поисках предпочтительного подхода. Любой член команды может использовать прототипы для изучения вопросов дизайна, хотя обычно лучше всего для этого подготовлены разработчики. Изучение дизайна должно быть направлено на решение конкретных проблем, которые были обнаружены в продукте.
- Изучение технологии. Разработчики, исследующие пути решения проблемы, часто пробуют различные приёмы написания кода, чтобы выяснить, который из них подходит лучше всего. Использование COM+, DHTML, Win32 или каких-либо определённых методов кодирования в рамках каждой технологии связано с определенными компромиссами. Иногда прототип позволяет провести зондирование и выяснить, какая технология лучше подходит для поддержки определённой функции пользовательского интерфейса.
Иногда прототипы создаются в силу сразу нескольких вышеперечисленных причин. Если планированию уделяется достаточно внимания, то разработчику, проектировщику и менеджеру проекта предоставляется время для совместной работы над созданием прототипа. В таких случаях чрезвычайно важно чётко определить цели и предполагаемую роль всех участников команды. Каждый должен отчётливо представлять себе цели, возможные издержки и конечный результат.
Кто создаёт прототипы?
Неофициальные прототипы может создавать кто угодно, вне зависимости от его образования или роли в проекте. Создать простой, но эффективный прототип нетрудно. Например, взять растровое изображение из Adobe Photoshop, импортировать его в Microsoft® FrontPage®, программный пакет для создания и управления веб-сайтами, добавить активные кнопки и ссылки. Подобные простейшие прототипы годятся только на определённом этапе и непригодны для моделирования более сложного взаимодействия.
При разработке официального прототипа большой командой, разработчик или менеджер проекта часто сотрудничают с проектировщиком и юзабилити инженером. Вместе они генерируют идеи, создают прототип, который отражает самые удачные из них, а затем передают его в юзабилити лабораторию, чтобы проверить, насколько эффективно он решает задачи пользователя. В случае, когда требуются дополнительные технические консультации, могут привлекаться и разработчики. Часто проектировщик или менеджер проекта сам пишет большую часть скриптов и кода.
Когда создавать прототип?
В зависимости от области применения и степени проработки деталей, прототипы можно создавать на любой стадии выполнения проекта. Чаще всего это бывает на ранних этапах, на этапах планирования или постановки технического задания, до того как разработчики приступят к написанию кода. Именно тогда необходимость всестороннего исследования возможных проблем велика, а инвестирование времени наиболее оправданно. Если прототип создаётся разработчиками, а не менеджером проекта или проектировщиками, планирование времени приобретает ещё большее значение, так как в этом случае необходимо предусмотреть время на создание прототипа в графике разработки. При создании любого пользовательского интерфейса нужно оставлять некоторый запас времени на разработку прототипов.
На поздних стадиях выполнения проекта небольшие прототипы помогают решить сложные технические вопросы и устранить недостатки проектирования. Написанная на скорую руку на языке HTML экспериментальная модель функционирования диалогового окна или веб-страницы может ответить на вопрос разработчика или подсказать участникам команды, каким должен быть результат. В некоторых случаях опытный менеджер проекта или проектировщик могут моделировать при помощи Microsoft JScript® и аппроксимировать большую часть программной логики, которую должны будут проработать разработчики.
Время, необходимое для создания прототипа, очень сильно варьируется в зависимости от области применения и точности, а также от того, каким должен быть конечный результат. Неформальный прототип может создать один человек за пару часов работы, создание более сложных может потребовать целых недель труда всей команды.
Как далеко заходить при создании прототипа?
Не акцентируйте внимание на дизайне при создании прототипа. Делайте ровно столько, сколько необходимо для его функционирования. Не беда, если некоторые кнопки не работают, а текст никогда не обновляется. Главное — возможность реализовать взаимодействия, которые необходимо исследовать.
Вот несколько причин, почему следует внимательно распределять усилия:
- Стоимость создания прототипа. Все хотят минимизировать расходы, связанные с построением прототипа. Поэтому очень важно определить минимальный объём средств, которые можно потратить, не нанеся ущерба эффективности. Поэтому так важно тестирование юзабилити, так как оно может точно определить части пользовательского интерфейса, которые потребуют больших усилий. Даже без проведения такого тестирования надо чётко определить, какие пользовательские проблемы должны быть решены, какие параметры должны быть улучшены.
- Ограниченный жизненный цикл. Прототипы должны иметь чётко определённый жизненный цикл. Надо определить какова конечная цель. Устроить презентацию на командной пятиминутке? Провести совещание по поводу окончательного анализа проекта? Сделать разбор технического задания? Провести юзабилити тестирование продукта? Убедиться, что разработка решит проблему пользователя? Как только достигнуты конкретные цели, прототип следует отложить в сторону. Код прототипа или его растровое изображение должны быть на время забыты. В исключительных случаях часть кода или наглядные элементы позднее используются в продукте, но рассчитывать на это не стоит.
- Риск увлечься. Показ прототипов разработчикам и другим членам команды не всегда идет на пользу. Слишком сложный и детально разработанный прототип, захватывающие воображение интерфейсы и анимация, могут чрезмерно увлечь людей. Всегда следует отдавать отчёт, насколько далеко можно зайти и насколько серьёзно должно восприниматься то, что включено в прототип.
Определение сферы охвата прототипа
Как только оговорены основные моменты, на которых следует сосредоточиться при создании прототипа, надо задуматься о следующем:
- Нужды потребителя. Если вы начинаете с осмысления ключевых вопросов или нужд вашего пользователя (возможно, юзабилити инженер может подкинуть пару хороших идей), значит, вы имеете представление, какие детали требуют наибольшего исследования.
- Задачи тестирования на удобство использования. Если прототип создаётся для проведения юзабилити тестирования продукта, следует обсудить с юзабилити инженером, какие конкретные задачи должны быть решены во время тестирования, и отталкиваться от этих задач при создании прототипа.
- Командный вклад. Беседуйте с ключевыми разработчиками по мере того, как идеи относительно создания прототипа начинают обретать контуры. Совместными усилиями надо определить, что представляется разумным, что является возможным, а что вовсе неприемлемо для будущего релиза. В некоторых случаях можно выйти немного за рамки того, что разработчики считают возможным относительно какого-либо аспекта разработки. Но только если этот аспект является ключевым моментом, и выход за рамки будет мотивировать команду. Однако не следует делать этого по отношению ко всем аспектам разработки. Пытаясь расширить границы возможного, очень легко деморализовать команду. Если требуется вдохновить коллектив наглядным показом возможных вариантов, можно пойти на этот шаг. Однако если необходимо определить конкретные изменения для следующего релиза, усилия следует сосредоточить на этих изменениях. Необходимо убедиться, что они вносятся модульно, чтобы разработчики видели путь построения разработки.
- Ширина или глубина? При создании больших прототипов следует определиться что предпочесть — ширину или глубину. Прорабатывать поверхностно все функции, либо выбрать одну и разрабатывать прототип, реализовывая все её возможности? Если по неразумению сделать это одновременно, получится громоздкий прототип, который сложно модифицировать и жалко выкинуть.
Как сделать прототип гибким?
Один из способов создания успешного прототипа — сосредоточиться на умном проектировании. Предусмотрев возможность реализации одной частью кода прототипа нескольких разных идей, можно сделать его более эффективным. Вместо создания пяти разных прототипов, можно разработать всего один, способный выполнять разные задачи.
Где лучше расположить панель инструментов — слева или вверху? Показывать на главной странице десять объектов или двадцать? Хороший прототип имеет что-то вроде встроенной панели опций, которая позволяет изменять параметры его работы и внешний вид. Её следует сделать скрытой, чтобы участники юзабилити тестирования случайно не обнаружили её во время испытаний.
Сложность заключается в том, чтобы прототип оставался простым, но в то же время достаточно полезным при показе участникам команды различных вариантов, которые надо обдумать и получить обратную связь.
Прототипы и бета-релизы: в чем разница?
Бета-релизы не могут считаться прототипами, потому что они являются законченными инженерными решениями. Если в какой-либо из функций бета-релиза найдена критическая ошибка, нельзя просто взять и выбросить часть кода, даже если это было бы в интересах продукта. Разработчики, тестировщики и проектировщики уже потратили своё время, и соблазн оставить всё, как есть, очень велик. Бета-версии, конечно же, помогают найти ошибки и дефекты, но они редко бывают полезными при проведении контролируемых исследований ценности того или иного направления при проектировании.
Инструменты и технологии
Существует несколько разных инструментов и технологий, которые можно использовать для создания прототипов. Все они имеют свои достоинства и недостатки. Прежде чем решить, на каком инструменте или технологии следует остановить выбор, необходимо уточнить, для решения какой задачи проектирования разрабатывается прототип, а также определить цели его создания.
- Microsoft Visual Basic. Это самая быстрая технология для создания прототипов пользовательских интерфейсов под Windows. Объект веб-браузера упрощает интегрирование пользовательского интерфейса, написанного на HTML, в стандартные компоненты Windows. Но верно и то, что разработчик, имеющий опыт работы с Microsoft Visual Studio, может создать пользовательский интерфейс на C/C++ быстрее, что создаёт соблазн повторно использовать код прототипа пользовательского интерфейса в коде конечного продукта. Нужно ясно понимать, что черновой прототип пользовательского интерфейса сильно отличается от конечного кода. Менеджер проекта должен удостовериться, какого рода код создаётся на конкретном этапе, и понимать, что именно может быть отброшено.
- Macromedia Director или Flash. Это один из самых популярных среди проектировщиков инструментов для создания прототипов пользовательских интерфейсов. Он наиболее ценен при разработке прототипов мультимедийных приложений или нестандартных графических интерфейсов, а также очень хорош при создании прототипов, которые требуют значительного использования анимации. Но недостаточная гибкость делает его неуклюжим по сравнению с Visual Basic при создании пользовательских интерфейсов под Windows. Однако искусный пользователь Director?а может генерировать интерфейсы под Windows или для веб-страниц без всяких проблем.
- HTML. Microsoft® FrontPage® и прочие HTML-редакторы позволяют создавать несложные прототипы. Для выражения своей идеи часто приходится создавать изображения, чтобы проиллюстрировать последовательность действий пользователя, и импортировать их во FrontPage®. Затем можно соединить страницы ссылками и сымитировать взаимодействие с программой. JScript и DHTML обеспечивают новый уровень возможностей, позволяя использовать очень сложную программную логику и механизмы взаимодействия. При использовании HTML для создания прототипа сайтов (так же, как и в вышеуказанном примере с кодом на C/C++) не следует попадаться в ловушку и считать сделанный на скорую руку код прототипа окончательным.
Впервые опубликовано в «Юзабилити Бюллетень, выпуск 5, апрель 2007».