Почему работа с внештатным дизайнером может стать чёрной полосой для вашего проекта
Дизайнер, работающий отдельно от студии разработки, увеличивает вероятность выйти за бюджет. Почему? Отвечает компания ADCI Solutions и приглашённые эксперты.
Мы привыкли к мобильным и веб-студиям без офиса: если они выходят на связь друг с другом, доступны в течение рабочего дня и обладают необходимой информацией о проекте, то всё в порядке. Но бывает, что один из занятых на проекте специалистов работает в отрыве от остальных. Таким специалистом может быть дизайнер. Наш опыт и опыт коллег из других мобильных и веб-студий, с которыми мы поговорили, чаще говорит о том, что такое сотрудничество до добра не доводит. И причиной обсудить эту тему стал один из проектов, где наша команда разработки и внештатный дизайнер ни разу не видели друг друга и не общались без посредничества клиента, который его нанял.
Как наш клиент переплатил за дополнительные часы разработки
Этот кейс случился во время работы над сайтом, где количество страниц с описанием услуг измеряется сотнями. Разный только контент, а неизменным остаётся компонент, который наши React-разработчики делали по дизайну от внештатного дизайнера. Дизайнер прислал пять страниц, где секция, разработанная на этом компоненте, только на первый взгляд воспроизводилась одинаково. Скрытые проблемы вышли наружу уже во время разработки компонентов. На разных страницах в этой секции были разные размеры и отступы между элементами: например, на одной странице отступ между заголовком и блоком рядом был 60 пикселей, на другой — 200 пикселей. Несмотря на то, что компонент — штука, которая пишется один раз, наши разработчики для каждой страницы прописывали в нём разные стили и классы.
Проект не в релизе и исходники дизайна не сохранились, так что ограничимся муляжами, отражающими суть:
Как мы дошли до такого?
Порой разработчик просто делает дизайн, который ему дают. Молча. Он не то чтобы глупый и подневольный специалист, но время, которое разработчику выделяют на оценку задачи, не всегда позволяет всмотреться в мелочи, а дьявол-то как раз в них. В нашем случае разработчик пошёл от дефолтного предположения, что компонент универсален. Но стоило погрузиться в задачу, и тут же вскрылся конфликт компонента и дизайна страницы.
Ситуация неприятная, но не уникальная. Если разработчики и дизайнер не работают бок о бок, то она может возникнуть на любом проекте, потому что:
- разработчикам не оплатили время на составление ТЗ для дизайнера и/или проверку сделанной им работы перед стартом разработки;
- соответственно, дизайнер работает без ТЗ;
- дизайнер вовсе не понимает, как работает дизайн в веб- и мобильных приложениях;
- взгляды дизайнера со стороны зарубежного клиента на то, что такое дизайн, отличаются от наших в силу культурных особенностей;
- клиент не проверил дизайн или проверил настолько, насколько хватило компетенций.
«Зато свой, родной»: каковы мотивы клиента отказаться от услуг студийного дизайнера?
Решение клиента держать дизайнера на своей стороне может быть принято им по разным причинам:
- дизайнер может быть близким другом/подругой клиента студии, либо кто-то из его родственников или коллег замолвил слово за своего человека — в общем, то, что по-русски называется блатом;
- кого-то из клиентов может устраивать студийное качество разработки, но не дизайна;
- свой дизайнер дешевле студийного, и это отлично сводит в ноль все контраргументы;
- разность менталитетов: работать с человеком, который в силу общих ценностей и культуры лучше понимает продукт и цели клиента, куда комфортнее;
- и самый неочевидный мотив — снижение возможных рисков.
Чем связана работа дизайнера и разработчика
Изучив ТЗ, дизайнер начинает искать референсы на том рынке, в который метит клиент со своим продуктом — ведь, скорее всего, всё это уже у кого-то было. Продукты, создатели которых хотят зарабатывать деньги, а не тратить родительские на какой-нибудь сдвиг парадигмы, не стремятся огорошить своих пользователей исключительным пользовательским опытом, который те ещё не проживали. Даже Snapchat, который хоть и мог сначала выглядеть как что-то с другой планеты, базировался на желании людей кичиться самыми откровенными моментами своей жизни, но при этом не оставлять следов. Чаще продукты подсматривают друг за другом и заимствуют фишки, которые пользуются популярностью: вот не было печали, зато теперь пожалуйста — сторис в телеграме. Потому что если пользователей заставлять учиться чему-то новому без очевидной для того выгоды, то пользователь уйдёт решать свою проблему в другое место.
Хороший дизайнер знает это и начинает продумывать внешний вид, интерфейс и навигацию сайта или приложения, не забывая о том, что главное — не запутать пользователя и дать ему то, за чем он пришёл. Индивидуальность никуда не пропадает — она в контенте, цветах, лид-магнитах, геймификации. Но типовые вещи остаются таковыми.
Соответственно, у разработчиков тоже находятся типовые приёмы для воплощения типовых дизайнерских задумок. И они начинают подыскивать соответствующие. На этой стадии контакт дизайнера и разработчиков должен быть максимально тесным — дизайнеру не стоит придумывать то, что разработчик не сможет воплотить в коде, а разработчик может подсказывать, можно ли это запрограммировать, или вместе с дизайнером понять, что на поиск решения нужно чуть больше времени, чем обычно.
Как минимизировать риск работы с некачественным дизайном
Итак, клиент настаивает: «Дизайнер будет на моей стороне». Чем вы можете себя обезопасить?
Расскажите обо всём, что может пойти не так: о том, что увеличивается время на согласование, передачу и приём правок, и это создаёт простои в работе; о том, что дизайнер не знаком с заведёнными в студийной работе правилами и поэтому может, например, передать дизайн не в том формате; в конце концов, что лучше, когда каждый делает свою работу, и клиент — это в основную очередь предприниматель, а не дизайнер, который смог бы компетентно оценить работу своего специалиста перед передачей на разработку.
После аргументов пытайтесь уговорить клиента на лишние 5-10-20 часов для скурпулёзной проверки дизайна. Конечно, в дальнейшем нужно будет доплатить и дизайнеру, чтобы он исправил возможные ошибки. Но это не стоит того, чтобы заставлять разработчиков попасть в наспех поставленную оценку и получить плохой результат — ведь выйдет себе дороже. Ещё хуже, когда разработчик по ходу дела находит ошибки, но под лозунгом «Времени на раскачку нет» глубже и глубже погружается в эту субстанцию всеми частями тела. И он уже знает, что будет делать всё заново, а проджект-менеджер неприятно удивит клиента. Как мы уже знаем, такие работы над ошибками дизайнера могут стоить сотен лишних часов.
Мораль: на любом этапе и в любых обстоятельствах доказывайте клиенту свой профессионализм.
Памятка c компетенциями
С каким дизайном приятно иметь дело
Если вы дизайнер-внештатник, вы можете получить много репутационных очков в глазах разработчиков, если не забудете об их представлениях о нормальном дизайне. И это не каприз, а нормальная культура инхаус-работы.
Итак, что хотел бы видеть разработчик в дизайне:
UI-кит:
- список текстовых стилей макета (шрифты и параметры шрифтов для заголовков, текста и т. д.). Если шрифт относится к Google Fonts, то лучше приложить ссылку на него — тогда он не подтягивается файлом, а прописывается ссылкой, что экономит 15 кБ;
- гибкие тексты и заголовки с учётом разного количества букв и вероятности переноса на несколько строк;
- все используемые в проекте цвета;
- размеры сетки и контейнеров для всех устройств;
- виды кнопок, ссылок;
- все состояния интерактивных элементов (hover, active, selected, checked, валидация, минимальные и максимальные состояния);
- используемые в проекте иконки изображения.
Помощь в понимании макета:
- комментарии к блокам;
- описание функциональности;
- хорошая структура дизайн-документа: все слои и фреймы понятно проименованы, соблюдена вложенность слоёв, одинаковые элементы интерфейса объединены в компоненты;
- последовательность и регулярность (логичность) в дизайн-решениях;
- понятная сетка и отступы;
- понятные референсы в местах, где есть такая необходимость (чаще это касается моушен-дизайна).
Оформление элементов:
- правильно указанные размеры для блоков и отступов. Все значения должны быть целыми числами;
- расположение блоков по сетке;
- указание line-height в процентах;
- применение Auto layouts (инструмент в Figma для автоматического выравнивания соседних модулей)
Личные качества:
- понимание контекста и целевой аудитории;
- внимание к мелочам.
Что не помешает знать дизайнерам о работе разработчика
Во второй половине 2010-х Tilda поставила для дизайнеров новую планку и подтолкнула их к изучению HTML, CSS и JavaScript, чтобы модифицировать стандартные блоки конструктора и создавать свои эффекты. Теперь и разработчики ждут от дизайнеров понимания, как работает веб и мобайл. Этот список компетенций составлен как теми, так и другими:
- умение взаимодействовать с разработчиками, чтобы обсудить технические детали, выяснить возможности и ограничения, решить возникшие проблемы и внести корректировки в дизайн при необходимости;
- использование лучших практик и общепринятых решений (например, что есть контейнеры 1024px, 1180px, 1200px и т. д., а не 1234px, потому что так влезло);
- представление об адаптивном дизайне (респонсивном, резиновом — кажется, терминология в этом вопросе уже мало кого волнует, но можете поправить нас в комментариях);
- знакомство со способом разметки CSS Grid Layout;
- знакомство с фреймворком Bootstrap;
- понимание и грамотное обращение с концепцией дизайн-систем, которые помогают сделать дизайн проекта единообразным и согласованным в рамках проекта.
- умение создавать интерактивные прототипы, чтобы проверить функциональность дизайн-концепций и взаимодействие пользователей с ними;
- знания вёрстки, чтобы упрощать или усложнять свой дизайн там, где это нужно.
Что не помешает знать разработчикам о работе дизайнера
Опрошенные нами специалисты разными словами говорят, что в тандеме «дизайнер-разработчик» роль второго больше сводится к тому, чтобы направлять дизайнера, указывать ему на проблемы и технически опасные решения. Для этого не требуется владеть дизайн-навыками, зато поможет умение вести диалог, насмотренность, общее представление о композиции, цветовой гармонии, типографике и принципах визуальной иерархии. Стандартом де-факто становится знание разработчиком Sketch и Figma, где разработчику видны все размеры, отступы и стили элементов, и откуда он выгружает элементы дизайна.
Но запрос на компетенции расширяется, когда речь идёт о продуктовой разработке. Здесь разработчику, возможно, придётся даже где-то прикрывать дизайнера.
Но всё начинается с признания того, что у дизайна есть своя ценность. И многие из комментаторов соглашаются, что, как бы сильны ни были стереотипы, дизайнер — это без пяти минут инженер.
За этой инженерией стоит человек с чувством прекрасного и своими несовершенствами, что тоже важно иметь в виду.
Какая информация от разработчика поможет дизайнеру на старте
Эти советы работают при условии, когда между дизайнером и разработчиком нет стены или же есть толковый коммутатор-модератор.
Заметная часть наших собеседников, занимающихся дизайном, начинает свой ответ с упоминания о технических ограничениях.
Но в то же время есть наблюдение, что будущее — за теми компаниями, которые ставят во главу угла пользователя и его удобство при работе с продуктом. И тут уже сам дизайн задаёт рамки для разработки.
Требования к передаче макета тоже могут варьироваться от разработчика к разработчику.
А там, где разработчик вовлечён в работу дизайнера, рождается поистине магия синергии.
Заключение
Команда на то и команда, чтобы общаться, знать о стиле работы друг друга, использовать регламентированные и неформальные правила эффективного рабочего процесса, быстро принимать решения и говорить, что было хорошо, а что лучше не повторять. Коммуникация, согласованность, скорость принятия решений, их консистентность — фундамент для проекта, чтобы завершить его качественно и в срок. Даже если в инхаус-команде всего этого нет, то есть условия для того, чтобы это появилось, и это должно волновать хороших руководителей. Внештатный же дизайнер почти неуправляем, он буквально подчиняет разработчиков своей воле (или безволию).
Последнее слово здесь, конечно же, за клиентом. Хочется, чтобы он понимал, что когда на одном из этапов работы над продуктом лажают, это может запустить цепочку событий, отравляющих нашу индустрию:
- студия разработки вынуждена сказать клиенту, что часть продукта надо переделывать;
- клиент переплачивает и злится — ему кажется, что с обеих сторон на него работают непрофессионалы;
- страдает репутация дизайнера и разработчиков;
- клиент теряет доверие к студиям вообще, становится мнительным и склочным, душнит и угрожает на первичной консультации и — если студия не поняла, с кем связалась — после неё;
- число таких клиентов растёт;
- число стрессовых для менеджеров и тим-лидов контактов с клиентами тоже растёт;
- итог: моральная усталость, увольнения, испорченные профессиональные и личные отношения.
Надеемся, что после прочтения этой статьи клиенты студий сделают правильные выводы и даже поделятся ими в комментариях. А разработчиков и дизайнеров мы просим поделиться своими историями, которые дополнят статью.
За помощь в подготовке материала благодарим Никиту Малышева (Niklan), Владимира Помелова (Умные разработки), Катерину Бондаренко (Wake Lab), Таню Моренко (Termius), Эда Хорькова (КОД9), Дашу Шпехт и Ануара Мендубаева (Antro.cx), Сергея Гончарова (red_mad_robot), Антона Бондаря (SALT AND PEPPER/snp.agency), Дмитрия Кащенко (BlackBricks).