Наташа пишет про IT

Конспект: "Как дизайну и разработке найти общий язык" (ч.1)



💳 поддержать мои гайды, лонгриды и просто задонатить на кофе - 5536913954129132 (Тиньк)



Это второй выпуск рубрики "Конспект" (первый - тут), в которой я буду публиковать сюда интересные материалы с краткой выжимкой.



Итак, сегодня принесла вам статью "Отрицание, гнев, торг: как дизайну и разработке найти общий язык".



❗️Статья очень большая, поэтому постов-выжимок будет два.



Почему я вообще принесла эту статью



Везде, где я работала, UI/UX-дизайнеры не были включены в продуктовую команду разработки, они жили отдельно, своими дизайнерскими командами со своими внутренними процессами. Контакт между дизайнерами и всеми остальными выглядел примерно так: "вот вам макеты, и живите с ними, как хотите".



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



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



Теперь выжимка (ч.1)



🟣основные боли разрабов при взаимодействии с дизайнерами:



🔘 неполные и неконсистентные макеты (не хватает экранов/состояний элементов/сообщений об ошибке или успехе/лоадеров);

🔘 вместо компонентов из дизайн-системы (если она есть), просят кастомные компоненты без объяснения причин;

🔘 дизайнеры не понимают ограничений разработки и рисуют "красивое";



🔵 основные боли дизайнеров при взаимодействии с разрабами:



🔘 реализуют макеты с очевидными багами, которые невозможно не заметить;

🔘 разрабы не вникают в макеты на этапе концепта (если им показывают) и заранее не указывают на ограничения;

🔘отказываются что-то делать, потому что это "слишком сложно/невозможно" (а потом оказывается, что и возможно, и не сложно);



❤️ что нужно улучшить, чтобы порадовать всех #1: делать больше совместных грумингов, чтобы разработка могла посмотреть на макеты несколько раз до того, как их полностью согласуют с продактами и C-lvl. Это уменьшит количество сложных ситуаций и переделок;



❤️ что нужно улучшить, чтобы порадовать всех #2: делать дизайн-ревью готового фронтенда заранее, а не за день до релиза, чтобы ревью и починка багов не делались с горящей жопой и с риском не выкатить релиз;



🟢 что отдельно можно улучшить, чтобы порадовать разрабов:



🔘если есть дизайн-система, стараться все, что можно, делать с ее помощью;

🔘стараться заранее продумывать все состояния компонентов и интерактивных элементов (ховеры, лоадеры, сообщения об успехе/ошибке, темную/светлую тему - если есть итд);

🔘повысить грамотность дизайнеров в плане ограничений платформ, чтобы не рисовали невыполнимое;

🔘указывать отдельно в фигме и в чатах, что в макетах что-то изменилось;



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



🔘 помочь дизайнерам повышать упомянутую "грамотность": организовать локальные внутренние ликбезы/митапы, делиться обучающими материалами;

🔘 разрабам - поучиться пользоваться фигмой, посмотреть пару туториалов (или почитать эту статью);



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