Why SaaS design needs Object-Oriented UX

The Bottleneck Moved

Designers are building direct to code now. Cool. Engineers are designing. Cool, cool. Product managers are making 50-page PRDs, and dumping them in Claude Code. Cool, cool, cool. Everyone is a unicorn now. Describe a screen to an AI tool and a working version appears in minutes: styled, responsive, plausible. The production bottleneck that shaped a generation of design process is gone.

But what is plausible is not necessarily sustainable. AI will cheerfully generate beautiful, coherent-looking UI on top of a broken conceptual model. For example, imagine a slick, custom project management app. Every screen looks right. The chasms in functionality don’t show up until users try to use the app and find that they can’t do key things: “project” means three different things in three different places, and the thing they made on one screen doesn’t exist on another.

Is the user’s project a marketing GTM launch with a defined start and end or is the project actually a team that work moves through indefinitely like in Jira? Or is their “project” a Russian doll of nested projects like managing the construction of a hospital over two years?

I once led that conversation: Trello and Jira each define a project, but OOUX illuminated that they are not at all the same object. Building used to be slow, and the slowness was productive tension. While estimates were argued and sprints dragged, teams had time to fight about what a project actually was. AI removed that friction, and the deliberation left with it.

Now anyone can ship a shiny, demo-ready thing before the team asks whether its nouns agree with the rest of the product, and we all know that sparkly demos are persuasive: they end conversations that should still be open. That’s what made clarity expensive. It used to be a byproduct of the process; now it’s a deliberate purchase. You have to choose it, budget for it, and defend it against the pull of one more shiny prototype, while conceptual debt compounds at the speed of AI.

I’ve written before that we can’t vibe code our way to intentional futures.

Paraphrasing Giulio Frigieri, the prototype proves what is possible; it proves nothing about what is viable. When production is nearly free, the differentiating skill is having the right clarity before you generate anything. There’s a name for that discipline: Object-Oriented UX. I first encountered it when I brought Sophia Prater (founder of the OOUX movement, whose complexity-untangling work spans Facebook, Mastercard, Delta, and CNN) to Trello for a week of training, and I went on to certify as an OOUX Strategist.

AI can generate endless screens. It cannot know your users’ mental model.

That’s your job.

OOUX is a Philosophy

Sophia’s definition: OOUXers deliberately align their software to their user’s real-world mental model of concrete, defined objects, so that abstract digital worlds can be as naturally intuitive as the physical world we evolved in.

Conventional UX practice starts with verbs: tasks, actions, user stories, the things a user can do. OOUX starts with nouns: the people, places, and things in the user’s mental model. You map the nouns first, before you get anywhere near calls-to-action, so the product’s structure matches how users already think instead of hoping they’ll adapt to yours. The volume of training and support documentation to features ratio is a good indicator of whether you have done this successfully.

Sophia’s metaphor for system objects is cookie cutters and cookies. The object is the cutter, the archetype. Every instance created is a cookie. And here’s the part most SaaS teams miss: you don’t sell cookies. You sell cookie cutters, and people use them to make their own. Or actually maybe a closet system is a better metaphor, more on that below.

OOUX isn’t a rigid process any more than a transit map is a train schedule. It’s a way of seeing, built on a fact about humans that predates software: people think in objects, and they need consistent, recognisable objects to understand any environment, digital or otherwise. 

The Abstraction Ladder

Not every product needs this discipline equally. The further your product sits from the physical world, the more deliberate your object modeling has to be. Think of it as a ladder.

On the bottom rung: eCommerce. When I designed at lululemon, the objects were handed to us by reality. Leggings are the object; a product page renders an instance; a gallery arranges instances by activity or fit. The digital thing represents a physical thing you can hold. The real world did the modeling for me. My job was to render it faithfully.

One rung up: content. Netflix’s objects are no longer physical, but they’re still stable and universally understood. A show has episodes; a movie has a runtime and a genre. The catalogue is the mental model. Users spend their time browsing someone else’s nouns, and those nouns arrive pre-defined.

Near the top: work management. Trello, Jira, and kin don’t sell content at all. They sell containers. A board, a list, a card: these are empty archetypes that mean nothing until a user pours their work into them. Trello is the Container Store of knowledge work, the Elfa closet system for whatever chaos you bring to it. And what people want to organise drastically changes the containers. Is this shoe storage box for boots or flip-flops? Depends entirely on the user.

That flexibility, and accompanying ambiguity, is the difference, and it’s why work management design is a different discipline. You’re designing a system of super nouns that has to flex around user nouns you may never see: a wedding, a sprint, an HVAC install, or a criminal investigation (I want to see that Trello board). Your objects hold their objects.

The less tangible your objects, the more deliberate the modeling must be, and work management is about as intangible as it gets.

ORCA: The Practice Behind the Philosophy

A philosophy needs a practice, and Sophia built one: ORCA, an iterative framework that translates research and requirements into design structure by asking four questions in order.

What are the Objects in the user’s mental model?
What are the Relationships between them?
What Calls-to-Action does each object offer?
And what Attributes make each object what it is?

This article is the why, not the tutorial (ORCA deserves its own piece). But one benefit matters here, especially for leaders: ORCA moves the critical conversations earlier. Dependencies, scope, permissions, the question of what happens to a card when its board is archived: these surface while the model is still cheap to change, not three sprints into build. Designers, PMs, and engineers end up with a shared conceptual language before anyone iterates through screens.

And a shared conceptual language before you build is exactly what your newest teammate needs most, be they a new grad or AI.

Your Object Map Is Your Prompt

OOUX has become disproportionately valuable now that designers are shipping code, and even when engineers are designing. Recently, I joined a day-long hackathon with Sophia Prater where we ran a fast round of ORCA before vibe coding an app. The results were spectacular vs what I have seen people creating off vibes alone. I’m thinking of running a similar exercise as a workshop offering.

An object map is a spec an AI can actually follow. Objects translate to data models. Attributes become fields and props. Relationships define the schema and the navigation. Calls-to-action are the interactions. The output of ORCA maps almost one-to-one onto the structure AI coding tools need to build coherently. It’s the difference between handing a contractor a blueprint and describing your dream house over the phone.

AI drifts without a stable noun system. Generate your product screen by screen (verb-first, the way most prompting naturally goes) and you’ll get five subtly different versions of “task” across five surfaces. Each screen is locally reasonable but the system is uncomfortably incoherent. An object model is the consistency contract that keeps a hundred generated screens describing one product.

Try it. Prompt a tool with “build me a project tracker” and you’ll get something generic and confident, its object model improvised on the spot. Prompt it with a defined model (these objects, these relationships, these attributes, these actions) and the output snaps into something that could only be your product.

Same tool. The difference is entirely in the nouns.

Verbs are cheap now. Flows, screens, prototypes, the how: these have become the easiest part to replace. What AI cannot do is know your users’ mental model unless it has the context you share. Content is no longer king. Context is the part of design’s job that just became more valuable.

To be clear: OOUX was worth learning when the deliverable was sticky notes and Figma files. AI didn’t create the need. It shortened the distance from conceptual model to shipped product, and raised the long-term cost of skipping the modeling.

The object map used to inform the spec. Now it is the spec.

Apply This to Your Work

1.     What are your objects? List the nouns your users would name. Not features: things. Objects have structure, instances you can list, and purpose for the user and the system.

2.     Can your team name the objects consistently? Count the objects that go by two or more names across design, code, support, and marketing. That number is your abstraction debt, and users are paying the interest.

3.     Do your objects hold user objects? If yes, you’re a container company, so model like one. Your archetypes have to survive contact with purposes you might not be predicting.

4.     What would you hand an AI? If you prompted a tool to rebuild your product today, does a written object model exist, or would the machine be guessing? Whatever it would guess wrong, your new hires are already guessing wrong too.

Clarity Is Still the Deliverable

If your team is thinking “we already have so many processes,” I know. I feel like process is out of style now, like a low-carb diet: “Oh no, I’m not using the double diamond anymore, gotta watch my roadmap.” But OOUX is so low fidelity, and so effective it shortens time to product market fit vs adding time.

OOUX threads through any process, enhancing discovery and early exploration where conceptual debt is otherwise created. I will say, expect to get lost the first time you run ORCA. We did on Trello, in a workshop, with the person who invented it in the room.

The designers who think in systems are the ones who can see the future. The ones who can model the system are the ones who get to define it. Objects are how you model it, and in a world where anyone can generate the screens, the model is the work.

This is one piece of a larger argument I’m building. Tolerance-Oriented Futures asks what a system’s conditions are before we envision futures beyond them, and OOUX is how I specify those conditions: honestly, object by object, before the sparkly vision video gets made.

Work With Me

If your product’s objects have gotten tangled (the same concept with three names, features that don’t compose, an AI-assisted codebase drifting away from anyone’s mental model), the problem usually isn’t execution. It’s the model underneath. Through Thoughtful Apes, I run object-modeling engagements that name what’s actually broken, build the shared language to fix it, and leave your team with a model they’ll still be building on long after the engagement ends.

Start the conversation. Tell me what your nouns look like.