Почему работа с внештатным дизайнером может стать чёрной полосой для вашего проекта
Дизайнер, работающий отдельно от студии разработки, увеличивает вероятность выйти за бюджет. Почему? Отвечает компания ADCI Solutions и приглашённые эксперты.
Мы привыкли к мобильным и веб-студиям без офиса: если они выходят на связь друг с другом, доступны в течение рабочего дня и обладают необходимой информацией о проекте, то всё в порядке. Но бывает, что один из занятых на проекте специалистов работает в отрыве от остальных. Таким специалистом может быть дизайнер. Наш опыт и опыт коллег из других мобильных и веб-студий, с которыми мы поговорили, чаще говорит о том, что такое сотрудничество до добра не доводит. И причиной обсудить эту тему стал один из проектов, где наша команда разработки и внештатный дизайнер ни разу не видели друг друга и не общались без посредничества клиента, который его нанял.
Как наш клиент переплатил за дополнительные часы разработки
Этот кейс случился во время работы над сайтом, где количество страниц с описанием услуг измеряется сотнями. Разный только контент, а неизменным остаётся компонент, который наши React-разработчики делали по дизайну от внештатного дизайнера. Дизайнер прислал пять страниц, где секция, разработанная на этом компоненте, только на первый взгляд воспроизводилась одинаково. Скрытые проблемы вышли наружу уже во время разработки компонентов. На разных страницах в этой секции были разные размеры и отступы между элементами: например, на одной странице отступ между заголовком и блоком рядом был 60 пикселей, на другой — 200 пикселей. Несмотря на то, что компонент — штука, которая пишется один раз, наши разработчики для каждой страницы прописывали в нём разные стили и классы.
Проект не в релизе и исходники дизайна не сохранились, так что ограничимся муляжами, отражающими суть:
Как мы дошли до такого?
Порой разработчик просто делает дизайн, который ему дают. Молча. Он не то чтобы глупый и подневольный специалист, но время, которое разработчику выделяют на оценку задачи, не всегда позволяет всмотреться в мелочи, а дьявол-то как раз в них. В нашем случае разработчик пошёл от дефолтного предположения, что компонент универсален. Но стоило погрузиться в задачу, и тут же вскрылся конфликт компонента и дизайна страницы.
Ситуация неприятная, но не уникальная. Если разработчики и дизайнер не работают бок о бок, то она может возникнуть на любом проекте, потому что:
- разработчикам не оплатили время на составление ТЗ для дизайнера и/или проверку сделанной им работы перед стартом разработки;
- соответственно, дизайнер работает без ТЗ;
- дизайнер вовсе не понимает, как работает дизайн в веб- и мобильных приложениях;
- взгляды дизайнера со стороны зарубежного клиента на то, что такое дизайн, отличаются от наших в силу культурных особенностей;
- клиент не проверил дизайн или проверил настолько, насколько хватило компетенций.
У дизайнеров, кажется, мало опыта именно с веб-дизайном. Порой разные страницы имеют разную ширину, а элементы, которые по сути сквозные, по каким-то непонятным причинам начинают меняться от страницы к странице. Был случай, когда в шапке не было логотипа и названия сайта — такой минимализм по версии дизайнера, с которым почему-то согласился владелец сайта. Но по итогу выяснилось (заказчик проверил это на своём окружении), что люди не понимали, куда попали и что это за сайт вообще.
«Зато свой, родной»: каковы мотивы клиента отказаться от услуг студийного дизайнера?
Решение клиента держать дизайнера на своей стороне может быть принято им по разным причинам:
- дизайнер может быть близким другом/подругой клиента студии, либо кто-то из его родственников или коллег замолвил слово за своего человека — в общем, то, что по-русски называется блатом;
- кого-то из клиентов может устраивать студийное качество разработки, но не дизайна;
- свой дизайнер дешевле студийного, и это отлично сводит в ноль все контраргументы;
- разность менталитетов: работать с человеком, который в силу общих ценностей и культуры лучше понимает продукт и цели клиента, куда комфортнее;
- и самый неочевидный мотив — снижение возможных рисков.
Бывают кейсы, когда большие клиенты хотят «хеджировать риски» и держать разных субподрядчиков на разных работах. Но в таких случаях деление может быть не только по линии «дизайнеры/разработчики», но и по отдельным составляющим программного решения. К примеру, одни делают сайт, другие — мобильное приложение.
Чем связана работа дизайнера и разработчика
Изучив ТЗ, дизайнер начинает искать референсы на том рынке, в который метит клиент со своим продуктом — ведь, скорее всего, всё это уже у кого-то было. Продукты, создатели которых хотят зарабатывать деньги, а не тратить родительские на какой-нибудь сдвиг парадигмы, не стремятся огорошить своих пользователей исключительным пользовательским опытом, который те ещё не проживали. Даже Snapchat, который хоть и мог сначала выглядеть как что-то с другой планеты, базировался на желании людей кичиться самыми откровенными моментами своей жизни, но при этом не оставлять следов. Чаще продукты подсматривают друг за другом и заимствуют фишки, которые пользуются популярностью: вот не было печали, зато теперь пожалуйста — сторис в телеграме. Потому что если пользователей заставлять учиться чему-то новому без очевидной для того выгоды, то пользователь уйдёт решать свою проблему в другое место.
Хороший дизайнер знает это и начинает продумывать внешний вид, интерфейс и навигацию сайта или приложения, не забывая о том, что главное — не запутать пользователя и дать ему то, за чем он пришёл. Индивидуальность никуда не пропадает — она в контенте, цветах, лид-магнитах, геймификации. Но типовые вещи остаются таковыми.
Соответственно, у разработчиков тоже находятся типовые приёмы для воплощения типовых дизайнерских задумок. И они начинают подыскивать соответствующие. На этой стадии контакт дизайнера и разработчиков должен быть максимально тесным — дизайнеру не стоит придумывать то, что разработчик не сможет воплотить в коде, а разработчик может подсказывать, можно ли это запрограммировать, или вместе с дизайнером понять, что на поиск решения нужно чуть больше времени, чем обычно.
Сложно включить какие-то задачи в группу нетиповых и требующих большего времени. На оценку задачи влияет то, решал ли разработчик её прежде или нет — будь он хоть сколько опытным, ему нужно разобраться. Клиент может отреагировать на это спокойно, если задача не горящая, но и имеет право искать специалиста с набитой рукой. На деле же разница в оценке у опытного и неопытного разработчика может составить всего пару часов, но у клиента свои представления о том, сколько может занимать восполнение пробелов в знаниях.
Как минимизировать риск работы с некачественным дизайном
Итак, клиент настаивает: «Дизайнер будет на моей стороне». Чем вы можете себя обезопасить?
Расскажите обо всём, что может пойти не так: о том, что увеличивается время на согласование, передачу и приём правок, и это создаёт простои в работе; о том, что дизайнер не знаком с заведёнными в студийной работе правилами и поэтому может, например, передать дизайн не в том формате; в конце концов, что лучше, когда каждый делает свою работу, и клиент — это в основную очередь предприниматель, а не дизайнер, который смог бы компетентно оценить работу своего специалиста перед передачей на разработку.
Я сам делал правки в картинках, иконках, анимациях — нам их предоставили очень плохими и притом несколько раз подряд: просишь дать нормальные, а после правок кидают всё равно не то. Ждать приходилось долго, а задача простаивает, и в итоге быстрее было разобраться самому и поправить, как нужно, в графических редакторах, хотя я не должен этого делать. Очень часто присылают дизайн в виде картинки, PDF и т. п., откуда не взять абсолютно ничего, и приходится делать на глаз.
Был у меня кейс, где дизайн рисовали 1,5 года. Сменилось три дизайнера. Но основная проблема была не в них, а в заказчике, который много на чём настаивал, не понимая на чём и какие у этого будут последствия. Долго описывать, но суть в том, что заказчику желательно не лезть к дизайнеру, не понимая, что просит, или хотя бы прислушиваться к тому, что ему говорят.
После аргументов пытайтесь уговорить клиента на лишние 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, где разработчику видны все размеры, отступы и стили элементов, и откуда он выгружает элементы дизайна.
Но запрос на компетенции расширяется, когда речь идёт о продуктовой разработке. Здесь разработчику, возможно, придётся даже где-то прикрывать дизайнера.
Если говорить о продуктовой разработке, то разработчику будет уместно погрузиться в суть исследований и UX, откуда взялись те или иные интерфейсные решения, которые этот разработчик будет делать, и т. д. Это позволит на этапе разработки адекватно «подчищать» хвосты за дизайнером или грамотно обращать его внимание на какие-то пробелы. В большей или меньшей степени, но каждый дизайнер забывает дорисовать какие-то состояния или пограничные кейсы. Если разработчик погружен в тему исследований, а сроки горят — это позволит быстро закрывать такие промахи или по крайней мере не пропускать их в работу до согласования.
Но всё начинается с признания того, что у дизайна есть своя ценность. И многие из комментаторов соглашаются, что, как бы сильны ни были стереотипы, дизайнер — это без пяти минут инженер.
Разработчик должен знать, что дизайнеры — это не художники, которые рисуют так, как чувствуют. Дизайнеры в работе руководствуются кучей данных: от личных пожеланий клиента до рекомендаций независимых исследовательских институтов. Поэтому просто что-то подвинуть или вообще не реализовать, потому что муторно — не проканает.
Работа дизайнера должна быть похожа на работу разработчика, и это, пожалуй, главная особенность специфики. Дизайн и творчество — это не одно и то же. Дизайнер решает вполне конкретные задачи (как и кодер), он должен рационализировать эстетику, расставлять правильные акценты, знать «визуальный язык программирования». Мне кажется, часто возникает ложное мнение, будто бы дизайнер — это какой-то творческий, возвышенный человек, который творит что-то неведомое, а разработчик пишет скучный, однообразный и вполне конкретный код. Это, конечно, далеко не так.
За этой инженерией стоит человек с чувством прекрасного и своими несовершенствами, что тоже важно иметь в виду.
Хотя я убеждена, что дизайн интерфейсов — это не область творчества, а область проектирования, хорошо, если разработчик понимает, что некоторые решения могут приниматься исходя из эстетических соображений. Например: почему выравнивание в этих двух блоках отличается? потому что это создает динамику или ставит нужный акцент. Хотя иногда неплохо учитывать и человеческий фактор: если в десяти случаях расстояние между блоками 20 пикселей, а в одиннадцатом внезапно 21, это скорее всего ошибка, а не задумка.
Разработчик должен учитывать факт, что в отличие от кода, дизайн — это довольно субъективная субстанция. Каждый воспринимает, видит, осязает объект по-своему. Задача дизайнера — перевести это субъективное нечто в объективный продукт. В итоге для разработчика это часто выглядит как «я так вижу», и дизайнер получает резонные возражения в точно таком же формате «я так считаю». Нужно помнить, что дизайнер, кроме своего субъективного взгляда и опыта, использует различные методики построения UX/UI, data driven-подходы, аналитику, best practices и прочие инструменты. Просто этот пласт информации часто скрыт от других членов команды, а дизайнеры не всегда могут корректно её донести.
Какая информация от разработчика поможет дизайнеру на старте
Эти советы работают при условии, когда между дизайнером и разработчиком нет стены или же есть толковый коммутатор-модератор.
Заметная часть наших собеседников, занимающихся дизайном, начинает свой ответ с упоминания о технических ограничениях.
На старте мне важно обсудить свою идею с разработчиком, чтобы услышать ограничения, влияющие на ключевые решения в дизайне. Обычно это помогает нам избежать кучи переделок, а то и вовсе отказаться от некоторых идей в силу их трудозатратности («вот видите, не сделали, и переделывать не пришлось»).
Но в то же время есть наблюдение, что будущее — за теми компаниями, которые ставят во главу угла пользователя и его удобство при работе с продуктом. И тут уже сам дизайн задаёт рамки для разработки.
Всё зависит от подхода к созданию проекта. Например, если мы говорим про дизайн-центричный подход, то дизайнер сам генерирует эти ограничения для разработки. Если наоборот, например, когда дизайнер приходит на проект с тяжелым legacy, то тут будет очень полезно их, ограничения, изучить, чтобы найти лазейки для их обхода и узнать, где на них можно просто забить.
Требования к передаче макета тоже могут варьироваться от разработчика к разработчику.
Один разработчик просил меня делать градации оттенков через opacity, потому что ему так удобнее, а другой просил так категорически не делать и всё переводить в 100% значения. Это не создаёт никаких проблем, поэтому отлично, если можно сразу договориться об этих моментах.
А там, где разработчик вовлечён в работу дизайнера, рождается поистине магия синергии.
На практике разработчик будет давать осмысленные комментарии после того, как будет понятен хотя бы образ решения (на словах, вайрфремах или первых набросках дизайна). На этом этапе важно услышать про узкие места, тяжеловесность запросов, стоимость разработки отдельных интерфейсных решений, пограничные состояния, на которые нужно обратить внимание. При этом, если разработчик подкинет идей про какую-то новую технологию для решения задачи — это прям золото. Последнее означает, что разработчик — не просто исполнитель, который видит ограничения, но ещё и инженер и любит крутые задачи.
Самый важный пункт для меня — чтобы разработчики были включены в работу над дизайном. Это классно, потому что они всегда в курсе статуса по дизайну, сразу же могут подсказать, насколько это реализуемо, и знают, почему и зачем было принято такое решение. Если такой процесс организовать сложно, то я бы рекомендовала просто добавить как можно больше встреч, особенно на начальных этапах, когда продумывается основное направление.
Заключение
Команда на то и команда, чтобы общаться, знать о стиле работы друг друга, использовать регламентированные и неформальные правила эффективного рабочего процесса, быстро принимать решения и говорить, что было хорошо, а что лучше не повторять. Коммуникация, согласованность, скорость принятия решений, их консистентность — фундамент для проекта, чтобы завершить его качественно и в срок. Даже если в инхаус-команде всего этого нет, то есть условия для того, чтобы это появилось, и это должно волновать хороших руководителей. Внештатный же дизайнер почти неуправляем, он буквально подчиняет разработчиков своей воле (или безволию).
На одном проекте нужно было внести правки в дизайн картинок и анимаций. А у клиента были сложности с дизайнером, и он нам ответил: «Дизайнер — фрилансер, его сложно заставить сделать правки, поэтому давайте сами попробуете». Ну и на других проектах зачастую ждёшь подолгу каких-то правок, картинок, иконок и т. д.
Последнее слово здесь, конечно же, за клиентом. Хочется, чтобы он понимал, что когда на одном из этапов работы над продуктом лажают, это может запустить цепочку событий, отравляющих нашу индустрию:
- студия разработки вынуждена сказать клиенту, что часть продукта надо переделывать;
- клиент переплачивает и злится — ему кажется, что с обеих сторон на него работают непрофессионалы;
- страдает репутация дизайнера и разработчиков;
- клиент теряет доверие к студиям вообще, становится мнительным и склочным, душнит и угрожает на первичной консультации и — если студия не поняла, с кем связалась — после неё;
- число таких клиентов растёт;
- число стрессовых для менеджеров и тим-лидов контактов с клиентами тоже растёт;
- итог: моральная усталость, увольнения, испорченные профессиональные и личные отношения.
Надеемся, что после прочтения этой статьи клиенты студий сделают правильные выводы и даже поделятся ими в комментариях. А разработчиков и дизайнеров мы просим поделиться своими историями, которые дополнят статью.
За помощь в подготовке материала благодарим Никиту Малышева (Niklan), Владимира Помелова (Умные разработки), Катерину Бондаренко (Wake Lab), Таню Моренко (Termius), Эда Хорькова (КОД9), Дашу Шпехт и Ануара Мендубаева (Antro.cx), Сергея Гончарова (red_mad_robot), Антона Бондаря (SALT AND PEPPER/snp.agency), Дмитрия Кащенко (BlackBricks).