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

В предметной области сервис-дизайна существует идея карты путешествия пользователя (Customer Journey Map). Однако эти карты делаются настолько по-разному, что найти чётко описанную методику не представляется возможным (Калбах, 2016). Типичные переживания начинающих касаются того, правильно ли они делают эти карты, верно ли выявляются точки опыта. С выходом этой книги оснований для переживаний остаться не должно. В ней представлен метод, раскрывающий и совершенствующий идею карты путешествия пользователя, объединяя её с сильными сторонами подходов к описанию разветвлённых процессов. Подход изложен во всех деталях с пошаговым алгоритмом, что поможет как тем, кто ищет чёткого руководства по линейным картам путешествий, так и тем, кто хочет охватить единой схематизацией все сквозные процессы в своём сервисе.

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

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

Четвёртая глава в подробностях рассматривает основные элементы карты, исключая события.

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

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

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

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

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

Под аббревиатурой UX (User Experience) скрывается проектирование пользовательского опыта. Эта междисциплинарная область знаний, увы, имеет высокую планку входа для новичков и до сих пор недостаточно стандартизирована и превращена в учебники и справочники. Принято считать, что область проектирования взаимодействия является уделом узких специалистов – UX-проектировщиков. Специалист в этой области достигает зрелости по прошествии десятилетий, что представляет собой непозволительную роскошь в современном мире. Я считаю, что знаниями по проектированию опыта либо должны обладать все в команде, либо специалистами в этой области важно становиться гораздо быстрее.

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

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

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

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