Let’s cut to the chase. ORCA stands for:
And if you are a UX designer dealing with any level of complexity, it’s an acronym you do not want to forget.
After about five years of practicing and teaching Object-Oriented UX at level 1, the ORCA process began emerging. Before, my process for OOUX was just Object Mapping.
An Object Map is an incredibly powerful artifact — it’s basically X-ray vision into your digital product’s structure — and it’s still the darling of the ORCA Process. But today, there’s sooooo much more to OOUX.
ORCA is a 15-step meat-grinder of a process: put good research in one end and out the other, get clarity, structure, and everything you need to go into interaction design with confidence. It’s an iterative process that helps you synthesize research into naturally-intuitive UX.
But the ORCA process is also forgiving, scaleable, and flexible. Remixable. Every project is different, and ORCA is incredibly adaptable. It’s also color-coded, game-like, collaborative, and a helluva lot of fun.
Before we get into the ORCA Process, let’s get some definitions out of the way in case you are new to OOUX.
(Many of the following words are lifted from my upcoming ORCA Handbook. Get on the waitlist so you know when it becomes available!)
What is Object-Oriented UX?
OOUX is a philosophy for designing digital systems that respects the fact that people think in objects, and thus, need consistent, recognizable objects to understand an environment or product. It guides design and development teams in deliberately aligning their software to their user’s real-world mental model of concrete objects, so that abstract digital worlds can be as naturally-intuitive as the physical world we evolved in.
Read how other OOUXers define OOUX.
The Four Pillars of ORCA
If OOUX is a philosophy and a set of guiding principles, ORCA is the how. It’s a protocol — and like I mentioned already with my meat grinder example: you can put good research in one end and get solution-sausage out the other end.
The ORCA process consists of four iterative rounds — which we will get into in a moment. Each round tackles the four pillars of the ORCA process.
Objects. Relationships. Calls-to-action (aka: CTAs). Attributes. Meet the four pillars of ORCA. These words can mean many things depending on the context. So, let’s define them in the context of OOUX.
Pillar One: Objects
Objects are real-world things that have value to the business and the users. They make up the user’s mental model and the business model of connected people, places, and things.
Objects are your anchors of understanding in the tumultuous sea of complexity. They are your friends. Get to know them, love on them, and give them the attention they so deserve.
On Instagram, some objects are: POSTS, USERS, STORIES, BRANDS, COMMENTS, PRODUCTS, REELS. (I like to put objects in all caps.)
Pillar Two: Relationships
Relationships help you understand your anchors of understanding! You’ve got to understand each object in the context of the other objects in the system. How do they relate to each other? You’ll need to communicate these relationships to your user, so you’ll first need to untangle them for yourself. Relationships not only help further define objects, they will pave the way for navigation paths.
On Instagram, a USER has many POSTS they create. A POST has 1 PRODUCT it can feature…or wait, can a POST feature many PRODUCTS? This is the kind of untangling we need to do when figuring out relationships.
Pillar Three: Calls-to-Action
Calls-to-action are the affordances of your objects. What actions does each object “call” various user roles to do? Every action you do in digital products, you do to something. In OOUX, we make sure to clearly connect objects and their associated CTAs.
On Instagram, a POST calls a user to like it, comment on it, bookmark it, and share it.
Pillar Four: Attributes
Attributes make up the detailed structure of your objects. Which content elements come together to define the shape of your objects? What metadata is needed so users can sort and filter through lists of objects?
In Instagram, a POST has images, a caption, a timestamp, and number of likes…as well as relationships to other objects like the USER who created it, USERS who are tagged in it, and the COMMENTS on it.
The Four Rounds of ORCA
During each of the ORCA process’s four iterative rounds, we define, question, examine, and collaborate on the ORCAs of our product — each time increasing in fidelity, each time getting closer to the truth.
Round 1: Discovery
Smoke out complexity. Ask great questions and get an initial picture of the system’s structure. You’ll uncover unknown unknowns, test assumptions, and end the round with a first draft of your emerging product — in the form of an Object Map.
During the Discovery Round,
- go Noun Foraging,
- build a Nested-Object Matrix (an objects-by-objects matrix with relationships described in the intersections — a scalable entity-relationship diagram),
- brainstorm CTAs with a CTA Matrix (object-by-role matrix with actions in the intersections) and,
- end the round with Object Mapping (a color-coded inventory of attributes that builds on the Nested-Object Matrix).
You might end the Discovery Round with more questions than answers and the realization that you actually need to return to research. This is why I often claim that this process is an effective BS-filter between research and design. Uncertainty cannot hide from this process. Uncovering those unknowns early in the process will save you so much time in the long run.
(Further reading: How to Sell UX Research with Two Simple Questions)
Round 2: Requirements
Continue to untangle the complexity you’ve uncovered and put it under a microscope. This stage spends a lot of time working on the granular clarity that ripples out to make powerful differences in the final product.
During the Requirements Round,
- write an Object Guide (a glossary on steroids),
- tackle MCSFD (relationship Mechanics, Cardinality, Sorting, Filtering, and Dependencies),
- expand your CTA Matrix to morph into object-oriented user stories, and
- examine each attribute for conditional logic, define potential values, note required fields, and so much more.
These activities are some of the most difficult in the process. But once you get comfortable with them you’ll truly feel like a complexity-wrangling boss.
Round 3: Prioritization
We’re not just thinking about which parts of the system need to be released first (business-focused mindset) but also what the hierarchy is among each of the objects, the relationships, and so on (user-focused mindset). This will inform how and where each part of the environment is represented and how intuitive it is for users to navigate the space.
During the Prioritization Round,
- Downgrade, eliminate, offload, and combine objects,
- Illustrate contextual navigation with a Nav Flow,
- Further expand your CTA Matrix, phasing interactivity and determining CTA placement based on user priority
- Phase attributes and force-rank them, creating a focused, prioritized Object Map — that will directly inform your sketches and prototype.
Round 4: Representation
We’re finally ready to start figuring out how things should look! All the information gleaned in the previous steps is brought together into a system of components and screens.
During the Representation Round,
- sketch cards, details, lists, and landing pages,
- link them all up in an interactive prototype, and
- test that prototype.
As we test, we try to answer the following questions to validate this foundational work…
- Are these the right things? Are these objects recognizable, familiar, and relevant to the user?
- Do the objects connect in a way that makes sense? Are there any relationships missing? Does moving through this space feel natural?
- Are these the actions that a user wants to take on these objects? Are the CTAs relevant, useful, and findable?
- Do the objects present all the right information? Are there any attributes missing or extraneous? Can users sort and filter lists of objects in ways that are useful to them?
Once this is validated, then and only then, do we go into user flows and detailed interaction design.
The artifacts of Rounds 1, 2, and 3 neatly transform into cards, details, lists, and landing pages that can be stitched together into a testable prototype. After we validated that prototype with users, then we go into the detailed design work of the user flows and interaction design behind each of the CTAs.
Yes, it’s 15-freaking steps. But here’s the beauty: Depending on the project, you might only hit a few of these. You might breeze through some steps in an afternoon, while others might take a week. You might reorder them for your needs. You might decide to skip over the Requirements Round (chock full of advanced moves) until you feel more comfortable with the basics of the process.
And there’s more good news. You don’t have to wait until the end of this process to start seeing benefits. You’ll start reaping the rewards during Object Discovery as you see your team communicating better by simply cleaning up the language you use to describe your product!
Any OOUX is better than no OOUX. It’s totally scalable. And I feel confident that once you start implementing this methodology, you’ll just want to use more and more of it.
See our Getting Started in OOUX resource collection
Putting ORCA into practice
The ORCA steps include activities that create priceless alignment between your designers, developers, and stakeholders. It’s ideal to have the whole team join in at every stage, but if that’s not possible or if a new team member is added later (which is inevitable), the ORCA artifacts will bring anyone up to speed quickly and with fine-tuned clarity. The Object Guide that you’ll create during Object Requirements, for example, is a particularly useful onboarding document.
Like I’ve mentioned, ORCA is a scalable methodology, and whatever amount you can incorporate will make a big, positive difference. Even a few hours of this work will be helpful! But at what point in the grander design scheme do you introduce ORCA? Keep in mind, what you’ll learn here won’t replace your design process. ORCA is a framework that you add to your existing process which likely already includes some amount of research, strategy, interaction design, sketching, prototyping, and testing.
You’ve probably seen the UX design process visualized in about 532 ways, but one of the more prevalent visualizations is that of the double diamond. (If you haven’t heard of it, you have a bit of googling to do.)
However, the double diamond has an obvious weak point.
The best point of the design process to insert the full ORCA treatment is right at the middle of the double diamond, when you have clarity about what the problem is but before you start crafting the solution. ORCA provides a “synthesis” or “structure” diamond, strengthening what is a massive gap in our design process.
The ORCA process not only helps synthesize research and business goals into information architecture, it provides a gauntlet between research and design. It lets you know when you are just going to waste your time in screen design and interaction design, because your research just isn’t strong enough. Yup, the ORCA process will often spit you back into the research diamond.
Remember, this is a good thing — you don’t want to jump into design, before you’ve gained a critical mass of understanding. Sowing this extra work into your process brings the valuable fruit of avoiding high risk pitfalls and their associated costs. You want to uncover false assumptions waaay before going high-fidelity, and ORCA carries a lot of that weight for you.
If we zoom in and paste the four ORCA rounds into our new diamond, we get another wave of lovely diverging and converging.
During Discovery, we cast a wide net. We brainstorm and gather all possibilities. Then we start to squeeze in on the truth. We put everything under a microscope in the Requirements Round, often eliminating things that don’t make sense or sending questions back to research. We strategically kill darlings during Prioritization, and we only sketch, prototype, and test what we suspect will be a rock-solid foundation for design.
Then, we can move into divergent design thinking, exploring several interaction patterns and solutions.
Ready to get started with ORCA?
I know that this article was high-level and not exactly tactical. It’s a 10,000-foot view, not a detailed road map. But if you are intrigued and want to learn more, I’ve got you. Here’s some further reading:
- Getting Started Resource Collection
- Get plugged into the Newsletter, Happy Hour, and more
- Consider investing in your career with the OOUX Masterclass
- Get on the waitlist for our upcoming ORCA Handbook
- Get on the waitlist for Cohort 7 of the OOUX Certification Program
- Check out my recent article on what it means to practice Advanced UX. Basically, OOUX helps you do just that.
- Not convinced? Check out these testimonials.
Tackling complex user experiences is hard. But it’s our job. Unfortunately, we are often rushing through the “understanding-the-complexity” part of the process as stakeholders and tight timelines push us into screen design before we are ready. We are shining a finicky flashlight around the problem, never able to see the big picture — and the picture seems to be constantly changing. You need a way to shine a light on complexity — and bring your team into it.
Welcome to the ORCA Process. It’s the floodlight you’ve been looking for.
Checkout this article on Medium.com.