Design around progress, not features

Open a typical SaaS dashboard and read it the way a user does. Reports. Contacts.

Campaigns. Integrations. Settings.

Analytics. A tidy row of capabilities, each one representing months of roadmap work, each one a door the user could open.

Now consider the question that user actually arrived with. It's almost never "which of these modules shall I explore?" It's something more like: am I on track?

What's working? What should I do next? Is anything about to go wrong?

The dashboard answers none of it. The user is holding a question about progress and the product is answering with an inventory.

That mismatch is so common we've stopped seeing it, and I've become convinced it's one of the most expensive defaults in product design.

Why products end up shaped like org charts

Nobody chooses feature-oriented design. Teams fall into it because features are how companies think. Roadmaps are lists of features.

Squads are organised around features. Databases have tables for the objects features manage, and navigation ends up mirroring the schema.

The product's information architecture becomes a diagram of the company's internal structure, one honest layer at a time.

Users, meanwhile, don't experience your product as structure. They experience it as a journey through a goal: some uncertainty, a series of decisions, and a need for evidence that they're getting somewhere.

Users do not buy features. They buy evidence that they are moving forward.

Every design decision that makes forward movement visible earns trust, and every screen that presents capability without direction quietly asks the user to do the orientation work themselves.

I keep meeting this pattern across completely different products, which is what convinced me it's a principle rather than a preference.

The same lesson, three products

At LeadGenius, I worked on campaign creation for a B2B platform. The instinctive framing of that work is "design a campaign builder," and a builder is a feature: a capable surface with many controls.

But no user wants a builder. They want a campaign, launched, working, producing results. Reframing the job as "get the user to a launched campaign" changed the design completely.

Instead of exposing every option, we used a guided wizard and templates that moved people through decisions in a sensible order, showing how far they'd come and what remained. Same underlying capability.

Entirely different experience, because it was organised around the user's progress rather than the feature's anatomy.

At Omi, the AI companion I'm building for UK first-time buyers, the temptation was to lead with the obvious feature: a mortgage calculator, maybe a readiness score.

But a first-time buyer doesn't wake up wanting a calculator. They wake up not knowing where they stand.

The positioning we landed on is the progress framing in its purest form: know where you stand, what's holding you back, and what to do next. Status, blockers, next actions.

When I evaluate an Omi screen now, the test isn't whether a feature works. It's whether the user leaves the screen more oriented than they arrived.

And in copy work for a landlord product, the first-draft message was a feature list: a dashboard for rent, repairs, expenses and tenants.

The version that actually landed promised something else: each property becomes easier to track, improve and grow. Same capabilities.

But one describes software and the other describes the landlord's life getting better, and only the second one is a reason to sign up.

Three products, three domains, one pattern. Features are the company's structure. Progress is the user's structure.

The product should be organised around the second one, because the user is the one who has to live in it.

The translation exercise

The practical tool I use for this is deliberately simple. Take any feature and force it through the sentence: this feature exists so the user can ___, and they'll know it worked when ___.

The first blank must be a milestone or a decision, not a capability. "So the user can manage contacts" fails; managing is what the software does.

"So the user can stop chasing payment status by email" passes; that's a change in someone's week. The second blank forces you to name the evidence, and evidence is the part products most often forget to show.

Plenty of products deliver progress the user never perceives, and unperceived progress does nothing for confidence, retention or renewal.

Run every main feature through that sentence and you have a progress map of your product. Then the interesting design questions surface.

Does the interface actually show status, or must the user assemble it from fragments? When something is blocked, does the product say so and say why?

Is there ever a clear next best action, or does every screen present forty equal options? When the user accomplishes something, is it acknowledged and visible, or does the achievement vanish into a table row?

What changes when you take this seriously

Navigation shifts from nouns to situations. Labels organised around what the user is trying to establish ("what needs my attention") rather than the objects the database stores.

Even keeping conventional labels, ordering by user priority instead of internal importance changes how the product reads.

Empty states become starting points instead of dead ends. Feature-oriented design treats empty as a display problem: there's no data, say so.

Progress-oriented design treats empty as the user's very first step: here's where this fits your journey, here's the fastest way to get value from it, and here's what will exist once you do.

Dashboards become orientation tools. Their job is answering the arrival questions: where do I stand, what changed, what needs me, what's next.

A dashboard that fans out into feature launchpads has abdicated that job to the user.

Messaging stops describing the machine. Every notification and email gets rewritten from "here is a feature" to "here is what this means for where you're heading."

One caution, because this idea has a degraded form. Progress design is not progress bars everywhere.

Streaks, badges and completion meters attached to activity the user doesn't value aren't progress, they're decoration, and users learn to distrust them quickly. The bar isn't the point.

The advancement is. If the underlying movement isn't real and meaningful to the user, no visualisation will save it, and faking it costs you the trust that real progress would have built.

And to be clear about the other side: none of this is an argument against features. Features are how progress gets enabled; capability is the raw material of every milestone I've described.

The argument is about organisation. Build features, absolutely. Just don't make the user experience your architecture.

Try it on your own product

Here's the exercise I'd leave you with. Take the five main items in your product's primary navigation. For each one, write down the progress a user is trying to make when they click it.

Not what the feature does. What the person is trying to move forward.

If the answers come easily, check whether your interface actually shows that movement: status, blockers, next action, evidence of completion. If the answers don't come easily, you've learned something more important.

You've found parts of your product that exist because they were built, not because someone is going somewhere with them.

Somewhere behind every click is a person asking whether they're closer than yesterday. The products that answer that question are the ones people stay with.