Structure Before Screens: The Secret to Scalable UX

Most design processes start with screens. You sketch a home page, map out a navigation, and work your way through the product one interface at a time. It feels productive. It feels tangible. And it often leads to products that don't scale.

The problem isn't the screens themselves — it's starting with screens before you've defined the objects those screens are about.

Object-Oriented UX (OOUX), developed by Sophia Prater, flips the process. Instead of designing screens first, you identify the core objects in your system, define what those objects are, what they do, and how they relate to each other — and only then do you think about interfaces.

It sounds like a small shift. In practice, it changes everything.

What Is an Object?

In OOUX, an object is anything meaningful that users interact with in your product. Not a feature. Not a screen. A thing — a noun with attributes and behaviors.

In a project management app, the objects might be: Project, Task, Team Member, Comment, Due Date, Tag.

In a medical society website, the objects are: Member, Resource, Event, Committee, Publication.

In a career guidance app for scientists, the objects are: Member, Opportunity, Mentor, Resource.

Each object has:

• Attributes — the data that describes it (a Task has a name, due date, assignee, status)
• Nested objects — objects it contains or relates to (a Project contains Tasks)
• Calls to action — what a user can do with it (create, edit, assign, complete, archive)

When you define objects clearly, something remarkable happens: your information architecture becomes obvious, your navigation writes itself, and your edge cases surface before you've designed anything.

Why Objects Before Screens?

Imagine designing a recipe app. You sketch a home screen, a recipe detail page, and a search results page. Everything looks great until a stakeholder asks: "Can users save recipes to custom collections?"

Now you're redesigning. Because you didn't have a Collection object in your model, you have to retrofit it everywhere. The navigation needs a new entry point. The recipe detail page needs a save button. The profile page needs a collections section. Each screen you've already designed is now partially wrong.

If you'd done OOUX first, Collection would have been in your model from the start. Its attributes (name, recipes, privacy setting), its relationship to Recipe, and its calls to action (create, add to, share, delete) would all be defined. When screens came time to be designed, Collection would already be a first-class citizen — and no retrofitting would be needed.

This is why I call OOUX an investment: it takes more time upfront and saves far more time downstream.

The OOUX Process in Four Steps

Step 1: Extract your objects from research

Don't invent objects from your own assumptions. Extract them from research: user interviews, existing product flows, support tickets, stakeholder goals.

Listen for nouns. When a user says "I need to find my past orders," Order is an object. When a stakeholder says "Doctors need to track their CME credits," CME Credit is an object. When your analytics show that users spend 70% of their time on the search results page, what are they searching for? That thing is probably an object.

List every candidate object you find. You'll refine later.

Step 2: Define attributes for each object

For each object, list its attributes. What data describes this thing? What would you need to know about it to make it useful?

An Event at a medical society might have: title, date, location, type (conference, webinar, workshop), registration status, CME credits available, speakers.

Don't worry yet about where these attributes appear on screen. Just define what the object is.

Step 3: Map relationships

How do your objects relate to each other? Which objects contain other objects? Which objects reference other objects?

A Member has a Membership Status. A Committee has many Members. A Resource can belong to many Topics. A Publication references many Members as authors.

Drawing these relationships as a simple diagram — sometimes called an object model or a relationship map — reveals the underlying architecture of your product. If you've ever seen a database entity-relationship diagram, it's similar in spirit, but focused on user needs rather than data engineering.

Step 4: Define calls to action

For each object, what can users do with it? These become your features.

A Mentor can be: browsed, requested, connected to, messaged, reviewed.

A Resource can be: searched, filtered, saved, shared, rated, flagged.

Notice that calls to action live on objects, not on pages. This is the key insight of OOUX: features are things you do with objects, not things you build in isolation. When you design this way, features are naturally coherent because they all relate back to a clear object model.

What OOUX Is Not

It's not object-oriented programming. The concepts are related in spirit, but OOUX is a design methodology, not a software architecture pattern. You don't need to be a developer to use it.

It's not a substitute for user research. OOUX is a framework for synthesizing what you've learned from research — not a way to avoid doing it. Your objects are only as good as the research that informed them.

It's not the last step before design. OOUX precedes and informs design, but it doesn't replace UX flows, wireframes, or prototypes. It's a foundation, not a finished product.

A Real-World Example: AGU Flight School

When I worked with the American Geophysical Union on their Flight School app, OOUX was the first thing we did after research.

We identified four core objects: Member, Opportunity, Mentor, and Resource. Defining the attributes and relationships for each of these — and agreeing on them with stakeholders before drawing a single screen — meant that when we moved into wireframes, every design decision had a clear foundation.

The Opportunity object turned out to be the highest-value object in the system. It had the most calls to action (discover, apply, save, share, complete) and the most relationships (an Opportunity could be linked to a Resource, mentored by a Mentor, and earned by a Member). Once we saw that clearly, it became obvious that Opportunities needed to be the primary navigation destination, not buried under a general "Resources" section.

That insight came from object mapping, not screen sketching.

Getting Started

You don't need a framework or special tools to try OOUX. Start small:

1. Pick one user flow you're currently designing
2. List every noun that appears in that flow — these are your candidate objects
3. For the three most important objects, write down: attributes, related objects, calls to action
4. Look for surprises. What relationships did you miss? What attributes require features you haven't designed yet?

That exercise alone will surface design decisions you didn't know you were making. And making those decisions explicitly, early, is what separates products that scale from products that don't.

Structure before screens. Always.