Пришло время рассказать, что такое сценарии и как о них думать.
Что называют «сценариями» по ошибке
Словом «сценарий» в интерфейсах часто называют всё подряд: последовательность нарисованных макетов, отдельное состояние экрана, конкретное нажатие на кнопку.
Например, дизайнер презентует работу: «Мы здесь проработали сценарий, когда человек попадает на этот экран; а вот сценарий, когда попадает на другой; а вот ещё сценарий, в котором нажимает такую‑то кнопку». Это не сценарии, это просто экраны или состояния интерфейса. Они, конечно, могут использоваться в каком настоящем сценарии, но тут не сказано в каком.
Или вот другой дизайнер спрашивает: «У меня в интерфейсе получается слишком много сценариев. Значит, я плохо его спроектировал?» Но сценарии не могут «получаться» в процессе проектирования; они ему предшествуют. Мы сначала понимаем, какие задачи и в каких обстоятельствах человек будет решать, а затем уже берёмся проектировать интерфейс, который позволит ему это сделать.
Реакции системы на каждом шаге, ошибки, лоадеры и подобные детали не нужно описывать не потому, что они слишком мелкие, а потому что они вообще относятся не к сценарию. Им место в документации к макетам при передаче в разработку.
Сценарии — это не описание того, что нарисовано, а инструмент понимания задачи.
Примеры сценариев
Когда мы говорим о сценариях, мы имеем в виду то, что происходит в реальности пользователя, когда он обращается к нашему продукту. С какими мыслями, ожиданиями, ограничениями, данными он приходит, какую задачу он хочет решить, к какому результату прийти.
Например, мы делаем программу для врача. Важный сценарий в работе врача — приём пациента:
Пациент пришёл, что‑то рассказал, показал где болит, принёс результаты анализов. Врачу нужно посмотреть историю болезни и карточку пациента, зафиксировать результаты приёма, выписать рецепт, заключение или направление к другому врачу. Возможно, распечатать что‑то из этого на бумаге и передать сведения во внутреннюю систему клиники.
Наверняка есть какие‑то ещё сценарии, скажем, сдача отчёт о работе за неделю или инвентаризация оставшихся бинтов и ваток. Вот под эти сценарий мы и делаем интерфейс.
Или мы проектируем систему управления проектами. У менеджера может быть такой сценарий:
С утра мне нужно понять общее состояние проектов и спланировать ближайшие действия. Увидеть, за какие проекты я отвечаю, какой у каждого статус, где требуется вмешательство, где не хватает исполнителей или других ресурсов. На основе этого я смогу решить, кому написать, какие встречи поставить и чем заняться в ближайшие дни.
Снова, есть куча других сценариев в работе менеджера, а интерфейс поможет ему через них пройти.
Язык сценариев
В сценарии вообще не упоминается интерфейс. Мы не пишем: «врач нажимает кнопку» или «врач открывает окно»; не пишем: «менеджер настраивает уведомления» или «включает режим просмотра проектов».
Сценарий всегда описывается на языке предметной области человека, который приходит в наш продукт. Врач принимает пациента, изучает его историю, даёт заключение. Менеджер оценивает состояние проектов, находит проблемы, планирует действия.
Если в тексте сценария встречаются кнопки, окна, экраны, режимы и другие интерфейсные термины, сценарий написан плохо или это вообще не сценарий, а просто описание интерфейса.
То же самое в навигации: посетитель не «находит иконку на директивном указателе», а приходит на концерт, опаздывает, сдаёт одежду, находит своё место в зале, ищет буфет или туалет.
Иерархия сценариев
Приём пациента, который обратился впервые, отличается от приёма пациента, который уже был у этого врача ранее и принёс новые анализы или заключения других специалистов. Также ход приёма может отличаться в зависимости от жалоб: в одном случае врачу нужно найти в компьютере какие‑нибудь снимки, в другом — посмотреть расписание коллеги, чтобы направить пациента к нему.
Такие вариации можно описывать как несколько самостоятельных сценариев: «первый приём», «повторный приём», «приём пациента с такими‑то жалобами», «с сякими‑то». Но если сценарии различаются лишь отдельным фрагментом, удобнее выделить этот фрагмент в подсценарий. Тогда основной сценарий описывает приём в общих чертах, а внутри него есть вариации.
Например, называем сценарий «пациент жалуется на боль в пятке, нужен пятолог» и описываем там только кусок того, что нужно врачу в этом случае. Полезно так оформить себе документ, чтобы было видно, что это не полный самостоятельный сценарий, а лишь небольшой кусочек в общем сценарии приёма:
Как‑нибудь отдельно стоит рассказать о функциональной иерархии продукта
Приём пациента
Пациент пришёл первый раз, нужно внести его в систему
Пациент уже был, нужно посмотреть предыдущие анализы и заключения
Пациент жалуется на боль в пятке, нужен пятолог
Пациент жалуется на боль в пупке, подключаем пупоскоп
Пациент жалуется на боль в плече, снимаем плечеграмму
Принтер сломался во время печати заключения
Отчёт за неделю
...
Инвентаризация
Инвентаризация бинтов
Инвентаризация ваток
Как‑нибудь отдельно стоит рассказать о функциональной иерархии продукта
В большом продукте структура может быть и глубже. В ней ориентироваться проще, чем в линейном списке из десятков похожих сценариев.
Начало работы над сценариями
Как я сказал выше, сценарии — это инструмент понимания задачи.
Когда клиент просит сделать интерфейс для его продукта, стоит расспросить его о продукте. Зачем он нужен? Кто будет им пользоваться, в какой ситуации? Что эти люди уже знают в момент обращения к продукту, чего не знают, какие у них возникают вопросы и трудности?
Полезно представить это прям как события, происходящие в физическом мире: где находится человек, как устроено его рабочее место, сидит он, стоит или идёт, свободны ли у него руки. Возможно, он постоянно переключается между несколькими рабочими программами; возможно, одновременно разговаривает с кем‑то по телефону; возможно, использует сервис на ходу и лишь время от времени смотрит в экран. Всё это важные части сценария и сильно влияет на будущий интерфейс.
Клиенты иногда пытаются сразу говорить на языке интерфейса: «Нам нужен такой‑то экран», «Здесь должна быть такая‑то кнопка», «Давайте предусмотрим область с такой‑то настройкой». В этот момент важно вежливо вернуть разговор к сути задачи: попросить не придумывать интерфейс раньше времени, а рассказать о самой ситуации, в которой к нему будут обращаться. Всегда держите в голове требования к языку сценариев, чтобы не сбиться.
Задача проектировщика — внимательно собрать все эти ответы, а затем привести их в порядок: отредактировать, выделить подсценарии.
Если вы работаете над собственным продуктом, те же вопросы нужно задать самому себе и так же внимательно на них ответить.
Роли и персоны
Медицинской программой могут пользоваться обычные врачи, лаборанты и медсёстры, главврач и даже бухгалтер клиники. Системой управления проектами могут пользоваться исполнители, менеджеры, руководители. У разных пользователей разные задачи, зоны ответственности, права и возможности. Таким образом, в сложном продукте сценарии делятся ещё и по ролям пользователей.
В каждом сценарии важно ясно представлять пользователя, а поэтому стоит описать всё существенное о нём: задачи, знания, полномочия, критерии решений, трудности и заботы. Если представитель каждой роли участвует во многих сценариях, отдельно описать сами роли.
В литературе по проектированию интерфейсов встречается идея «персон»: вместо функционального описания ролей предлагают придумать псевдонастоящих людей — дать им имена, биографии, вкусы, увлечения, любимую музыку и еду:
Леночка любит кабачки, группу «Айова» и гулять на рассвете. У неё татуировка с кошачьими лапками и она немного заикается.
Анатолий Петрович рыбачит каждые выходные и обожает своего пса Артура. У него хриплый голос из‑за курения, и он много матерится, но в душе он очень добрый.
Предполагается, что эта ахинея помогает проникнуться к пользователям эмпатией и лучше для них проектировать.
Придумывание персон кажется мне клоунадой, тратой времени и карго‑культом. Эмпатия сама по себе не помогает проектировать интерфейсы. Я видел много очень чутких и эмпатичных людей, которые с искренней заботой о пользователей и большим старанием проектировали пыточные интерфейсы и даже не понимали этого.
Важно разобраться в пользователях именно с точки зрения их взаимодействия с продуктом. Подробности их вымышленной личной жизни не имеют к этому отношения.
Количество сценариев и приоритеты
Когда вы начинаете интерфейсный проект и знакомитесь со сценариями, вы можете столкнуться с тем, что их слишком много. В продукте куча ролей; у каждой роли — десятки задач плюс их вариации. Чем глубже вы погружаетесь, тем больше открывается новых нюансов и ветвлений в этой бездне.
Тогда нужно сознательно провести границу: да, существует много других сценариев, которые мы пока не обсудили. Но мы уже обсудили два десятка. Вероятно, это ключевые, раз они пришли в голову раньше других? Давайте договоримся, что интерфейс обязан хорошо их покрывать в первой версии, а к остальному вернёмся позже. Да, наша медицинская программа пока не будет уметь автоматически прогнозировать расход бинтов на следующий месяц на основе статистики за предыдущий и формировать заказ, хотя было бы круто. Ну значит пока сделают как‑то в другом месте и вручную, не беда.
Отказаться от части сценариев — это продуктовое решение, и его нужно принимать вместе с клиентом. Но важно, что поскольку обсуждение ведётся на языке предметной области, граница проходит в области смысла продукта, а не того, как организованы окна, меню и разделы.