Почему я не создаю документов с пользовательскими сценариями на этапе проектирования

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

В 2018 году на одном из своих вебинаров я рассказывал, как составлять пользовательские сценарии «на лету». Это очень поверхностное касание темы, но оно вполне может пригодиться тем, кто продаёт проектирование интерфейсов. Ссылка на нужную минуту вебинара на ютубе.

Для чего они создаются?

1. Чтобы продемонстрировать клиенту, что мы с ним оба одинаково понимаем, как должны вести себя пользователи в будущей системе, до того, как браться за создание макетов;
2. Чтобы создание этих самых макетов основывалось на этом понимании, а не на фантазиях проектировщика.

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

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

Затем по этому согласованному документу я создаю интерактивный прототип, где можно покликать по ссылкам и пройтись по пользовательским сценариям по-настоящему.

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

Что мне нужно делать в такой момент? Говорить клиенту: «Вы же согласовали со мной пользовательские сценарии, давайте придерживаться договорённостей?». Конечно, нет. Я вношу правки в получившийся результат — и клиент остаётся довольным. А зачем я тогда тратил время и деньги клиента на создание первоначального документа? Непонятно.

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

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

Что я потерял в результате такого решения?
— Деньги за создание дополнительного документа.

Что я получил?
— Перестал тратить время на создание дополнительного документа;
— Экономию нервов на этапе, когда клиент даёт обратную связь по прототипу, которая не соответствует пользовательским сценариям, о которых мы договаривались;
— Более довольных клиентов, т.к. работа сдавалась быстрее и с меньшим количеством дискуссий.

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

Когда я бы всё-таки стал создавать документ с пользовательскими сценариями?
— При автоматизации производства, в рамках документа с описанием бизнес-процессов;
— Когда на стороне клиента есть специалист достаточно высокого уровня, чтобы согласовывать подобные документы. И при этом он сам просит написать пользовательские сценарии перед созданием прототипа;
— Если бы я был ещё совсем неопытным проектировщиком, и документ давал бы мне опору в процессе работы (кстати, при этом я бы вполне мог не показывать его клиенту).

Стоит ли отдельно рассказывать, почему я также отказался от документа с описанием целевой аудитории (персонажей)?