Как не изгадить жизнь вашему разработчику — рекомендации дизайнера из Facebook

Часто бывает так, что коллеги находятся по разную сторону баррикад. И хотя они должны работать вплотную друг с другом, эта «плотность» чаще приводит к трениям, чем к плодотворной работе. Так тестировщики порой проклинают программистов, а программисты — дизайнеров. Дизайнер Facebook Чарли Дитс научился находить с разработчиками общий язык. Оказывается, для этого много не нужно — достаточно просто понять их. И следовать этим трем советам.

«Я дизайнер и я не хочу ничего понимать. Я хочу креативить.

Я дизайнер и я люблю программистов. Может, даже сильнее, чем полагается. Помню, когда я только присоединился к команде сообществ в Facebook, я много пенился, общаясь с iOS-разработчиком, который уже какое-то время поработал в компании. Я извергал из себя истории о том, как мне приходилось управляться с Objective-C. Как если бы я был первокурсником и доказывал старшекурсникам, что достаточно крут, чтобы с ним тусоваться.

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

Добро пожаловать в DOM

Научитесь кодить

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

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

Если вы работаете в iOS с привязанными к сетке макетами, поиграйте с UICollectionView и посмотрите, как там все происходит. Изучите существующие ограничения. Если вы веб-дизайнер, ознакомьтесь с фреймворками, которые использует ваша команда, как и почему они обращаются с DOM. Идея в том, чтобы научиться говорить с инженером на одном языке, тогда команде будет проще приходить к взаимовыгодным решениям.

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

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

Не объясняйте — делайте прототип

Вы, наверное, не раз произносили такую фразу: «Почему бы нам не сесть вместе, и я буду объяснять тебе все по мере того, как ты будешь писать». Не делайте так. Как бы вам понравилось, если бы ваш проджект-менеджер заявил: «Давай сядем вместе, и я буду объяснять тебе, что нам нужно, по мере того, как ты будешь рисовать»?

Важно сделать прототип проекта.

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

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

Я большой фанат использования Framer в своих прототипах. Это мощный инструмент, построенный на коде, благодаря чему я могу лучше предвидеть и доносить до разработчиков сложные анимации, потому что для этого мне самому сперва приходится в них разобраться. Многие дизайнеры в Facebook используют Origami. Люди часто говорят, что в Origami они могут создавать UX-модели даже лучше, чем без него, потому что инструмент очень гибкий и креативный.

Предоставьте инженеру такую спецификацию, какую хочет он

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

Спецификация видео-плеера для Джо Лифриери. Никакой двусмысленности

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

Выводы

Легко говорить о своих обязанностях с позиции названия должности. Но если копнуть глубже, все мы — кучка людей, работающих над созданием одного и того же продукта. Мне помогает отношение к самому себе, как к «специалисту по дизайну», командному игроку. Идеи могут исходить от «специалиста по проджект-менеджменту» или «специалисту по анализу» — от кого угодно. К концу дня я должен завершить все задачи по дизайну, но на этом не заканчивается область, в которой я могу пригодиться.

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

Источник: Medium