В предыдущих главах мы обсудили концепцию персон и убедились в важности преобладания целей над задачами. Только после того, как мы определили пользовательских персон и выяснили их цели, мы можем переходить к изучению задач, будучи уверенными, что они не нарушат процесс проектирования. Наш метод для объединения задач в единое целое мы называем «сценариями». Сценарий – это краткое описание действий пользователя, которые он предпринимает при взаимодействии с программным продуктом, пытаясь достигнуть своих целей. Далее в этой главе я остановлюсь на сценариях более подробно, а также расскажу о некоторых других инструментах, полезных при проектировании. Я также опишу кейс, из которого можно будет понять, как эти инструменты, в частности сценарии, работают на реальных проектах.
По мере того как в ходе процесса проектирования внимание смещается от общих концепций к проработке деталей, эффективность сценариев также повышается. Мы разыгрываем эти сценарии с нашими персонами, будто с актерами, изучающими свою роль, и через это проверяем правомерность наших предположений в отношении проектирования. Ничего удивительного, что такой процесс работы с нашими сценариями напоминает подход актера к постижению характера своего героя, когда актер вживается в образ персонажа, чтобы увидеть мир его глазами и ощутить его эмоции. Мы тоже пытаемся думать так, как это сделала бы наша персона. Мы на время забываем о собственном уровне образования, способностях, степени подготовки и методах, которыми владеем, воображая себя человеком, обладающим опытом и восприятием, присущим персоне. Учитывая, что мы являемся проектировщиками, а не актерами, воплотить подобное без понимания контекста и знания нюансов бывает нелегко, потому сценарии оказываются мощным подспорьем. К примеру, если мы обладаем информацией о том, что Бетси создает веб-сайт для страховой компании, нам становится гораздо проще проникнуть в самую ее суть. Это может показаться странным, однако на самом деле это вполне нормальная ситуация. Это так же, как программисты проникают в самую суть компьютеров. Для программистов становится привычным даже описывать действия компьютеров от первого лица, например, от них можно услышать: «Я получил доступ к базе данных и теперь сохраняю записи в своем кэше». Хотя они употребляют местоимение «я», не они выполняют все действия, а компьютер. Однако, ставя себя на место компьютера, им легче понять, что происходит у него внутри и что ему требуется, а затем реализовать это в коде.
Сценарии обычно составляются исходя из информации, полученной на первом этапе проведения исследования. Из интервью с пользователями, а также в ходе прямого наблюдения за их действиями о задачах можно узнать довольно много. Целям свойственна стабильность, они практически не меняются, а вот задачи изменчивы, и нередко при компьютеризации деятельности часть этих задач отпадает. Проходя этап разработки сценариев, мы традиционно отыскиваем задачи, которые существуют лишь потому, что так исторически сложилось, а затем, по мере возможности, избавляемся от них.
Качественный сценарий в большинстве случаев является таковым благодаря ширине охвата, нежели глубине детализации. Другими словами, более важно, чтобы в сценарии присутствовало описание какого-либо процесса от начала и до конца, чем подробное описание каждого шага с мельчайшими нюансами.
Здесь важно прорабатывать только те сценарии, которые будут способствовать процессу проектирования, и не углубляться в исключения. Обычно мы создаем сценарии двух видов, хотя их может быть и больше, – это сценарии на основе ежедневных действий и сценарии на основе обязательных действий.
Сценарии ежедневных действий представляются наиболее важными и полезными. В них описываются самые частые действия пользователя. Например, для систем отслеживания ошибок и неисправностей в программах типичным сценарием, выполняемым ежедневно, будет, соответственно, поиск ошибок и заполнение отчетов об ошибках, найденных в текущем периоде. Любой специалист технической поддержки выполняет две эти задачи по несколько раз каждый день.
В целом у большинства пользователей количество таких описанных ежедневных сценариев будет весьма ограниченным. Обычно число таких сценариев не превышает одного или двух. Больше трех их бывает крайне редко.
Сопровождение сценариев ежедневных действий в пользовательском взаимодействии должно быть невероятно качественным. Новым пользователям требуется осваивать такие сценарии очень быстро, а потому нужна хорошая встроенная система обучения. Это значит, что пояснения к применению различных функций должны быть описаны прямо в интерфейсе самой программы. Тем не менее чем чаще пользователь работает с программой, тем меньше ему в дальнейшем требуется использовать эти пояснения и инструкции. Вместо этого вскоре возникнет потребность в освоении быстрых сочетаний клавиш. Более того, еще чуть позже, по мере приобретения опыта работы с программой, у пользователей возникнет и потребность в индивидуальной подстройке программы под их персональный стиль действий с учетом личных предпочтений.
В сценариях обязательных действий описываются все действия пользователей, которые нужно исполнять непреложно, однако нечасто. К этому виду сценариев можно отнести такие действия, как чистка баз данных и создание исключительных запросов. Взаимодействия на основе обязательных действий также требуют качественного обучения. Тем не менее в данном случае пользователь никогда не перерастет их и не станет применять параллельные действия вроде сочетаний клавиш. Ввиду нечастого использования этих операций пользователь подстроится под настройки программы и не потребует персонализации. Таким образом, разработчики будут освобождены от необходимости дорабатывать этот вид взаимодействия до того уровня, который требуется при использовании сценариев ежедневных действий. Приблизительно по той же причине салон нового «Ягуара» отделан со всей роскошью, в сравнении с грубой металлической окантовкой его моторного отсека.
Несмотря на то что почти у всех программных продуктов количество сценариев обязательных действий невелико, их количество все же превышает число ежедневных сценариев.