Я бог продуктивности: пять шагов, чтобы познать радость быстрых правок в ките Figma

Перестроили процесс работы команды с атомарным китом в Figma: изменения элементов — во всех экранах или локально — занимают несколько минут. В статье — как было и как стало, а также файл-пример для тренировки.

Сами породили проблему. У нас детальное проектирование: мы не рисуем исключительно основные экраны в авторизации — мы рисуем 70 и более экранов. Они содержат состояния всех элементов, все тексты всех возможных ошибок по всем каналам (push, SMS, email и так далее), все мелкие негативные и альтернативные сценарии, которые могут случиться с пользователем.

Каждый раз, когда требовались правки в элементы, изменения приходилось вносить во все экраны и параллельно отлавливать возможные ошибки. Процесс превращался в рутинную продолжительную драму. А иногда и не рутинную: два дня тщательно вносишь правки по просьбе клиента, а при проверке он находит то единственное место, где ты пропустил.

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

В прошлом году жизнь изменилась. Мы перестроили процесс работы команды с атомарным китом и научились вносить правки сразу по всему дизайну или локально. Вместо 1–2 дней — минуты, вместо десятков кликов — 1–2–3. «О господи, какой прекрасный кит я придумал! Я бог продуктивности. Я гуру фигмы», — кайф пришёл на смену боли.

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

Наша дизайнерская вселенная населена пятью сущностями, две из них — наша находка.

Выглядит так:

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

Как это сделать — объясняем и показываем на примерах.

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

Создание атома происходит в три клика.

Изменения — примерно так же.

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

Молекула — группа двух или более атомов. Она содержит те атомы, которые нужны для работы элемента: например, кнопка состоит из атома прямоугольника, текста, иконки, а карточка товара — это прямоугольник, текстовые контейнеры (например, «Название товара», «Описание товара»), изображение.

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

Чтобы собрать молекулу, поместите все атомы на Frame, выделите и нажмите Command+K. Затем разместите, как нужно:

И как можно её изменить:

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

Организм — это состояние молекулы: например, кнопка может быть доступна или недоступна. В организмах мы чаще всего редактируем цвета и иконки, иногда текст — если он не меняется нигде и никогда (например, в тап-баре всего приложения).

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

Теперь покажем, как править организмы:

Важно!

Как неправильно:

Как правильно:

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

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

Создаём специальный организм:

Показываем, как изменения работают только внутри одного организма и не влияют на другие:

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

Берём специальный организм, используем его в другом сценарии без изменений — получаем общий организм. Создавать его отдельно или специально не нужно. Например, инпут «Телефон» может использоваться как логин в приложении, тогда он появится сразу в двух сценариях — «Вход» и «Смена логина».

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

Общими организмами могут быть любые элементы: как инпуты, так и целые страницы.

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

Задача:

На ревью старший дизайнер попросил увеличить расстояние между текстом и левым краем инпута: вместо 20px сделать 25px.

Решение:

Нам нужно изменить расстояние, то есть изменить расположение атомов: это про разметку. За неё отвечают молекулы. Идём в неё, выбираем все текстовые слои, вносим правку одним нажатием: потратили 10 секунд и расстояние поменялось во всех инпутах сразу.

Задача:

После UX-теста мы поняли, что серые плейсхолдеры плохо видят более 80% пользователей. И нужно было изменить цвет в определённом состоянии элемента.

Решение:

За состояния отвечают организмы, поэтому зашли в организм «Инпут дефолт» и везде поменяли цвет плейсхолдера на более тёмный.

Задача:

UX-редактор сказал изменить текст инпута Key Word на Password, потому что так привычнее.

Решение:

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

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

Задача:

Старший дизайнер заметил, что отступы между инпутами логина и пароля слишком большие/маленькие и с ними нужно ещё поработать.

Решение:

Меняем расстояния между инпутами в компоненте авторизации — корректировка происходит на всём сценарии.

Мы сделали тренировочный файл в Figma: продублируйте его себе в Drafts, а потом двигайте, проверяйте, изучайте.

#figma