A Prototype Users Can Touch
You could spend two weeks designing the perfect review screen for Farhan's clerks. Or, two days after the first invoices flow through the pipeline, you could put a plain page in front of Farhan showing yesterday's real invoices with the wrong charges highlighted, and learn more in one hour than two weeks of guessing would teach you. Clerks cannot react to an architecture diagram. They react instantly to their own invoices.
The rule
Real data, real user, days not weeks — then watch, don't explain.
- Real data. Clerks recognise their own carriers and invoices, so they spot what is wrong immediately. Sample data hides the messy cases that matter.
- Real user, real task. The screen does one job: show each flagged charge with the amount billed and the amount expected, and let the clerk approve or dispute it with a reason.
- Days, not weeks. Use boring, fast tools: a component library, a simple server-rendered page, even an internal-tool builder. Polish comes after the screen proves it helps.
- Watch, don't explain. Give the user a task and stay quiet. Where they hesitate, the design is wrong. If you have to explain a button, fix the button.
Frontend basics still matter in a prototype. The key numbers must stand out, the page needs clear loading and error states, and people who check hundreds of invoices a day need keyboard shortcuts.
<tr class="flagged">
<td>Fuel surcharge</td>
<td>₹6,300 billed</td>
<td>₹5,040 expected (12% of ₹42,000 base freight)</td>
<td><button>Dispute</button> <button>Approve</button></td>
</tr>Showing where the expected figure came from lets the clerk trust it, or spot that the rate card itself is out of date.
The shortcut
Run a silent session: give the task, stay quiet, note every hesitation, fix the biggest one, and repeat the next day.
Build
Two days after the thin slice first runs: one page listing yesterday's flagged invoices from the busiest carrier.
The trap is polishing too early: colours, logos and animations on a screen nobody has used yet. Its twin is demoing on sample data, where every invoice is clean.
Drills
Answer fast — trust the rule.
Which is the best first prototype for the clerks?
During a session, Farhan asks, "What does this button do?" What should you conclude?
Why add keyboard shortcuts to a prototype for clerks?
What should appear beside a flagged fuel surcharge?
Why run the prototype on real Harbourline invoices rather than neat sample data?
Remember
- Real data, real user, days not weeks — then watch, don't explain.
- Shortcut: the silent session. Give the task, stay quiet, note hesitations, fix the biggest, repeat.
- Trap: polishing before anyone has used it, or demoing on clean sample data.