Project: implement and review a dispatch queue UI

Last updated: 5 Oct 202619 min read

project

Implement a fictional Dispatch Queue from an approved screen brief and one desktop screenshot. The fixture contains 47 shipments, 6 on hold. Build a status filter, visible-result count, and row list. Deliver a component inventory, interaction contract, responsive state matrix, rendered review packet, and test results. Leave shipment actions outside this change. The screenshot supplies visual evidence but no authority about hidden states, URL persistence, or control semantics.

Plan the implementation boundary

Inspect existing Select, list-row, typography, spacing, and focus patterns. The queue page owns filter selection and fetch state. Reuse the Select if it can express the approved behavior. Record whether the filter belongs in the URL as an unresolved product decision until confirmed; keep the initial implementation local if no routing behavior is specified. All shows 47 visible records and Held shows 6. Loading is pending work, empty means a successful query returned no matches, and error means data could not be obtained. Do not turn the error into a misleading count of zero.

Build the state and access matrix

Check a wide All state, a narrow Held state with a long destination, a narrow empty search, and a narrow request error. The filter and Retry controls need names, keyboard access, and a visible focus state. Keep headings and rows in a logical reading order. Compare each rendered state with the approved visual intent, then test filter transitions and error recovery separately. A screenshot does not reveal those interactions. If an existing shared Select must change, identify every consumer and run regression checks there too.

Fixture: All 47; Held 6; other status counts are unspecified.
States: loading | result | empty | request error.
Acceptance: count = visible successful result, never a failed fetch.
Widths: wide All; narrow Held with long text; narrow empty/error.
Access: named controls, keyboard path, visible focus, reading order.
Release packet: captures, state assertions, affected consumers, fixes.

Performance and operating cost

Filtering N loaded rows costs O(N) per selection; a copied visible list costs O(N) additional space. If production data is paginated, the server owns filtering and the count must describe the returned scope or a verified total. A complete V-by-S screenshot grid costs O(VS) captures, so choose representative states by distinct failure risk. Run cheap state assertions before image comparisons. The reviewer should reject a visually close screen if the error state lies about data, the filter cannot be used by keyboard, or a shared component change lacks consumer checks.

Common Mistakes

Do not infer URL state or pagination from a desktop image.
Do not copy pixels at the expense of semantic controls and natural reflow.
Do not approve a polished error screen that reports a successful empty result.

Connected lessons

prompt engineering

ui engineering