BH Design System
The BH UI Toolkit is a central design system underpinning virtually all digital products across the Baker Hughes organisation, enabling design and development teams to build consistently and at scale.
Objectives
Streamline processes, build, improve, and maintain a scalable, central component library that supports all Baker Hughes digital products while ensuring consistency across the entire organisation.
Challenges
The existing design system suffered from rigid component structures, inconsistent documentation, and a high barrier to adoption.
- Earlier version had an extensive growing backlog of unresolved GitHub issues
- Multiple project teams had already adopted version one and were experiencing friction
- Technical resource constraints limited the pace of improvement
- Third-party library dependencies created additional architectural constraints
Approach
Not everything goes into the design system
Rather than discarding what existed, I chose to diagnose and repair the foundation first — conducting a thorough analysis of the existing design and code architecture before prescribing improvements.
Federated Model
I initiated a federated model, embedding designers and developers from teams already using version one. A steering committee was established to align priorities and manage incoming change requests, significantly reducing the backlog.
Roadmap & Milestones
A structured roadmap was developed to clearly communicate the current state, prioritised actions, and target outcomes across the organisation.
Three-Tier Architecture
A three-tier architecture with Atomic Design approach was adopted to support multi-product, multi-brand scalability with clear separation at token, component, and pattern levels.
Atomic Design
Foundation & Components
Colour System
The colour palette was comprehensively upgraded with full tint/shade ranges, semantic alert states, data visualisation colours, and foundational tokens supporting multi-project needs.
Theme and multi-brand support (White label product)
Tokens are created and mapped in such a way that it supports both light and dark themes. This helped designers to easily swap themes, extend to support their brands and devs to use the right code.
Typography
Typography defined to support responsive screens with a clear visual hierarchy across all breakpoints.
Component Library
Components were built in alignment with brand standards and I implemented WCAG 2.1 accessibility guidelines to achieve Level AA compliance. Existing base components were iteratively enhanced rather than fully replaced, ensuring minimal disruption to ongoing live projects.
Documentation
Zeroheight served as the single source of truth. Every sprint produced updated component documentation including usage guidelines and "Dos and Don'ts". Release notes communicated via email and maintained in GitHub.
Communication and Code Release
- Connecting with multiple project teams and listening to their component needs built trust within the global teams.
- Right amount of communication in right time helped teams to take project level decisions
- Regular code releases and detailed notes gave them better clarity on code changes
Outcomes
Let's build something meaningful together.
Open to discussing new opportunities, design challenges, and collaborations.