← Workbook
Dossier Print
sequential

The Design Sprint: The Build–Test–Revise Loop

The Dev Loop

The design sprint — a structured five-day process developed at Google Ventures — became the default model for rapid product validation in the 2010s. A decade later, the companies that birthed it are reckoning with its limitations: it optimises for speed of learning at the cost of depth, and it has a cultural tendency to validate rather than challenge assumptions.

Mule Design Studio / Medium 2017-03-13 economic

Design Sprints Are Snake Oil

Designer and strategist Erika Hall argues that design sprints function as a universal solution marketed to solve any problem regardless of context. Hall notes that the method promises 'fast, tangible results for virtually any problem of any size, in any organization'—a claim she views as snake oil. The methodology fails when applied to challenges requiring weeks or months of sustained thinking, not rapid artifact generation. Hall contends practitioners risk 'identifying their expertise with the style of activity' rather than focusing on disciplined methodology and lasting outcomes.

"A five-day sprint won't fix a problem that takes weeks to understand."

Source ↗
Working Backwards 2021-02-09 scientific

Working Backwards: Amazon's Press Release First Approach Beats the Sprint

Amazon's Working Backwards process, documented in the 2021 book by Colin Bryar and Bill Carr, emphasizes writing a press release and FAQ before building any product. Unlike rapid prototyping, this method forces teams to articulate customer needs through written narrative discipline before engineering begins. The PR/FAQ uncovers hidden assumptions through the writing process itself. AWS, Kindle, and Prime Video were all developed using this thinking-first approach, which invests months in planning to enable faster, more focused execution later. The process functions as a 'funnel for ideas,' filtering candidates against customer reality before any resource commitment.

"Write the press release before you build the product. What you learn will shock you."

Source ↗
Tangent 2021-11-29 economic

Five Types of Bias Invalidate User Testing in Product Design

Product strategist Nadine Clarke identifies five systematic biases that distort user testing feedback: confirmation bias (overlooking contradictory signals), the familiarity principle (users expect things where they've seen them before), the sunk cost fallacy (persisting with solutions despite evidence), courtesy bias (providing socially acceptable feedback rather than honest assessment), and the framing effect (how information is worded influences response). Courtesy bias is particularly damaging in sprint testing sessions: users claim they love a prototype when they wouldn't actually use it. Testing with friends and colleagues amplifies this problem—social desirability bias prevents honest critical feedback, making enthusiastic responses in a private testing room irrelevant to real market behavior.

"They loved it in your office. They loved it for free. Then they didn't buy it."

Source ↗
Martin Fowler 2018-08-25 cultural

The State of Agile Software: Stop the Agile Industrial Complex

In his keynote at Agile Australia 2018, software architect Martin Fowler identified the 'Agile Industrial Complex'—the network of consulting firms, certification bodies, and framework vendors who impose standardized processes on teams rather than respecting team autonomy. Fowler argues this violates the first principle of the Agile Manifesto: 'Individuals and Interactions over Processes and Tools.' He states that 'the Agile Industrial Complex imposing methods upon people is an absolute travesty,' because teams perform best when choosing their own working methods. Fowler traces the problem to Frederick Taylor's separation of planning from execution, and advocates for letting teams determine their own processes through continuous retrospectives rather than accepting top-down methodological mandates.

"Agile promised to free people from process mandates. The industrial complex made process the commodity."

Source ↗

The big question

A design sprint is designed to answer "should we build this?" quickly. But does the format actually challenge the premise, or does it create a fast path to confirming what the team already believed?

passage

Reading

The Dev Loop: How Programmers Ship Code With AI

Every working program starts broken. A programmer's job is not to write perfect code the first time — it's to iteratively break, test, and fix until the system works.

The dev loop is the concrete cycle you run, over and over:

  1. Build — write or modify code
  2. Test — run it and see what breaks
  3. Debug — understand why it failed
  4. Iterate — fix and repeat

This loop happens fast. The best developers run dozens of cycles per hour. Each cycle tells you something: an error message, a silent failure, unexpected behavior, or success that proves your understanding was correct.

With an AI coding assistant (Claude, GitHub Copilot, Cursor), the loop accelerates further. Instead of writing code from scratch, you:

  1. Describe the problem to the AI
  2. Run the code the AI produces
  3. Show the AI the error when it fails
  4. Ask the AI to fix it with the context of the failure
  5. Test again

The AI doesn't run the code — you do. The AI doesn't know if the code works — you tell it. This is load-bearing. Your job is to be the AI's test harness.

Real example: Building a weather API client

You decide to fetch weather data from an API. You tell Claude:

"Write a Node.js script that fetches the weather for Seoul from the OpenWeatherMap API and logs the temperature."

Claude produces:

const fetch = require('node-fetch');
const apiKey = 'your-key';
const city = 'Seoul';

fetch(`https://api.openweathermap.org/data/2.5/weather?q=${city}&appid=${apiKey}`)
  .then(res => res.json())
  .then(data => console.log(data.main.temp))
  .catch(err => console.error(err));

You run it: node weather.js

Error: Cannot find module 'node-fetch'

You tell Claude:

"I got this error: Cannot find module 'node-fetch'. How do I fix it?"

Claude says: "You need to install it. Run npm install node-fetch."

You run the command, then run the script again.

New error: TypeError: fetch is not a function

You show Claude the error. Claude sees the issue — node-fetch v3+ uses ES modules, not CommonJS. It offers:

import fetch from 'node-fetch';
// rest of code...

Or: "Use an older version of node-fetch, or use the built-in fetch in Node 18+."

You choose the second. Run again.

New output: 16.4 (the temperature in Celsius)

Success. The loop closed. You now have working code and understand the actual flow: HTTP request → JSON parse → extract field.

Without the AI, this would have taken you longer and involved more dead ends — reading docs, guessing at syntax. With the AI, you spent less time searching and more time running and learning from actual behavior.

Why this matters

The dev loop trains your judgment. Every error teaches you:

  • What inputs the code expects
  • What outputs it produces
  • Where your mental model was wrong
  • How to ask for help in a way that gives the AI enough context

The faster you loop, the faster you learn. Waiting for a 10-minute build, or hesitating to run code because you're unsure, breaks the loop and kills your momentum.

Programmers who ship fast are not smarter — they loop faster. They run code constantly, fail cheaply, and adjust. Working with an AI partner means the loop can be even faster, as long as you stay in control: you decide what to build, you run it, you validate the results, and you decide what to ask next.

title

DOSSIER: THE DESIGN SPRINT

The Build–Test–Revise Loop

You don't think your way to a great product. You build your way there.

By the end of this dossier you will be able to operate a fast iteration cycle — build code, test it, learn from failure, and revise — and explain why looping beats planning.

1 / 8

Loading activity...

Answer key
## Answer Key

**Cycle 1: Build → Test (the first sort function)**
- Tested: Running the sort function with the given array of objects with date strings.
- Learned: JavaScript's `.sort()` with a Date comparator can correctly sort objects chronologically when dates are in string format; the basic ascending-order comparison works.

**Cycle 2: Test → Debug → Iterate (reverse order)**
- Tested: Sorting in reverse (newest first) by adding a minus sign.
- Learned: Simply adding a minus sign doesn't reverse the sort; you must reverse the operands in the comparison (b minus a instead of a minus b) to flip the order from ascending to descending.

**Cycle 3: Test (timestamp format edge case)**
- Tested: Whether the sort function still works when date strings include time components in ISO 8601 format (e.g., '2025-01-15T14:30:00Z').
- Learned: The JavaScript `Date` constructor automatically parses ISO 8601 format correctly, so the existing sort function remains valid even with more complex timestamp strings; the code is robust to that variation.

**Marking:** Award full credit if the student identifies the cycle boundaries (Build/Test/Debug/Iterate), names what was tested, and articulates one concrete technical lesson from each cycle. Minor wording variations are acceptable.
Task

Loop Run

Task: Run Your First Dev Loop With Claude

Your goal: Build a small working program using the dev loop.

Setup:

  1. Open a text editor or IDE (VS Code, Cursor, or a web playground like replit.com).
  2. Keep this lesson visible alongside your editor.
  3. Have a terminal or "Run" button ready.

The Build:

Tell Claude (in this chat, or a new Claude session, or your IDE's AI assistant):

"Write a JavaScript function that takes an array of numbers and returns an object with these properties:

  • count: how many numbers
  • sum: the total
  • average: the sum divided by count
  • min: the smallest
  • max: the largest

Example input: [3, 7, 2, 9, 1] Expected output: { count: 5, sum: 22, average: 4.4, min: 1, max: 9 }"

The Test:

Copy the code Claude gives you into your editor. Run it with your test input. Record the output.

The Iterate (if it fails):

If the output is wrong, show Claude the error or wrong result, and ask it to fix it. Run again.

The Deliverable:

Once it works, paste the final working code and write a 2–3 sentence summary:

  • What did the AI get right on the first try?
  • What did you have to ask it to fix (if anything)?
  • How many cycles did the loop take?
Open Claude Output · project
design-sprint · content dossier · teacher copy