Skip to main content
jb
Design System Self-Assessment

Grade your design system …like a report card.

Ten minutes, five subjects, thirty-two questions. An honest snapshot of where your system shines and where it’s quietly burning your team out.

~10 minutes No signup Stays on your device
Start scoring How it works

Briley & Co. Academy

Design System Report Card

Term: ongoing · Student: your team

  • 01 · Component Consistency —
  • 02 · Accessibility —
  • 03 · Token Architecture —
  • 04 · Documentation —
  • 05 · Handoff Process —

Final grade

—/64

let’s find out!

no wrong answers
the rules of the game

How it works

1

Answer honestly

For each prompt, pick No, Partial, or Yes. Nobody’s grading you.

2

Watch the score

Subject grades appear live. The floating badge tracks your running total as you go.

3

Read the report

Finish every row and a written report card appears with what to tackle first, and what to leave alone.

teacher’s grading key

0

No

Not addressed yet.

1

Partial

Partially in place.

2

Yes

Working well.

total score so far

0/64

Questions answered

0/32

01 · Component consistency
—

Component consistency

Are the pieces of your UI actually the same pieces, or are there six buttons wearing the same trench coat?

01. Similar UI patterns (buttons, inputs, modals) are built as shared components, not duplicated across the codebase.

02. Component APIs (props, slots, events) follow a consistent naming convention across the library.

03. Visual decisions (spacing, color, border radius) reference tokens, not hardcoded values inside components.

04. Components render consistently across the browsers and viewports your product supports.

05. One-off components that duplicate an existing shared component don’t exist in the codebase.

06. Deprecated components have a documented migration path and are not mixed with current components in production.

02 · Accessibility
—

Accessibility

Not a feature, not a checklist. The subject that tells you whether your system is architecture or wallpaper.

01. Every interactive component (buttons, links, form controls) is fully operable with a keyboard alone.

02. All form inputs have visible, programmatically associated labels.

03. Focusable elements have a clearly visible focus indicator that meets WCAG 2.1 AA contrast requirements.

04. Color is never used as the only means of conveying information (errors, statuses, required fields).

05. Components that control visibility (modals, drawers, tooltips) trap focus correctly and return focus on close.

06. Informative images and icons have descriptive alt text, and purely decorative elements are hidden from assistive technology.

07. Text and interactive elements meet WCAG 2.1 AA contrast ratios (4.5:1 for text, 3:1 for UI components).

08. Dynamic content updates (alerts, notifications, loading states) are announced to screen readers.

03 · Token architecture
—

Token architecture

The quiet plumbing underneath everything. Good tokens make redesigns a rename, not a rewrite.

01. Tokens are defined in a single source of truth (design tool, JSON file, or equivalent) and synced to code.

02. Token names follow a consistent, predictable pattern (for example: category/property/variant) with no abbreviations or ambiguity.

03. Semantic tokens (for example: color.text.primary) reference primitive tokens (for example: color.gray.900), not raw values.

04. Token names describe intent, not value. For example, color.brand-primary rather than color.blue.

05. Tokens cover every design decision that varies across themes, modes, or brands.

06. Every component references tokens rather than redefining their values.

04 · Documentation
—

Documentation

The delivery, not the afterthought. If it isn’t documented, it doesn’t really exist for the next engineer.

01. Every component has a working example showing its most common use case.

02. Props, slots, and events are documented with types and plain-language descriptions.

03. Components with common misuse patterns or non-obvious behavior have explicit do/don’t guidance.

04. Documentation is updated as part of the development workflow, not added retroactively.

05. A getting-started guide lets a new developer install and use the library without asking anyone for help.

06. Keyboard interactions, ARIA attributes, and screen reader behavior are documented per component.

05 · Handoff process
—

Handoff process

The seam between design and code. When it’s working, nobody talks about it. When it isn’t, nobody talks about anything else.

01. Design files use components from the shared library, not custom one-offs that don’t exist in code.

02. Designers and developers use the same token names to describe design decisions.

03. New components follow a documented process from design to code.

04. Developers don’t rebuild components that already exist in the library.

05. A clear owner (team or individual) is responsible for maintaining and evolving the design system.

06. The design system has a versioning and changelog process so consumers know what changed between releases.

scroll for your final report →

teacher's report

Keep going — answer every question to unlock your report.

Final score

0/64

Overall grade

—

Pick a choice for every question and a personalized writeup will appear here with the two things I'd prioritize first.

This scorecard is also a work sample.

It’s built like everything else here: accessible radio groups, live scoring, no frameworks, the same tokens. Whatever your number says, if you want to compare notes — or you’re hiring someone who builds tools like this — get in touch.

Get in touch Connect on LinkedIn