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

  • 13 июля, 07:23
  • 4303
  • 0

Автор: Анатолий Лукавенко, Webmaster в DataArt

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

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

  1. базовые и самые важные пункты для эффективного сотрудничества дизайнера и веб-разработчика;
  2. успешную передачу дизайна в разработку;
  3. неловкие кейсы из жизни веб-разработчика при работе с готовым дизайном.

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

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

ОСНОВЫ ЭФФЕКТИВНОГО СОТРУДНИЧЕСТВА

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

Уважение

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

Рабочие отношения

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

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

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

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

Гибкость разработки

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

Понимание

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

Открытая коммуникация

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

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

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

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

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

УСПЕШНАЯ ПЕРЕДАЧА ДИЗАЙНА В РАЗРАБОТКУ

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

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

РУКОВОДСТВО ПО СТИЛЮ ИНТЕРФЕЙСА (UI STYLE GUIDE)

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

ДИЗАЙН-СИСТЕМА

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

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

Стандарты наименования

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

Экономия времени на работу с вопросами и предложениями

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

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

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

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

Запланированная встреча для передачи дизайна

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

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

  1. Какие браузеры должен поддерживать продукт?
  2. Какую дизайн-систему использовали или заимствовали?
  3. Какой фреймворк желательно использовать?
  4. Будет ли возможность у клиента менять контент самостоятельно?
  5. К кому обращаться, если возникнут вопросы по разработанному дизайну?
  6. Какой должна быть точность выполнения дизайна, какие страницы не требуют точной детализации?
  7. Где возможны изменения в дизайне в будущем?
  8. Как будут информировать разработчика, если возникнет необходимость внести изменения?
  9. Какие страницы желательно делать в первую очередь, а какие могут подождать?

Ключевые принципы передачи дизайна в разработку

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

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

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

НЕЛОВКИЕ КЕЙСЫ ИЗ ЖИЗНИ ВЕБ-РАЗРАБОТЧИКА ПРИ РАБОТЕ С ГОТОВЫМ ДИЗАЙНОМ

Адаптивный и резиновый дизайны

Если вы разрабатываете дизайн и продукт для нескольких расширений, то можете на финальном этапе обнаружить скачки во время изменения размеров экрана. На то есть много причин, но разработчик должен уточнить, какой подход ему выбрать к созданию верстки продукта с хорошим адаптивом — от самого маленького до самого большого экрана (mobile first) или наоборот (desktop first). Кроме этого, существует элементный подход (element first), когда мы фокусируемся не на расширении, а на элементах дизайна и том, как они будут выглядеть на экранах разного размера.

Состояние наведения

Состояние hover показывают на кнопках, однако нередко забывают показать на отдельных элементах дизайна. Это могут быть цитаты и другие поля текста или картинок. Лучше всего демонстрировать все состояния динамических интерактивных элементов. И не забывайте о скорости и виде перехода (transition) из одного состояния в другое.

Индикатор фокуса

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

Организация слоев

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

Ширина контента

Иногда ширина текстовых полей, заголовков и т. п. должна быть разной для разных размеров экрана. Такие размеры следует указывать отдельно, отмечая максимальную и минимальную ширину для этого контента. Если разработчик будет сразу знать о разной ширине некоторых элементов контента, то будет использовать правильные инструменты. Например, есть такие варианты grid-template-columns.

Бывает, что select box слишком короткий для некоторых элементов из списка выбора. Это также нужно учитывать, чтобы разработчику потом не приходилось придумывать, как обойти эту проблему.

Темная тема

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

Фиксация

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

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

Нетипичные случаи

Хороший дизайнер всегда помнит о нетипичных случаях поведения сервиса/продукта, сбоях в системе и их логическом представлении пользователю: ошибки, предупреждения, оповещения. Абсолютно все случаи, конечно, проработать сложно, но если хотя бы большинство будет показано или описано в дизайне, это не только облегчит жизнь разработчикам, но и создаст лучший пользовательский опыт.

Мультиязычность

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

Состояния полей форм

Очевидно, что в дизайне нужно показывать все состояния полей форм. Однако, как показывает практика, многие об этом забывают. Главное — помнить о всех видах состояний. Самые популярные: normal, errors, mandatory, focused, typing, disabled.

Анимация

Не стоит недооценивать анимацию и микровзаимодействия. Они не только персонализируют продукт с помощью финальных штрихов, но и улучшают UX. Удобный инструмент для дизайнеров — Lottie от Airbnb. Он позволяет работать с анимацией в AfterEffects, экспортировать в .json и главное — просматривать готовый результат перед передачей дизайна в разработку.

ЗАКЛЮЧЕНИЕ

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


0 комментариев
Сортировка:
Добавить комментарий

IT Новости

Смотреть все