10 принципов хорошей дизайн-системы. Глава 3
Концентрат от создателей дизайн-систем для компаний Atlassian, Salesforce, LinkedIn, Shopify, Amazon, Etsy и GitHub. Доходчиво и наглядно.
Современные дизайн-системы — это еще и результат многолетней эволюции способов написания front-end части. Когда я начинала свою карьеру, большинство сайтов были разработаны с помощью одноразового, неэффективного, хрупкого и несовместимого кода. Благодаря накопленному опыту и многолетнему сотрудничеству фронтенд-разработчиков и дизайнеров появились практичные методы написания и организации кода. Сейчас наблюдается бурный рост фронтенд-фреймворков и инструментов, которые помогают создавать код на HTML, CSS и JavaScript в разы чище и удобнее в поддержке/развитии.
На мой взгляд, это потрясающий шаг в развитии подходов к фронтенд-разработке. Беглый взгляд на оглавление раздела об инструментах в "Cody Lindley’s Front End Developer Handbook 2017’s section on tools" показывает ошеломляющее множество идей и вариантов по подходам к организации дизайн-систем на программном уровне.
В этом руководстве я даже не пытаюсь охватить все доступные варианты технологий, а проведу сразу сквозь главное, что работает в большинстве случаев.
Интересуетесь свежими статьями по продуктовому дизайну (UX/UI)? 🚀
Подписывайтесь на канал в Telegram | ВКонтакте, Instagram, Facebook
Мой опыт — это разработка, поддержка и развитие 3-х дизайн-систем. Во-первых, я расскажу об основополагающих принципах, не зависящих от технологий, которыми должна руководствоваться команда разработки дизайн-системы. Затем остановлюсь на некоторых распространенных ошибках и уберегу от попадания в классическую ошибку. А еще я познакомлю вас с полезными инструментами, которые помогут вам на пути, а пока запомните следующее: ваш технический подход не так важен, как создание живой, дышащей системы — гибкой, поддерживаемой, стабильной, масштабируемой и успешной в долгосрочной перспективе.
Принципы
Добротно сделанная дизайн система собрана по следующим принципам (и они не привязаны к конкретным технологиям):
Целостность и последовательность. Способ реализации компонентов следует четкому и предсказуемому шаблону;
Автономность. Ваша дизайн-система рассматривается как отдельная зависимость в проекте (dependency);
Повторное использование. Компоненты можно подключить и использовать в разных контекстах;
Доступность. Приложениями, созданными с использованием вашей дизайн-системы, могут пользоваться настолько много людей, насколько возможно, независимо от того, как и в каких условиях они получают доступ в интернет;
Надежность. Независимо от продукта или платформы, к которой применяется ваша дизайн-система, она должна работать с минимальным количеством ошибок;
Давайте рассмотрим каждый из этих принципов более подробно.
Принцип 1. Целостность и последовательность
Задайте правила в вашей дизайн-системе, задокументируйте их и периодически поглядывайте, что все им следуют. Если у вас есть четко задокументированные стандарты написания кода и лучшие практики (best practices), дизайнеры и разработчики смогут легко использовать вашу дизайн-систему и, что более важно, вносить в нее свой вклад.
Профессиональный лайфхак — Анкета с гайдлайнами для фронтенда
Не знаете, как подобрать технологии? Брэд Фрост создал удобную анкету “Frontend Guidelines Questionnaire”. Помогает!
Кодстайл (Code style guides)
Кодстайл представляет собой грамматические правила синтаксиса и семантики для вашего кода. Синтаксис кода — это набор правил для структурирования и форматирования вашего кода (например, фигурные скобки всегда переходят на новую строку). Семантика кода обеспечивает правила для понимания вашего кода (например, расположение объявлений свойств CSS в алфавитном порядке). Но не увязните в бессмысленных войнах между табами и пробелами. Самое главное — получить целостный и чистый код, а не достичь теоретического совершенства!
Автоматизация проверки кодстайла
Чтобы обеспечить соблюдение стандартов вашего кода и добиться согласованности в вашей системе, помогите своим коллегам написать код, который будет следовать правилам с помощью линтинга и других инструментов.
Профессиональный лайфхак — Отправная точка для стиля кода
Начните с руководства по стилю открытого исходного кода — я предпочитаю правила Airbnb «Mostly Reasonable» (“Самые разумные”) для CSS, JavaScript и React, а затем измените их в соответствии со своими потребностями. Обязательно включите правила код-стайла вашей команды в документацию вашей дизайн-системы.
Линтинг — это автоматизированный процесс анализа кода и выявления ошибок. Такой способ помогает автоматически найти код, который либо не соответствует вашим правилам синтаксиса, либо неисправен, содержит ошибки или плохо написан. Инструменты линтинга, такие как CSSLint или StyleLint для CSS и JSHint или ESLint для JavaScript, могут быть запущены вами вручную при локальной разработке, или быть автоматическим хуком перед коммитом ваших изменений в системе управления версиями (лучший вариант), или же они могут быть частью процесса сборки.
Профессиональный лайфхак - Автоматическое форматирование
Вы можете перестать беспокоиться о написании вашего JavaScript кода в соответствии с правилами синтаксиса, используя Prettier для автоматического переформатирования кода без изменения основных функций.
Конфигурация редактора кода
Часто упускаемая из виду, но важная для линтинга — это конфигурация редактора, обеспечивающая соблюдение стиля кода в выбранном вами редакторе (-ах). EditorConfig.org (Рисунок 1) предоставляет кроссплатформенный формат для определения стилистических правил для большинства редакторов кода и сред разработки, так что вы можете автоматически преобразовывать табуляции в пробелы - таким образом, прекращая войну между табами и пробелами!
![](https://ivan-demin.gitbook.io/~gitbook/image?url=https%3A%2F%2Fux-journal.ru%2Fwp-content%2Fuploads%2F2020%2F12%2Ffigure1-v2-min-1600x839.jpg&width=768&dpr=4&quality=100&sign=5c21f709&sv=1)
Принцип 2. Автономность
Ваша дизайн-система должна находиться в отдельном репозитории системы контроля версий и не зависеть от вашего основного кода. Хотя для настройки и запуска потребуется больше работы, но отдельный репозиторий дает много долгосрочных преимуществ:
Такой подход помогает выпускать версионные релизы вашего кода (подробнее об этом позже);
Помогает шарить код между разными командами, продуктами и кодовыми базами;
Побуждает разрабатывать компоненты изолированно, поэтому они не будут привязаны к одному варианту использования;
Обеспечивает инфраструктуру для надежного тестирования;
Он составляет основу веб-сайта для живого стайл-гайда;
Автономный репозиторий дизайн-системы функционирует как единственный источник истины. Есть только одно место, где определены компоненты, которые затем передаются другим кодовым базам как отдельная зависимость. Поскольку все способы использования указывают на каноническую реализацию, изменения в одном месте распространятся на всю систему.
В идеале, все программные части для каждого компонента в вашей системе размещены вместе: CSS, JavaScript, HTML-шаблоны и документация находятся в одной точке, возможно, в одном каталоге. Если вы используете React с CSS-in-JS, каждый компонент может быть даже инкапсулирован в один файл. Чем ближе части кода друг к другу, тем проще отслеживать и управлять зависимостями между ними, и тем проще будет обновлять и поддерживать код.
Принцип 3. Повторное использование
Успешные дизайн-системы можно использовать многократно. Bootstrap, самая используемая интерфейсная библиотека всех времен, поддерживает сотни (если не тысячи) веб-сайтов, потому что ее архитектура была разработана с учетом возможности повторного использования.
Создавать повторно используемые в разных контекстах компоненты жизненно важно, но это до сих пор достаточно тяжело хорошо реализовать. В итоге, если вы сделаете компоненты слишком сфокусированными для одного варианта использования или слишком негибкими, то пользователи все-равно начнут создавать свои собственные шаблоны.
Чтобы шаблоны можно было повторно использовать и масштабировать, они должны быть модульными, компонуемыми, универсальными и гибкими.
Модульные компоненты автономны и не зависят друг от друга;
Составные компоненты можно комбинировать для создания новых шаблонов;
Универсальные компоненты могут обрабатывать несколько вариантов использования;
Гибкие компоненты можно настраивать и расширять для работы в различных контекстах;
Профессиональный лайфхак — Stay DRY
Устоявшаяся практика в разработке программного обеспечения — это не повторять себя (“Don’t Repeat Yourself” — DRY). Когда две разные части кода выполняют одну и ту же функцию, вы удваиваете вероятность ошибок, непреднамеренных побочных эффектов и количество времени, затрачиваемого на поддержание функциональности. Цель вашей дизайн-системы — уменьшить дублирование за счет создания повторно используемых шаблонов.
Модульная архитектура CSS
Возможность повторного использования и масштабируемость в дизайн-системах начинаются с модульного подхода к архитектуре кода. Однако CSS не является модульным по своей сути. Так что со временем такие системы, как SMACSS, OOCSS и BEM, добавили в CSS структуру и модульность. Совсем недавно подходы CSS в JS, такие как стилизованные компоненты (Styled Components), решили проблему путем определения свойств CSS в структурах JavaScript-кода.
Независимо от того, используете ли вы одну из этих систем или работаете со своей собственной, основы любой хорошей архитектуры CSS одинаковы:
Определяет четкие соглашения об именовании для компонентов, их вариаций и утилитарных классов;
Требует писать CSS с низкой специфичностью и соблюдением строгих областей видимости, чтобы максимально уменьшить количество непреднамеренных побочных эффектов;
Обладает внутренней системой утилитарных классов, которые позволяют изменять стили управляемым способом;
Описывает правила для создания модульных, составных, универсальных и гибких компонентов;
«Интернет предназначен для всех людей, независимо от конфигурации их оборудования, программного обеспечения, языка, культуры, местоположения, физических или умственных способностей. Когда Интернет достигает этой цели, он становится доступным для людей с различным диапазоном слуха, движения, зрения и когнитивных способностей».
Веб-доступность, INITIATIVE (WAI) W3C
Чтобы узнать больше об архитектуре CSS, я настоятельно рекомендую прочитать Гарри Робертса “https://CSSguidelin.es/”, а затем добавить такую же документацию в вашу систему.
Профессиональный лайфхак — Пространство имен
Работаете с устаревшим кодом? Выберите уникальное, короткое и простое пространство имен для префикса ваших классов, например `.ds- [имя компонента]`. Это позволит избежать конфликтов классов при смешивании нескольких библиотек на странице и гарантирует, что вы знаете, что ваш класс `.ds-btn` отличается от класса` .btn` из Bootstrap.
Принцип 4. Доступность
Доступность (или a11y) частенько неправильно воспринимается, кто-то все еще считает, что это про создание сайтов для небольшой группы пользователей, которым нужны особенные технологий — например для незрячих людей, которым нужны программы для чтения с экрана. Такие программы слишком часто отвергалась как слишком сложная, слишком трудоемкая или “ненужная для именно наших клиентов”. Однако доступность предназначена не только для отдельной небольшой группы, но и для примерно 15% людей во всем мире — 56,7 миллиона человек только в Америке попадают в круг лиц с широким спектром постоянных или временных нарушений зрения, слуха, моторики и когнитивных функций.
«[Тестирование доступности] дает разработчикам отправную точку, чтобы сказать «вот некоторые ошибки, для которых у меня есть реальные способы исправить их прямо сейчас».
Alicia Sedlock — frontend-разработчик и адвокат по доступности
К счастью, это отношение меняется, и наша отрасль принимает более всеобъемлющее определение понятия “доступность”. Предоставление доступа к вашему сайту для пользователей с ограниченными возможностями делает его удобнее для всех, кто его посещает. Если же для вашей мотивации этого недостаточно, то улучшение доступности вашего сайта может также помочь улучшить и SEO, а с юридической точки зрения это поможет избежать дорогостоящих судебных процессов.
В знаменательном деле против сети продуктовых магазинов Winn-Dixie федеральный судья постановил, что веб-сайты попадают под действие положений Закона об американцах с ограниченными возможностями (ADA). Если вы только изучаете тему доступности, существует множество ресурсов, которые помогут вам начать работу. Я рекомендую прочитать вводные статьи из W3C’s Web Accessibility Initiative (WAI) и проекта A11y. Вы можете проверить текущее состояние своего сайта с помощью Tota11y — букмарклета-визуализатора от Khan Academy. Начать внедрять повышение доступности для людей с ограниченными возможностями там, где ее раньше не было, может быть непросто, но когда вы используете свою дизайн-систему, это проще, чем вы думаете.
Обеспечьте соответствие вашей дизайн-системы правилам проекта a11y
Чтобы гарантировать, что все в вашей организации создают доступные сайты, функции и приложения, внедрите передовые методы обеспечения доступности в код вашей дизайн-системы.
Проверьте цвета на соответствие установленным правилам цветового контраста (рисунок 2).
Созданные компоненты должны быть доступны по умолчанию как с клавиатуры, так и для скрин-ридера. Библиотека шаблонов Ebay Accessibility MIND — это потрясающий исчерпывающий ресурс, который поможет разработать доступные компоненты и лучшие практики. Поощряйте коллег создавать код в соответствии с этими рекомендациями и тестировать навигацию не только с клавиатуры, но и с использованием вспомогательных устройств, таких как программы чтения с экрана (скрин-ридеры).
Включите в вашу документацию стандарты кода и рекомендации для общих лучших практик проекта a11y, таких как использование более крупных, разборчивых размеров текста, постоянное связывание поля формы с его названием и правильное добавление атрибутов альтернативного текста к изображениям и др. Дизайн-система Lightning от Salesforce и Polaris от Shopify - отличные примеры практических рекомендаций по обеспечению доступности.
Эти практики доступности делают ваши продукты удобнее для всех, упрощают просмотр, взаимодействие и навигацию по сайту, улучшают показатели заполнения форм и уменьшают количество ошибок пользователей.
![](https://ivan-demin.gitbook.io/~gitbook/image?url=https%3A%2F%2Fux-journal.ru%2Fwp-content%2Fuploads%2F2020%2F12%2Ffigure3-v2-min-1600x796.jpg&width=768&dpr=4&quality=100&sign=c1fb69&sv=1)
Используйте силу вашего центра истины (онлайн дизайн-системы), чтобы создать основу для накатывания доступности, и в итоге снимите часть нагрузки с продуктовых команд. Гораздо проще продумать нюансы с доступностью с самого начала, чем встраивать их после того, как функциональность была спроектирована и разработана.
Принцип 5. Надежность
Надежная дизайн-система сопровождается комплектом тестов для оценки качества. Тестирование дает уверенность в вашем коде и облегчает его внедрение. Пользователи будут знать, что они могут обновить или изменить свой пользовательский интерфейс, не сломав ничего при этом. Кроме того, ваша дизайн-система станет обладать уникальными возможностями для надежного тестирования вашего фронтенд-кода.
«Мне нравится думать об этом как-то так ... есть неявный договор, что это всегда будет работать».
Alicia Sedlock — frontend-разработчик и адвокат по доступности
Тестируйте кирпичики дизайн-системы и ее шаблоны, а не живой огромный продукт в полете на живом
Поддержание актуальности тестов для страниц, приложений и функций — особенно на быстро меняющемся сайте или на сайте с интенсивными экспериментами требует большой работы. Тесты очень быстро устаревают! Вы можете сузить объем своих тестов и получить более высокий уровень уверенности во фронтенд-коде всего сайта, тщательно протестировав компоненты вашей дизайн-системы. Вам просто нужно сгенерировать пример кода для различных состояний каждого компонента для вашей документации и использовать их в качестве фикстур для тестирования.
Виды тестирования
Для обеспечения стабильности вашей дизайн-системы используются 4 типа тестирования:
Модульное тестирование (или юнит-тестирование): такие тесты проверяют, что небольшие блоки кода (обычно отдельные функции) ведут себя должным образом. Юнит-тесты запускают функции с набором предопределенных входных данных, а затем проверяют, что они возвращают ожидаемый результат. Некоторые популярные фреймворки для юнит-тестирования: Mocha, Jasmine и Jest.
Функциональное тестирование: в функциональных тестах примеры вашего кода или «фикстуры» запускаются в виртуальном “headless” браузере, затем тестируются путем моделирования действий пользователя и проверки нового состояния браузера на предмет ожидаемого результата этих действий. Фреймворки функционального тестирования: Nightwatch, Protractor и Casper.
Визуальное регрессионное тестирование: эти тесты помогают выявить непредвиденные визуальные изменения стилей компонентов. Тест-фреймворк делает скриншоты ваших фикстур как до, так и после изменений, а затем сравнивает их, используя алгоритм для обнаружения визуальных различий. Существуют фреймворки с открытым исходным кодом, такие как Wraith, Gemini и BackstopJS, а также платные сервисы, такие как Applitools и Percy.io. Посетите отличный ресурс Кевина Лэмпинга (Kevin Lamping) «Визуальное регрессионное тестирование» для получения дополнительной информации.
Автоматизированное тестирование доступности: используйте инструменты, чтобы убедиться, что ваши компоненты доступны. Некоторыми вариантами проведения автоматизированных a11y проверок являются AATT Paypal-а и a11y от Адди Османи и aXe от Deque Systems.
Распространенные проблемы
Система никогда не будет идеальной. Вы будете принимать решения, о которых позже пожалеете, независимо от того, сколько времени вы потратите на разработку своей дизайн-системы. Однако вы можете предвидеть проблемы, которые будут возникать по мере роста вашей системы, и работать, чтобы избежать или смягчить их влияние на ваш проект.
Я заметила, что в дизайн-системах возникают 3 общие проблемы:
Поддержание актуальности документации в соответствии с системным кодом
Обработка критических изменений
Предотвращение падения производительности
Давайте подробно рассмотрим каждую из этих проблем.
Ведение документации
Когда я впервые создавала библиотеку UI-компонентов, моя команда решила, что будет проще создать веб-сайт документации с базой кода отдельно от нашего приложения. Оглядываясь назад, я понимаю, что это решение нарушило главное правило «Не повторяйся». Всякий раз, когда компонент изменялся в нашей основной кодовой базе, мы должны были не забыть обновить документацию, а затем проделать утомительную работу по дублированию измененного кода в двух разных кодовых базах. Неудивительно, что наша документация почти сразу устарела!
Учитесь на наших ошибках, сокращая дистанцию между вашей документацией и кодом с использованием.
Минимизируйте разделение между кодом библиотеки и кодом документации
Ранее в этой главе мы обсуждали хранение кода вашей дизайн-системы в отдельном репозитории, который служит вашим единственным источником истины. Когда документация и код размещены вместе, более вероятно, что вы не забудете обновить документацию при изменении компонента. Подумайте о добавлении хука перед коммитом в репозиторий вашей дизайн-системы, чтобы предупреждать коллег, когда их изменения в коде не содержат обновленных файлов документации.
Автоматизируйте документацию
Начните документирование вашей системы с помощью простых, удобочитаемых файлов, написанных при помощи markdown, расположенных совместно с каждым компонентом. Github уже настроен для рендеринга и отображения любого файла с именем README.md, когда вы просматриваете содержимое папки. Поэтому вам может вообще не понадобиться яркий веб-сайт. Если все же вы решите создать полнофункциональный веб-сайт документации, используйте автоматизацию, чтобы упростить процесс. Вместо создания новой кодовой базы для отдельного веб-сайта используйте инструмент, который автоматически сгенерирует для вас документацию, (существует множество инструментов для этого), таким образом уменьшая объем структурного HTML-кода, который вам нужно писать и поддерживать.
Профессиональный лайфхак — Cupper
Хейдон Пикеринг (Heydon Pickering) из Paciello Group создал инструмент с открытым исходным кодом: “Cupper” — конструктор документации, который создает полностью доступную документацию. Это веб-приложение на принципах (PWA), поэтому вы можете сохранять и просматривать контент в автономном режиме на поддерживаемых устройствах.
Рассмотрите возможность запуска автоматизированного процесса, чтобы уменьшить полезную нагрузку CSS, а затем используйте эту информацию, чтобы решить, какие компоненты принадлежат вашему основному файлу. UnCSS (https://dbtr.co/unCSS) удаляет неиспользуемые селекторы из вашего CSS и выводит новый сокращенный файл. Другой подход заключается в том, чтобы автоматически определять CSS, необходимый для рендеринга критически важного содержимого, и встраивать его в тэг head страницы, чтобы повысить скорость рендеринга. Адди Османи (Addy Osmani) составил полезный список инструментов для критического пути CSS (https://dbtr.co/critical-CSS).
![](https://ivan-demin.gitbook.io/~gitbook/image?url=https%3A%2F%2Fux-journal.ru%2Fwp-content%2Fuploads%2F2020%2F12%2FCupper-Documentation-Builder-e1511839639112-1600x763.jpg&width=768&dpr=4&quality=100&sign=79895ae8&sv=1)
Обработка изменений
По мере роста внедрения и расширения использования вашей дизайн-системы вы всегда будете осознавать, что не все сделали правильно с первого раза, и вам понадобится план, как справиться с критическими изменениями. Критическое изменение - это ситуация, когда необходимые изменения в коде компонента нарушают существующие способы использования этого компонента или класса. Система дизайна Morningstar предоставляет участникам рекомендации относительно того, что считается критическим изменением. При неправильном обращении критические изменения могут стать серьезной проблемой для ваших пользователей.
Неправильный путь: дублирование
Изначально все CSS и JavaScript для Etsy's Web Toolkit находились в одном монорепозитории с остальным кодом сайта команды. Это означало, что всякий раз, когда кто-то вносил критическое изменение в компонент, его коммит, вносящий изменение, также должен был содержать исправления и обновления для каждого отдельного использования этого компонента. Сначала, когда всего лишь небольшая команда создала и использовала систему на наборе страниц, найти и внести эти изменения было относительно легко. Но по мере того, как внедрение распространилось по всей компании, это быстро стало неуправляемым.
Внесение серьезных структурных изменений в существующие компоненты, которые наша команда в Etsy начала дублировать и затем делать их устаревшими, стало ужасной головной болью для всех. Когда мы реорганизовали наш компонент «Tabs», чтобы сделать его полностью доступным, мы создали новый компонент под названием «Tabs2», а компонент «Tabs» сделали устаревшим, в надежде, что команды возьмутся за работу по обновлению своего кода. Но без четких указаний о том, как и почему, а также без графика, указывающего, когда обновлять, большинство пользователей не были обновлены для использования нового компонента. Такое дублирование - кошмар при поддержке кода.
Правильный путь: управление версиями (версионирование) Храните код дизайн-системы в репозитории системы управления версиями, тогда сможете быстрее разруливать критичные изменения и получите управляемую систему. Такой подход даст вам возможность версионировать релизы вашего кода, которые можно использовать совместно с другими проектами. Git позволяет пометить коммит номером версии релиза, а менеджеры пакетов, такие как npm и Yarn, позволяют упаковать и опубликовать несколько версий кода вашей дизайн-системы.
С версионированием релизов разработчики, которые интегрируют код вашей дизайн-системы, могут нацеливаться на конкретную версию как на зависимость и контролировать, когда и как выполняется обновление до новых версий. Обязательно публикуйте примечания к выпуску с подробным описанием изменений, чтобы другие команды могли узнать, как обновления повлияют на их кодовую базу, и лучше спланировать работу по обновлению в сроках своих проектов.
Профессиональный лайфхак — Использование semver
Многие проекты с поддержкой версионирования используют semver (сокращение от семантического версионирования - semantic versioning) для различения типов релизов. Semver использует 3 целых числа, разделенных точками, для обозначения major.minor. версии патча, например, v1.2.3.
1. Основные (мажорные) версии (1.0.0) содержат критические изменения по сравнению с предыдущими версиями.
2. Второстепенные (минорные) версии (0.1.0) добавляют новую функциональность, которая обратно совместима.
3. Патчи (0.0.1) содержат исправления для существующих функций и имеют обратную совместимость.
Semver добавляет еще один уровень уверенности в том, что определенные обновления должны быть незаметными для пользователей, в то время как другие могут потребовать регрессионного тестирования или изменений в коде.
Как избежать проблем с производительностью
По мере роста дизайн-системы увеличивается и размер ресурсных файлов, отправляемых по сети с каждой страницы. Такой подход может отрицательно сказаться на загрузке страниц вашего сайта, что, в свою очередь, отрицательно скажется на прибыли вашей компании. Поэтому помогайте продуктам, созданным на основе вашей дизайн-системы, избежать проблем с производительностью и используйте подход, ориентированный на мобильные устройства. В общем создавайте свою систему с учетом модульности.
Сначала мобильные (Mobile first)
Низкая скорость загрузки страницы оказывает наибольшее негативное влияние на посетителей с мобильных устройств. Согласно статистике Google и Akamai, более половины мобильных посетителей покидают страницы, загрузка которых занимает более 3 секунд, в то время как большинство мобильных сайтов загружаются дольше 10 секунд. Поскольку мобильный трафик обгоняет десктопный, повышение производительности ваших страниц становится как никогда важным и дает конкурентное преимущество.
Создавайте свою дизайн-систему с учетом мобильных устройств — тестируйте на настоящих устройствах с настоящим железом и настоящим сетевым подключением, чтобы вы по максимуму прочувствовали опыт живых клиентов.
Используйте модульность
Первоначально имело смысл объединять все компоненты и утилиты Etsy Web Toolkit в отдельные файлы для CSS и JavaScript. Хотя это полезно для прототипирования, оно добавляет ненужный вес страницам, на которых не используются все компоненты. Теперь мы работаем над тем, чтобы избежать проблем с производительностью, эффективнее используя модульность, присущую системе. Для этого мы:
Выбираем набор основных компонентов и утилит, которые используются чаще всего. Этот базовый файл будет включен на всех страницах, использующих дизайн-систему, и может быть закеширован браузером для сокращения времени загрузки
Добиваемся полной модульности всех компонентов без межкомпонентных зависимостей (если они не являются явными и не управляются системой)
Упаковывать и распространять код системы нужно так, чтобы его можно было использовать как отдельные модули CSS и JavaScript, добавленные как зависимости только тогда, когда компонент фактически используется на странице. Мы используем внутреннюю систему для определения зависимостей в нашем внешнем коде. Создавайте модули своей дизайн-системы так, чтобы они работали с менеджером зависимостей, который использует ваша команда. Например, Webpack — популярный вариант.
Думайте наперед
Маркеры дизайна
Большую часть этой главы я была сосредоточена на создании дизайн-систем для веб-приложений и сайтов. Однако это не полная картина. Современные организации сталкиваются с уникальными проблемами, связанными с масштабированием дизайн-систем. Сегодня мы создаем для нескольких веб-платформ и нативных платформ, которым требуется согласованный дизайн. В более крупных организациях может быть несколько суббрендов, которым нужна общая поддержка, функциональность и организованность, которые предоставляет дизайн-система, но каждому из них нужен свой внешний вид, соответствующий бренду. UX команда Salesforce представила решение обеих этих проблем: дизайн-токены (маркеры дизайна).
Кросс-платформенный шаринг
Маркеры дизайна — это способ абстрагироваться от деталей дизайна, таких как цвета, шрифты, радиус закругленных углов и т. д.. Это формат, который можно использовать на разных платформах с помощью инструмента Theo из Salesforce. Вместо того, чтобы определять основной цвет вашего бренда как $ переменную SASS в вашем веб-приложении, UIColor в вашем iOS-приложении и textColor в вашем Android-приложении, вы определяете один маркер дизайна в общем файле JSON, который компилируется в платформо-зависимый код. Решили изменить радиус всех закругленных углов с 3 пикселей на 5 пикселей? Измените значение один раз в файле токенов, и оно автоматически распространяется на все ваши приложения.
Многопродуктовая тематика
Вы также можете использовать токены, чтобы «тематизировать» один и тот же структурный стиль для нескольких брендов. Одному бренду нужны оранжевые пуговицы, а другому — синие? Не проблема! Вы можете определить разные значения токенов для каждого бренда, а затем объединить их в один и тот же базовый CSS для вывода тематических версий вашей дизайн-системы. Таким образом, все классы одинаковы, и все доступные функции JavaScript, над созданием которых вы так усердно работали, можно использовать как есть, без каких-либо изменений для каждого брэнда.
Заключение
Систематизация frontend-части приносит пользу всем в вашей организации: разработчики работают быстрее, дизайнерам не нужно изобретать велосипед и, в конечном итоге, ваши пользователи получат больше удовольствия от работы. Но старт разработки может показаться неподъемным!
К счастью, существует множество ресурсов и растущее сообщество людей, которые делятся лучшими практиками и готовы помочь построить вашу систему. В «Styleguide Resources» от Анны Дебенхам (Anna Debenham) перечислено около 500 общедоступных систем дизайна / руководств по стилю / библиотек шаблонов, которые можно использовать в качестве вдохновения. Хотя они выглядят и ощущаются по-разному, но все они преследуют общую цель и разработаны с помощью основополагающих принципов, созданных отраслью разработки в результате многих лет проб и ошибок.
Гибкая, поддерживаемая, стабильная, масштабируемая и успешная дизайн-система начинается с прочного фундамента, который выходит за рамки фреймворков или инструментов. Если я чему-то и научилась за свою карьеру, так это тому, что единственной постоянной составляющей фронтенд-разработки являются изменения. Скорее всего, через несколько лет технология, управляющая вашим интерфейсом, будет выглядеть совсем иначе, чем сейчас. Если вы разрабатываете на долгосрочную перспективу и планируете справляться с изменениями, вы можете внедрять новые, более эффективные методы по мере роста вашей системы.
Это не значит, что ваша цель — создать еще один Bootstrap. Даже если ваша команда может реализовать лишь некоторые из лучших практик, которые мы обсуждали в этой главе, это все равно стоит того, т.к некоторые из рекомендуемых мной методов еще не реализованы в дизайн-системе, над которой я работаю каждый день! Дизайн-системы — это не что-то одноразовое, это непрерывный процесс итераций и изменений: когда мы делаем ошибки, учимся друг у друга и создаем новые и лучшие подходы к фронтенд-коду.
Last updated