Single interface language

1) What is a single interface language and why is it needed

The Unified Interface Language (NEI) is a common system of concepts, visual rules, and interactions shared by designers, engineers, analysts, and content authors.

• Consistency - Same components and terms across products and teams.
• Speed: quick builds, fewer holivars, faster onboarding.
• Quality: consistent UX patterns, availability "by default."
• Scalability: safe evolution without breaking up into a "UI zoo."

2) Layers of a single language

1. Tokens (color, typography, dimensions, shadows, indents, radii, animations).
2. Components (buttons, input fields, tables, graphs, modals, toasts, tabs).
3. Patterns (forms, validation, step-by-step wizards, lists/tables, notifications).
4. Content (micro-copywriting, terminology, error messages).
5. Iconography and illustrations (family, style, dimensions and lines).
6. Availability and i18n/RTL (A11y rules, translability, locales).
7. Processes (versions, guides, reviews, linters, showcases and examples).

3) Design tokens (the basis of expressiveness)

Tokens are named values that are reused in all products.

3. 1 Token structure (example)

json
{
"color": {
"bg": { "base": "#FFFFFF", "subtle": "#F7F8FA" },
"fg": { "primary": "#11131A", "muted": "#656D76" },
"accent": { "primary": "#2F6BFF", "warning": "#FF9F1A", "critical": "#E53935", "success": "#2EAE60" }
},
"space": { "xs": 4, "sm": 8, "md": 12, "lg": 16, "xl": 24, "2xl": 32 },
"radius": { "sm": 8, "md": 12, "lg": 16, "pill": 1000 },
"shadow": { "sm": "0 1px 2px rgba(0,0,0,.08)", "md": "0 4px 12px rgba(0,0,0,.10)" },
"font": { "family": "Inter, system-ui", "size": { "sm": 12, "md": 14, "lg": 16, "xl": 20 } },
"motion": { "duration": { "fast": 120, "base": 200, "slow": 320 }, "curve": { "inout": "ease-in-out" } }
}

3. 2 Naming tokens

From general to particular: 'color. accent. primary`, не `primaryBlue`.
Without being tied to a brand in naming (brand is a topic, not a token name).
Gradations: 'fg. muted`, `fg. primary`, `fg. inverse`. Do not encode brightness in the name ('blue500') without a system.

3. 3 Theme tokens

Light, dark, contrasting: change values, not names.
Themes - override layer, UI remains consistent.

4) Components: Contract, States, Availability

Component = Visual + Behavior + Props Contract + A11y.

4. 1 Button Contract Example

ts type ButtonProps = {
kind: "primary"      "secondary"      "tertiary"      "danger";
size: "sm"      "md"      "lg";
icon?: "plus"      "download"      "trash";
disabled?: boolean;
loading?: boolean;
ariaLabel?: string;
onClick?: (e: MouseEvent) => void;
};

States: 'default/hover/active/focus/disabled/loading'.
Availability: focus ring, target sizes ≥ 40-48 px, 'aria-pressed' for toggle.

4. 2 Component guarantees

Stable dimensions (line-height, paddings).
Accessibility out of the box (roles/aria, keyboard, contrast).
Invariants: error inside the field always at the bottom and with 'aria-descripedby'.

5) UX patterns (repeatable logic)

Forms: left/top label, placeholder ≠ label, side by side + summary errors, input masks and prompts.
Modals: one main CTA, 'Esc' closes, focus trap, focus return.
Tables/lists: sorting, sticky header, pagination, export.
Filters: explicit Apply button, reset, saved presets.
Notifications: toast ≤ 3-5 s, pause at focus, 'role = "status/alert"'.
Dashboards: top insights → context → graphics → CTA.

6) Common terminology and micro-copywriting

6. 1 Glossary

Maintain a single glossary of business and UX terms. Each interface article references it.
For doublets - choose one word ("wallet" vs "balance"), the second - as a synonym in the search.

6. 2 Rules of text

Briefly and on the case; avoid jargon.

Errors - explain what to do: "Specify the date in the format YYYY-MM-DD."

Headings are nouns; buttons - verbs ("Save," "Cancel").
Consistent units: date/time in UTC or locale, currencies with code (EUR, USD).

7) Iconography and illustrations

The family is isomorphic: single angle, line thickness, grid 24 × 24.
Statuses and semantics: color - secondary; shape/icon + text - primary.
Scaling: pictograms do not "float" in different densities (1 ×/2 ×/3 ×).

8) Availability (A11y) and localization (i18n/RTL)

Components undergo WCAG AA: contrast, keyboard navigation, focus, 'prefers-reduced-motion'.
Translated strings - in resources, not in code. Placeholders and number/date format are localizable.
RTL: mirroring icons, correct Tab order, DnD logic from the keyboard.

9) Numbers, dates, currencies and formats

Dates/time: ISO-8601, true time point - UTC; user - locale.
Currency: minor units/decimal strings; always specify a code (for example, "€12.34" or "12. 34 EUR" - by locale).
Interest: '12.3%' and points' + 1.2 pp'clearly distinguish.
Rounding: to significant digits; "k/m" for large numbers.

10) Governance: Roles, Artifacts, Channels

Design Language Council (DLC): Token/component owners, RFC claims.

• Content Center (Figma/Code) + Live Catalog with Examples.
• Documentation: guides, patterns, A11y, content guide.
• Changelog with dates, levels (added/changed/deleted/removed/fixed).
• Channels: weekly design sink, Slack channel, implementation showcases.

11) Versioning and evolution

SemVer for component package: 'MAJOR. MINOR. PATCH`.
MINOR - additive: new tokens, props with defaults, new components.
MAJOR - breaking: removing props, changing semantics → migration guides.
Decrements: warnings, window ≥ 90 days, compatibility flags.

12) Linters and automatic checks

UI-linter: forbidden colors outside of tokens, anti-patterns (button-diva, disabled outline).
A11y-checks: contrast, roles/aria, focus, keyboard.
i18n-linter: "hard" lines in the code, incorrect placeholders.
Screenshot tests: visual regressions of components.
Visualization API contracts (if any): data types, ranges, signatures.

13) Component showcase (storybook/sandbox)

Live examples with props controls, code, states, A11y-checker.
"Recipes": registration form, step 3 wizard, table + filters, modalka + toast.
"Sandbox of locales": switching language/formats/RTL.

14) Naming and structure patterns

14. 1 Components (BEM/semantics, CSS example)

.btn/basic/
.btn--primary/view/
.btn--danger
.btn--lg/size/
.btn __ icon/part/

In the code - monotonous names of props: 'size', 'kind', 'disabled', 'onClick'.

14. 2 Library file structure

/tokens
/components
/button
/input
/modal
/patterns
/docs
/changelog

15) Anti-patterns

"Free" colors/indents outside of tokens.

Duplicate components: "ButtonV2," "PrimaryButtonNew."

Placeholder as the only field label.
Disabling outline and div-buttons.
Unpredictable hover/active/disabled.
Transliterated terms instead of normal translation.
Lack of migration guides during updates.

16) Single Language Quality Metrics

Coverage - the proportion of screens using the content library.
Consistency Index: Reuse tokens vs "manual" styles.
A11y Pass Rate - percentage of components passing WCAG AA.
Defect Escape: UI/content defects in 1k commit sales.
Time-to-Ship - time to implement a typical screen before/after DLS.
Adoption: DAU showcases, PR number with components/patterns.

17) Screen checklist

• Used tokens (color/indents/radii), not hard values.
• Components from the library; custom - RFC only.
• Accessibility: keyboard/focus/contrast/roles/aria.
• Units: dates/currencies/percentages - per format guide.
• Microcopies: buttons = verbs, errors = action to correct.
• Locales/RTL do not break the layout.
• States: loading/empty/error are provided.
• Visual regression tests updated.

18) Implementation plan (3 iterations)

Iteration 1 - Foundation (2-3 weeks)

Tokens (color/typography/spacing/motion), basic components (Button, Input, Select, Tooltip, Modal), content guide (tone, labels, errors).
Showcase (storybook) and A11y-checker, token linter.

Iteration 2 - Patterns and Localization (3-4 weeks)

Patterns of forms/tables/filters, icon pack 24 × 24, RTL/i18n sandbox, rules for numbers/dates/currencies.
SemVer, changelog, RFC/migration process, autotests (visual + A11y).

Iteration 3 - Scale and Evolution (Continuous)

Compositional components (Wizard, DataGrid, Chart primitives), temization (light/dark/contrast), quality metrics reports, regular UX audits.

19) Mini-FAQ

Is it necessary to "all at once"?
No, it isn't. Start with tokens and base components, then add patterns and processes.

How to convince teams to use the YEI?
Show the winnings: speed, fewer defects, ready-made screen recipes and A11y out of the box.

What to do with legacy screens?
Migration plan, bridge styles through tokens, priority screens - first.

Total

A single interface language is not only a component library. This is a system of rules and processes, where tokens set expressiveness, components - behavior and availability, patterns - repeatability of decisions, and governance and metrics - sustainable evolution. Make your language clear, verifiable and extensible - and your products will look and work uniformly, quickly and reliably.