Стандарт качества дизайна сайтов
Зачем это изучать
Вы превратите «сделай красивый сайт» в набор конкретных требований, по которым Codex сможет проектировать, реализовывать и проверять интерфейс.
Проверено: 23 августа 2026 года.
Этот стандарт — baseline для новых или существенно перерабатываемых сайтов. Он не заменяет брендбук, продуктовые исследования, юридические требования и правила конкретного проекта. Если они существуют, они приоритетнее.
1. Сначала — задача, не макет
До кода Codex фиксирует:
- аудиторию и один главный сценарий страницы;
- ключевое действие и критерий, по которому пользователь понимает его пользу;
- обязательный контент, ограничения бренда и технический стек;
- целевые размеры экранов и состояния: загрузка, пустой результат, ошибка, успех, длинный текст и отключённое действие;
- способ проверки: браузер, клавиатура, адаптивные размеры, тесты и метрики.
Не начинайте с декоративной анимации, случайного градиента или галереи референсов. Сначала проверьте, что структура страницы поддерживает задачу пользователя.
2. Визуальная система вместо разрозненных стилей
Codex должен опираться на уже существующую дизайн-систему проекта. Если её нет, нужно создать небольшой набор токенов и использовать его последовательно:
| Слой | Минимум, который нужно определить |
|---|---|
| Цвет | фон, текст, приглушённый текст, граница, акцент, success/warning/error и состояния hover/focus |
| Типографика | семейство, шкала размеров, начертания, высота строки, максимальная длина строки текста |
| Пространство | кратная шкала отступов и единый контейнер страницы |
| Форма | радиусы, границы, тени и их назначение |
| Движение | только осмысленные переходы; поддержка prefers-reduced-motion |
Не дублируйте произвольные hex-значения, пиксели и box-shadow в компонентах. Один смысл — один токен. Для повторяющихся решений создавайте компонент, а не ещё одну почти такую же разметку.
3. Иерархия, контент и действия
- На первом экране видны назначение страницы, ценность и главное действие.
- У страницы один визуально главный CTA; вторичные действия не конкурируют с ним размером и цветом.
- Заголовки образуют логичную структуру
h1→h2→h3, а не служат только для выбора размера текста. - Текст в кнопках и ссылках говорит о результате действия: «Сохранить профиль», а не «Нажмите сюда».
- Не прячьте важный смысл только в цвете, иконке, hover или анимации.
- Реальный контент важнее lorem ipsum: проверяйте длинные имена, цены, отсутствующие изображения и локализацию.
4. Адаптивность и устойчивость
Проектируйте один интерфейс для диапазона, а не три несвязанных скриншота. Минимум проверок: 320 px, обычный мобильный экран, 768 px, 1024 px и широкий desktop. В каждом размере проверьте:
- нет горизонтальной прокрутки и обрезанного текста;
- навигация и таблицы имеют понятную мобильную стратегию;
- целевые зоны касания и расстояния между ними достаточны;
- изображения сохраняют пропорции, имеют заданный размер или
aspect-ratio; - фиксированные панели не перекрывают focus, CTA и системные элементы.
5. Доступность — обязательное свойство
Цель по умолчанию — WCAG 2.2 AA для интерфейса, если проект не требует более строгого уровня. WCAG задаёт тестируемые критерии, а не только общие пожелания; рекомендации охватывают восприятие, управление, понятность и совместимость интерфейса.
Перед приёмкой Codex обязан проверить:
- весь сценарий проходит клавиатурой; нет keyboard trap;
- focus всегда заметен и не скрыт закреплённой панелью или модальным слоем;
- интерактивный элемент имеет корректные имя, роль и состояние;
- у изображений есть осмысленный
alt, а декоративные исключены из чтения; - у полей есть видимая подпись, ошибка и понятный способ исправления;
- контраст текста и существенных элементов соответствует выбранному уровню;
- порядок в DOM соответствует визуальному и смысловому порядку;
- движение можно сократить через
prefers-reduced-motion.
Автоматическая проверка полезна, но не доказывает качество фокуса, смысла alt, порядка чтения и понятности текста. Нужен ручной проход в браузере.
6. Производительность сохраняет дизайн
Быстрый интерфейс воспринимается как более качественный. Не добавляйте тяжёлые шрифты, видео, анимации или клиентский JavaScript без функции для сценария. Для публичных страниц используйте как ориентир 75-й перцентиль реальных загрузок: LCP ≤ 2,5 с, INP ≤ 200 мс и CLS ≤ 0,1. Лабораторная проверка ловит регрессии до релиза, но не заменяет полевые данные.
Практические требования:
- резервируйте место под изображения, embed и динамические блоки;
- не блокируйте первый экран необязательными скриптами;
- используйте оптимальный формат и размер изображений;
- загружайте ресурсы ниже первого экрана по необходимости;
- измеряйте производительность на мобильном профиле, а не только на рабочем компьютере разработчика.
7. Шаблон задания для Codex
Создай [страницу/сайт] для [аудитория], чтобы она могла [главный сценарий].
Главное действие: [CTA и результат].
Контент и тон: [обязательные блоки, бренд, язык, запреты].
Используй существующие компоненты и токены проекта; новые зависимости не добавляй.
Поддержи 320–1440 px, длинный контент, loading/empty/error/success состояния.
Цель доступности — WCAG 2.2 AA: семантика, клавиатура, видимый focus,
контраст, подписи полей и осмысленные alt.
Перед завершением проверь в браузере ключевой сценарий, мобильный размер,
клавиатуру и производительность. В отчёте перечисли выполненные проверки и
все непроверенные пункты.Расширенные промпты для нового сайта, точечной правки и read-only review находятся в постановке задач. Полный browser-контур — в проверке реализации.
Внешние источники ↗
- WCAG 2.2 — актуальная рекомендация W3C и тестируемые критерии доступности.
- How to Meet WCAG 2.2 — фильтруемый справочник критериев и техник.
- Web Vitals — назначение метрик LCP, INP и CLS, актуальные целевые значения и различие лабораторных и полевых данных.
- Источники раздела — OpenAI, W3C, GOV.UK, USWDS, Playwright и Storybook.