Published on March 22, 2026
Do you find yourself designing screens with only a vague idea of how the elements on the screen relate to other components within the system? Do you leave stakeholder meetings feeling uncertain about directives that often seem to contradict previous discussions? You know that a better understanding of user needs would help team members align on the actual goals, but time and budget for research are limited. When it comes to negotiating for direct user interaction, you might feel like Oliver Twist, timidly asking, “Please, sir, I want some more.”
The key is to engage stakeholders in identifying high-risk assumptions and hidden complexities, ensuring they become just as motivated as you are to obtain insight from users. Essentially, you need them to feel that it’s their idea.
In this article, we will explore how to collaboratively shine a light on misalignments and gaps in the team’s shared understanding on two simple questions:
1. What are the objects?
2. What are the relationships between those objects?
These inquiries align with the first two stages of the ORCA process, which could become essential in reducing guesswork in design. What is ORCA, you might ask?
ORCA stands for Objects, Relationships, CTAs, and Attributes, and it provides a framework for creating robust object-oriented user experiences. Object-oriented UX is my design philosophy. ORCA is an iterative methodology that synthesizes user research into a coherent structural base to support both screen and interaction design. It has proven to make my work as a UX designer more collaborative, effective, strategic, and enjoyable.
The ORCA process consists of four iterative rounds and a comprehensive fifteen steps. Each round enhances clarity regarding our Os, Rs, Cs, and As.
It’s essential to note that ORCA is a “garbage in, garbage out” process. To ensure that the testable prototype produced in the final stage is effective, it relies on being informed . However, if your research is limited, the initial stages of the ORCA process serve another critical purpose: they help in justifying the need for further research.
In essence, ORCA acts as a transitional phase between research and design. With solid research backing, you can confidently navigate from research to design. Conversely, without robust data, the process often requires you to return to research, armed with a list of specific unanswered questions.
Mark Twain once wisely stated, “What gets us into trouble is not what we don’t know. It’s what we know for sure that just ain’t so.” The first two steps of the ORCA process—Object Discovery and Relationship Discovery—illuminate the hidden corners of your team’s misunderstandings and complexities that may have been overlooked. These discussions can reveal differences in individual mental models that can derail projects and frustrate UX designers.
Once these discrepancies are uncovered, the justification for conducting user research becomes clear. However, the way this is achieved is fundamental. We can’t simply declare, “YOU ARE WRONG!” Instead, we must guide team members to recognize gaps in their understanding. When stakeholders take ownership of these assumptions, securing buy-in for UX research becomes significantly easier, and the entire team can get on the same page.
Imagine your users are doctors, and you’re unsure how they utilize the system you’re redesigning. You might approach the situation , “We need to understand doctors better! What are their pain points? How do they use the current app?” However, this approach often yields vague responses that lack actionable insights.
Instead, facilitate a discussion that encourages stakeholders to ask specific questions themselves. Consider this exchange:
“Wait a second, how often do doctors share patients? Does a patient in this system have both a primary and a secondary doctor?”
“Can a patient even have more than one primary doctor?”
“Is it a ‘primary doctor’ or just a ‘primary caregiver’? Can that role also be filled by a nurse practitioner?”
These dialogues uncover the complexity of the issues and reveal critical areas where clarity is needed. As the questions evolve collaboratively, you can gently challenge stakeholders’ confidence.
When such inquiries about the system arise from your stakeholders, overlooking the necessity of understanding these complexities before designing screens becomes untenable. Designing software without comprehending the users’ real-world information environment can lead to products that fail to align with user needs, leading to confusion and a subpar experience.
To elicit these meaningful conversations efficiently and diplomatically, begin with the two guiding questions that frame the first two steps of the ORCA process:
1. What are the objects?
2. What are the relationships between those objects?
While these questions sound simple, deriving answers is often challenging. Here’s how these questions can serve as the foundation for an Object Definition Workshop. During this workshop, the initial queries will evolve into a plethora of specific inquiries that underscore the necessity for further user research.
Preparation begins with what I call “noun foraging.” This involves identifying nouns relevant to your project’s business or industry across multiple sources.
Consider a variety of resources for noun foraging:
– The product’s marketing site
– Competitor marketing sites
– Existing product components (labels, terms used)
– User interview transcripts
– Notes from stakeholder interviews or vision documents
Put on your detective hat and utilize what materials you have. If your only resources consist of a marketing website, some screenshots of the legacy system, and customer service chat logs, leverage those for insights.
As you explore, focus on recurring nouns that could represent objects in your system. Remember the acronym SIP—Structure, Instances, Purpose—to evaluate whether a noun qualifies as an object, like “book” in a library app.
Once you have gathered your list of potential object nouns, identify words that you are uncertain about, as these will guide deeper discussions with stakeholders. Create a concise list of nouns that not only represent potential objects but also those that require further definitions.
Next, facilitate an Object Definition Workshop where you can collaboratively discover various aspects of your system. Set the tone of your workshop as a requirements-gather