Дизайн в Figma, который полюбят разработчики
Недавно я выступил на Figma Config 2022 с докладом под названием «Как создать дизайн Figma, который полюбят разработчики».
Так как презентация была на японском языке, а я хотел поделиться содержанием с большим количеством людей, я решил перевести ее и на английский. Надеюсь, вам понравится!
Что такое «Дизайн, который любят разработчики»
Я считаю, что есть два основных критерия:
- Понятные цели и идеи дизайна;
- Простота обновления реализации при изменении дизайна.
На мой взгляд, первого можно достичь с помощью структурированного дизайна, а второго — с помощью дизайн-системы.
Структурированный дизайн — это концепция, которую мы представили на конференции Figma по дизайн-системам в 2021 году. Существует две формы дизайна: произвольная и структурированная.
Поскольку строгого определения этих терминов не существует, я буду говорить, исходя из своего понимания. Произвольная форма удовлетворяет только внешний вид. Структурированный же дизайн определяет поведение, отличное от внешнего вида, и организует данные дизайна.
Для чего нужны разные формы дизайна?
Я считаю, что это потому, что у самого понятия «дизайн» есть две цели.
Одна из них — проверка гипотезы UI.
На этом этапе цель состоит в том, чтобы создать разные дизайн-концепты и принять решение «Давайте использовать этот интерфейс!» Поскольку эти концепты еще не определены и будут неоднократно пересматриваться и меняться, структурирование дизайна может быть бесполезным и даже мешающим.
Другая цель состоит в том, чтобы передать замысел проекта так, чтобы его поняли разработчики.
Замыслом или задумкой будем называть все, что намеревался передать дизайнер. Если в конечной реализации были использованы не те начертания шрифтов, отступы или цвета, значит, замысел не передан. И часто проблема именно в том, как дизайн организован.
Конечная цель дизайна — воплотить его в рабочий продукт. А чтобы все прошло гладко, дизайн должен быть структурирован. Разработчики при реализации должны легко получать все необходимые значения. И желательно, чтобы даже в теории было сложно возникнуть какому-то недопониманию.
Кроме этого, структурированность помогает сделать дизайн «ремонтопригодным» и качественным в долгосрочной перспективе. Возможность беспрепятственно реализовать эти две формы дизайна — одна из причин, по которой Figma так любима.
В этой статье я хотел бы поговорить о том, как из произвольного дизайна сделать структурированный, а также дать пару советов о том, как сделать дизайн простым для восприятия. Обновление: т. е. как систематизировать свой дизайн.
Правильно передайте замысел дизайна
Чтобы разработчик превратил дизайн в настоящий рабочий экран, в коде должны быть отражены различные значения. Важно иметь возможность быстро и без расхождений сообщить о «замысле дизайна».
Что такое «замысел» дизайна?
Я уверен, что существует много других деталей, но рассмотрим только четыре основные категории:
- Визуальные свойства — цвета, типографика и т. д.
- Макет;
- Адаптивность;
- Состояния.
1. Визуальные свойства
О визуальных свойствах особо беспокоиться не стоит — их легко найти на панели дизайна Figma. Но это, конечно, если вы не делаете ничего странного.
Однако тут могу посоветовать следить за высотой строки. Если она не установлена должным образом, может возникнуть несоответствие между значениями отступов и тем, как они выглядят на холсте.
2. Макет
Что касается компоновки, я считаю важным «создавать слои, подобные коду», при этом правильно используя такие функции, как Auto Layout.
Так можно избежать анти-паттернов, которые затрудняют понимание замысла дизайна, и предотвратить проекты, которые трудно реализовать.
Например, я столкнулся со следующими анти-паттернами, в которых несколько строк текста представлены разрывами строк. Из-за этого невозможно было считать значение отступа.
Отступы ниже не установлены, что оставляет место для интерпретации разработчиком (т. е. фактическая реализация может отличаться от того, что задумал дизайнер). Это может привести к снижению «ремонтопригодности» в будущем.
Тогда что нам нужно сделать, чтобы иметь возможность создавать слои, подобные коду?
(Кстати, используя термин «код», я имею в виду только визуальную часть, которая представляет собой HTML и CSS для интернета, не включая JS.)
Многие вещи достаточно похожи в Figma и коде. Например, Auto Layout — это почти то же самое, что Flexbox в CSS.
Ограничения (constraints) также работают для указания относительной ширины/высоты и работают как position:absolute.
Я думаю, изучение кода приводит к лучшему дизайну, слои которого будут более тесно связаны со структурой HTML-тегов.
Еще один важный способ получить обратную связь — попытаться реализовать свой собственный дизайн.
Однако, учитывая тот факт, что вы создали все сами и знаете детали замысла дизайна, лучше получить отзывы от других разработчиков. И подумать, можно ли улучшить дизайн там, где есть отличия от готового продукта.
3. Адаптивность
Когда вы слышите слово «адаптивный», вы, вероятно, думаете о дизайне для разных точек останова, таких как десктоп, планшет, мобильный телефон и так далее.
Однако в дополнение к этому в коде также необходимо определить поведение при изменении размера экрана даже в пределах одного и того же типа устройства.
Это можно определить с помощью ограничений (constraints в Figma), которые определяют, как слои будут (или не будут) изменяться при изменении размера родительского фрейма.
Также свойство Resize в Auto Layout позволяет указать, должны ли ширина и высота изменяться в соответствии с высотой дочернего элемента или иметь фиксированные значения.
4. Состояния
Пользовательский интерфейс динамичен и имеет много разных состояний.
UI Стек — это хорошо известная диаграмма, и такие состояния, как Пустое, Загрузка и Ошибка, часто отсутствуют и не обнаруживаются до тех пор, пока разработчик не реализует пользовательский интерфейс.
В дополнение к этому также полезно создавать прототипы, чтобы облегчить просмотр переходов пользователя. Прототипы в основном используются для тестирования интерфейса, но с точки зрения разработчика также полезно видеть переходы при взаимодействии.
Для прототипов можете использовать плагин ProToFlow. Он отображает стрелки переходов на панели дизайна, поэтому разработчикам не нужно переключаться на панель прототипов, чтобы увидеть их.
Еще важны варианты и интерактивные компоненты. Варианты могут представлять несколько состояний компонента, а интерактивные компоненты могут отображать переходы между этими состояниями.
Непрерывная реорганизация дизайна
Я успел обозначить уже много вещей, но некоторые из вас могут задаться вопросом: «Должен ли я делать все эти вещи одновременно?»
Мой ответ: «Нет, вы можете делать это постепенно».
Не обязательно делать все с самого начала. Нужно просто уметь отделять этап дизайна от этапа передачи.
Целью первой фазы дизайна является принятие решения «Давайте использовать этот UI», как объяснялось в начале статьи.
На этом этапе мы создаем лоу-фиделити и хай-фиделити прототипы, не прилагая слишком много усилий к детальному внешнему виду или структурированию дизайна.
После этого мы переходим к фазе передачи, где структурируем дизайн и добавляем заметки, чтобы разработчики могли легко все понять.
Я называю этот процесс, направленный на то, чтобы сделать сам дизайн более удобным в сопровождении, «рефакторингом» дизайна.
Также в инженерной культуре существует практика проведения «долгового дня» (извините, если он существует только в японской инженерной культуре). Это день, когда мы работаем только над оставшимися долгами, то есть подгоняем хвосты.
Я думаю, что делать то же самое с дизайном было бы достаточно эффективным.
Сложно постоянно следить за тем, чтобы дизайн был оптимальным. А особенно когда появляется много новых требований. Поэтому я думаю, что было бы хорошо, если бы мы могли создать механизм улучшения дизайна, основанный на предпосылке, что «долги всегда накапливаются».
Сделайте дизайн легким для обновления
Теперь давайте поговорим о следующей важной теме: облегчение обновлений дизайна. Если мыслить как разработчики, «дизайн, который легко обновлять» означает «в код легко вносить изменения». Для этого важно систематизировать дизайн, другими словами построить дизайн-систему.
Почему дизайн-система выгодна и разработчику? Потому что, когда дизайн систематизирован, согласованный интерфейс создается с использованием уже определенных токенов и компонентов. Это делает кодирование простым и быстрым, поскольку код также может повторно использовать уже определенные ресурсы.
Обсудим следующие два момента, которые можно использовать при систематизации дизайна в Figma:
- Дизайн-токены;
- Компоненты/варианты.
Дизайн-токены
Прежде всего, «что такое дизайнерский токен?» Определение следующее.
Дизайн-токены — это неделимые части дизайн-системы, такие как цвета, интервалы, масштаб типографики.
Один из способов добиться этого в Figma — использовать стандартную функцию под названием Стили.
Их важно использовать, но они не имеют функций для экспорта/импорта настроек, которые позволяли бы задействовать их в коде.
По этой причине настоятельно рекомендую использовать плагин под названием Figma Tokens.
Он позволяет сохранять разные значения, которые нельзя определить как стиль в Figma. Например, интервал, радиус скругления и т. д. Также плагин позволяет выводить результат в виде JSON и синхронизироваться с GitHub. Отличная вещь для использования дизайн-токенов, поэтому обязательно попробуйте.
Компоненты/варианты
Figma позволяет вам определять компоненты и несколько состояний этих компонентов как варианты.
И при определении компонента важно согласовать детализацию, имя и свойства между дизайном и кодом. Отчасти это связано с тем, что они предназначены для общего языка дизайна, а отчасти потому, что, если они не установлены, сложность обновления кода при обновлении дизайна может возрасти.
А еще думаю, что очень эффективно создавать компоненты вместе с разработчиками.
Приведенные выше вещи — это именно то, о чем разработчики думают в своей повседневной работе, поэтому, принимая их во внимание, вы сможете создавать более удобные компоненты. Кроме того, это хороший способ сократить количество переделок, убедившись, что дизайнеры осведомлены о работе друг друга.
Коммуникация
Итак, поговорив о технических вещах, я хотел бы закончить обсуждением коммуникации. Тут важны такие моменты:
- У разных компаний свое виденье удобного дизайна;
- Некоторые вещи необязательно внедрять в дизайн, этим самым загромождая его. Многое можно передать словами.
Во-первых, каждая организация имеет свои уникальные характеристики. Некоторые разработчики знакомы с дизайном и Figma, некоторые нет, у некоторых небольшое количество разработчиков, а у некоторых куча разработчиков и команд.
Таким образом, единой формулы для идеального дизайна не существует. Я думаю, всегда хорошо обсудить и изучить наилучшую форму дизайна для каждой организации.
Например, если что-то сложно выразить в Figma, можно просто сделать пометку.
Также полезно провести встречу при передаче дизайна разработчику.
Кроме того, как и в случае с компонентами, упомянутыми ранее, полезно давать разработчикам просматривать проект еще на стадии дизайна. Это поможет избежать отката на несколько шагов назад на этапе передачи дизайна в разработку. И в целом ускорит процесс.
Структурирование дизайна — очень важный процесс, но я за то, чтобы сделать его достаточно гибким и не слишком строгим.
Вывод
Способ создания дизайна может влиять на общую скорость и качество разработки продукта. Как в положительную, так и в отрицательную сторону.
Чем более проект структурирован и продуман, тем легче разработчикам понять его замысел и быстро (и качественно) его реализовать.
Кроме того, степень структурированности дизайна зависит от конкретной компании. Поэтому давайте общаться друг с другом и искать наилучшую форму!
