If You Cannot Draw the Screen, You Probably Have Not Decided Enough

Key takeaways

If you cannot draw the screen, you probably have not decided enough — sketching forces you to answer questions a written brief lets you avoid, like which metrics appear, in what order, and who can see them.
A wireframe is a decision-making tool, not design decoration: for most business owners, the act of sketching is how the plan actually gets made, not a translation of a plan that already exists.
Five rough sketches — dashboard, main data-entry form, confirmation state, error state, and report view — at roughly twenty minutes each take under two hours and surface the majority of hidden decisions in a typical business application.
Wireframes move decisions to the cheap end of the timeline: a change to a paper sketch takes thirty seconds, while a change to a working feature can take days because finished code has been written, tested, and integrated elsewhere.
Static wireframes are enough for most projects, but a clickable prototype earns its cost for heavily branching user journeys, sign-off on something unfamiliar, and high-stakes flows like checkouts or irreversible deletions.

If You Cannot Draw the Screen, You Probably Have Not Decided Enough — Working With App Developers — Prototyping

There is a moment in almost every software project when a business owner looks at a developer's first working prototype and says, quietly, 'That's not what I had in mind.' The developer is baffled. The brief said 'a dashboard with the key metrics.' This is a dashboard. It has metrics. What went wrong?

What went wrong was that nobody ever drew the screen. A description, however detailed, leaves enormous room for interpretation. A sketch – even a rough one, scribbled on paper or knocked together in a free tool in twenty minutes – forces you to answer questions you didn't know you'd avoided. Which metrics? In which order? What happens when a user clicks one? Who can see this screen at all?

If you cannot draw the screen, you probably have not decided enough. That is not a criticism of your planning effort; it is just the nature of software. Decisions that feel obvious in conversation turn out to be contested the moment someone has to choose pixels. The sketch is not design decoration. It is a decision-making tool – one of the cheapest available.

A rough sketch exposes missing decisions faster than a long meeting. Get something on paper before you get anything in code.

Why a sketch is decision-making, not decoration

It is tempting to think of wireframes as something that happens after the decisions are made – a visual translation of a plan that already exists. That is backwards. For most business owners commissioning software, the act of sketching is how the plan gets made.

When you try to draw the login screen, you immediately discover whether you need a 'remember me' checkbox, whether a forgotten-password link belongs there or on a separate page, and whether you are logging in with an email address, a username, or a company account number. None of those questions appear in a text description that says 'users log in securely.' They only surface when you pick up a pen.

This is why developers who ask for wireframes are not being awkward. They are trying to establish what you actually want before they build something expensive based on guesswork. A hand-drawn sketch carries more decision content than three pages of written requirements.

The screen as a conversation between business and developer

Software development works best when it is a structured conversation. The business owner brings knowledge of the outcome – what users need to be able to do, what decisions need to be recorded, what errors would cause real problems. The developer brings knowledge of what is technically feasible, what patterns exist, and where hidden complexity lurks.

A wireframe is a shared object that lets both sides of that conversation point at something concrete. 'When the user clicks this button, what should happen next?' is a question that a developer can answer technically and a business owner can answer commercially. Without a shared screen to point at, those two answers never quite find each other.

A sketch is not a commitment to pixels – it is an invitation to disagree early, when disagreement is cheap.

Sharing early sketches also surfaces assumptions you didn't know each side was making. The developer assumed that 'confirmation' meant an on-screen message; you assumed it meant an email and a PDF receipt. That three-second conversation, over a rough drawing, saves days of rework. The same conversation after the feature is built costs real money and frays real relationships.

What to sketch: the five screens that matter most

You do not need to sketch every screen before development starts – that would take weeks and produce a design document nobody would follow precisely anyway. But there are five types of screen that almost always contain hidden decisions, and sketching at least one of each will save you significant pain:

The dashboard or home screen. What does a logged-in user see first? Which numbers, tasks, or alerts appear here? What action should they take most often, and is that action obvious without explanation?
The main data-entry form. What are the fields? Which are required? What validation happens on submission? What happens if the user leaves halfway through?
The confirmation or success state. After the user completes an action – placing an order, submitting a request, sending a message – what do they see? What are they expected to do next?
The error state. What happens when something goes wrong – a payment fails, a file is the wrong format, the network drops? Does the user know what to do, or just that something broke?
The report or summary view. If your application produces any kind of output – a report, a list of records, an export – what does it look like? What columns matter? What can be filtered or sorted?

Five rough sketches, twenty minutes each – under two hours to surface the majority of hidden decisions in a typical business application.

Why wireframes reduce expensive rework

Software cost is not evenly distributed. The cheapest phase is planning, because nothing has been built yet. The most expensive is late-stage revision, because every change means unpicking code that has already been written, tested, and integrated elsewhere. A change to a paper sketch takes thirty seconds; a change to a working feature can take days.

Wireframes move decisions to the cheap end of the timeline. Requirements do evolve, and good developers build in flexibility – but wireframes eliminate the category of change that comes from 'we never actually agreed on this in the first place.'

When a clickable prototype is worth the effort

For most projects, static wireframes – screens that do not respond to clicks, just show layout – are sufficient to expose the decisions that need making. But there are situations where a clickable prototype, one that simulates moving between screens, earns its cost:

User journeys with many branches. If the path through your application depends heavily on user choices – a booking flow that changes based on service type, a quote calculator that branches by product category – it is very hard to reason about the full journey from static screens. A clickable prototype lets you walk the journey end-to-end and spot the missing steps.
Stakeholder sign-off on something unfamiliar. If you are commissioning software that your colleagues have never used before, asking them to sign off on wireframes may produce agreement that evaporates the moment they see the real thing. A prototype – even a simple one – helps people understand what they are agreeing to.
High-stakes flows. A checkout, a data-deletion confirmation, a regulatory submission – anywhere that errors are costly or irreversible, a prototype lets you test the journey with real users before real consequences are possible.

Figma's free starter plan, Excalidraw, and Canva's whiteboard let you build a linked set of screens without specialist skills. You do not need agency-grade assets to ask 'does this make sense to you?'

Practical steps: from blank page to useful sketch

Start with the first screen a user sees after logging in. This is almost always the most contested screen – everyone has an opinion about what belongs on the dashboard – and resolving it early sets the tone for the rest of the project.
Label your decisions, not just your layouts. Annotate the sketch: 'This table shows last 30 days by default – can the user change the date range?' That question, written on the wireframe, gets answered in the review meeting rather than discovered in testing.
Sketch the error state, not just the happy path. Errors reveal system requirements the happy path conceals: if a payment fails, what does the user see, and can they retry? These questions surface data and logic requirements more reliably than any other technique.
Show it to someone who will actually use the software. Not the person who commissioned it – someone who will use it daily. Their confusion tells you more than any technical review.
Agree what 'done' means for each screen before coding starts. Which fields, which states, which permissions – settled in the sketch review, not discovered in testing.

The question is never 'have we decided everything?' – it is 'have we decided enough to start?' Wireframes tell you the answer.

Moving forward

Most software projects do not fail because of bad code. They fail because both sides believed they were talking about the same thing – and discovered the gap only once something expensive had been built. A sketch is the cheapest insurance against that outcome. It does not need to be beautiful or complete; it needs to be specific enough to surface disagreement while disagreement is still cheap.

Your immediate action: open Excalidraw, Figma, or a piece of paper, and sketch the first screen a user should see after logging in to whatever you are building. Do it now, before the next meeting with your developer. Bring it to that meeting and ask: 'Is this what you were imagining?' The conversation that follows will be the most useful thirty minutes of your project so far.

Business owner toolkit

Sketch Your First Screen

Picture it

Simple wireframe flow: login → dashboard → action → confirmation, showing the four essential screens every app needs before development begins.

Map it

Rough app screen with labelled decision points — fields, buttons, permissions, error states, and next steps — annotated to expose what needs to be agreed before coding starts.

Free tool to try

Figma Starter, Excalidraw, Canva whiteboard

Quick exercise: Sketch the first screen a user should see after logging in — label every field, button, and link with the decision it represents.

The Businessman's Pain Point: You provide a written brief, but when the developer starts building, they have to constantly stop to ask about missing decisions (e.g., "what happens if they click here?" or "what error message should show?").

You are an experienced product design facilitator and software discovery consultant who specializes in helping teams uncover hidden complexity before development begins. You have run dozens of low-fidelity wireframing workshops and know how to draw out the unspoken assumptions, edge cases, and missing logic that typically blow up budgets mid-build.

My goal: facilitate a pen-and-paper "Wireframing Workshop" with my team so we surface hidden software decisions—error states, permissions, confirmations, empty states, edge cases, and unstated logic—BEFORE we hire a developer to write code.

Create a step-by-step facilitation guide I can run myself. As you build the guide, help me think through:

- How to prepare the room, materials, and team mindset for a low-tech session (pen, paper, sticky notes only)
- How to structure the workshop in clear time-boxed phases (warm-up → sketching → interrogation → consolidation)
- What facilitator prompts and questions to ask at each phase to expose hidden decisions, especially around:
  - Error and failure states ("What happens when this fails?")
  - Permissions and roles ("Who can see or do this, and who cannot?")
  - Confirmations and destructive actions ("What requires a 'Are you sure?'")
  - Empty, loading, and partial states
  - Validation rules and input edge cases
  - Notifications, messaging, and system feedback
  - Offline, slow, or interrupted scenarios
- How to push the team past the "happy path" without overwhelming non-designers
- Techniques for capturing decisions and open questions on paper so nothing is lost
- How to close the workshop with a clear artifact or decision log we can hand to a developer

Use entirely hypothetical examples (e.g., a fictional appointment-booking app, an imaginary internal expense tool) to illustrate prompts and exercises. Do not ask me to upload, share, or describe our actual product or screen designs—keep everything generic and adaptable.

Where useful, offer me options or trade-offs (e.g., "if your team is technical vs. non-technical, try X vs. Y") rather than locking in one path. Treat this as a working session: feel free to ask me clarifying questions about team size, product type, or time available if it would meaningfully change your recommendations, but assume a default of 4–8 people and a half-day session if I don't specify.

How to sketch your screens to surface hidden decisions before coding starts

Start with the post-login screen. Begin with the first screen a user sees after logging in. This is almost always the most contested screen — everyone has an opinion about what belongs on the dashboard — and resolving it early sets the tone for the rest of the project.
Label your decisions, not just your layouts. Annotate the sketch with the decisions behind it, for example 'This table shows last 30 days by default — can the user change the date range?' A question written on the wireframe gets answered in the review meeting rather than discovered later in testing.
Sketch the error state, not just the happy path. Draw what happens when something goes wrong — a payment fails, a file is the wrong format, the network drops. Errors reveal system, data, and logic requirements the happy path conceals, including whether the user can understand what to do and retry.
Cover the five screens that hide decisions. Sketch at least one of each high-risk screen type: the dashboard or home screen, the main data-entry form, the confirmation or success state, the error state, and the report or summary view. Five rough sketches at about twenty minutes each take under two hours.
Show it to someone who will actually use it. Share the sketch with someone who will use the software daily — not the person who commissioned it. Their confusion tells you more than any technical review, and sharing early surfaces assumptions each side didn't know it was making.
Agree what 'done' means for each screen. Before coding starts, settle which fields, which states, and which permissions each screen needs in the sketch review rather than discovering them in testing. The goal is not 'have we decided everything?' but 'have we decided enough to start?'

Frequently asked questions

Why does my developer keep asking me for wireframes or sketches?

Developers who ask for wireframes are not being awkward — they are trying to establish what you actually want before building something expensive based on guesswork. A hand-drawn sketch carries more decision content than three pages of written requirements, because drawing forces you to answer questions a text description leaves open. The wireframe becomes a shared object both sides can point at and disagree over while disagreement is still cheap.

Why did the prototype not match what I described in the brief?

A description, however detailed, leaves enormous room for interpretation. A brief that says 'a dashboard with the key metrics' does not specify which metrics, in which order, or what happens when a user clicks one. Those contested decisions only surface when someone has to choose pixels — which is exactly why drawing the screen before coding prevents the 'that's not what I had in mind' moment.

Which screens should I sketch before development starts?

You don't need to sketch every screen, but five types almost always hide decisions: the dashboard or home screen, the main data-entry form, the confirmation or success state, the error state, and the report or summary view. Sketching at least one of each — roughly twenty minutes apiece, under two hours total — surfaces the majority of hidden decisions in a typical business application. The error state in particular reveals data and logic requirements the happy path conceals.

Do I need an expensive design agency to make wireframes?

No. You do not need agency-grade assets to ask 'does this make sense to you?' Free tools like Figma's starter plan, Excalidraw, and Canva's whiteboard let you build a linked set of screens without specialist skills, and a rough sketch on paper works just as well. The point is to be specific enough to surface disagreement, not to be beautiful or complete.

When is a clickable prototype worth the extra effort over static sketches?

For most projects static wireframes are enough, but a clickable prototype earns its cost in three situations: user journeys with many branches (a booking flow or quote calculator that changes by category), getting stakeholder sign-off on something colleagues have never used before, and high-stakes flows like checkouts, data deletion, or regulatory submissions where errors are costly or irreversible. A prototype lets you walk the journey end-to-end and test it before real consequences are possible.

How do wireframes actually save money on a software project?

Software cost is not evenly distributed — planning is the cheapest phase because nothing has been built, and late-stage revision is the most expensive because every change means unpicking code that has already been written, tested, and integrated. Wireframes move decisions to the cheap end of the timeline and eliminate the category of change that comes from 'we never actually agreed on this in the first place.' A change to a paper sketch takes thirty seconds; a change to a working feature can take days.

The Warehouse Blueprint

Building Your Custom Warehouse Tool

A custom tool begins with a clear outcome, not code. Own the workflow, brief real exceptions, and use the Done Ladder.

3 Aug 2026 · 5 min read

Working With App Developers

Your App Needs a Handover Plan Before It Needs a Launch Party

Launch day is not the end of your project — it's the moment the business needs to take control. Here's how to plan a handover that actually protects you.

17 Jul 2026 · 8 min read

Working With App Developers

Meetings Do Not Manage Projects. Decisions Do.

Plenty of app projects have conversations but few recorded decisions. The same topics return week after week. Here's how to turn meetings into a management system.

14 Jul 2026 · 9 min read