top of page
Screenshot 2026-01-12 173916.png

 BLUE PRISM 

 Design System:
 Hyperspace

Establishing consistency, accessibility, and governance across an enterprise RPA platform

SCROLL FOR MORE

I joined Blue Prism when the UX function was at its most formative, and our nascent design system was just beginning. 

As the team and product grew, so did the pressures on our design system. Here's how, as a lead, I scaled our processes and velocity to meet product demands.

Introduction

Role: Lead UX Designer
Scope: Entreprise SaaS, RPA Platform
Users: Internal product teams and end users
Scale: 12+ products across web and mobile

Challenges

There were a number of challenges motivating us to create a design system...

​

  • Blue Prism was actively moving from a 20+ y/o legacy desktop system to a web application

  • Rapid product portfolio expansion had left design inconsistent and implementations disparate

  • Accessibility risks meant clients turning rejecting Blue Prism, and even fialing to renew contract

 

In response we needed something agile and responsive, that could fulfill the demands of existing systems while reacting to the needs of new products.

 Why our own design system? 

With so many design systems readily availble out of the box, why did we feel it best to build our own?

​

Proprietary control

As a complex product ecosystem, Blue Prism couldn't risk investing in a system that may be out of our control, force us to update outside of our established cycle, or lose support altogether.

​

Building for complexity

Similarly, the needs of our product meant that no one system would provide everything we needed. We would have to use multiple systems together, supporting them individually and enusring they were compatible.

​

A product in its own right

We approached our design system as a product in its own right, with the same approach to design and development. Hypothetically, Hyperspace could become part of Blue Prism's wider portfolio.

Approach

I began my time at Blue Prism as a UX Designer and Researcher, contributing from the very beginning. After a short time, I became the Lead UX Designer and shared ownership of design system vision with other leads across the design and development team.

​

I was responsible for:

  • Alignment across design, engineering, and product

  • Ensuring consistency within design system, documentation, and principles

  • Establishing patterns that could scale across all products

 Our design principles 

In addition to our design principles, we needed:

  • Consistent design language across all touchpoints

  • Collaborative building of components across our matrix UX teams

  • Documentation that enababled shared taxonomy

  • Accessibility built into every component from the ground up

 Our process 

Standard_Process 2.png

Our process map covered our design and research funcitons, as well as UI, QA, POs, and developers.

​

Identifying needs

Generative research, telemetry, and community ideas fed into our iterative research to identify pain-points and opportunities that required new components. These were prioritised according to the business roadmap.

​

Designing and building components

Generative research fed into low-fidelity designs that were then evaluated with users. These were iterated into high fidelity designs and handed to UI development to be built into react components in the design system.​

​

Integrating into sprint

Sprint teams were always informed when components were available, and were able to bring them into production environments. UX reviews would ensure components were implemented correctly.

bottom of page