Как дизайнеры могут сделать жизнь фронтов легче
Cайдбар №1: людей, у которых есть систематические, а не единичные проблемы считаем профнепригодными. Если дизайнер все время забывает какие-то состояния экранов, компонентов, не переиспользует, неаккуратен, невежлив — это не ок, однако, оставляем таких за рамками текста.
Сайдбар №2: если вы дизайнер интерфейсов и когда-нибудь решите написать на вакансию в Злые марсиане, считайте тред требованиями к соискателям.
Это ответочка к посту о том, как фронты могут сделать жизнь дизайнеров легче.
1. Дизайн-система
Жизнь фронта драматически улучшается, если в дизайне есть система. Почему: если систему не создаете вы, ее приходится создавать за вас фронтенд-инженеру — так устроен код, у них выбора нет.
Отсутствие системного подхода гарантированно приведет к постоянным конфликтам с инженерами. Так делать не круто, это часть нашей дизайнерской работы.
Дизайн-система (преступно коротко) это когда дизайн построен из ограниченных наборов текстовых и графических стилей, переиспользуемых компонентов и последовательных правил компоновки.
Круто, если при поддержке и развитии системы, дизайнеру не пофиг что там в коде и он занимает активную позицию в задаче двусторонней синхронизации компонентов. Например, оформляет все изменения как фичу или, хотя бы, не забывает предупредить.
В прошлом треде я писал, что круто, когда и фронт в этом вопросе не пассивен. Это все еще так, но это не повод наглеть и заставлять фронта постоянно ходить к вам с вопросами «а этот новый отступ это апдейт старого или как?»
2. Процесс работы
Фичи
Круто, если дизайнер, видя перед собой Очень Большую Фичу, заботится о своей команде и с ранних этапов обсуждения с клиентом, предлагает план как съесть слона по частям — достигнуть результата через серию небольших задач, которые можно дизайнить, верстать и выкатывать по очереди.
Не круто дизайнить что-то огромное месяц и потом вываливать на инженеров 50 макетов. В этом объеме будет очень тяжко разбираться. Вы и сами задолбаетесь объяснять по кругу как эта глыба работает. В итоге, вы как команда гарантированно где-то скосячите — проверено на себе всей историй IT, поверьте.
Ну и при последующей приемке верстки, вам же будет проще отсмотреть небольшой кусок, выдать фронту две просьбы что-то поправить, вместо того, чтобы пыхтеть два дня, в результате выкатить сотню правок, которые вам потом снова перепроверять. Это высосет жизнь и из вас, и из фронта.
Правило: разбивайте фичи на фичульки.
Круто, если дизайнер уважает мнение технической команды и понимает, что технические ограничения это просто часть устройства мира, не чья-то лень, не злой умысел.
Если нарисованное трудно реализовать, круто, если дизайнер проявляет инициативу, собирает дружелюбное и вежливое обсуждение, чтобы вместе придумать выход.
Круто, если дизайнер не напрягается от просьбы фронта объяснить свои дизайн-решения. Очевидно, никто не пытается вас уличить в косяках — инженер пытается разобраться в устройстве дизайна, чтобы делать свою работу осознанно. Вашему фронту не пофиг — это же круто, вам повезло!
Макеты
Круто, если дизайнер владеет золотой привычкой утверждать макеты у технической команды. Не знаю даже, нужно ли обосновывать — очевидно, что ребята, которые будут превращать картинки в работающий продукт, должны наблюдать за ходом дизайна и врубаться что происходит, чтобы вовремя ворваться со «стойте, запахло техническими проблемами».
Второй убитый заяц — к моменту, когда фича придет в разработку, инженеры уже будут примерно знать что там надо делать и почему решения такие.
Третий — вопросов про ваши дизайн-решения не будет, если все будут видеть откуда у них ноги растут.
Сайдбар: я сам вообще предпочитаю синкаться с командой несколько раз в день. Еще до макетов рассказываю в канале проекта словами идею решения, в процессе делюсь недоделанными кусками, объясняю каким путем решил пойти и почему. С таким подходом у команды появляется миллион шансов не только указать на невидимые мне проблемы, но и предложить идею покруче.
Передача в разработку
Очень круто, если дизайнер дизайнит не только продукт, но и... документацию фичи. Это значит, что а) вообще всё, что касается фичи, собрано в одном месте; б) все идеи графически и текстом объяснены.
Представьте длинный артборд в Фигме — собраны все экраны, касающиеся фичи, стрелочками показан флоу, нужные штуки подписаны, причем в контексте, варианты состояний показаны, тоже близко к контексту. Если фича ссылается к решениям из прошлых фич — нужное оттуда должно быть скопировано. Есть ссылка на таску в трекере.
У этого приема есть крайне полезный сайд-эффект: если фича понятно описана, то это не только помогает фронтам и другим инженерам быстрее разобраться что надо делать, но и а) упрощает дизайнеру демонстрацию клиенту, б) сам дизайнер, вернувшись к фиче через год, сможет восстановить что и почему делал.
Правило: 100% знаний о фиче должно быть собрано в одном месте.
3. Знания
Круто, если дизайнер в курсе технологий. Например, чувствует себя уверенно, чтобы найти на Гитхабе нужный файл, поправить пару строк и оттуда же из веб-интерфейса закоммитить изменения на проверку инженерами. Или понимает, что если приложение использует геолокацию, то она может быть отключена на устройстве пользователя.
Не стоит кипятиться, никто не требует знаний, как у инженеров. Не надо уметь настраивать Вебпак, писать на Реакте. Осваивать чужую профессию не надо.
Однако, понимание синтаксиса HTML и CSS, блочной модели, как браузер строит веб-документ, что такое DOM — это правда не рокет-саенс. Это несложные и базовые, особенно для дизайнеров интерфейсов, знания. Буквально основа профессии.
Отдельно круто, если дизайнер сам умеет технически реализовывать спецэффекты. Например, знание синтаксиса описания анимаций на CSS позволит не мучать фронта три часа «а давай вот тут чуть плавнее», а самостоятельно отполировать анимацию до идеала.
* * *
Вот, кажется, и все. Если вам кажется, что все перечисленное не ваша работа, поверьте, вам стоит пересмотреть свои взгляды. Мой опыт показывает, что от этих штук одни выгоды — атмосфера в команде классная, все на одной волне, продукт идет бодро, без критичных косяков. В итоге у вас растет зарплата, потому что вы объективно становитесь более лучшим профессионалом и вас рекомендуют коллеги.
Комментировать текст лучше в твитер-треде.
Ссылки по теме
Как выглядит хороший макет — Блог Михаила Озорнина
P. S. Открытые вакансии в Злых марсианах.