Как дизайнеру ужиться с разработчиками: мой опыт

Меня зовут Илья, работаю UX/UI дизайнером настольного приложения для аналитиков данных. Приложение — сервис не для всех, а в основном для опытных специалистов. Казалось бы, необычный кейс для дизайнера: нужно делать сложное и не уходить в интерфейсы «для бабушек».

Ещё одно ограничение в работе: я работаю в отделе разработки, и мою работу принимает тимлид программистов. Я думаю, что это нормально для компании, где весь продукт создаётся руками разработчиков, и этот отдел ключевой.

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

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

Я хочу поделиться опытом, как строить процесс работы с разработчиками: как получать задачу, как её делать, как передавать и на что опираться при презентации результата.

Получаю задачу от руководителя компании: переделать определенный компонент программы, который неудобен и непонятен пользователю. Всё логично, вопросов нет, надо приступать. Приношу результат начальнику разработки: «Серверную часть мы менять не будем, эту функцию надо оставить, надо изменить только визуальную часть». Так, а зачем я вообще делал редизайн?

Оказывается, сам функционал менять не надо: нужно изменить только отображение. В чём проблема? Я знал, что работу будет принимать тимлид разработки, но не поинтересовался у него об ограничениях в работе. Я не спросил, а как он видит результат моего редизайна. Получается, на самом деле задача звучит так: редизайн компонента без изменения сервисной части программы (логики работы функционала) с оставлением имеющегося функционала.

Задача изначально поступила от руководителя, поэтому надо согласовать новое звучание задачи с ним. «Нужно сделать более понятным и удобным взаимодействие с программой, но сам функционал и логику не менять?» Да, все верно.

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

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

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

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

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

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

Напишите манифест дизайна и согласуйте со всеми в компании. Манифест — свод правил в дизайне, которые все признают. Если возникнет спорный момент, то обращайтесь к нему. Постоянно дополняйте манифест: возникла конфликтная ситуация в процессе работы над дизайном — обсудите, придите к консенсусу и зафиксируйте решение.

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

Скинуть результат работы ссылкой на Figma — подписать себе приговор. Будет миллион замечаний, придирок: это реализовывать не будем, это так не работает, это вообще чушь. Разработчикам нужен результат, где каждый пиксель аргументирован и не опирается на «мне как дизайнеру виднее».

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

Не поленитесь сделать презентацию слайдами с поэтапным представлением результатов работы. Объясняйте, что вы делали и к каким результатам пришли. Например: «У всех наших конкурентов есть функция N, которая нужна для этого. Функция N нужна всем опрошенным пользователем. Насколько сложно ее реализовать и как можно облегчить процесс внедрения?» Обычно этого достаточно, чтобы прийти к осмысленному обсуждению добавления новой функции.

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

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

Не закидывайте разработчиков своей терминологией: паттерны поведения, 9 эвристика Нильсена, закон Миллера. Если вы перед презентацией знаете, как примерно будет реализовываться дизайн — учитывайте это в своей защите. Можно прямо сказать: «Обсуждал с разработчиком, он сказал, что решение вполне реализуемое, но придется потратить неделю на реализацию»

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

Много вопросов без ответа и критики на презентации — результат вашей недоработки. Постарайтесь всё выяснить заранее и презентовать решение, которое команда видела до этого и сама рада результату.

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

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

Советуйтесь с разработчиками. Спрашивайте, что можно реализовать и насколько это будет затратно. Если задача трудная, то подойдите к разработчику и скажите: «Мне кажется, такое практически нереализуемо. Что думаешь?» Часто разработчики хотят также выделиться перед своим тимлидом и сделать трудную задачу. В этом случае они встанут на вашу сторону и будут защищать решение.

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

Разработчики — друзья дизайнеров, они хотят делать рабочие решения. У них также есть свои ограничения: кто-то не сможет реализовать крутящуюся 3D-фигуру на сайте, кто-то боится тимлида и не хочет новаторств.

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

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

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