Design system / Project story
From foundations to components, from components to patterns. A story about turning repeated UI decisions into a system that leaves room for the work each product needs to do.
Atlas is a design system built to support a rapidly growing B2B platform operating across multiple business domains — procurement, sales, credit, order management, and logistics.
01 / The starting point
Procurement screens, credit dashboards and enquiry flows serve different needs. Atlas explores what they can share: a consistent vocabulary for hierarchy, interaction and feedback, without forcing every workflow into the same layout.
Client — Aditya Birla Pivot.
This story pairs the implemented portfolio system with your supplied reference screenshots and recordings. Reference material is preserved as supplied; it does not establish team ownership, research execution or measured business outcomes.
02 / The principles
03 / Building & scaling
Phase 01
Discover the repetition
Before adding more components, identify where the same task behaves differently. The supplied story starts with procurement, sales, credit and order workflows: repeated tables, filters, navigation and forms become the starting point for a shared language.
Phase 02
Establish the language
The next layer is a vocabulary, not just a palette. Semantic tokens describe the purpose of a value; typography and spacing establish hierarchy. In this portfolio, Atlas applies that separation so the same components can follow the active theme.
Phase 03
Define the behaviour
A button is more than its resting appearance. Intent, size, state and optional content describe how it behaves. The supplied component examples bring these variations together, while a reference library gives new patterns room to develop before becoming shared defaults.
Phase 04
Maintain the system
A library needs a way to evolve. The supplied governance material describes shared review, release cycles, walkthroughs and feedback. These are the operating principles for sustainable adoption—not a measured claim about this portfolio’s rollout.
04 / Connecting design & delivery
The supplied property panels make the contract tangible: intent, size, appearance, state and optional icons. Documentation then adds context—when to use a pattern, how it responds and what stays consistent across platforms.
05 / What the story demonstrates
Atlas is implemented here as a token and documentation layer. The supplied material illustrates how that thinking can extend into enterprise components, team practices and product flows. The production screens below show the domain context; no adoption figures or delivery improvements are claimed without supporting evidence.
The implemented foundations behind this portfolio.
01
Six ramps, eleven stops each. The brand base is copper #c97f52 at stop 500. Sister hues keep copper's saturation and lightness and shift hue only, so every ramp shares relative luminosity. Primitives are never used directly in components.
Copper · brand --atlas-copper-50…950
Neutral --atlas-neutral-50…950
Red --atlas-red-50…950
Green --atlas-green-50…950
Amber --atlas-amber-50…950
Blue --atlas-blue-50…950
02
The only colors components may reference. Each role aliases the active theme, so the four palettes re-skin every component without a single semantic name changing.
Background
page canvas
--atlas-bg
Surface
cards, raised blocks
--atlas-surface
Fill
quiet fills, hover wash
--atlas-fill
Text / primary
headings, body emphasis
--atlas-text-primary
Text / secondary
captions, metadata
--atlas-text-secondary
Text / inverse
on ink buttons
--atlas-text-inverse
Stroke / default
hairlines, card borders
--atlas-stroke-default
Stroke / strong
hover borders
--atlas-stroke-strong
Interactive
links, accents, focus
--atlas-interactive
Success
positive feedback
--atlas-success
Warning
caution feedback
--atlas-warning
Error
destructive feedback
--atlas-error
Info
neutral feedback
--atlas-info
03
Six roles on a ×1.25 modular scale over a 4px base. Display and Heading step up automatically at the desktop breakpoint — consumers never set sizes manually.
Display
Urbanist · 40/64px · 600 · -0.03em
atlas-display
Complicated products, made calm.
Heading
Urbanist · 32/44px · 600 · -0.02em
atlas-heading
The tools I think in.
Title
Urbanist · 20px · 600 · -0.01em
atlas-title
Danske Bank Research Hub
Body
Epilogue · 16px · 400 · 1.65
atlas-body
For 7+ years I've turned procurement, banking, trading and B2B workflows into interfaces people finish tasks in without a manual.
Label
Epilogue · 13px · 600 · 0.01em
atlas-label
View case studies
Caption
Epilogue · 12px · 500 · 0.02em
atlas-caption
Conceptual illustrations, not product screenshots.
04
Spacing · 4px base
Radius
radius-sm
radius-md
radius-lg
Elevation
elevation-1
elevation-2
elevation-3
05
Components are defined by intent, consume semantic tokens only, and ship their hover, focus, active and disabled states built in — consumers never style states manually. Focus rings are always visible; contrast meets WCAG AA.
Buttons
atlas-btn · atlas-btn-primary / -accent / -ghost
Badges
atlas-badge
Cards
Resting
Surface, hairline stroke, elevation-1.
Raised
Elevation-2 for hovered or active surfaces.
Featured
Elevation-3, the premium shadow, for hero surfaces.
atlas-card
06
Editorial reading column
Long-form content sits in a measured 740px column inside a 1060px container — the case-study rhythm.
Copper-italic emphasis
One italic accent word per headline, in the interactive color. Never more than one.
Instant on mobile
Scroll-reveal motion is desktop-only; on phones every element renders immediately.
Theme-safe by construction
Because components only touch semantic tokens, all four palettes — light and dark — just work.
07
Following Brad Frost's Atomic Design, Atlas components are organised into five intent groups.
Properties as API contracts
Design props and code props carry the same names and values, so a component is described the same way in the design file and in the codebase.
<Button
variant="primary | accent | ghost"
size="sm | md | lg"
icon="leading | trailing | none"
disabled={boolean}
/>Component management
The library stays curated, not a catch-all. New organisms live locally in their feature until they earn a place by meeting all three criteria:
Proven reuse
Used across more than one domain, not a one-off.
Consistency is critical
Brand or experience breaks if it drifts.
Clear value
It removes repeated decisions or build effort across teams.
08
Repeating user intents become patterns. The objective: standardise system logic and response everywhere, while layout and data density stay context-specific.
Drawer
Side sheet on desktop, bottom sheet on mobile — same hierarchy, actions and dismissal rules.
Card
One structure for summary, metadata and actions; density adapts to the surface it sits on.
Platform & domain variance
06 / The final screens
Selected supplied Birla Pivot screens bring the story back to the product: mobile enquiry flows, credit-monitoring dashboards and detailed enquiry responses. They illustrate the kinds of tables, drawers and forms a shared system needs to support, with Birla Pivot’s own branding.
Vijay.
Loading