DESIGN RULES

1. Главный принцип

Интерфейс строится не вокруг экрана, компонента, Tailwind-классов или модного стиля. Интерфейс строится вокруг:

пользователь -> контекст -> задача -> объект -> действие -> состояние -> восстановление -> доверие

Красивый экран без поведения, состояний и понятной задачи считается незавершенным.

2. Сначала определить продуктовую рамку

Перед дизайном ответить:

• кто пользователь;
• где и когда он использует интерфейс;
• что он хочет сделать;
• какой главный объект на экране;
• какое главное действие;
• как часто действие повторяется;
• насколько действие рискованное;
• что должно быть понятно за 3 секунды;
• какой desired feeling: доверие, скорость, премиальность, спокойствие, азарт, технологичность;
• какая метрика качества: time-to-action, conversion, error rate, support load, retention, INP.

Если рамки нет, дизайн почти всегда превращается в шаблон.

3. Иерархия важнее украшения

На каждом screen/state должен быть один главный фокус.

Правила:

• один primary action в контексте;
• вторичные действия визуально тише;
• destructive action отделять;
• цвет акцента использовать редко;
• если выделено все, не выделено ничего;
• экран должен читаться прищуром до чтения текста.

Проверки:

• blur/squint test;
• grayscale test;
• 3-second test;
• keyboard focus order.

4. Spacing и группировка

Отступы выражают смысл:

внутри элемента < внутри группы < между группами < между секциями

Ориентир:

• 4 px: icon + label, micro gap;
• 8 px: поля внутри control;
• 12-16 px: элементы одной группы;
• 24 px: разделение групп;
• 32-40 px: крупные блоки;
• 48-64 px: секции.

Правила:

• label ближе к своему input, чем к соседнему;
• action ближе к объекту, который меняет;
• не лечить плохую группировку цветом;
• не делать card для каждой группы;
• card нужна, когда есть смысловая рамка или повторяемый item.

5. Цвет

Цвет в UI - это роль, а не украшение.

Минимальные роли:

• background;
• surface;
• text;
• muted text;
• border;
• primary action;
• selection;
• focus;
• success;
• warning;
• danger;
• info;
• disabled.

60/30/10 использовать только как sanity check:

60% спокойная база
30% структура/поддержка
10% акцент/действие/статус

Контраст важнее палитры:

• обычный текст: минимум 4.5:1;
• крупный текст: минимум 3:1;
• UI components/иконки: минимум 3:1.

Цвет не должен быть единственным носителем смысла.

6. Типографика

Интерфейс читают, а не рассматривают.

Правила:

• 3-5 текстовых ролей достаточно для большинства UI;
• body должен быть читаемым, не декоративным;
• display text использовать редко;
• line-height body примерно 1.4-1.6;
• длинный текст не растягивать на всю ширину;
• числа в таблицах выравнивать и делать сканируемыми;
• labels важнее placeholder.

7. Поведение интерфейса

Каждое действие должно иметь цепочку:

before -> immediate feedback -> processing state -> result -> recovery

Обязательные состояния:

• default;
• hover, где есть pointer;
• focus-visible;
• pressed/active;
• disabled;
• loading/submitting;
• success/saved;
• error/retry;
• empty;
• offline/sync, если данные сетевые;
• permission, если нужен доступ.

Если пользователь нажал кнопку и за 100-200 мс ничего не увидел, интерфейс ощущается сломанным.

8. Loading, empty, error

Loading:

• skeleton для известной структуры контента;
• spinner только для короткого неопределенного ожидания;
• progress bar для измеримого процесса;
• streaming/partial results для AI, поиска, генерации, аналитики.

Empty state:

• first use;
• no results;
• filtered empty;
• permission empty;
• offline empty;
• system issue.

Не смешивать эти пустоты одним текстом.

Error:

• рядом с проблемным полем;
• объясняет что случилось;
• говорит как исправить;
• не очищает введенное;
• не обвиняет пользователя;
• дает retry/recovery.

Плохая ошибка: Что-то пошло не так.

9. Inline actions

Правило:

action belongs near the object it changes

Inline правильно:

• rename рядом с названием;
• copy/share рядом со значением;
• row actions в таблице;
• validation рядом с field;
• undo рядом с result/toast;
• save state рядом с редактируемым блоком.

Отдельная кнопка/toolbar/dialog нужны:

• для глобального действия;
• для рискованного действия;
• для bulk action;
• для сложного multi-step flow;
• когда действие должно быть очень заметным новичку.

10. Формы

Форма - это разговор, а не список полей.

Правила:

• visible labels;
• related fields группировать;
• helper text рядом с решением;
• validation не слишком рано;
• error summary для длинных форм;
• inline error рядом с field;
• правильная mobile keyboard;
• не очищать поля после ошибки;
• autosave/draft для длинного ввода;
• рискованные действия подтверждать или давать undo.

11. Навигация, поиск, фильтры

Разделять:

• navigation = куда идти;
• search = найти известное/примерное;
• filter = сузить набор;
• sort = изменить порядок;
• tabs = переключить view;
• chips = показать активные ограничения.

Search не должен быть костылем плохой информационной архитектуры.

Для поиска нужны:

• scope;
• suggestions;
• recent searches, если уместно;
• no results state;
• clear/reset;
• tokens/chips для сложных фильтров.

12. Графика

Графика должна иметь работу.

3D          -> объект, материал, тактильность, вау
изометрия  -> система, процесс, связи
фото       -> реальность, доверие, люди, место
скриншот   -> доказательство продукта
пиктограмма -> быстрый концепт
motion     -> состояние, переход, feedback

Нельзя:

• generic 3D blob без смысла;
• изометрические человечки ради SaaS-декора;
• скрывать слабый продукт красивым mockup;
• смешивать разные asset styles без системы;
• ставить графику выше ясности.

13. Стиль

Стиль выбирать по задаче, а не по названию.

Оси:

• utility vs expressive;
• dense vs airy;
• platform-native vs branded;
• content-first vs control-first;
• trust-first vs excitement-first;
• human/tactile vs technical/precise.

Правило риска:

риск выше -> интерфейс спокойнее, паттерны знакомее, copy прямее
риск ниже -> можно больше выразительности и эксперимента

Marketing surface может быть смелым. Core workflow должен быть ясным.

13.1 Визуальная выразительность и глубина

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

Мера берётся из раздела 13: маркетинговая поверхность может быть выразительной, ядро рабочего процесса остаётся спокойным.

Приёмы, числа и чеклист «не пресно» — в visual-craft-premium.md. Там же разобрано, почему слой не противоречит правилам этого файла: глубина даётся светом, а не вложением рамок и не карточкой в карточке.

14. AI UI

AI-фича должна быть workflow, а не магическая textarea.

Обязательные состояния:

• capability intro;
• input;
• retrieving/thinking;
• generating/streaming;
• tool call;
• partial result;
• draft;
• confidence/provenance, где нужна точность;
• edit;
• accept/apply;
• reject/regenerate;
• undo;
• failure/retry;
• privacy/data note.

Chat не всегда лучший интерфейс. Часто нужен hybrid UI: prompt + controls + preview + apply.

15. Accessibility

Accessibility - не финальный чеклист, а базовое ограничение.

Минимум:

• semantic HTML/native controls;
• keyboard navigation;
• visible focus;
• contrast;
• target size;
• labels;
• screen reader names;
• error identification;
• reduced motion;
• responsive reflow/zoom;
• color not alone.

Если component не доступен, component не готов.

16. Design system

Design system - не UI-kit, а язык решений.

Фиксировать:

• principles;
• color tokens;
• type tokens;
• spacing tokens;
• radius/elevation/motion tokens;
• component anatomy;
• variants;
• states;
• accessibility rules;
• examples;
• anti-examples;
• code mapping.

Имена токенов должны быть семантическими:

color.text.danger, not red-500
space.group.md, not 24px-everywhere

17. Tailwind / shadcn / UI kits

Framework не является стилем.

Tailwind = способ писать CSS
shadcn/Tailwind UI = заготовки
design system = свои решения

Плохо:

• дефолтные карточки;
• серые borders everywhere;
• random rounded-xl;
• одинаковые shadows;
• component soup;
• arbitrary values без системы;
• "нейронка сделала dashboard".

Хорошо:

• semantic tokens;
• свой layer компонентов;
• ограниченная spacing/type/color scale;
• documented states;
• переработанный бренд;
• real product flows.

18. Антипаттерны

Избегать:

• card soup;
• landing-page design inside dashboard;
• hover-only actions;
• icon-only mystery;
• generic SaaS isometry;
• dark premium trap;
• expressive everywhere;
• AI sparkle вместо AI UX;
• placeholder product screenshots;
• empty/error/loading forgotten;
• filters as tabs;
• search as excuse for bad IA;
• dashboard as chart cemetery;
• "красиво, но непонятно что делать".

19. Быстрый чеклист ревью

Перед сдачей спросить:

• пользователь и контекст ясны?
• главный объект понятен?
• главное действие видно?
• hierarchy читается за 3 секунды?
• spacing показывает связи?
• цвет имеет роли?
• текст читается?
• есть loading/empty/error/success?
• есть recovery/undo/retry?
• опасные действия отделены?
• mobile/focus/keyboard работают?
• доступность не сломана?
• графика выполняет работу?
• бренд помогает, а не мешает?
• UI не похож на дефолтный kit?
• продукт можно объяснить через живой сценарий?

20. Как ставить задачу на интерфейс

ЦА:
Контекст:
Главная задача:
Главный объект:
Частота:
Риск:
Desired feeling:
Primary action:
Secondary actions:
Inline actions:
Global actions:
Состояния: loading / empty / error / success / offline / permission / AI / saved
Данные: реальные/примерные, длинные строки, пустые наборы
Ограничения: mobile, accessibility, platform, performance
Метрика качества:
Референсы по похожему сценарию:
Анти-референсы:

Если этого нет, нельзя требовать хороший UI.