Привет, Хабр! Меня зовут Лена Жукова, я фронтенд-разработчик в Сбертехе.
В этом посте я затрону не новую, но всегда актуальную тему — взаимоотношения дизайнера и фронтенд-разработчика.
Статья будет полезна новичкам и командам, у которых еще не выработаны рабочие процессы.
Давайте рассмотрим несколько примеров из жизни и попробуем разобраться, как избежать разногласий.
Наверняка большинство читателей Хабра сталкивались с такими ситуациями.
1. Запутанные термины
Вместо комментариев к макету разработчик получил непонятные термины или дизайнер не понимает термины макета.Это связано с тем, что каждый рассматривает продукт из своей области.
Поэтому стоит воспользоваться общим словарем терминов.
Например, в дизайне есть понятие «лидинг», что буквально означает «между строк».
Аналог по раскладке — line-height. Возникает интересный вопрос: должен ли дизайнер понимать код и должен ли разработчик понимать принципы дизайна? В статье «Почему дизайнер и разработчик должны работать вместе» автор дает советы по этому поводу.
Чтобы преодолеть этот разрыв, разработчик и дизайнер должны говорить на одном языке и, где это возможно, расширять свои навыки.
И дизайнер, и разработчик должны обладать базовыми знаниями:
- основы дизайна, такие как цвета и шрифты
- оптимальные графические форматы и калибровка
- HTML и CSS
- тенденции в дизайне и разработке
- потребности и желания пользователей
- сетки, рамки и каркасное моделирование
Совет. Некоторые моменты объясните своему коллеге подробнее, и возможно, он захочет и дальше развивать свои знания в этой области.
2. Это невозможно сделать
Так разработчик может ответить дизайнеру, и причин этому может быть много: ограничения системы, близость к релизу, загруженность человека.Но дизайнер не всегда до конца понимает эти технические моменты и может подумать, что вы просто не хотите этим заниматься.
Совет. Спросите/объясните, почему нельзя - более простым языком, «на пальцах», попробуйте сделать чуть позже или упростите первоначальный вариант.
3. Я что-то изменил в макете
Дизайнер может что-то изменить в макете по ряду причин: исследование, изменение системы, изменение процессов применения.Параллель здесь такая: нам всем нужны четко описанные задачи.
Если кто-то где-то что-то изменил и никому не сказал, то никто об этом не узнает. Очень важно договориться о микроизменениях – это совсем не сложно.
Совет. Попросите дизайнера отметить изменения в макете и расставить их приоритеты.
Это удобное решение для визуального ориентирования.
Раньше мы часто создавали общую папку с версиями макетов и ui-китов.
Теперь такие изменения отчетливо видны в цеплин .
4. Этого не было в макете и я это придумал сам
Если не указаны состояния элементов или в макете не учтены какие-то особенности процесса, не делайте это за дизайнера.Каждый может что-то забыть или не додумать, все мы люди.
В любом случае каждый должен делать свою работу.
Это достаточно спорный случай, и большинство знакомых мне дизайнеров он был не в восторге.
Но есть также противоположные мнения .
5. Макет не соответствует макету
Это боль каждого дизайнера, поэтому обязательно сделайте ревью дизайна (без него работа по дизайну не считается завершенной).Дизайнеры замечают каждый пиксель и помогут исправить любые мелочи и ошибки.
Но иногда после проверки может потребоваться переделать всю планировку.
Чтобы этого избежать, используйте инструменты для проверки, например Идеальный пиксель .
Если товар все же отличается от макетов, причина может быть в идеальных данных.
Не используйте lorem ipsum. Контент всегда является частью решения, а фейковый контент не позволит вам увидеть важные кейсы интерфейса.
6. Непоследовательность дизайна
Разработчик не может понять значение элементов в макете, элементы не соответствуют сфере применения приложения или в целом интуитивному пользовательскому интерфейсу.Совет. Расскажите об этом дизайнеру.
Конечно, критика не всегда приятна, но конструктивная и правильная обратная связь всегда полезна для продукта.
Вы понимаете, что означает этот значок?
Общие советы
При первой встрече команды вам следует просто поговорить — узнать, с чем каждый из вас работал раньше, особенности будущей или существующей системы.Договоритесь о четком и последовательном рабочем процессе.
Работайте в общей среде, интересуйтесь друг другом.
Поддержите творчество обеих сторон.
Поделитесь своим отзывом.
Уважение – важный аспект, но его нельзя включить как кнопку, его нужно заслужить трудом.
Для этого вам нужно:
- покажи, что ты умеешь слушать
- покажите, что вы умеете искать решение, а не критиковать
- покажите, что вы цените свою работу и своих коллег
- покажите, что вы постоянно развиваетесь и работаете, готовы делиться знаниями и учить других
- покажите, насколько важно для вас сделать именно этот продукт
- наконец, покажите, что вы готовы преодолевать разногласия, противоречия и идеологическую напряженность с другими участниками, если есть шанс улучшить результат.
Нижняя граница
На самом деле идеального рецепта не существует. Ограничения создаются не просто так, а командная игра помогает их преодолеть.Реальность такова, что всякая разработка — это дизайн, а любой дизайн — это разработка.
Одно не может существовать без другого.
Были ли у вас подобные истории? Поделитесь в комментариях, как вы их решили или НЕ решили.
P.S. Спасибо за помощь Борису Мануковскому и Дизайн-центру Сбертеха.
П.
П.
С.
Всех с днём радио! Теги: #Разработка сайтов #дизайн #фронтенд #Графический дизайн #веб-дизайн #сбертех #сбертех #Сбертех
-
Хорошая Мелочь В Gmail
19 Oct, 24 -
Подробное Руководство По Вскрытию
19 Oct, 24 -
«Финам» Вложит В Ит Еще 150 Млн Руб.
19 Oct, 24 -
Модульные Тесты И Наследование
19 Oct, 24 -
Кластеризация Google Карт
19 Oct, 24 -
Типография Муравьева Опубликована На Github
19 Oct, 24
