Чем сервис-дизайнеры отличаются от обычных и зачем они нужны бизнесу

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

Что выигрывает бизнес при привлечении сервис-дизайнеров

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

Успейте купить корпоративный пакет COSSA-2025 со скидкой!

Cossa анонсирует главный рекламный формат на весь 2025 год: сразу 8 различных опций.

Пакет идеально подходит для онлайн-сервисов, стартапов, интернет-компаний и digital-агентств.

Успейте приобрести пакет до повышения цены!

Первый этап: определитесь со стратегией

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

На первом этапе нужно задать стратегические вопросы владельцу бизнес-процесса

За оценку ресурсов также отвечает дизайнер. Можно сэкономить время и начать сразу проектировать, проверяя свои решения в боевых условиях. А можно взять время на исследования, анализ и тестирование ― это будет дольше, но надёжнее. Как говорится, «Быстро, качественно, дёшево ― выбирайте любые два».

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

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

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

Есть два случая, когда бриф особенно полезен. Первый ― заказчик «расписывается кровью» под своими желаниями. Он всё обдумал и честно заполнил бриф. Второй случай ― заказчик не уверен в том, чего хочет, но готов подумать. Вопросы для него служат своеобразной дорожной картой. Если серьёзно, многое зависит от продуктовой культуры компании. К сожалению, мало кто может похвастаться системным подходом, без которого невозможна постановка задач и распределение ролей.

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

Второй этап: визуализируйте клиентский путь

Ко второму этапу мы приступаем, имея на руках валидированные гипотезы. Теперь их нужно верифицировать, то есть подтвердить. Для этого выстраиваем схему процесса: как пользователь из заданной точки А попадает в нужную нам точку Б. Путь пользователя, который выполняет конкретную задачу, называется user flow.

Он состоит из конкретных действий, которые пользователь предпринимает, чтобы выполнить сценарий. Чтобы составить карту этого сценария ― визуализировать клиентский путь, мы используем инструмент Service Blueprint («карта сервиса», «сервисный сценарий»).

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

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

Один из сервисов такси перед выпуском расширения обратился к нам, чтобы протестировать два своих приложения ― историческое и новое, а также сравнить их с двумя основными конкурентами. Мы определили 19 сценариев, которые нужно было проверить для каждого из четырёх приложений.

Некоторые сценарии мы тестировали, не выходя из дома: проверили скорость загрузки, общение с поддержкой и другие события. Этим мы занимались днём, а по вечерам наша команда садилась в такси и исследовала сценарии в полевых условиях: мы ездили из точки А в точку Б, катались по кругу, проверяли разницу между экономом и VIP, отказывались от заказов до старта и посреди поездки. В итоге наши наблюдения и выводы из них легли в отчёт на 122 страницы.

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

Третий этап: разработайте визуальный концепт

На этапе визуализации мы тиражируем пользовательские сценарии ― user flows ― на три–четыре экрана, которые отправляются в разработку. Это может быть главный экран приложения, либо несколько экранов, показывающие фичи сервиса, либо кликабельный прототип. Задача ― проиллюстрировать бизнес-процесс, согласно key visual («ключевому визуальному образу»).

Если раньше работа шла над тем, что будет за кулисами нашего бизнес-процесса, то сейчас речь идёт о «видимом» дизайне. Некоторые заказчики особенно ревностно относятся к визуалу. Чтобы согласование не перешло в многомесячное противостояние, лучше ограничить круг лиц, принимающих решение.

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

Нередко появляются пограничные, или edge кейсы. Это проблема или ситуация, которая возникает только при нестандартном рабочем параметре: изменении логики, появлении новых данных и так далее. Например, мы визуализируем процесс доставки из федеральной сети магазинов. Выясняется, что какой-то регион не входит в зону доставки. Значит, нужно спроектировать пул экранов, которые видят пользователи из этого «выключенного» региона: что делать, если доставка недоступна?

Четвёртый этап: масштабируйте свою идею

Спроектированные бизнес-процессы с утверждённым визуалом масштабируются на весь продукт и отправляются в разработку. Если речь идёт о доработке имеющегося продукта, можно протестировать новый функционал на ограниченной аудитории. Например, обновлённый дизайнерами сервис доставки увидят 5% пользователей, а остальные 95% будут пользоваться старым сервисом ― до тех пор, пока функционал не пройдёт боевое крещение. Эта стратегия называется soft launch, дословно «мягкий запуск». Если решение создаётся с нуля, итерации зависят от продукта, рынка и других факторов.

Такой подход ― апробирование трансформации на отдельном бизнес-участке ― важная часть методологии Agile. Короткие итерации, или спринты, позволяют оперативно накапливать данные для совершенствования продукта. А значит, ошибки не столь критичны: fail early, fail often, fail cheap («ранний провал, частый провал, дешёвый провал»). Важный момент ― на протяжении всего проекта дизайнеры, разработчики и представители бизнеса должны работать вместе. Скорость требует включённости всех участников процесса.

Разумеется, не все и не всегда работают по Agile. Иногда у заказчика есть ресурсы только на дизайн, а на разработку появятся только через полгода. Так или иначе нужно будет вернуться к проекту и снять метрики.

Пятый этап: согласуйте с заказчиком

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

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

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

Вывод

Дизайнер, безусловно, может «просто нарисовать». Например, когда стоит задача создать новые иконки для приложения. Но задача, как правило, масштабнее ― создать или усовершенствовать само приложение. Его нужно спроектировать, протестировать, доработать. И повторить этот цикл несколько раз.

Поэтому чаще всего дизайнер ― это не художник, а архитектор. Нужно на берегу сверить ожидания и убедиться, что видение результата у заказчика и исполнителя совпадает.

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

Источник фото на тизере: John Anvik on Unsplash

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.