UI/UX Rules

Calm, clear, desktop-first pages: overview, then detail, then action.

v1StandaardTerug naar overzicht

Inhoud bewerken

Pas de instructie aan. Opslaan maakt een nieuwe versie en is terug te draaien.

Gelijk aan standaard

Voorbeeld

De huidige opgeslagen inhoud.

Toon inhoud (2.298 tekens)

# UI/UX Rules

How Assembly Hangar pages should look and behave.

The interface must be clear, calm, understandable and easy to use for a
non-technical user, while feeling high-end: compact, confident and polished. A
page is only finished when the user can immediately understand what it is for,
what matters most, what to do next and what can be ignored.

## The problem we are solving
Pages can become too busy: too many cards, boxes, panels and scattered controls.
Every change must actively reduce complexity and improve hierarchy.

## Core UX rule
Overview first. Detail second. Action third.

## Rules
- Desktop-first. Mobile is not the current priority unless specifically requested.
- Keep pages calm, clear and professional; avoid a wall of blocks.
- Do not give every small data point its own card.
- Use progressive disclosure; use detail pages, drawers, tabs or modals where appropriate.
- Use clear hierarchy; one primary action per section.
- Secondary actions should not compete with the main action.
- Dangerous actions must be separated and confirmed.
- Clickable rows and cards must look clickable.
- Empty states explain what is missing and what to do next.
- Loading and error states must be clear.
- Group related information; the page should feel like one coherent product.
- Use the established visual system; reserve non-blue accents for warning, danger or exceptional success.

## Page structure
Every important page should roughly follow:
1. Header - title, short description, primary action, status if relevant.
2. Overview section - key status, important metrics, progress, warnings or blockers.
3. Main content - tables, lists, workflows or modules, grouped logically.
4. Detail access - clickable rows, drawers, modals, detail pages, tabs.
5. Actions - clear primary action, secondary actions, dangerous actions separated.
6. Help / empty / error state - explain missing info and the next step.

## Acceptance criteria for UI work
A UI change is acceptable only if:
- the page is easier to understand;
- hierarchy is clearer;
- the user knows where they are;
- the user knows what the main action is;
- related information is grouped;
- settings are easier to find;
- unnecessary panels are reduced;
- components are consistent;
- existing functionality is not broken.

# UI/UX Rules How Assembly Hangar pages should look and behave. The interface must be clear, calm, understandable and easy to use for a non-technical user, while feeling high-end: compact, confident and polished. A page is only finished when the user can immediately understand what it is for, what matters most, what to do next and what can be ignored. ## The problem we are solving Pages can become too busy: too many cards, boxes, panels and scattered controls. Every change must actively reduce complexity and improve hierarchy. ## Core UX rule Overview first. Detail second. Action third. ## Rules - Desktop-first. Mobile is not the current priority unless specifically requested. - Keep pages calm, clear and professional; avoid a wall of blocks. - Do not give every small data point its own card. - Use progressive disclosure; use detail pages, drawers, tabs or modals where appropriate. - Use clear hierarchy; one primary action per section. - Secondary actions should not compete with the main action. - Dangerous actions must be separated and confirmed. - Clickable rows and cards must look clickable. - Empty states explain what is missing and what to do next. - Loading and error states must be clear. - Group related information; the page should feel like one coherent product. - Use the established visual system; reserve non-blue accents for warning, danger or exceptional success. ## Page structure Every important page should roughly follow: 1. Header - title, short description, primary action, status if relevant. 2. Overview section - key status, important metrics, progress, warnings or blockers. 3. Main content - tables, lists, workflows or modules, grouped logically. 4. Detail access - clickable rows, drawers, modals, detail pages, tabs. 5. Actions - clear primary action, secondary actions, dangerous actions separated. 6. Help / empty / error state - explain missing info and the next step. ## Acceptance criteria for UI work A UI change is acceptable only if: - the page is easier to understand; - hierarchy is clearer; - the user knows where they are; - the user knows what the main action is; - related information is grouped; - settings are easier to find; - unnecessary panels are reduced; - components are consistent; - existing functionality is not broken.