The Week Before the Build
5 auditors. 90 minutes. One rename.
Tuesday morning, Day 2. A Big Four audit team is watching its compliance lead draw a state machine on a whiteboard. By Friday afternoon the screen she is describing will have stalled five auditors at the same column header. The fix will be a single word.
A design sprint runs on a fixed shape. Monday the expert is in the room with the whiteboard. Tuesday and Wednesday are the prototype. Thursday the prototype meets real users. Friday the fixes land. The audit roll-forward project ran on this shape.
The firm was about to rebuild the screen its audit teams used daily, the one that moves a client's job from last year into this year. The default path on a tool like this is to design in isolation, build, ship, and discover the friction six months in. By then the fix costs ten times what it cost on Wednesday. The sprint was the cheaper bet.
The screen moves a client's job from last year into this year. Every auditor at the firm uses it, every cycle. The plan was to rebuild it on assumptions.
Roll-forward is a hard model to get right. Conglomerate clients inherit data down a list of subsidiaries. Independent clients inherit nothing. Inside the same flow an auditor might handle a board change, a criteria change, a new database to register, a job memo. The combinations matter. The wrong toggle on the wrong row produces the wrong outcome for a year.
Shipping that screen on assumption was the expensive path. Every auditor would hit the friction. Every job, every cycle, until someone wrote a workaround into the training deck. The sprint swapped six months of slow discovery for five days of fast discovery, while changes were still cheap.
The shape of the week
- 01
Expert interview. Day 1, inside the firm, with the compliance lead. She drew the state machine on a whiteboard. Which combinations of selections produced which job outcomes, where the inheritance branched, where the exceptions lived. The cheapest hour of the project, and the one that decided what the prototype was actually testing. Skip this layer and the prototype tests the designer's guesses, not the firm's logic.
- 02
Concept and prototype. Around 70 clickable screens covering two end-to-end scenarios. A head client with seven subsidiaries. Three independent clients, one expired, one needing a new database registered mid-flow. Most of those screens existed to be thrown away. The point of a prototype is not to keep it. It is to give a user enough of a path that they can show you where the path breaks.
- 03
User testing. Five one-on-one sessions, back to back, in a two-camera testing room. A facilitator stayed in the room with the participant. The client team watched the live feed from the studio next door, so the auditor wasn't reading a crowd. Five sessions is the number that surfaces a pattern, a finding Jakob Nielsen put numbers behind in the 90s and that holds up every time the sessions are run properly. Three confirms a suspicion, four and five close it.
- 04
Roundtable. Same five participants in the afternoon, no fixed agenda. Themes from the morning surface when the testing pressure comes off. Auditors who answered narrowly during their session started telling stories across each other's tools, processes, and quiet frustrations. The most useful conversation of the project happened here.
- 05
Iteration. Fixes landed the same week, not next quarter. Even with the expert at the whiteboard and a careful prototype, the sessions surfaced things nobody had predicted. Each layer of the sprint exists to catch what the previous layer missed.
Day-one reaction, before they touched the prototype
“Ugh, another system to learn.”
The moment that surfaced
Session 3, an auditor pauses with the cursor over a column. She reads the header, looks back at the row, reads the header again. Twenty seconds pass before she clicks. The same pause had shown up in sessions 1 and 2.
The header just said "Database." In that column an auditor was supposed to pick which record to roll the previous year's data into. The firm's audit platform. A specific system with a specific name.
The word "Database" carried at least three meanings inside this firm. The audit platform. The client-management system. The new database the auditor was about to register a few clicks later inside the same flow. The header didn't say which one. Five out of five hesitated. By the time the live feed lit up between sessions the team next door was already messaging the fix.
The fix was a rename to the explicit platform name with a short description under each option. Not a redesign. A naming pass. Caught in a sprint, the cheapest change of the project. Found in production, the most expensive moment in the flow. Every auditor, every job, every cycle, until somebody wrote a training module to paper over it.
What the week bought
The firm walked out of the week with a tested direction, a decision log, and a handful of small, specific changes that came directly out of the sessions. The redesign went into the build with the friction already named and the riskiest assumptions already retired.
A sprint will not ship a finished product. It will not replace the discovery a long-running team does over a year of close contact with users. What it does is point the next quarter of build at the right thing. On a screen every auditor touches every cycle, that is what the week buys.
- Column header rename. "Database" became the explicit platform name with a short description under each option. The smallest change in the project and the one that recovered the most time, found in 90 minutes of watching real auditors.
- Inheritance checkbox dropped. Replaced with a thin colored bar on the left edge of each cell, so the relationship to the head client reads at a glance and the row stays quiet when nothing diverges from the parent.
- Button labels rewritten where the sessions caught them. "Undo" read as destructive. "Check iPower" was ambiguous about who was doing the checking. One participant asked for "Proceed to next phase" so she'd know what she was committing to before she clicked.
- Sync-status bar at the top of the service view. It doesn't fix organisational trust on its own, but it removes the small moments of doubt that compound across a long flow.
- Colored column groups, tested and dropped. The bucketing by function (risk analysis, the job itself, database registration) read clearer in Figma and felt like a traffic jam in the wild. Cost of testing it: one afternoon. Cost of shipping it: a development cycle and a revert.
Why the sprint earns its week
Sprints work because they collapse the discovery loop. Expert interview, prototype, real users, iteration, all of it inside one week instead of spread across quarters. Most of what teams discover in production shows up in a test session if the sprint is set up right. Cheap to fix on Wednesday. Expensive to fix six months in.
Every layer of the sprint earns its place. The expert interview points the prototype at the right logic. The prototype gives the user a surface to break. The user testing surfaces what the team is too close to see. The roundtable catches what testing pressure suppresses. The iteration closes the loop while attention is still on the problem. Drop a layer and the next one tests the wrong thing.
Naming inside an enterprise system is design work, not copy work. Users are trained on what specific words mean inside their tools. The cleanest flow in the world loses them on a label that reads wrong, and the cheapest fix in the project lives somewhere on a header. Watch a user read every label out loud before shipping the screen.
The loudest feedback in user testing is rarely about the screen. One auditor opened with "ugh, another system to learn" before touching the prototype. That sentence was about the broader platform, not the toggles. The screen in front of an auditor is the only place that frustration has to land, even when the screen is fine. Hear it for what it is.
Want this kind of result? Start with the version that matches your situation
These pages break the work down by the problem teams usually feel first, before they know what kind of engagement they actually need.