Как построить успешное сотрудничество дизайнера и веб-разработчика. Выводы из опыта

20.10.2021 Всем привет! Я занимаюсь коммерческой разработкой сайтов более трех лет. Сейчас Webmaster в DataArt. Поскольку работаю в дизайн-студии и сам имел опыт в дизайне, тема работы дизайнера и разработчика бок о бок меня интересовала всегда. Ведь считаю, что хороший результат - это прежде всего налажена работа всех участников, которые работают для его достижения.

В статье рассмотрю:

базовые и важнейшие пункты для эффективного сотрудничества дизайнера и вебразработчика;
успешную передачу дизайна в разработку (на что нужно обращать внимание дизайнеру и вопросы желательно задавать вебразрабу)
неудобные кейсы из жизни при работе с готовым дизайном.
Эта тема будет интересна тем, кто хочет ознакомиться с процессом сотрудничества дизайнера и разработчика, наладить взаимодействие с дизайнером или разработчиком или построить взаимодействие этих специалистов для достижения поставленных задач.

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

Основы эффективного сотрудничества

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

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

рабочие отношения
Когда мы делимся опытом, становимся более профессиональными и даем другим ту информацию, которую они давно искали или должны искать - это win-win со всех сторон. Дизайнер, к примеру, может предварительно узнать, как сложно будет создать определенные дизайн-решения разработчику, как это повлияет на время выполнения и бюджет проекта. А разработчик - более четко понять, почему именно такие дизайн-решения являются важными для проекта. Такое часто возникает, когда продукт уже на стадии внесения определенных поправок и нужно добавить новый функционал (фильтрацию, вывод информационных блоков, акционные предложения, списки желаний). Важно проговорить это с разработчиком и понять, плановые изменения можно выполнить быстро и без особых усилий, или это будет непросто, потому предусматривать изменение структуры главных блоков. Это в реалиях близкого дедлайна лучше упростить. Правильное решение таких моментов являются ключевыми в здоровых рабочих отношениях. Сейчас на большинстве проектов я веду диалог с дизайнером о предстоящих изменениях, и порой случается, что еще на этапе дизайна удается влиять на решение. Это меня сильно радует, ведь так я причастен к разработке на более глубоком уровне.

Раннее вовлечение в проект

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

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

гибкость разработки
Выполнение малых кусков работы и их проверка помогают убедиться, что все идет как надо. Двусторонние проверки друг друга позволяют избегать узких мест в коммуникации и интеграции. Прозрачность разработки проявляется в частом ДЭПЛ готовой работы для просмотра в реальном времени всеми заинтересованными сторонами и соответственно видимости всех изменений в дизайне, когда есть доступ к генеральному файла.

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

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

Введение в контекст

Это больше касается разработчиков. Ведь когда они будут понимать, какой именно продукт разрабатывают, смогут избежать и решить больше проблемных участков заранее. Привлекайте разработчика в процесс, создавайте идеи вместе. Научите его думать о конечного пользователя продукта / сервиса. Разъясните, кто является его бренд-персоной, ведь персонификация помогает лучшему запоминанию главных идей, требований продукта. К примеру, нужно разработать дизайн страницы по резервированию помещения. Эта страница может иметь разное наполнение и вид. Для генерирования идей сначала следует создать базу понимания продукта и пользователя. Здесь на помощь должна прийти дизайнер и рассказать о продукте основную информацию: какое его задачи, он решает, что уникального. Но главное - это понять потребность пользователя. Удобно создать персоны - это реальные пользователи. Ведь при разработке мы думаем о реальной человека с его потребностями, стилем жизни, предпочтениями.

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

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

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

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

Инструкции по стилю интерфейса (UI Style Guide)

Составляя для команды «шпаргалку» по построению дизайна по определенным правилам, нужно обращать внимание на то, чтобы документация дизайн-компонентов касалась только важных аспектов. Это должен быть инструмент, который можно использовать быстро и легко. Также он должен быть актуален и доступен для каждого члена команды. Основные части обычно содержат: схемы типографики, палитру цветов, дополнительные компоненты пользовательского интерфейса и так называемые «делайте / не совершайте» ( примеры правильных и неправильных элементов интерфейса и их соответствующего применения).

Дизайн-система

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

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

Экономия времени на работу с вопросами и предложениями
Чтобы к дизайнеру было меньше вопросов и его не отвлекали слишком часто при работе, стоит выделить отдельное время на вопрос, обзоры и другие внутренние уточнения и согласовать его с разработчиком. Интерактивные прототипы не у всех проектах нужны и не всегда на них время. Однако это сэкономит много времени на разработку, ведь специалист будет быстрее работать, чем если бы он пользовался статическим прототипом. Также нередко сайты (особенно landing pages) содержат анимационные эффекты, для удобства и более четкого понимания давайте разработчику ссылки на платформы, где это сделано в похожем виде.

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

Готовый набор элементов интерфейса (UI Kit)

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

Запланирована встреча для передачи дизайна
После отсылки всех материалов дизайнеру стоит запланировать встречу с разработчиком, на которой он ответит на его вопросы, расскажет о деталях дизайна и его правильное выполнение, укажет, на что обратить внимание, объяснит бизнес-логику, если она необходима в дизайн-решениях.

Вопрос к дизайнерам могут быть следующие:

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

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

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

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

(586 рейтинг, средний 4,2 из 5)
Как построить успешное сотрудничество дизайнера и веб-разработчика. Выводы из опыта
  • IT
  • 586
  • Дата публикации 01.07 20

Смотрите похожие записи