Design system, components and patterns

4 designers. 15+ modules. No shared library.

This project didn't follow a traditional UX research process -- it was a systems problem that needed a systems response. Four designers were working in parallel on different modules with no shared components, no naming conventions, and no agreed-upon patterns. Stakeholders kept flagging inconsistencies in demos. New features took longer to ship because every team reinvented the same UI solutions.

The first step was a full product audit -- not of user behaviour, but of design decisions. Every screen across all 15 modules was reviewed against four questions:

• Visual consistency: Do fonts, sizes, buttons, and labels look the same across modules?
• Functional consistency: Do the same interactions behave the same way everywhere?
• Internal consistency: When we introduce new pages, do users already know how to use them?
• External consistency: Are we aligned with the mental models users bring from other enterprise tools?

Five consistency pillars as the design brief.

The audit output wasn't a bug list -- it was a brief. We identified five pillars where inconsistency was causing the most friction for users and the most rework for designers:

Atomic Design as the framework. Figma as the source of truth.

We adopted Atomic Design (Atoms → Molecules → Organisms → Templates → Pages) as the structural framework for the component library. Every UI element was categorised into this hierarchy, then built in Figma with variants, nested components, and shared tokens.

One of the most valuable outputs of the design system audit was discovering that policy creation follows an identical structural pattern across 6 modules -- Attendance, Leave, Payroll, Field Visit, Shifts, and Expense. Once identified, we standardised it as a reusable template:

One Figma library. One token system. Two platforms.

The component library was built in Figma with full variant support, nested component overrides, and a shared token layer that spans both web and mobile. Every pattern documented in Confluence with the same structure: Importance, Goals/Needs, Solution, Anatomy, Variants, Do's and Don'ts, and Usage Examples.

• Figma component library: All atoms, molecules, and organisms with Figma variants and auto-layout. Any designer on the team can swap states and override content without breaking the structure.
• Shared token layer: Colour tokens (Light L1, Secondary Text L0, Error D1, etc.), spacing tokens, and typography tokens are defined once and applied across web and mobile components.
• Confluence documentation: Every pattern has a dedicated Confluence page with screenshots, anatomy diagrams, and explicit do/don't guidance. 30+ patterns documented to date.
• Design-to-dev handoff: Component names in Figma match class names in the codebase. CSS variables align with token names. AG Grid table columns documented with exact pixel values for developer implementation.

Measurable consistency across all new modules.

The design system was adopted across all new feature development from the point of launch. Impact was visible in both design velocity and product quality:

• New modules start from templates, not blank artboards. Field Visit Tracking, the last major module shipped, used 100% library components -- zero custom UI invented for the module.
• Stakeholder review sessions reduced from 3-4 rounds to 1-2. Consistent components meant reviewers focused on flow and logic, not visual inconsistencies.
• The policy creation pattern standardised across 6 modules -- HR managers familiar with Leave policy creation needed no training for Attendance or Payroll policy setup.
• Blue collar kiosk UI was built entirely from atoms. The face-scan kiosk required only 2 unique components -- everything else was assembled from library atoms.