Screen ID Naming Conventions: Giving Every Page a Stable Name

On a project with three agencies, two time zones and a client review cycle, the single most expensive ambiguity is "the product page". Which one? The listing, the detail, the comparison view, the mobile variant? A screen ID removes that question permanently, and it costs one column in a spreadsheet.

What a screen ID is for

A screen ID is a short, stable identifier for one screen in the information architecture. It appears in the IA sheet, in the design file's frame name, in the development ticket, in the QA test case, and in the client's feedback email. Everyone points at the same string.

The benefits compound on larger projects:

• Unambiguous reference. "LAF-KR-P-03 is missing the size selector" needs no further explanation.
• Traceability. Requirement → design → implementation → test case are linked by the same key.
• Scope control. Counting screens by ID makes "we added three screens" a fact rather than an argument.
• Localisation management. The same screen across five markets is one row per market, related by a shared suffix.

A scheme that holds up

{BRAND}-{LOCALE}-{GROUP}-{SEQ}

LAF-KR-P-03
 |   |  |  └ sequence within the group, zero-padded
 |   |  └ functional group
 |   └ locale
 └ brand / site code

Brand (3 characters). Uppercase, derived from the site or brand name: LAF, INN, SUL. Fixed for the life of the project.

Locale. KR, EN, JP, TW, GLOBAL. Use the market you actually operate, and keep it consistent with your URL locale segments so an ID maps to an address.

Group. The depth-0 functional area. A compact set that covers most sites:

Code	Group	Typical screens
C	Common	GNB, footer, search, global modals
M	Main	Home, hero, homepage sections
P	Product	Category, listing, detail
B	Brand	Brand story, philosophy
CO	Company	About, history, network
S	Support	FAQ, contact, downloads
E	Event	Campaigns, promotions
CT	Content	Blog, articles, news
A	Account	Login, join, my page
CTT / CHK	Cart / Checkout	Cart, order, payment
O	Other	Anything genuinely uncategorised

Sequence. Two digits, zero-padded, assigned in the reading order of the IA sheet — which is grouped by depth-0 and then ordered by click depth.

The result reads at a glance: SUL-JP-P-07 is the seventh product-area screen of the Japanese Sulwhasoo site.

The rule that makes it work: IDs are immutable

This is where most conventions fail. Once an ID is issued, it never changes meaning:

• A deleted screen's ID is retired, not reused. If P-03 is dropped, P-04 does not become P-03. The gap is a feature — it tells you something was removed.
• New screens get the next number, even if they belong in the middle of the sheet conceptually. Sort order is a column; identity is not.
• Renaming a screen keeps the ID. "Product Detail" becoming "Item Detail" is a label change.
• Moving a screen between groups is a new ID, with the old one retired and a note pointing to it. This is the one genuinely disruptive case, so it is worth stabilising the group taxonomy early.

If IDs shift between revisions, every downstream document silently rots, and people stop trusting the ID — at which point you are back to "the product page".

Generating IDs from a crawl

Assigning IDs by hand for 400 screens is a day of work and produces inconsistencies. Generating them from a site crawl takes minutes and is deterministic.

DeepAnalyzer emits the full BRAND-LOCALE-GROUP-SEQ key for every crawled screen: the brand comes from the hostname, the locale from the path or domain, the group from taxonomy classification of navigation labels and URL patterns, and the sequence from the sorted IA order. Because the sort is stable, re-running the crawl on an unchanged site produces the same IDs.

For an AS-IS analysis of a competitor or a legacy site you are about to replace, that is usually enough on its own. For a TO-BE document, treat the generated sheet as a first draft: freeze the IDs at the point the sheet is approved, then apply the immutability rules from there. The moment of freezing matters more than the moment of generation.

Using the IDs across the project

Design. Frame names in Figma become LAF-KR-P-03 Product Detail. Reviewers can then cite a frame without a screenshot.

Development. Tickets reference the ID; route definitions carry it in a comment. Code review against an IA sheet becomes possible.

QA. Test cases map one-to-one onto IDs, so coverage is countable: 112 screens, 112 test cases, 9 untested.

Client communication. Feedback arrives as "LAF-KR-S-02: phone number is wrong" instead of "the contact page, the one with the map, not the other one."

Localisation. LAF-KR-P-03 and LAF-JP-P-03 are the same screen in two markets, which makes translation scope and market-specific deviation both easy to see.

Common mistakes

Encoding too much. LAF-KR-PROD-DETAIL-SIZE-SELECT-01 is a description, not an identifier. Keep the ID short and put the description in the adjacent column.

Sequential numbering across the whole site. LAF-KR-001 through LAF-KR-247 means inserting a screen renumbers everything after it. Group-scoped sequences keep the blast radius small.

Encoding the URL. URLs change. IDs must not.

Skipping the common group. GNB, footer and global search are screens in the IA sense — they have requirements, designs and test cases. Give them IDs.

Different conventions per agency. Agree the scheme in the kickoff, not in week six.

FAQ

How many groups should I define?

Eight to twelve. Fewer and the groups stop being informative; more and people cannot remember them, so classification becomes inconsistent between contributors.

What if a screen belongs in two groups?

Pick the group that owns the requirement — usually where the screen appears in the primary navigation — and note the secondary relationship in the comments column. One screen, one ID.

Do modals and popups get IDs?

If they have distinct requirements, yes. A confirmation dialog with its own copy, states and error handling is a screen. A tooltip is not.

How do I handle responsive variants?

One ID per screen, not per breakpoint, with responsive behaviour documented in the same row. Separate IDs only when mobile and desktop are genuinely different flows rather than different layouts.

Can I change the scheme mid-project?

You can, once, early, with a mapping table from old to new — and only if the current scheme is actively causing errors. After designs and tickets reference the IDs, the cost of changing exceeds the benefit almost every time.