Внедрение внутри команды

Что это такое

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

Почему это важно

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

Ключевые идеи

Сделайте путь по умолчанию путём системы

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

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

Находите препятствия наблюдением, а не догадками

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

Отвечайте открыто

Держите вопросы и ответы где-нибудь на виду: одни и те же три вопроса задаёт каждый новичок, а публичный ответ снимает их навсегда.

Рано перенесите заметный экран

Ничто не убеждает так, как система в самом продукте. Перенесите один популярный экран от начала до конца и покажите «до» и «после».

Измеряйте переиспользование

Считайте компоненты, использованные вне системы, — форки и локальные переопределения. Это число, отслеживаемое во времени, и есть метрика внедрения; скачивания и просмотры страниц не подходят.

Практика

Посмотрите, как один потребитель собирает экран

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

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

Перенесите один экран и запишите трудозатраты

Возьмите один заметный экран, замените его локальные паттерны на системные и замерьте время. Повторите на втором экране.

Готово, когда: второй экран занял измеримо меньше времени, чем первый, и оба свободны от локальных переопределений.

Частые ошибки

• Выпустить библиотеку и объявить о ней — люди продолжают работать как раньше; исправить: уберите путь копирования-вставки и сделайте шаблон значением по умолчанию.
• Считать причиной нежелание — настоящая причина обычно в недостающем состоянии или токене; исправить: посмотрите, как кто-то собирает экран, и запишите, на что он наткнулся.
• Отвечать на вопросы приватно — одни и те же вопросы повторяются с каждым новичком; исправить: отвечайте там, где все могут найти ответ.
• Не переносить ничего заметного — у системы нет примеров в продукте; исправить: перенесите один популярный экран и покажите результат.
• Измерять скачивания — это число ничего не говорит о согласованности; исправить: считайте локальные переопределения и форки вне системы.

Что читать дальше

• Дизайн-системы (03-design-ux/32-design-systems) — трек, который закрывает эта глава.
• Управление и версионирование (03-design-ux/32-design-systems/03-governance-and-versioning) — правила, от которых зависит внедрение.
• API компонента и документация (03-design-ux/32-design-systems/02-component-api-and-documentation) — артефакт, вокруг которого на самом деле идут проблемы внедрения.
• Передача дизайна и спецификации (03-design-ux/42-design-handoff-specs) — как упаковать компоненты, чтобы их было легко внедрять.