The front-end and UX diligence rubric
The instrument itself. Four axes, nineteen questions, one colour each. Open this page when you are scoring; your filled-in copy lives at learning/ux-diligence/RUBRIC.md.
What this covers, and what it does not
This scores the front-end and UX half of a technical workstream. It does not cover back-end architecture, security testing, data, IP, team, commercial, financial or legal diligence. Those are other people’s workstreams and this page has nothing useful to say about them. Print that sentence on the cover of anything you produce from this rubric — a scope statement is what stops a reader treating four axes as a verdict on the whole company.
The four marks
Every question gets exactly one mark. No partial credit, no “amber-green”, no scores out of ten — a number implies a precision the evidence does not support, and it invites averaging, which is how a single red gets diluted into a comfortable overall seven.
- Green
- No remediation work is implied. Not “good” — simply nothing the buyer has to fund.
- Amber
- Remediation is implied and it is bounded. You can name the work and put weeks on it.
- Red
- Remediation is implied and it is either large or its size is genuinely unknown. Red is not a judgement of quality; it is a claim that this line will consume budget.
- Not assessed
- The evidence was not obtainable in the time and access actually granted. This is a distinct mark and must never be quietly rounded into amber. A page with six “not assessed” marks is telling the reader something true and important about the access you were given.
The axes
UX maturity
Does anyone here know what their users do?
Every question below is a proxy. You are not measuring how good the design is — taste is not a diligence finding. You are measuring whether the organisation has a mechanism for finding out when it is wrong, because a company without one will keep being wrong after the deal closes.
1.1Research cadence — is there a repeating mechanism for learning what users do?
- Green
- A named cadence you can point at: scheduled sessions, a research repository, findings referenced in roadmap documents.
- Amber
- Research happens, driven by individuals rather than a mechanism — it exists when someone champions it and stops when they leave.
- Red
- No mechanism, and no one can name the last time a user was observed. Product decisions are sourced from sales escalations.
1.2Does a design system exist as shipped code, not only as a Figma library?
- Green
- A versioned package other teams install, with a changelog and more than one consuming application.
- Amber
- A component library exists in one app, or a Figma library exists with no code counterpart. Two half-systems that disagree also score amber.
- Red
- Neither. Components are copied between screens by hand.
1.3Adoption — what share of the product actually goes through it?
- Green
- Adoption is measured, the measure is published internally, and the trend is up.
- Amber
- The system exists and adoption is asserted but never measured.
- Red
- Adoption is measured and low, or new work is visibly bypassing the system.
1.4Consistency debt — how many ways does this product do the same thing?
- Green
- One date picker, one table, one empty state, one error pattern, across the surfaces you can reach.
- Amber
- Two eras of interface visibly coexist and the boundary is legible — an older section and a newer one.
- Red
- Three or more eras, or inconsistency inside a single flow.
1.5Accessibility posture — claimed, tested, or neither?
- Green
- A conformance claim naming a standard and a level, backed by a dated report and automated checks in CI.
- Amber
- A claim with no evidence behind it, or automated checks with no manual testing.
- Red
- No claim, no tooling, and obvious failures on the surfaces you can reach.
Front-end technical debt
What will it cost to change this interface?
This axis is deliberately the least subjective one on the page. Every question resolves against a published fact with a date on it — a support window, a compiler flag, a build time — so the score can be defended without an argument about taste. Anything that cannot be resolved that way belongs on a different axis or nowhere.
2.1Framework and version, against the framework’s own published support window.
- Green
- Inside active support, with a visible history of upgrading within a release or two of current.
- Amber
- Inside long-term support but not active, or current-but-stalled with no upgrade in the last year.
- Red
- Past the vendor’s published end-of-life date, or on a framework whose maintainers have stopped publishing one.
2.2Language strictness — is TypeScript on, and is it strict?
- Green
- TypeScript with `strict` enabled and no blanket suppressions at the config level.
- Amber
- TypeScript with `strict` off, or on with wide exclusions — the types exist but do not constrain.
- Red
- No static typing, or types present and systematically defeated.
2.3UI test coverage — does anything guard a refactor?
- Green
- Component and end-to-end tests that run on every change and actually fail when behaviour breaks.
- Amber
- Tests exist and are routinely skipped, quarantined, or so flaky the team ignores red.
- Red
- No automated UI tests. Every change is verified by a human clicking through.
2.4Build and CI feedback time.
- Green
- A developer learns their change is broken in minutes, not after lunch.
- Amber
- Feedback takes long enough that people batch changes to avoid waiting.
- Red
- Feedback is slow enough that the team has stopped trusting it and merges anyway.
2.5Dependency risk — outdated, unmaintained, or single-owner.
- Green
- Automated updates land regularly; no critical path runs through an unmaintained package.
- Amber
- A backlog of outdated dependencies with no known blocker beyond time.
- Red
- A load-bearing dependency is unmaintained, or an upgrade is blocked by a fork nobody can rebase.
2.6Dead code and duplicated components.
- Green
- Removal happens. There is evidence in the history of code being deleted, not only added.
- Amber
- Duplication is known, catalogued, and tolerated for stated reasons.
- Red
- Nobody can say which of the three implementations is the live one.
Agentic readiness
Could an agent ever act inside this product?
This axis is not asking whether the product has AI in it. Almost every product now claims some. It asks whether the preconditions for an agent doing real work exist — a surface to act through, state to read, telemetry to be judged against, and a user expectation that software proposes and a person disposes.
3.1Is there an API surface an agent could act through?
- Green
- A documented, versioned API that covers the actions a user can take in the UI, not only the read paths.
- Amber
- An API exists but is partial, internal-only, or lags the interface — the UI can do things the API cannot.
- Red
- The only way to perform an action is a human operating the interface.
3.2Is application state reachable, or trapped in the view?
- Green
- What the user is looking at can be described as data by something other than the rendering layer.
- Amber
- State is retrievable with effort — scattered across components, but derivable.
- Red
- The screen is the only representation of the state. Nothing outside the DOM knows what the user is doing.
3.3Is there telemetry to measure agent impact against — a before, so there can be an after?
- Green
- Task-level instrumentation already exists: completion, time-to-outcome, error and abandonment rates, per flow.
- Amber
- Page-level analytics only. You can see traffic, not whether anyone finished anything.
- Red
- No product analytics, or analytics that nobody reads and nobody trusts.
3.4Does a review-and-approval concept already exist in the product?
- Green
- Drafts, reviewer queues, confirm-before-send, or an approval role already exist and users already use them.
- Amber
- An approval concept exists in one corner of the product and nowhere else.
- Red
- Every action is immediate and final. Introducing a human-in-the-loop step means changing the user’s mental model, not adding a feature.
Graftability
Could a surface built once elsewhere be installed here at all?
The axis that exists because of the operating model rather than the product. If the plan is to build a capability once and put it into many products, then the cost of installing it is a property of each target, and it is nearly independent of how good that target’s code is. A clean codebase with no theming seam is harder to graft into than a messy one with a good boundary.
4.1Is there a theming seam, or is styling hardcoded?
- Green
- Colour, type and spacing resolve through variables or tokens a new surface could adopt without a rewrite.
- Amber
- A partial token layer with hardcoded values behind it — a new surface would match on some screens and not others.
- Red
- Values are literal and scattered. Matching the host product means reimplementing its look by hand.
4.2Where is the auth and session boundary, and can a new surface sit inside it?
- Green
- A standard identity layer a new surface can join, with a documented way to obtain the acting user and their permissions.
- Amber
- Bespoke session handling that is understood and documented.
- Red
- Bespoke session handling nobody currently on the team designed.
4.3Can any part of the UI be released independently?
- Green
- Independent deploy is a routine event, not an exception someone has to arrange.
- Amber
- One deployable, but frequent — a new surface ships when the app ships, which is often enough not to matter.
- Red
- One deployable, released rarely, with a manual release process. Your surface inherits their release calendar.
4.4Does an embedding or extension point already exist?
- Green
- Plugin points, slots, embedded widgets or an extension API already exist and something already uses them.
- Amber
- A single hardcoded integration exists that could be generalised.
- Red
- Nothing. Every addition is a change to the core application.
How the remediation estimate is built
Weeks, never money. A dollar figure implies a rate card that is not yours to set, and it converts an engineering judgement into a number the reader will treat as priced. Weeks stay in your lane and stay arguable.
- Take only the ambers and reds. Greens imply no work. If a green line generated an estimate, it was not green.
- Group them into workstreams, not questions. Upgrading the framework, enabling strict typing and clearing the dependency backlog are one workstream done by one team in one sequence, and estimating them separately triple-counts the setup.
- State the assumed team for each workstream — how many engineers, at what level, doing this and not other work. Weeks without a team size is not an estimate, it is a mood.
- State the sequencing. What must finish before what. Two eight-week workstreams that cannot run in parallel are sixteen weeks, and the reader cannot tell unless you say.
- Give a range, not a point. A point estimate from partial evidence is a false claim about your own certainty.
- Print the assumptions beside the number. The estimate will be wrong. Printed assumptions are what let someone with more information correct it; a bare number can only be disputed.
- Name what would make it materially worse. One line. This is the sentence a reader remembers six months later when it happens.
Before you hand it over
- Every finding has a cost and a timeline, or it has been deleted. A finding with neither is an observation.
- Every colour has a threshold written down that a second reader would apply the same way.
- The scope statement is on the cover, and the “what I could not see” block is filled in honestly.
- It fits on one page. Everything that did not fit is, by definition, not what the decision turns on.
Every claim on these pages links to its source. If a source looks wrong or out of date, check the resource list and tell your teaching agent — the course is meant to be corrected.