Как разработчики интерфейса могут помочь преодолеть разрыв между дизайнерами и разработчиками
Опубликовано: 2022-03-10В течение последних девяти лет почти каждый дизайнер, с которым я работал, выражал мне свое недовольство тем, что им часто приходилось проводить дни, давая обратную связь разработчикам, чтобы исправить интервалы, размеры шрифта, визуальные аспекты, а также аспекты макета, которые просто не были правильно реализованы. . Это часто приводило к ослаблению доверия между дизайнерами и разработчиками и вызывало немотивированность дизайнеров, а также плохую атмосферу между двумя дисциплинами.
Многие разработчики все еще имеют плохую репутацию чрезмерно технических и невежественных, когда дело доходит до внимания к деталям, которые придумала команда разработчиков. Согласно статье Энди Бадда, «[…] многие разработчики находятся в таком же положении в отношении дизайна — они просто этого не осознают». Однако на самом деле (как указывает Пол Боуг) «разработчикам [должно] постоянно приниматься проектные решения».
В этой статье я дам практические советы разработчикам интерфейса, чтобы избежать разочарований и повысить производительность при работе с их творческими коллегами.
Глядя глазами дизайнера
Давайте на мгновение представим, что вы были дизайнером и потратили последние недели — если не месяцы — на разработку дизайна веб-сайта. Вы и ваши товарищи по команде прошли несколько внутренних изменений, а также презентаций для клиентов и приложили огромные усилия для точной настройки визуальных деталей, таких как пустое пространство, стили шрифтов и размеры. (В эпоху адаптивности — конечно, для экранов разных размеров.) Дизайн был одобрен клиентом и передан разработчикам. Вы чувствуете облегчение и радость.
Через несколько недель вы получаете электронное письмо от своего разработчика, в котором говорится:
«Промежуточный сайт настроен. Вот ссылка. Не могли бы вы, пожалуйста, QA?»
В предвкушении вы открываете эту промежуточную ссылку и после прокрутки некоторых страниц замечаете, что сайт выглядит немного не так. Интервалы даже близко не соответствуют тому, что предлагает ваш дизайн, и вы замечаете некоторые перегибы в макете: неправильные шрифты и цвета, а также неправильные взаимодействия и состояния наведения. Ваше волнение начинает медленно угасать и превращаться в чувство разочарования. Вы не можете не спросить себя: «Как такое могло случиться?»
Поиск причин
Возможно, просто было много досадных недоразумений в общении между дизайнерами и разработчиками. Тем не менее, вы продолжаете спрашивать себя:
- Как выглядела передача дизайнов? Были ли это просто PDF-файлы, файлы Photoshop или Sketch, отправленные по электронной почте с некоторыми комментариями, или это была настоящая встреча по передаче проекта, на которой обсуждались различные аспекты, такие как возможная система дизайна, типографика, отзывчивое поведение, взаимодействие и анимация?
- Существовали ли интерактивные или движущиеся прототипы, помогающие визуализировать определенные взаимодействия?
- Был ли составлен список важных аспектов с определенными уровнями приоритета?
- Сколько бесед состоялось — и с дизайнерами, и с разработчиками в одной комнате вместе?
Поскольку связь и передача обслуживания являются двумя очень важными ключевыми моментами, давайте подробнее рассмотрим каждый из них.
Общение является ключевым
Дизайнеры и разработчики, пожалуйста, общайтесь друг с другом. Много говорить. Чем раньше в проекте и чем чаще, тем лучше. Если возможно, проверяйте работу по проектированию вместе в начале проекта (и регулярно), чтобы постоянно оценивать осуществимость и получать междисциплинарные отзывы. Дизайнеры и разработчики, естественно, сосредотачиваются на разных аспектах одной и той же детали и, следовательно , видят вещи с разных углов и точек зрения .
Ранняя проверка позволяет разработчикам ознакомиться с проектом, чтобы они могли начать исследования и планирование на будущее в отношении технических терминов и внести свои идеи о возможной оптимизации функций. Частые встречи также сближают команду на личном и социальном уровне , и вы учитесь находить подход друг к другу для эффективного общения.
Переход от проектирования к разработке
Если организация не следует по-настоящему гибкому рабочему процессу, первоначальная передача проектных композиций и ресурсов (от команды дизайнеров разработчикам), скорее всего, произойдет в какой-то момент проекта. Эта передача — если она выполнена тщательно — может стать прочной основой знаний и соглашений между обеими сторонами. Поэтому очень важно не торопиться с этим и запланировать дополнительное время.
Задавайте много вопросов и обсуждайте каждое требование, страницу, компонент, функцию, взаимодействие, анимацию, что угодно — и делайте заметки. Если что-то непонятно, попросите разъяснений . Например, при работе с внешними или контрактными командами и дизайнеры, и разработчики могут подписывать сделанные заметки в качестве документа о взаимном согласии для дальнейшего использования.
Композиции плоского и статического дизайна хороши для демонстрации графических и макетных аспектов веб-сайта, но явно не имеют должного представления взаимодействий и анимации. Просьбы о прототипах или рабочих демонстрациях сложных анимаций создадут более четкое представление о том, что необходимо создать для всех участников.
В настоящее время существует широкий спектр доступных инструментов прототипирования, которые дизайнеры могут использовать для моделирования потоков и взаимодействий с разным уровнем точности. Хавьер Куэлло объясняет, как правильно выбрать инструмент прототипирования для вашего проекта, в одной из своих подробных статей.
Каждый проект уникален, как и его требования. Из-за этих требований не всегда можно построить все концептуальные функции. Часто доступное время и ресурсы для создания чего-либо могут быть ограничивающим фактором. Кроме того, ограничения могут исходить из технических требований , таких как осуществимость, доступность, производительность, удобство использования и кросс-браузерная поддержка, экономических требований, таких как бюджет и лицензионные сборы, или личных ограничений, таких как уровень квалификации и доступность разработчиков.
Итак, что, если эти ограничения вызывают конфликты между дизайнерами и разработчиками?
Поиск компромиссов и накопление общих знаний
Чтобы успешно сдать проект вовремя и выполнить все установленные требования, поиск компромисса между двумя дисциплинами в большинстве случаев неизбежен. Разработчики должны научиться разговаривать с дизайнерами в нетехнических терминах, когда они объясняют причины, по которым вещи требуют изменений или не могут быть реализованы в конкретной ситуации.
Вместо того, чтобы просто сказать: «Извините, мы не можем это построить», разработчики должны попытаться дать понятное для дизайнеров объяснение и — в лучшем случае — подготовить предложения по альтернативному решению , работающему в рамках известных ограничений. Подтверждение вашей точки зрения статистикой, исследованиями или статьями может помочь подчеркнуть вашу аргументацию. Кроме того, если сроки являются проблемой, может быть, реализацию некоторых трудоемких частей можно перенести на более позднюю фазу проекта?
Даже если это не всегда возможно, если дизайнеры и разработчики сидят рядом друг с другом, это может сократить циклы обратной связи и упростить выработку скомпрометированного решения. Адаптация и прототипирование могут быть выполнены непосредственно посредством кодирования и оптимизации с открытым DevTools.
Покажите своим коллегам-дизайнерам, как использовать DevTools в браузере, чтобы они могли изменять основную информацию и просматривать небольшие изменения в своем браузере (например, отступы, поля, размеры шрифта, имена классов) на лету.
Если структура проекта и команды позволяет это, как можно скорее сборка и прототипирование в браузере может дать всем участникам лучшее понимание адаптивного поведения и может помочь устранить ошибки и ошибки на ранней стадии проекта.
Чем дольше дизайнеры и разработчики работают вместе, тем лучше дизайнеры поймут, что проще, а что сложнее построить разработчикам. Со временем они могут сослаться на решения, которые в прошлом работали для обеих сторон:
«Мы использовали это решение, чтобы найти компромисс в проекте А. Можем ли мы использовать его и для этого проекта?»
Это также помогает разработчикам лучше понять, в каких деталях дизайнеры особенно заинтересованы и какие визуальные аспекты для них важны.
Дизайнеры ожидают, что интерфейс будет выглядеть (и функционировать) так же, как их дизайн
Файл дизайна против. Сравнение браузеров
Полезный метод, чтобы предотвратить разочарование дизайнеров, состоит в том, чтобы сделать простое сравнение слева направо между файлом проекта, который вы передали, и тем, как выглядит ваше текущее состояние разработки. Это может показаться тривиальным, но как разработчик вы должны позаботиться о стольких вещах, которые должны работать «под капотом», что вы могли упустить некоторые визуальные детали. Если вы видите заметные несоответствия, просто исправьте их.
Подумайте об этом так: каждая деталь в вашей реализации, которая выглядит точно так, как она была задумана , экономит как вам, так и дизайнеру драгоценное время и головную боль , а также способствует доверию. Не у всех может быть одинаковый уровень внимания к деталям, но для того, чтобы натренировать свой глаз замечать визуальные различия, может быть хорошим подспорьем быстрый раунд Can't Unsee.
Это с ностальгией напоминает мне игру, в которую мы играли давным-давно, под названием «Найди это». Вы должны были найти несоответствия, сравнивая два, казалось бы, похожих изображения, чтобы набрать очки.
Тем не менее, вы можете подумать:
«Что делать, если в дизайне просто нет заметной системы размеров шрифтов и интервалов?»
Что ж, хорошая мысль! Опыт показал мне, что может помочь начать разговор с дизайнером (ами), попросив разъяснений , а не начинать радикально менять вещи самостоятельно и создавать нежелательные сюрпризы для дизайнера (ов) позже.
Изучите основные правила типографики и дизайна
Как утверждает Оливер Рейхенштайн в одной из своих статей, 95% информации в Интернете является письменным языком. Поэтому типографика играет жизненно важную роль не только в веб-дизайне, но и в разработке. Понимание основных терминов и понятий типографики поможет вам более эффективно общаться с дизайнерами, а также сделает вас более универсальным разработчиком. Я рекомендую прочитать статью Оливера, так как он подробно описывает важность типографики в Интернете и объясняет такие термины, как микро- и макротипографика .
В «Справочном руководстве по типографике в мобильном веб-дизайне» Сюзанна Скакка подробно описывает терминологию типографики, такую как гарнитура, шрифт, размер, вес, кернинг, интерлиньяж и отслеживание, а также роль типографики в современном веб-дизайне.
Если вы хотите еще больше расширить свой типографский кругозор, возможно, вам стоит прочитать книгу Мэтью Баттерика «Практическая типографика Баттерика». Он также содержит сводку основных правил типографики.
Одна вещь, которую я нашел особенно полезной в адаптивном веб-дизайне, заключается в том, что нужно стремиться к средней длине строки (символов в строке) от 45 до 90 символов , поскольку более короткие строки более удобны для чтения, чем более длинные.
Должны ли разработчики проектировать?
Было много дискуссий о том, должны ли дизайнеры учиться кодировать, и вы можете задать себе тот же вопрос, но наоборот. Я считаю, что вряд ли можно преуспеть в обеих дисциплинах, и это совершенно нормально.
В своей статье «Совместная работа: как дизайнеры и разработчики могут общаться для создания лучших проектов» Рэйчел Эндрю прекрасно отмечает, что для более эффективного сотрудничества нам всем необходимо кое-что узнать о языке, навыках и приоритетах наших товарищей по команде, чтобы мы могут создать общий язык и пересекающиеся области знаний.
Одним из способов стать более осведомленным в области дизайна является онлайн-курс, известный как «Дизайн для разработчиков», который предлагает Сара Драснер, в котором она рассказывает об основных принципах компоновки и теории цвета — двух фундаментальных областях веб-дизайна.
«Чем больше вы узнаете за пределами своей собственной дисциплины, на самом деле лучше для вас [...] как разработчика».
— Сара Драснер
Визуальный центр
Сотрудничая с дизайнерами, я узнал разницу между математическим и визуальным центром. Когда мы хотим привлечь внимание читателя к определенному элементу, естественный фокус нашего глаза находится чуть выше математического центра страницы.
Мы можем применить эту концепцию, например, к позиционным модальным окнам или любым видам наложений. Этот прием помогает нам естественным образом привлечь внимание пользователя и сделать дизайн более сбалансированным:
Мы все в этом вместе
В быстро меняющихся и не очень гибких средах агентств с жесткими сроками разработчиков часто просят реализовать полнофункциональные адаптивные интерфейсы на основе макетов мобильных и настольных компьютеров. Это неизбежно вынуждает разработчика принимать проектные решения на протяжении всего процесса. Такие вопросы, как «На какую ширину мы уменьшим размер шрифта заголовков?» или «Когда мы должны переключить наш трехколоночный макет на один столбец?» может возникнуть.
Кроме того, в запале может случиться так, что такие детали, как состояния ошибок, уведомления, состояния загрузки, модальные окна или стили страниц 404, просто пропадут. В таких ситуациях легко начать обвинять и обвинять людей, которые должны были подумать об этом раньше. В идеале разработчики никогда не должны попадать в такую ситуацию, но что, если это так?
Когда я слушал выступление основателя и генерального директора Ueno Харальдура Торлейфссона на конференции в Сан-Франциско в 2018 году, он представил две их основные ценности:
«Ничто здесь не является чьей-то проблемой».
«Мы убираем мусор, который не выбросили».
Что, если больше разработчиков начнут активно макетировать вышеупомянутые недостающие части так хорошо, как они могут, а затем доработать вместе с дизайнером, сидящим рядом с ними? Веб-сайты живут в браузере, так почему бы не использовать его для создания и улучшения?
Хотя поиск отсутствующих или забытых деталей не всегда может быть идеальным решением, я понял из своего прошлого опыта, что это всегда помогало нам двигаться вперед быстрее и устранять ошибки на лету — как команде .
Конечно, это не означает, что дизайнеры должны быть отвергнуты в процессе. Это означает, что разработчики должны стараться уважительно идти навстречу дизайнерам , проявляя инициативу в решении проблем. Кроме того, меня как разработчика команда ценила гораздо больше просто за заботу и ответственность.
Укрепление доверия между дизайнерами и разработчиками
Доверительные и позитивные отношения между творческой и технической командой могут значительно повысить производительность и результаты работы. Так что же мы, как разработчики, можем сделать, чтобы повысить доверие между двумя дисциплинами? Вот несколько предложений:
- Проявляйте внимание к деталям .
Создание вещей точно такими, как они были спроектированы, покажет дизайнерам, что вы заботитесь о них, и вызовет улыбку на их лицах. - Общайтесь с уважением .
Мы все люди в профессиональной среде, стремящейся к наилучшему результату. Проявление уважения к дисциплине друг друга должно быть основой для любого общения. - Регистрируйтесь заранее и регулярно .
Вовлечение разработчиков с самого начала может помочь устранить ошибки на раннем этапе. Благодаря частому общению члены команды могут выработать общий язык и лучше понять позиции друг друга. - Сделайте себя доступным .
Наличие как минимум 30-минутного окна в день, когда дизайнеры могут обсуждать идеи с разработчиками, может дать дизайнерам ощущение поддержки. Это также дает разработчикам возможность объяснять сложные технические вещи словами, которые лучше понимают люди, не являющиеся техническими специалистами.
Результат: беспроигрышная ситуация
Необходимость тратить меньше времени на контроль качества за счет эффективного общения и надлежащей передачи проектов дает как креативной команде, так и команде разработчиков больше времени, чтобы сосредоточиться на создании реальных вещей и меньше головной боли. В конечном итоге это создает лучшую атмосферу и укрепляет доверие между дизайнерами и разработчиками. Голос фронтенд-разработчиков, которые проявляют интерес и знания в некоторых областях, связанных с дизайном, будет больше слышен на встречах по дизайну.
Упреждающий вклад в поиск компромисса между дизайнерами и разработчиками и решение проблем в качестве разработчика может дать вам более широкое чувство сопричастности и участия во всем проекте. Даже в сегодняшней бурно развивающейся творческой индустрии нелегко найти разработчиков, которые, помимо своих технических навыков, заботятся о визуальных деталях и обращают на них внимание. Это может быть вашей возможностью помочь преодолеть разрыв в вашей команде.
Связанные ресурсы
- «Как правильно выбрать инструмент для прототипирования», Хавьер Куэлло
- «Справочное руководство по типографике в мобильном веб-дизайне», Сюзанна Скакка.
- «Практическая типография Баттерика», Мэтью Баттерик
- «Работаем вместе: как дизайнеры и разработчики могут общаться, чтобы создавать лучшие проекты», Рэйчел Эндрю.
- «Дизайн для разработчиков», Сара Драснер, Frontend Masters
- «Веб-дизайн на 95 % состоит из типографики», — Оливер Райхенштейн.
- «Не могу разглядеть», викторина для браузера, чтобы тренировать ваше чувство распознавания визуальных деталей.