Вы можете быть гениальным творцом, создавать шедевры, если рассматривать вашу работу как искусство. Искусство вызывает у нас эмоции, вдохновляет, погружает в мысли и идею автора. Но искусство мало связано с утилитарными потребностями человека, которые должен решать дизайн.
Я заметил, что многие дизайнеры немного путают свою работу с искусством, тратят много времени на поиск вдохновения, пытаются придумать что-то новое.
Вы, наверное, уже слышали такую фразу «Всё уже придумано до нас», это не значит, что нужно бездумно копировать существующие решения. Это значит, что у пользователя уже сформирован опыт. Ваш дизайн будет удобным, если вы воспроизведёте уже знакомый пользовательский опыт, а не заставите его получать новый опыт.
За свои 15 лет работы в IT я совершал и видел много ошибок, это были не только мои ошибки. Ошибки фаундеров стартапов, руководителей и целых команд. Это нормально, продуктовая культура развивалась медленно и из-за нехватки необходимых знаний мы двигались по наитию, без понимания кто наш пользователь, какие у него потребности, зачем ему наш продукт и как продукт будет зарабатывать.
Я хочу поделиться своими знаниями и опытом, которые были накоплены за это время и уже приносят плоды.
Дизайн-процесс простыми словами
Я не претендую на авторство какой-то новой методологии, уже существуют прекрасные методологии Design Thinking, Lean Startup и Scrum, которые я использую в работе.
Мы делаем продукты или новые функции не для себя, а для пользователей. Главное правило «Мы не пользователи», у нас свой опыт и глубокое погружение в продукт, а у пользователя свой опыт. Это нужно всё время учитывать, что очевидно для нас, может быть совсем непонятно пользователю. Это значит, что никто в команде не знает как лучше для пользователя, даже инвестор.
Вы придумали идею нового продукта, новой функции или получили задачу с реализацией какой-то функции:
- Ответьте себе на вопрос «Какую задачу решает эта идея?». Как только вы ответите на этот вопрос, ваша идея станет гипотезой, что у пользователя есть потребность или проблема;
- Теперь нужно провести небольшое исследование, чтобы проверить гипотезу. Для этого нам нужно найти респондентов среди существующих или потенциальных пользователей нашего продукта. Я видел, как мои коллеги по цеху ищут респондентов в социальных сетях, это малоэффективный способ. Если вы не стартап, то проще найти респондентов через отдел продаж, отдел поддержки или продуктовых менеджеров. Так что при возможности обращаемся к ним за помощью в поиске контактов;
- Связываемся с респондентами, назначаем подходящую дату и время. Ни в коем случае не рассказывайте респондентам о своей идее. Спросите про их текущий опыт, про задачу, которую вы хотите решить своей идеей. Сталкивались ли респонденты с задачей и как сейчас они решают эту задачу, сколько времени или денег они тратят на решение этой задачи.
Это исследование называется глубинным интервью, чтобы подготовиться к такому исследованию и провести его правильно, вам поможет книга «Спроси маму» (Роберт Фитцпатрик); - После сессий интервью анализируем данные исследования, сводим все ответы вместе, ищем общие признаки. Вы узнаете больше о опыте пользователей, сможете раскрыть больше проблем и проверите свою гипотезу. Если вы подтвердили гипотезу, вы узнали как сейчас пользователь справляется с задачей. Если ваша идея облегчает жизнь пользователю, то есть пользователю придется тратить меньше времени, совершать меньше действий или он сможет сэкономить деньги, переходим дальше;
- Выбираем одну потребность или проблему пользователя;
- Придумываем варианты решений потребности/проблемы пользователя. Будет лучше, если вы это будете делать не в одиночку, а вместе с командой с наибольшим набором разных компетенций. Это поможет вам найти наиболее компромиссное решение с точки зрения простоты реализации и экономии времени работы команды;
- Как только мы нашли оптимальное решение, можно, примерно, оценить временные затраты команды и посчитать во сколько обойдётся разработка. Умножить полученное число на погрешность оценки и оценить, хотя бы примерно, сколько времени будет окупаться разработка. Возможно, сразу станет очевидно, что овчинка выделки не стоит;
- Создаём прототип, он может быть нарисованным на бумаге, в Figma или малофункциональной разработкой. Цель, сделать как можно дешевле, но чтобы можно было проверить на реальном пользователе, как он справится с задачей;
- Договариваемся с респондентами о очной или онлайн встрече и проводим качественный юзабилити-тест. Главное, видеть, что делает респондент. Респондент запускает прототип, вы должны ввести его в контекст, рассказать, о ситуации и какую задачу он должен решить. Можете заранее подготовить план теста с вопросами. Чтобы держать контакт с респондентом, нужно его спрашивать, что он видит на экране, как он это понимает. Если респондент будет отвечать, не то, что вы ожидаете, не сможет с первого раза найти нужную кнопку — значит прототип нужно переделать и повторить тесты;
- В результате сессий юзабилити-тестов может выясниться, что у пользователей нет проблемы, которую вы пытаетесь решить, значит были допущены ошибки при поиске решения или результаты исследования были неверно интерпретированы. Тогда возвращаемся на соответствующий шаг и повторяем процесс.
Если респонденты справляются с прохождением юзабилити-теста без подсказок и проблем, поздравляю, у вас хороший дизайн, потому что он работает.
Казалось бы на этом работа дизайнера закончена, он предает прототип в разработку и всё? Как бы не так. В ходе разработки могут выясниться неучтённые нюансы. Если разработчики не участвовали в поиске решения и захотели что-то упростить, это может сломать весь пользовательский опыт. Здесь придётся вернуться к изменению прототипа и проведению повторных тестов. После завершения работы разработчиков, необходимо проверить пользовательские сценарии, что они соответствуют прототипу.
В итоге, мы выпускаем продукт, который работает, решает потребности пользователей. Но как пользователи или потенциальные потребители узнают о том, что у вас появилась классная функция в продукте?
Синергия отделов компании
Я работал в разных компаниях и как правило в компании авторитетом обладает один отдел, это может быть отдел разработки, отдел маркетинга или продаж. Каждый отдел тянет одеяло на себя. Только в одной компании я видел синергию работы отделов.
Отдел маркетинга отвечает за привлечение новых клиентов, отдел продаж за продажи и удержание, отдел разработки за поставку новых функций и поддержку работоспособности. Иногда, отделы берут на себя лишние функции и замыкают все процессы на себе.
Если в компании более сильный отдел маркетинга:
- Компания успешно привлекает новых клиентов, но страдает качество продукта и удержание клиентов;
- Маркетинг формирует задачи для разработки. Ресурс разработки сосредоточен на создании новых функций в сжатые сроки и не уделяет должного внимания стабильности продукта;
- Получается, что компания быстро теряет уже привлеченных клиентов и балансирует на окупаемости инвестиций в рекламу. Что плохо в долгосрочной стратегии, если случится сбой в привлечении новых клиентов, компания не сможет поддержать необходимый доход за счет базы лояльных клиентов.
Если в компании более сильный отдел продаж:
- Плохо развивается продукт компании и есть проблемы с привлечением новых клиентов;
- Чаще всего, это заказная разработка, интеграторы и дизайн-студии. У компании есть какой-то программный продукт, который дорабатывается под нужды каждого клиента. То есть, основной ресурс разработки тратится на доработки для клиента вместо развития продукта;
- Из-за непостоянного потока клиентов компания экономит на зарплатном фонде, что сказывается на качестве продукта.
Если в компании более сильный отдел разработки:
- Продукт богатый функциями и очень сложный для пользователя;
- У маркетинга проблемы упаковать продукт, а у продаж сложности с обработкой возражений потенциальных покупателей;
- Это могут быть разработки для нужд крупных компаний, государства или частных инвесторов. У компании фиксированный бюджет на зарплатный фонд, что влияет на качество или скорость разработки и нет другого источника дохода, чтобы иметь возможность расширить штат разработчиков;
- Как правило, такая компания имеет плохую обратную связь от конечных пользователей, плохо понимает кто пользователь и какие у него потребности;
- Компания слепа к рыночным условиям и не может сформировать стратегию развития продукта, кроме как от запросов основного заказчика.
Как все отделы заставить работать вместе?
Это уже зависит от руководства компании и понимания общих целей, чтобы отделы работали как единый механизм и не мешали друг другу. Здесь поможет методология Scrum, которая организует рабочие группы, в которые входят представители разных отделов.
Как выглядит продуктовый процесс в здоровой компании:
- Каждый отдел может формировать бэклог продукта. Например, отдел маркетинга увидел сильную функцию в продукте конкурента или провёл своё исследование и выявил какую-то потребность, а отдел продаж работает с возражениями и получает запросы от потенциальных покупателей, которые блокируют продажи;
- Все эти задачи попадают в бэклог к продуктовому менеджеру. Менеджер берёт задачу и проводит исследование, может привлечь исследователя или дизайнера в роли исследователя;
- После подтверждения гипотезы задача попадает в рабочую группу с представителями разных отделов. Команда придумывает варианты решений, создает и тестирует прототип, разрабатывает готовое решение;
- Отдел маркетинга запускает кампанию по привлечению пользователей, в которой рассказывает о новой функции;
- Отдел продаж связывается с потенциальными покупателями, которые запрашивали функцию и пробует совершить продажи.
Теперь у нас есть понятное взаимодействие между отделами компании, все отделы работают вместе, помогают друг другу сделать продукт лучше и донести ценность до целевой аудитории продукта.
Нужны пруфы?
Успешные продукты, в которых я использовал методологию Design Thinking:
В заключение
Если вы хотите делать успешные продукты, ознакомьтесь с теоретической базой и попробуйте найти единомышленников в компании. Менять продуктовый процесс эффективнее в команде, чтобы не биться любом о стену в одиночку.
Процесс Design Thinking можно применить в любой компании и в рамках небольшого эксперимента показать руководству как просто делать хорошие продукты.
Не бойтесь пробовать, все с чего-то начинают. Мало обладать знаниями, важно наработать опыт. Если боитесь сделать первые шаги, вам помогут курсы или мастер-классы, без рекламы могу рекомендовать Wonderfull.
Для теории вам помогут книги:
- «Спроси маму» (Роберт Фитцпатрик) — база, чтобы научиться задавать вопросы на интервью;
- Принцип «черного ящика» (Мэтью Сайед) — перевернёт ваше представление о ошибках, повысит культуру открытости и признания ошибок;
- Дизайн-мышление — здесь важно понять дизайн-процесс. Вам подойдёт любая книга, где хорошо описаны этапы процесса, будь то «Дизайн-мышление. Все инструменты в одной книге» (Оливер Кемпкенс) или «Дизайн-мышление. От инсайта к новым продуктам и рынкам» (Михаэль Леврик, Ларри Лейфер, Патрик Линк).
Для закрепления теории на практике вам поможет методичка «Дизайн-мышление. Рабочие материалы» от Wonderfull; - «Lean Startup/Бизнес с нуля» (Эрик Рис) — познакомит с теорией «бережливого производства», научит экономному производству и адаптации к рыночным условиям;
- «Спринт» (Джейк Кнапп, Джон Зерацки, Брейден Ковитц) — поможет выстроить продуктовый процесс с предсказуемым планированием.
