Rain Lag

The Coffee‑Shop Code Rehearsal: Designing Features on Paper Before You Touch the Keyboard

Discover how “coffee‑shop code rehearsals” and paper prototyping help you design better features, catch UX problems early, and save time and money—before you ever open your editor.

Introduction: Why You Should Leave Your Laptop Closed

You sit down in a coffee shop to “get some coding done.” But instead of opening your laptop, you pull out a notebook, a pen, and maybe a few sticky notes. For the next hour, you design and "run" your feature entirely on paper.

This is the coffee‑shop code rehearsal: practicing features on paper before you touch the keyboard.

It’s not anti‑code. It’s pre‑code.

By rehearsing your feature on paper, you can explore different designs quickly, surface UX and workflow problems early, and think clearly about the user journey without getting pulled into implementation details. Done well, this inexpensive, low‑tech ritual can save hours (or days) of rework.

In this post, we’ll explore what a coffee‑shop code rehearsal looks like, why it works, and a practical, repeatable process you can start using today.


What Is a Coffee‑Shop Code Rehearsal?

A coffee‑shop code rehearsal is a deliberate, offline design session where you:

  • Sketch the feature you’re planning to build
  • Simulate user interactions on paper
  • Walk through flows, edge cases, and states
  • Gather informal feedback from peers or potential users
  • Refine the design before you write a single line of code

You can do it anywhere—at your desk, on a whiteboard, in a park—but a coffee shop captures the spirit: casual, low pressure, away from your usual tools.

The goal is not pixel‑perfect design. It’s clarity:

  • What exactly should this feature do?
  • How does a user move through it?
  • What can go wrong, and how do we handle it?
  • Where might people get confused or stuck?

By the time you open your editor, you’ll have already rehearsed the feature several times in your head and on paper.


Why Paper First? The Power of Cheap Exploration

1. You explore designs before you’re locked into code

The moment you start coding, you start making commitments:

  • Data models
  • API contracts
  • UI components
  • Library choices

These commitments are expensive to change. Paper, on the other hand, is amazingly cheap.

With a pen and a few sheets of paper, you can:

  • Try three different layout ideas in 10 minutes
  • Sketch two competing flows for the same task
  • Add or remove steps without refactoring anything

The psychological effect matters too: you’re less attached to a rough sketch than you are to code you’ve struggled with for an hour. This makes you more willing to throw away bad ideas early.

2. You catch UX and workflow issues before they cost you

Many project delays come not from technical difficulty but from design misunderstandings:

  • The user flow has too many steps
  • Important information is hidden or unclear
  • Error states aren’t handled
  • A “simple” feature actually needs a bunch of edge cases

Paper prototyping exposes these early. When you walk someone through your paper flow and they say, “Wait, how do I get back?” or “I’m not sure what this button does,” you’re discovering real problems before you’ve invested in code.

Catching these issues on paper can save:

  • Days of redesign and refactoring
  • Developer time spent reworking UI
  • QA cycles on fundamentally flawed flows

3. You think about users, not tools

When you design in Figma or code directly in React, it’s easy to focus on:

  • Component reuse
  • Library constraints
  • CSS issues

In a coffee‑shop rehearsal, you leave all that behind. There’s no auto‑layout, no build errors, no linter.

Instead, you’re forced to think in terms of:

  • User goals: What are they actually trying to accomplish?
  • User flows: How do they get from A to B to C?
  • Edge cases: What if they have no data? What if the network fails?
  • Clarity: Is it obvious what happens when they tap or click?

This offline constraint is a feature, not a bug. It keeps your brain on product and experience, not implementation.


A Simple, Repeatable Paper‑Prototype Process

You don’t need to overengineer this practice. A repeatable 4‑step loop works well:

  1. Sketch
  2. Simulate interaction
  3. Gather feedback
  4. Refine

Let’s break that down.

1. Sketch: Put the feature on paper

Start with the user story, not the UI. Write a one‑liner at the top of the page:

“As a user, I want to schedule a weekly report so I don’t have to generate it manually.”

Then sketch the screens or states involved. Use boxes, arrows, and labels. Keep it ugly on purpose:

  • Draw a rough layout of each screen or panel
  • Label key actions (buttons, links, gestures)
  • Note any important system states (loading, empty, error, success)

Use multiple sheets for different stages of the flow:

  • Sheet 1: List of existing reports
  • Sheet 2: “Create schedule” dialog
  • Sheet 3: Confirmation / management screen

Your aim: capture the flow, not the finished design.

2. Simulate interaction: Run it like a play

Now turn your prototype into a mini‑simulation.

  • Pretend you’re the user
  • Point at elements as if you’re clicking or tapping
  • Narrate what you’re doing and expecting

Example:

“I’m on the reports page. I want this report automatically every week. I see ‘Schedule report’—I click it. Now I expect a dialog asking for frequency and time. I set it to weekly, Monday at 9am. I hit save. I expect to see some confirmation and maybe a list of scheduled reports.”

As you narrate, pay attention to friction:

  • Did you know where to click?
  • Were the options clear?
  • Did you ever feel lost?
  • Did you miss a state (e.g., what if the user cancels)?

Mark confusing areas with a big “?” or a note like “User confused here.”

3. Gather feedback: Show it to someone

Even one other person can dramatically improve your design.

Ask a peer, PM, designer, or nearby friend to play the user. Hand them the first page and say:

“Imagine you want to [do X]. Walk me through what you’d do. Talk out loud.”

While they interact:

  • Resist the urge to explain
  • Watch where they hesitate or ask questions
  • Note misunderstandings (“I thought this would send it now, not schedule it.”)

You can also lightly role‑play:

  • You’re the “computer,” moving between screens when they “click” things
  • They’re the user, saying what they’d do and what they expect next

All of this can happen in a few minutes over coffee.

4. Refine: Iterate rapidly

Use a fresh sheet of paper to redraw improved versions. Don’t “edit” the old one to death; treat it as a snapshot of what you tested.

Tighten the flow based on what you learned:

  • Remove unnecessary steps
  • Clarify labels or actions
  • Add missing states or confirmations

Run the flow again. If you have time, show it to a second person. Each loop should be fast and lightweight—10–20 minutes, not days.


Best Practices for Effective Paper Rehearsals

To get the most from your coffee‑shop sessions, keep these guidelines in mind.

1. Stay low‑fidelity on purpose

Fancy drawings are a trap. High‑fidelity sketches invite design debates about colors and spacing. You want structure and clarity, not polish.

  • Use boxes and text, not intricate UI elements
  • Stick figures and scribbles are fine
  • Write labels clearly; that’s where the meaning is

Ugly sketches signal to others that it’s safe to critique and change things.

2. Narrate user scenarios

Ground everything in specific stories:

  • “A new user logging in for the first time”
  • “An expert user trying to complete a task fast”
  • “A frustrated user whose network just failed”

Narration keeps you anchored on real behavior, not abstract features.

3. Role‑play interactions

Treat it like a play rather than a static artifact.

  • Have one person be the user, one the system
  • Flip pages or reveal sticky notes when actions happen
  • Speak in first person: “Now I click this,” “Now I expect…”

Role‑playing makes hidden assumptions obvious.

4. Embrace rapid iteration

Don’t aim to get it right in one pass. Expect your first sketch to be wrong in useful ways.

  • Timebox: e.g., 30–45 minutes total
  • Commit to at least 2–3 iterations
  • Take photos of each version in case you want to revisit ideas

Speed matters more than completeness at this stage.


Where AI Fits In—After the Rehearsal

AI tools can supercharge your workflow after you’ve done a human‑centered, paper‑first rehearsal.

Once you’ve clarified the flow on paper, AI can help you:

  • Generate UI variants of your sketches
  • Suggest alternative flows or simplifications
  • Turn hand‑drawn screens into low‑fidelity digital wireframes
  • Analyze patterns from feedback notes and highlight recurring issues

But starting with AI often pushes you prematurely into higher fidelity, tool‑driven design. That can obscure fundamental questions:

  • Is this flow even the right one?
  • Are we solving the right user problem?

So treat AI as a multiplier, not a replacement. Do the coffee‑shop rehearsal first; bring in AI to refine, explore, and systematize once the core idea is sound.


Conclusion: Make Rehearsal a Habit, Not a One‑Off

The coffee‑shop code rehearsal is simple:

  • Grab paper and pen instead of your editor
  • Sketch the feature as a series of states and flows
  • Simulate interactions and narrate user scenarios
  • Get quick feedback, then iterate

This low‑tech ritual helps you:

  • Explore more ideas, more cheaply
  • Catch UX and workflow problems before they become code problems
  • Stay focused on users, not tools and frameworks

You don’t have to wait for a big redesign or a formal workshop. Use paper rehearsals for:

  • A new onboarding flow
  • A complex settings page
  • A tricky multi‑step feature

Next time you head to a coffee shop “to code,” try leaving your laptop closed for the first 45 minutes. Rehearse your feature on paper. When you finally touch the keyboard, you’ll be coding something you’ve already seen work—at least in rehearsal.

The Coffee‑Shop Code Rehearsal: Designing Features on Paper Before You Touch the Keyboard | Rain Lag