Object-Oriented UX, Part 2
Read part 1 of this series here.
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).
In part 1, we established the reasons why this framework is useful to designers, developers, and the users themselves. We also gave concrete examples of how OOUX organization methods better mimic our physical realities and even the English language — and many other languages’ syntax structures.
Now, in part 2, we’ll dive into a detailed explanation of how to create this system on your project. Before we begin in earnest, I want to give a nod to Sophia V. Prater, chief evangelist of OOUX, and pioneer in the methodology.
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 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 — they way they describe our product back to us.
We also rely heavily on user stories when populating nouns. User stories are short, simple descriptions of a feature told from the perspective of the person who desires the capability, usually a user or customer of the system or tool. We’ve found the following prompt to be particularly helpful as OOUX User Story Mad Libs. When beginning to “extract nouns,” try to fill the exercise out at least five times — thinking of different use cases and scenarios.
As a ____________ (type of user), I want to __________ (specific goal) so that ___________ (specific reason).
We can also gather nouns (the great noun harvest! ☭) from your product’s mission statement. For example, let’s pretend we are designing a platform that helps florists to source fresh flowers from local farms in their region. How lovely. In the aforementioned sentence, the nouns would be “platform,” “florist,” “flower,” “farm,” and “region.” Already this tells us a lot about the central focus of our product. These are your initial objects.
In the beginning, don’t worry about whittling down the “right” nouns. Write all nouns down on a sticky note or whiteboard! At Think Company, we tend to most use Miro (formerly Realtime Board), if the team is remote. If working collaboratively in-person, we use Post-It Notes and then let the handy Post-It App capture, organize, and transcribe up to 200 objects at a time.
For now, just worry about creating the initial collection of nouns. We will whittle and prioritize later.
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.
Getting pedantic, there can be so many nouns associated with a flower. A “peduncle,” the “xylum,” its “leaf type,” its lifespan, whether or not the flower has a relationship with a pollinator (like a bee). The sheer volume of nouns can be endless — that is if we allow it, and if it’s needed. In conversations with our key users, florists (and our secondary users, the farmers), they seem to only need “color,” “common name,” “latin name,” and “photo” to know what type of flower they’d like to purchase. So, we’ll cap the object content there. In the future, if florists need more or less core content, we can add or subtract that content easily.
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.
Soon we’ll notice that a flower has unique core content, but it also has relationships to other things. Other “nouns”/”objects.” A flower can be found on a farm. A farm is its own unique object. So, we’ll cross-link or nest those two objects. A user would thus be able to navigate to both a farm or a flower individually, and a user will see that the two are related within our designed modules. But the object in which the user chooses to enter, the path they decide to take, gives them the context they immediately need.
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.
At this point, work with the team (or yourself) to prioritize which objects must be designed first, which objects are most important. Challenge yourself to figure out which objects will be most important to your users. What pieces of core content are nice-to-haves? Subtract anything that’s superfluous. Below is just one example of an object map that our team has worked on for a product. These maps tend to be very different in shape, size, and scope! Some may have as few as 6 objects, and another as many as 30. This module map becomes our “requirements to design.”
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”
RESOURCES:
Here’s a Google Slides deck that will walk you through the “Florist and Flowers Purchasing Platform” OOUX example. Feel free to make a copy and play.
Originally published by Keren Toledano on the Think Blog.
