Читать книгу Дизайн-стройка. Как создать команду мечты за 90 дней - Андрей Богданов - Страница 5

Прежде чем приступить к конкретным рекомендациям по созданию дизайн-команд, давайте попробуем ответить на основополагающий вопрос: «А зачем, собственно, вообще нужны эти команды?»

Представители других ролей – разработчики, тестировщики, аналитики, менеджеры, владельцы продукта – прекрасно уживаются в рамках единой продуктовой команды и редко стремятся создавать свои, выделенные7[1]. Так почему же дизайнеры во многих компаниях норовят обособиться и сбиваются в отдельные группы со своими лидерами?

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

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

Дизайн – это творчество, НО его результат можно измерить

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

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

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

Дизайн технически несложен, НО зависит от технических моментов и сам влияет на них

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

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

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

Дизайн просто критиковать, НО сложно оценить объективно

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

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

Ошибки в дизайне не критичны в моменте, НО губительны в перспективе

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

Чтобы исключить такие случаи, нужно выстраивать особые процессы, которые обеспечивают высокое качество дизайна.

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

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

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

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

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

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

Включение продуктового дизайна в подразделение маркетинга может быть полезным для формирования цельного образа бренда в разных каналах. Для любого продукта важно, чтобы клиент всегда воспринимал его одинаково: и в рекламной коммуникации, и при физическом контакте, и в процессе взаимодействия с цифровым интерфейсом. Но, как и в случае с бизнесом, «подружить» дизайн с маркетингом можно и без формального подчинения дизайн-команды маркетинговому руководству. Проектирование продукта – это объемная многосоставная компетенция, а маркетинговая составляющая – это лишь небольшая, хоть и важная, ее часть. Поэтому, отдавая дизайн в распоряжение руководителей от маркетинга, мы рискуем сильно сузить восприятие дизайна внутри компании.

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

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