McKinsey Advanced Analytics
128

Что такое дизайн с точки зрения бизнеса — и что можно поменять в вашем проекте

В закладки

Меня зовут Николай Комаров, я дизайн-директор в McKinsey & Company. Хочу рассказать про результаты нашего пятилетнего исследования того, как чёрный ящик под названием «дизайн» влияет на бизнес в 300 публичных компаниях. Мы собрали больше двух миллионов финансовых записей и запротоколировали около 100 тысяч проектных действий, а потом опросили руководителей бизнеса и дизайн-специалистов.

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

Чем отличаются компании, которые делают «великолепный» дизайн?

А одной простой вещью — для них это способ понять потребности клиента. И речь не о том, что дизайнер хорошо или плохо рисует. Речь о том, что дизайнер хорошо проектирует то, чем дальше будет пользоваться клиент. В этих компаниях процесс «вот товар, придумай упаковку» перевёрнут — «покажите упаковку, которая понравится клиентам, потом мы сделаем товар на этой основе». Казалось бы, идея простая ещё со времён чуть позже Форда — сначала пойми, что нужно рынку, потом это делай. Но на практике, ¾ компаний считают, что это слишком очевидно, поэтому так делать не надо!

Больше 40 процентов компаний из исследования не разговаривают со своими клиентами во время разработки продукта. Половина компаний не знает, как оценивать продукт, который сделали разработчики: условно, «компания курильщика» считает по фичам, а «компания здорового человека» — по тому же NPS клиента. Но не всё и не всегда так просто решается «в лоб», я сейчас утрирую.

Если обобщать:

  • Решения часто принимаются на основании мнения «мы знаем, что нужно пользователю» без проверки.

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

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

В остальных компаниях чаще всего бизнес не интересовался метриками, а дизайнеры и не использовали никаких метрик.

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

Полное исследование можно скачать вот здесь.

Что можно сделать?

Первое — встраивать метрики проектирования (оценка удовлетворённости и оценка удобства пользователей).

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

Третье — делать пользовательский опыт ответственностью каждого, а не изолированной функцией. Наши исследования показывают, что преодоление изоляционистских тенденций чрезвычайно ценно. Речь идёт примерно о 7 % роста. И речь даже не о том, что это какой-то комплексный KPI. Просто каждый должен понимать, что и зачем он делает, и по возможности видеть метрики, получать обратную связь. «Я сижу пишу код» или «я сижу рисую иконки» — нормально, но круче «я пишу код, чтобы сделать мир лучше тут-то» и «я рисую кнопки вот такоооого размера, чтобы шахтёры попадали в них рукой в грубой перчатке».

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

Четвёртое — сразу начинать прототипировать и итерировать идеи. Почти 60 процентов компаний использовали прототипы только для финального этапа. Самые успешные компании сознательно развивают культуру обмена ранними прототипами с внешними аудиториями и продвигают зародышевые идеи.

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

Итого, основные тезисы по исследованию:

1. Аналитическое лидерство — введение метрик и оценка дизайн-активностей.

2. Кросс-функциональность — человеко-центричность внедряется в организацию и становится ответственностью всех сотрудников, а не только одного департамента.

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

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

Напоминает кое-какие фреймворки разработки, правда?

Как внедрять это в своей компании?

За годы выстраивания таких процессов в МсKinsey мы начали использовать фреймворк, в основе которого — парадигмы Design thinking, Zero-based design и Service design, и теперь рекомендуем использовать его при перестроении компании в сторону клиентоориентированности.

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

Шаг 1. Анализируем ситуацию «как есть», понимаем потребности клиентов, бизнеса и всех стейкхолдеров.

На первой стадии существующие решения не важны, нужно, условно, забыть всё и пойти к конечным клиентам разбираться, что за задача решается, и как было бы оптимально её решать. Очень важно, что именно тут мы создаём CJM с цепочкой интерфейсов-прототипов и прямо вместе со всеми сторонами его обсуждаем. Пока не касаясь технических моментов, а говоря только о том, удобно или нет. Такая процедура очень быстро устаканивает ожидания от проекта у всех и очень быстро позволяет принять решения. Если перед глазами нет визуального инструмента — процесс затянется на месяцы вместо недели. Каждое изменение прототипа можно проверить тут же рядом на исследованиях с реальными конечными пользователями (пока это интервью и тесты в духе «найди тут кнопку для того-то»).

На этом этапе очень помогают co-creation сессии вместе с клиентами и инструменты визуализации пользовательского опыта и процессов — customer journey maps и service blueprints. В банках, проектируя новые системы для офис-обслуживания, мы сперва собираемся с сотрудниками и разбираемся, как на самом деле работают основные процессы — например, выдача кредита, какие инструменты используются, как происходит общение с клиентом, сколько времени занимает каждый шаг, что на нём работает, какие проблемы приходится решать и т.д. В результате мы получаем отпечаток реальности, c которым все коллективно согласны, на основе которого можно думать над новыми решениями.

Шаг 2. Придумываем целевое видение, каким мы хотим видеть продукт или сервис в будущем.

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

— Придумываем, как будет выглядеть наше решение на горизонте, например, года, какой функционал в принципе было бы круто сделать. Для этого используем карты клиентского пути и user story maps.

— Построив идеальное видение — приземляем его на существующие процессы (технологии, требования юристов, безопасников и т.д.).

— Рисуем интерактивный прототип этого видения, чтобы у всех перед глазами была более-менее конкретная картинка — north start — к чему мы хотим прийти.

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

3. Отстраиваем от целевого видения шаги в настоящее: начинаем видеть, как мы можем к нему прийти.

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

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

4. Сначала MVP.

Делаем минимально работающий прототип! Базовый постулат гласит, что чем раньше появятся работающие прототипы, тем больше шансов сделать продукт быстро для клиента, а не для себя. Поэтому мы всё время работаем с прототипом разной степени проработки — от wireframe на первом шаге до релиза (и дальше поддерживаем релиз). На этом этапе мы получаем уже численную оценку гипотез, которая часто совпадает с качественной, с шагов 1, 2 и 3, но не всегда. И иногда нужно дополнительно получить числа для оценки точных приоритетов дальше.

Как это происходит

  1. Создаются продуктовые команды. Они должны быть автономны, то есть состоять из владельца, разработчиков, дизайнера, тестировщиков и всех нужных специалистов — например, финансистов в банке, инженеров в телекоме, системных архитекторов в ИТ-компаниях и так далее.
  2. Отвечаем на вопрос: «Что нам нужно сделать?». Не в виде решения, а в виде сформулированной задачи. То есть как раз применяем zero-based методологию в том числе. Строим целевой клиентский путь. Ищем способы проверить первые прототипы решений и проверяем их. Двигаемся по продукту как по цепочке сценариев и рассматриваем, что нужно для реализации каждого.
  3. Прорабатываем дизайн MVP каждого шага и пробуем его на реальных людях. Тут возникает масса согласований, ищем прямо внутри продуктовой команды способы их пройти. Работаем в спринтах (как правило, двухнедельных), планируем дизайн-задачи на спринт, выбираем день для проверки гипотез через юзертесты, например, за день-два до демо, проводим их и определяем доработки. Запускаем аджайл разработку. Тут либо разработка уже идет параллельно с дизайном MVP, либо после завершения дизайна запускается. Бывает и так и так.


В общих чертах — примерно так. Детали есть ещё на нашем портале про дизайн в бизнесе: https://www.mckinsey.com/business-functions/mckinsey-design/our-insights. Ну и, конечно, с удовольствием отвечу на вопросы.

Превращаем терабайты данных в выдающиеся финансовые результаты
{ "author_name": "McKinsey Advanced Analytics", "author_type": "editor", "tags": [], "comments": 0, "likes": 2, "favorites": 4, "is_advertisement": false, "subsite_label": "mckinsey", "id": 127448, "is_wide": true, "is_ugc": false, "date": "Mon, 18 May 2020 10:18:51 +0300", "is_special": false }
Объявление на vc.ru
0
Комментариев нет
Популярные
По порядку

Прямой эфир