OOUX is a framework that challenges designers to create content relationships that are built on heterarchies instead of hierarchies. It helps us to fulfill near infinite user routes, rather than traditional, linear, parent-child relationships. The framework separates all “things” into “objects.” Objects can be “conceptual” (social and mental constructs) and “physical” (everything else — the tangible world).
IS OOUX RIGHT FOR YOU?
Use OOUX when there are too many objects to force a hierarchy, or when a system is incredibly complicated and may include constantly-shifting situational contexts and desires. Both of these will require a flexible heterarchy that thrives on:
- Spiderwebs over tree branches
- Circular and contextual design
- Associations between things
We have used the framework to redesign complex call center customer service interfaces, a CRM for a pharmaceutical company, a small-to-medium business multi-location networking and billing dashboard, and for grantmakers who sought better ways to organize their public health data. The OOUX process helped us to both simplify existing systems and to design for new complexity.
Let’s break down the steps in OOUXing. (Uh-oh, did we just turn an acronym made of nouns into a verb? For shame.) Here’s a broad summary of steps and smaller, tactical actions to be taken within each step:
1. EXTRACT OBJECTS
Objects are the nouns that people talk about or need in order to use a product. We can collect nouns from our purpose statement, from user stories, or from business goals. It’s best to collect from all three.
We can also discover nouns by listening to user research — particularly things like in-depth interviews. Tag or write on a whiteboard any time you hear a noun that’s related to the use of the product. Keep a tally. You may be shocked, and there may be terms that were previously completely lacking from your interface. These nouns help us to uncover the user’s mental model — the way they describe our product back to us.
2. DEFINE THE CONTENT FOR EACH OBJECT
In this step, we are forced to define what makes an object unique. What makes a flower, a flower? What gives a noun its “nounness”? What is the object’s key data and information?
In our example, one of our objects is a “flower.” In speaking to florists, they (hypothetically) mention to us that flowers each have casual names and latin names. Some of our florists know flowers by their latin names, other florists only use colloquialisms. For example, the common name “daisy” can actually refer to 22 variants of daisies. But our florists most often use the name “daisy” to refer to the lawn daisy, latin name Bellis perennis. We learned a lot there — we learned that in order for flowers to make sense to all florists, they need both the Latin Name and Common Name for disambiguation. That’s already two core pieces of content.
Our florists also tell us that color family is very important when choosing flowers for a client, and that they like to see what the flower looks like to make sure they’re selecting the right flower. So already we know that a flower, as an object, needs the core content of “latin name,” “common name,” “image,” and “color” so that the florists can make a selection. Continue to build this out per object.
All main objects contain core content, metadata, and maybe other nested objects — a piece of core content, but also a distinct object. As we begin to speak with our users, listen to our user research, and speak to our business stakeholders, we can start building out the objects more completely.
3. CROSS-LINK OR NEST OBJECTS AND CREATE ASSOCIATIONS
To figure out if something should be nested, ask yourself: does this object need a relationship with another object for context? Can it exist by itself, or should there be overlap? Watch your associative system come to life! Infinite paths to finite objects.
In our example, core content — like text and media — are light blue. Metadata — any fields or pieces of information which a user might need to sort or filter — are greenish blue. Objects are always orange, nested or unique. CTA’s (verbs and actions) are deep blue.
Our version of OOUX also includes optional permissions (identity management and access control) and states. Objects can be different if a user is logged in (authenticated). They could have access to more types of core content or metadata. The same applies for permissions: objects can flex their content (or disappear entirely from the system) if a certain type of user doesn’t have access to it.
4. ADD ACTIONS/VERBS TO EACH OBJECT
Next we make sure our system is actionable. Without actions, a product is flat. A one-way dialogue. We can uncover actions based on business goals and requirements. Remember, “We are designing a platform that helps florists to source fresh flowers from local farms in their region.” Just from that prompt we know that we need to help a florist “source” flowers. We also know that we need to help them geolocate farms. For something to be “local” it needs to have been located.
We can also uncover actions culled from latent user needs discovered during qualitative research. If many florists say something like, “I wish I could automatically repeat purchases from my favorite farms,” that tells us that maybe we should consider adding that action to the product. The action being “automic order” or “recurring order.” What are people hoping to accomplish in the product? What can be done in the natural world? Here are some things that we might be able to do:
- Check availability of the flower at a farm
- Locate a farm
- Bundle many flowers for a bulk discount
- Find a florist
- Favorite a farm
- Favorite a florist
- Buy the flowers
- Ask a farmer a question
If thinking about natural world actions, flowers can wilt and die. We could even say that in order for something to be “fresh,” like in our mission statement, it needs to be assessed or timestamped. It may need an expiry date or a freshness range. So perhaps we need the ability to mark a flower as past its prime or wilted.
In the natural world, our farmers cut or harvest their flowers. Maybe that’s a better term to use within our interface than “buy”? Perhaps our florists can set when to “cut” the flowers for optimal freshness and delivery? Again, that’s up to us! Tack the actions you think are most needed for your product on the objects.
5. PRIORITIZE OBJECT MODULES, KEEP THEM CENTRALIZED
At this point, the team has created an inventory of the objects. This is a form of a site map or a module map. It contains all the important objects in the system. It’s a place to reference definitions of things. What does a “farmer” mean to us? What does a “region” mean? This should be the “one-map-to-rule-them-all.” A central place for designers, researchers, and developers to understand the plane of your product. The beauty of this shared repository is that when a single object is changed, everyone is aware.
We can start to wireframe what these modules will look like because now we know what they should contain. You can even treat the Post-It’s as a clickable (ultra lo-fi) prototype of your system.
6. DESIGN, BUILD, DEPLOY, TEST, ITERATE, ADD, SUBTRACT, REPEAT
As daunting as it sounds, our work is never truly done. As real users begin to interact with our system of navigation, we will figure out what works and what does not. We will add objects and core content. We will subtract objects and core content. We will test objects. Your module map is an organism that will change over time.
“You never actually own an Object Model. You merely look after it for the next generation”