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

Практика показывает, что если нужно что-то предметно обсудить в ИТ (и в других областях тоже), то речь идёт именно о классических дизайн-подходах с User Flow и CJM. То есть очень многие процессы разработки ускоряются за счёт построения процесса от конечного пользователя к продукту, а не наоборот.

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

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

Компании с правильными дизайн-процессами зарабатывают существенно больше.

Я бы хотел рассказать про три базовые вещи с позиции пятилетнего исследования и своей практики в российских и международных компаниях:

1. Мало кто воспринимает дизайн как способ проектирования продукта и как полноценный бизнес-процесс. Чем глубже этот процесс интегрирован, тем лучше финансовые результаты бизнеса в целом.
2. Часто складывается ситуация, что в дизайне никто не играет за клиента.
3. Нет особой финансовой разницы между плохим, посредственным и хорошим дизайном: рынок вознаграждает только компании с отличными процессами.

Меня зовут Николай, я дизайн-директор в McKinsey & Company. Одна из моих рабочих задач — показывать и объяснять компаниям, что такое дизайн. Вопреки распространённому мнению, это не «картинка» или «нарисованный интерфейс». Это проектирование, которое ведёт к тому, что будет решаться основная задача бизнеса. А основная задача бизнеса — максимально удовлетворять потребности клиентов, зарабатывая при этом или накапливая какой-то другой ресурс.

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

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

Давайте расскажу чуть подробнее и с числами исследования.