Your Design Isn’t Done Until It Tells a Story

I watched payroll experts stare blankly at a system we built — and realised the problem wasn’t them. We had built exactly what they asked for. But it wasn’t what they needed.

The Brief

Last year, my team and I were handed a clear brief: rebuild a payroll system that was painful to use, make it configurable, scalable, and sellable as a SaaS product. Simple enough. We got to work.

We dove into research — stakeholder meetings, prototype testing, end-to-end process mapping, reverse-engineering payroll from first principles. With a tight timeline and very little handholding from the department, we figured most of it out ourselves. By the time we were done, we were confident. We had automated the painful parts, built in scalability, and covered every requirement they’d asked for. We walked into that presentation room ready.

The Room

The stakeholders approved every process. The logic was sound. Every requirement was met. Then came the silence.

“It’s a lot,” one of them said.

“Is there a way to make it simpler?”

Simpler? We had already simplified where we could. These were payroll experts — people who had been running payroll long before we wrote a single line of code. How could they be confused?

Some on the team shrugged it off as resistance to change. But one comment stuck with me:

“It’s confusing knowing what to set up and knowing where to go. The UI is really great, though. Maybe we’ll just need training.”

In UX, that word is a red flag. If users need training to navigate a system built for their daily work, the design hasn’t finished its job.

The Realisation

New features rolled in, tweaks and updates, the engineers adapted. But I couldn’t let it go.

I went back through the system myself — not as a designer looking at screens, but as a first-time user trying to figure out what to do next. And I felt it immediately. The answer became clear. Thirteen modules, each comprehensive and correct — and no thread connecting them. Every screen answered, “What can I do here?” but none of them answered, “What should I do next?”

The user was always lost. Not because the system was broken. Because it wasn’t telling a story.

As Don Norman, the father of user-centred design, puts it: “Good design is actually a lot harder to notice than poor design, in part because good designs fit our needs so well that the design is invisible.”

Our system was visible in all the wrong ways. Every click required a decision. Every module demanded orientation. The cognitive load was invisible to us because we had built it — but it was crushing to everyone else.

The Work

I took it upon myself. No one asked me to. The stakeholders had already signed off and moved on. But I pulled in another designer, and we sat with it for days.

The question we kept asking was: how do you make something genuinely complicated feel simple without removing what makes it powerful?

The answer didn’t come from adding anything. It came from reframing everything.

I knew about storytelling in UX long before this project. But it took building something this complex to truly feel what it meant in practice.

We stopped asking “What does this module do?” and started asking “What is this module saying?” What is it telling the user about where they are in the process? What story does the system tell from the moment someone logs in until payroll is complete?

Thirteen modules collapsed into four words: Setup. Run. Approval. Report.

Four words. That’s the whole story.

But renaming wasn’t enough. The story needed to be felt at every level.

We added progress tracking to every module card in Setup — so users could see exactly what they’d configured and what remained.

Every card tells the user exactly where they stand

We built a Quick Start Guide that broke the entire setup into nine timed steps, so nobody stared at a blank system wondering where to begin. We made tutorials accessible from within the flow, not buried in a help centre.

Nine steps. Timed. No guessing.

And crucially — if a user tried to run payroll before completing setup, we didn’t block them with an error. We met them there. We showed them their progress, what was done, what wasn’t, and exactly what they needed to finish. The system guided instead of gatekeeping.

Not a dead end. A redirect with context.

That’s the difference between a system that works and a system that tells a story.

When we presented the redesign, every single person in that room followed along — including people who had nothing to do with payroll. No confusion. No silence. Just complete understanding.

The feedback said everything:

“You’ve built the simplest and easiest product for us. I don’t have to be tense anymore during payroll week.”

Months later, payroll has been running consistently. Not a single support request about how to use it. Sales had one response: “We can’t wait to sell this to more clients.”

That’s what a story does. It doesn’t just guide the user through a system. It makes them feel like the system was built for them.

What This Actually Means

Steve Jobs once said, “Design is not just what it looks like and feels like. Design is how it works.”

I’d push that further — design isn’t done until the user understands how it works without being told.

The payroll system didn’t get simpler. It became clearer. The complexity was still there — every configuration, every pay grade, every approval layer. We didn’t remove any of it. We gave it a narrative.

That’s the job. Not to make things beautiful. Not even to make them functional. To make them legible. To ensure that anyone who touches what you’ve built understands instinctively what it’s doing, where it’s going, and what they need to do next.

As Jakob Nielsen emphasises in his usability heuristics, good design reduces cognitive load — it minimises memory effort and shows users what they need, so they can focus on the work, not the tool.

Your design isn’t done when all the features work. It isn’t done when the UI looks good. It isn’t done when the stakeholders sign off.

It’s done when the system tells a story so clearly that the user never has to ask, “What’s next?”

Next time you review a design, don’t just ask: Does it work?

Ask: Does it have a beginning, a middle and an end? Does it guide without instructing? Does it answer questions before the user thinks to ask them?

If not, you’re not done yet.