What gets noticed, and what carries the weight
Reviews tend to cover the top layer. It is visible, it is quick to check, and it produces a clean report. The layer underneath is where products fail in use.
These three diagrams set out both layers for accessibility, design systems and user experience. Use them to check what your last review actually covered.
The UX iceberg
The screens are the part of the work that is easiest to review, and the smallest part of what determines the outcome.
6 visible
15 underneath
On the surface
Visible, quick to check, easy to sign off.
- The screensLayout, hierarchy and visual polish.
- The prototypeIt clicks through convincingly.
- PersonasA deck of them exists.
- Journey mapPrinted, on a wall.
- Usability testFive participants, one round, near the end.
- Design system usageThe screens use the components.
In the craft
Design work that never shows up in a screenshot.
- Problem framingWhether this is the problem worth solving, established before anything is drawn.
- Information architectureFindability and mental models, rather than a tidier menu.
- Content designThe words carry the flow, and are designed alongside it rather than filled in afterwards.
- StatesEmpty, first run, error, offline, slow and partial, designed rather than discovered in production.
- PerformanceLatency and stability treated as part of the experience, not as an engineering concern.
In the evidence
What separates a decision from a preference.
- Continuous access to usersA standing recruitment channel, rather than a scramble at the start of each project.
- Research that moves the roadmapFindings arriving early enough to change a decision that has not been made yet.
- Behavioural dataWhat people do, held against what they say they do.
- InstrumentationA measure defined before release and tied to the decision it is meant to inform.
- Service and back stageThe operations, policy and staff work that the interface only reports on.
In the organisation
Where good design work is overruled.
- Decision rightsWhether design can say no, and to whom.
- A seat before the commitmentInvolved when the problem is chosen, not after the date has been promised.
- Debt ownershipNamed owners for the flows nobody wants.
- Research capacityFunded time, rather than research done in the gaps between delivery.
- A shared bar for qualityAn agreed definition of good, so that it is not re-argued on every project.
Test it yourself
Name the last roadmap decision that changed because of a research finding, and the date on which it changed.
Reference
ISO 9241-210 human-centred design for interactive systems · ISO 9241-11 usability definitions
The accessibility iceberg
A page can pass every automated check and still be unusable with a screen reader.
6 visible
18 underneath
On the surface
Visible, quick to check, easy to sign off.
- Colour contrastThe contrast checker returns a pass.
- Alt textImages carry an alt attribute.
- Keyboard focusTab moves through the page in order.
- HeadingsThere is an H1 and a heading structure.
- Form labelsEvery field has a visible label.
- Automated scanThe tool reports zero errors.
In the build
Decided in code and in component specifications.
- Semantic structureLandmarks, roles and native elements used for what they are, before any ARIA is added.
- Accessible namesWhat the screen reader announces matches what the voice user says out loud.
- Focus managementFocus moves where the interaction moved it, and never lands on nothing.
- State and changeLive regions announce updates rather than rendering them silently.
- Dialogs and overlaysFocus trapped, background inert, focus returned on close.
- Error recoveryErrors are announced, described in text and correctable without starting again.
- Composite widgetsTabs, comboboxes, trees and carousels built to the ARIA Authoring Practices rather than from scratch.
In the conditions
Real people, real devices, real content.
- User preferencesReduced motion, forced colours, 200 per cent text scaling and 400 per cent zoom all survive.
- Assistive technology diversityTested on more than one screen reader, and on the browser pairings people actually use.
- Mobile and touchTarget size, orientation, gesture alternatives and mobile screen reader behaviour.
- Third-party componentsThe embedded widget, the payment iframe and the chat bubble you did not write.
- DocumentsTagged PDFs, reading order, and exports that leave the product accessible.
- Language and directionLanguage attributes, right-to-left support, and translations that keep their semantics.
In the organisation
Where accessibility either holds or quietly lapses.
- Testing with disabled peoplePaid participants and real tasks, rather than a colleague guessing with the screen switched off.
- Accessibility at design stageSettled in wireframes and component specifications, not filed later as QA defects.
- Regression preventionComponent-level ownership and automated checks that block a merge.
- Procurement and legalEN 301 549 evidence, an accessibility statement, and a conformance report that survives scrutiny.
- Funded ownershipA named owner with capacity, rather than the one person who happens to care.
Test it yourself
Ask someone who uses a screen reader every day to complete your primary task, unaided, on their own device and with their own settings. Watch without helping.
Reference
WCAG 2.2 AA · EN 301 549 · Directive (EU) 2019/882 · ARIA Authoring Practices Guide
The design system iceberg
A component library is an artefact. A design system is an agreement about how work gets made.
6 visible
16 underneath
On the surface
Visible, quick to check, easy to sign off.
- Component libraryA Figma file with components in it.
- Colour and type tokensThe palette has names.
- Documentation siteThere is a page for each component.
- Icon setOne consistent family.
- Naming conventionThings are named the same way.
- It looks currentThe system matches the latest brand work.
In the components
What each component owes its consumer.
- States and edge casesEmpty, loading, error, overflow, long strings and right-to-left, all specified.
- Accessibility shipped insideRoles, focus order and keyboard behaviour arrive with the component, not after it.
- Design and code parityThe Figma component and the coded component behave the same way under the same properties.
- Composition rulesWhat may be slotted, nested or overridden, stated rather than assumed.
- Responsive behaviourDefined once at component level, rather than re-decided by each consuming team.
In the contract
The part teams plan their work around.
- Token architecturePrimitive, semantic and component layers, rather than one flat list of hex values.
- ThemingLight, dark, density and sub-brands without forking the codebase.
- VersioningSemantic versions, changelogs and a deprecation window people can plan against.
- Breaking-change processHow a change reaches every consumer, and who absorbs the cost of adopting it.
- Migration pathWhat happens to the screens built before the system existed.
In the organisation
Where systems are abandoned rather than replaced.
- Contribution modelWho may propose a change, who decides, and how long a decision takes.
- Decision rightsWhat happens when a product team wants an exception, and who is allowed to grant one.
- Adoption measuredThe share of shipped screens actually using the system, tracked over time.
- Support channelA place where questions get answered the same week.
- Funded teamA roadmap and headcount, rather than evenings and goodwill.
- Retirement of the old libraryFunded, dated and completed, rather than left running in parallel indefinitely.
Test it yourself
Take the last screen you shipped. Count how many of its components came from the system, and how many were rebuilt locally. Then ask the team why.
Reference
There is no standard here. The nearest references are the W3C Design Tokens Community Group format and whatever your own contribution model actually says.