How a product manager’s question changed who our invoice redesign is for, why one document has to do 3 jobs at once, and why I want designers prototyping fixes on surfaces they don’t own.
Invoices are a living document. One of our designers said that in our 1:1 this week while walking me through their work on how our invoices explain themselves, and I told them it’s an accurate term and I like it. One document has to work as a request for payment, a receipt and a record of what each appointment cost. So when a client pays their share and insurance comes back later with a different amount, it’s the same document with new numbers on it, and the client is left to work out why.
The designer’s first version was built to help clinicians explain the invoice to their clients. Then a product manager asked a question in a thread that changed who the project is for: the clinician only needs to explain things if the client doesn’t understand them. The designer told me they’d gotten it wrong at first, and I appreciated hearing it, because a turn like that is easy to resist once you’ve built a first version around the other answer.
The clinician only needs to explain things if the client doesn’t understand them.
Putting the client first moved the layout toward something closer to a ledger: a summary at the top, then a ledger for each appointment below it, and the separate summaries for each appointment will likely go. It also exposed a case a simple layout can’t handle. Some practices bill insurance at their full fee so that the contracted rate comes back correctly, which means the first number on the invoice isn’t what anyone expects to pay. For that, the designer has been studying statements that label every line explicitly: the amount billed, what insurance paid, any discounts and what you’re responsible for. One of them was so clear that my only reaction was, no ambiguity at all.
I asked one question I’d ask anyone designing around money: philosophically, are you and the team feeling like the less math clinicians and clients have to do, the better? And if not, what’s the principle guiding the UX decisions? A principle like that settles a lot of small layout debates before they start.
The timing of the work taught a lesson too. This designer took the earliest version to the people closest to the problem first, a few designers who know billing well and their product manager, and only then to our broader crit. I’d keep doing it in that order: you take it early to the people with the most expertise, and you broaden it once you have stronger data points and talking points. By the time it reaches the wider team, they’re poking holes in something that already feels solid, which is a much better use of everyone’s time.
Then the part I’d like every designer to hear. The full fix for a confusing balance doesn’t live only on the invoice. If something in the ledger changes, the client should get a push alert, open the app, see the update and not freak out. That app belongs to another team, so this designer can’t ship that piece. They do have the skills and the tools now to prototype it with AI and show that team what’s missing. Maybe the team never builds it, and the designer will still have covered the full end-to-end experience, which is what we need every designer to do, and they can stop there. If designers aren’t willing to overstep a little to do that work, we’re never going to make the case for the broader change.