Часто бывает так, что коллеги находятся по разную сторону баррикад. И хотя они должны работать вплотную друг с другом, эта “плотность” чаще приводит к трениям, чем к плодотворной работе. Так тестировщики порой проклинают программистов, а программисты – дизайнеров. Дизайнер Facebook Чарли Дитс научился находить с разработчиками общий язык. Оказывается, для этого много не нужно – достаточно просто понять их. И следовать этим трем советам.
“Я дизайнер и я не хочу ничего понимать. Я хочу креативить.
Я дизайнер и я люблю программистов. Может, даже сильнее, чем полагается. Помню, когда я только присоединился к команде сообществ в Facebook, я много пенился, общаясь с iOS-разработчиком, который уже какое-то время поработал в компании. Я извергал из себя истории о том, как мне приходилось управляться с Objective-C. Как если бы я был первокурсником и доказывал старшекурсникам, что достаточно крут, чтобы с ним тусоваться.
Я заметил, что многие дизайнеры не умеют общаться с программистами. Они с ними разговаривают, но при этом не пытаются взаимодействовать. Поэтому я написал эту колонку. Часть наших обязанностей как дизайнеров – понимать, с какими проблемами сталкиваются программисты. Именно это поможет сделать процесс создания продукта более эффективным.
Добро пожаловать в DOM
Научитесь кодить
Я осознаю, что это может прозвучать напыщенно. На самом деле, это не так. Вам не нужно уметь круто программировать, чтобы понять, через что придется пройти вашему программисту. Кодить – его работа, а вам достаточно знать хотя бы основы, чтобы, как минимум, понимать то, что он говорит. Поэтому научитесь программировать.
Я считаю, что будучи в состоянии понять основные принципы программирования, можно создавать проекты, которые реально осуществимы. Если вы научитесь предугадывать, как все это будет выглядеть и работать после реализации, то с самого первого дня будете двигаться в ногу со своим разработчиком.
Если вы работаете в iOS с привязанными к сетке макетами, поиграйте с UICollectionView и посмотрите, как там все происходит. Изучите существующие ограничения. Если вы веб-дизайнер, ознакомьтесь с фреймворками, которые использует ваша команда, как и почему они обращаются с DOM. Идея в том, чтобы научиться говорить с инженером на одном языке, тогда команде будет проще приходить к взаимовыгодным решениям.
Представьте себе самый маленький проект и сделайте его самостоятельно. Отметьте, с какими сложностями вы столкнулись. Через какое-то время, если вы будете периодически этим заниматься, то в следующий раз, когда ваш разработчик скажет, что в дизайне нужен “сдвиг модели”, вы поймете, что он имеет ввиду.
Помните, совсем не обязательно уметь хорошо кодить. А уж тем более, не нужно самому становиться девелопером. Достаточно изучить основы и концепции, чтобы понимать своих разработчиков.
Не объясняйте – делайте прототип
Вы, наверное, не раз произносили такую фразу: “Почему бы нам не сесть вместе, и я буду объяснять тебе все по мере того, как ты будешь писать”. Не делайте так. Как бы вам понравилось, если бы ваш проджект-менеджер заявил: “Давай сядем вместе, и я буду объяснять тебе, что нам нужно, по мере того, как ты будешь рисовать”?
Важно сделать прототип проекта.
Кто-то скажет, да ну, проще сказать “я хочу чтобы бокс расширялся от верхнего края и потом в него из центра вставлялась картинка”, чем сделать такую вот гифку. Ваша работа – сделать прототип того, как ваш дизайн должен работать в итоге. Иначе это вообще не дизайн.
В хорошем прототипе двусмысленности быть не может. Из него разработчик почерпнет всю информацию о том, как должен работать продукт. Да, на создание прототипа нужно время, но в итоге масса времени, потраченного на устные объяснения, недопонимание и переделывание, будет сэкономлена.
Я большой фанат использования Framer в своих прототипах. Это мощный инструмент, построенный на коде, благодаря чему я могу лучше предвидеть и доносить до разработчиков сложные анимации, потому что для этого мне самому сперва приходится в них разобраться. Многие дизайнеры в Facebook используют Origami. Люди часто говорят, что в Origami они могут создавать UX-модели даже лучше, чем без него, потому что инструмент очень гибкий и креативный.
Предоставьте инженеру такую спецификацию, какую хочет он
Это о том, что нужно относиться к инженерам как к людям, а не машинам. Каждый программист смотрит на спецификацию по-своему. Один хочет безукоризненную спецификацию, чтобы все соответствовало вплоть до пикселя. Другой может использовать заготовленные компоненты и ваши подробные разметки ему не нужны.
Спецификация видео-плеера для Джо Лифриери. Никакой двусмысленности
Узнайте, что хочет видеть ваш разработчик, и дайте ему это. Вникните в их работу, и когда вы оба наберете хороший рабочий темп, то сэкономите уйму времени, которое могли бы потратить на ненужные вещи.
Выводы
Легко говорить о своих обязанностях с позиции названия должности. Но если копнуть глубже, все мы – кучка людей, работающих над созданием одного и того же продукта. Мне помогает отношение к самому себе, как к “специалисту по дизайну”, командному игроку. Идеи могут исходить от “специалиста по проджект-менеджменту” или “специалисту по анализу” – от кого угодно. К концу дня я должен завершить все задачи по дизайну, но на этом не заканчивается область, в которой я могу пригодиться.
Когда вы начинаете вникать в рабочий процесс, все как-будто ускоряется. Потому что работать в команде – гораздо эффективнее, чем работать самому по себе. Познакомьтесь со своими разработчиками, поймите их проблемы, поинтересуйтесь их задачами. Возможно, благодаря этому в следующий раз, когда вам сильно понадобиться более светлый оттенок серого, ваш программист отнесется к этому с пониманием”.
Источник: Medium
