Как устроена работа дизайнеров в продукте? С какими вызовами сталкиваемся мы в корпоративной культуре и как создать среду, где дизайн будет по-настоящему влиятельным и качественным? На все эти вопросы я постараюсь ответить в этой лекции

Начать стоит с рассказа о себе – почему я решила рассказать об этой теме и какой опыт я имею в ней

Сейчас я работаю старшим продуктовым дизайнером в Россельхозбанке, ранее работала в других известных банках и встречала на своём опыте самые разные процессы

Помимо этого я училась в МИДиС и сейчас учусь в НИУ ВШЭ, преподаю в онлайн школе Formfactor и люблю помогать начинающим дизайнерам разобраться в сложных вещах

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

Начать стоит с того, какие типы команд в продуктовой работе существуют. Условно есть два основных типа. Первый — централизованные команды. Здесь дизайнеры — это единый пул экспертов, своего рода «агентство» внутри компании. Их «нанимают» продукты для решения задач

Плюс — высокий уровень экспертизы и консистентности Минус — дизайнер далёк от продукта и бизнес-метрик

Второй тип – это кросс-функциональные команды. Здесь дизайнер встроен в постоянную продуктовую команду и плотно погружён в её контекст

Плюс — скорость и глубина погружения Минус — риск потери консистентности и единого уровня дизайна по компании

Логичный вопрос: а можно ли совместить плюсы двух моделей? Можно! Это комбинированная модель. Дизайнер физически находится в продуктовой команде, но сильно вовлечён в общую дизайн-культуру через качественные дизайн-процессы и дизайн-культуру. Это идеал, к которому стоит стремиться, но его сложнее всего реализовать

Какой же вывод? Идеальный путь для развития продукта с нуля – начать с сильной централизованной команды, чтобы выстроить экспертизу и культуру, а потом постепенно эволюционировать к комбинированной модели. Не пытайтесь сделать комбинированную модель сразу – может получиться плохо

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

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

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

1. На практике часто этапы смешиваются, и это нормально. Например вы брейнштормите и параллельно накидываете исследование

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

3. Дизайн-процесс нужен не для бюрократии. Он должен адаптироваться под общую производственную цепочку и помогать поставлять ценность клиенту и бизнесу

Давайте расставим акценты на ключевых этапах:

Понимание задачи – это очень важный этап, который многие упускают, но попробовав сделать это несколько раз, дальше вы будете применять это уже автоматически и избавитесь от неловкостей, когда вы не верно поняли задачу.

Также этот этап может позволить понять, а нужна ли задача вовсе или решение может быть более простым без потребности в дизайне. Суть заключается в распределении задачи на куски: в чем польза для бизнеса, в чем польза для пользователя, какая ЦА и какой критерий успеха у этой задачи? Уточняя эти вопросы у стейкхолдера, а лучше прийдя со своим видением, вы избежите большой работы в стол

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

Например, я не представляю как это вообще может быть – пойду смотреть референсы,

Я не знаю, зайдет ли это пользователям - пойду проведу быстрые коридорки,

Мне кажется это уже не актуально - поисследую рынок,

Я не понимаю кто этим будет пользоваться - проанализирую глубже ЦА и так далее

Брейншторм это этап, когда многие дизайнеры упираются в 1-2 варианта и идут их вылизывать. Я сторонник того подхода, когда вы, без просьбы стейкхолдера, генерите как можно больше вариантов решения задачи и развиваете наиболее удачные, отвечая на все вопросы себе, а уже после выводите 1-2 конечных результата, которые могут обсуждаться

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

Ревью это важный этап чтобы понять, не упустили ли вы что-то. Некая прожарка в которой главное не спорить и отбиваться, а слушать и иногда аргументировать, чтобы сделать решение наиболее качественным

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

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

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

Если культура не сильно развита, созвонитесь с разработчиком и пройдетесь по задаче на момент понимания и вопросов

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