Алан Купер - Психбольница в руках пациентов Страница 57

Сценарии

По мере детализации проектирования эффективность сценариев повышается. Наши персонажи проходят через эти сценарии, словно актеры, читающие роли, что позволяет проверять корректность проектирования и выдвинутые предположения. Неудивительно, что наш сценарный процесс часто сравнивают с игрой по Станиславскому – актер должен вжиться в роль, знать то, что знает персонаж, чувствовать то, что чувствует персонаж. Мы стараемся думать так, как думает он. Мы забываем о собственном образовании, способностях, подготовке, инструментах и думаем, что обладаем лишь данными и биографией персонажа. Поскольку мы проектировщики, а не актеры, без контекста и конкретных деталей может быть нелегко, поэтому сценарии оказываются большим подспорьем. Зная, к примеру, что Бетси пытается создать сайт для страховой компании, нам проще ставить себя на ее место. И это не так странно, как может показаться. Ведь программисты ставят себя на место своих компьютеров. Программисты привычно описывают действия компьютера от первого лица, они говорят: «Я обращаюсь к базе данных, а затем сохраняю записи в буфере». Человек говорит «я», но всю работу на самом деле выполняет компьютер. В роли компьютера человеку проще симпатизировать потребностям машины в процессе написания кода.

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

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

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

Повседневные сценарии

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

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

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

Обязательные сценарии

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

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

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

Сценарии исключительных ситуаций

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

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

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

Адаптирующийся интерфейс

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

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

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

В Мiсrоsоft Word, к примеру, стандартная панель инструментов содержит пиктограммы для загрузки документа, закрытия и печати текущего документа. Перечисленные задачи выполняются с разумной частотой, и присутствие пиктограмм оправданно. Однако здесь же, рядом, располагаются пиктограммы, генерирующие схему документа и внедряющие в документ электронные таблицы. Мiсrоsоft поместила эти пиктограммы в Основном рабочем пространстве, чтобы мы смогли оценить мощь Word. К несчастью, большинство пользователей к этим функциям так никогда и не обращаются, а если и обращаются, то вряд ли часто. Этим функциям просто не место на панели инструментов, потому что панель инструментов – это идиома интерфейса, обеспечивающая доступ к самым востребованным функциям.

Вечные середняки

Обычно самые мощные инструменты позволяют нам понять, представить личности наших пользователей, вжиться в них. Одну умозрительную модель мы применяем постоянно – она называется «вечные середняки». Большинство пользователей – не новички и не эксперты, они просто вечные середняки. Помните Рупака, Шэннон, Декстера и Роберто из главы 9, где речь шла об уровне подготовленности? Квалификации этих людей совершенно различны, но все четверо являются вечными середняками.