The key idea
An application needs boundaries and connected flows; a component needs a precise interaction contract. Adapt your depth to the prompt.
Recognize the shape of the prompt
Two useful starting categories are complete applications and reusable UI components. A feed spans routes, data, and features; an autocomplete concentrates complexity inside one interaction. You may also be asked to extend or diagnose an existing interface. This guide treats that as a practical third format, because its starting point and constraints differ.
Confirm the expected deliverable
Ask whether the discussion needs a high-level architecture, a reusable component API, an implementation sketch, or a performance investigation. The same phrase—'design search'—can mean very different amounts of work.
Application prompts: connect the essential flows
Choose a small set of routes and user actions before describing modules. For a marketplace, agree whether browsing, product details, cart, and checkout are all in scope. Then define the shared product identity, cart ownership, and service contracts that connect those screens.
- Draw route-level views, reusable feature modules, a data layer, and the services they call.
- Explain initial rendering, subsequent navigation, and what browser Back restores.
- Describe one read path and one write path, including pending and failure states.
- Keep prices, permissions, and checkout eligibility authoritative on the server; the browser presents the result.
A reasonable cart draft can live locally for a guest, but merging it after sign-in introduces quantity, inventory, and conflict decisions. Name that tradeoff instead of silently assuming local storage solves persistence.
Component prompts: define an interaction contract
A reusable component serves two users: the person interacting with it and the developer integrating it. Specify its inputs, events, state ownership, keyboard behavior, and customization points. Internal subcomponents should support those requirements rather than expose every implementation detail.
| Contract | Autocomplete example |
|---|---|
| Inputs | Current value, disabled state, option identifiers, and an async suggestion loader |
| Events | Input change, option selection, and an explicit clear action |
| State ownership | Distinguish selected value, editable text, highlighted option, and popup visibility |
| Interaction | Arrow navigation, Enter selection, Escape dismissal, and preserved text editing |
| Customization | A label, option rendering, styling hooks, and clear empty/loading/error content |
If the parent controls the value, do not maintain a competing internal selection. Uncontrolled defaults are useful too, but their initialization and reset behavior must be explicit. Accessibility belongs in this contract from the start.
Extension and diagnosis prompts: preserve working behavior
Examples include adding offline drafts to a form or making a slow dashboard responsive. Begin by asking what already exists: data contracts, browser support, traffic patterns, constraints, and evidence of the problem. Propose the smallest change that can demonstrate improvement.
- 1
Baseline
Reproduce the symptom and capture a useful measurement.
- 2
Hypothesis
Identify a likely bottleneck or missing behavior and explain why.
- 3
Change
Introduce a targeted improvement with a rollback or compatibility approach.
- 4
Validate
Compare the same task and conditions, including correctness and failure paths.
For a slow table, distinguish network delay from expensive rendering before choosing pagination, caching, or virtualization. Each addresses a different bottleneck; virtualization also needs careful focus and accessibility behavior.
A small worked example: remote autocomplete
Describe the contract before the implementation
TypeScripttype Suggestion = { id: string; label: string };
type SearchState = {
query: string;
selectedId: string | null;
activeId: string | null;
status: 'idle' | 'loading' | 'success' | 'error';
suggestions: Suggestion[];
};
type LoadSuggestions = (
query: string,
signal: AbortSignal,
) => Promise<Suggestion[]>;Debounce requests if the agreed experience allows a short wait. Abort superseded fetches and guard against stale responses, so an older query cannot replace newer suggestions. Clear selection when appropriate rather than treating highlighted and selected options as the same thing.
Use the appropriate combobox pattern: give the input a label, expose expanded state and its popup relationship, and represent the active option consistently. Preserve normal text editing. Test Arrow keys, Enter, Escape, no results, loading, and request failure with keyboard and assistive technology.
Let the product choose the deep dive
| Example | Useful emphasis | Question to investigate |
|---|---|---|
| News feed | Pagination, stable identity, scroll restoration | What happens if new posts arrive while someone reads? |
| E-commerce | Rendering, discoverability, cart correctness | What changes if the displayed price becomes stale? |
| Chat | Ordering, reconnecting, pending delivery | How does the UI distinguish unsent from confirmed messages? |
| Autocomplete | Request races and keyboard interaction | Which response is allowed to update the current popup? |
| Modal dialog | Focus, dismissal, and background interaction | Where does focus return when the dialog closes? |
| Collaborative editor | Document identity and concurrent edits | How are conflicting edits reconciled and communicated? |
These are starting points, not universal priorities. A private marketplace dashboard may have little SEO value; a public chat archive may need indexing. Recheck the actual users and routes before applying a familiar checklist.
Check your scope with three short prompts
Design a booking application
Application: agree search and booking flows, URL filters, availability freshness, and confirmation behavior. A calendar component is one part of the system.
Design a reusable date picker
Component: define value/range rules, locale formatting, keyboard navigation, focus, disabled dates, and integration with forms.
Our search becomes slow after typing
Diagnosis: reproduce it, separate request latency from rendering work, then validate a targeted change. A framework rewrite is not a diagnosis.
For each prompt, name the expected output, one missing requirement, and the first failure case you would investigate. If your answer fits every prompt unchanged, make it more specific.
Sources & further reading
Original explanations and examples by FineFrontend, informed by the guide and primary references below.
- GreatFrontEnd: Types of questions (opens in a new tab)
Background on application and component prompts. The extension/diagnosis category and worked scenarios here are original additions.
- W3C WAI: Combobox pattern (opens in a new tab)
Combobox semantics and keyboard interaction.
- MDN: AbortController (opens in a new tab)
Cancellation of fetch and other abortable operations.
- React: Choosing the state structure (opens in a new tab)
Avoiding duplicated selection state and conflicting ownership.