Skip to main content
Marketplace · Design systems

Design System for Heavy Equipment Operations

Creating one coherent product language across more than 2,000 components, six operational contexts, and five hundred screens for a national heavy-equipment marketplace.

Read case studyAll projects

Key results

500+

screens across six product contexts

2,000+components across the Design System
30+developers coordinated with design
20 monthsof design and delivery leadership
2021–2023Client under NDA

Project colophon

Heavy (client under NDA)

2021–2023
Role
Design Lead / UX Designer / Design PM Proxy
Engagement
20 months
Scope
UX/UI · User Testing · Design System · Design Project Management
Tools
Balsamiq · Figma · Storybook · Confluence

Areas of impact

This was not a single product redesign. The platform connected sourcing, rental operations, internal tools, and customer experiences, each with its own workflows and stakeholders. More than five hundred screens were required across six contexts, supported by a Design System containing over 2,000 components.

I worked as Design Lead, UX Designer, and later Design PM proxy. My responsibility was to keep the experience coherent while coordinating with more than thirty developers and helping a large international team move quickly enough to meet investor-driven deadlines.

At this scale, consistency is not achieved by reviewing every screen. It comes from aligning the system, the prototypes, and the way the team delivers work.
01/04System scale+
01

System scale

One language across six products

The team used Atomic Design to turn repeated interface needs into a shared foundation. We produced eight comprehensive libraries with corresponding documentation in Storybook and Confluence, supporting four major operational contexts and their related customer experiences.

Designing beyond the component library

The Design System had to support dense enterprise workflows while meeting ISO-informed expectations and satisfying stakeholders across the United States, Europe, and Japan. We created detailed prototypes and more than 160 screens for the sourcing context alone.

The goal was not visual uniformity for its own sake. Shared patterns reduced the number of decisions each product team had to remake and made complex operational flows easier to learn across contexts.

Map of the six operational contexts - customer portal, sales, finance, supply, lifecycle and supplier portal - served by one systemComponent anatomy diagram labelling every asset, separator, icon and button group inside a single row componentButton variants documented across contained, ghost, split and cancel treatments within the component groupQuote summary flowing through supplier selection to invoice details across the marketplace screens
Six contexts, one Design SystemSix operational contexts on one map, the component anatomy underneath them, its button set, and the quote-to-invoice path they assemble into.
02

Validation

Prototypes that behaved like products

User testing included operational users and C-level executives. Enhanced prototypes contained instructions, realistic scenarios, and embedded questions, allowing participants to experience complete flows instead of isolated screens.

Finding impediments before development

Testing exposed usability risks while they were still inexpensive to change. The scenarios were also structured so future designers could repeat or adapt them without reconstructing the original study.

This made research an enduring delivery asset: it improved the current release and created reusable evidence for later decisions.

Briefing screen shown to test participants: think aloud, no rush, we're testing the designs and not youDifficulty rating collected inside the prototype itself, so each task is scored the moment it is finishedPer-task usability results pairing a success and failure split with verbatim participant feedback
An app-like testing environmentThe participant briefing, the difficulty rating collected inside the prototype after each task, and the findings that came out of it. Testing in the prototype meant no separate research tooling to reconcile afterwards.
03

Delivery leadership

Making design a reliable delivery partner

A large developer group and many stakeholders made information transfer a project risk. I became the Design PM proxy and a single point of contact for design delivery.

One sprint ahead

We organized design in Agile sprints with a one-sprint overlap ahead of engineering. Scrum ceremonies helped surface impediments early, maintain full team capacity, and protect the delivery date despite investor pressure.

Where UX had limited influence, I brought data-backed examples into planning and review conversations. This shifted discussions from preference toward evidence and steadily increased the attention given to usability across the platform.

Executive summary turning usability findings into concrete UX recommendations for the supplier portalThe full screen inventory in one view, the artefact used to keep five hundred screens coherentMobile delivery confirmation and job-site views, carrying the same system to a handset in the field
Design delivery at scaleThe executive summary, the full screen inventory, and the mobile views. Five hundred screens stay coherent only if somebody can see all of them at once.

Reflection

The system included the way we worked

The most important system was not only the Figma library. It was the combination of reusable components, realistic validation, clear ownership, and a delivery rhythm that kept design close to engineering.

That operating model helped the team deliver a broad redesign on time while improving usability across a platform whose complexity could easily have fragmented the experience.

Next project

Redesigning a Growing Salon Platform→