Atlas : A Design System for PIF

Atlas Design System

Building one shared language for a product ecosystem that runs on jury debates, design submissions, and government time.

Problem

Two designers and a small engineering pod were shipping three connected products for PIF, and without a shared library, the same dropdown was being rebuilt three times in three different shades of grey. Every new screen meant re-deciding things we'd already decided.

Three PIF products were shipping without a shared library, so the same UI patterns kept getting rebuilt and re-decided.

Solution

Atlas is a four-tier component library and token architecture built in eight weeks: sub-atoms feed atoms, atoms compose molecules, molecules form organisms. One Figma file, Tailwind-aligned tokens, and bilingual support handled at the foundation layer because the product had to ship in Arabic and English from the same components.

Atlas is a four-tier component library built in eight weeks, with Tailwind-aligned tokens and bilingual Arabic-English support baked into the foundation.

Role

Co-designed the system end-to-end with one other product designer while shipping the consumer-facing interfaces in parallel.

Duration

2 Months, alongside a contract role with McKinsey.

THE SHINY HIGHLIGHTS

ATLAS AT A GLANCE

Four tier system

Built on a four-tier token system to create scalable, reusable, and consistent UI patterns across the product.

04

ORGANISMS

03

MOLECULES

02

ATOMS

01

SUB ATOMS

Four tier design system

Built on a four-tier token system to create scalable, reusable, and consistent UI patterns across the product.

04

ORGANISMS

03

MOLECULES

02

ATOMS

01

SUB ATOMS

I] The thing I kept hearing

Where I learned the real problem wasn't visual. It was infrastructural.

Where I learned the real problem wasn't visual. It was infrastructural.

The context

The context

PIF's Smart City Hub runs international architecture competitions on behalf of the Saudi government, and the platform we were building had to host the whole messy workflow across two other products with a deadline that didn't move.

The moment it became obvious

The moment it became obvious

I wasn't planning to build a design system. Then in week two an engineer asked me which [Button] to use because there were already three of them in the file, and a week later a PM circled the same form field on three different screens and asked whether it was the same component or three different things. The honest answer to both was "I don't know."

"Submit" buttons across products

Smart City Hub

Submit

14px / 4px radius / #1E3A8A

KVS

Submit

13px / 8px radius / #2563EB

PIF Suite

Submit

15px / pill / #1D4ED8

Same intent.

Three different blues.

Three different shapes.

"Email" fields across products

Smart City Hub

Email

name@email.com

KVS

EMAIL ADDRESS

Enter your email

PIF Suite

e-mail*

type here

Different label cases.

Different border treatments.

Same field, three voices.

Shades of grey across the file

#94A3B8

#9CA3AF

#A1A1AA

#9E9E9E

#A3A3A3

#999999

#8E8E93

#92929D

Eight greys.

All called "grey".

None of them tokens.

"Submit" buttons across products

Smart City Hub

Submit

14px / 4px radius / #1E3A8A

KVS

Submit

13px / 8px radius / #2563EB

PIF Suite

Submit

15px / pill / #1D4ED8

Same intent.

Three different blues.

Three different shapes.

Smart City Hub

Email

name@email.com

KVS

EMAIL ADDRESS

Enter your email

PIF Suite

e-mail*

type here

"Email" fields across products

Different label cases.

Different border treatments.

Same field, three voices.

What we found in the Figma file in week two

Problems found

Auditing the obvious options

Auditing the obvious options

We audited Material 3, Carbon, and Polaris before writing a single token. Each was excellent in its context, but none fit ours.


  • Material 3 carried Google's brand DNA in ways PIF couldn't ship
    .

  • Carbon was the closest philosophical fit, government grade and accessible. Its component
    library was deeper than we needed in some places and shallower in the niche places we needed most, like jury scoring and weighted submissions.

  • Polaris was beautiful but built for ecommerce.

Criteria

Material 3

Google

Carbon

IBM

Polaris

Shopify

Atlas

What we built

Bilingual / RTL support

First-class Arabic was non-negotiable

Bolted on later

Possible, not native

English-first

Brand fit for PIF context

Government-grade, neutral, restrained

Reads as Google

Government-grade

E-commerce DNA

Built for it

Niche components we needed

Jury scoring, weighted submissions

Generic only

Some, not enough

E-commerce only

Designed in

Accessibility (WCAG AA)

Required by client procurement

Strong

Best in class

Strong

Theming flexibility

Dark mode + brand swap from day 1

Themed for Google

Strong

Possible

3-tier tokens

Strong fit

Partial fit

Poor fit

Audited against our actual screen inventory before we wrote a single token

The decisive criterion

The deeper issue was that none handled Arabic right to left as a first class default, which is what we needed. So we forked the philosophy without forking the file.

  • shadcn's structural approach

  • Carbon's accessibility discipline

  • Material's documentation rigor

II] Foundations

The architectural choice that changed every conversation downstream.

The architectural choice that changed every conversation downstream.

Why a fourth tier

Why a fourth tier

Atomic design has three tiers. We added a fourth underneath called sub atoms: typography, spacing, radius, color, shadows, the things most systems file away as tokens in a documentation appendix.

We promoted them to a tier of their own at the top of the file structure, which sounds pedantic but changed how the team worked.

  • Designers stopped reaching for raw hex values.

  • Engineers stopped hand coding padding:12px

  • Every conversation now had to first reference a sub atom, and if the sub atom didn't exist, that became the conversation worth having first.

The pattern

The pattern

We landed on a four part dot notation pattern: [category].[concept].[role].[modifier]. So a button background is color.surface.primary.default, and the same on hover is color.surface.primary.hover.

Two rules we held the line on

Two rules we held the line on

  • No values in names
    color.brand.500 is forbidden, color.brand.primary is required. Values change, roles don't.

  • No direction in spacing
    space.left is forbidden, space.inline.start is required. That's the lever that makes bilingual support automatic everywhere downstream.

Together, these two rules meant we could retheme the product, swap brand colors, and flip the language without touching a component file.

The pattern

[category].[concept].[role].[modifier]

Category

color

What kind

of token

.

Concept

surface

Where it

applies

.

Role

primary

What job

it does

.

Modifier

hover

State or

variant

More examples

font.body.lg.regular

Body text, large size, regular weight

space.inline.start.tight

Inline spacing (start↔end), tight density

radius.surface.card.default

Border radius, applied to cards, default state

color.text.muted.disabled

Text color, muted role, disabled state

The pattern

[category].[concept].[role].[modifier]

Category

color

Concept

surface

Role

primary

Modifier

hover

More examples

font.body.lg.regular

space.inline.start.tight

radius.surface.card.default

color.text.muted.disabled

four part dot notation pattern

The bilingual problem

The bilingual problem

A button with a leading icon in English needs the icon on the left. The same button in Arabic needs it on the right. Same component, same token, different rendering.

How we solved it

How we solved it

We encoded direction into spacing tokens themselves: space.inline.start and space.inline.end instead of space.left and space.right. The system reads document direction at runtime and resolves automatically, so components never need to know which language they're in.

Actual product screens (LTR / RTL)

III] Design System

The architectural choice that changed every conversation downstream.

The architectural choice that changed every conversation downstream.

I] Sub Atoms

I] Sub Atoms

The vocabulary below components. Tokens for typography, spacing, color, radius, shadows, and breakpoints, the values everything else inherits. Sub atoms aren't components yet, they're the raw material components are made of.


We documented eight sub-atom token sets here, each one named according to the same four part convention. If a sub atom doesn't exist, no atom can quietly invent it.

SUB-ATOMS

8 tokens

· 2 categories

Visual styles

Aa

Typography

Color

Shadows

Radius

16:9

Aspect ratio

Layout & structure

Spacing

Breakpoint

Separator

Examples from the system

Below are a few selected examples from the design system, showcasing how semantic tokens were written, structured, and documented across different Sub-atom primitives.

SUB-ATOMS

8 tokens

Ashish 28

Energetic, fitness conscious, social

The Resilient Go-Getter

Struggles to balance an active lifestyle with flare-ups, conscious of appearance, finds strict routines frustrating

Flexible care strategies, motivational tracking, community support

Seema 36

Busy professional, caregiver, family woman

The Overwhelmed Multitasker

No time for frequent appointments, stress-induced flare-ups, hesitant to change diet

Simple guided routines, stress-management techniques, meal planning help

Ashish 28

Reserved, practical, stability over change

The Experinced Warrior

Feels psoriasis is a lifelong struggle, skeptical about new treatments, avoids socialising in events

Personalized coaching, discreet solutions, empathetic community engagement

Key takeaways from the Interviews

'Spacing' tokens

(the ones that handle bilingual)



space.inline.start.tight = 8px


space.inline.start.cozy = 12px


space.inline.start.comfy = 16px


space.inline.start.loose = 24px


space.inline.end.tight = 8px


space.inline.end.cozy = 12px


& So on


spacing

'Radius' tokens

radius.surface.card= 12px


radius.surface.modal= 8px


radius.surface.button= 8px


radius.surface.input= 8px


radius.surface.badge= 8px


radius.surface.image= 8px


& So on


Radius

II] Atoms

II] Atoms

The smallest functional pieces of the interface. A button is an atom, an input is an atom, a badge is an atom. Each one does one thing, takes its values from sub atoms, and ships with every variant and state baked in.

We landed at around fifteen atoms, each documented with its full state matrix, default, hover, active, focus, disabled, loading, error. The point isn't that an atom is small. The point is that it's complete on its own.

ATOMS

15 components

· 3 categories

Media & identity

Icons

AB

Avatar

BRAND

Logos

Video

Form controls

Button

Button

All

New

Filter

Tab 1

Tab 2

Tabs

Pick…

Select

Type here…

Input

Type…

Text area

Toggle

Slider

Feedback & display

Badge

Badge

Tooltip text

Tooltip

Progress

Examples from the system

Below are a few selected examples from the design system, showcasing how semantic tokens were written, structured, and documented across different Atom components. It also shows token properties that help with state management, such as default, hover, active, and so on.

ATOMS

15 components

Ashish 28

Energetic, fitness conscious, social

The Resilient Go-Getter

Struggles to balance an active lifestyle with flare-ups, conscious of appearance, finds strict routines frustrating

Flexible care strategies, motivational tracking, community support

Seema 36

Busy professional, caregiver, family woman

The Overwhelmed Multitasker

No time for frequent appointments, stress-induced flare-ups, hesitant to change diet

Simple guided routines, stress-management techniques, meal planning help

Ashish 28

Reserved, practical, stability over change

The Experinced Warrior

Feels psoriasis is a lifelong struggle, skeptical about new treatments, avoids socialising in events

Personalized coaching, discreet solutions, empathetic community engagement

Key takeaways from the Interviews

'Button' token property

button.variant = default | secondary | destructive


button.size = sm | default | lg | icon


select.state = default | hover | focus | loading | disabled | pressed

Visual Tokens

button.default.backgroud.default


button.secondary.backgroud.hover


button.destrcutive.backgroud.focus


button.ghost.backgroud.loading


& So on

40%

Button (Scroll Around)

'Select' token property

select.show-icon = true | false


select.border.filled = true | false


select.text.label = true | false


select.text.label.disabled =


default | focus | filled | filled-focus | disabled

Visual Tokens

select.backgroud.default


select.border.filled


select.text.label


select.text.label.disabled


& So on

70%

Select (Scroll Around)

III] Molecules

III] Molecules

Combinations of atoms that solve one specific UI problem. The atom answers "what's the smallest piece," the molecule answers "what's the smallest useful piece."

Around twenty molecules in the library, each one assembled from atoms we'd already designed.

MOLECULES

20 components

· 6 categories

Overlays & popups

Dialog title

Content area

OK

Cancel

Dialog

⚠ Alert

Confirm action?

Yes

Alert dialog

Popover

Content here

Popover

Toast notification

Sonner

Hover card

Preview content

Hover card

Form groups

Option A

Option B

Radio group

Check A

Check B

Checkbox

S

M

L

Toggle group

Switch

Navigation

Home

Docs

Page

Breadcrumb

Item A

Item B

Dropdown menu

Search…

Command

Action 1

Action 2

Context menu

Data display

Section

Content row

Accordion

Chart

Col A

Col B

Data

Data

Data

Data

Table

Row title

Collapsible

Layout utilities

Resizable

Scroll area

Skeleton

Examples from the system

Below are a few selected examples from the design system, showcasing how semantic tokens were written, structured, and documented across different molecule components. It also shows token properties that help with state management, such as default, hover, active, and so on.

MOLECULES

20 components

Ashish 28

Energetic, fitness conscious, social

The Resilient Go-Getter

Struggles to balance an active lifestyle with flare-ups, conscious of appearance, finds strict routines frustrating

Flexible care strategies, motivational tracking, community support

Seema 36

Busy professional, caregiver, family woman

The Overwhelmed Multitasker

No time for frequent appointments, stress-induced flare-ups, hesitant to change diet

Simple guided routines, stress-management techniques, meal planning help

Ashish 28

Reserved, practical, stability over change

The Experinced Warrior

Feels psoriasis is a lifelong struggle, skeptical about new treatments, avoids socialising in events

Personalized coaching, discreet solutions, empathetic community engagement

Key takeaways from the Interviews

'Checkbox' token property

checkbox.active = active | inactive


checkbox.state = default | focus | disabled | pressed


checkbox.show-text = true | false


checkbox.show-description = true | false

Visual Tokens

checkbox.background.inactive


checkbox.background.disabled


checkbox.border.inactive


checkbox.border.focus


checkbox.icon.checkmark


checkbox.text.label


& So on


70%

Checkbox (Scroll Around)

'Switch' token property

switch.variant = default | box


switch.state = default | focus


switch.active = on | off


switch.label-position = left | right

Visual Tokens

switch.track.background.off


switch.track.background.on

switch.track.background.on.disabled..dis


switch.box.background.


switch.box.border

& So on

70%

Switch (Scroll Around)

IV] Organisms

IV] Organisms

Organisms are where the system meets the product, and where the system gets tested hardest, because organisms are the things users actually look at.


Eleven organisms, built from molecules and atoms underneath them. By the time we got to this tier, almost every decision had already been made one or two layers down. That's the point of the architecture: the further up the stack you go, the fewer choices you should have to make.

ORGANISMS

11 components

· 3 categories

Navigation & shell

Logo

About

Work

Header

Main content

Sidebar

1

2

3

Pagination

Content & display

Card title

Description text

Card

Slide 1

Content

Carousel

Name

Status

Date

Row 1

Active

Jan 5

Row 2

Pending

Jan 8

Data table

Section title

Section

Interactive & input

Name

Input…

Email

Input…

Form

May 2026

Mo

Tu

We

Th

Fr

8

9

10

11

12

Date picker

Select option…

Option A

Option B

Combobox

Sheet

Action

Sheet

Examples from the system

Below are a few selected examples from the design system, showcasing how semantic tokens were written, structured, and documented across different organism components. It also shows token properties that help with state management, such as default, hover, active, and so on.

ORGANISMS

11 components

Ashish 28

Energetic, fitness conscious, social

The Resilient Go-Getter

Struggles to balance an active lifestyle with flare-ups, conscious of appearance, finds strict routines frustrating

Flexible care strategies, motivational tracking, community support

Seema 36

Busy professional, caregiver, family woman

The Overwhelmed Multitasker

No time for frequent appointments, stress-induced flare-ups, hesitant to change diet

Simple guided routines, stress-management techniques, meal planning help

Ashish 28

Reserved, practical, stability over change

The Experinced Warrior

Feels psoriasis is a lifelong struggle, skeptical about new treatments, avoids socialising in events

Personalized coaching, discreet solutions, empathetic community engagement

Key takeaways from the Interviews

'Combobox' token property

combobox.show-avatar = true | false


combobox.show-label = true | false


combobox.show-description = true | false


combobox.show-group-label = true | false


combobox.state = default | hover | focus | disabled | pressed

Visual Tokens

combobox.background.default


combobox.border.hover


combobox.text.focus


combobox.icon.chevron


combobox.avatar.size


& So on

70%

Combobox (Scroll Around)

'Card' token property

card.variant = non-operational-devco | non-operational-pif | operational

card.lifecyle-stage = L1 | L2 | L3 | L4 | L5


card.status = on-track | at-risk | validate | live


card.show-image = true | false




card.show-kpi = true | false



Visual Tokens

card.backgroud


card.text.tittle

c

card.text.kpi.value


card.badge.status.live


& So on

70%

Card (Scroll Around)

IV] Governance

Light enough nobody dreaded it. Structured enough it killed bad requests.

Light enough nobody dreaded it. Structured enough it killed bad requests.

Contributing a new component

Contributing a new component

Anyone could propose a new component by opening a thread in #design-system with a screenshot of the unmet need. Every Friday, the team triaged proposals into one of three outcomes.

  • Use the existing component differently. The most common outcome.

  • Extend the existing component. Second most common.

  • New component warranted. The rarest, and the only path that opened a build ticket.

Communication channels

Communication channels

Communication ran on three channels.


  • Slack release notes for every change, written like a changelog.

  • A 30 minute open Tuesday office hour for whoever wanted to ask anything.

  • Notes panels inside the Figma components themselves, explaining what each was for and what it explicitly wasn't for.

Deprecating a component

Deprecating a component

When something had to die, it got a: [deprecated] prefix in Figma, a Slack release note, and a 30 day migration window before archive. We deprecated four components in eight weeks.

01

Slack

Propose

Open a thread in #design-system with a screenshot of the unmet need.

Use existing differently

~50% of proposals

+

Extend existing

~30% of proposals

+

New component

~20% — continues below

03

Figma

Build

Proposer drafts the component. The team refines and names as per convention.

02

Friday : 30min

Triage

Foundation team reviews proposals and decides one of three outcomes.

04

Slack Release note

Ship

Release to the library with a slack post: what changed, why and which screen.

how a new component gets in

V] Reflection

Light enough nobody dreaded it. Structured enough it killed bad requests.

Light enough nobody dreaded it. Structured enough it killed bad requests.

Reflections

Reflections

What turned out harder than I expected

What turned out harder than I expected

  • Naming

    I budgeted a day; it took two weeks. Every name encodes a decision about what's a category and what's a variant.

  • Bilingual edge cases

    Arabic isn't English flipped. Numbers stay LTR inside RTL paragraphs, punctuation behaves differently, and date pickers needed two genuinely different mental models. Encoding direction at the token layer solved 80%. The last 20% was hand tuning.

What worked

What worked

  • Sub atoms as a visible tier.

    People stopped designing in pixels and started designing in tokens.

  • Encoding direction into spacing tokens early.

    Cost a week, saved a month.

  • Friday triage.

    Lightweight enough nobody dreaded it, structured enough it killed bad requests.

Numbers from a system thats still rolling out

Numbers from a system thats still rolling out

Component Reuse

80%

Target (≥80% sessions)

Baseline: 30–40%

Design-to-handoff

-60%

faster than pre system baseline, measured per screen

Products consuming atlast

2/3

One in private beta

One shipped

One yet to adobpt

Three hero Metrics

Check Out Other Projects

Other Projects

Ashish 28

Energetic, fitness conscious, social

The Resilient Go-Getter

Struggles to balance an active lifestyle with flare-ups, conscious of appearance, finds strict routines frustrating

Flexible care strategies, motivational tracking, community support

Seema 36

Busy professional, caregiver, family woman

The Overwhelmed Multitasker

No time for frequent appointments, stress-induced flare-ups, hesitant to change diet

Simple guided routines, stress-management techniques, meal planning help

Ashish 28

Reserved, practical, stability over change

The Experinced Warrior

Feels psoriasis is a lifelong struggle, skeptical about new treatments, avoids socialising in events

Personalized coaching, discreet solutions, empathetic community engagement

Key takeaways from the Interviews

Dr Reddy’s Daily Bloom

Dr Reddy’s Daily Bloom

Making psoriasis care and UV therapy simpler, more engaging, and easier through an app.

Making psoriasis care and UV therapy simpler, more engaging, and easier through an app.

View Project

Prudential Health Insurance

Prudential Insurance

Prudential Health Insurance

Designing a digital experience that makes insurance feel simple, guided, and reliable.

Designing a digital experience that makes insurance feel simple, guided, and reliable.

View Project

Let's connect & make something great!

I'm always open to new opportunities, collaborations, and connections. Whether you have a project you'd like to discuss, want to share your work, or just say hi! Feel free to reach out.

@2026 • Made with heart, hustle, and a few too many ‘just one more tweak’ moments by Pranay

@2025 • Made with heart, hustle, and a few too many ‘just one more tweak’ moments by Pranay

Let's connect !

Open to collaborations, projects, and new connections. Feel free to reach out or just say hi.

Atlas Design System

Building one shared language for a product ecosystem that runs on jury debates, design submissions, and government time.