Определяйте решения, а не только галерею стилей
Дизайн‑система — это не просто скриншоты. Она фиксирует повторяющиеся решения: отступы между секциями, оформление основного действия, поведение ошибки формы и язык сообщений об успехе или неудаче. USWDS описывает дизайн‑токены как дискретные палитры значений для типографики, отступов, цвета, межстрочного интервала и прозрачности. Документируйте правило, его назначение, утверждённые варианты и владельца. Начните с основ и пяти‑восьми компонентов, которые чаще всего встречаются в важных пользовательских сценариях; стандартизация всей площадки разом чаще порождает шум, а не ясность.
Фиксируйте утверждённые роли цветов, гарнитуру, отступы, границы, радиусы, точки перелома и анимационные решения, которые реально используются на вашем сайте.
Используйте паттерн для повторяющейся организации задач, например регистрация аккаунта или результаты поиска, а не для единичного визуального украшения.
Используйте токены, чтобы контролировать повторяющиеся значения
Дизайн‑токен — это читаемое человеком имя, связанное со значением. Design Tokens Community Group описывает токены как платформонезависимый способ зафиксировать дизайнерские решения; по сути токен — это имя и значение. Используйте имена по назначению, например `color-action-primary` или `space-section`, вместо того чтобы раскидывать сырые значения по шаблонам. Поддерживайте документированную привязку от токенов назначения к базовым значениям. Токены упрощают координированные изменения, но не гарантируют контрастность, соответствие бренду или хорошую иерархию. Валидируйте каждую комбинацию и состояние страницы.
Создавайте токены для повторяющихся выборов, а не для каждой исключительной ситуации; иначе список токенов будет лишь сохранять несогласованность.
Для широко используемого токена укажите затронутые страницы, протестируйте репрезентативные экраны и при необходимости дайте инструкции по миграции или откату.
Создавайте компоненты с поведением и границами
Компонент — это повторно используемая часть интерфейса с поведением, а не только визуальная форма. Документируйте семантическую структуру, обязательные и опциональные входы, варианты, адаптивное поведение и все релевантные состояния: загрузка, отключённый, ошибка, пустое и успех. Включите поведение при работе с клавиатурой и правила работы с контентом. Не принуждайте все макеты встраиваться в компонент. GOV.UK оценивает общие компоненты по полезности, уникальности, удобству, согласованности и универсальности; это полезная дисциплина при решении, что заслуживает общей поддержки. Широко используемый компонент может также широко распространить дефект, поэтому тестируйте его на страницах, где им реально пользуются.
Перечислите каждое состояние, видимое пользователю, и покажите реальные подписи, длинный текст и ошибки, чтобы было видно ограничение реализации.
Ясно помечайте старые варианты, назовите замену и удаляйте их только после того, как затронутые сценарии будут пересмотрены.
Сделайте доступность условием релиза
Доступность должна быть встроена в систему, потому что повторяющиеся выборы могут повторять барьеры. WCAG 2.2 требует, на уровне A, клавиатурной управляемости функциональности, кроме случаев, где путь движения по своей природе необходим, и требует осмысленного порядка фокуса, когда последовательность важна. Делайте семантические элементы управления, видимый индикатор фокуса, метки, логичное перемещение фокуса, идентификацию ошибок и возможность выполнения задач без указательного устройства частью руководства по компонентам. Используйте автоматизированные проверки на ранних этапах, затем ручное тестирование клавиатурой, масштабирование, адаптивность и тест страницы. USWDS предупреждает, что доступные компоненты не гарантируют доступность сервиса; кастомный код, тексты, интеграции и контекст всё ещё требуют проверки.
Убедитесь, что люди могут добраться до элементов, управлять ими, понимать их и покинуть их без мыши, без попадания в ловушку фокуса.
Юридические обязанности различаются по юрисдикциям и контрактам. При материальной значимости соблюдения привлеките квалифицированную экспертизу по доступности и юридическую проверку.
Рассматривайте правила контента как стандарты интерфейса
Слова — это входы компонента, а не украшение, добавляемое после дизайна. Установите правила для подписей действий, меток форм, сообщений об ошибках, заголовков, ссылок, терминологии, дат, чисел и аббревиатур. Руководство GOV.UK отдает предпочтение активному залогу и обращению к пользователю на «вы» там, где это возможно; используйте принцип ясного, последовательного языка, адаптируя голос под аудиторию. Сопоставляйте правила с моделью контента: укажите, какие поля обязательны, рекомендации по разумной длине и что происходит при отсутствии информации. Размещайте рекомендации в документации по компонентам и в рабочих процессах CMS, чтобы редакторы могли ими пользоваться.
Говорите, что не сработало, где это произошло и какое следующее действие нужно выполнить, когда это безопасно и полезно.
Ограничение — это сигнал к переработке или переписыванию, а не разрешение удалять существенный смысл.
Управляйте системой, прежде чем она вырастет быстрее доверия
Говернанс — это лёгкий процесс для назначения владельцев, запросов, проверок, релизов и вывода из эксплуатации. Назначьте ответственного владельца и ревью‑группу, включающую специалистов по дизайну, инженерии, контенту и доступности. Сопоставляйте доказательства с радиусом поражения. Местный паттерн может требовать формулировки проблемы и теста страницы. Изменение общей кнопки или токена должно включать затронутые сценарии, проверки доступности, визуальное сравнение, примечания по миграции и инструкции по откату. GOV.UK просит авторов показать, что компонент полезен для многих команд, не является дубликатом и протестирован с репрезентативными пользователями; используйте это как практическую модель, а не как универсальное правило.
Сохраняйте проблему, варианты, принятое решение, владельца, затронутую версию и дату пересмотра в месте, доступном для поиска командами.
Маркируйте изменения как патч, добавление или ломающие, чтобы потребители знали, когда нужна миграция и период совместимости.
Предотвращайте регрессии до релиза
Свяжите систему с доставкой. Требуйте, чтобы изменение указывало затронутые токены и компоненты, затем тестируйте затронутые состояния и репрезентативные страницы. Визуальное сравнение, тесты взаимодействия, проверка контента и проверки доступности обнаруживают разные типы дефектов. Приоритизируйте не только высоконагруженные пути, но и критичные по последствиям; доступ к аккаунту и контактные формы могут быть важны даже при умеренном трафике. Это поддерживает проактивную оптимизацию доступности и работы Status Is UP, сужая область дефекта и облегчая верификацию утверждённого исправления. Это не мониторинг простоя и не замена плана реагирования на инциденты.
Храните версию компонента, результаты тестов, выводы, утверждения и любой принятый риск вместе с записью релиза.
Сохраняйте предыдущую стабильную версию и пропишите шаги восстановления и проверку во время низко‑рискованного обслуживания.