The following article is offered for informational purposes only, and is not intended to provide, and should not be relied on, for legal or financial advice. Please consult your own legal or accounting advisors if you have questions on this topic.

В Flex мы — небольшая команда инженеров, способная на многое и ориентированная на результат. После нескольких лет быстрых изменений продукта и смен направлений мы накопили значительный объем UX-долга, что стало проявляться в неуклюжем пользовательском опыте. 

Нам по-прежнему нужно было быстро выпускать продукты, но с гораздо более высокими стандартами качества и общим пониманием того, что на самом деле означает «качество». Однако, когда мне предложили идею создания дизайн-системы, меня охватила легкая паника.

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

Задача

Быстро возник вопрос: «Как мы можем внедрить «легковесную» дизайн-систему, которая принесет пользу, не замедляя нас?»

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

Обычные, комплексные дизайн-системы

• Пользовательские компоненты (кнопки, модальные окна, таблицы и т.д.)
• Пользовательские инструменты (настройки Storybook, внутренняя инфраструктура)
• Процессы/управление изменениями
• Высокие затраты на поддержку

Легковесные дизайн-системы

• Только наиболее часто используемые компоненты и паттерны
• Легко внедряется — документация и код находятся там, где уже работают разработчики.
• Использует существующие библиотеки вместо создания с нуля (по возможности)
• Содержит стандарты использования

Наши ограничения: Маленькая команда, большие цели.

Мы начали с элегантной серии дизайнов, которая охватывала все: от атомарных компонентов (кнопки, поля ввода и т.д.) до типовых макетов и многошаговых процессов. 

На протяжении всего этого процесса мы приложили все усилия, чтобы не создавать новые компоненты без крайней необходимости. Использование выбранных нами инструментов было крайне важным. Мы небольшая компания, которая еженедельно выполняет огромный объем работы; меньше всего нам хотелось увязнуть в мелочах, решая уникальные проблемы, связанные с уникальными компонентами.

Хотя визуальные несоответствия были очевидны, более глубокой проблемой, которую я заметил в Flex, было отсутствие единого подхода к созданию типовых пользовательских интерфейсов, таких как формы. Можно было зайти в кодовую базу и найти пять разных способов реализации форм. Было очевидно, что нам нужен набор стандартов.

Создание набора единых стандартов

Ранее мы начали создавать раздел «шпаргалка» для разработчиков, где они могли бы найти набор лучших практик для копирования и вставки. Это стало идеальным местом для демонстрации нашей формирующейся дизайн-системы. Мы могли использовать эту область (позже переименованную в «Playground»), чтобы разработчики могли просматривать и использовать эти стандарты для наших наиболее распространенных пользовательских интерфейсов, ускоряя свою работу, а также позволить дизайнерам убедиться, что то, что они создали, действительно используется. Наконец, встраивание этого в наше собственное веб-приложение (а не внешнее размещение, например, через платформу Storybook) помогло обеспечить его использование.

Однако история только начиналась. Сначала нам предстояло одолеть пару «драконов»:

1. Мы были привязаны к предыдущей версии выбранной нами библиотеки пользовательского интерфейса и для обновления потребовались бы поистине геркулесовы усилия. Это изменение затронуло бы как наше клиентское приложение, так и наш внутренний инструмент Alfred.
2. Нам нужно было объединить репозитории для совместного размещения наших внутренних и веб-приложений чтобы обеспечить использование дизайн-системы во всех приложениях.

После завершения этих этапов мы обновили темы обоих приложений, чтобы они соответствовали новым дизайнам, и процесс набрал обороты.

Факторы усиления

После изменения тем нашего внутреннего инструмента Alfred и веб-приложения мы начали создавать набор лучших практик в Playground. Со временем Playground стал содержать «80/20» наших сценариев использования — единый центр для компонентов, макетов и общих утилит.

‍

‍

Хотя мы знали, что Playground будет полезен разработчикам для копирования/вставки компонентов, чтобы ускорить работу, этот набор стандартов оказался идеальным для того, чтобы большие языковые модели (LLM) понимали, как должен генерироваться код пользовательского интерфейса.

Представляем: Cursor

Вскоре после того, как мы начали создавать Playground, наша команда фронтенда начала использовать Курсор ИИ. Мы создали нашу справочную площадку для правил Cursor Playground, чтобы использовать ее в качестве отправной точки при генерации любого кода пользовательского интерфейса:

• Примеры использования компонентов нашей дизайн-системы можно найти в Playground по адресу `src/areas/playground`.
• При реализации новых компонентов, таких как Drawers, Tables, Wizards, Layouts и т.д., скопируйте файл в том виде, в каком он реализован в Playground, и используйте его в качестве отправной точки в той области, над которой вы работаете.
• В большинстве случаев вы не будете обновлять файлы в `src/areas/playground`, а просто использовать компоненты оттуда в качестве отправных точек для копирования в новые папки в `src/areas`.

Наши предыдущие усилия по изменению темы принесли огромные плоды, поскольку они позволили Cursor создавать пользовательские интерфейсы, соответствующие нашей дизайн-системе, без необходимости обращаться к каким-либо руководствам по стилю.

Чтобы еще точнее определить, «что означает качество фронтенда в Flex», мы кодифицировали стандарты, которые ранее согласовали как команда UI. Cursor ссылается на это в дополнение к правилам Playground, чтобы LLM понимала не только что нужно создать, но и как это сделать в сочетании с нашими различными инструментами и соглашениями. Вот фрагмент того, как мы ссылаемся на нашу текущую библиотеку UI, Mantine, из файла правил Cursor:

• Используйте Mantine в качестве основной библиотеки компонентов React.
• Используйте библиотеку Mantine в полной мере, включая компоненты из `@mantine/core`, хуки из `@mantine/hooks`, формы с `@mantine/form`.
• Для компонентов всегда старайтесь сначала использовать компоненты из наших папок `components/core` или `components/composites`, в противном случае используйте основные компоненты Mantine, когда это возможно.
• Избегайте использования инлайн-стилей или классов — всегда старайтесь сначала использовать пропсы Mantine для стилизации цветов и фоновых цветов, отступов и размеров и т.д.
• Для цветов всегда используйте цвета нашей темы Mantine (например, `theme.colors.yourColorHere[index]`).
• Для отступов и размеров используйте функцию `rem()` Mantine вместо пиксельных или числовых значений, например `gap={rem(12)}`.

Результаты Flex

Использование ИИ в сочетании с нашей дизайн-системой стало переломным моментом для создания и поддержания более высоких стандартов скорости и качества. Наша недавняя функция «Дебиторская задолженность» была полностью разработана всего за три недели! 

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

Недавно мы использовали Playground в качестве образовательного ресурса, чтобы показать, как разработчики могут использовать альтернативы инструменту управления состоянием, который мы активно пытаемся вывести из эксплуатации. В ближайшем будущем мы планируем привязать наши стандарты Playground к нашей сборке CI, чтобы обеспечить дальнейшее внедрение.

Уроки для других команд

Если вы находитесь на ранней стадии, вот что мы рекомендуем:

• Начните с малого: Сосредоточьтесь на наиболее часто используемых компонентах пользовательского интерфейса
• Избегайте индивидуальной разработки: Большинство современных библиотек компонентов пользовательского интерфейса могут быть использованы для быстрого старта работы над вашей дизайн-системой. Оставьте индивидуальную разработку для более сложных компонентов и рабочих процессов
• Определите конкретно, что такое «хорошо»: Убедитесь, что у вашей команды есть набор согласованных стандартов в отношении инструментов пользовательского интерфейса и соглашений о кодировании, чтобы вы могли кодифицировать их с помощью инструментов ИИ
• Сделайте это очевидным для вашей команды: Встройте вашу дизайн-систему в продукт, чтобы обеспечить ее применение
• Сделайте это доступным для LLM: Убедитесь, что ваши инструменты ИИ могут легко ссылаться на вашу дизайн-систему и стандарты для обеспечения согласованности перед генерацией кода

Заключительные мысли

Вам, вероятно, не нужна индивидуальная или полная дизайн-система. Вам нужна полезная.

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

Для команд на ранних стадиях развития, делающих ставку на скорость и инструменты ИИ, это может быть одной из самых разумных инвестиций в инфраструктуру, которые вы можете сделать.

‍