What this prompt does
This prompt makes the AI a senior fintech product designer specifying a card management dashboard built to feel secure and operate one-handed. It covers a card carousel with masked numbers and reveal-on-auth, instant freeze/unfreeze with optimistic UI, daily and monthly spend limits, security controls like region restrictions and notifications, card lifecycle actions, and a full set of states. The [card_types] placeholder drives the carousel contents, and [platform] shapes whether the layout targets mobile, web, or both.
The structure works because in a money app the UI is the trust layer, so the prompt insists on instant feedback and explicit states. Freeze must use optimistic UI so it never feels laggy, and the design must include loading, empty, error, and a clear "card frozen" state so nothing ever looks broken. The [stack] variable produces a component list aligned to your framework, while the lifecycle steps cover ordering, replacing, and activating cards end to end. By naming reveal-on-auth for masked card numbers and explicit region and ATM toggles, the prompt also captures the security gestures users expect from a modern card screen, the small interactions that quietly signal the app is taking their money seriously.
When to use it
- Designing a card controls screen for a neobank or fintech app
- Supporting both physical and virtual cards via
[card_types] - You need an instant, optimistic freeze/unfreeze toggle that feels trustworthy
- Adding spend limits, region restrictions, and notification settings
- Covering card lifecycle: order, replace a lost card, activate a physical card
- Building for a specific
[platform]with one-handed operation in mind
Example output
You get a screen-by-screen layout plus a component list for your [stack] and the trust/safety cues that make users comfortable managing money. The card overview is a carousel of your card types with masked numbers and reveal-on-auth; controls cover freeze, online/offline, and contactless/ATM toggles; and the states section explicitly defines loading, empty, error, and the card-frozen view so the UI always communicates clearly.
Pro tips
- List the exact
[card_types]you offer; the carousel and reveal behaviour are generated per type - Set
[platform]to your real target so the one-handed layout assumptions hold - Ask the model to design the frozen and error states first, since an ambiguous frozen state makes users doubt the whole app
- Keep
[stack]accurate so the component list maps to your framework - If the freeze interaction reads as slow, request explicit optimistic-UI handling with a rollback on failure
- Have it spell out the trust/safety cues separately; those are what make a card screen feel safe to operate
- If the limits section is thin, ask it to define the feedback shown the moment a daily or monthly spend limit is hit, since silent failures here confuse users
