Андрей Богданов – Дизайн-стройка. Как создать команду мечты за 90 дней (страница 5)
Представители других ролей – разработчики, тестировщики, аналитики, менеджеры, владельцы продукта – прекрасно уживаются в рамках единой продуктовой команды и редко стремятся создавать свои, выделенные7[1]. Так почему же дизайнеры во многих компаниях норовят обособиться и сбиваются в отдельные группы со своими лидерами?
Я поступлю невежливо и отвечу вопросом на вопрос:
Конечно, дело не в том, что продуктовый дизайн – самая сложная дисциплина. Скорее, самая противоречивая. В дизайне слишком много разных «НО», которые достойны того, чтобы рассмотреть их по отдельности.
Дизайн безусловно не является искусством, но так же, как и оно, несет в себе творческое начало. Креативность, привлекательность, эмоциональность – все это важные характеристики дизайна.
Но, конечно, дизайн не живет по принципу «я художник, я так вижу». Несмотря на ярко выраженную эстетическую составляющую, он служит сугубо практическим целям: решать задачи бизнеса и улучшать пользовательский опыт. Более того, качество дизайна можно (хотя и не всегда просто) измерить конкретными показателями в виде продуктовых метрик. Меняя визуальную составляющую продукта, мы изменяем его потребительские качества, что напрямую влияет на бизнес-эффект.
Такая двойственная природа дизайна порождает многообразие интерпретаций и точек зрения, с которых можно рассматривать спроектированные дизайнерами сценарии.
Овладеть инструментами для создания дизайна относительно просто. Чтобы научиться экспертно владеть Figma, конечно, придется приложить некоторые усилия, но все же это куда проще, чем освоить программирование.
При этом дизайн цифровых продуктов крепко завязан на технические ограничения. Мы не можем нарисовать в макетах все, что угодно, а должны учитывать архитектуру продукта. Может получиться так, что самый безупречный дизайн будет невозможно реализовать на практике из-за неучтенных нюансов разработки.
В то же время не только разработка влияет на дизайн, но и дизайн на разработку. В зависимости от того, как спроектированы макеты, программисты могут или воплотить задуманное в считанные дни, или потратить бессчетное количество времени на запуск «космического корабля», который спроектировал дизайнер.
Обсуждать дизайн очень легко из-за его наглядности, поэтому вокруг дизайнера постоянно собирается толпа разнообразных комментаторов и советчиков. Некоторым – например, владельцу продукта – комментирование положено по должности. Другим – нет, но это, как правило, их не останавливает.
При этом реальной экспертностью обладают далеко не все советчики, а их рекомендации могут сбивать дизайнера с верного пути и менять проектируемые сценарии в худшую сторону. Хаотичное комментирование дизайна совсем не похоже на четкую процедуру код-ревью у разработчиков и поэтому нуждается в дополнительной модерации.
Еще одна проблема заключается в том, что плохие дизайн-решения имеют отложенный эффект. Тот факт, что пользовательский путь спроектирован неудачно, может вскрыться только после релиза, когда мы увидим падение бизнес-показателей или негативные отзывы клиентов. А может и не вскрыться вовсе, если не налажен процесс отслеживания метрик и сбора обратной связи.
Чтобы исключить такие случаи, нужно выстраивать особые процессы, которые обеспечивают высокое качество дизайна.
Можно вспомнить еще много разных «НО», однако, кажется, написанного достаточно, чтобы понять специфический характер дизайнерской работы. Из-за этой специфики и приходится обособлять дизайнеров от других коллег как с точки зрения процессов, так и с точки зрения организационной структуры.
При этом включение дизайнеров в обособленную команду вовсе не исключает их закрепление за командами продуктовой разработки. Если правильно выстроить процессы, дизайнеры прекрасно могут существовать одновременно в двух измерениях: собственно дизайнерском и продуктовом.