I recently finished the OOUX Masterclass Certification Program and became a Certified OOUX Strategist, which has fundamentally changed the way I approach product design. As a passionate advocate for Design Thinking, I wanted to share some insights from my experience in learning OOUX and how these design philosophies mesh, helping teams build better digital products with more clarity and momentum.
My Background as a New UX Designer
Before diving in, I want to express that this article is not meant to be a thorough examination and lesson in what to do. I’ll be talking about my first official UI/UX experience at my previous company, and how the OOUX masterclass taught me the things that I wish I’d known back when I started at that company.
I began my official UI/UX journey with a 12-week Professional UI Design bootcamp from the Interaction Design Foundation, in conjunction with Google’s UX Design Certificate on Coursera (well, 60% of it anyway).
Both programs were excellent in teaching me the foundations of UX and UI. The methodologies and tools felt like home to me, as I’m someone who has strength in empathy, visual design, experience design, and an endless desire to learn and grow. I even took the CliftonStrengths assessment and discovered that my #1 recommended career path is UX Design, go figure.
But neither of those programs, nor the idea that UX is the “perfect career for me,” could prepare me for the actual reality of being a UIUXer — especially in a small company that is actively trying to stabilize and grow.
And it was a whirlwind. Those years gave me real design callouses — earned through ambiguity, pressure, learning from failures, and constant iteration. I spent three years there, primarily learning on the job and taking crash courses on Udemy when I could afford the time and energy.
It’s been a little over four months since I was laid off (due to government changes forcing the company to restructure), and since then, I’ve been focusing on:
- Self-reflection, rest, and healing from burnout
- Letting my callouses harden
- Taking the OOUX masterclass, which has been like therapy for my career.
At the beginning of the masterclass, I was stuck in the headspace that maybe this career path isn’t right for me, like maybe I just can’t hack it. I blamed myself for how messy our project was and how much frustration we had on our team, believing things like, I’m just not a good enough designer, I’m not valuable because I can’t code professionally, and, I clearly don’t know how to communicate with people who don’t think the way I do.
None of those thoughts reflected the real problem. Those thoughts were just symptoms of an issue I hadn’t been able to name yet.
Our team wasn’t drowning because I lacked talent or skills. Rather, we were struggling because we didn’t have a shared way to think about the problem, the system, or each other’s perspectives. And once I started viewing the situation through an OOUX lens, the mess began to make sense, and I started to realize I just didn’t have the structure that I needed to bridge the communication gaps between design, development, and leadership.
Here’s what I’ve learned in the last 3.5 years working in the digital product industry: UX is absolutely valuable. It’s necessary for long-term upward growth. But it’s also incredibly hard to introduce in environments that aren’t used to it.
UX isn’t just about talking to users and applying common sense. It’s not throwing together high-fidelity screens or relying on best practices you’ve memorized to magically “make it good.” Good user experience requires methodical work, clear strategy, and thoughtful collaboration from everyone involved in what we’re building.
In those environments, a designer’s job isn’t just to design; it’s to act as a bridge. We invite others into the design process and help them participate in it meaningfully. But that invitation has to empower people, not overwhelm them with new frameworks, terminology, or process.
When our approach makes people feel bogged down instead of enabled, UX quickly gets labeled as expensive, time-consuming, and low-value. And to be honest, in that context, leadership isn’t wrong to see it that way.
But how do you become that bridge when you don’t yet have experience doing it? I don’t have a universal answer for every new designer, but I’ve found the answer for myself: Object-Oriented UX (OOUX).
Design Thinking vs. OOUX
Design Thinking is a deeply human-centered, iterative framework for solving ambiguous problems. OOUX is a design philosophy that is grounded in how humans naturally make sense of the world: through objects, their relationships, their attributes, and the actions we take.
It’s not unlike object-oriented programming; it’s derived from it. And honestly, it is so important that as UX designers, we work with a design philosophy that parallels engineering paradigms — because this is how we build effective communication between two totally different ways of approaching the same challenge.
In my experience, Design Thinking resonates most strongly with designers — while other roles often struggle to see how it translates into concrete execution. It gives designers a language for exploring ambiguity: get to the root cause, brainstorm, experiment, test, and repeat (or jump around as needed). It helps us explain how we solve problems.
The challenges in an agile, cross-functional product team:
- Hard to estimate: It’s not impossible to estimate design-thinking tasks, but it’s hard to be accurate without risking quality.
- Iteration can look like backtracking: In ambiguous spaces, revisiting earlier steps can read like “analysis paralysis” to non-designers and hurt morale.
- Broad by design: It keeps you in the big picture, while implementation requires attention to system complexity and edge cases.
Now, it’s important for me to note that when you are working with little to no information in a given problem space, Design Thinking is incredible for getting you concrete information to start working with. And you can adapt and scale the process as needed to continue gathering and refining more and more information. But where I have struggled the most is somewhere between ideation and implementation.
As a Design Thinker, you will have:
- Built empathy with your users. You’ve made some sense out of scattered research and insights. You’ve built empathy maps and affinity maps to really define the core problem(s) that you need to try to solve. You’ve built journey maps to get to the heart of user flows and identify opportunities for improvement.
- Generated big-picture solutions. You’ve sketched them out, built wireframes, or even prototypes, highlighting the overall solution. You’ve shared them with the team, highlighting the user journey and explaining their overall goal.
But then your team comes back to you with so many questions about conditional logic, interdependencies, state-dependent behavior, exceptions, branching logic, and so on — things that Design Thinking and other similar design frameworks don’t actually teach you.
And that is where OOUX comes in.
In my last project, I was drowning in all of the above, and I had no way of concretely being able to tackle those nuanced questions in a truly impactful way. There were engineers on my team who were happy to share the specifics, but it largely happened in verbal conversations while they shared their screens, breezing through code or data sources while explaining their ideas and concerns, and I couldn’t keep up. I couldn’t get a handle on their logic. And that made it all the more difficult for me to visually represent their ideas back to them, meaning iterating for higher-fidelity functionality was a burnout-inducing nightmare.
The result was predictable: cyclical conversations, cognitive overload, missed deadlines, and steadily declining momentum. As complexity increased, so did misalignment across design, development, and project planning.
As the sole designer, I began asking for support. Not because the work was impossible, but because the role itself had quietly expanded beyond basic UI/UX design. I was being asked to reason about business rules, system logic, data relationships, and edge cases without the tools or shared language to do so effectively.
Looking back, the challenge wasn’t capability — it was structure. We lacked the tools needed to support deep, system-level thinking beyond high-level overviews. With the right framework in place, much of that cross-functional complexity could have been navigated more clearly and far more sustainably.
What OOUX has given me, where Design Thinking fell short, is a concrete way to get to the heart of complexity within a system. It helps me tackle complex, edge-case-heavy problems in a way that clarifies requirements across design and engineering. This level of clarity accelerates UI and interaction design, reducing back-and-forth with developers.
Enter faster and better forward momentum.
Design Thinking with ORCA in Mind
Here’s how I combine them in practice, using Design Thinking as the macro process, and ORCA as the structure that prevents nuance from slipping through the cracks.
The Design Thinking flow is: empathize, define, ideate, prototype, test, implement.
OOUX has a process called ORCA (Objects, Relationships, Calls-to-Action, Attributes), which flows like this: ORCA Discovery, ORCA Requirements, ORCA Prioritization, ORCA Representation.
Let’s pretend we’re working on a brand new product idea, and we’re starting with little more than a general concept and a hope for what could happen from a bird’s eye view.
We’ll start with Empathy
Yes, we want to identify our target market. Yes, we want to hold user interviews. We want to collect qualitative and quantitative data so we can narrow down the concept that we need to build. We want to build empathy maps, personas, perspective grids, experience maps, customer journeys, etc. We want to research the domain and get a feel for the competition. We want to understand our competitors’ unique value propositions, where they fall short, and how we can build a better solution.
Without ORCA thinking:
I would turn this phase into decorated FigJam boards, research decks, or written documentation — and then move on. It often became too much information, and those “living documents” would get lost, forgotten, or outdated. Worse, they wouldn’t clearly highlight what the team actually needed to align on.
With ORCA thinking:
I would use the aforementioned artifacts for myself and start collecting potential objects, actions, and attributes throughout this entire phase. I’d also be playing with mini system models between potential objects to get a feel for what the relationships between those objects would look like. And this is the information that I would share with the team. Of course, all of the research data will still exist to back me up or help inform others when needed, but I’d relieve the team of the burden of having to sift through all the data with me, and instead, immediately start naming the product’s potential ORCA, together. This sets the stage for early cross-functional alignment.
We’ll then Define the problem
With research data in place and personas to reference, we’ll come up with a problem statement, or a few. We’ll write Jobs-to-be-Done, user stories, how-might-we’s, etc. We’ll continue expanding on our customer journey mapping, maybe even touch on service blueprinting. We’ll assess qualitative and quantitative success metrics.
Without ORCA thinking:
I would say, wow, I’ve got a lot of data here. Guess I’ll start sketching. And that is still valid, but my sketches would likely be valuable for little more than high-level thinking, which doesn’t really set me up for building a truly cohesive user experience, nor helping engineers start building the backend foundations with any real confidence or connection to the user experience we’ll want in the end.
With ORCA thinking:
I would use this data to start piecing together the first iteration of an object map. I’d begin accounting for potential user roles and the actions those roles could take on the objects in the map. I’d look closer at the relationships between all of the objects and add that to the map. And this is what I would review with the team. Instead of bogging them down with all my research data, we’d be collaborating in a game-like fashion to understand and define the actual pieces of the puzzle — again, to strengthen early cross-functional alignment on the inner workings of our system.
Going all-in on Ideation
This is where we brainstorm a significant amount, to go broad before we narrow. This section is best performed as a team, of multiple perspectives from different POVs. There’s all kinds of exercises we can do here, including mind mapping, crazy 8s, prioritization matrices, more concept sketches, wireframing, design reviews of sketches and wireframes, etc.
Without ORCA thinking:
From here, I would honestly jump into high-fidelity screen design and prototyping. But the likely outcome would be: fragmented ideas, missing pieces, too many questions to answer, or worse — not enough questions asked — bloated and unclear design scope, functionality misalignment, and lots of workshops and whiteboards that may never be looked at by the team again.
With ORCA thinking:
The OOUX Strategist version of me would return to the object map; one visual artifact acting as the source of truth, which highlights the product’s functionality and even layout/navigation at the most basic level, without spending days, weeks, or months building screens that will eventually need to be re-worked.
Using that object map, I’d start drafting requirements documentation, articulating the necessity of each object in the system, as well as the functionality/mechanics/etc. of its attributes, relationships, and calls-to-action. I’ll likely even do some early prioritization based on the user-backed data from the empathize/discovery phase. Because of the rigid structure of building requirements documentation that OOUX offers, both design and engineering will have a very clear idea of how to build the things we’re building. No high-fidelity screen design needed at this point, and especially, no prototypes that only address the high-level user experience and not the system-level, functional details within each potential user flow.
Maybe this sounds like a lot, but the process would be quick and iterative, and save us a ton of time and design/tech debt in the long run, while allowing further refinement later. This helps us move forward with more concrete information about what we’re actually building. And all the while, we’d be naturally uncovering an intuitive experience because we’d be honoring the fact that humans think in objects, and what they can do to those objects, or to pieces of those objects.
Time to Prototype (& Test)
While I find this entire process exciting and game-like, this is the part that excites me the most.
Without ORCA thinking:
Without structural modeling, I had tremendous anxiety at this point, because who can confidently build high-fidelity designs that can be tested with real users, without having concise requirements documentation? I certainly tried, but often missed the mark. As stated earlier in this article, there was always so much operational detail that I would miss. And design reviews with the team typically left us feeling more misaligned and frustrated than empowered and ready to go.
With ORCA thinking:
With object-based reasoning in place, I have no fear or frustration here. Whether I’m building screens myself or prompting an AI to do it for me, with OOUX, I am genuinely confident at this stage because of the clarity we have been building upon since the beginning. At this point, I have all, or at least most, of the information I need to either get to work in Figma myself or confidently prompt an AI platform.
Representation in OOUX gives us the ability to build object-oriented sketches very quickly. These sketches are low fidelity, but can easily be turned into low- to mid-fidelity designs that are testable on real people. This gives us more time for testing and validating what matters most, early on:
- Users can contextually navigate the platform with minimal cognitive load or roadblocks
- Users can take the actions necessary to get their jobs done, with minimal cognitive load or roadblocks
Low-fidelity prototypes backed by OOUX data prevent us from spending ample time building polished, high-fidelity visual designs that don’t always really test for the two points noted above.
Testing on these low-fidelity prototypes gives us the user and business data that we need to potentially do even more prioritization, highlighting which objects/relationships/actions/attributes are more of a nice-to-have rather than a necessity, reducing the present scope, and maximizing momentum. And we can decide to slate those nice-to-haves for implementation at a later date, while spending our energy building an MVP that is built upon a scalable foundation of realistic requirements that we have already figured out (for the most part) while ideating.
Implementation: Launching an MVP
As mentioned above, when we include ORCA-specific work in the Design Thinking process, the result is that we not only will have built a team that is aligned on the details of the product, but we also build an MVP that — though it may not be pretty yet — is fully functional and feels “complete,” without broken navigation or a clumsy experience.
Because of this, we launch an MVP that can grow alongside our user base. We’ll then spend time enhancing the product as is, improving our current objects as well as refining the brand as we go (rather than waiting for the fully polished visual design in order to take action), and we can add objects into the system if/when it is needed and feasible.
This is real, concrete scalability rooted in naturally intuitive user experience design and development.
Final Thoughts
As mentioned in the beginning, these are my initial reflections after finally diving headfirst into OOUX. I will soon be exploring the advanced concepts, and I can’t wait to share more thoughts throughout my learning journey.
Whether you’re new to OOUX or a seasoned veteran, I would love to hear your thoughts and opinions on my reflections here. I hope you found this article insightful in some ways, but I’m a glutton for critical and constructive feedback — so let me have it!
Written by a human, edited with the help of genAI — strictly for clarity, not for opinions. All frustrations, insights, and design callouses are 100% organic. No robots were harmed in the making of this article. 🤖🤷♀️✨
