Привет, Хабр! Меня зовут Лена Жукова, я фронтенд-разработчик в Сбертехе.
В посте я разберу не новую, но всегда актуальную тему — взаимоотношения дизайнера и фронтенд-разработчика. Статья пригодится новичкам и командам, у которых еще не выстроены процессы работы. Рассмотрим несколько примеров из жизни и попробуем разобраться, как избежать разногласий.
Наверняка большинство читателей Хабр сталкивались с такими ситуациями.
Вместо комментариев по верстке разработчик получил непонятные термины, либо дизайнер не понимает терминов верстки. Это связано с тем, что каждый рассматривает продукт из своей области. Поэтому стоит использовать общий словарь терминов.
Например, в дизайне есть понятие интерлиньяж, который дословно означает «между линий». Аналогом в верстке является line-height.
Отсюда вытекает интересный вопрос — должен ли дизайнер понимать код, а разработчик понимать принципы дизайна? В статье «Почему дизайнер и разработчик должны работать вместе» автор дает советы по этому поводу. Чтобы преодолеть разрыв, разработчик и дизайнер должны говорить на одном языке и, по возможности, расширять свои наборы навыков.
И дизайнер, и разработчик должны иметь базовые знания:
В реальной жизни все бывает не так идеально, поэтому не стоит ругать дизайнера, если он не хочет учить верстку, или обвинять разработчика в том, что он по-своему видит интерфейс.
Совет. Объясните коллеге какие-то моменты подробнее, и возможно, он захочет дальше развивать свои знания в этой области.
Так разработчик может ответить дизайнеру, и на это может быть множество причин: ограничения системы, близость релиза, загрузка человека. Но дизайнер не всегда до конца понимает эти технические моменты и может думать, что вы просто не хотите этим заниматься.
Совет. Спросите/объясните, почему нельзя — более простым языком, “на пальцах”, попробуйте сделать это чуть позже, либо облегчить первоначальный вариант.
Дизайнер может что-то поменять в макете по ряду причин: проведенному исследованию, при изменении системы, изменении процессов приложения. Здесь параллель такая — всем нам нужны четко описанные задачи. Если кто-то где-то что-то поменял и никому не сказал, то никто об этом не узнает. Очень важно договориться о микроизменениях — это совсем не сложно.
Совет. Попросите дизайнера делать в макете метки с изменениями и расставить приоритеты. Это удобное решение для визуального ориентирования. Раньше часто делали общую папку с версиями макетов и ui китами. Сейчас подобные изменения отлично подмечаются в zeplin.
Если не указаны состояния элементов или в макете не учитываются какие-то особенности процесса, не делайте это за дизайнера. Все могут что-то забыть или не продумать, все мы люди. В любом случае, каждый должен заниматься своей работой.
Это довольно спорный кейс, и большинство моих знакомых дизайнеров были от него не в восторге. Но есть и противоположные мнения.
Это боль каждого дизайнера, поэтому обязательно делайте дизайн-ревью (без него работа по дизайну не считается законченной). Дизайнеры подмечают каждый пиксель, помогут исправить какие-то мелочи или ошибки. Но иногда после проверки может понадобится переделать всю верстку. Чтобы этого избежать, пользуйтесь инструментами для ее проверки, например Perfect Pixel.
Если все-таки продукт отличается от макетов, причина может быть в идеальных данных. Не используйте lorem ipsum. Контент всегда является частью решения, а фейковое наполнение не даст увидеть важные интерфейсные кейсы.
Разработчик не может понять значения элементов в макете, элементы не соответствуют области приложения или общепринятому интуитивному интерфейсу для пользователя.
Совет. Скажите об этом дизайнеру. Конечно, критика не всегда бывает приятна, но конструктивная и корректная обратная связь всегда полезна для продукта.
Вам было бы понятно что значит эта иконка?
При первом знакомстве команды стоит просто поговорить — узнать, с чем до этого работал каждый из вас, особенности будущей или существующей системы.
Договоритесь о четком и последовательном рабочем процессе. Работайте в общей среде, интересуйтесь друг другом. Приветствуйте креатив обеих сторон. Делитесь обратной связью.
Уважение — важный аспект, но его невозможно включить, как кнопку, его нужно заслужить своей работой. Для это нужно:
Хорошо, когда ты готов выложить все свои силы, чтобы сделать продукт, а не выложить все свои упреки.
На самом деле, идеального рецепта нет. Ограничения создаются не просто так, а командная игра помогает их преодолеть. Реальность такова, что вся разработка — это дизайн, и весь дизайн — это разработка. Одно не может существовать без другого.
Были ли у вас подобные истории? Поделитесь в комментариях, как вы их решали или НЕ решали.
P. S. Благодарю за помощь Бориса Мануковского и Дизайн-центр Сбертеха
P. P. S. Всех с днем радио!
В посте я разберу не новую, но всегда актуальную тему — взаимоотношения дизайнера и фронтенд-разработчика. Статья пригодится новичкам и командам, у которых еще не выстроены процессы работы. Рассмотрим несколько примеров из жизни и попробуем разобраться, как избежать разногласий.
Наверняка большинство читателей Хабр сталкивались с такими ситуациями.
1. Непонятные термины
Вместо комментариев по верстке разработчик получил непонятные термины, либо дизайнер не понимает терминов верстки. Это связано с тем, что каждый рассматривает продукт из своей области. Поэтому стоит использовать общий словарь терминов.
Например, в дизайне есть понятие интерлиньяж, который дословно означает «между линий». Аналогом в верстке является line-height.
Отсюда вытекает интересный вопрос — должен ли дизайнер понимать код, а разработчик понимать принципы дизайна? В статье «Почему дизайнер и разработчик должны работать вместе» автор дает советы по этому поводу. Чтобы преодолеть разрыв, разработчик и дизайнер должны говорить на одном языке и, по возможности, расширять свои наборы навыков.
И дизайнер, и разработчик должны иметь базовые знания:
- основ дизайна, таких как цвета и шрифты
- оптимальных графических форматов и калибровки
- HTML и CSS
- тенденций в дизайне и разработке
- потребностей и желаний пользователя
- сеток, рамок и каркасного моделирования
В реальной жизни все бывает не так идеально, поэтому не стоит ругать дизайнера, если он не хочет учить верстку, или обвинять разработчика в том, что он по-своему видит интерфейс.
Совет. Объясните коллеге какие-то моменты подробнее, и возможно, он захочет дальше развивать свои знания в этой области.
2. Это невозможно сделать
Так разработчик может ответить дизайнеру, и на это может быть множество причин: ограничения системы, близость релиза, загрузка человека. Но дизайнер не всегда до конца понимает эти технические моменты и может думать, что вы просто не хотите этим заниматься.
Совет. Спросите/объясните, почему нельзя — более простым языком, “на пальцах”, попробуйте сделать это чуть позже, либо облегчить первоначальный вариант.
3. Я что-то поменял в макете
Дизайнер может что-то поменять в макете по ряду причин: проведенному исследованию, при изменении системы, изменении процессов приложения. Здесь параллель такая — всем нам нужны четко описанные задачи. Если кто-то где-то что-то поменял и никому не сказал, то никто об этом не узнает. Очень важно договориться о микроизменениях — это совсем не сложно.
Совет. Попросите дизайнера делать в макете метки с изменениями и расставить приоритеты. Это удобное решение для визуального ориентирования. Раньше часто делали общую папку с версиями макетов и ui китами. Сейчас подобные изменения отлично подмечаются в zeplin.
4. Этого не было в макете и я придумал сам
Если не указаны состояния элементов или в макете не учитываются какие-то особенности процесса, не делайте это за дизайнера. Все могут что-то забыть или не продумать, все мы люди. В любом случае, каждый должен заниматься своей работой.
Это довольно спорный кейс, и большинство моих знакомых дизайнеров были от него не в восторге. Но есть и противоположные мнения.
5. Верстка не совпадает с макетом
Это боль каждого дизайнера, поэтому обязательно делайте дизайн-ревью (без него работа по дизайну не считается законченной). Дизайнеры подмечают каждый пиксель, помогут исправить какие-то мелочи или ошибки. Но иногда после проверки может понадобится переделать всю верстку. Чтобы этого избежать, пользуйтесь инструментами для ее проверки, например Perfect Pixel.
Если все-таки продукт отличается от макетов, причина может быть в идеальных данных. Не используйте lorem ipsum. Контент всегда является частью решения, а фейковое наполнение не даст увидеть важные интерфейсные кейсы.
6. Несоответствие дизайна
Разработчик не может понять значения элементов в макете, элементы не соответствуют области приложения или общепринятому интуитивному интерфейсу для пользователя.
Совет. Скажите об этом дизайнеру. Конечно, критика не всегда бывает приятна, но конструктивная и корректная обратная связь всегда полезна для продукта.
Вам было бы понятно что значит эта иконка?
Общие советы
При первом знакомстве команды стоит просто поговорить — узнать, с чем до этого работал каждый из вас, особенности будущей или существующей системы.
Договоритесь о четком и последовательном рабочем процессе. Работайте в общей среде, интересуйтесь друг другом. Приветствуйте креатив обеих сторон. Делитесь обратной связью.
Уважение — важный аспект, но его невозможно включить, как кнопку, его нужно заслужить своей работой. Для это нужно:
- показать, что ты умеешь слушать
- показать, что ты умеешь искать решение вместо критики
- показать, что ты ценишь свой труд и своих коллег
- показать, что ты все время развиваешься и трудишься, готов делиться знаниями и обучать других
- показать, как для тебя важно сделать именно этот продукт
- наконец показать, что ты готов преодолевать разногласия, противоречия и идеологические трения с другими участниками, если есть шанс улучшить результат.
Хорошо, когда ты готов выложить все свои силы, чтобы сделать продукт, а не выложить все свои упреки.
Итог
На самом деле, идеального рецепта нет. Ограничения создаются не просто так, а командная игра помогает их преодолеть. Реальность такова, что вся разработка — это дизайн, и весь дизайн — это разработка. Одно не может существовать без другого.
Были ли у вас подобные истории? Поделитесь в комментариях, как вы их решали или НЕ решали.
P. S. Благодарю за помощь Бориса Мануковского и Дизайн-центр Сбертеха
P. P. S. Всех с днем радио!
Комментарии (6)
kucheriavij
07.05.2018 10:27Сколько уже было про perfect pixel расписано. Сколько людей распиналось что это трата времени и работа на показушность, и вроде-бы все всё поняли, и снова он вылезает. Этот инструмент нужен только тогда, когда в макете используется продакшен текст, и никогда иначе, в противных случаях это будет подгонка решения под ответ, и после вставки продакшен контента приходится потом править верстку…
Я понимаю, что у вас в сбере в макетах наверняка используется онли продакшен контент и так далее. Но не все работают в сбере, и не во всех случаях заказчик предоставляет адекватный контент, поэтому приходится работать с тем что есть, и вот в таких случаях «пиксель перфект» не уместен, от слова совсемZenitchik
07.05.2018 10:46Всё ещё веселее, если нужно поддерживать старого ишака. Различия между браузерами ±пиксель — гарантированы, приходится договариваться, который браузер должен считаться основным, а в остальных — допускать смещение на пиксель-другой.
kucheriavij
07.05.2018 11:25Есть такое, к счастью в моей практике ишак уже не требует никто. Даже муниципальщики требовали его последний раз лет 5-6 назад, сейчас и они его не проверяют
Zenitchik
07.05.2018 14:21В моей, в общем, тоже. Это я по старой памяти. 2 или 3 года назад самый отсталый из клиентов перестал требовать работы в IE8, а с IE9 — уже можно жить нормально.
drfisher
08.05.2018 18:41Если не указаны состояния элементов или в макете не учитываются какие-то особенности процесса, не делайте это за дизайнера.
На мой взгляд, удовлетворительное решение, созданное верстальщиком, лучше, чем отсутствующее идеальное от дизайнера. Не нужно ждать его ответа, нужно сделать самому, а дизайнеру потом просто сообщить, что мол вот, не стал ждать, сделал так… Если не понравится, он поправит, но зачастую дизайнера вполне устроит ваше решение. Ведь оно основано не на фантазии, а на опыте в подобных кейсах.
talik
Крайне наглядная аналогия будет с концепт-карами.
На выставках показывают очень красивве прототипы, но как только дело доходит до конвеера то технологи преврашают нарисованное дизайнерами в обычный, практичный продукт без извысков.