You don’t always have to build from atoms. Sometimes, you need to discover them.

Atomic Design is one of the core mental models of modern design systems. It gives us a common language for describing the interface as a hierarchy: atoms, molecules, organisms, templates, and pages.

Brad Frost said from the very beginning that atomic design is not a linear process, but a mental model that allows us to keep both the whole and its parts in view at the same time. The five levels are not steps one through five.

From Template to Atoms.

However, in practice, most teams apply the model in one direction. This is especially true when they aim to build a component library: they define the smallest reusable parts and assemble larger blocks from them. And the begin to use them all in screens.

Small building blocks, gradually assembled into a finished screen

This habit is so common that many people mistake it for the methodology itself.

Product work usually starts from the other side — from the user experience. When we look at a screen, the first question isn’t “what components are used here,” but “what does the user need to do here?” How will they search, filter, compare, select, edit, and so on?

This is another entry point into the Atomic Design model. We could say that this is a “scope-first” approach.

A component-first approach can obscure the actual structure

A “component-first” approach usually begins with an inventory:

This is a button
This is an input
This is a badge
This is a table

There are two well-known methods that handle this very well: Brad Frost’s Interface Inventory and Nathan Curtis’s Component Cut-Up Workshop. Both are excellent for their intended purpose: describing an existing interface and kicking off the work on the component library.

But they answer a specific question: “what’s on the screen?” We need to think about the rest ourselves: ”why something is there and what it’s connected to”.

Let’s take a typical admin screen with a data table as an example.

The user inventory here looks pretty good:

Page title
Primary actions
Tab navigation
Search input
Filter inputs
Sort buttons
Pagination
Tooltips
etc.

What remains behind the scenes is how all of this is interconnected:

The status badge is associated with a single row.
Sorting rearranges all rows in the dataset. Even though the control itself is located within a single column header.
Search and filters change which records are displayed on the screen at all.
A primary action like Add people affects the entire page.
Tabs can completely replace the content area’s contents.

The proximity of elements to one another is a poor guide in all of this. The sort button is the most obvious example: it resides in a column header but affects the entire table. Elements are linked not by their location, but by the scope of their behavior.

Thinking in scopes

When breaking down a screen, we can start with the scope of each action — the set of data or part of the interface that changes when the user triggers that action.

For the admin screen above:

This isn’t a complete breakdown, but it already highlights a couple of important points.

First: each row in the left column answers the same question — what is changing?

You might be tempted to add categories like “navigation” or “table header,” but these describe what the control is or where it’s located. That’s a different axis, and mixing the two axes is exactly what will cause the exercise to quietly turn back into an inventory breakdown.

Second: tooltips and badges have no scope at all. They don’t change anything. They’re included in the table to indicate that something isn’t a control — just to complete the picture.

This breakdown isn’t universal. On a different screen or in a different product, the scopes will be different.

It’s not the list that’s carried over, but the process:

Start with what the user can do and what they can interact with.
Determine what each specific user action will affect.
Decide which level should own the logic.

This way, we get a structural model of the screen even before we start creating components.

Where the logic lives

When we design components, we think about the library: its versatility, independence, and applicability in contexts we cannot predict.

When we design a product, we think about business logic — the parts must come together to form a cohesive user experience.

Search, filters, and pagination illustrate this tension quite clearly. As library components, they can appear in different combinations on different screens, so it makes sense to keep them independent.

But on this admin screen, they manage a shared dataset:

Changing a filter can reset pagination to the first page.
A search query with no matches empties the table, and pagination becomes unnecessary.

It is impossible to list all such scenarios when documenting individual components, and the components themselves should not be aware of them. The moment the filter component becomes aware of the pagination component, it loses its reusability and begins to carry the business logic of a single specific use case.

But something has to manage these connections. In my experience, it’s most convenient to do this at the template level.

A slightly different view on the role of a template

In Atomic Design, templates are page-level objects that position components within a layout and define the content structure: they are about structure, not state.

To put it very simply, a template acts as a “dumb” (presentational) component that only knows how it looks and what data it receives from outside.

“Smart components” (container components) are capable of managing data, state, and behavior. They are often built as wrappers around “dumb” (presentational) components.

This is roughly what I suggest doing with templates. The individual components remain “presentational”: a table knows how to render rows, a filter knows how to return a value, pagination knows how to display a page number — and they’re all independent and unaware of each other. The template is the wrapper that unites them and holds the logic for how they work together.

For data-dense product screens, the template level is the natural place not only for layout, but also for:

Which zones are on the screen and where they are located.
How the zones are connected.
The shared state that flows between them.
Rules that belong to the screen’s context, rather than to any specific component.

I have often seen developers on product teams create wrappers around several library components when they need to reuse the same set of features, such as filters, search, tables, and pagination, that behave as a single unit.

Of course, this kind of logic can be documented as a story in Storybook, but developers often prefer to keep it as ready-made modules rather than rebuilding it from scratch every time.

Sometimes these wrappers appear spontaneously and end up somewhere in the /components directory alongside buttons and other “presentational” components. However, it’s still better to keep such templates separate.

I should clarify: I’m not saying that every template must contain logic or that any logic should be dragged into a template. The criteria are the same as the question about scope:

If a rule describes a relationship between areas and is repeated from screen to screen (“changing the filter resets pagination to the first page”), it belongs in a template.
If a rule applies to a specific screen and specific data (“disabled users cannot change their role”), that’s at the page level, and the template shouldn’t be touched.

A template that knows too much stops being reusable.

I believe this is more of an extension than a contradiction to the logic of Atomic Design templates. This is also the clearest distinction between this approach and Component Cut-Up:

Cut-up helps the team identify recurring visual elements and turn them into a list of potential components.
A scope-first analysis helps understand “what a user can do on the screen, what their actions affect, and which level should be responsible for it”.

Same template, different reality

A good template is a reusable structure that works across different product contexts. For example, the same template can be used to manage Members, Projects, Invoices, and other pages.

The zones remain the same:

Page header
Primary action area
Navigation
Toolbar
Content area

What changes are the elements within them: same structure, different content and behavior.

This is the moment when a design system becomes more than just a set of components and begins to describe product patterns. This is exactly what most product teams need.

Checking the breakdown with real content

At the page level, we populate the templates with actual content. At this stage, we need to stress test the system and our layout to make sure the structure can handle content it might not have been designed for. Not just for the “happy path,” but also when:

When there is no data. For example, when a search query returns no results.
While data is loading.
When the page opens on a small screen.
The text is much longer than intended for the layout.

These are just a few scenarios for a particular single screen. Some of them are typical, such as the empty state. Others may be specific. It’s similar to what QA does with edge cases: finding where things break.

The difference lies in what “breaking” means. It’s not always a design problem. Often, it’s a sign that the breakdown is incomplete: a certain state or part of it has no owner, or a rule hasn’t been defined for the zone in case it’s empty.

When this approach is useful?

First, when you need to create a design system for an existing product. When the product already exists, the question isn’t “How do we create components from scratch?” but rather “How do we understand and systematize what already exists?”

Second, when there are debates about the boundaries of components. A scope-first breakdown provides both sides with a more neutral way to discuss ownership. Instead of arguing about whether something “looks like” a component, the team can discuss what it affects and which level should own that behavior.

Third, when a product has many similar screens. Admin panels, dashboards, CRM tools, settings pages, marketplaces, financial tools, and internal platforms often repeat the same patterns with different data. Scope-first approach helps clarify which parts are truly reusable and which are simply visually similar.

And finally — documentation. Product patterns are much easier to describe in terms of their scopes — page actions, object actions, states. Not through a flat list of components. And this is closer to how a user perceives the screen.

When this approach doesn’t help?

This approach isn’t one-size-fits-all, and based on my experience, I can point out at least two ways to mess it up.

The first is to adjust the logic and components to fit a single screen. The temptation is understandable: if the scope model just fits perfectly, you may want to build a library around it. But a screen is a specific use case, while components should live longer. A scope indicates the level at which the logic should reside. It says nothing about how versatile the component itself will be. I’ve encountered this situation very often when product teams were working under pressure, and designers and developers tried to save every new pattern as a component or a design system template.

The second is breaking down what’s already clear. On a landing page, settings form, or login screen, the scope map takes up a single line, yet it can still take a long time to analyze. The entire approach rests on two things: screen density and the overall flow between zones. If neither is present, a traditional inventory cut-up will be faster and deliver the exact same result.

Conclusion

Atomic Design is a versatile model that makes it quite easy to build component libraries. However, teams often try to use it to build interfaces from small parts, taking the “atomicity” of the approach too literally.

Day-to-day product work often starts from the other end: a complex screen already exists, and it needs to be understood. This article shows that Atomic Design helps with this as well. Moreover, the result is not just a more precise breakdown into components, but also a clearer understanding of the product pattern behind the screen.

For product teams, this is usually what matters most.

Thanks for reading! Write in the comments what you think about the topic.

Let’s stay in touch! Connect with me on LinkedIn and follow me here on Medium for more design-related content.

Entering Atomic Design from the screen was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Menu

Entering Atomic Design from the screen