Forms, data views, status states and operational screens were repeating the same decisions without one reliable set of rules. The system had to improve consistency without forcing a full redesign.
Case study / B2B HR Design System
Turning repeated UI decisions into a shared product system.
The product did not need a new coat of paint. It needed a common language for decisions that were being solved repeatedly across dense HR workflows, product screens and implementation.
Design Systems
B2B + HR
UI Foundations
Component Rules
Engineering Handoff
I defined foundations, component behavior, interaction states and usage rules, connecting what designers needed to decide with what developers needed to implement.
12+ foundations and component groups covering color, typography, grids, shadows, icons, loaders, form states, tables and dashboard patterns.
Story
The system had to improve delivery, not decorate Figma.
A component library would not solve the real problem on its own. The team needed to understand when to reuse a decision, when a product context required an exception and how states should behave once the screen reached development.
I focused on the layer where product quality becomes visible in daily work: hierarchy, spacing, states, component behavior and documentation that could survive beyond the original Figma file.
01 / Foundations
Start with decisions that affect every screen.
I started by defining the visual foundations that every screen depends on: color, typography, layout, spacing and elevation. This gave the interface a more stable hierarchy before moving into individual components.
- Created a clearer visual language for product screens.
- Defined repeatable rules for hierarchy, spacing and surface depth.
- Kept the system aligned with the existing product direction.
02 / Utility Layer
Design the states people notice when the product stops moving.
The utility layer covers the details that often create inconsistency: icon sizing, loaders, empty states and progress feedback. These patterns reduce ambiguity in the moments where the product is loading, waiting or guiding the user forward.
- Documented reusable patterns for transitional states.
- Reduced one-off decisions across repeated interface moments.
- Protected clarity in loading, empty and in-progress states.
03 / Components
Components are product decisions, not reusable shapes.
Components were organized around usage, states and behavior, not only appearance. Buttons, badges, inputs, dropdowns, search, tabs, progress, empty states, toasts and messaging patterns were treated as product decisions that needed to be reused consistently.
- Defined component states, sizes and usage logic.
- Designed for dense B2B screens where consistency matters at scale.
- Made the library easier to translate into reusable frontend patterns.
04 / Data & Patterns
The system had to survive dense product screens.
B2B HR products are rarely made of simple marketing pages. The system needed to support tables, task lists, popups and attachment patterns: the kind of everyday product density where clarity, hierarchy and spacing directly affect usability.
- Supported data-heavy workflows and repeated operational tasks.
- Created patterns for lists, tables, overlays and attachments.
- Balanced information density with readable, human interface rhythm.
05 / Impact
A clearer contract between design and development.
The system gave the team a more reliable base for creating, reviewing and implementing product screens. Instead of treating consistency as a final visual check, it made the underlying rules available earlier in the design and delivery process.
- Improved design consistency across product patterns.
- Created a clearer source of truth for design and development.
- Made future UI work easier to scale without restarting from scratch.
