Design systems are having a moment. Every job posting wants one. Every conference talk references one. Every senior designer has an opinion about token architecture and component naming conventions.
And somewhere in a startup with four employees and a product that pivots every three months, a designer is building a button library nobody asked for.
Let’s talk about when a design system is actually the right tool — and when it isn’t.
The case against premature systematizing
A design system is infrastructure. And like any infrastructure, it only makes sense to invest in it when you have something worth building infrastructure around.
If your product is still figuring out what it is — if your user flows change week to week, your information architecture is unresolved, and your team is still debating core features — a design system will slow you down without making you faster. You’ll spend time maintaining a component library for a product that looks completely different six months from now.
The cost isn’t just time. It’s the false sense of stability that a polished component library creates. A system that looks organized can mask the fact that the underlying product thinking hasn’t been done yet.
What you could do instead
Before you think about components, think about objects.
This is the core insight of OOUX — Object-Oriented UX — a methodology developed by Sophia Prater that reframes how designers approach product thinking. Instead of starting with screens and flows, you start with the nouns of your product: the objects your users actually interact with.
In an e-commerce platform, objects might be a Product, an Order, a Customer, a Review. In a project management tool, they might be a Project, a Task, a Team Member, a Comment. These objects exist independently of any screen. They have attributes — pieces of information that describe them — and they have actions — things users can do to them or with them.
Mapping your objects before you design anything is one of the highest-leverage things you can do as a designer. It forces clarity about what your product actually is at a structural level, before visual and interaction design decisions obscure the underlying model.
Enter the ORCA process
OOUX gives us a framework called ORCA, which stands for Objects, Relationships, Calls to Action, and Attributes. Working through ORCA is essentially doing the foundational product thinking that most teams skip in their rush to get to Figma.
Here’s what each piece means in practice:
Objects — What are the core entities in your product? What does a user fundamentally interact with?
Relationships — How do objects relate to each other? Does a Project contain Tasks? Can a Task belong to multiple Projects? These relationships define your information architecture before you’ve drawn a single screen.
Calls to Action — What can a user do with each object? Create it, edit it, delete it, share it, assign it? CTAs at the object level inform your navigation, your component needs, and your interaction patterns.
Attributes — What information lives on each object? A Task might have a name, a due date, an assignee, a status, a priority. Attributes tell you what data your UI needs to display and what your content hierarchy should be.
Working through ORCA isn’t glamorous. It happens in documents and spreadsheets and messy workshop sessions. But when it’s done well, everything downstream gets easier — because you’re designing with a shared understanding of what the product actually is.
Why ORCA and atomic design are more aligned than you think
You may be familiar with atomic design — Brad Frost’s methodology for building UI from the ground up, starting with atoms (basic elements like buttons and inputs), combining them into molecules, then organisms, then templates, then pages.
Atomic design is a brilliant framework for thinking about UI systematically. But here’s what often gets missed: it assumes you already know what you’re building.
ORCA is what you do before atomic design. Your objects map directly to organisms and templates. Your attributes tell you what atoms and molecules you need to surface. Your calls to action define what interactive components are required and in what contexts.
Get your ORCA right and your atomic design practically writes itself. Skip it and you’ll find yourself building components for screens that don’t have a clear structural logic underneath them — and your system will show it.
So when do you actually need a design system?
Here’s a practical litmus test:
You need a design system when:
- Your product has stabilized enough that core objects, flows, and patterns are unlikely to change dramatically
- You have more than one designer, or designers and developers working in parallel
- You’re experiencing inconsistency across your product that is slowing down development or confusing users
- You’re scaling — new features, new platforms, new team members who need shared language
You don’t need one yet when:
- You’re still in discovery or early validation
- Your team is small and can maintain consistency informally
- Your product architecture is still being defined
- You haven’t completed your ORCA — you don’t fully understand your objects, relationships, and actions yet
That last point is the most important one. A design system built on top of unresolved product thinking is a beautiful house on a shaky foundation. It looks impressive until something shifts.
The bottom line
Knowing when not to build a design system is just as valuable a skill as knowing how to build one. It signals that you understand systems thinking at a level beyond “components go in Figma.”
Do your object modeling first. Understand the structure of your product before you start systematizing its appearance. Get your ORCA right.
The design system will be waiting for you when you’re ready for it. And when you do build it, it’ll actually hold.
