I joined a new team as a senior engineer, working on a large ecommerce site. The product itself was well established. The initiative was not. It was new, and on the question of what we should actually build for it, the sky was the limit.
That's a stranger position than either a blank canvas or a well-specified backlog. Nobody handed us a spec, and nobody was going to. The job wasn't build the thing, it was figure out which thing is worth building, and then defend that choice to people with opinions. We had to narrow down before committing engineering time to any of it.
What I ended up building, so you know where this is going: a brief goes in, and a few minutes later several genuinely different mockups come out, each one a plain HTML file you open in a browser.
Two things were fixed, though. It had to live inside an existing product, with existing patterns and existing pages around it. And we had to integrate a third-party chatbot, which we wanted to feel like a designed part of the experience rather than a widget bolted into a corner. So the real shape of the problem was a wide-open question sitting inside a fairly tight box. Remember the chatbot. It comes back later, and not in a flattering way.
Here was the team available to do that: one and a half developers, one designer, and two product owners who were both part-time. A design sprint was obviously the right instrument. It is designed for exactly this, a wide-open space and no agreed direction. There was equally obviously no way to fund five days of everyone's time to run one.
Which sets up the failure mode. When the space is that wide and there's no capacity to explore it properly, you don't stay open. You build whichever idea got articulated best in the first week, and you find out in three months whether it was the right one. Skipping divergence costs you most when you had the most room to diverge.
What a design sprint is, if you've never sat through one
Five days, roughly: Understand the problem, Sketch possible solutions, Decide which one to build, Prototype it, Validate it with real users at the end of the week.
The part that matters for the rest of this post is that Sketch gets an entire day of its own. It's the diverge day: the one where the job is to open the space up rather than narrow it down. That is not padding. Divergence has to be protected from production: the moment you start building, you stop generating options, and whatever you happened to be building becomes the plan. A separate day is how you make sure the Decide day has more than one thing to decide between.
The cost of all this is also the reason most teams never do it: five days multiplied by everyone in the room.
I automated one day of it
Not the sprint. One day of it: Sketch.
I picked that day because it's the only one where the output is quantity of different options, and that's the one thing here you can parallelize without a room full of people. You cannot parallelize Decide; that's a conversation. You cannot parallelize Validate; that needs actual users. But "produce several unrelated takes on the same brief" is embarrassingly parallel work that we were about to skip entirely for lack of time.
So I wrote a brief (the problem we were solving, who it was for, what had to be on the page, the tone) and had Claude Code generate a handful of directions from it. Note what the brief does not say: what the thing should look like, or which approach to take. That's the part I wanted back.
Here's the whole loop, recorded afterwards on a throwaway brief rather than our actual work. One line in, an interview to fill in the gaps, then six agents building three directions at two fidelity tiers each:
Roughly four minutes end to end, sped up here. The part I'd point at is the middle: six agents dispatched at once, each building one direction, none of them able to see what the others are doing. That last bit is where the real problem is.
The failure mode: three directions that are the same direction
Ask a model for "three mockup directions" and the pull is toward one layout with three different headlines. Most of the instructions in this thing are written against that pull.
The fix is a single decision about where the angles get chosen: the orchestrating agent picks all three itself, up front, and never delegates that to the agents doing the building.
brief.md
│
▼
┌─────────────────────────┐
│ orchestrating agent │
├─────────────────────────┤
│ reads the brief │
│ resolves design tokens │
│ picks the 3 angles ◄───┼── never delegated
└─────────────────────────┘
│
│ 6 agents, dispatched in one message
┌───────────────────┼───────────────────┐
▼ ▼ ▼
─ angle A ─ ─ angle B ─ ─ angle C ─
agent 1 lofi agent 3 lofi agent 5 lofi
agent 2 hifi agent 4 hifi agent 6 hifi
every agent gets: the full brief, the resolved tokens, its tier's rules
the only variable: which angle it was handed
and none of the six can see the other five
That's forced by how the parallelism works. Each direction is built by a separate agent, all dispatched at once, and none of them can see the others. That isn't a feature I added, it's what fanning out means. So if you let each agent invent its own angle, all three are inventing from the same brief in the dark, and you get three siblings. Choosing up front is the only moment in the run when all three candidates are visible at the same time, so it's the only place convergence can be caught.
What counts as a real difference is also written down, because "make them distinct" isn't an instruction a model can act on: each angle has to have its own information hierarchy, its own idea of what belongs above the fold, and one signature element. Not a different accent color.
Separately, each direction gets built twice: a grayscale lofi wireframe and a polished hifi version. That's not about divergence, it's about which conversation you're having. Lofi keeps people on structure before color hijacks it. Hifi is what you can put in front of a stakeholder and get a reaction to.
What came back
Better than I expected, which is most of why I'm writing this up.
We got several directions that were genuinely different from each other, not palette swaps, each viewable as a wireframe and as something close to real. Instead of a blank wall on Monday, the team had things to point at and argue about, which is most of what the Sketch day is for.
I can't tell you which direction won, because we haven't picked one yet. It's too early to know which of these survives contact with the roadmap. That's the honest shape of a divergence story: still having options at this stage is the exercise working, not a chapter I'm withholding.
The output itself is unglamorous: self-contained HTML files, no build step, open them in a browser.
The same direction, wireframe first and then polished:
Where it fell over: directions we couldn't build
The convergence problem was a flaw in how the tool was built, and I caught it before it cost anyone anything. This one is different. It was a flaw in how I used the tool, and it made it all the way to finished screens before anybody noticed.
Now the chatbot comes back. Some of the directions were not technically feasible. They designed the integration the way you'd want it to work rather than the way it does work, assuming a level of control over the conversation surface that a third-party dependency doesn't hand you.
This was my fault, not the tool's. I had written the goal into the brief (integrate the chatbot, make it feel designed) without writing in what the integration could and couldn't do. The generator only knows the constraints you give it, so it happily designed past the ones I'd left out, and produced some lovely screens we could never ship.
The fix is boring: write your technical constraints into the brief like they're requirements, because they are. What the third party won't let you restyle, what you can't intercept, what has to stay in an iframe. And budget a feasibility pass over whatever comes back.
What this does not replace
This is not a design sprint. It doesn't give you a facilitated Decide session. It doesn't put anything in front of a user. And it produces none of what a real sprint quietly produces best: a team that argued in a room for a week and now shares an understanding of the problem. That alignment is half the value of a sprint and no generated mockup creates it.
What it does is make the divergence part cheap enough to happen at all. If you can run a real sprint, run it, and maybe use this to give the Sketch day a running start. If you can't, this gets you a set of directions to react to instead of a blank wall, which is a better starting position than the one we were in.
Try it
I cleaned it up and put it here: rapid-prototyping-kit. Brief in, directions out, bring your own design tokens.
Top comments (0)