skip to content

A customer-support ticketing tool imports design-system components in most of its files, yet much of its interface still looks hand-built; how do you measure its real UI coverage?

level: seniorimportance: should knowfreq 28%

answer

  1. files are not screens
  2. what users see, weighted
  3. sample key screens and flows
  4. classify regions: system, overridden, local
  5. weight by time on screen

basics

~20 s

Measure coverage as the share of the shipped, rendered interface built from system components, not the share of files importing one: sample key screens, classify regions as system-built, overridden or local, and weight screens by use.

solid answer

~50 s

Import counts measure references, and one icon import makes a file look adopted. **UI coverage** is the share of what users actually see that the system supplies. I'd pick the flows that matter, weighted by use; for a ticketing tool that is the ticket queue, the ticket detail with its reply composer, and search. On each screen I classify every region as system-built, system but overridden, or local. That can be done by hand on sampled screenshots, or automated by having system components mark their rendered output so a pass over the running app counts system-rendered elements against all interactive ones. Then I weight each screen by traffic or time on screen. The gap usually turns out to be a few large local composites, like the composer toolbar, and those become the system team's most valuable targets.

go deeper

for a junior

Recall that coverage means how much of what users see comes from the system, which is different from how many files import it.

for a middle

Explain the units you can count, the three classes of system, overridden and local, and why weighting by use changes the result.

for a senior

Show a repeatable audit plan for a real product: flows chosen by use, a fixed sampling rule, weighting, and a ranked list of the largest local composites to act on.

for a principal

Argue which coverage level is healthy, which interface should legitimately stay local, and how to report coverage without rewarding thin wrappers around local work.

## Why import counts and coverage diverge In a **design system**, **UI coverage** is the share of a product's shipped, rendered interface that is built from system components. It differs from **code usage**, which counts references to system components in source files. The two diverge because references are cheap: a file that imports one system icon counts as using the system, even if every other element in it is hand-built. Take a customer-support ticketing tool whose files mostly import something from the system. The agents' day is spent in three places: the ticket queue, the ticket detail with its reply composer, and search. The queue uses the system's table; but the composer toolbar, the canned-response picker, the ticket timeline and the priority chips are local composites that import only the system's icons and a few tokens. The import metric looks excellent, while the screen agents stare at for hours is largely outside the system. ## Defining the unit you count Coverage needs a unit that reflects what users see. Common choices: - **Regions of a screen**: header, toolbar, list, detail panel, each classified as a whole. - **Interactive elements**: every control a user can operate, classified individually. - **Visual area**: the share of pixels drawn by system components, which favours large surfaces. Each region or element is placed in one of three classes: **system-built**, **system but overridden** (the component is used but its look or behaviour is changed), and **local**. The middle class matters; lumping it into system-built hides the places where the system is present in name only. ## Three ways to measure | Method | How it works | Strength | Weakness | |---|---|---|---| | **Manual screen audit** | Screenshots of sampled screens, regions marked by a reviewer | Catches look-alikes and overrides; works on any platform | Slow; depends on a consistent sampling rule | | **Runtime marking** | System components tag their rendered output; a pass over the running app counts tagged versus untagged elements | Repeatable; can run on every release | Needs a hook in each platform's components; cannot judge overrides visually | | **Import ratio** | Share of files or modules importing the system | Cheap and continuous | Measures references, not interface; overstates | Many teams use the import ratio continuously, runtime marking per release where the platforms allow it, and a manual audit a few times a year to calibrate the other two. ## A measurement plan 1. **Choose the flows** that represent the product, weighted by use: for the ticketing tool, triaging the queue, answering a ticket, and searching past tickets, on both the web agent console and the mobile app. 2. **Fix a sampling rule**, such as the top screens by traffic plus one screen per feature area, so later audits are comparable. 3. **Classify** each region or element into system-built, overridden or local. 4. **Weight** each screen by traffic or time on screen, so the composer counts for more than a rarely opened preferences page. 5. **Rank the gaps** by weighted area: the few local composites that cover the most user time. 6. **Repeat** on a schedule and report the trend per product and platform. ## Turning coverage into action - A large local composite used by one product is a candidate pattern for that team; one repeated across products is evidence for a system addition. - A region that is system but overridden often points to a missing variant, such as a compact density for dense agent screens. - Low coverage on mobile with high coverage on the web suggests the native component set lags, not that the mobile team resists. - Coverage should not be pushed to 100%: some regions, such as a custom data visualisation unique to one product, are legitimately local. ## Pitfalls - Counting only the web console and calling it product coverage. - Classifying an overridden component as system-built because it imports the system. - Auditing whatever screens are convenient, so each audit samples differently and trends are meaningless. - Treating coverage as a target to maximise, which rewards wrapping local work in thin system shells.

  • Why keep a separate class for system components that have been overridden?
    An overridden instance counts as system usage in code, but users may see nothing of the system's look or behaviour, and it will not receive the system's fixes cleanly. Keeping it separate shows where the system is present in name only, and those regions are usually the clearest evidence of a missing variant or a wrong default.
  • Should the system team aim for 100% UI coverage?
    No. Some interface is legitimately product-specific, such as a one-off visualisation or an experimental feature, and forcing it into the system bloats the system with single-use parts. A realistic goal is high coverage of recurring patterns on the most-used flows, with the remaining local regions known and deliberate rather than accidental.
  • How do you make repeated coverage audits comparable?
    Fix the sampling rule, the unit of counting and the classification guide before the first audit, and keep them stable. Record which screens and versions were audited. If the rule must change, re-audit a previous sample with the new rule so the trend line has an overlap rather than a silent break.

saying these in an interview costs you the question

  • The share of files importing the system is the same as UI coverage.
  • An overridden system component should count as fully system-built.
  • Coverage should be pushed to 100%, with no legitimately local interface.
  • Unweighted screen counts reflect what users actually experience.
  • Measuring coverage on the web alone represents the whole product.