Wireframes and prompting plan

Before you write a line of code, spend 10 minutes on paper. I know, I know: the keyboard is right there. But a sketch and a prompt plan will make tomorrow's build session genuinely faster, and paper is the cheapest place in the world to change your mind.

Wireframes

A wireframe is a rough layout sketch: boxes and labels, no colour, no styling. It answers "what goes where?" before any HTML is written.

Sketch at least two pages from your project:

1. Draw a rectangle for the browser window.
2. Label each section: "nav," "hero," "card grid," "footer," and so on.
3. Mark where your core user action happens. Is it obvious on the page?

That's it. If you're drawing styling details, stop. You're spending too much time on wireframes.

Post them on the wall when done.

The visual brief

The wireframe says what goes where. The visual brief locks the three design decisions from the visual design session, on paper, before any code:

Why bother? Because a model implements a decision; it can only guess at a vibe. Two minutes spent on font pairing saves ten minutes of re-prompting when the model's defaults don't match your page.

Prompting plan

A prompting plan is a list of the specific prompts you intend to write during Sprint 1. Writing them out in advance forces clarity about what you're asking the model to do and which techniques you'll use.

For each component you plan to build, write:

• Component name: "navigation bar," "hero section," "resource card"
• Technique stack: e.g., "structured output + few-shot"
• Example source (if few-shot): e.g., "my About Me nav bar" or "two hand-written card examples"
• At least one design spec from your visual brief: "asymmetric two-column layout," "accent colour #0057FF on the CTA only," "display-weight hero heading"

A strong Sprint 1 plan covers the must-have components from your scope worksheet. You don't need to plan every prompt. Just walk in tomorrow knowing what you're building, and tomorrow will feel like assembling instead of flailing.