Отрицание, гнев, торг: как дизайну и разработке найти общий язык

Привет! Я Женя, ведущий продуктовый дизайнер в Ozon, и за 10+ лет в дизайне повидала всякого: ошибок в макетах (своих и чужих), недостаточно полных спецификаций, неучтённых корнер-кейсов, сотни сообщений в тредах с разработкой и переносы релиза из-за досадных багов. 

Стало понятно: спроектировать макеты в Figma может каждый, но докатить их до прода так, как было задумано, — целое искусство, в котором дизайн и разработка должны идти рука об руку. Понимают ли они друг друга? Я запустила анонимный опрос в командах: что радует и что раздражает разработчиков в макетах дизайнеров — и наоборот. И в этой статье хочу порефлексировать над его результатами.

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

^{Осторожно, количество мемов в статье зашкаливает}  

Итак…

Бывало ли у вас такое, что, вроде, вы умный человек, коллеги ваши — компетентные люди, вы все вместе усердно поработали, а на проде получается что-то такое, что и друзьям стыдно показать, и себе неудобно признаться, что вы в этом участвовали…?

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

Поэтому когда дизайнер получает заветное «норм» от своего лида и согласование от тысячи стейкхолдеров, первое, что хочется сделать — это выдохнуть. Но опытный дизайнер знает, что это только половина пути (и путь этот может быть тернистым).

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

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

Мне захотелось пощупать, есть ли такая проблема (или мне кажется?), и мы запустили внутри компании перекрёстный опрос. Дизайнеров спросили, что им нравится и не нравится во взаимодействии с разработкой, и такой же опрос провели среди мобильных разработчиков. 

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

И начнём мы с огня 🍿

А именно, почему у разработчиков пригорает от макетов дизайнеров

1. Недостаточно состояний экранов, нет тёмной темы и корнер-кейсов.
   Это в топе жалоб разработчиков. Все недостающие состояния обязательно вылезут (хорошо, если не на проде) и всё равно догонят дизайнера, только нужно будет уже отвлекаться от следующей задачи. Поэтому лучше заложить время в рамках текущей задачи и подумать, а о чём ещё стоит помнить:
   • Не забыть про точки входа и выхода, показать флоу стрелочками, в идеале — собрать прототип (помогает выявить дыры в сценарии).
   • Мыслить как QA: прикинуть не только ожидаемые данные в формах, но и min/max значения, ошибки, состояния успеха, empty state, лоадеры, etc).
   • Проактивно спрашивать про корнер-кейсы всех, до кого доберётесь (продакта, аналитика, разработку, QA).
   • Проверять все (повторюсь, ВСЕ) экраны в тёмной теме (dark mode). Подходы «да там всё на токенах дизайн-системы, должно быть норм» и «достаточно проверить ключевые экраны» приводят к косякам на проде, потому что там, где забывают показывать dark mode в макетах, забывают и проверять его на дизайн-ревью.

   

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

   

3. Дизайнеры не понимают мобильную кухню. Мыслят компонентами, а не виджетами.
   Возможно, это наша специфика, поэтому поясню контекст: у нас исповедуется подход SDUI, экраны собираются из виджетов, которые бывают общие (common, CMS, etс — используются в нескольких доменах) и продуктовые (например, в вертикали PDP регистрируют виджеты карточки товара).

   

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

4. Дизайнеры плохо знают специфику платформ или разработки в целом (откуда идут данные).
   Тут несколько проблем:
   • Если дизайнер не интересуется, как его макет затем реализовывается в коде, то он будет раз за разом предлагать дорогие или нецелесообразные решения с точки зрения соотношения выгоды от проверки гипотезы и стоимости её разработки.
   • Сюда же относится проблема, что большинство дизайнеров и продактов сами сидят на iOS и не всегда знают особенности Android, а там другая системная навигация или целый зоопарк коэффициентов виртуального разрешения, и это нужно учитывать в дизайн-решении.
   • Не всегда дизайнер понимает, что зашивается на фронте, что тянется с бэка, а если с бэка, то что будет, если данные не придут?

   

5. Дизайнеры долго отвечают.
   Неожиданное открытие, но оказавшееся распространённой проблемой. Видимо, разница в количестве встреч в календаре: разработчики ожидают быстрого ответа здесь и сейчас, а у дизайнера ближайший просвет между встречами только через 4 часа.

   

Дизайнерам тоже было что сказать в ответ

1. Расхождение вёрстки и макетов.
   Очевидные визуальные баги.
   После QA следует этап дизайн-ревью: дизайнер проверяет реализацию своего решения и оставляет комментарии, если есть расхождения. Подробнее об этом процессе расскажу ниже, но основная боль в нём: иногда дизайнер встречает какие-то совсем очевидные баги, и хочется очень вежливо спросить «С какой стати? Вы меня извините, я сейчас скандал такой учиню!»

   

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

   

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

   

4. Проблемы коммуникации: ждут молниеносного ответа, говорят на своём языке.
   Скорее всего, уже на пятом теге в треде дизайнер догадывается, что его ответ очень нужен, но освободиться он сможет в ближайшее окошечко между встречами. А когда освободится, то ничего не поймёт в треде, потому что там всё на разработческом.

   

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

   

   Часто аргументы понятны: продукту нельзя ронять перфоманс (aka перф) — основные метрики для мобильной разработки (LaunchTime, HitchRate, HangTime, ScreenTotalTime и прочие заклинания, показывающие скорость взаимодействия с приложением). Разработка тратит большие ресурсы на ускорение загрузки, оптимизацию и рефакторинг, каждая миллисекунда на счету — поэтому мы не можем себе позволить долгие сплеши, сложную анимацию и прочие прикольные эффекты, как это принято на Dribbble, ведь пользователи в быстром интерфейсе решают свои задачи быстрее, а значит быстрее растёт GMV.
   Поэтому мы с пониманием относимся к аргументам «вот этот ваш блюр, анимация, etc уронит перф», но я встречала ситуацию, когда в одной команде отказали в фиче с аргументом ухудшения перфа, а в другом департаменте такую же фичу сделали и ничего не упало — это вызывает вопросы. 

Что можно было бы улучшить?

По мнению разработчиков

1. Использовать дизайн-систему и затаскивать меньше кастома.
   Это главный лейтмотив — есть дизайн-система, используйте, пожалуйста, её. Если вы стопроцентно  ̶м̶а̶м̶о̶й̶ ̶к̶л̶я̶н̶у̶с̶ь̶ уверены, что там нет компонента, который решит вашу продуктовую задачу, то посоветуйтесь с командой ДС, и после её благословения можете нести этот ваш кастом, так мы будем уверены, что это оправдано.

   

2. Увидеть все состояния виджета в обеих темах.
   Крик души: иногда нужно просто подумать, какие ещё возможны состояния в виджете или сценарии. И не забыть всё-всё продублировать рядом в тёмном режиме: так вас не только разработка будет носить на руках, но и QA скажут спасибо. 

3. Понимание SDUI ускорит наши ТТМы.
   Если дизайнер будет разбираться и понимать, как хотя бы верхнеуровнево будет реализовываться макет, это сильно сократит Time to market разработки (а это для них главная организационная метрика).
   Тут дизайнер может возразить: это их работа, мне до одного места их ТТМы, у меня своих задач навалом. На что я возражу в ответ: вы всё равно потратите всё то время на покрытие непокрытых кейсов, описание неописанных моментов, комментарии несостыковок на дизайн-ревью — только будете делать это уже на следующих этапах, когда задача будет в анализе, разработке или QA. Качественная подготовка макета экономит время и дизайнеру тоже. 

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

5. Указывать изменения дизайнов в макетах.
   Небольшое, но важное пожелание: если в макетах что-то поменялось после того, как задача взята в работу (а такое бывает чаще, чем хотелось бы), то обязательно подсвечивайте это изменение в макетах и сообщайте в тредах. Иначе разработчик может пропустить изменение, заметят это только на QA и произойдёт re-open, который никто не любит. 

По мнению дизайнеров

1. Сделать дизайн-ревью обязательным этапом и не в последний момент.
   Здесь передаю привет и огромную благодарность нашим тимлидам и руководителям, кто затаскивал дизайн-ревью в команды как обязательный процесс, иначе на проде мы видели бы более грустную картину.
   Теперь мы полируем этот процесс: например, разработка привыкла, что нужно показать решение дизайнеру, но успевает это сделать в конце спринта, и дизайнеру нужно экстренно всё бросить и сидеть с лупой, чтобы при отсутствии критов (критичных багов, которые мы не можем допустить до прода) фича успела отрезаться в ветку релиза. Поэтому сейчас мы просим предупреждать заранее, когда нужно будет провести ревью, чтобы запланировать своё время. 

2. Изучить Figma.
   Для дизайнеров удивительно, когда разработчик не воспринимает Figma как полноценный инструмент для работы, не знает базовую функциональность и даже работает через веб-версию (а в браузере, как известно, ощущения не те). 

3. Ликбез по разработке.
   Мы бы рады понимать, но не понимаем. Пожалуйста, расскажите нам, как у вас тут всё устроено и как всё работает. 

4. Собрать шаблон идеальной спецификации.
   Лично для меня болезненный момент: я пока сама не нащупала этот идеальный баланс, как показать всё достаточно, но не избыточно. 

5. Больше общаться и взаимодействовать друг с другом, сходить в бар.
   Просто оставлю цитатой:

   

Но не всё так плохо

Разработка хвалит дизайн за

1. Красивые макеты 💅

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

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

Простите, немного отвлеклась. Вернёмся к результатам опроса, что ещё отмечают хорошего разработчики:

2. Когда дизайнер готов идти навстречу, оперативно вносит правки.
   Ценно, когда дизайнер понимает, что цикл разработки имеет свои рамки, и если не поддерживать макет своевременно и пропускать вопросы от QA, то задача может не успеть поехать в ближайший релиз. 

3. Используют готовые компоненты, идеально — готовые виджеты.
   Надеюсь, при третьем напоминании вы уловили, насколько это важно для разработки. 

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

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

Дизайн благодарен разработке за

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

2. Аккуратную вёрстку: всё как было задумано в макетах.
   Я до сих пор помню фичу, к которой у меня было 0 (ноль, zero) комментариев на дизайн-ревью (одной рукой пишу, другой слёзы счастья вытираю). 

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

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

5. То, что они есть.

   

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

---

Понял-принял, а делать-то что?

Вывод первый и самый важный: настраивайте процессы

Опять же, смотрим на дизайн-процесс только от момента согласования решения. Как это устроено у нас:

Пройдёмся подробнее:

Спецификация

По сути, это документ, необходимый для уменьшения степени неопределённости продуктовой фичи для остальных участников процесса. Очень выручает, когда что-то реализовано не так, и есть на что сослаться и сказать: «̶А̶ ̶я̶ ̶г̶о̶в̶о̶р̶и̶л̶а̶!̶ Это тут описано». Целое искусство — найти баланс между достаточным, но не избыточным описанием. 

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

Чек-лист

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

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

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

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

Груминг

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

Саппорт

Задача уходит в анализ или in progress разработчика, и начинается: тут непонятно, а тут глянули под капот — и всё совсем не так. Вопросы сыпятся дизайнеру как из рога изобилия, и важно оперативно отвечать, чтобы не тормозить процесс (насколько это возможно в плотном графике встреч). 

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

Дизайн-ревью (aka фронт-ревью)

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

Как может происходить приёмка:

• Онлайн: собирается созвон всех неравнодушных, QA или разработчик показывает экран и проходимся по флоу. Обязательно проверяем все платформы и не забываем про тёмную тему.

• Офлайн: дизайнер отсматривает решение по скринам и видео от QA или сам устанавливает тестовые сборки в XCode и Android Studio.

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

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

Иногда мы пользовались правом вето и откладывали релиз: да, это срывало сроки, обещанные менеджменту, но прод не увидел чего-то непотребного. Как и во всём, здесь тоже важно найти баланс. 

Если вам интересно узнать больше, читайте статью моей дорогой коллеги @KseniyaBelyaeva «Как дизайнеры тестируют, или Что такое дизайн-ревью» и обязательно внедряйте эту практику к себе. Главное, договоритесь с разработкой об обязательности процесса, донесите ценность мероприятий, и чтобы QA заводили задачи на разработчиков по комментариям дизайнера. 

Ура, фича на проде! 

И наконец-то, если на приёмке не выявлено критов, фича отрезается в релиз и постепенно докатывается до прода через несколько дней.

Да, опытный дизайнер знает, что это тоже ещё не конец — удача, если фича выиграет в A/B-тесте с первого раза, но всё равно уже можно испытать короткий миг катарсиса. 

Вывод второй: несите свет знаний в массы

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

Что можно сделать дизайнерам:

• Обучать Figma.
  Например, наш дорогой @vandesign писал статью «Скажи что-нибудь на разрабском, Figma» и записывал видеоролики, а фичёвые дизайнеры подсовывали этот контент своим разработчикам. 

• Объяснять ценность дизайна.
  Когда дизайнер может обосновать каждый прямоугольник в своём макете и почему эти прямоугольники сложены именно так, а не иначе, это вызывает ощущение, что решение осознанное, и в нём нельзя просто так взять и заменить одни прямоугольники на другие почти такие же. Как минимум, это нужно обсудить с дизайнером, ведь, возможно, он эти прямоугольники тестировал в Pathway 5 раз. 

• Развивать продуктовое мышление.
  Вовлекать команду разработки в продуктовую культуру — занятие увлекательное, но точно окупаемое в долгосрочной перспективе.
  1. Важно с самого начала относиться с должным уважением: перед тем, как разбирать макет под лупой на груминге, важно рассказать, а что мы вообще делаем, какая цель этой фичи, как мы с её помощью улучшим опыт пользователя и заработаем денег компании. В каком-то смысле, нужно продать идею разработчикам, чтобы они тоже эмоционально вовлеклись, даже если им сходу не нравится этот блюр фона и кастомная анимация.
  2. В процессе поддержки и дизайн-ревью также можно проговаривать: если это крит, то почему, какую продуктовую потребность мы не закрыли какими-то недоработками?
  3. И особенно важно вернуться к разработке в конце, о чём часто забывают когда A/B-тест проведён, и либо поделиться успехом (ребята смогут записать себе эти метрики в своё перфоманс-ревью), либо интерпретировать результаты неуспеха и что будет дальше. Если продакт и дизайнер забывают этим делиться, то разработчик может не знать о дальнейших планах на фичу и думать, что три месяца работы были в стол, ругаться об этом на ретроспективе и потом искать работу в модном стартапе. А может быть, всего лишь нужно дождаться следующей итерации, и всё взлетит.
  Процесс вовлечения разработчиков в продуктовую культуру не быстрый, но совместная работа выходит на качественно новый уровень, когда все участники процесса знают, куда продукт движется и какими способами.

Что можно сделать разработчикам: 

• Обучать, как устроена архитектура приложения.
  Нам повезло с командой мобильной разработки, которая генерирует немало контента, полезного и дизайнеру: это может быть внутренний митап от разработчиков ДС фичёвым разработчикам, или статья на Хабре о SDUI, или выступление про особенности релизного цикла. Тут главное не забывать друг друга приглашать и анонсировать. 

• Объяснять, почему так долго и дорого.
  Полезно проговаривать причины дороговизны решения: потому что здесь кастом, а здесь анимация, а здесь haptic, который мы ещё не трогали. Возможно, это поможет дизайнеру отсеивать потенциально дорогие решения ещё до груминга (но это неточно).

• Не стесняться предлагать решения.
  Встречный шаг навстречу вовлечённости в продукт: дизайнер чаще будет благодарен за советы и комментарии. Например, однажды мы принесли на груминг макеты регистрации юрлица, где нужно было собрать с пользователя определённую информацию. Бэкендер предложил другое решение: сделать всё под капотом, а данные подтягивать из справочника. Хоть макеты и отправились в стол, я не расстроилась: мы не добавили лишний шаг в регистрации и пользователи будут тратить меньше времени. И всё это благодаря неравнодушной разработке (Рома, Лёша, привет!) 

Вывод третий: коммуникация решает

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

• Давайте говорить на одном языке.
  У нас есть локальный девиз:

  

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

---

Подытожим

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

• Улучшить дизайн-процессы.
  Если ваши решения катятся до прода без нареканий, то можно пропускать этот пункт. Если нет, то можно внимательно посмотреть на процессы подготовки макетов: есть ли спецификация? есть ли чек-лист? а если есть — его точно используют? един ли он для всех команд? есть ли дизайн-ревью? есть ли регламент на дизайн-ревью, проверяются ли все платформы и тёмный режим?
  Если в Figma у дизайнеров всё отлично, а на проде — такое себе, значит, что-то где-то точно идёт не так. 

• Совершенствовать макеты.
  Если вспомнить, как оформляли макеты лет 5 назад (спасибо, если будут показаны разные брейкпоинты и описана логика парой предложений) и как сейчас — это небо и земля. Конечно, время работы дизайнера над задачей увеличилось кратно и иногда нужно полчаса, чтобы накидать виджет, но 2 недели, чтобы описать его, дотащить и проверить — и да, это теперь тоже работа дизайнера. Подстёгивает и сам тренд в индустрии, и это хорошо видно по развитию Figma — дизайнеры должны мыслить как разработчики при сборке макетов, и собранный на группах, а не на автолейаутах, макет уже выглядит постыдно. 

• Самообразовываться и образовывать коллег.
  В индустрии меняется всё очень быстро (даже быстрее, чем хотелось бы). Приходится исповедовать lifelong learning подход, и вдвойне эффективнее подпитывать культуру обмена знаниями между командами. Подсовывайте коллегам полезный контент, зовите на внутренние митапы, организовывайте синки — все средства хороши, если это укрепляет взаимопонимание. Тут нам повезло: у нас достаточно сильные комьюнити по направлениям. Что разработчики, что дизайнеры постоянно выступают с лекциями и пишут статьи, из которых можно почерпнуть тонну полезной информации и «переопылиться».

• Не расслабляться.
  Если не инвестировать своё время в выполнение этих пунктов, то можно очень быстро оказаться на профессиональной обочине. 

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

---

Что ещё по теме

Автор: Evgenia Marinina

Источник