Когда дизайнер не уточнил, фронт додумал — и мир не пережил
Снова получили реализацию «не как в фигме»? Я спросила у фронтов, почему так происходит и как это чинить без драмы. Это первый выпуск моей рубрики «Поговорим?», где я прихожу к коллегам и расспрашиваю о их работе и пересечениях с дизайном. Чтобы наконец понимать друг друга, а не выяснять «Кто виноват?».
Я — Вика, ведущий дизайнер в Nedra Digital. Сегодня мы поговорим с двумя мощными фронтендерами: Валера (ведущий фронт) и Вера (старший фронт).
1. Старт задачи: входные данные и контекст
Что тебе нужно, чтобы нормально начать работать над задачей?
Для работы над задачей нужно, чтобы на макете были отрисованы все необходимые состояния, чтобы ничего не приходилось додумывать/довыяснять уже когда задачу взяли в разработку
Как узнать, что задача вообще реализуема? И нужна ли ранняя синхронизация?
Практически все задачи реализуемы, все зависит от времени. Ранняя синхронизация с дизайнером важна, но не обязательна, если дизайнер понимает верстку и сам знает сложность реализации задачи
Есть ли что-то, что дизайнеры обычно НЕ дают, но ты бы хотел получать?
Очень классно, когда на макетах есть заметки от дизайнера по разным тонкостям, на которые нужно обратить внимание, чтобы точно ничего не упустить. Так же удобно, когда на макетах показаны переходы из одного состояния в другое, разделение по правам, разделение по составным частям задачи, так гораздо легче работать, чем есть просто много макетов одной страницы и нужное состояние приходится искать самостоятельно/писать/звонить
Как ты относишься к тому, чтобы подключаться к задаче ещё до появления макетов? Это полезно или мешает?
Подключаться до появления макетов это супер полезно, если делаются какие-то не типовые решения, или сложные переходы/этапы. Плюс во время дискуссии можно прийти к лучшему решению, но при этом разработчик тоже должен понимать UX
2. Про проектирование: логика, флоу и решения
Когда смотришь на макеты — что для тебя самое важное? На что ты обращаешь внимание первым?
Когда смотрю на макеты, хочется сразу понимать флоу задачи, увидеть всю логику, все состояния, чтобы суметь дать оценку
Какие ошибки дизайнеры делают чаще всего на уровне логики?
В прошлом опыте у меня было, что дизайнеры отрисовывали только дефолтный макет, и потом когда я брала задачу в работу и шла по спеке, возникло 1000 вопросов по состояниям
Какие решения ты любишь, а какие вызывают боль? Почему?
Мне нравится когда все последовательно, пронумеровано, есть все ссылки на переходы, этапы. Боль, это когда в процессе меняются макеты, и об этом нигде не указывается
Как тебе удобнее обсуждать спорные решения: созвон, переписка, комментарии в макетах?
Мне удобнее созвон или переписка, так можно более подробно обсудить решение + мне кажется так решение будет принято быстрее
3. Про дизайн-систему и компоненты
Насколько тебе важно, чтобы дизайны опирались на ДС?
Использование ДС это всегда удобно, если эта распространённая ДС и у нее есть поддержка. Дизайнер должен понимать какие есть компоненты и использовать приоритетно их
Что бесит в «кастомных» элементах, которые дизайнеры любят изобретать?
«Бесит» в кастомных компонентах только если дизайнер перед придумыванием не спросил у разработчиков сложность реализации. Например был опыт, когда дизайнер с заказчиком придумывали макет, и напридумывали так, что дизайн система по большому счету и не нужна была, так как проще было написать с нуля, чем кастылить
Как ты относишься к «я чуть-чуть поменяла компонент, но он почти такой же»?
Ничего не имею против «чуть-чуть поменяла», если это не затратно и дизайнер спросил сложность реализации у разработчика
4. Про передачу макетов
Какие файлы/инфа должны быть у тебя, чтобы не было страданий при реализации?
В первую очередь макеты, потому что «давай сперва оценим, а потом доделаем макет» - это боль и страдания. Спецификация, по которой формировалась задача и делался макет
Какие ошибки в передаче встречаются чаще всего?
Как правило при передаче макетов, могут быть не те ссылки, или дизайнер и разработчик по разному поняли задачи
Что в макетах ты считаешь «обязательным»: взаимодействия, анимации, состояния, адаптивы и др?
В макетах обязательно нужны состояния и должно быть как-то помечено, как пользователь взаимодействует с интерфейсом (если это не очевидно). Анимации и адаптивы - это специфика каждой задачи/продукта
5. Про взаимодействие в процессе разработки
Часто ли бывает, что в макете что-то не учли? Как лучше выявлять такие моменты?
Чтобы в макете что-то не учли и взяли это в работу, бывает крайне редко, так как перед этим все макеты проходят этапы согласования, в которых обязательно должны присутствовать фронт
Какие вопросы ты бы хотел, чтобы дизайнер задавал чаще?
Один их самых важных вопросов, «Насколько сложно будет реализовать?» и «Сколько времени понадобится, чтоб это сделать» Потому что иногда какая-то простая вещь со стороны дизайнера (например изменение иконки или перемещение иконки в другое место или инпут, там, где его нет в компоненте) может сильно увеличить стоимость разработки такого компонента
Какие проблемы обычно всплывают уже после релиза?
После релиза могут возникнуть сложности уже с браузерами, и какие-то тонкости браузерные которые всплывают неочевидным образом. Либо заказчик после релиза еще что-то придумал
6. Про отношения «дизайнер и фронтендер»
Что делает работу с дизайнером лёгкой?
Легко работать с дизайнером если вы оба понимаете что делаете, когда дизайнер идет на встречу, а не упирается, потому что зачастую дизайнер и разработчик по разному видят макет» «Классно работать, когда дизайнер делает классные, структурные и легкие для чтения фронтами макеты, также когда дизайнер и фронт слышат друг друга, находят компромиссы, решают возникшие вопросы эффективно в сторону наиболее оптимального для всех решения
Что делает её невыносимой?
Мне не приходилось работать с невыносимыми дизайнерами, наверное мне повезло. Слышал только от других разработчиков о таких. Где дизайнер говорил: «Вы просто ничего не понимаете, вы просто токсики»
Какие качества ты больше всего ценишь в дизайнерах?
Для меня самое важное это структурность макетов (все что объясняла выше), поэтому начинающим дизайнерам советую обращать внимание именно на это. Чтобы когда разработчик смотрел на макет, ему сразу был виден весь флоу задачи, все состояния, разделение по пермишенам и т.д.
Финалим
Если коротко: меньше догадок, больше синка. Дизайн и фронт не должны угадывать друг друга. Мы можем делать круче, быстрее, выше, сильнее, если просто не молчать, а обсуждать всё по пути — тогда мы действительно будем работать как команда.
А как вы работаете с фронтами?