Design prompts

I'm designing a flow for [describe the task the user is trying to complete, for example "linking a bank account during onboarding"]. Here is my first draft of the steps.

Propose two alternative structures for the same flow: one that reduces the number of screens even if each screen does more, and one that spreads the same information across more, simpler screens. For each alternative, name the specific tradeoff against my draft (what gets easier, what gets harder, and for which kind of user).

Do not just praise my draft or declare one alternative universally better. State the actual tradeoff for each.

My draft flow: [list your steps]

I need microcopy for an error state. Here is exactly what caused the error, technically. Write three versions of the message: one that names the specific cause in plain language, one that focuses only on what the user should do next, and one that combines both in under 15 words.

For each version, tell me what information is lost by keeping it short, so I can decide deliberately rather than by accident.

Do not write a message that could apply to more than one actual cause. If the message would be true regardless of what broke, it's too generic.

Technical cause: [describe exactly what failed and why]

You have never seen this product before and you don't know what any of the following screens are for beyond what's on them. I'm going to describe each screen in a flow in order. After each one, tell me: what you think happens if you tap the most obvious button, what you're unsure about, and what you'd expect to see next that isn't mentioned.

Do not use any knowledge of how similar apps typically work to fill in gaps. React only to what's actually described, the way someone with no context would.

Screen 1: [describe what's on it]
Screen 2: [describe what's on it]
(continue for each screen)

Here is a description of a screen: its layout, its text, its colour choices, and its interactive elements. Check it against these specific things and flag any that are unclear or likely to fail: whether interactive elements are described with a clear label and not just an icon or colour, whether any information is conveyed by colour alone, whether text size and contrast are specified anywhere, and whether the tab or focus order makes sense given the layout.

For anything you can't determine from my description because I haven't specified it, say so explicitly rather than assuming it's fine.

Screen description: [describe the layout, text, colours, and interactive elements]

Here is a flow, step by step. For each step, classify it as one of: a decision the user must actually make (the outcome depends on their input), a confirmation of something already decided, or pure information with no input required.

Then tell me: of the steps you classified as decisions, which ones could actually be defaulted or inferred from data we already have, removing the need for the user to decide at all. Be specific about what data would need to exist for the default to be safe.

Flow: [list your steps]

I'm going to describe a wireframe screen by screen, including what's on each screen and what each interactive element does when tapped. Turn this into a written flow spec: a numbered sequence of states, where each state lists what's visible, what actions are available, and exactly which state each action leads to.

Explicitly name any screen that can be reached from more than one previous state, and any action whose destination I haven't specified, so I can fill those in rather than have you guess at them.

Wireframe description: [describe each screen and its interactive elements]