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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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