Case study · Design systems · GEP Worldwide

The problem. GEP’s products shared a font and a color palette, but no design system. Design reviews turned into arguments, and teams kept building their own versions of the same controls.

The answer in brief. I proposed Radiant and spearheaded it, because a design system would make accessibility simpler for everyone. It has 80+ components and 42,000+ design tokens. A senior designer and I built it, a talented developer manager worked with me on the coded component library, and I set the accessibility standards and gave the final review of designs. About 16 product teams used it. Accessibility checks ran in the build, so teams caught problems before release.

My role: Head of Accessibility and Design Systems, Nov 2022 to Jun 2026. By the end I managed six people on the design system and accessibility work, one in Romania and five in India.

Before Radiant

When I joined GEP, I spent my first months fixing WCAG problems for a major banking client. At the same time, a designer was starting work on a design system. The senior director of UX heard my story about building WCAG practice and a design system at HealthEquity, and she brought the two efforts together.

The existing style guide covered fonts and colors. It left a lot of room for opinion. Designers argued over each decision, and product and development disagreed with them. Nobody had asked for a design system. I saw the arguments growing and thought there had to be a faster way to settle them.

Designers worried they would lose creative freedom. The opposite happened. They spent less time choosing controls and more time solving the actual problem.

What is in it

Radiant has 80+ components and more than 42,000 design tokens. The tokens cover color, text size, fonts, spacing, themes and client branding. The count includes every color in every theme. Radiant also supports right-to-left languages. It scaled across several of GEP’s software platforms, with a semantic layer on top that made it more complex to build and more powerful to use.

At least 80% of the component types used across GEP’s products were covered. About 20% were still to build.

How a component earns its place

Any product manager or designer could ask for a new component. We reviewed requests in a monthly cycle, spending about two days on them.

1. The designer first asks whether the request is a one-off. If it is, they finish it in Figma and it stays out of the system.
2. If it is not a one-off, they fill out a short form. The form captures the problem, not the solution. It sets the scope early and keeps product-specific requests from cluttering the core system.
3. The designer builds the design from a shared Figma template.
4. The design system team reviews it. We add it, mark it as a duplicate of something that exists, or reject it with feedback.
5. For anything we add, UX and product management have to agree before it enters the system.

Getting teams on board

I worked with about 16 product teams, each with at least six developers. I did not direct them. Leadership did. The VP of development required the teams to use Radiant, and design leadership required the same of the designers.

My part was making it easy to say yes. We started with a pilot team. The developer manager and I ran training sessions on how to use the system. We also worked with our teams in Romania and India so everyone knew where to find components and designs. Design reviews included me, another manager and the senior director of UX.

Designers spend their days in Figma, so finding the right control was hard at first. We showed them that looking things up in the documentation was faster, and that each entry linked straight to the right Figma file. That also let us retire the old Figma libraries that had been around since day one.

Accessibility built in

Once Radiant existed, we could check it against WCAG. That is where my accessibility lifecycle began, and I wrote about it in Making accessibility the default.

Developers wrote their own unit tests. GEP did not have a dedicated testing team, so my team did the final accessibility and UI review. My WCAG testers also checked that teams were using the design system fully. Later I added AI and Playwright to the checks, and a developer who loved automation built accessibility tests into the build process.

Three components I am proud of

The accordion. Clients needed to collect a lot of information from their customers, like a long survey. The accordion broke those processes into short sections that people could work through one at a time.

The map. It showed risks in the production process that could affect a client’s procurement flow. Below it, a table gave the same information in text. I pushed the team to build the map on canvas, the way we did at FamilySearch. They chose Highcharts for nearly all graphs and visuals, so I made sure the table was always there.

Bar charts over pie and donut charts. Research, including Cleveland and McGill’s 1984 study, shows people judge length more accurately than angles or areas. I first learned this from Stephen Few’s Information Dashboard Design, which I ran as a book club for my team at Ivanti. Marketing liked pie and donut charts, so we did not remove them. Instead, we made sure a bar chart and a table were always available as another view. I also think bar charts are more accessible than pie charts.

What changed

Design reviews got calmer, and product and development agreed faster. I measured progress in Power BI, comparing commits, reported bugs, development time and design system use before full adoption and again at the end of 2025. That comparison showed a 56% improvement. Developers also told us they were seeing about 20% quicker turnaround. The documentation platform reported about 2,300 page views a month.

What I would do differently

I would argue harder for a dedicated testing team. Our developers tested their own work and my team did the final accessibility and UI review, but full feature testing was missing, and bugs got through.

I would also choose the documentation platform differently. The one we used connected well to Storybook and Playwright, and its reporting beat the tool we built in house. But it made us jump through hoops. Next time my requirements would be strong reporting, accessibility checks in the build, and a tool designers find simple to use.

Building or fixing a design system?

hire.daveb@startide.net · LinkedIn · Back to design systems work