Making complex products feel obvious

The products we admire most share one trick: they make something hard look like it was never hard at all. You don't notice the design. You notice that you got the thing done. That feeling is easy to describe and difficult to build, because the complexity underneath never actually goes away. Someone has to decide where it lives.

That decision — where the complexity goes — is most of the job. Here's how we think about it.

Complexity is conserved. Choose who carries it.

There's an old idea in interaction design that every system carries a certain amount of irreducible complexity, and the only real question is who deals with it: the people who build the product, or the people who use it. We find that framing useful because it removes the fantasy that a clever enough designer can make difficulty disappear.

It can't. What design can do is move it. A form that asks for twelve fields can become a form that asks for three, if the product is willing to infer, default or look up the other nine. A settings screen with forty toggles can become four sensible choices, if the team is willing to hold an opinion. Each of those moves costs engineering time and a little nerve. Each one also takes weight off someone who never signed up to carry it.

When a product feels complicated, the cause is rarely that the problem is complicated. More often the team handed the complexity to the user because that was the cheapest place to put it.

Start from the job, not the data model

The most common way complex products go wrong is that the interface quietly mirrors the database. There's a table for facilities, so there's a screen for facilities. There's a table for bookings, so there's a screen for bookings. It's tidy for the people who built it and baffling for everyone else, because nobody arrives wanting to "view a facility record." They arrive wanting to know where their kid can swim on Saturday.

When we built the Sport Calgary recreation-discovery map, the underlying data was genuinely large: 1,286 facilities on live data, each with its own details and its own operator. The tempting design was a directory — searchable, filterable, complete. What people actually needed was a map, a question and a short list of good answers. The completeness is still there. It just isn't the first thing you see.

The same data serves a very different person, too: the staff member responsible for keeping it accurate. So they get their own dashboard, shaped around their job rather than the public's. Two audiences, two front doors, one source of truth. Serving both from a single interface would have made both worse.

Hide the machinery, never the consequences

Progressive disclosure — showing the essentials first and revealing depth only as people need it — is the workhorse of obvious design. But it has a failure mode worth naming. You can hide the machinery of a product, and usually you should. You should never hide what it's about to do.

This matters most when the stakes are real. Arisium, the governed agentic education platform we're building, does meaningful work on a teacher's behalf, and the system underneath is not simple: autonomy tiers, approval gates, rules about what an agent may do on its own and what it must bring back for review. A teacher doesn't need to understand that architecture to use it. They do need to know, clearly and at the right moment, what is waiting for their approval and what will happen when they give it.

Obvious doesn't mean hidden. It means the right thing is visible at the right moment, and nothing surprising happens off-screen.

That's the line we try to hold. Tuck the configuration away. Put the consequence right where the decision is made.

Obvious is earned in the edge cases

Almost every product looks simple in the demo. The happy path is short, the data is clean, the network is fast. The difference between a product that feels obvious and one that merely looks it shows up everywhere else: the empty state on day one, the error that explains what to do next, the half-finished task that's still there when you come back, the declined permission that doesn't leave the screen broken.

We spend a disproportionate share of design time on those moments, because that's where trust is won or lost. Someone who hits a dead end once starts treating the whole product as fragile. Someone who gets a clear, calm answer at the worst possible moment starts to believe the product knows what it's doing — and gives it more room next time.

A few habits help:

• Write the words early. Labels, buttons, error messages. If we can't name a thing plainly, the concept usually isn't clear yet, and no layout will rescue it.
• Default to a decision. Every option we expose is a question we're asking someone else to answer. We ship a strong default and make changing it easy.
• Borrow the platform's grammar. People already know how their phone behaves. Standard components and familiar patterns spend none of their attention; invented ones spend a lot.
• Test with the least patient person you know. Not the expert. The person who will give it thirty seconds and move on.
• Remove before you explain. When something confuses people, the fix is more often taking an element away than adding a tooltip.

Why it's worth the effort

Making a product feel obvious is slower up front. It means more conversations about what the product is for, more prototypes thrown away, more engineering spent on inference and defaults instead of on extra screens. It's tempting to treat it as polish — something to get to after launch.

We'd argue the opposite. Clarity is what lets a complex product get adopted at all. It's what keeps support conversations short, onboarding light and the roadmap flexible, because a product built around a clear job is far easier to extend than one built around its own internals. The complexity was always going to be paid for. The only choice is whether your team pays it once, or your users pay it every day.

If your product does something genuinely complex and you want it to feel like it doesn't, we'd love to talk.