UI prompts: turn a brief into components and states

Last updated: 5 Oct 202611 min read

tutorial

A UI implementation prompt is an executable work contract. It should describe the user's task, available data, existing components, design constraints, state transitions, and acceptance checks. Separate what the brief establishes from what the implementer must inspect in the repository. State which component owns a filter, where the URL or application state lives, and what happens when data is loading, empty, stale, or unavailable. Ask for a short inventory of unknowns before code changes. A screenshot cannot answer ownership, persistence, or error behavior; those decisions need an explicit brief or a reviewed assumption.

Operational case

A fictional dispatch team has a queue of 47 shipments, including 6 on hold. The requested screen has a status filter and a count above the list. The prompt makes the count mean currently visible records: 47 for All and 6 for Held. A network failure is an error state, not an empty queue. The filter is a reusable control, but the queue page owns the selected status and fetch result. The implementer checks whether the application already has a filter component and a spacing scale before creating another pair. The brief leaves the action behind a shipment row out of scope.

Task: implement the Dispatch Queue status filter.
Data: 47 shipments; Held filter returns 6.
Ownership: queue page owns selected status and fetch result.
States: loading, 47 All, 6 Held, true empty result, request error.
Reuse: inspect existing filter control and tokens before adding code.
Acceptance: visible count follows the selected filter; error never says zero.
Unknown: ask which filter, if any, belongs in the URL.

Performance and operating cost

A client-side filter over N loaded rows is O(N) time per selection and O(N) space for a copied visible list; server-side filtering instead spends a request and must reconcile count with the returned page. The prompt does not choose between them without knowing dataset size and pagination. Inventory work adds review time, but prevents duplicate components and contradictory state stores. Keep generated changes scoped to the queue page and shared primitives that really need alteration.

Common Mistakes

Do not make a loading or network error appear as a zero-result search.
Do not invent filter persistence or URL behavior from a still image.
Do not create a second control before inspecting the existing component library.

Connected lessons

prompt engineering

ui engineering