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 nearly 30 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.

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:

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.

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.

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)

The [Screen] identifies a specific, unique view or page within a Flow. This is the primary "map" in our Atlas that shows where the user is.

• The 00 Screen: The number 00 is reserved for the main entry point or "index" screen of a Flow. For example, 1-00 would be the Homepage of a website.
• Using Capital Letters: In the unlikely case that you run out of screen numbers, then you use A-Z. After 99 would then come A1, A2, A3 … B1, B2, B3 and so on. The 0 still represents the initial state of the screen, so A0 and B0 are reserved.
• The Hierarchy Rule (.): To show a parent-child relationship, we use a period. This is perfect for list-to-detail patterns.
  • Example: 1-01 could be the "Product Listing Page," and 1-01.1 would be the "Product Detail Page" for an item from that list. This keeps related screens logically grouped. For sibling menu items, like product categories, simply give them their own numbers (e.g., 1-02 for Hardware, 1-03 for Software).

The [Screen] identifies a specific, unique view or page within a Flow. This is the primary "map" in our Atlas that shows where the user is.

• The 00 Screen: The number 00 is reserved for the main entry point or "index" screen of a Flow. For example, 1-00 would be the Homepage of a website.
• Using Capital Letters: In the unlikely case that you run out of screen numbers, then you use A-Z. After 99 would then come A1, A2, A3 … B1, B2, B3 and so on. The 0 still represents the initial state of the screen, so A0 and B0 are reserved.
• The Hierarchy Rule (.): To show a parent-child relationship, we use a period. This is perfect for list-to-detail patterns.
  • Example: 1-01 could be the "Product Listing Page," and 1-01.1 would be the "Product Detail Page" for an item from that list. This keeps related screens logically grouped. For sibling menu items, like product categories, simply give them their own numbers (e.g., 1-02 for Hardware, 1-03 for Software).

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 wait, there is one more thing (to quote Steve Jobs).

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. 

• Example:
  
  • 1-02.1-06_A: Product Detail Page - Error State (Variation A).
  • 1-02.1-06_B: Product Detail Page - Error State (Variation B).
  • 1-02.1-06: The final, approved version.

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 JJMMDD.

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 pipe symbol (|) is a great separator because it's not used in either semantic versioning or the YYMMDD date format.

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."

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.

• 00-19: General UI States. These are the universal states for any project (Default, Hover, Active, Loading, General Error/Success, etc.).
• 20-49: 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-79: 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-99: Custom / Project-Specific States: This leaves a flexible range for any other unique states your project may require.

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 (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.

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

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

Here is an example showing every component in use:

1-01-02-00_A@2.2.0|250924b

• 1-01-02-00: The core screen ID (e.g., Password Reset Dialog, Default State).
• _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.

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:

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.

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.