Фронт-сцена, бэк-сцена и поддерживающие процессы

Что это такое

У сервиса два слоя. Фронт-сцена — всё, что видит клиент: экран, курьер, человек на телефоне. За ней стоит бэк-сцена, то есть работа, благодаря которой это становится возможным: сборка заказа, очередь, согласование, ночная пакетная задача. Поддерживающие процессы — системы, которые держат бэк-сцену в рабочем состоянии: план по персоналу, поставки товара, маршруты эскалации.

Почему это важно

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

Ключевые идеи

Проведите линию и проверьте, что она держится

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

Фронт-сцена:  "Ваша посылка в пути"   (уведомление)
Бэк-сцена:    посылка отсканирована на складе
Поддержка:    задача синхронизации сканера склада каждые 15 минут
Сбой:         скан в 18:40, синхронизация в 19:00, 20 минут сообщение неверно

Если обещание на фронт-сцене не имеет названного действия на бэк-сцене, это пожелание.

Считайте пропускную способность, а не только поток

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

Приход 09:00-10:00    420 заявок
Агентов на линии      6  x  8 заявок/час = 48
Очередь в 10:00       372

Впечатление клиента от сервиса во многом и складывается из ожидания, поэтому очередь — поверхность проектирования.

Сбои тоже проектируют

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

Назначьте человека на каждую передачу

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

Практика

Нанесите на карту один сервис и отметьте стыки

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

Готово, когда: у каждого шага фронт-сцены рядом стоит действие бэк-сцены, а у каждой обведённой передачи назван владелец.

Напишите один путь сбоя

Выберите шаг, который скорее всего откажет, и напишите для него сценарий: что видит клиент, что видит агент и что клиенту скажут в первую минуту.

Готово, когда: в сценарии сбоя названы сообщение, канал и ответственный человек, и ни один шаг не говорит «обрабатывается автоматически».

Частые ошибки

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

Что читать дальше

Сервис-дизайн (03-design-ux/38-service-design) — трек, которому принадлежит эта глава.
Картирование пути пользователя (03-design-ux/22-journey-mapping) — сквозная схема, под которой лежит этот слой.
Информационная архитектура (03-design-ux/09-information-architecture) — структурирование того, что клиенту нужно найти по пути.
Юзабилити-тестирование (03-design-ux/33-usability-testing) — проверка моментов, которых клиент действительно касается.