What this prompt does
This prompt casts the AI as a senior product designer and asks it to specify a fintech account overview screen tightly enough to actually build. Instead of a vague mood board, you get a named component tree: multi-currency balance cards, a quick-actions row, a transactions list, a spending chart, plus loading skeletons and an error/retry state. The [stack] placeholder decides whether the output targets React Native, React Web, or whatever you fill in, so the component shapes and prop names match your real codebase.
The structure works because it forces the model past the happy path. By naming [currencies] it generates one balance card per currency with a sparkline and a primary/secondary hierarchy, and by demanding pending vs settled, empty, loading, and error states it covers the cases that quietly break trust in money apps. The [theme] variable threads through every section so the dark-mode-first or light spec stays consistent rather than drifting card to card. Because the prompt asks for named props and a short layout note per section, the result is something a developer can act on directly instead of reinterpreting a flat picture, which is where most design-to-build handoffs lose fidelity.
When to use it
- Scoping a new fintech or banking app before any visual design starts
- Building a multi-currency wallet where each currency needs its own balance card
- You need pending vs settled transaction states defined early, not patched in later
- Handing a developer a buildable spec with named props instead of a flat mockup
- Standardizing loading skeletons and error/retry behaviour across a finance dashboard
- Translating a finance feature into a specific
[stack]like React Native or React Web
Example output
You get a structured component spec rather than prose: a component tree where each section (balance cards, quick actions, transactions, spending chart) is listed with named props and a short layout note. Each component enumerates its states, so the transactions list explicitly covers pending vs settled, and the balances section covers loading skeletons and an error/retry path. It reads like a build checklist a developer can implement section by section.
Pro tips
- Set
[currencies]to the exact list you support; the model generates one balance card per entry, so an accurate list saves you trimming later - Use
[theme]to lock dark-mode-first or light early, since it flows into contrast and number formatting notes - Match
[stack]to your real framework so the prop names and component shapes are usable, not generic - If the transactions section feels thin, ask it to expand the pending vs settled and amount color-coding rules specifically
- Request that it call out per-locale number formatting in the accessibility notes; that detail is easy to miss across multiple currencies
- Iterate by asking for the empty state for new accounts separately if the first pass skims over it
