Atomic Design, a core mental model in modern design systems, is often mistakenly applied as a linear process from atoms to pages. While ideal for building component libraries by assembling small parts, product work typically starts from a user experience perspective, focusing on user needs and actions on a screen. This "scope-first" approach begins by determining what users need to do and what their actions affect, rather than just inventorying components. It helps define the structural model of a screen before component creation, identifying relationships between elements based on the scope of their behavior.For instance, in a data table, filtering affects the entire dataset, even if the control is physically located in a column header. This approach defines what is changing with each user action, distinguishing controls from static elements like tooltips. When designing components, reusability is key, but product design also considers business logic. The template level is a natural place to manage the interconnections and shared state of components, ensuring they work cohesively within a screen's context without compromising individual component reusability.Templates, traditionally seen as "dumb" layout structures, can be extended to hold screen-specific logic and manage how independent components interact. This means a template can define zones, connections, shared state, and rules within a screen, acting as a "smart" wrapper for "presentational" components. Such templates are reusable structures that apply across different product contexts, helping to describe product patterns beyond just component sets.At the page level, templates are populated with actual content to stress-test the system, ensuring the structure can handle various scenarios, including empty states, loading data, and unexpected content lengths. This "scope-first" method is particularly useful for creating design systems for existing products, resolving debates about component boundaries by focusing on behavior, and systematizing patterns across similar screens. It provides a clearer way to document product patterns based on user actions and scopes rather than a flat list of components.However, this approach is not universal; it can be misused if logic is tailored to a single screen, compromising component versatility, or if applied to screens with low density or simple flows where a traditional component inventory would suffice. Ultimately, Atomic Design is a versatile model, but product teams benefit from a "scope-first" perspective to understand user needs and define structural models before building component libraries, ensuring a coherent and functional user experience.