Рефакторинг макетов

Как подготовить дизайн для разработки

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

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

Рефакторинг дизайна — это процесс переработки макета, не создающий новых фич, который приводит к повышению качества макета.

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

Польза от рефакторинга:

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

Почему нельзя сразу делать хорошо

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

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

Дисклеймер

В статье будет понятный список действий, чтобы подговиться к рефакторингу «формы» интерфейса (UI) и исходников, и сделать его правильно.

В статье не будет ничего про рефакторинг «смысла» интерфейса (UX), потому что его сложно починить без переработки интерфейса, что равно по затратам новой фиче. Зато Юрий Ветров собрал несколько ссылок по этой теме.

Следите за алмазиком 💎 — он покажет, на какие моменты в статье нужно обратить внимание.

Алгоритм

0. Готовимся к рефакторингу

Нужно знать, что чинить. Иногда сразу понятно: так, тут я насоздавал кучу копий текста и не сменил названия. А если речь идёт про какие-то мелкие графические помарки, то без подсказки не обойтись.

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

В Трелло список может выглядеть так

Бывает, что для скорости делаешь несколько вариантов кнопки, используешь их в макете, а через неделю уже не помнишь, что их нужно собрать в один компонент.

1. Чиним «грехи»

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

💎 Открываем список с «грехами», сортируем по приоритетности и начинаем чинить.

2. Приводим к системности

Разработчики не любят случайные кегли, отступы, размеры элементов, потому что при разработке они превращаются из элегантных стилей в кучи костылей, исключений, выпригивающих из исключений и всё такое.

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

💎 Где можно строить систему:

• Сетка. Простым интерфейсам сетка может и не нужна, но сайту или приложению с несколькими экранами, который еще и периодически обновляется нужны правила расположения контейнеров.
• Отступы. Часто дизайнеры забывают про отступы от блоков и делают их случайными. См. Отступы в дизайне: системный подход.
• Цвета. Хороший способ улучшить эстетику и поддержать бренд интерфейса — поработать с цветовой палитрой. Выявить главные цвета, собрать набор дополнительных, избавить от грязных и случайных.
• Размеры. Легче всего внести какие-то закономерности в размеры — использовать модули определенного маленького размера (например, 8 px), а на основе них вычислять итоговые размеры.
• Типографика. Разработчикам и дизайнерам удобно, когда есть понятная иерархия кеглей и стилей типографики. Констистентность дизайна повышается, если используется набор очевидных надписей: заголовок, подзаголовок, основной текст, подпись и т. д.
• Стили элементов. Сюда относится то, как дизайнер формирует какие-то состояния кнопок, ссылок и интерактивных элементов, как должны изменяться цвета, размеры, по каким законам. Система дает предсказуемость и масштабируемость, при создании новых элементов не придется думать о том, как сильно затемнить кнопку.
• Набор компонентов. Дизайн-системы наше все, но это слишком обширная тема. Как минимум, стоит по-максимуму выносить повторяющиеся элементы в символы, декомпозировать их на атомы, а потом из этого собирать макеты.

Кнопки, построенные на модулях в 9 px

3. Уменьшаем количество сущностей

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

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

💎 Проверяем все элементы дизайна: кнопки, контролы, компоненты, блоки, типографику. Если есть похожие или почти одинаковые сущности — сливаем в одну или думаем, как построить систему.

Кнопки не дублируются, а строятся из одного компонента

4. Полируем артефакты

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

💎 Что проверяем:

• Правила именования. Лучше всего выбрать какой-то стиль, например, кебаб-кейс, договориться с командой и придерживаться его в проекте. Это касается файлов, разделов, артбордов, групп, слоев.
• Правильный порядок артбордов, групп и слоев. Опять же, выбран один способ и придерживаться его. Например, по горизонтали располагать разные экраны, а по вертикали состояния этих экранов. См. статью Сергея Плаща.
• Настройка экспортов. Разработчики конечно сами могут всё это настроить, но дизайнеру сделать это легче и проще. 5 минут — и экспорт есть у нужных артбордов, ассетов и иконок.
• Доступность ассетов. В макетах используются шрифты, иконки, фотографии. Всё это нужно предоставить разработчикам в удобном виде. Если это Скетч, то просто положить рядом с файлом в отдельные папки. И не забыть про лицензии.
• Документация. Стайлгайд, матрица состояний, области клика, граничные случаи — всё это помогает разработчикам не додумывать дизайн за дизайнера, а качество продукта на выходе улучшается.
• Версионирование. Тут тема сложная. Если в команде не используется Фигма или Скетч с абстрактом, то нужно убедиться, что разработчики получат правильную свежую версию и не запутаются.

Пример именования артбордов по BEM’у

Что нужно запомнить

1. Держаться главного правила: после рефакторинга не должны появиться новые фичи, экраны, измениться или добавиться сценарии.
2. Во время дизайна не забывать записывать все косяки, которые обычно остаются на потом.
3. Подходить к дизайну системно: использовать сетку, думать о цветовой палитре, работать с вертикальным ритмом, использовать понятную типографику, собирать систему компонентов.
4. Чем меньше сущностей — тем лучше. Периодически нужно проверять все элементы и пытаться упростить, если получается.
5. Заботиться об артефактах: правила именования, порядок артбордов/слоев/групп, экспорты, ассеты, документация, версионироване.

Матвей Правосудов

Мой телеграм-канал, где я делюсь мыслями про работу, дизайн, и продуктивность: Task → Solution.