10 вещей, которые мне никто не рассказывал о дизайн-системах
Мое знакомство с дизайн-системами было больше похоже на засасывание меня в черную дыру.
Тогда я работала продакт-дизайнером в компании, занимающейся разработкой программного обеспечения для грузоперевозок. Мы росли экспоненциально, поэтому наша UI-библиотека нуждалась в критических улучшениях, чтобы не отставать от потребностей бизнеса. Во время проведения аудита с целью определить, что нужно оптимизировать, я узнала, что Figma выпустила функцию автолейаута. Я применил ее к нашей библиотеке, но задача только усложнилась. Я не остановилась на ревизии, мне пришлось создать целую дизайн-систему.
В том проекте я выполняла несколько обязанностей: создавала компоненты и документацию, проводила исследования и обучала своих коллег-дизайнеров тому, как использовать и вносить свой вклад в нашу новую дизайн-систему.
Та первая дизайн-система, которую я создала, была рождена необходимостью решить проблему отсутствия согласованности между дизайном и разработкой. После такого интенсивного погружения в мир дизайн-систем, а также благодаря опыту работы в других компаниях, я узнала довольно много вещей, о которых мне хотелось бы, чтобы кто-нибудь рассказал мне в самом начале. Сегодня я поделюсь ими с вами.
1. Дизайн-система — это не то же самое, что UI-библиотека
Когда Figma выпустила свой автолейаут, она изменила способ создания компонентов дизайнерами. Я провела аудит, чтобы определить, какие элементы можно перестроить с помощью этой новой функции. И, представьте себе, обнаружила большое количество несоответствий компонентов между проектами и продуктом, находящимся в производстве.
Разработчики и дизайнеры имели доступ ко всем компонентам, но не имели никаких указаний о том, когда и как их использовать. Я не ожидала, что первоначальная задача по обновлению некоторых компонентов превратится в большой проект, но это произошло.
В итоге я не только применила автолейаут к некоторым компонентам, но также должна была создать документацию, чтобы наконец добиться согласованности. Так библиотека пользовательского интерфейса стала дизайн-системой. Благодаря этой истории я узнала, что UI-библиотека представляет собой набор компонентов и стилей, а вот дизайн-система — это набор руководств по управлению набором компонентов и стилей.
2. Сделайте свою дизайн-систему продуктом, и ваши пользователи будут вам благодарны!
Любой продукт, над которым вы работаете, должен решать проблемы пользователей и удовлетворять конкретные потребности бизнеса. А один из первых шагов к созданию эффективного продукта — определение пользователей, их рабочих процессов и их болевых точек. Та же логика применима и к дизайн-системе.
Вы разрабатываете дизайн для двух групп пользователей, когда создаете дизайн-систему. Во-первых, вы строите ее для конечных пользователей, которые станут покупателями продукта вашей компании. Но вы также проектируете ее и для дизайнеров, которые создают эти услуги и полагаются на дизайн-систему.
Когда вы относитесь к своей дизайн-системе как к продукту, дизайнеры продукта, которые ее внедряют, могут сосредоточиться на том, как создать плавную UX-навигацию для конечного пользователя, вместо того, чтобы тратить время на выбор подходящего цвета для кнопки. В то же время разработчики могут легко взять готовый компонент и применить его.
Основная цель дизайн-системы — оптимизировать рабочий процесс пользователей и сэкономить время. По сути, дизайн-система — это продукт для создания продуктов.
3. Дизайнеры и разработчики должны быть как атом: неразделимы
Подобно дизайнерам, разработчики могут ускорить свои рабочие процессы при создании продуктов с помощью готовых компонентов из дизайн-систем. Настоящая проблема заключается в поддержании согласованности между этими двумя бригадами.
Конечные пользователи не взаимодействуют с инструментами дизайна (такими как Figma, Zeplin, Invision или Sketch), но они взаимодействуют с продуктом в процессе производства. Они могут сказать, когда за кулисами есть несоответствие, особенно если ему виной дизайн-система. Функциональная согласованность также имеет значение. Конечные пользователи хотят иметь возможность предсказать, как поведут себя компоненты. Если компоненты ведут себя не так, как ожидалось, пользователи будут сбиты с толку, а их доверие может пошатнуться.
Разработчики и дизайнеры должны работать вместе на всех этапах создания дизайн-системы, чтобы поддерживать согласованность. Я на своем опыте познала, что сотрудничество — единственный секрет успешной дизайн-системы.
4. Причудливые соглашения об именах не всегда практичны
Когда я впервые создала дизайн-систему, я очень гордилась своей выдающейся цветовой палитрой. Я разработала самые крутые названия цветовых стилей: деним, шамбре, малахит и киноварь. Я думала, они будут достаточно гибкими, но затем нашему продукту для управления автопарком понадобился темный режим. Первой проблемой, с которой мы столкнулись, было отсутствие стандартизации использования каждого цвета во всех компонентах. Дизайнеры и разработчики не знали, когда какой цвет использовать. Некоторые границы были серыми, а некоторые синими.
Мы решили эту проблему, назвав цветовые токены на основе контекстно-независимого использования. Это упростило введение тем в систему дизайна.
Существует несколько способов токенизации значений цвета. Каждая компания использует свою структуру. Asana использует [sentiment-sage-prominence-interaction], а Material Design применяет логику [design-system-type-purpose]. Я рекомендую исследовать и применить наиболее подходящие семантические или глобальные имена. Те, что смогут масштабироваться в соответствии с текущими и будущими потребностями вашей дизайн-системы.
5. Атомарный дизайн и магия основ
Прежде чем приступить к первой версии нашей дизайн-системы, я изучила лучшие практики для создания основы. Так я нашла исключительный метод создания модульных систем под названием Atomic Design, придуманный Брэдом Фростом.
Согласно ему компоненты могут быть разбиты на более мелкие независимые компоненты, которые можно отредактировать или заменить на другие без нарушения структуры компонента. Этот метод позволяет быстрее собирать проекты и автоматически обновлять компоненты. Он изменил правила игры! Рекомендую применять его к любой дизайн-системе.
6. Ваша кросс-функциональность совершенствует дизайн-систему
Команда дизайн-системы не должна быть изолирована от своих основных пользователей, а взаимодействие между дизайн-системой и продуктовыми командами, которые ее используют, вещь не односторонняя. Дизайн-системы должны совершенствоваться по мере развития продуктов. Но отчеты и запросы от нескольких команд могут стать чрезмерными, если компания растет в геометрической прогрессии.
Открытие дизайн-системы для кросс-функциональных участников и предоставление им возможности обслуживать свои собственные запросы — лучшая стратегия для удовлетворения потребностей бизнеса.
Одной из основных проблем могут быть критические изменения. Рекомендую предоставить участникам рекомендации и материалы, чтобы они чувствовали себя комфортно и уверенно в процессе. Кросс-функциональное сотрудничество открывает новые перспективы развития дизайн-системы и достижения бизнес-целей.
7. Долговечная дизайн-система требует сотрудничества, выходящего за рамки продукта и разработки
Подводя итоги, можно сказать, что крупные компании рассматривают дизайн-системы как основу своего бренда и видения продукта. Гайдлайны касаются не только программных продуктов, но и определяют целостное взаимодействие с брендом. Поэтому так важно, чтобы команда дизайн-системы реагировала на постоянную обратную связь от заинтересованных сторон и основных пользователей.
«Сотрудничество» между продуктовыми командами, маркетингом, брендингом, клиентским опытом, менеджерами и командой дизайн-системы способствует развитию вашей дизайн-системы. Кроме того, всегда легче принимать что-то, когда вы являетесь частью этого и лучше с этим знакомы. Составление списка заинтересованных сторон и определение того, как дизайн-система будет оптимизировать их рабочие процессы, — лучшая стратегия для последовательного взаимодействия с клиентами.
8. Принятие дизайн-системы командой — самая сложная часть
У меня есть несколько соображений по поводу этапа принятия. Во-первых, создание учебных материалов для вовлеченных команд — отличная стратегия. Это могут быть видеоролики, семинары, курсы или любой другой способ подачи информации, о котором вы только можете подумать.
Процесс распространения зависит от вашей компании и ее возможностей. Конечная же цель состоит в том, чтобы повысить осведомленность о преимуществах использования дизайн-системы. Если ваши заинтересованные лица не поймут, как внедрить дизайн-систему в свои рабочие процессы, они не будут ее использовать. А это может нарушить единообразие взаимодействия для конечных пользователей.
Если ваши заинтересованные стороны примут дизайн-систему, но не поймут, как постоянно применять ее обновления, они найдут способ заставить ее работать на них — даже если это означает отсоединение компонентов или работу не по руководствам.
9. Доступность обязательна
Доступ к коммуникационным технологиям и равные возможности — это права человека, а доступность — это инклюзивная практика, которую каждая команда должна применять при создании любой дизайн-системы.
Да, это добавляет больше шагов в процесс создания, но повышает ценность продукта для бизнеса и удовлетворяет потребности большего числа клиентов. Компании, которые включают доступность веб-контента в свои гайдлайны, улучшают доступность для всех пользователей, повышают согласованность и оптимизируют взаимодействие с пользователем.
Я узнала на своем примере, что вам не нужно быть экспертом в этой области. Однако осознание инклюзивности сделает вас более этичным профессионалом и более чутким человеком.
10. Бесконечность дизайн-системы
Как и любой продукт, дизайн-система проходит интенсивный рекурсивный процесс после первого запуска. Дизайнеры будут сообщать об ошибках и новых запросах и нуждаются в постоянной поддержке со стороны команды, отвечающей за дизайн-систему.
По мере развития компании приоритеты продуктовой команды тоже будут меняться, поэтому они будут полагаться на дизайн-систему, чтобы своевременно реагировать на новые запросы. Наряду с созданием учебных материалов вам стоит отслеживать работу и улучшения, чтобы понимать, кто что сделал и когда. Чтобы избежать риска регрессии, рекомендую обновлять запросы об ошибках и добавлять новые функции, используя отдельные выпуски, чтобы при необходимости можно было восстановить библиотеку. И не забывайте, что расширение возможностей ваших сотрудников с помощью знаний является ключом к долгосрочным улучшениям.
За время моего опыта работы с дизайн-системами мне пришлось переработать и отказаться от многих задач. Чтобы не тратить время впустую, подумайте заранее о том, как создать модульное, масштабируемое и гибкое решение, которое облегчит будущие усовершенствования. Задача по созданию дизайн-системы может звучать как набор шагов в линейном процессе, которому вы просто следуете, но на самом деле это циклический процесс. Он включает в себя бесконечные релизы, периодическое обслуживание и кросс-функциональность. Будьте готовы к этому и не бойтесь приобретать собственный опыт.
