The Atlas Outline

The Naming Solution for Design & Development Teams

How the Flow-Screen-State-Section framework solves the chaos of design-to-dev handoffs.

Let’s be honest: most projects don’t have a naming convention; they have a collection of insufficient naming habits that leads to chaos. The Atlas Outline is the framework that replaces those bad habits with a clear map and a unique address for every single screen.

Everyone has their own logic for organizing files. It works perfectly—until you join a team. Suddenly, that “obvious” system requires lengthy explanations, and the project descends into a mess of long file paths, confusing names, and wasted time. This is the unspoken chaos at the heart of many design-to-dev workflows, a problem that text-based names and complex folder structures have failed to solve.

But what if there was a framework that was almost self-explanatory? That’s why I created The Atlas Outline. This isn’t a theory; it’s a battle-tested system I’ve been refining for many years, from the early days of Information Architecture to modern workflows in Figma. It’s a simple, powerful solution designed to bring lasting order to your projects by giving every view a unique and memorable address.

The framework is built on four words: Flow, Screen, State, and Section. In this article, I’ll break down the simple rules behind each component. By the end, I promise you will have internalized the system, understood its benefits, and be ready to use it on your very next project.

The Guiding Principles of a Great Naming Convention

Before we dive into the solution, let’s agree on what a successful naming convention must achieve. Over the years, I’ve found that any system that lasts must be built on four key principles. It’s not enough for a system to be organized; it has to be robust, intuitive, and future-proof.

Here are the principles that separate a temporary fix from a permanent solution:

What does a Great Naming Convention must deliver?

Clarity:

Is it instantly understandable?

Scalability:

Will it work for 10 screens and 500?

Stability:

Does it break when the UI changes?

Uniqueness:

Can every single view be uniquely identified?

Clarity: Is it instantly understandable?

A great system doesn’t require a decoder ring. A new team member, whether a designer, developer, or project manager, should be able to look at a screen’s name and understand its context and purpose with minimal explanation. Clarity is the foundation of efficient communication.
Scalability: Will it work for 10 screens and 500?

The biggest flaw in most ad-hoc systems is that they break under pressure. A convention must work just as well for a simple MVP as it does for a complex, multi-platform application. It shouldn’t become more confusing as the project grows.
Stability: Does it break when the UI changes?

Designs are never static. Navigation menus get redesigned, sections get reordered, and features get moved. A truly stable naming convention is tied to the function of a screen, not its temporary position in the sitemap. This ensures that a redesign won’t force you to rename hundreds of files and break every reference in your documentation.
Uniqueness: Can every single view be uniquely identified?

This is the ultimate test. There must be a way to create a distinct, unambiguous address for every screen, including all its possible variations—pop-ups, error messages, loading animations, and disabled states. If two different states share the same name, confusion is inevitable.

Any system that fails on even one of these principles will eventually collapse into chaos. Now, let’s look at a framework designed from the ground up to excel at all four: The Atlas Outline.

Breaking Down the Atlas Outline: The Four Core Components

The Atlas Outline gives every screen a unique, logical address using a simple four-part structure. It’s designed to be read like a set of coordinates, moving from the broad user journey down to the finest detail of the interface.

The format is: [Flow]-[Screen]-[State]-[Section]

Let’s break down each component.

A. [Flow]: The User’s Goal or Journey

The [Flow] is the highest-level identifier. It doesn’t represent a single page, but rather a complete user journey or a core feature of your application. Think of it as a major chapter in your product’s story.

The Golden Rule:

A Flow is tied to a user’s goal, not its position in the navigation menu. This ensures the system remains stable even through complete redesigns.

The Special A- Flow:

When developing a software or a web application, your first task is likely going to be to design the Application Shell. That is everything that is on your screen permanently or can be accessed from every screen like the navigation bar or any panels.

Example:

A-01-00: Main Navigation Bar (Default State).
A-02-02: Global Notification System (Active State, showing a message).

The Special 0- Flow:

We reserve 0- for all “pre-application” tasks. For a web application, this covers the entire authentication journey (Login, Registration, Password Reset). For installable software, it represents all screens in the installation process. The core user experience then begins with the 1- Flow.

Examples: Login, Registration, Password Reset, Software Installation, or an initial onboarding tour.

Example Flows:

A- Application Shell (Menus, Panels, Messages)
0- Onboarding & Authentication
1- Product Discovery (Homepage, categories, search, etc.)
2- Checkout Process
3- Account Management (Profile, order history, settings)

Ruleset #1: Flows

The Golden Rule: A Flow is tied to a user’s goal, not its position in the navigation menu. This ensures the system remains stable even through complete redesigns.
The Special A- Flow: The first task software or a web application is to design the Application Shell. That is everything that is on your screen permanently or can be accessed from every screen like the navigation bar or any panels. The Special
0- Flow: We reserve 0- for all “pre-application” tasks. For a web application, this covers the entire authentication journey (Login, Registration, Password Reset). For installable software, it represents all screens in the installation process. The core user experience then begins with the 1- Flow.

B. [Screen]: The User’s Specific Location

The [Screen] identifies a specific, unique view or page within a Flow. If the Flow is the chapter of your product’s story, the Screen is the specific page. In the Atlas Outline, we use a Two-Character Coordinate (0-9, A-Z) to define this location.

The 00 Screen: The Entry Point

The number 00 is always reserved for the primary entry point or “Index” screen of a Flow.

1-00: The Homepage of a website.
3-00: The main Account Dashboard.

The Series-Sequence Rule (Hierarchy)

To show relationships—like a list-to-detail pattern—we use Grouping. Instead of messy decimals (like .1 or .2), we use the first digit as the Series (the group) and the second digit as the Sequence (the specific screen). This allows you to “chunk” your interface into logical series. By deciding on these groups early, you create a system that is instantly scannable:

The “10” Series: Product Listing (1-10) and its subsequent Product Details (1-11, 1-12).
The “20” Series: Hardware Category (1-20) and its sub-categories (1-21, 1-22).
The “30” Series: Software Category (1-30) and its sub-categories (1-31).

Scalability: Alphanumeric Expansion

The Atlas Outline is built for massive scale. Because we use both numbers (0-9) and capital letters (A-Z), each position has 36 possible values.

Groups: You have 36 possible “Series” per flow (0, 1, 2… 9, A, B, C… Z).
Screens: You have 36 possible “Screens” within each series.

This gives you 1,296 unique screen addresses per Flow—enough to map the most complex enterprise software without ever breaking the four-part structure. If you run out of numbers (99), you simply move to letters: A0, A1… B0, B1… and so on.

Ruleset #2: Screens

The 00 Rule: Always reserve -00 for the main entry point or index of the Flow.
The Series Rule: Use the first digit/letter to group related pages (e.g., the “20” series is for Search).
The Sequence Rule: Use the second digit/letter for the specific screen within that group.
The Stability Rule: Once a screen is assigned an ID, it keeps that ID even if its position in the menu changes.

C. [State]: The Screen’s Current Condition

The [State] is where the Atlas Outline truly shines, bringing a level of clarity that most systems lack. While the Screen tells us where we are, the State identifies the specific condition of that view. This is the key to eliminating ambiguity for developers, QAs, and stakeholders.

The 00 State: The Happy Path

The default state is always 00—what the user sees when they first arrive. Think of this as the “Happy Path.” A State can represent the condition of an entire screen (Global State), a specific component, or even a specific point in an animation.

The Alphanumeric Grid: Infinite Flexibility

Just like the Screen ID, the State ID uses a two-character coordinate (0-9, A-Z). This provides 1,296 possible states per screen. While you will likely never need that many, this alphanumeric capacity ensures that even the most complex form-heavy applications never run out of room.

Creating Your Project’s State Legend

While state numbers are flexible, they must be immutable and consistent across the project. At the start of any new project, your team should define a State Legend to act as your single source of truth.

Recommended State Ranges:

To keep your Atlas intuitive, we recommend the following ranges for your legend:

00–1Z: General UI States
- 00: Default / Initial View
- 01: Hover / Focus (e.g., a button is hovered)
- 02: Active / Selected (e.g., a navigation item is active)
- 04: Loading (e.g., a skeleton screen or spinner)
- 06: Error (e.g., a general page-load error)
- 07: Success (e.g., a generic “Task Completed” message)
20–4Z: The Input Series (Transfer Convention)
This range is reserved for screens representing user input, typically steps in a form or a “wizard” before submission. (e.g., 20 = Step 1 Initial, 2A = Step 1 Validation Error).
50–7Z: The Output Series (Transfer Convention)
This range is reserved for system responses to user input, such as detailed search results, data visualizations, or filtered views.
80–ZZ: Custom / Project-Specific States
Use this range for anything unique to your product, such as animation steps (e.g., 8A for “Animation Start” and 8B for “Animation End”).

Ruleset #3: THE GLOBAL VS. LOCAL RULE:

A State ID at the Screen level (1-10-06) represents a Global Condition (the whole screen is in error). A State ID followed by a Section (1-10-06-04) represents a Local Condition (the screen is fine, but Section 04 has an error).

D. [Section]: The Optional Anchor Point

The [Section] is your secret weapon for complex pages. It’s an optional identifier used to pinpoint a specific region or component within a single Screen.

A quick but important clarification: When we say “Section,” we mean a conceptual area defined during the design phase—not necessarily the HTML <section> tag. Think of it as a logical grouping like “the payment form” or “the order summary.” This approach keeps the design logic separate from the final code implementation, ensuring the system remains stable and flexible.

When to Use It:

Use it for long-scrolling pages, complex dashboards, or to specify where a particular State is occurring (e.g., an error state in the “Payment Details” section of a checkout screen).

The Optionality Rule:

This is the only part of the address that is not required. If a screen is simple and needs no specific anchor points, you simply leave it off. This keeps your naming convention clean and uncluttered.

Example: 2-01-06 could mean the entire “Shipping Info” screen has an error.
Example: 2-01-06-03 could mean the error is located specifically in the “Zip Code” section (03) of that screen.

By combining these four components, you create a system that is not only clear and scalable but also incredibly stable and capable of uniquely identifying every possible view in your application—fulfilling all four of our guiding principles. I should mention that you can use of course also a label to make it easier, but that is optional and the name can be changed, the screen identifier however always stays the same. If you named the first screen “1-00 Home” to “1-00 Start”, this would absolutely be possible, because you don’t change the unique id. The label just acts as a reminder or hint, but I address the labels again at the end of this article.

The Language Code (I18n)

When designing user interfaces, it is important to specify the language that is displayed in the interface. We are using the standard country & language codes for that. Because the language is so important, it gets added directly after the section.

The Variations (Optional)

When designing screens and developing a user flow, you might need to experiment with different variations of the exact same screen. How do you deal with this? The Atlas Outline uses the underscore at the end and capital letters. If you add _A or _B at the end, then it becomes clear that this is a variation.

Once one of the variations becomes the final one, you delete (!) the underscore for that particular one, but you leave it with the others. This way you don’t have to delete them and will always be able to reference it back. I have often experienced the scenario, that an old idea was discussed again and I could then show that we already tried this.

Versioning (Semantic & Date)

Software evolves over time and so does the user interface. In software development, we use what is called semantic versioning. Version 1.0 is normally the release version of a software and by the time version 1.1 is in the works, there are very likely already changes to the User Interface. We want to be able to track these and keep the old screens as reference. This requires us to be able to rename the old screens or mark a screen as future release.

For the screen design, we also have the need to give our screens a version. To differentiate it from the semantic versioning, we will use Date Versioning in the format YYMMDD.

How do we combine these, if there is ever a need?

This addresses an advanced, real-world scenario where a design iteration (identified by date) is specifically targeted for a software release (identified by semantic version).

To combine both, we use a single versioning suffix (@) with a clear internal separator. This keeps the format clean and groups all versioning information together logically.

The recommended format would be: @[SemanticVersion]#[DateVersion]

The hashtag symbol (#) is a great separator because it’s not used in either semantic versioning or the YYMMDD date format.

Here is how it would look in practice

Let’s take a screen for a password-reset dialog, 1-01-02-00.

Design for a Future Software Release:

1-01-02-00@2.2.0 This screen is the design for the upcoming software version 2.2.0.

A Specific Design Iteration by Date:

1-01-02-00@250912 This is the version of the design as it existed on September 12th, 2025 (YYMMDD).

Handling Multiple Daily Iterations:

It’s common for designers to create several distinct versions on the same day. To differentiate these, simply append a lowercase letter (e.g., a, b, c) to the date. For example, @250912a would denote the first iteration from September 12th, 2025, and @250912b the second. This keeps the versioning concise and unambiguous for daily design changes.

Combining Both (our example Scenario):

1-01-02-00@2.2.0#250912b

This single, clear identifier tells the team: “This is the design iteration from September 12th, 2025, which is intended for the software version 2.2.0.“

The Transfer Convention: A Best Practice for Forms and Interactions

For applications that rely heavily on user input, such as forms and complex interactions, we can add an optional layer of organization to our State Legend. This “Transfer Convention” reserves specific ranges of numbers for user inputs and system outputs.

Adopting this convention makes your State Legend instantly familiar across different projects and teams. It standardizes how we map the “conversation” between a user and the system.

Recommended State Ranges:

00-1Z: General UI States.

These are the universal states for any project (Default, Hover, Active, Loading, General Error/Success, etc.).

20-4Z: Transfer Convention:

User Input States. This range is reserved for screens that represent a specific combination of user inputs, typically before the user submits a form.

50-7Z: Transfer Convention:

System Output States. This range is reserved for screens that show a specific system response to a user’s input, such as detailed validation messages.

80-9Z: Custom / Project-Specific States.

This leaves a flexible range for any other unique states your project may require.

The Label Convention: Giving Your Numbers Meaning

The Atlas Outline ID is the stable, unique identifier for any view, but it should always be paired with a clear, human-readable label for context. The label acts as a helpful hint or reminder of what the ID refers to.

The best practice is to create a full, contextual label that describes the entire path of the ID. This ensures that even when viewed in isolation—like in a Jira ticket or a Figma comment—the reference is instantly understandable without needing to look it up.

Good vs. Better Labeling:

Good (but incomplete):

1-03-50-01: Output Section

Better (clear & contextual):

1-03-50-01: Product Discovery – Search Page – Error State – Results Section

Space Saving (using CamelCase and Omission):

1-03-50-01: PrdctDscvry-Srch-Err-Rslts

This complete label should be the standard for naming your frames in design tools. A key strength of this convention is the separation of the ID and the label. The numeric ID is permanent and never changes. The descriptive label, however, is flexible. You can refine it over time—for instance, changing “1-00 Home” to “1-00 Start“—without ever breaking the link to the unique ID.

The Complete Unified Structure

This means the full, final structure of the Atlas Outline, including all optional suffixes, would be:

[Flow]-[Screen]-[State]-[Section].[I18n]_[Variation]@[VersionInfo]

Here is an example showing every component in use:

1-01-02-00.EN_A@2.2.0#250924b

1-01-02-00: The core screen ID (e.g., Password Reset Dialog, Default State).
.EN: That is your country & language code
_A: This is Variation A of the design, part of an exploration or A/B test.
@2.2.0#250924b: This specific variation was iterated on Sept 24, 2025, and is targeted for software version 2.2.0. The b at the end indicates that it is the second design version of that day.

This approach allows you to layer additional metadata onto the core ID in a way that is structured, unambiguous, and handles even the most complex versioning needs.

The Benefits: Why Your Team Should Adopt the Atlas Outline

Adopting a new system requires a conscious effort, so what’s the return on that investment? The Atlas Outline isn’t just about keeping your files tidy; it’s about fundamentally improving the way your team collaborates. It’s a small change that delivers significant, cascading benefits throughout your entire workflow.

Here are the four key benefits you can expect:

1. Crystal-Clear Communication

The Atlas Outline creates a universal, unambiguous language for your entire team. When a designer, developer, QA tester, and project manager all use the number 3-02-06 to refer to the “Password Reset Error State,” guesswork is eliminated. This creates a single source of truth that drastically reduces misunderstandings and saves time in meetings, comments, and tickets.

2. Flawless Design-to-Dev Handoffs

This is where the system pays the biggest dividends. Developers no longer have to guess which states or variations of a screen they need to build. The design files themselves become a precise specification. A Figma frame named 1-01.1-05 (Project View – Empty State) tells them everything they need to know, making handoffs faster, more accurate, and less frustrating.

3. Future-Proof and Scalable Projects

Because the system is tied to a screen’s function rather than its temporary position in the navigation, it is incredibly stable. You can completely redesign your website’s UI, and the underlying addresses will remain the same. This makes onboarding new team members easier, as the project’s structure is logical and self-documenting, and it ensures the system won’t collapse as your project grows from 50 screens to 500.

4. Streamlined Project Management

Imagine writing a Jira or Asana ticket that says, “Fix the validation bug on 2-03-06-02.” The developer knows instantly and precisely where to find the error: in the Checkout flow, on the Payment screen, in the CVV section. This level of precision makes documentation clearer, bug reports more effective, and the entire management process more efficient. Ultimately, these benefits lead to faster development cycles, fewer bugs, and a more aligned and collaborative team environment.

Conclusion: Your Atlas Awaits

We began this journey by acknowledging a familiar problem: the chaos that comes from having no real and consistent naming convention.

The Atlas Outline offers a clear path forward out of this chaos by providing a simple, memorable address for every flow, screen, state, and section. It transforms your project from a tangled wilderness into a world that can be easily and confidently navigated by everyone on your team.

This framework builds a durable bridge between the worlds of design and development. Investing a small amount of effort in this structure upfront will pay you back tenfold in saved time, fewer bugs, and a truly collaborative workflow.

Examples

Here are a few examples that hopefully make it easier to understand how to use the Atlas Outline.

Website Example

To see the Atlas Outline in action, let’s map out a familiar example: a standard corporate website with a clear information architecture.

The site’s navigation is organized into three distinct areas:

1. Main Menu (Primary user navigation)

Homepage
Products
- Hardware: This page lists categories like Displays, Harddrives, Computers, and Cables.
- Software: This page lists categories like Graphic Software, Games, and Business.
Services
Contact

2. Info Menu (Legal and company information, often in the footer)

About Us
Terms
Data Policy
Imprint

3. User Menu (For account management)

Login / Logout
Account

Here is how you get started.

The most important first step is to group pages by user journey (Flow), not by their visual position in the navigation menus. This ensures the numbering system remains stable even if you redesign the menus later.

Defining the Flows

Based on the scenario, we can define four logical user flows:

0- Authentication: The process of logging in.
1- Core Business & Discovery: The main journey of a user exploring what the company offers (homepage, products, services, contact).
2- Company & Legal Information: The secondary journey for users seeking information about the company itself (about us, terms, imprint).
3- Account Management: The journey for an authenticated user managing their account details.

Numbering the Website Screens

With the flows defined, we can now assign a unique address to each page. For these examples, we’ll primarily use the default state (-00).

0- Authentication Flow

0-01-00 Login Page: The main screen for the authentication process.
0-01-06 Login Page (Error State): The same screen, but showing an error message after a failed login attempt.

1- Core Business & Discovery Flow

1-00-00 Homepage (Start): The primary entry point for the main user journey.
1-01-00 Products (Main Page): The top-level products page.
1-01.1-00 Hardware Submenu Page: The page a user lands on after clicking the “Hardware” submenu item. It is a child of the Products page (1-01).
1-01.1-00-01 Hardware Page (Categories Section): This refers specifically to the section on the Hardware page that lists the categories (Displays, Harddrives, etc.).
1-01.1.1-00 Computers Category Page: A user has clicked on “Computers” from the Hardware page. This is a drill-down, making it a child of the Hardware page (1-01.1).
1-01.2-00 Software Submenu Page: The page for the “Software” submenu item, a sibling to the Hardware page (1-01.1).
1-02-00 Services Page: A top-level peer to the Products page.
1-03-00 Contact Page: Another top-level peer.

2- Company & Legal Information Flow

2-01-00 About Us Page
2-02-00 Terms Page
2-03-00 Data Policy Page
2-04-00 Imprint Page

3- Account Management Flow

3-00-00 Account Dashboard: The main page a user sees after logging in to manage their account. This is the entry point for this flow.

This structure provides a clear, logical, and scalable map of your entire website. Even if you were to move the “Contact” page from the main menu to the info menu, its number (1-03-00) would remain the same because its purpose hasn’t changed.

5 Problems Atlas Outline Solves

Ambiguous and Inconsistent Naming

Most projects lack a formal naming system, leading to a “collection of bad habits” where screens are named inconsistently. This creates a state of chaos where no one is certain what to call a specific view, wasting time and causing confusion.
Chaotic Design-to-Dev Handoffs

Developers often receive design files without a clear specification for all the different variations of a screen (e.g., error messages, empty states, loading animations). This forces them to guess what to build, which often leads to missed requirements, bugs, and frustrating rework cycles.
Fragile Naming Tied to the UI

Traditional naming is often based on the visual layout or sitemap. When the UI is inevitably redesigned—for example, when a feature is moved in the navigation menu—the entire naming structure breaks, requiring a massive effort to rename hundreds of files and update all documentation.
Lack of Scalability

Simple naming conventions that work for a small 10-page website quickly break down under the pressure of a complex application with hundreds of screens and states. As the project grows, the system becomes more confusing and unreliable.
Inefficient Project Management

Writing tickets, bug reports, or documentation is often imprecise. A ticket that says “Fix the bug on the checkout screen” is vague and requires follow-up questions to pinpoint the exact location and state of the error.

5 Benefits Atlas Outline Provides

Crystal-Clear Communication

The Atlas Outline creates a universal and unambiguous language for the entire team. By providing a unique address for every view, it establishes a single source of truth that drastically reduces misunderstandings.
Flawless and Precise Handoffs

The design files themselves become a precise specification. A Figma frame named 1-01.1-05 (Project View – Empty State) tells a developer everything they need to know, eliminating guesswork and ensuring all states are built correctly the first time.
Future-Proof Stability

Because the system is tied to a screen’s function (Flow) rather than its visual position, it is incredibly stable. You can completely redesign the website’s UI, and the underlying addresses will remain the same.
Built-in Scalability

The framework is designed to work just as well for a simple MVP as it does for a complex, 500-screen application. The structured, hierarchical format (Flow-Screen-State-Section) ensures the system remains logical and organized as the project grows.
Streamlined Project Management

The system allows for incredibly precise references. A ticket can now say, “Fix the validation bug on 2-03-06-02,” and the developer knows instantly to look at the Checkout flow, on the Payment screen, in the CVV section. This makes bug reports and documentation more effective and the entire management process more efficient.

Frequently Asked Questions

Isn’t this system overkill for my small website or project?

Not at all. The beauty of the Atlas Outline is its scalability. For a small project, you might only ever use the first three components (Flow-Screen-State). The system provides a solid foundation that grows with your project, so you never have to waste time inventing or reorganizing a system later. It’s about building a good habit from the start.

How should I number modals, pop-ups, or dialog boxes?

Treat any view that takes over the user’s primary focus as a new Screen within the current flow. For example, if a user is on the “Product Detail Page” (1-01.1-00) and clicks “Write a Review,” the pop-up modal would be a new screen in that hierarchy, such as 1-01.2-00. This keeps the logic clear: it’s a new, focused interaction related to the previous screen.

Why use numbers instead of descriptive words like Products-Hardware-Error?

This is a core design choice for three reasons:

Brevity and Clarity: 1-01.1-06 is much shorter and faster to reference in tickets and documentation.
Language Independence: Numbers are universal. 06 means the same thing to a developer in Hamburg, a designer in London, and a QA tester in Tokyo.
Reduces Ambiguity: Descriptive names create endless debates. Is it “Products” or “ProductList”? “Error” or “ErrorState”? Numbers eliminate this ambiguity entirely. The number is the unique ID; the description is its label.

What about dynamic, user-created content, like a new To Do list? I can’t pre-number those.

This is handled by creating a “template” number. In your design, you would create a single, generic screen for “User-Created List View” and assign it a number like 1-10-00. In your documentation and design system, this number then represents the template for any list the user creates. It’s a way to number the functionality, not every piece of individual content.

Should my code components or file names match the Atlas Outline numbers?

Not necessarily. The Atlas Outline is a communication and referencing system, not a strict file-naming convention for code. Code has its own organizational logic (e.g., Atomic Design, feature folders). The Atlas Outline number is the bridge between the two worlds. You would use it in your Jira tickets, design documentation, code comments (// Corresponds to Atlas Outline ID: 2-01-06), or Storybook to link a specific design to a specific component.

What happens if I reorder items in my navigation? Do I have to rename everything?

No, and this is a key strength of the system. The numbers are tied to the function of a screen, not its visual order. If your “Services” page (1-02-00) moves above the “Products” page (1-01-00) in the main menu, their numbers do not change. This stability ensures that a simple UI refresh doesn’t break your entire project’s documentation.