← Назад | Продолжение (Глава 3) →
(Перед вами бесплатный курс от InVision Studio «Дизайн-системы. Погружение». В курсе 7 глав. Если вы здесь впервые, то лучше начните сначала)
Вы читаете перевод руководства “Design Systems Handbook”. Над переводом работали: Валерия Новожилова, Анастасия Свеженцева и Егор Хлебников.
Автор оригинальной главы Jina Ann — опыт развития дизайн-систем в Salesforce (Lightning Design System) и ведения спец-проектов в Amazon.
Запуск дизайн-системы может восприниматься как нечто сложное. Все-таки необходимо учесть много вещей: стиль, как проектировать с учетом принципов модульности и масштабируемости, как другие команды будут работать с дизайн-системой, как продать идею менеджерам и руководителям компании. С чего же все-таки стоит начать дизайнеру, какие первые шаги стоит предпринять?
Крупные задачи всегда легче решить, если их разделять на небольшие кусочки. Прежде чем погрузиться в процесс дизайна, подумайте, кто должен участвовать в создании дизайн-системы, и как участники команды смогут работать сообща. Как только вы собрали нужных людей, вы готовы начать думать о языке дизайн-системы, в который войдут цвет, типографика, принципы работы с пространством и многое другое. Ваш язык визуального дизайна станет ядром вашей дизайн-библиотеки пользовательского интерфейса — спектра компонентов, которые можно применять вместе для сборки интерфейса.
Давайте шаг за шагом рассмотрим, как вы можете приступить к созданию своей дизайн-системы.
1. Собираем команду
Прежде чем начать работу над своей дизайн-системой, подумайте о команде, которая вам понадобится, чтобы воплотить ее в жизнь. Кого нужно задействовать? Осторожно, спойлеры! Вам понадобятся не только дизайнеры.
«У нас есть программа под названием гильдия. По сути, мы берем по одному человеку из каждой гильдии и для нашей системы дизайна мы работаем с ними в как с контрольной группой потенциальных пользователей».
Rachel Cohen — LINKEDIN
Вот краткий список специалистов, которые могут быть представлены в вашей команде для создания эффективной дизайн-системы:
- Дизайнеры помогут определить и проработать визуальные элементы системы
- Front-end разработчики помогут создать модульную и продуманную программную реализацию
- Эксперты по доступности помогут убедиться, что ваша система соответствует таким стандартам, как, например, WCAG
- Контент-стратеги помогут команде вложить уникальный голос и тон в дизайн-систему
- Исследователи помогут вам понять потребности клиентов
- Эксперты по оптимизации обеспечат быструю загрузку вашей системы на всех устройствах
- Продакт-менеджеры помогут добиться соответствия дизайн-системы потребностям клиентов
- Лидеры (вице-президенты и директора) помогут продвигать и согласовывать видение всей компании, включая исполнительное руководство
После того, как вы собрали и сплотили специалистов в команду дизайн-системы, определите сильнейших в каждой области. Каждому из них предстоит продвигать решения и бороться за результат. Вы должны четко знать, кто в команде может непрерывно развивать каждую из областей в дизайн-системе.
Ваша следующая задача с командой экспертов и сильным руководством — выстроить подходящую модель команды, которая поможет в достижении бизнес-целей.
2. Выбираем правильную модель команды
Модель команды призвана объединить людей и организовать работу. Она так же важна, как и команда по созданию дизайн-системы. В статье «Team Models for Scaling a Design System» первопроходец в дизайн-системах Натан Кертис описывает три популярные командные модели, которые чаще других применяются в компаниях.
Модель «Герой»: системой дизайна управляет одна голова.
Централизованная модель: выделяется специальная команда, задача которой заниматься развитием дизайн-системы — это их основная работа.
Федеративная модель: несколько ключевых игроков из различных команд в компании сообща начинают развивать дизайн-систему.
У каждой из вышеперечисленных моделей есть свои сильные и слабые стороны.
Модель «герой-одиночка» самая быстрая для старта и с минимум связей. В ней все решает один человек, он один отвечает за большой объем работы. Но модель «герой-одиночка» может работать медленее, чем хотелось бы на целой серии задач.
Когда централизованная команда поддерживает систему в хорошем состоянии, ее участники могут быть не так плотно связаны с потребностями клиентов,так как они менее вовлечены в исследования пользователей.
А вот федеративная команда прекрасно понимает, что именно необходимо для раскрытия потенциала продукта с учетом потребностей пользователей, но может сильно застрять в существующих модулях.
Многие команды переходят от одиночной модели к централизованной или федеративной, потому что, как упоминает Натан в своей статье, «герои-одиночки» масштабируются с огромным трудом. Централизованные или федеративные модели обычно намного лучше подходят для масштабирования дизайн-системы.
Вот тут в статье подробно разобрали модель команды Salesforce в ответ на статью Натана. Когда я работала в Salesforce в команде Lightning Design System, мы использовали комбинацию централизованной и федеративной моделей. В такой большой корпоративной организации, как Salesforce, одной централизованной команды дизайн-систем было недостаточно. С таким количеством задействованных ключевых игроков и большим количеством полезных свойств системы, которые нам нужно было охватить по продуктам и платформам, нам нужен был особый подход, который был бы устойчивым.
Хотя у Lightning Design System есть основная команда, у нее также есть и ключевые участники из других областей продукта и фич экосистемы Salesforce, которые действуют как федерация экспертов, которые выявляют новые идеи и ставят задачи на развитие дизайн-системы. Исследователи, специалисты по доступности, ведущие продуктовые дизайнеры, разработчики прототипов и UX инженеры работают с центральной командой дизайн-системы, чтобы применять в работе дизайн-систему, и одновременно помогать с созданием и развитием шаблонов, компонентов и дизайн-системы в целом. Инженеры добиваются чистого кода и помогают поддерживать систему в рабочем состоянии.
Хотя одиночная модель менее популярна в большинстве команд, так как основной участник может стать узким местом, но бывают ситуации, когда она может сработать достаточно хорошо. В разгар политической кампании, которая развивалась с головокружительной скоростью, у Мины Маркхэм было мало времени, чтобы привлечь подкрепление, поскольку она разрабатывала новые онлайн-ресурсы для Хиллари Клинтон. Она создала дизайн-систему под названием «Pantsuit» (Брючный костюм), чтобы помочь другим командам из разных мест ускорить проектирование и производство, сохранив единообразие бренда компании. Модель-одиночка позволила Мине сосредоточиться в первую очередь на скорости, а во вторую — на долговечности, что отличается от обычного предприятия.
Когда вы определяете, какая модель команды вам больше подходит, подумайте о своих целях. Если вы хотите действовать быстро, модель одиночка идеально подходит на начальном этапе, хотя, возможно, потом потребуется проделать некоторую работу, чтобы полностью внедрить систему в других командах. Если вы хотите действовать быстро, но с самого начала поощрять участие, рассмотрите модель централизованной команды. Федеративная модель - хороший вариант для получения наибольшего участия участников и совместной ответственности. В любом случае помните, что дизайн-система - это продукт, поэтому укомплектуйте ее, как продукт, а не проект; вы хотите, чтобы люди его поддерживали и совершенствовали.
Когда команда и модель, которая ее организует, сформированы, пора запустить вашу дизайн-систему так же, как и любой новый продукт: поговорив со своими клиентами.
3. Проводим интервью с клиентами
Исследование пользователей — это уже обыденность в любом процессе, связанном с разработкой цифрового продукта. На этом этапе предстоит разобраться с тем, кто будет использовать вашу дизайн-систему, и как именно будут ее использовать? Ваша дизайн-система начнет применяться гораздо чаще, если вы создадите ее так, чтобы она вписывалась в рабочий процесс других команд.
Профессиональный лайфхак
Создание крепких и полезных гайдов по стилю на основе данных
Исаак Хейс и Донна Чан выступили с интересным докладом под названием «Создание крепких и полезных гайдов по стилю на основе данных» (англ. “Building Empowering Style Guides with Practical Research”) на конференции Clarity. В докладе предлагается ряд полезных методов, которые помогут вам эффективно проводить исследования для вашей дизайн-системы. Ребята превращают интервью в данные и разрабатывают принципы дизайна, метрики и пользовательские истории.
С помощью интервью с пользователями вы можете выявлять барьеры, добывать принципы, которые помогут другим правильно использовать систему, и сосредоточить свою энергию на самых важных моментах.
Еще иногда интервью проводят с участниками вашего open source сообщества. Такой подход работает в организациях, которые предоставляют инструменты для разработчиков клиентам и организациям-партнерам. Если вы планируете сделать открытым исходный код своей дизайн-системы, — к примеру у вас есть гипотеза о чем-то более крупном и полезном — в этом случае вам потребуется поговорить с потенциальными пользователями системы, чтобы выяснить, какие кейсы ваша дизайн-система должна покрывать.
А еще есть руководители и менеджеры. Очень важно вникнуть в их идеи. Вам же пригодятся их финансы для поддержки и развития системы. Прислушивайтесь к их барьерам и используйте их для целеполагания и постановки метрик развития.
Примерами запросов руководителей могут быть запросы про ускорение разработки новой функциональности, повышение производительности и улучшение качества пользовательского интерфейса.
Как только у вас будут интервью с клиентами вы сможете взяться за структурирование и сгруппировать все по полочкам. Необходимо создать два типа списков:
- Перечень визуальных атрибутов (таких как отступы, цвет и типографика), который поможет нам создать визуальный язык;
- Список с перечислением каждого элемента пользовательского интерфейса (кнопки, карточки, модальные окна), который поможет нам создать библиотеку компонентов пользовательского интерфейса.
Давайте сначала сосредоточимся на глобальном визуальном. Мы перейдем к раскладыванию по полочкам UI элементов позже.
4. Делаем аудит визуального языка экосистемы
Конечно, если вы запускаете дизайн-систему для продукта, которого еще не существует, вы можете пропустить этот шаг и сразу перейти к созданию визуального языка для своего нового продукта. Считайте, вам очень повезло!
Визуальный аудит
На старте мы рекомендуем взглянуть сначала на CSS, которые применяется для создания всех UI-элементов. Здесь поможет инструмент CSS Stats — он покажет, сколько правил, селекторов, объявлений и свойств есть в ваших таблицах стилей.
А еще он покажет, сколько сейчас уникальных цветов, размеров и семейств шрифтов на живой системе. Он также показывает гистограмму для количества значений расстояний и размеров. Это отличный способ увидеть, где можно объединить или удалить значения.
Если вы создаете набор элементов в Sketch, используйте плагин SketchStyle-Inventory, чтобы быстро объединить все цвета, стили текста и символы. Это также дает вам возможность объединять похожие стили в один.
5. Создаем визуальный язык дизайн-системы
Должна признать, как выпускница художественной школы, визуальный язык в дизайн-системе — моя любимая часть работы. Мне нравится думать о теории цвета, типографике и организации пространства — визуальных моментах любой дизайн-системы. Если мы разделим каждый компонент дизайн-системы, мы обнаружим следующие фундаментальные элементы, составляющие ее визуальный язык дизайна:
- Цвета
- Типографика (размер, интерлиньяж, шрифты и т. д.)
- Интервалы (margins, paddings, positioning coordinates, border spacing)
- Изображения (иконки/знаки, иллюстрации)
Более продвинутый уровень стандартизации также включают следующие элементы:
- Визуальная форма (глубина, высота, тени, закругленные углы, текстура)
- Движение
- Звук
Рассмотрим роль каждого элемента дизайна, которую он играет в таком простом компоненте, как кнопка. Кнопка обычно имеет заливку (background color), шрифт, надпись и внутренние отступы. Рядом с названием кнопки может быть иконка для обозначения визуальной подсказки. Граница по краю служит простым орнаментом и может даже закруглять углы. Наконец, при наведении указателя мыши на кнопку или нажатии на нее может запускаться анимация или звук для обратной связи. Хоть кнопка и может показаться простой, но для ее воплощения требуется целая серия дизайнерских решений.
Маркеры дизайна (токены дизайна)
Прежде чем мы углубимся в стандарты визуального дизайна, я хочу обсудить токены дизайна. Токены являются «субатомной» основой реализации дизайн-системы. В простейшем случае это пары имени и значения, хранящиеся в виде данных для абстрагирования свойств проекта, которыми вы хотите управлять.
Значения для всех маркеров дизайна хранятся в одном месте, что упрощает достижение согласованности при одновременном снижении нагрузки на управление дизайн-системой.
Пример: SPACING_MEDIUM: 1rem.
В дизайн-токенах вы можете хранить цвета, расстояния, размеры, продолжительность анимации и т. д., и распространять их на различные платформы.
Более подробно мы рассмотрим маркеры дизайна в главе 3.
Цвет
Цвета, которые вы выбираете для своей дизайн-системы — это больше, чем просто продолжение вашего бренда. Пользовательский интерфейс использует цвет, чтобы передать следующие моменты:
- Обратная связь на действие пользователя: состояния ошибки и успеха.
- Информация: диаграммы, графики и элементы навигации.
- Иерархия: отображение в структурированном виде с помощью цвета и типографики.
Цвета в дизайн-системе включают 1-3 основных цвета, которые представляют ваш бренд. Если ни один из них не подходит для цвета ссылки и кнопки, то вы можете также ввести дополнительный цвет. Рекомендуется использовать один и тот же цвет для ссылок и кнопок, так как это облегчит пользователям распознавание интерактивных элементов.
Скорее всего, у вас будут нейтральные цвета для общего фона и границ пользовательского интерфейса - обычно серые. И, наконец, у вас будут цвета для таких состояний, как ошибка, предупреждение и успех. Сгруппируйте эти цвета, чтобы увидеть, насколько хорошо они работают вместе, и при необходимости доработайте их.
Профессиональный лайфхак
В книге «Программирование дизайн-систем» («Programming Design Systems» ) Руне Мэдсена есть несколько замечательных глав по цвету, доступных для чтения в Интернете, в том числе «Краткая история теории цвета».
Существует множество средств проверки цветового контраста, которые вы можете использовать, чтобы убедиться, что ваша цветовая палитра подходит всем, кто будет использовать ваши продукты. Обязательно проверьте коэффициенты контрастности для сочетания цветов фона и текста.
В крупных дизайн-системах еще включают цвета для объектов и продуктов. Например, в Salesforce у нас был цвет для контактов, торговых сделок, групп и т. д. У нас также были определенные цвета и для самих продуктов: Sales Cloud, Marketing Cloud, Analytics Cloud и т. д. Цвет может быть полезным инструментом навигации для ваших пользователей.
Использование цвета для поиска пути может быть сложной задачей, особенно когда нужно обеспечить принцип доступности интерфейса, так как люди с дальтонизмом могут не заметить некоторые различия.
Вы также можете добавить ряд оттенков — цвет, смешанный с белым, и теней — цвет, смешанный с черным. Вы также можете использовать другие цвета вместо белого или черного, чтобы избежать запутанности, например, оранжевый, чтобы затемнить желтый, чтобы он не казался коричневым.
Такие цветовые вариации дают широкий выбор. Но будьте осторожны, слишком много вариантов может привести к серьезным несоответствиям в дизайне. Используйте легкие оттенки, тени и нейтральные палитры, чтобы предотвратить неправильное использование системы, такой подход дает дизайнерам необходимую гибкость. Вы всегда можете добавить больше цветов, если потребуется.
Типографика
Шрифты и начертания
Выбранные вами шрифты имеют большое влияние как на ваш бренд, так и на пользовательский опыт. Помните об удобочитаемости при выборе шрифтов, подходящих для вашей системы. Использование общих системных шрифтов, таких как Helvetica, Times New Roman или Verdana, может быть отличным быстрым выбором, поскольку они знакомы пользователю. Некоторые компании предпочитают настраиваемые веб-шрифты, чтобы лучше отражать их бренд, но уделяйте особое внимание тому, как вы их используете, поскольку это может повлиять на производительность.
Большинство дизайн-систем, над которыми я работала, включают всего два шрифта: один шрифт для заголовков и основного текста и моноширинный шрифт для кода. Иногда для заголовков используется дополнительный шрифт, дополняющий основной шрифт. Большинству дизайн-системам больше и не нужно, если у вас, конечно, не система, поддерживающая несколько брендов. Лучше всего поддерживать небольшое число шрифтов, поскольку это не только лучший способ типографского дизайна, но и предотвращает проблемы с производительностью.
«Межстрочный интервал (интерлиньяж) составляет не менее полутора пробелов внутри абзацев, а интервал между абзацами как минимум в 1,5 раза больше, чем межстрочный интервал».
Веб-контент, указания по доступности (WCAG) 2.0 W3C
В наши дни модно использовать очень тонкий шрифт, но имейте в виду, что могут возникнуть проблемы с читабельностью. Если вы хотите использовать легкие или тонкие начертания, используйте их только для текста большего размера.
Масштабирование
При выборе размера шрифта учитывайте удобочитаемость шрифта, который вы выбрали. В большинстве случаев подходит размер 16 пикселей. Это размер шрифта по умолчанию в большинстве браузеров, и большинству людей он легко читается. Мне нравится использовать 16 пикселей, поскольку это отлично работает с метриками, используемыми Apple и Google (и набирает популярность как стандартный подход). Я рекомендую это в качестве основы, хотя я бы использовала его в относительном формате, например, 1rem для систем на основе CSS.
Вы можете использовать модульную шкалу для большего или меньшего размера шрифта для таких элементов, как заголовки. Модульная шкала - это набор чисел, в котором у вас есть 1 базовое число и коэффициент для генерации следующего числа. Вы продолжаете применять соотношение к новому числу, чтобы получить еще одно число.
Профессиональный лайфхак — Понимание модульной шкалы
Узнайте больше о модульной шкале, чтобы создавать более выразительную типографику.
При выборе шрифта обязательно подумайте о том, как он будет работать на различных размерах экрана, так как необходимо сохранить читаемость. Вы же не хотите, чтобы заголовки были слишком большими для мобильных устройств. Для дисплеев гораздо большего размера у вас есть возможность увеличить размеры.
Распространенный подход — увеличить заголовки на больших окнах просмотра.
Вы также можете использовать относительные единицы для масштабирования шрифта, основываясь на проценте от размера вашего экрана.
Интерлиньяж
Интерлиньяж, или высота строки в CSS, может улучшить читаемость и эстетику вашей типографики. Хотя оптимальная высота строки может варьироваться в зависимости от начертания шрифта и длины строки, общее практическое правило заключается в том, чтобы интерлиньяж был примерно в 1,4–1,5 раза больше размера шрифта. W3C Web Accessibility Initiative рекомендует 1.5.
Такой подход сделает ваши расчеты предсказуемыми, вам не нужно все это вычислять. Вы можете определить высоту строки без единицы измерения, и браузер сделает за вас всю сложную математику.
Для заголовков подтяните его в зависимости от вашего шрифта. В большинстве случаев я считаю, что соотношение 1,25 или 1,125 работает достаточно хорошо.
Расстояние и размер
Система, которую вы используете для определения интервалов и размеров, будет наиболее полезна, когда у вас задан ритм и баланс. Это означает использование значений, основанных на шаблонах и пропорциях. Использование согласованной шкалы расстояний также способствует удобству поддержки за счет известных соотношений. Это делает макеты более предсказуемыми, и они с большей вероятностью «вписываются» и хорошо выравниваются.
Создавая приложение для Android, я изучала рекомендации Google по дизайну и заметила образец использования 8dp между элементами и 16dp для внешних отступов. Это побудило меня отказаться от привычной десятичной шкалы, так как я обнаружила, что шкала на основе 4dp работает намного лучше.
Шкала, основанная на 4dp, как рекомендуемая шкала, пользуется все большей популярностью по многим причинам. И iOS, и Android платформы используют и рекомендуют метрики, которые кратны 4. Стандартные форматы размеров для значков ICO, которые используются в большинстве операционных систем, обычно основаны на 4 (16, 24, 32 и т. д.), чтобы они легче масштабировались. Размер шрифта по умолчанию в браузере обычно составляет 16. Когда все использует эту систему, все элементы интерфейса с большей вероятностью разместятся на своих местах и выстроятся в линию. И наконец, хорошо срабатывает адаптивная математика.
Для горизонтального расстояния достаточно хорошо работает шкала, основанная на 8 единицах. Вы можете сделать поля и отступы, равными или пропорциональными размеру шрифта. Но для вертикального ритма я обычно использую шкалу, основанную на 12 единицах. Это связано с тем, что высота строки, которую я получаю при умножении 16 на 1,5 (16 пикселей - размер шрифта по умолчанию), дает нам 24.
Иногда вам, возможно, придется нарушать это правило. Если вы добавили к чему-либо границу размером 1 пиксель, эта граница может нарушить выравнивание. Поэтому вы можете использовать отступы или поля, которые вычитают эту сумму. Это то, что вы делаете в индивидуальном порядке.
Возможно, вы хотите, чтобы элементы увеличивались и уменьшались вместе с содержимым. Для общего размера избегайте установки ширины и высоты, если это не является абсолютно необходимым. Вы можете значительно упростить создание адаптивного дизайна, если позволите элементам плавно заполнять пространство, отведенное в макете.
Изображения
Разрешения файлов
Я считаю, что для значков и иллюстраций лучше всего подходит векторный формат (SVG), обеспечивающий масштабируемость и адаптивный дизайн. Однако, если вам нужно использовать фотографию, вам может потребоваться формат растрового изображения, такой как JPG или PNG.
Для большинства фотографий, иллюстраций и диаграмм вы можете разрешить изображению на 100% вписываться в контейнер или область просмотра и позволить высоте автоматически устанавливать себя, не определяя ее самому. Это лучше всего работает для отзывчивых макетов. Вы также можете определить некоторую предустановленную ширину для изображений, если вы не хотите, чтобы они отображались в полном размере (например, половинную ширину, треть или четверть). Я рекомендую устанавливать их как максимальную ширину (max-widths), чтобы изображение можно было масштабировать для меньших экранов.
Иконографика
Прежде чем начинать рисовать значки, сначала составьте для них рекомендации. Будут ли они заполнены или очерчены? Какой вес лении? Будут ли они использовать более одного цвета? Каких размеров они будут? Установлена ли граница изображения иконки внутри внешней границы?
У вас могут быть разные стили для разных типов значков. Например, значки утилит и действий (такие как колокольчик для уведомлений или значок шестеренки для настроек) могут быть сплошными и одноцветными, а значки навигации могут быть многоцветными и более креативными. Четкие инструкции сохранят единообразие ваших значков.
Иллюстрации
Иллюстрации — отличный способ добавить характер вашему продукту. Вы можете использовать их для пустых состояний, экранов загрузки, модальных окон и других компонентов, вызывающих визуальный интерес. Shopify пошел на многое, чтобы создать уникальные иллюстрации для всех возможных пустых состояний своей платформы, и они мощно передают индивидуальность бренда.
Как и в случае с иконками, полезно иметь рекомендации по стилю ваших иллюстраций.
Визуальная форма
Визуальная форма или качество материала вашего пользовательского интерфейса - это фоновые изображения, градиенты и текстуры, тени и высота (z-индексы), закругленные углы и границы. Это визуальные качества, которые помогают подчеркнуть и украсить элементы, чтобы добавить визуальную иерархию и эстетику. В любом случае, все это примеры украшений, которые необходимо стандартизировать.
Google отлично показывает, как работают глубина и высота с наслоением компонентов.
Движение и звук
Когда вы определяете свой визуальный язык, движение и звук могут не сразу прийти в голову. Вы переживаете это по-другому. Но движение и звук могут сильно повлиять на работу вашего приложения. Вы также захотите, чтобы это было систематизировано для единообразия. Лично я не исследовала эти области подробно, но есть несколько отличных примеров из дикой природы.
6. Организуем библиотеку компонентов (UI-кит)
Мы провели визуальный аудит и изучили визуальные свойства элементов, такие как цвет, размер и типографика. Теперь мы проведем аудит пользовательского интерфейса, в которой мы рассмотрим его основные элементы - кнопки, карточки, списки, формы и т. д. Если визуальный язык — это визуальный подход и то, как все выглядит на глобальном визуальном уровне, то библиотека пользовательского интерфейса (также известная как библиотека шаблонов) смотрит на фактические компоненты пользовательского интерфейса.
Давайте посмотрим на каждый из этих элементов дизайна и на ту роль, которую они будут играть в вашей дизайн-системе. Проведите инвентаризацию всех элементов интерфейса приложения в продакшене, чтобы увидеть, сколько дизайнерских долгов вам нужно решить, и какие элементы используются чаще всего. Предупреждаю! Это может вызвать уныние, так как у большинства компаний очень непоследовательные пользовательские интерфейсы.
Чтобы создать инвентарь интерфейса, просто откройте все продукты, находящиеся в продакшене в вашей организации, сделайте скриншоты всех кнопок, форм, различных стилей шрифтов, изображений и соберите их в виде набора слайдов или на больших плакатах, которые может видеть вся команда.
Вы можете сделать это с помощью вырезанных распечаток или скриншотов.
Соберите людей, которых вы привлекаете к созданию дизайн-системы (как упоминалось ранее в этой главе). Попросите их провести этот аудит вместе с вами, либо через митинг, или через практическое занятие. Идея состоит в том, чтобы собрать различные компоненты, которые вы используете, распределить их по категориям и объединить.
Некоторым нравится делить объекты на элементы, компоненты, области, утилиты и так далее. Атомарный дизайн — отличный пример такого мышления и отличная концептуальная модель. Но когда дело доходит до этого, каждый элемент в значительной степени является компонентом, поэтому в конце концов вы можете обозначить все как таковое. Но в целом я вижу, что большинство систем дизайна разбивают объекты на следующие категории:
- элементы (или основы, или атомы) — это небольшие автономные компоненты, такие как кнопки и значки
- компоненты (или молекулы, или модули) — обычно они представляют собой набор небольших компонентов в более крупный компонент, такой как форма поиска (которая включает поле ввода, кнопку и, возможно, даже значок поиска)
- области взаимодействия (или зоны, или организмы) — это такие области пользовательского интерфейса, как левая панель навигации.
- лейаут — расположение элементов на странице (например, заголовок, боковая панель и область основного содержимого и затем футер)
После завершения аудита вы можете объединить и удалить то, что вам не нужно (либо в электронной таблице, либо сразу в коде в процессе рефакторинга, если вы хотите внести немедленные изменения). Также задокументируйте, что это за компонент и когда его использовать. Итоговый вариант и станет вашей библиотекой пользовательского интерфейса (или библиотекой шаблонов, или библиотекой компонентов, в зависимости от того, как ваша организация решит называть ее).
Большая часть документации по дизайн-системе включает название компонента, описание, пример и код. Другие могут показывать метаданные, истории релизов, примеры и многое другое. Самое главное, чтобы вы показали то, что необходимо вашей команде для выполнения работы.
Вывод и рекомендация
Создание дизайн-системы не только помогает команде обеспечить согласованный пользовательский опыт, но и объединяет команды дизайна и разработки вокруг одной цели. Если вы выбираете путь значительно улучшить взаимодействие между дизайнером и разработчиком, то вам просто необходимо создать общий визуальный язык, прошитый едиными токенами дизайна, а также сделать набор компонентов и шаблонов, аккуратно разложенных в библиотеке пользовательского интерфейса. А еще бонусом вы получите контроль над пользовательским интерфейсом, повысите управляемость, масштабируемость и надежность.
← Назад | Продолжение (Глава 3) →