Everyone loves the idea of clean, high functioning systems. The kind that scale. The kind that create clarity and consistency across a growing org. But most of the time, that’s not how systems actually show up in UX or product work.
The truth is, we’re usually building systems, while we’re building the thing its meant to support. Yes, crazy right? Its because in each new cycle, you’re hopefully, learning something new to optimize your experience and elevate your output.
What does this look like in action? Heres how it starts:
A team member acknowledges patterns
Someone tries to reduce friction
A tool or doc gets reused a few times
And eventually… someone says, “Hey, should we make this a thing?” This is the quiet birth of a system.
We tend to assume systems come after the chaos but its simply not the case. Most often systems are forged in the chaos. They’re not separate from the work they emerge inside it.
Here are some UX / Product systems you could layer into your work:
Discovery & Research Start paying attention to patterns, like what teams need, when they ask, and how research fits into their cycle.
Synthesis & Insight → Use the same structures to organize findings.
Design & Ideation → Create rituals that are repeatable and expected. Measure them, prove them. This keeps your team and customers engaged.
Design-to-Dev Handoff → Establish shared language. For example, start by agreeing on what “ready for dev” actually means.
Design QA or Launch Readiness → Turn one checklist into a living framework that can be shared with and understood cross-functionally.
The system you’re creating isn’t just a tool. It’s a signal of trust, a source of clarity, and a way of showcasing consistant iteration and growth.
The goal of Methods in the Compare facet is to help teams align the methods and systems they are already using with a set of metrics that help them bring more rigor to the process.
In my experience design and product leaders often feel forced to choose between pushing forward based on intuition or getting stuck in a loop of approvals and delay. The result is endless debate, unclear priorities, and decisions that feel safe but not smart.
The Compare part of the framework was created in response to that frustration.
It’s a way to act quickly without acting blindly. It gives you a structure to test what matters, surface clear UX metrics, and guide your team using evidence that builds trust inside and outside the product.
Yes, that’s a good example for comparing things that are alike in competitive landing pages.
In a workflow where the needs change screen to screen, like an onboarding flow, product/advocacy/design/engineerng might all have to work and evaluate the effectiveness of each step.
Each group could be concerned about different metrics and activities.
Here’s an example of an action map for a men’s clothing store in an omni channel experience:
