Четкое ТЗ и много общения: что нужно айтишникам и дизайнерам, чтобы понять друг друга

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

Понять друг друга

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

1. Понимание специфики работы друг друга. Когда дизайнер имеет представление о технических ограничениях, а разработчик осознает логику UX (англ. user experience — пользовательский опыт, — прим. ред.) и визуальной структуры, совместная работа становится продуктивнее. Она предполагает обмен знаниями.

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

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

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

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

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

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

В нашей компании дизайнеры сначала согласовывают макеты с фронтендерами и лишь потом показывают клиенту, ведь какие-то моменты, которые кажутся простыми, могут быть необоснованно сложными в реализации. А разработчики после завершения верстки отправляют каждую страницу на проверку дизайнеру. Он сразу заметит косметические баги и проблему с Pixel Perfect (подход, когда итоговый результат максимально точно совпадает с макетом), если они есть.

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

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

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

Идеальное ТЗ

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

Например, грамотно составленное техническое задание. Оно должно содержать:

• Цели и задачи — прописывается, зачем создается продукт и какие проблемы он должен решать. Раздел с функциональностью должен максимально конкретизировать запрос: какие страницы, разделы, кнопки, формы, фильтры нужны, что происходит при клике, как работает поиск, какие состояния у элементов.

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

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

Плохо составленное, расплывчатое ТЗ может быть просто невыполнимо — размытые формулировки, множество не связанных референсов и отсутствие конкретных сроков. Как следствие, разработка итогового решения затягивается: то дизайнер создает макет, который нельзя реализовать, то разработчик не выполняет требования дизайнера.

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

У нас в агентстве практикуется такой сценарий: дизайнер рассказывает идеи фронтендеру, тот сперва ищет несколько подходящих вариантов реализации и лишь затем дизайнер использует одну из предложенных для макетов.

Как контролировать работу

Улучшают совместную работу, конечно, и цифровые инструменты. Главное — не утонуть в бесконечных чатах и документах, а выбрать подходящий набор.

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

Сам дизайн мы создаем Figma — вносим правки в реальном времени, при этом фича Dev Mode помогает разработчикам быстро получить размеры, цвета и кодовые свойства.

Вопросы, которые требуют быстрых решений, обычно обсуждаем в корпоративных мессенджерах или Telegram-чатах. Лучше выбрать одну площадку для моментальной коммуникации и установить правила, что и как на ней обсуждается.

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

Как понять, что все получилось

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

• Соответствие UI-гайдам и макетам. Мы создали гайдлайны, чтобы разработчики не додумывавали детали, а ориентировались на них. Это важно сделать в самом начале проекта. На стадии проверки технические специалисты и дизайнеры просто сверяют то, что получилось, с тем, что задумали изначально.

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

• Функциональность. Все элементы работают так, как задумано: кнопки кликабельны, анимации плавные, формы валидируются, нет багов, которые мешают использованию (текст не налезает на кнопку, скролл не ломает верстку и так далее). Это, в том числе, проверяет команда тестировки.

• Кросс-браузерность и адаптивность. Дизайн не «разваливается» на разных устройствах и в разных браузерах, нет проблем с высокой нагрузкой или медленными соединениями.