Сотрудничество между дизайнерами и разработчиками — это важный элемент создания отличных продуктов. У каждой компании есть своя организационная структура как для дизайнеров, так и для разработчиков. В некоторых компаниях, представители этих профессий работают в двух разных командах. Также, разработчики могут делиться на подкоманды, например, фронт и бэк-энд разработка. В других компаниях, дизайнеры и разработчики работают в одной команде. Но независимо от ситуации, постоянное сотрудничество между ними очень важно для успеха проекта.
Как разработчик, я участвовал в разработке многих дизайнерских проектов. Также, я работал дизайнером, и поскольку я был по обе стороны баррикад, то могу поделиться несколькими советами, которые помогут дизайнерам лучше сотрудничать с разработчиками.
1. Постоянно общайтесь с разработчиками с самого начала проекта
Я считаю, что общаться с дизайнерами очень полезно. Не только во время передачи проекта. Участие в беседах, которые определяют функционал продукта, позволяет мне заранее подготовиться к работе. Дизайн — это совместная работа, и разработчики являются ее неотъемлемой частью.
Я часто видел дизайнеров и разработчиков, которые выполняли схожие задачи. Дизайнеров, которые писали свой код, разработчиков, принимавших участие в вайрфрэйминге, прототипировании, и визуальном дизайне.
Если дизайнер в чем-то не уверен, я бы предпочел, чтобы он проконсультировался со мной или моими коллегами. Мы не такие страшные! Дизайнеры часто интересуются моим опытом в других проектах. Я, также, часто обращался к разработчикам, во время работы над вайрфрэймами низкой точности. У некоторых опытных разработчиков, с которыми мне приходилось работать есть масса опыта и знаний в разных областях. Если разработчик уже какое-то время работает над проектом, то возможно, он сможет увидеть что-то, что вы пропустили.
2. Тщательно описывайте взаимодействия
Описания и документация помогают мне убедиться в том, что я ничего не пропустил, особенно, когда речь идет о взаимодействиях. Пишите свои описания, или используйте инструменты, вроде Sketch Notebook. Уточните, как должны выглядеть разные состояния кнопок, создайте диаграммы, и т.д.
Ниже, я приведу несколько вопросов, о которых я думаю, когда вы приносите мне дизайн страницы результатов поиска:
- Будем ли мы динамически загружать такое же количество результатов под текущим списком?
- Будем ли мы использовать анимацию при загрузке результатов?
- Что должно произойти, когда мы доходим до последнего результата? Можно ли удалить кнопку «Загрузить еще?»
- Будем ли мы использовать спиннер во время загрузки результатов?
Если вы дизайнер, то некоторые из этих вопросов покажутся вам закономерными. Как дизайнер, я понимаю, насколько просто предполагать, что все должны понимать, как что-то должно себя вести. Поэтому, когда я вижу, что что-то можно интерпретировать по-разному, я стараюсь добавить краткие и понятные описания.
Если у меня нет описания, или я не вижу похожую функцию, которая уже была бы реализована, или если дизайнера нет на месте, я принимаю решение самостоятельно, или консультируюсь с коллегами, чтобы можно было продолжить работу. Про себя же, я говорю что-то вроде: «Надеюсь это именно то, что они имели ввиду, потому что я бы сделал это именно так!». Только затем, я согласуюсь с дизайнером. Однако на все эти вопросы могли бы ответить сами дизайнеры в описании, что сэкономило бы мне время на подтверждение, и внесение изменений, которых в противном случае можно было бы избежать.
Рекомендации по стилю, также, способны поддерживать постоянство при разработке продукта. Однако, большинство моих коллег работают самостоятельно, сверяясь с рекомендациями по стилю только если это абсолютно необходимо.
3. По возможности, вместо статичных вайрфрэймов создавайте прототипы
Иногда это невыполнимо, но старайтесь, по возможности, создавать прототипы, или анимации взаимодействия. Они показывают мне (и всем, кто работает над проектом), как этот элемент или взаимодействие должны работать.
4. Выделите время для объяснений, вопросов, и обзоров
Для плавного продвижения проекта, свободное общение играет важную роль. У всех свои приоритеты, и все думают по-разному, поэтому общение поможет вам гарантировать, что все занимаются одним делом. Даже, если дизайнеры и разработчики находятся в разных организациях одной компании, открытое общение все равно возможно. Некоторые разработчики, из тех, с которыми мне приходилось работать, ненавидят телефонные разговоры и встречи. Другим не нравится получать уведомления по электронной почте. Найдите подход к каждому, и общайтесь с ним на его языке.
5. По необходимости подстраивайтесь под наши рабочие процессы
Узнайте побольше о наших рабочих процессах, и адаптируйтесь к ним. Пишите JIRA тикеты, чтобы все понимали, когда пришло время начать работу над очередной функцией.
6. Будьте организованы
Как разработчик, какие-то иконки я получаю в виде вложений в e-mail, а другие, в виде сообщений, с описанием местонахождения файла. Иногда, мне приходится рыться в куче папок, чтобы найти последние дизайны. Не нужно усложнять другим жизнь!
Когда я получаю чистые, хорошо организованные файлы, процесс разработки идет намного быстрее и проще. Создайте единое хранилище для файлов, с понятной иерархией каталогов. Это особенно важно, когда мне приходится работать с несколькими дизайнерами одновременно, и у каждого есть свой взгляд на вещи.
7. Проведите пользовательское исследование, и поделитесь его результатами с разработчиками
В какой-то мере, каждый участник проекта должен быть вовлечен в исследовательский процесс. Это может быть прослушивание звонков, просмотр записи, или чтение стенограммы. Это может показаться тратой времени, однако, такой подход поможет вам лучше понять пользователей.
Мне, как разработчику, очень важно понимать пользователя, для которого я создаю продукт. Это дает мне видение того, что нужно сделать в первую очередь, и почему.
Перевод статьи Валинды Чан
