What this prompt does
This prompt assigns the model the role of a senior marketplace UX designer and asks it to specify home services search results tightly enough to build — naming components, card fields, and filter behaviour. The framing optimises for fast trust and quick contact, which is exactly what a directory results page has to do. Three variables shape the output: [categories] defines the services covered (plumbing, cleaning, electrical, handyman), [stack] sets the implementation idiom such as Next.js with Mapbox, and [ranking] tells the model what ordering should prioritise, like verified providers with fast response times.
The deliverables are built around conversion levers. The provider card carries photo, rating with review count, distance, price range, response time, and a verified badge — the signals that stop a thin card from being scrolled past. It pairs an instant-quote primary CTA with a secondary profile action, defines the filter set with applied-filter chips, and specifies a synced list-plus-map split view with a mobile bottom-sheet. Crucially it asks for trust and ranking notes surfaced honestly, so ordering logic is explained rather than hidden. Because the prompt names components and filter behaviour explicitly, the answer reads like a build ticket rather than a sketch, and the states it demands are exactly the screens a rushed first pass skips yet a new market hits first.
When to use it
- Scoping a results page for a home services or local marketplace
- Deciding which trust signals belong on a provider card
- Designing filters with applied-filter chips for
[categories]you support - Planning a synced list-and-map view plus a mobile bottom-sheet layout
- Defining the no-providers-in-area state for a new market launch
- Documenting how
[ranking]influences order in a way users can trust
Example output
You get a component spec: the provider card with its named fields, the per-card instant-quote and view-profile actions, the filter set with chips, and the list/map split with synced hover and selection plus a mobile bottom-sheet. It also defines the states — loading skeletons, no-providers-in-area, and a widen-search prompt — and a short, honest note on how verified status and response time influence ranking.
Pro tips
- Make
[ranking]explicit; "verified providers with fast response times" gives sharper ordering logic than leaving priority unstated. - Design the no-providers-in-area state deliberately — in a new market it is the screen most users hit first, so a widen-search prompt matters.
- Keep the card dense with trust signals; rating, review count, and response time are what convert, so do not strip them to look clean.
- Set
[categories]to your real service list so filters and card copy fit the domain. - If you use a map, confirm the
[stack]choice (e.g. Mapbox) and ask for the synced hover behaviour as explicit code in a follow-up. - Ask the model to keep ranking explanations honest and visible; hidden ordering erodes trust on a marketplace.
