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

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

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

* * *

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* * *

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

Представь себе!

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

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

Словарь

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

Если нет слов для выражения идеи, то ее практически невозможно передать. И определенно невозможно такую идею проанализировать и разложить на составляющие до достаточного уровня технических деталей, чтобы реализовать ее на языке C# или Java.

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

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

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

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

Языковой прорыв

Прежде всего, хороший словарь делает общение более эффективным. Однако создание терминологии иногда имеет и другой очень важный эффект. Время от времени нам приходится работать с командами, в которых определенные термины уже стали частью культуры. Хороший пример – фраза Мiсrоsоft «Embrace the Internet». Подобные фразы и слова могут иметь почти религиозное значение и произноситься с оттенками благоговейного трепета. Такое благоговение приводит к неспособности разобрать значение слова и повторно изучить его в свете новых императивов проектирования. Означает ли фраза, что следует идти навстречу браузерам, или же HTML, или же только протоколам ТСР/IР? Эти священные слова – забор вокруг храма. Растоптав священные верования клиента, мы не продвинемся в процессе проектирования. Поэтому мы разбиваем процессы, задачи, программы на четко определенные обособленные фрагменты и назначаем им новые имена, не имеющие унаследованного смысла. Эти новые имена, обычно еще и шутливые, и такое легкомыслие позволят «пробить» серьезные мины участников.

Реальность смеется последней

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

Разумеется, встречаются и настоящие ограничения, которые обойти действительно невозможно, однако в попытках это сделать приобретается ценный опыт. Даже если мы не можем изящно обойти ограничение, наше путешествие по тупиковому маршруту может пролить свет на какую-то не замеченную ранее возможность. Этот процесс основан на работе Эдварда де Боно, посвященной нестандартному мышлению^[34].

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

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

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

Пример: Logitech Scanman

Наш инструмент «представь себе!» оказался особенно полезным в одном крупном проекте. Подразделение корпорации Logitech, занятое производством сканеров, пригласило нас для участия в проектировании программного обеспечения для совершенно нового поколения настольных сканеров, ориентированных на рынки домашнего и малого офисов.

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

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

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

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

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

Как обычно, мы начали процесс с создания набора персонажей. Расскажу о том, как мы сконструировали этот набор.

Магазинная цена сканера была около $150. Для массового продукта это был достаточно мощный сканер с высоким разрешением и цветопередачей, однако до уровня профессиональных планшетных сканеров, стоивших обычно от $800 до $1000, он не дотягивал^[35]. Всем было ясно, что основной рынок сбыта продукта формируют пользователи в домашних и малых офисах, известных под собирательным называнием SOHO (small office, home office).