company_banner

Дизайнеры и разработчики: заклятые друзья и лучшие враги

    Привет, Хабр! Меня зовут Лена Жукова, я фронтенд-разработчик в Сбертехе.

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



    Наверняка большинство читателей Хабр сталкивались с такими ситуациями.

    1. Непонятные термины


    Вместо комментариев по верстке разработчик получил непонятные термины, либо дизайнер не понимает терминов верстки. Это связано с тем, что каждый рассматривает продукт из своей области. Поэтому стоит использовать общий словарь терминов.

    Например, в дизайне есть понятие интерлиньяж, который дословно означает «между линий». Аналогом в верстке является line-height.

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

    И дизайнер, и разработчик должны иметь базовые знания:

    • основ дизайна, таких как цвета и шрифты
    • оптимальных графических форматов и калибровки
    • HTML и CSS
    • тенденций в дизайне и разработке
    • потребностей и желаний пользователя
    • сеток, рамок и каркасного моделирования

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

    Совет. Объясните коллеге какие-то моменты подробнее, и возможно, он захочет дальше развивать свои знания в этой области.

    2. Это невозможно сделать


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

    Совет. Спросите/объясните, почему нельзя — более простым языком, “на пальцах”, попробуйте сделать это чуть позже, либо облегчить первоначальный вариант.

    3. Я что-то поменял в макете


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

    Совет. Попросите дизайнера делать в макете метки с изменениями и расставить приоритеты. Это удобное решение для визуального ориентирования. Раньше часто делали общую папку с версиями макетов и ui китами. Сейчас подобные изменения отлично подмечаются в zeplin.



    4. Этого не было в макете и я придумал сам


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

    Это довольно спорный кейс, и большинство моих знакомых дизайнеров были от него не в восторге. Но есть и противоположные мнения.

    5. Верстка не совпадает с макетом


    Это боль каждого дизайнера, поэтому обязательно делайте дизайн-ревью (без него работа по дизайну не считается законченной). Дизайнеры подмечают каждый пиксель, помогут исправить какие-то мелочи или ошибки. Но иногда после проверки может понадобится переделать всю верстку. Чтобы этого избежать, пользуйтесь инструментами для ее проверки, например Perfect Pixel.

    Если все-таки продукт отличается от макетов, причина может быть в идеальных данных. Не используйте lorem ipsum. Контент всегда является частью решения, а фейковое наполнение не даст увидеть важные интерфейсные кейсы.

    6. Несоответствие дизайна


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


    Вам было бы понятно что значит эта иконка?

    Общие советы


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

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

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

    Хорошо, когда ты готов выложить все свои силы, чтобы сделать продукт, а не выложить все свои упреки.

    Итог


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

    Были ли у вас подобные истории? Поделитесь в комментариях, как вы их решали или НЕ решали.

    P. S. Благодарю за помощь Бориса Мануковского и Дизайн-центр Сбертеха

    P. P. S. Всех с днем радио!
    • +10
    • 5,4k
    • 6

    Сбербанк

    185,97

    Компания

    Поделиться публикацией
    Комментарии 6
      0
      Крайне наглядная аналогия будет с концепт-карами.
      На выставках показывают очень красивве прототипы, но как только дело доходит до конвеера то технологи преврашают нарисованное дизайнерами в обычный, практичный продукт без извысков.
        +1
        Сколько уже было про perfect pixel расписано. Сколько людей распиналось что это трата времени и работа на показушность, и вроде-бы все всё поняли, и снова он вылезает. Этот инструмент нужен только тогда, когда в макете используется продакшен текст, и никогда иначе, в противных случаях это будет подгонка решения под ответ, и после вставки продакшен контента приходится потом править верстку…

        Я понимаю, что у вас в сбере в макетах наверняка используется онли продакшен контент и так далее. Но не все работают в сбере, и не во всех случаях заказчик предоставляет адекватный контент, поэтому приходится работать с тем что есть, и вот в таких случаях «пиксель перфект» не уместен, от слова совсем
          0
          Всё ещё веселее, если нужно поддерживать старого ишака. Различия между браузерами ±пиксель — гарантированы, приходится договариваться, который браузер должен считаться основным, а в остальных — допускать смещение на пиксель-другой.
            0
            Есть такое, к счастью в моей практике ишак уже не требует никто. Даже муниципальщики требовали его последний раз лет 5-6 назад, сейчас и они его не проверяют
              0
              В моей, в общем, тоже. Это я по старой памяти. 2 или 3 года назад самый отсталый из клиентов перестал требовать работы в IE8, а с IE9 — уже можно жить нормально.
          0
          Если не указаны состояния элементов или в макете не учитываются какие-то особенности процесса, не делайте это за дизайнера.

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

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое