I'm writing this from a booth at a local diner I visit weekly. There's a receipt tucked under my coffee cup, a server juggling four tables, and an order ticket clipped to a wheel in the kitchen window.

Customers, servers, orders, receipts… those are the objects. A customer gets one receipt per visit (typically), and collects many receipts over a lifetime. One server has many customers. One order has many items. The customer places the order, the cook prepares it, the server closes it out.

I can't help it…

I'm mapping the system 🤓

If I were designing software for this diner tomorrow, I'd know exactly what needs to live on that receipt: a name, a timestamp, a total.

That habit of seeing objects first is something I learned midway through my UX career, and I want to tell you why I think it's the fastest way to get a stuck team moving again.

But first, the stuck part.

Watching mental models break

A lot of my consulting work involves gathering user feedback on redesigns of legacy software. This is typically software someones has used for years. They know exactly where everything lives, often relying on decades of muscle memory.

Now, sitting in front of a new design of the same software, they struggle. I can feel their minds grind slowly forward as they take in the new landscape. And yet, after a few weeks or so of using this new design, they become more familiar with it. Their muscle memory forms and they are familiar with where things live.

So why the slow processing at first?

It's usually simple, their mental model just hasn't caught up to the new design. And rebuilding ones mental model takes time and repetition. There's no shortcut through it. I feel it myself whenever a tool I rely on changes (looking at you Apple Photos😏)

Now here's the part that took me a bit longer to see….

Teams that are building software go through the exact same thing. When there's a big reorganization, or new leadership steps in, or a big strategic pivot—suddenly everyone's mental model of how work "works" is obsolete, all at once. Who owns what? Where are we going? What do we even call this thing now?

For months, everything drags. Leaders wonder why nobody's moving.

And then, eventually, understanding settles back in. The team clicks, and the train finally leaves the station.

That slow start is the cost of everyone rebuilding their mental model separately, in meeting after confusing meeting, instead of rebuilding one model together.

Rebuilding one model, together

Midway through my career I was introduced to Sophia Prater, who created Object-Oriented UX and the ORCA process. She was a designer on fast-moving teams who needed to understand a system before she could make good design choices. So she built a visual toolkit (ORCA) for doing exactly that: define the Objects, map the Relationships, name the Calls-to-action, document the Attributes.

Everything I did at the diner at the start of this? That's the process, informally.

1. Start with the things: There are customers. There are servers. There are orders. There are receipts. Those things make up the system.

2. Agree on what to call them: Is it an invoice or a receipt? Pick one. Define it clearly (this sounds small, but half the confusion on product teams comes from people using different words for the same thing, or the same word for different things.)

3. Map the relationships: A customer typically gets one receipt per visit, but many receipts over time. A customer has one server at a time. One order can have many items. Once you see the relationships, the shape of the system starts to appear.

4. Name the actions: What can people actually do to these things? The customer places an order. The cook prepares it. The server delivers it and checks the customer out. Who are the people, and what are they doing?

5. Document the attributes. If I'm designing a tool for ordering food online, what needs to live on that receipt? Customer name. Date and time. Total price. These details are what you'll need when it's time to design real screens.

That's ORCA: Objects. Relationships. Call-to-actions. Attributes.

This has become the operating system running behind how I see every problem. As an independent consultant I get dropped into industries and domains I know nothing about. One month I'm learning how technicians diagnose farm equipment, the next I'm untangling a university staff portal. My OOUX training holds up every time, and it's why I don't have that slow uptick when I land somewhere new.

I leave that train station fast 🏃🏼‍♀️

For years I thought of that as my personal advantage, but then I started to see what was happening in rooms when I'd use this method with product teams. When a whole team (Engineering, UX, Product, Design) sits down and defines a system together, out loud, arguing over whether it's an invoice or a receipt until they pick one, something shifts.

They start speaking a shared language that same day. The clarity sticks. And people carry it into how they think about everything afterward.

Why I teach object-oriented thinking now

When a team stalls after a big change, my advice is no longer "give it time." Instead, it's a sign that we need to get everyone in a room and rebuild the mental model together, deliberately, with objects.

This process started as a tool for UX designers. But what I've seen, again and again, is that it's a beautiful way for anyone to understand a complex system.

The fastest teams I've worked with aren't the most talented or the best funded. They're the ones where everyone sees the system the same way.

They're the ones that leave the station first 🚂