UI Discovery

Claude Code UI Design Prompts: Tested React Example

Use Claude Code for a scoped change that can be checked in the repository and the browser. The prompt should name the starting point, preserve existing work and define what counts as complete.

UI Discovery editorial · Updated

A search-state repair tested in Claude Code

The starting component treated failed requests like empty results and allowed an older response to overwrite a newer search. The generated component separates idle, loading, successful, empty and error states and keeps only the latest request's result.

Tool
Claude Code 2.1.292
Model
claude-sonnet-5-5
Checked

Search five fictional projects. Try alpha for a result, no-match for an empty state, and fail for a failed request that recovers on retry. Search slow, then fast, to try overlapping requests.

This example uses local sample data. Searches do not contact a server or change your account. Reload the page to reset the simulated failure.

What passed in the browser

  • Populated search results
  • Empty results keep the query and offer clear filters
  • Failed requests keep the input and offer retry
  • Retry returns the matching project
  • Loading has a distinct status message
  • An older slow response cannot replace a newer result; input focus stays put
  • An older failed request cannot replace a newer successful result
  • Long project labels fit a 390px viewport
  • The site integration wraps 150-character queries at mobile widths
Test method and limits

One original brief was run in Claude Code against a disposable React 19 search fixture. Claude Code read the fixture and returned a complete component; a separate local harness applied it and ran the browser checks. The interactive example embeds the unchanged component with deterministic sample data and a site wrapper that wraps long query text.

This verifies one brief in one fixture. It does not measure production API behavior, prove screen-reader announcements, or validate the other tool-specific briefs. Adapt the component to your real API, tests and design system.

How to use this guide

Ask for an evidence-based starting point

Before editing, have the agent locate the current route, shared components and relevant tests. A short diagnosis should cite the code responsible for the behavior. This is particularly useful for UI bugs where the cause may be state handling rather than styling.

Set boundaries around consequential changes

An empty-state repair should not redesign navigation, install a new UI framework or alter authentication. Name those boundaries explicitly. Ask the agent to preserve unrelated working-tree changes and to stop before publishing, deleting data or changing external services.

Give the agent a way to verify the result

Specify the failing scenario and its expected outcome. For a search result page, test a populated result, a no-match result, a network error and rapid repeated queries. Ask for the relevant regression test and distinguish checks that passed from checks that could not run.

Original prompt to adapt

The original brief used for the tested example above. Adapt it to your repository and check the result with your own tests.

Find the existing search-results page and its tests. Explain how it currently distinguishes loading, no matches and a failed request. Then fix any conflated states without changing the visual system, dependencies, API contracts or authentication. Preserve unrelated working-tree changes. A no-match result must keep the query and offer a clear-filter action. A network error must keep previous input and offer retry. Announce result changes without moving keyboard focus. Add regression coverage for empty results, rejected requests and a slow response arriving after a newer query. Run the relevant checks and report actual results. Do not commit, deploy or modify external data.

A focused follow-up

Review your own diff for a stale-response race and for clearing the user's query after a failure. Reproduce either issue in a test before making a correction; leave unrelated code alone.

Review checklist

  • The change stays within the identified route and necessary shared logic.
  • A delayed older response cannot overwrite newer results.
  • Unrun tests and remaining uncertainty are stated explicitly.

Continue with real references

Official tool documentation

Tool interfaces and capabilities can change; check the provider’s current documentation.

Common questions

Was this Claude Code prompt tested?

Yes. This search-state brief was run in Claude Code 2.1.292 using model claude-sonnet-5-5 on October 7, 2026. A separate browser harness checked the returned React component for results, empty states, failure, retry, stale responses and long labels. The page includes the working local example and explains the test limits.

Can I use the same prompt in my project?

Adapt the search route, API and acceptance criteria to your repository. The example uses fictional local data; the test does not establish how your production API or authentication will behave. Keep your existing tests and verify the result before publishing.