Making Better Design Decisions Using the Onion Model
You may know from your experience that one of the main challenges of the design process is focusing attention on the right things at the right time. It’s hard enough to do it yourself, but it gets exponentially harder when you have a team and stakeholders involved. Ideas and questions pop up all the time and your job may be to decide which ones are worth discussing.
There are rarely wrong things to discuss when it comes to designing a product — it’s usually the wrong time to discuss them. How do you figure out what’s important at the moment?
Even if you intuitively know the answer, it’s a challenge to explain your reasoning to others. And one of the tools that has helped me the most in my product management journey is the concept of “layers of design decisions”.
In this article, I’ll do my best to explain the concept and how you can use it to steer design processes more effectively.
Products Are Like Onions
They stink? Well, yeah, sometimes they do. But the most importantly — they have layers.
One of the most prevalent concepts in software architecture is the “onion model”. It’s used to visualize the idea that some elements, and therefore decisions, are more “central” and influence everything closer to the outer edge. Consequently, the things at the edge can change without impacting the core.
Here’s one of the most popular variations of an “onion model” published by Robert C. Martin in 2012:
Since the graphic focuses on software architecture, it uses many technical terms that may be overwhelming. However, we can simplify the model to make it more useful for reasoning about design decisions.
Meet the Product Layers
There are three main layers of a product — Domain, Logic and Presentation.
Domain refers to the very core of your product — what are the main “entities” you can distinguish, their properties, and their internal rules that are very unlikely to change over time.
To use a simple example, when you design a very simple e-commerce system, you may distinguish Orders, Payments, Products, and Clients. These are your core entities. They have certain properties, e.g., a price or name of a Product, status of an Order, or an ID of a Payment. They also follow some core rules, like “the price of a product cannot be lower than 0”.
Now, Logic is about interactions between these entities and rules that are more specific to your product. Can you order the same product twice in the same order? Can a Client only pay with a credit card, or can they send a bank transfer? Is there a minimum value for an order to get free delivery
As you can imagine, these rules are much more likely to change over time, but if they do, they don’t affect the domain. Products will still have prices, Orders will have statuses and so on.
Finally, there’s the Presentation layer, which is focused on how the Domain and the Logic are presented to a user. It includes very fundamental aspects of UI, like layout, pages, navigation, and more detailed ones as well — visual components we use, colors, typography, etc.
The Inside-Out Rule Of Impact
It’s critical for a good user experience that the Presentation represents Domain and Logic well. However, if you completely redesign how a Product page looks, does it affect the Domain or the Logic? Not in the slightest. These are still the same entities, following the same rules, just presented differently.
Now imagine, that we realize that we forgot about Discounts. Introducing a new entity “Discount” to the Domain has an impact on both the Logic and the Presentation layers. We need to figure our new rules of Discounts interacting with Clients, Orders and payments. We have to represent discounts in the checkout process and the structure of components related to orders.
Let’s say we did it successfully and our marketing team can now issue the beloved Black Friday discount. But after some time there’s a new request to send Discounts to Clients that made purchases for at least $500. This is the Logic layer. The Domain should remain intact, but you may have to modify some of the steps in checkout to inform a Client about this rule or design an e-mail that delivers the code to them.
Changes made to the Domain, impact the Logic and the Presentation. Changes to the Logic, impact the Presentation, but should leave the Domain intact. And changes made to Presentation, don’t impact the more central layers at all.
This is the inside-out rule.
The Outside-In Rule Of Discovery
From my experience, the hard thing about the design process is that most of the time we don’t think inside-out, but outside-in. There are tools and techniques that may facilitate the process to focus more on goals, not solutions, but we naturally tend to visualize everything we want to achieve.
That’s why I advocate embracing our visual minds and stakeholders sketching out solutions — more often than not you’ll find more insights in these sketches than in hours of discussions.
However, when we start exploring a problem starting with the Presentation layer, it’s easy to get caught up discussing solutions that have no impact on the Domain and Logic layers.
As a result, these discussions seem like you’re not moving forward. They’re a waste of time because further exploration of the Domain and Logic layers often reveals completely different requirements than we imagined at the beginning.
We can then formulate the outside-in rule of discovery like this:
Until the inner layers are stable, you limit investing in the outer layers to the minimum that’s necessary to learn more about the inner layers.
In other words, until our understanding of the Domain and the Logic layers is complete enough that they stop changing, we should focus our discussions only on problems that lead us to understanding them better.
Going back to our e-commerce example. Let’s say we sketch out the checkout process and someone puts an “Add a coupon” button on of the screens. The most important things to discuss at that moment are “What are coupons? What are their properties?” (Domain) and “How do they impact other elements of the system?” (Logic), not “Why this button is placed here and not there?” (Presentation).
Using the Model To Facilitate the Design Process
So far we’ve established the general, layered structure of products. We understood that because of the inside-out rule of impact, we must use the outside-in rule of discovery to shift our initial focus to understanding the domain. Only when we have a good understanding of the inner layers, we can develop the outer ones.
If everyone involved in the design process is aware of this model, it’s much easier to cut discussions that don’t move you forward.
It’s inevitable that our minds drift and we can’t help coming up with alternative ideas. But now, we can ask ourselves — “Will this decission have an impact on our domain or logic, or is the impact limited to visual?”.
Imagine you facilitate a dicsussion and you feel like it drifted to less important (or at least less urgent) matters.
When you say “Let’s talk about it later” it’s arbitrary and non-negotiable, therefore more prone to trigger conflicts and jeopardize collaboration.
“I think that this decisions impacts only the presentation layer, and we’re still figuring out the logic. Let’s talk about it later.” is a much different message. You use a specific reason for postponing a discussion that can be debated. Someone may recognize how a given decision impacts the inner layers and bring it out, leading to a more fruitful discussion.
The Rollercoaster Of Reality
So far you may have thought “Well, it’s a nice model, but there’s no way it works in the real life. No one simply starts outside-in and then gently flows inside-out to the surface.”
And you’d be absolutely right. To better understand the actual dynamics of the design process, we need to add the third dimension to this 2D model — time.
There are usually three major phases of a journey through the layers:
- Opening game — you gather first visuals and insights about the business process, to draft the first model the domain. Then, you put it to test, by developing your ideas with wireframes or mock-ups.
- Mid-game — you encounter issues or new requirements that usually require you to move back to the core assumptions, change them, and try to test them again. You may feel like “you’ve got it” at times, but if you still need to modify basic properties of the domain, you don’t have a stable foundation yet.
- Endgame — you still discover new needs, but realize that you don’t need to change anything about the domain and you just build logic and presentation upon the stable foundation. Then, and only then do you increase fidelity of your designs and start focusing on the final visuals.
And now the hard part — what moves you forward in the process are decisions. They are often not obvious. You won’t have 100% certainty, that you have the right idea, the right model.
However, and that’s the most important take-away from the graph above, you can only test your assumptions by trying to move forward and build upon them. When you accept the fact that there will be a lot of going back-and-forth and you keep the outside-in rule in mind (only do as much as needed to test your assumptions), it’ll be easier for you to let go of what you already created.
Put This Idea Into Practice
When you facilitate the design process, try to use this narrative to build a shared understanding of the current goals. You’ll find it much easier to explain to the team and stakeholders, why you need to put certain discussions and decisions on hold when there’s a clear justification.
Usually, you’ll find yourself using phrases like:
I think the placement of X is important, but right now we’re not even sure if it’s going to be there or if we’re going to need something else. So let’s pause here, and move forward to test the whole idea first.
It’s even easier when the team is familiar with the “onion” model and you can use the same, ubiquitous language.
You know what, what components we’ll use here is more of a Presentation issue. At this stage we’re still figuring out what data we’re gonna need to complete the process. So let’s move on and go back to the question when we’re sure that the Domain and Logic we came up with makes sense, ok?
From my experience, “the Onion model” is a great tool to direct everyone’s attention to what’s important at the given moment. I hope you’ll find it useful too!
