Блиц-интервью с Юрием Ветровым

Какие нужны качества, чтобы «дизайнить дизайн-процессы», то есть управлять большими дизайн-командами?

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

• Иметь долгосрочное видение и чёткий план ближайших шагов. Не забывать ни про первое (иначе будет набор хаотичных действий), ни про второе (иначе останется пустое прожектёрство).
• Уметь слушать других и доносить свою позицию. Первое нужно, чтобы слышать реальные проблемы за их симптомами, а второе — добиваться реализации идей. Если оба варианта не помогают — выходить на управляемый конфликт (но не злоупотреблять этим).
• Понимать, как масштабировать методы и практики. Любой процесс или подход нужно внедрять с учётом под потенциальное использование на большем количестве проектов, дизайнеров, команд.
• При этом не бояться «закостылить» метод на старте, чтобы понять, нужен ли он вам вообще. Иначе можно потратить кучу сил, полируя подходы, которые вообще не пригодятся.
• Не профукать навык специалиста — дизайн-менеджер не должен терять связь с землёй. Мы всё-таки в первую очередь про дизайн, и уже во вторую — про менеджмент. Важно работать руками или другим способом участвовать в дизайн-процессе (например, в концептуальном проектировании на доске).
• Но помнить, что надо регулярно отпускать задачи — ты не можешь сфокусировано заниматься всем сразу. И не лениться читать про менеджмент, чтобы не ходить по известным граблям самому.
• Команда — это самое главное и ценное, что есть у дизайн-менеджера. Без неё нет смысла в таком человеке. Важно развивать и укреплять её всегда и при любой возможности.

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

Где границы полезности дизайн-систем? Когда они нужны, а когда нет?

Дизайн-системы (если говорить об их правильном современном понимании, то есть о единых компонентах в коде, а не UI Kit в Sketch) решают несколько задач:

1. Меньше багов на живом, когда один и тот же элемент интерфейса верстают заново. В итоге получаем более качественный дизайн меньшими силами.
2. Реже изобретаем велосипед, когда простейшие задачи выдумываются каждый раз с нуля. Получаем более целостный интерфейс, что здорово помогает бренду и общему удобству использования.
3. Быстрее собираем типовые экраны и блоки. В итоге экономим силы для более сложных интерфейсных решений.
4. Масштабируем улучшения типовых решений, когда доработки для одного из продуктов тут же могут забрать все остальные. В итоге улучшаем показатели успешности всей линейки продуктов.
5. Не доводим продукты до состояния «нужен кардинальный редизайн», регулярно обновляем и освежаем их. В итоге дизайн находится в актуальном состоянии гораздо дольше.

Звучит так, что слюни текут, но работает оно в идеальном виде далеко не сразу. Мы начали переход на компонентную дизайн-систему в 2012 году и, хотя неплохо продвинулись, не всё работает как часы — ещё пилить и пилить. Поэтому возникает вопрос — а надо ли это затевать, если так долго и муторно? Моё мнение — обязательно. Даже с той кучей нерешённых вопросов, что остались у нас, выхлоп получился огромным — видно, что работа над продуктами стала системнее, версии «на живом» значительно лучше и ближе друг к другу, мы стали быстрее запускать новые функции и продукты на базе единого дизайна.

Есть мнение, что это всё только для больших компаний, а небольшим сервисам или ребятам с одним сайтом дизайн-систему не потянуть. С одной стороны, да — дизайн-система даёт выхлоп, если решения в дизайне используются повторно. Если у вас всего пара экранов, которые сильно отличаются, то переиспользовать нечего. Или ваш продукт постоянно и часто меняется, то гибкость будет важнее систематизации. С другой стороны, если описать хотя бы базовые параметры визуального дизайна (цвета, шрифты, отступы) и управлять ими через токены (Tokens in Design Systems), то это обеспечит систематизацию, но не потребует городить сложный компонентный фреймворк. А в будущем скажете себе спасибо, что поставили стакан воды на утро.

Дизайнеру стоит прокачиваться в одной выбранной сфере дизайна, или лучше развивать максимально широкий набор навыков?

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

При этом знать всё глубоко невозможно, так что какой-то фокус нужен. Какой он будет — ваше дело, к чему ближе лежит душа. Мы используем карту компетенций для развития дизайнера. В ней собрали все навыки, которые потенциально полезны продуктовому дизайнеру. Каждый в команде оценивает себя, мы вместе смотрим на сильные слабые места и выбираем точки роста. Дальше ставим цели на год на их основе и регулярно встречаемся, чтобы отслеживать прогресс и разруливать возникающие сложности. В итоге хорошо и дизайнеру (становится сильнее и бодрее) и компании (больше выхлоп от специалиста).

Какая последняя стоящая книга НЕ о дизайне, что ты прочитал?

Andy Grove — High Output Management (русское издание 1996 года). Безумно круто выправляет мозг в плане того, как (дизайн-)менеджеру приносить максимум пользы и выносить минимум чужих мозгов.

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

А о дизайне?

Henry Dreyfuss — Designing for People. Классика от классика пром.дизайна, изданная ещё в 1955 году. Поразительно, как многие проблемы в организации работы, взаимодействии продуктовой компании и агентства, развитии T-образных специалистов описаны в том же виде и тем же языком, что и сейчас. Это и хорошие, и плохие новости — динамика взаимоотношений дизайнера и продуктовой команды определяется самой спецификой работы. И хотя итоговые продукты и инструменты меняются, эта динамика во многом сохраняется.

Как автоматизация повлияет на профессию дизайнера? Что делать сейчас, чтобы быть востребованным через 5 лет?

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

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

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

Возвращаясь к изначальному вопросу :) Учитывая, что рутина будет автоматизироваться и дальше, ценность навыков в работе с конкретным инструментом снизится, как и порог входа — начинающему дизайнеру, разработчику или менеджеру будет гораздо проще сделать хорошо. Так что копайте шире, развивая смежные навыки дизайнера интерфейсов. Специалист, который может не только нарисовать макет, но пообщаться с пользователями, помочь в реализации дизайна в коде, получить обратную связь от рынка после запуска и сильно улучшить результат на её основе — всегда будет в цене.

Что думаешь о слухах о том, что iOS 13 будет про задачи, а не приложения?

Редко читаю про слухи, проще дождаться официальной презентации. Из того, что пробежался про iOS 13 понял только совсем общие вещи про новый стартовый экран и фокус на iPad. В целом интересно, как Microsoft решает задачу объединения десктопа и планшета через планшетизацию десктопа, а Apple — наоборот.

Я долгое время собирал мобильные и планшетные ОС, чтобы посмотреть на интересные интерфейсные наработки и необычные направления. Самыми сильными были WebOS от Palm (позже их купил HP) и Windows Phone — они предлагали более интегрированные подходы между ОС и приложениями, в отличие от тупенького «стартовый экран и запускаемые оттуда атомарные утилиты», с которого начинал iOS. Правда, со временем начинающие сдулись, а Android и iOS взяли всё лучшее оттуда и смысл в коллекционировании пропал. Так что верю, что после бедного на изменения анонса интерфейса iOS 12 будет что-то интересное.

Что думаешь о DesOps?

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

С другой стороны, хотя DesignOps просто переупаковывает уже известные подходы, термин поставил очень грамотный фокус — развивать дизайн-процессы, инструменты, методы и практики под масштабирование. Т.е. так, чтобы ими мог легко воспользоваться любой дизайнер в компании. Это то, что отличает его от остальных. Я не очень люблю всё это перекрашивание в новые термины ради попадания в тренд, но мне нравится фокус на масштабировании. А также то, что DesignOps связан с понятной менеджерам и разработчикам концепцией DevOps — проще объяснить, чем мы занимаемся. Так что, видимо, буду использовать его сам (на всякий случай добавил зеркало своего сайта про UX-стратегию с адресом DesOps.Co.