Главное недопонимание
Дизайнер думает картинками, разработчик — состояниями и данными. Макет показывает один момент, а программа должна работать во всех.
Отсюда классический конфликт: дизайнер отдаёт красивый экран, разработчик спрашивает «а что если имя длинное, а если товаров ноль, а если картинка не загрузилась» — и оказывается, что об этом не думали.
Хороший дизайнер закрывает эти вопросы до того, как их зададут.
Что передавать вместе с макетом
Состояния. Не один экран, а пять:
- обычный;
- загрузка;
- пусто, когда данных нет;
- ошибка;
- край: очень длинный текст, много элементов, отсутствующая картинка.
Именно эти состояния занимают большую часть времени разработки, и именно их дизайнеры чаще всего не рисуют.
Поведение. Что происходит при нажатии, куда ведёт, что меняется. Стрелочки на схеме или короткое описание.
Правила адаптации. Как это выглядит на телефоне. Не «уменьшите пропорционально» — на узком экране раскладка обычно меняется принципиально.
Систему, а не набор экранов. Одна кнопка с описанными состояниями, а не двадцать кнопок, слегка отличающихся друг от друга. Разработчик соберёт из компонентов, и если компоненты не совпадают, он будет спрашивать про каждое отличие.
Чего избегать
Магических отступов. 13, 17, 22 пикселя — признак того, что двигали на глаз. Используйте шаг: 4, 8, 12, 16.
Двадцати оттенков серого. Соберите палитру и придерживайтесь.
Шрифтов, которых нет. Проверьте, доступен ли он и как это скажется на скорости загрузки.
Эффектов, дорогих в реализации. Сложная анимация или необычная раскладка могут стоить дня работы. Спросите заранее, стоит ли того.
Как договариваться
Разработчик говорит «так нельзя» — это редко упрямство. Обычно за этим стоит: долго, ломается на телефоне, недоступно с клавиатуры, требует переделки данных.
Продуктивный разговор выглядит так: выясните ограничение, назовите, что для вас важно, найдите вариант. «Мне важно, чтобы главное действие было заметно. Если так сделать сложно — давайте выделим цветом, а не размером».
Непродуктивный: «в макете так, сделайте так».
Что стоит понимать про реализацию
Не программировать, а понимать порядок величин:
- Изменение отступа — минуты. Изменение структуры экрана — дни. Отсюда: правки по мелочи вносить легко, а переделку раскладки надо обсуждать заранее.
- Данных может не быть. Всё, что приходит с сервера, иногда не приходит.
- Текст меняется. Особенно при переводе: то, что помещалось, перестаёт.
Что улучшает работу больше всего
Присутствие дизайнера при обсуждении, а не передача макета через стену. Пятнадцать минут разговора на старте экономят три круга правок.
И совместная работа над проектом с самого начала. Дизайнер, который был в команде и видел, как его решения реализуются, растёт быстрее — он перестаёт рисовать то, что невозможно сделать, и начинает предлагать то, что даёт результат за разумное время.
Хватит читать — пора делать
На CohortX можно найти команду под пет-проект и получить тот самый опыт, о котором спрашивают на собеседовании.
Похожие статьи
- How designers work with developersWhat to hand over with a mockup, why 'just make it look like the picture' fails, and how to negotiate compromises.
- Code review: taking part without taking offenceWhy review exists, how to receive comments, how to give them, and why it's a beginner's greatest source of growth.
- Разбор кода: как участвовать и не обижатьсяЗачем нужен код-ревью, как принимать замечания, как давать их самому и почему это главный источник роста для новичка.