Skip to content

Maturity

How mature root is, assessed against the six-dimension maturity framework published by the Nielsen Norman Group. Maturity is not a ladder in that model: six dimensions move independently, and the shape they make together says more than any average of them does. A system can be excellent at building components and still have nobody using them.

This is a self-assessment, scored by the team that wrote the code, against what this repository can be shown to contain - so it is evidence-led where evidence exists and conservative where it does not. NN/G's own method asks for four to eight evaluators from different roles, and treats the disagreements between them as the point of the exercise; one evaluator produces no disagreements, which is this baseline's main weakness, and the next assessment is where that changes.

Assessed by 1 evaluator. One maintainer, scoring each dimension against what this repository can be shown to contain. NN/G's method asks for four to eight evaluators from different roles and treats the gaps between them as the discussion; a single-evaluator baseline has no gaps to read, which is its main weakness.

Organizational Team Infrastructure Governance Support Adoption
  • This team's baseline
Baseline average

2.5

The mean of the six, and the least useful number on this page: two systems with the same average can have opposite shapes.

Lowest dimensions

2

Organizational alignment, Team effectiveness, Support, Adoption - which is where the roadmap's "what comes next" starts.

Organizational alignment

 2 - Emerging

Where the system sits in the organization: who funds it, who sponsors it, and whether the teams it serves agree that it serves them.

Why that score. Two named contributors and one publisher in the manifests. Nothing in this repository records funded headcount, an executive sponsor or a cross-functional mandate, and a claim that cannot be shown is not scored higher.

What each level looks like
  1. 1 - Absent. Nobody owns the system; it exists because somebody keeps it alive after hours.
  2. 2 - Emerging. A team is doing the work and a few people elsewhere know about it; funding is informal.
  3. 3 - Functional. The system has a named owner, an agreed remit and a budget line that survives a quarter.
  4. 4 - Strong. Product and engineering leadership plan around it, and adopting it is the default choice for new work.
  5. 5 - Exceptional. The system is part of how the organization builds; a reorganization changes who runs it, not whether it runs.

Team effectiveness

 2 - Emerging

Whether the people doing the work can keep doing it: capacity, the mix of skills, how they work together, and whether the pace is survivable.

Why that score. Two contributors, no separate content, accessibility or product roles. The output is sustained - thirty architecture decision records, 549 unit tests, a full gate on every push - but it rests on very few people, which is the definition of a bus factor.

What each level looks like
  1. 1 - Absent. One person, in the gaps of another job.
  2. 2 - Emerging. A small group with no dedicated capacity; design and engineering are covered, the other crafts are not.
  3. 3 - Functional. A standing team with capacity of its own, covering design, engineering and documentation.
  4. 4 - Strong. Cross-functional by design - accessibility, content and product are in the team, not consulted by it.
  5. 5 - Exceptional. The team is stable, sized to its demand, and improves how it works without being asked to.

Infrastructure robustness

 4 - Strong

The system itself: components, tokens, documentation, tooling, and whether quality standards are built into them rather than checked afterwards.

Why that score. Fifty-four components in one package each, foundation pages generated from the token stylesheets, every page on this site rendered from the source it documents, and accessibility, token resolution, README shape and selector shape all gated in the build rather than reviewed by eye. What holds the score below five is that most components are still in progress.

What each level looks like
  1. 1 - Absent. A folder of copied components; no tokens, no documentation.
  2. 2 - Emerging. Components exist and are documented by hand; the documentation drifts from the code.
  3. 3 - Functional. Tokens and components are versioned together and documented; quality is checked by review.
  4. 4 - Strong. Documentation is generated from the source, and accessibility and consistency are gates the build enforces.
  5. 5 - Exceptional. The system is hard to use wrongly: the tooling makes the correct thing the easy thing, everywhere.

Governance

 3 - Functional

How change is decided: who may contribute, what happens to a deviation, how versions are released, and how the next thing is chosen.

Why that score. Release is gated per package by the component's own Ready for Dev flag, structural decisions are recorded as numbered ADRs, and commits are scoped to the package they touch. What is missing is a written contribution model and a way to record a deliberate deviation, so both currently live in someone's head.

What each level looks like
  1. 1 - Absent. Changes land because somebody had time; nothing is recorded.
  2. 2 - Emerging. An informal review; decisions are remembered rather than written.
  3. 3 - Functional. Versioning and release are defined, and the significant decisions are recorded.
  4. 4 - Strong. A published contribution model, a route for deviations, and a prioritization anyone can follow.
  5. 5 - Exceptional. Governance is visible and boring: the process is known, used and rarely argued about.

Support

 2 - Emerging

What a consumer meets when they need help: onboarding, a place to ask, release notes and roadmap, and whether the feedback comes back.

Why that score. The documentation site is the entire support surface - a page per component, Getting Started, a showcase and this roadmap. There is no published changelog yet, no help channel named anywhere in the repository, and no recorded feedback loop from the teams that use it.

What each level looks like
  1. 1 - Absent. Read the source.
  2. 2 - Emerging. Documentation exists; questions are answered ad hoc by whoever wrote the component.
  3. 3 - Functional. Onboarding material, a named channel for questions, and release notes.
  4. 4 - Strong. Advocacy as well as answers: office hours, worked examples, and feedback that reaches the backlog.
  5. 5 - Exceptional. Consumers get unblocked without the team, and what blocked them changes the system.

Adoption

 2 - Emerging

Three things people often merge into one: how much the system is used, how correctly it is used, and whether it is trusted.

Why that score. The packages build and release one per component, and nothing here measures who consumes them: no usage figures, no conformance report, no list of products on the system. This is the dimension this repository knows least about, and the score reflects the absence of evidence rather than evidence of absence.

What each level looks like
  1. 1 - Absent. Nothing uses it.
  2. 2 - Emerging. One or two products use parts of it; nobody measures how much.
  3. 3 - Functional. Usage is measured and growing; the system covers the common cases.
  4. 4 - Strong. Most new work starts from the system, and conformance is measured rather than assumed.
  5. 5 - Exceptional. Teams reach for it first and say so; deviations are rare, deliberate and documented.

How to read the shape

The radar is not a score with six decorations: it is the point of the model. What the shape says is read four ways.

  • Area is the crude reading - how much system there is at all.
  • Symmetry is the useful one. A balanced hexagon is a system whose parts match each other; a spike beside a valley is a system pulling itself apart.
  • Valleys are where the next quarter's work is, whatever the average says.
  • Tension between a peak and the valley beside it is the thing worth arguing about: excellent infrastructure nobody adopts is a different problem from thin infrastructure everybody depends on, and both can average three.

There is no universally correct profile. A system serving one product deliberately scores low on governance; one serving forty cannot afford to.

The six dimensions and the one-to-five scale come from Design-System Maturity: A 6-Dimension Framework, Huei-Hsin Wang, Nielsen Norman Group. The six dimensions and the 1-5 scale are NN/G's. The level descriptions below, the scores and the evidence are this team's own, written against this repository.