Проблемы внедрения дизайн-системы

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

Что такое дизайн-система?

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

Система дизайна — это набор стандартов для управления дизайном в масштабе за счет уменьшения избыточности при создании общего языка и визуальной согласованности на разных страницах и каналах.

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

Какую проблему пытается решить дизайн-система?

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

Вам нужно рассмотреть несколько вещей, помимо новых функций. Для новых элементов пользовательского интерфейса (например, аккордеона, которого у вас нет ни на одной другой странице) вам потребуется предварительная работа по дизайну, а затем разработчики могут приступить к их реализации. Но обычно здесь будут какие-то перестановки, например, сколько border-radius для нового элемента, какова задержка анимации и как насчет радиуса box-shadowspread?

Кроме того, для существующих элементов, таких как кнопка, используемых на других страницах, может потребоваться «небольшая» обработка для использования на новых страницах (поскольку она может не совсем соответствовать использованию).

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

Обратите внимание, что я говорю не только о визуальных деталях (они, безусловно, имеют решающее значение), таких как высота, цвет, типографика, макет, изображение, анимация и т. д., но также о доступности, языке и тонах, которые вы используете на разных страницах, и усилия по внесению новых изменений при одновременном сохранении согласованности.

Именно об этом дизайне в масштабе мы говорим здесь.

Проблемы, с которыми вы можете столкнуться

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

Доступность

Для серьезной дизайн-системы доступность не является факультативной, а обязательной. Вам нужно построить клавиатурную навигацию, и вам нужно использовать ARIA атрибутов, когда это необходимо, а коэффициент цветовой контрастности должен удовлетворять минимальным требованиям WCAG.

Например, в Material UI и Atlassian Design System с помощью клавиатуры можно выполнять почти все действия: переходить к следующей ссылке, искать документ, переключаться между темным и светлым режимами и т. д.

Но не все дизайн-системы построены одинаково. Ant Design — самая популярная дизайн-система в Китае, не имеет визуального индикатора при навигации с помощью клавиатуры. Вы не можете видеть кольцо выделения вокруг ссылок или около того.

Обновление новой версии

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

— Хайрам Райт

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

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

Какие шаги нужно предпринять, когда это кардинальное изменение
Если при обновлении возникнут проблемы, что вы будете делать? Откатитесь на старую версию или пропатчите новую
Что делать, если в некоторых продуктах используется основная версия 3, и вы хотели бы обновить ее до последней версии? Насколько это легко?

Используя такие инструменты, как jscodeshift (со скриптом codemod), обновление можно значительно упростить. Но, тем не менее, будут некоторые сложные дела, которые вы можете пропустить. Так что будьте готовы к некоторым специальным хакам и здесь. У меня есть целая статья о том, как использовать codemod и jscodeshift для автоматического обновления ломающегося API.

Стратегия тестирования

Излишне говорить о том, насколько важен тест для любой кодовой базы, а теория тестовой пирамиды применима к компонентам системы проектирования. В дополнение к модульным тестам, которые больше сосредоточены на изолированном тесте без участия реального браузера, и интеграционным тестам, которые объединяют некоторые компоненты и проверяют, хорошо ли они работают во всех поддерживаемых браузерах (в том числе с разными версиями), вы также нужны визуальные регрессионные тесты.

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

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

Ниже приведен конкретный пример того, как это работает в реальном сценарии. Я использовал cypress + cypress-visual-regression для проверки. Есть много других альтернатив. Доступны как коммерческие (browserstack), так и фреймворки с открытым исходным кодом.

И в реализации я поменял местами два продукта в разделе сведений о заказе, и поэтому визуальная регрессия обнаружила разницу:

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

Документы

Легко упустить из виду, насколько важным может быть документ в дизайн-системе. Если бы вы могли сделать его живым документом, например, встроить codesanbox на страницу, чтобы потребитель (разработчик) мог поиграть с кодом, это было бы здорово.

Кроме того, хороший документ должен включать в себя руководство о том, когда продукт должен использовать какие компоненты, чтобы сделать взаимодействие с пользователем более естественным. В Atlassian Design System использование компонента состоит из нескольких четко определенных разделов, таких как Анатомия, Поведение, Рекомендации и рекомендации по содержанию и т. д. .

Бизнес как обычно

Когда вы достаточно велики, чтобы привлекать внутренних и внешних пользователей, это связано с обязанностями поддержки и дежурства. Люди могут использовать компоненты неожиданным образом (поэтому вам потребуется больше времени на изучение), и вы должны убедиться, что сообщение всегда согласовано как команда (чтобы потребитель не чувствовал себя сбитым с толку).

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

Право собственности на дизайн-систему

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

Команда продукта может сосредоточиться на том, как извлекать данные и преобразовывать их в некоторую форму, которая может использоваться компонентом Order или UserProfile, в то время как система дизайна больше фокусируется на токенах, производительности отдельных компонентов и на том, как сделать их более компонуемыми. и тому подобное.

Краткое содержание

Дизайн-система — отличный способ убедиться, что пользовательский опыт вашего продукта остается согласованным, и облегчить некоторые проблемы при проектировании в масштабе. Но это не бесплатно, это довольно дорого, чем вы думали. Извлечение общей библиотеки компонентов — это простой первый шаг, после которого выполняется 80% работы.

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