skip to content

A utility billing portal's shared usage-meter spec is one default mockup with pixel redlines; what would you add before anyone builds it, and why?

level: seniorimportance: should knowfreq 32%

answer

  1. what happens over budget
  2. states beyond the happy path
  3. value text, not only percent
  4. meter is not a progress bar
  5. color is not the only cue

basics

~20 s

Add anatomy, variants, a full state list including over budget, loading and no data, behaviour at and beyond the maximum, content rules for units and rounding, token-based redlines, and accessibility notes: the meter pattern, its name, readable value text and a non-color cue for status.

solid answer

~40 s

The mockup answers only what the meter looks like on a good day. I would add **anatomy** (label, track, fill, budget marker, value text) and **variants** (standard, compact). Then **states**: normal, near budget, over budget, loading, no data and error. **Behaviour** must say what happens past the budget, because WAI-ARIA 1.2 says a meter's current value must not exceed its maximum: cap the fill and state the overage in text, or define the range differently. **Content rules** set units, rounding and locale formatting. **Redlines** become token references. **Accessibility notes** name the Authoring Practices meter pattern, the visible label as its name, value text that reads in kilowatt-hours rather than only a percentage, a non-color cue for over budget under WCAG 2.2 criterion 1.4.1, and 3:1 contrast for the fill under 1.4.11.

go deeper

for a junior

Recall that a spec needs more than one mockup: named parts, all states and accessibility notes.

for a middle

Explain the meter pattern's rules: a required name, a value within its range, readable value text, and not for progress.

for a senior

Show how you turn a single mockup into a contract, surfacing the over-budget rule, unhappy states and platform-neutral token redlines before build.

for a principal

Decide what minimum a spec must reach before any build starts, and how to enforce it without making contribution too slow to be worth it.

## What the spec currently says In a utility company's billing portal, a shared **usage meter** shows electricity used this month against a budget the customer set. The spec handed to engineering is one mockup of a meter at 60 percent, with pixel measurements. Every other question is left to whoever builds it, on each platform, separately. The review is about finding those questions before three teams answer them three ways. ## Structure the spec is missing - **Anatomy**: label, track, fill, budget marker, value text, optional helper text. Named parts give design, code and documentation one vocabulary. - **Variants**: standard and compact; with or without helper text. - **Redlines as token references**: the pixel numbers are true in one theme, density and platform only; token references stay true when those change. ## States beyond the happy path | State | What the spec must decide | |---|---| | Normal | the baseline look | | Near budget | the threshold, and how it is signalled | | Over budget | how the fill, marker and text show it | | Loading | placeholder look while usage is fetched | | No data | new account or meter not yet read | | Error | usage could not be retrieved | The unhappy states are exactly the ones customers call support about. ## Behaviour at and beyond the maximum This is the question the mockup hides. Usage can exceed the budget. **WAI-ARIA 1.2** says a meter's current value must not fall below its minimum or exceed its maximum, so the spec must pick a rule, for example: 1. cap the fill at the maximum and state the overage in the value text, such as 430 of 400 kilowatt-hours used, 30 over budget; or 2. define the range so the maximum is above the budget, with the budget shown as a marker inside it. The spec should also cover rounding, what happens when the budget is zero or unset, and whether the fill animates when the value updates. ## Content rules - Units spelled consistently (kilowatt-hours or its abbreviation, per the content style guide). - Rounding and number formatting per locale. - Label length limits and truncation behaviour in the compact variant. - The wording of each state's text, especially over budget and no data. ## Accessibility notes - **Pattern**: the Authoring Practices **meter** pattern, for a numeric value within a defined range. It is **not** for progress; showing an upload's percent completion calls for a progress bar instead. - **Name**: the meter requires an accessible name; the visible label provides it. - **Value text**: assistive technologies often present a meter's value as a percentage, so the spec gives a readable value text in real units. - **Keyboard**: not applicable for a display-only meter, so it takes no focus stop unless it becomes interactive. - **Color**: WCAG 2.2 criterion **1.4.1 Use of Color**, level A, means over budget cannot be signalled by a red fill alone; add text or an icon. - **Contrast**: criterion **1.4.11 Non-text Contrast**, level AA, asks at least 3:1 against adjacent colors for graphics needed to understand the content, which includes the fill against the track. ## Why before building Every item above is cheap to decide in a document and expensive to reconcile once web and native teams have each shipped their own answer. A senior reviewer's job is to turn one mockup into a contract two platform teams could build identically from.

  • Why not just let the meter's value exceed its maximum when the customer is over budget?
    WAI-ARIA 1.2 says a meter's current value must not exceed its maximum, so assistive technologies may report a nonsensical or clamped value. The spec should cap the fill and put the overage in the value text, or set the range so the budget is a marker below the maximum.
  • The team wants the same component to show a bill upload's percent complete. Should the spec allow it?
    No. The Authoring Practices meter pattern says a meter should not indicate progress; that is what a progress bar is for. Progress has a different meaning, completion over time, and a different expected announcement, so it deserves its own component or variant with its own semantics.

saying these in an interview costs you the question

  • A red fill alone is enough to show the customer is over budget.
  • A meter and a progress bar are interchangeable components.
  • The value can simply exceed the maximum when usage is over budget.
  • A percentage is always a clear enough value for assistive technology.
  • Unhappy states can be designed after the first release.