BEN KAGUAMBA
P
r
o
d
u
c
t
V
i
s
u
a
l
M
o
t
i
o
n
S
y
s
t
e
m
P
r
o
d
u
c
t
designer.
designer.
Welcome
Enjoy a sample of my work - the ideas and energy that power my process.
BEN KAGUAMBA
P
r
o
d
u
c
t
V
i
s
u
a
l
M
o
t
i
o
n
S
y
s
t
e
m
P
r
o
d
u
c
t
Product
designer.
This is one of those "Big" internet things. Please use a desktop or larger screen width.
FEATURED WORK
HALFORDS DESIGN SYSTEM
2024-25
Building Halford's first scaleable, best-practice design system from the ground up.
Design Systems
UI
Context: A Fragmented Experience
When I joined Halfords, the digital product experience was inconsistent and fragmented. The design team relied on a loosely structured Figma file which was a collection of sprint outputs without governance, documentation, or a shared language.
This caused real friction. Across Halfords’ vast product and service range (spanning cycling, motoring, and service fulfilment) inconsistent UX patterns were undermining customer confidence, while inefficiencies in design and development slowed down delivery.
At the same time, Halfords was beginning a technical transformation: a move toward a headless CMS and React-based frontend. This wasn’t just a re-platforming effort, it was an opportunity to rebuild the foundations of the digital experience properly.
There was no formal brief, but I recognised the opportunity early. I took ownership of the challenge, began driving the work forward, and led the creation of Halfords’ first structured design system.
My Role
As the lead UX/UI designer, I worked alongside two other designers. While they focused on product delivery, I independently defined, built, and scaled the design system — from foundational tokens to live component libraries. My role extended far beyond asset creation: I shaped the strategy, connected design decisions to technical realities, and embedded the system across design and development.
Token Architecture
I built a three-tier token architecture to support flexibility and future-proofing:
Raw Values: Base HEX/pixel codes
Primitives: Structured colour families (e.g. orange.500, neutral.600)
Semantic Aliases: Role-based tokens (e.g. Surface-Default, Error-Background, On-Surface-High)
This separation allowed us to change visual styling without breaking design consistency, while providing engineers with stable, meaningful variables.
Colour Roles & Accessibility
Inspired by accessibility principles, I defined a robust system of colour roles: text states, surface colours, interaction states (hover, pressed, disabled), and semantic meanings (success, error, warning). Each pairing was tested to meet WCAG standards by default.
Typography System
I replaced fragmented typography (separate sets for mobile, tablet, and desktop) with a single, proportional scale. Semantic tokens allowed typography to adapt across contexts while preserving hierarchy and rhythm.
Spacing & Grid
I introduced a base-4 spacing system mapped to design relationships — from micro (input-label) to macro (page sections). The grid system followed four responsive breakpoints with consistent gutter and margin rules, aligned with reflow and accessibility standards.
Iconography System
I audited and rebuilt Halfords’ icon library as structured Figma components, categorised by size (20px–44px), and paired with Material Icons for functional coverage. I also defined clear usage guidance: when to use outline vs filled, minimum sizes, and accessible colour pairings.
From Tokens to Components
Working in parallel with a site-wide redesign, I began building molecule and organism components (buttons, inputs, cards, modals) and validating them through live product work. Each molecule referenced core tokens and followed accessibility best practices (contrast, focus states, tap targets).
This allowed us to balance consistency with pragmatism — components were flexible enough to evolve as product needs surfaced, but grounded in a shared design language.
Scaling Through Organisms and Governance
With atoms and molecules in place, I moved on to organisms — larger design structures supporting Halfords’ diverse proposition. To ensure these scaled cleanly:
I introduced a Figma library system with strict publishing workflows
I ran working sessions to align naming conventions between design tokens and code
I created “incubation” spaces where new ideas could be explored safely without polluting the core library
Collaboration and Implementation
Team Adoption
Designers quickly adopted the system in their own work. I supported this with regular training, detailed documentation, and hands-on help — especially with more complex components. The system became a shared language across the team, improving both quality and velocity.
Engineering Integration
All tokens were implemented into Storybook by our front-end developers, allowing for seamless integration of design and development. The result was a consistent, high-standard frontend foundation that accelerated delivery and reduced ambiguity at handoff.
What I’m Most Proud Of
I’m particularly proud of the colour and typography systems. These foundational tokens are where design meets expression — and getting them right meant enabling creativity within constraints. They not only elevated the product’s tone and rhythm, but gave the rest of the team the tools to build accessible, confident experiences with ease.
From Systems to Solutions
With the foundations in place, I shifted focus to one of Halfords’ biggest UX challenges: the ecommerce purchasing journey.
This next case study explores how I applied the design system to redefine a complex fulfilment flow — simplifying the experience for customers under pressure, and setting the stage for better business outcomes.
RE-IMAGINING THE HALFORD'S PURCHASING JOURNEY
2024-25
Migration to a headless React front end created an opportunity to address one of Halfords’ most persistent UX problems: fulfilment complexity. I initiated and led an end-to-end redesign that simplified the purchasing flow and allowed it to scale cleanly.
Leadership
Strategy
UX
React Migration as an Opportunity
Halfords was preparing for a headless React upgrade when I caught sight of a bigger picture. The brief covered framework parity only, yet the migration meant every critical template would be rebuilt line by line. This opened the door to question the flow itself - an unexpected gain - to reduce the cognitive load caused by fulfilment logic without slowing the migration.
I sketched two journey maps: the first captured the old flow in meticulous detail; the second imagined what would happen if fulfilment choices moved closer to checkout. The maps neatly illustrated the weight of every extra click.
Building The Case: A Three Part Investigation
1st came a site audit - I walked page by page through the entire purchasing journey and saw the same overload pattern repeat.
On the product page the fulfilment stepper ran so far down the screen that it stranded the main image and pushed key details - description, specs, reviews - below the fold.
In the basket each fulfilment bucket carried its own pair of change‑method buttons, so a four‑item basket could show eight extra controls and force needless scrolling.
Calendar widgets were equally fragmented: garage MOTs offered two daily slots, Mobile Expert showed hourly windows and click and collect fittings used half‑hour increments.
The audit proved the journey felt busy and space inefficient long before any metrics entered the discussion.
2nd came a competitor review - IKEA, Currys and Argos all delay fulfilment until users committed to products, and their flows look faster and clearer.
3rd came an internal roadshow - I gathered refined the story into a concise deck and presented it to product, engineering and leadership. The pitch was simple: we were rebuilding anyway, so why not rebuild smarter?
What the Data Showed
Working with the lead product owner on raw Google Analytics on basket composition we found the numbers were decisive; the average basket contained 1.7 items and fewer than one in 150 orders mixed fulfilment types. We were making every customer pay a cognitive cost for a feature almost no one used.
Once stakeholders saw that only 0.67% orders had a mixed fulfilment type the conversation moved quickly from whether we should change to how we would deliver the change. Edge cases were still discussed, but defending the status quo now required fresh evidence.
I proposed a straightforward countermeasure: surface availability early and ask for commitment later. A concise availability line on the product page would inform users without trapping them. Consensus followed, and the redesign moved from idea to funded roadmap.
Modelling the Complexity
Halfords fulfils through four channels: home delivery, click and collect, garage services and mobile expert. Some products, such as car batteries, shift between retail and service depending on fitting. Each channel carries distinct stock checking and location rules.
Critically, and to simplify the flow, we decided that fulfilment would be selected for the basket as a whole, not per item. The system therefore needed to know in real time whether every item could share a fulfilment method. We also required location data early enough to display availability without heavy user input. Borrowing from Apple and IKEA, we explored automatic postcode detection and fallback postcode entry in the header and product page.
Design Strategy: PDP, Basket and the Calendar
The fact that only 0.67% of orders had mixed fulfilment types drove every design choice that followed.
On the legacy product page the entire fulfilment workflow unfolded in a single stepper that turned the page into a mini checkout. We replaced it with a concise line beside the Add to Basket button that simply states “Collect today after 6 pm” or “Delivery in five to seven days”. Commitment now happens later.
For the hybrid state, where fulfilment still had to be finalised on the product page, the detailed interface moved into a sliding drawer that appears only after Add to Basket. Five of six hallway testers located the drawer in under three seconds. The page is clear and the component remains detachable when the dedicated fulfilment stage launches.
Basket
The basket followed the same principle: show product information and hide architecture. Items had been split into fulfilment buckets complete with controls for switching method and time. We removed the buckets and now list items with image, title, price, quantity and a remove option. When an item already has a booking, the booking sits beneath the title so relevance is obvious without extra containers.
Calendar
Calendar selection moved into its own drawer. Decoupled from specific pages it can appear wherever performance data proves most effective. In the full future flow it will live inside the fulfilment stage, but if analytics later show that service categories convert better when bookings surface earlier, the same drawer can be summoned from the product page without touching basket code.
The calendar’s portability makes the flow future-ready for experiments on placement and category optimisation. Together these changes create pages that read at a glance while giving us the ability to bring the booking drawer forward for an MOT campaign or leave it later for simple retail baskets without rewriting basket code.
Phased Rollout: In Four Steps
Checkout was simplified first because it carried the fewest technical constraints.
Next came the product page, which introduced availability surfacing and postcode capture.
The basket was rebuilt last to support items without pre‑selected fulfilment.
Finally, the dedicated fulfilment stage was introduced to centralise selection and booking.
Throughout the process I collaborated with engineers, product owners and embedded designers. The design system team supplied high fidelity designs and pattern libraries while feature teams handled edge cases.
Cultural Shifts
I defined the token set, built core components and documented design rules. Weekly collaboration calls with embedded designers and code parity sessions with engineering tightened feedback loops and reduced handoff friction. The design system became a living product that scales with minimal debt.
Reflection and Outcomes
The core challenge was fulfilment complexity, but solving it required changes to architecture, flow, process and culture. Modelling basket level fulfilment rules proved the hardest technical task. The most instructive lesson came from moving a concept with no brief into production by linking evidence to outcome. The redesign is rolling out in phases, but early testing and smoother team collaboration show that the foundation is stronger than before.
PONTIC : DEVELOPING A FINANCIAL PLATFORM FOR DENTISTS
2023-25
I conceived and am currently developing Pontic, a financial platform for UK dentists, created to fill a gap in accessible, profession-specific financial planning. I defined the vision and designed a dashboard uniting income, expenses, tax, and leave forecasting in one system.
Fintech
Healthcare
Next JS
Context: Pontic
Dentists in the UK face an unusual set of financial pressures: irregular income, fragmented expenses, and complex tax structures. The tools available to them are generic at best. I began shaping Pontic as a response to that gap, a profession-specific platform bringing income, expenses, tax, and time-off planning together in one place.
Different versions and experiments of layout as I explored.
Action
Working independently, I set the vision and began mapping how such a system could look and function. I explored the architecture, sketched dashboard flows, and tested how information might be surfaced in a way that feels approachable rather than overwhelming. AI played an important role in this phase, acting as a partner in rapid prototyping, helping me move from abstract idea to tangible structures, components, and early interface designs far quicker than would otherwise have been possible. Alongside this, we established a design system directly in code, building it from scratch using SCSS files to create tokens, utilities, and reusable patterns that could scale with the product.
Outcome
Pontic remains a work in progress, but the project demonstrates how I take an identified gap and begin translating it into product form. It captures my approach to scoping complexity, experimenting with emerging tools, and articulating a clear direction that could scale into a fully realised platform.
I conceived and am currently developing Pontic, a financial platform for UK dentists, created to fill a gap in accessible, profession-specific financial planning. I defined the vision and designed a dashboard uniting income, expenses, tax, and leave forecasting in one system.
Fintech
Healthcare
Next JS
Context: Pontic
Dentists in the UK face an unusual set of financial pressures: irregular income, fragmented expenses, and complex tax structures. The tools available to them are generic at best. I began shaping Pontic as a response to that gap, a profession-specific platform bringing income, expenses, tax, and time-off planning together in one place.
Different versions and experiments of layout as I explored.
Action
Working independently, I set the vision and began mapping how such a system could look and function. I explored the architecture, sketched dashboard flows, and tested how information might be surfaced in a way that feels approachable rather than overwhelming. AI played an important role in this phase, acting as a partner in rapid prototyping, helping me move from abstract idea to tangible structures, components, and early interface designs far quicker than would otherwise have been possible. Alongside this, we established a design system directly in code, building it from scratch using SCSS files to create tokens, utilities, and reusable patterns that could scale with the product.
Outcome
Pontic remains a work in progress, but the project demonstrates how I take an identified gap and begin translating it into product form. It captures my approach to scoping complexity, experimenting with emerging tools, and articulating a clear direction that could scale into a fully realised platform.
BIO
My name is Ben Kaguamba.
I have a mixed cultural background, being both Kenyan and British (yes, I miss the sun). My dog keeps me active and humble (if I had a pound for every time someone said 'Who's walking who?'). He's an African Hunting Dog, the regal Rhodesian Ridgeback.
SKILLS
UX/UI Design
Web Design
Figma & Framer
HTML & CSS
Spline
Rive
Adobe CS
ben.kaguamba@gmail.com
CONNECT
BEN KAGUAMBA