Как дизайнеру общаться с разработчиками
Привет, меня зовут Дима Лыжин и я дизайнер интерфейсов. За время работы с разработчиками накопились мысли, хотел с вами поделиться.
В этой статье не будет конкретных примеров про грамотную передачу градиента или создания мягкой тени для разработки на андроид. Я хотел бы поговорить об общей теме разделения на “разработку” и “дизайн”, на “своих” и “чужих”.
Два народа жили в мире. Все изменилось, когда появились дизайн требования…
Ох уж эти дизайн требования… Представьте, вы сделали дизайн, отдали в разработку и спокойной совестью ушли пить кофе. Прошло время, по вашим макетам сверстали дизайн и вы с ужасом обнаруживаете, что межстрочник не тот, выравнивание съехало, а иконки как-то странно уходят в мыло. Знакомо? Думаю, бывало со всеми.
Тут каждый может фыркнуть в сторону разработчиков, свалив всю вину на них, но от них здесь только половина. Корень проблемы — недостаток межотдельной коммуникации. Давайте разбираться.
Все мы понимаем, что для грамотной разработки нужны грамотные требования, однако проблема часто заключается в том, что видение “грамотности” у дизайнера и разработчика сильно различается. Иногда в компаниях процесс выстроен как бы по комнатам. Макеты создаются в комнате дизайна, через узкое окошко передаются в комнату разработки, в которой вообще неведомо, что происходит. Из-за такой схемы, когда у разработчика возникают вопросы, он просто не может спросить дизайнера, потому что он в другой комнате, а окошко открывается только в момент передачи макетов.
Более того, в некоторых коллективах может быть распространено разделение на “нас” и “их”. То есть существуют некие “они”, которые чаще всего виноваты во всех смертных грехах и всегда что-то не понимают, несут бред и вообще странные ребята. Для дизайнеров “они” могут быть разработчиками, а для разработчиков “они” — дизайнеры, которые опять навыдумывали какой-то ерунды.
Дизайнер+ разработчик = ❤️
После передачи макетов не нужно закрываться в себе, уходить по-английски и забывать про свое детище. В разработке слишком много камней, о которых дизайнер может даже не догадываться, и, если у разработчика возникнуть вопросы, а дизайнера рядом не будет, он найдет ответ на них сам.
Постройте свой процесс так, чтобы разработка принимала участие на самых ранних этапах проработки функционала и интерфейса. Допустим вы работаете над новой фичей. Не поленитесь, закиньте встречу или выгрузите предварительные экраны и покажите их разработке. Поверьте, никто вас не побьет за не проработанные макеты, а разработчики смогут задать свои вопросы и подсказать, как будет проще реализовать задуманную вами механику. Зачастую случается так, что дизайнеры улетают в далекий космос и придумывают нереализуемые, очень тяжелые концепции, которые могут сломать весь пользовательский опыт и быть крайне трудно реализуемые. Здесь вам на помощь и придет супергерой-разработчик, который поможет докрутить ваш функционал до рабочего состояния. На этом этапе есть высокий соблазн отвергнуть все предложения разработки и отмахнуться от них, сославшись на то, что разработчики ничего не понимают. Но я призываю вас прислушиваться, обсуждать и искать решения, которые будут удачны со всех сторон.
Такой подход поможет избежать не только недопонимания между отделами, сэкономит вам время и нервы, но и может открыть неочевидные кросс-функиональные решения для вашей задачи.
Дизайнерам в свою очередь нужно, не отпускать макеты на самотек дальше по процессу. Сопровождайте их на каждом этапе. Разработчики всегда могут дать вам пощупать то, что они делают. Попросите ранний билд приложения, раннюю версию сайта, чтобы самому все посмотреть и пощупать. Важно иметь в процессе итерации дизайн-ревью еще на этапе разработки. Вот просто брать и руками тыкать в еще сырую версию. Это позволит вам отловить недочеты и ошибки на ранних этапах, когда цена ошибки пока не так велика. Помните, то что для вас кажется естественным и очевидным, может не быть таковым для разработки. Помогайте им в этом.
Долой еженедельные митинги с разработкой! Стоп, что?!
Хорошо, когда в процессе предусмотрены итерации, где два отдела встречаются раз в (выбери свой промежуток) и обсуждают накопившиеся вопросы. Но здесь кроется одна не самая очевидная проблема: некоторые вопросы могут просто не дожить до этого митинга. Возможно, разработчик сам нашел на них свой ответ, разработчик решил вопрос его в уме до митинга и забыл, кто-то посчитал вопрос недостаточно значимым, чтобы выносить его на митинг, где обсуждаются самые важные вопросы за какой-то отрезок времени и еще куча причин, почему вопрос не дошел до дизайнера.
Вместо этого (или в дополнение) создайте среду, в которой дизайнеры и разработчики могут общаться без ожидания очередного митинга. Создайте общий чатик, куда каждый человек может прийти, задать свой вопрос и быстро получить на него ответ. Согласитесь, ведь гораздо лучше, если разработчик при первом подозрении на неоднозначность в требованиях не придумает ответ сам, а напишет дизайнерам. С общим чатом, это сделать гораздо проще, чем письмом или каким-нибудь другим видом корпоративной коммуникации.
А еще чат поможет двум командам познакомиться, они перестанут быть друг для друга эфемерными загадочными “разработчиками” и “дизайнерами”.
Хорошо, когда в процессе предусмотрены итерации, где два отдела встречаются раз в (выбери свой промежуток) и обсуждают накопившиеся вопросы. Но здесь кроется одна не самая очевидная проблема: некоторые вопросы могут просто не дожить до этого митинга. Возможно, разработчик сам нашел на них свой ответ, разработчик решил вопрос его в уме до митинга и забыл, кто-то посчитал вопрос недостаточно значимым, чтобы выносить его на митинг, где обсуждаются самые важные вопросы за какой-то отрезок времени и еще куча причин, почему вопрос не дошел до дизайнера.
Вместо этого (или в дополнение) создайте среду, в которой дизайнеры и разработчики могут общаться без ожидания очередного митинга. Создайте общий чатик, куда каждый человек может прийти, задать свой вопрос и быстро получить на него ответ. Согласитесь, ведь гораздо лучше, если разработчик при первом подозрении на неоднозначность в требованиях не придумает ответ сам, а напишет дизайнерам. С общим чатом, это сделать гораздо проще, чем письмом или каким-нибудь другим видом корпоративной коммуникации.
А еще чат поможет двум командам познакомиться, они перестанут быть друг для друга эфемерными загадочными “разработчиками” и “дизайнерами”.
И что?
Подводя итог, скажу что нужно выходить из своей уютной дизайнерской комнаты, пытаться выстраивать отношения с разработкой, даже если не очень хочется. Так вы сможете не только прокачаться в своем ремесле, но еще и почерпнуть знания из соседних областей. А еще и процесс улучшите!
Ну а если вам эта статья ничего полезного не дала и показалась очевидной, то я очень рад, что вам удалось прийти к такому подходу. Так держать!
Курсы со скидкой 55%. Промокод DESIGNPUB.
