Сценарии ежедневных действий

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

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

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

Сценарии обязательных действий

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

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

Сценарии исключений

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

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

* * *

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

Адаптивный интерфейс

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

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

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

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

Вечная середина

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

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

 

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

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

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

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

 

 

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

 

 

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

 

 

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

* * *

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