/ › Documentation Docs › Expand an area: Guidelines
    Sign in

    On this page

    • Expand an area: Guidelines
      • A common objection
      • Consistency is critical
      • Rules
    • Principles
      • Use the alphabet
      • Use the date
      • Stop using numbers
      • Use natural hierarchies
      • Look for patterns
      • Invent your own scheme
      • Use existing codes

    Community

    • Forum
    • Discord

    System expansion

    • System expansion: Introduction
    • Multiple systems: Overview
    • Multiple systems: Guidelines
    • Expand an area: Overview
    • Expand an area: Guidelines
    • Extend the end: Overview
    • Extend the end: Guidelines

    Pre-built systems

    We spent hundreds of hours designing them so you don't have to.

    • Life Admin System
    • Small Business System

    Expand an area: Guidelines

    A common objection

    People see this and say, "well what's the point of Johnny.Decimal if I can just make up my own thing?". To which I say: there are no absolutes in life.

    I'm trying to be pragmatic and honest. My default system is great for many things, not every thing. We can still use the principles of Johnny.Decimal to stay organised – these are outlined below.

    Consistency is critical

    You can build almost any 'shape' of system and be organised. The key is to be consistent in your structure and file naming. This sounds obvious, but if it's front of mind you won't go far wrong.

    Help your future self by documenting your scheme and design decisions in your JDex. The standard zero 00.00 Index would be a good place.

    Rules

    Only expand the part that needs to be expanded

    Aim to expand a single area of your system.

    Most of what you do should still fit in the standard Johnny.Decimal structure. If you're a freelance designer, manage the rest of your business with standard areas and categories.

    All IDs start with the area number

    Standard Johnny.Decimal IDs start with the number of the area they're in: 83.66 belongs to area 80-89.

    You must retain this pattern. You're going to expand one area. Choose that area, and then ensure that every number that it contains starts with the area number.

    Example

    In the Small Business System, area 50-59 is expanded and uses a five-digit non-standard numbering scheme: A0000 … A9999. A indicates the area that has been expanded.

    In this example, the usable numbers are 50000 … 59999. Expanding 70-79 the range would be 70000 … 79999.


    Principles

    Use the alphabet

    In a standard Johnny.Decimal system, numbers replace the alphabet as the primary sort. This is because most things do not benefit from being sorted alphabetically.

    But some things do. For example, if you have a long list of organisations, ordering them alphabetically makes sense.

    It makes no sense to allocate the organisations a number and sort numerically. See figure 62.27A below.

    Use the date

    Many things benefit from being ordered chronologically: jobs for a client; semesters at university.

    And we tend to remember where these kind of things happened 'in time'. So the date can help us find things later.

    Look for opportunities to use the date. This must always be specified as year-month-day in the format yyyy-mm-dd, e.g. 2024-08-30. This will sort chronologically in your filesystem.1 See figure 62.27A below.

    Stop using numbers

    In a standard Johnny.Decimal system, every item has a number: the ID. However in many expand-an-area scenarios, numbers might only make sense at the higher levels.

    Use numbers to guide you to the place you need to be. Or where there isn't an alphabet or date alternative.

    But when they become a burden, or when the alphabet or date is better, stop using them. See figure 62.27A below.

    Use natural hierarchies

    If natural hierarchies exist, use them. Why invent another scheme for something that already has one?

    Example: A freelancer

    A freelance designer organises their workload by client, product, then job. Use this hierarchy in your system (or adapt it to your own situation). Don't worry that it breaks the area → category → ID structure. See figure 62.27A below.

    Look for patterns

    A sub-principle of 'be consistent': always look for patterns. If you do something over and over it should be a template. This saves time and helps your brain.

    Templates usually benefit from having numbers to keep them in order. Numbering in tens (10, 20, 30) makes sense here. It leaves room between items (05, 15, 25) for one-offs or items you forgot.

    Example: A freelancer

    A freelance designer creates promotional material for the footwear industry. They have two clients, Joe's Shoes and Tammy's Trainers. Joe makes three products: Big Boots, Cool Kicks, and Sick Sneakers.

    The jobs follow a similar pattern. The client provides a brief, copy, images, and video. The designer produces working files for review and a final delivered product.

    This is an opportunity to make a reusable template. And to use numbers again. Not as a unique identifier, but to control the order of filesystem folders.

    Here's how their system might look. Area 10-19 is a standard Johnny.Decimal area, and they've expanded 20-29 to handle their clients and jobs.

    20-29 Clients and jobs
    ā”œā”€ā”€ā”€ā”€ Joe's Shoes
    │     ā”œā”€ā”€ Big Boots
    │     │   ā”œā”€ā”€ 2025-06-30 Box design
    │     │   │   ā”œā”€ā”€ā”€ 10 Brief
    │     │   │   ā”œā”€ā”€ā”€ 20 Copy
    │     │   │   ā”œā”€ā”€ā”€ 30 Images
    │     │   │   ā”œā”€ā”€ā”€ 40 Video
    │     │   │   ā”œā”€ā”€ā”€ 50 Reviews
    │     │   │   └─── 60 Final
    │     │   ā”œā”€ā”€ 2025-07-08 Full page ad
    │     │   │   ā”œā”€ā”€ā”€ 10 Brief
    │     │   │   ā”œā”€ā”€ā”€ 20 Copy
    │     │   │   └─── …
    │     │   └── 2025-08-11 ABC TV ad
    │     │       └─── …
    │     ā”œā”€ā”€ Cool Kicks
    │     │   └── 2025-06-30 …
    │     └── Sick Sneakers
    │         └── …
    └──── Tammy's Trainers
          └── …
    Figure 62.27A. A freelancer's templated system. It employs the principles: Use the alphabet, Use the date, Stop using numbers, Use natural hierarchies, Look for patterns.

    Invent your own scheme

    There's a reason people love their Johnny.Decimal IDs. They're a useful shortcut in many situations. So if you need an ID for something, feel free to make one up. Just remember: be consistent.

    Example: A freelancer

    I like to give each of my invoices a unique ID that relates to the job.

    In the example above, we might invent a scheme like 20.JOE.BB.20240708. We're not going to use this code every day. But it serves as an unambiguous reference to that job when we need one.

    And I shouldn't have to explain this scheme: it's obvious to which job I'm referring. Annotate your filesystem and JDex to make the scheme self-documenting.

    20-29 Clients and jobs
    ā”œā”€ā”€ā”€ā”€ Joe's Shoes (JOE)
    │     ā”œā”€ā”€ā”€ā”€ Big Boots (BB)
    │     │     └──── …
    │     ā”œā”€ā”€ā”€ā”€ Cool Kicks (CK)
    │     │     └──── …
    │     └──── Sick Sneakers (SS)
    │           └──── …
    └──── Tammy's Trainers (TTR)
          └──── Chucks for Chicks (CC)
                └──── …
    Figure 62.27B. The freelancer's system annotated with codes for later use. Note the consistency: every client code is three letters; every product code is two.

    Use existing codes

    Much of life already uses the concept of a short code. University courses have them. Creative agencies use them. Almost every professional job management system will allocate a 'job number' of some kind. So where a code exists, don't invent another.

    Example: A student

    Our student attends university in the Northern Hemisphere. They use the standard Life Admin System at 10-19.

    And they have a similar structure at 20-29 to handle the administration of being a student: finances, accommodation, and extra-curricular clubs. These are standard Johnny.Decimal areas.

    Their courses require an expand-an-area solution. They naturally group by year then semester, and each has a code assigned by the university. Within each course, we use the same template, numbered from 10 … 60.

    It's convenient that the first semester, Autumn, sorts before Spring. If this wasn't the case, we could add numbers to the front to force a sort. Perhaps the month?

    10-19 Life admin
    20-29 University admin
    30-39 University courses
    ā”œā”€ā”€ā”€ā”€ 2024
    │     ā”œā”€ā”€ Autumn
    │     │   ā”œā”€ā”€ ENVE422
    │     │   │   ā”œā”€ā”€ 10 Course requirements
    │     │   │   ā”œā”€ā”€ 20 Course curriculum
    │     │   │   ā”œā”€ā”€ 30 Research & reading
    │     │   │   ā”œā”€ā”€ 40 Exam prep
    │     │   │   ā”œā”€ā”€ 50 Submissions
    │     │   │   └── 60 Results
    │     │   └── ENVE435
    │     │       ā”œā”€ā”€ 10 Course requirements
    │     │       ā”œā”€ā”€ 20 Course curriculum
    │     │       └── …
    │     └── Spring
    │         ā”œā”€ā”€ ENVE423
    │         │   └── …
    │         └── ENGS501
    │             └── …
    ā”œā”€ā”€ā”€ā”€ 2025
    │     ā”œā”€ā”€ Autumn
    │     │   ā”œā”€ā”€ BIOL323
    │     │   │   ā”œā”€ā”€ 10 Course requirements
    │     │   │   ā”œā”€ā”€ 20 Course curriculum
    │     │   │   └── …
    │     │   └── PHIL666
    │     │       └── …
    │     └── Spring
    │         └── …
    └──── 2026
          └── …
    Figure 62.27C. A student's system with an expanded area for course work. Note the consistency: every year has two semesters; every semester has course codes; every course is templated.

    Footnotes

    1. This is ISO 8601 for the date nerds. ↩


    ā—€ Back Expand an area: Overview Extend the end: Overview Next ā–¶ (Use the ← arrow keys →)

    Written by humans • Search • Support