RoadRunner Design System
RoadRunner is a 3D simulation tool for autonomous vehicles. I built a comprehensive design system made it consistent with other tools in its product ecosystem while improving its accessibility and usability.
Shipped
Contributions:
Visual Design Audit
Scalable, Accessible Design System
The Team:
1 x UX Designer (myself)
1 x Project Lead
2 x Software Engineers
1 x Technical Writer
Timeline:
8 weeks over
2 Development cycles
Industry:
Automotive
Autonomous Systems
RoadRunner is a tool used by engineers to simulate road environments to build and test autonomous vehicles.
The Problem
As a newly acquired product, RoadRunner didn’t align with the MathWorks ecosystem, leading to inconsistencies that disrupted the user experience.
It also suffered from accessibility and discoverability issues, making it challenging for new users to navigate and find key features.
The Outcome
Established a comprehensive design system that aligned RoadRunner with MathWorks' product ecosystem, reducing development time by 25% through component reuse.
Improved interaction usability and accessibility, resulting in a 73% increase in WCAG 2.2 AA compliance and a 30% improvement in task completion rates.
Phase 1: Menus, Widgets and Tool Bars
(Shipped in 2023)
To manage the scope of the project, I divided the redesign into two phases. In phase one, I improved the readability of elements that use static user inputs (like text fields and buttons) as well as other widgets in the Control Panel.
Before and After the Redesign of the Tool Bars and Widgets
Phase 2: Interactions on the 3D Canvas
In phase two, I created an atomic design system that modelled user's interactions in the 3D Canvas. There were three main types of interaction controls, and three ways to control them.
Atoms = Points
Defined as individual route points, serving as the fundamental building blocks of the system.
Molecules = Spans
Road spans created by connecting multiple route points, forming functional units.
Organisms = Routes
Complete routes, composed of road points, spans and curves, offering a full structure for road mapping.
The redesign improved consistency across the different tools while providing more clarity of information.
I differentiated the canvas controls by varying shape, size and color, making sure to establish recognizable patterns for consistency across the product ecosystem.
Visibility against all backgrounds
I implemented annotations and tooltips with transparent dark backgrounds to ensure readability against any surface.
See overlapping points clearly
Users typically hover over points to inspect them for selection. Closest overlapping points are shown in a different color and size than the active point.
Differentiating Active and Disabled States
Shape: Unique forms for each control, allowing for faster recognition.
Size: To emphasize visual hierarchy and provide feedback.
Opacity: Higher opacity pulls important points forward, making them stand out from the background. Lower opacity allows less relevant points to recede, reducing visual clutter.
Static vs. Dynamic
Dotted lines are used to denote labels and indicators to provide users with clear visual cues about which elements are informational vs. actionable.
73% improvement in WCAG 2.2 AA Compliance
The text and labels were difficult to read in the selected and focused states, failing WCAG 2.2 AA Standards. To fix this, I applied dark mode accessibility best practices throughout the UI to enhance readability at all states.
BEFORE
73% of patterns failed WCAG Standards
In usability testing, we noticed users would click around, selecting and deselecting to read the labels.
AFTER
Accessibility optimized
All states – Selected, Hover, In-Focus and Disabled – now optimized for accessibility and clarity.
Clear information hierarchy leading to 30% increase in task completion
New users struggled to learn interaction patterns, relying on help text that was difficult to access in the workspace.
Moving tool instructions and error messages closer to the workspace led to better information hierarchy leading to a 30% improvement in task completion and significantly enhancing user comprehension and focus during usability testing.
BEFORE
Discoverability issues
"Status bar? What status bar?"
A bright yellow bar at the bottom displayed all instructional information with no differentiation, causing users to miss critical details while the brightness distracted from the main canvas.
AFTER
Clearer information hierarchy
"Oh, I see what to do now!"
Tool information now appears in a subtle blue status bar at the top, with warnings and errors highlighted in yellow using distinct icons, improving focus and comprehension.
Mapping a Design System
My Process
One of my biggest challenges was the size and scope of the project.
Over 55 tools with inconsistent behavior makes it difficult to apply uniform patterns. The visual design had to balance standardization and flexibility so that new users can understand and adapt to each tool.
RoadRunner Toolbar with 55 tools
I collaborated with product leads to map the product’s features and prioritize changes carefully, ensuring users wouldn’t experience abrupt shifts in functionality.
Managing scope also influenced my approach to research and design; I needed a clear starting point and a method to keep my research organized.
I began the research by mining customer data for known pain points, but this data didn’t cover all product areas or provide detailed insights into user goals.
RoadRunner users are engineers who typically follow an unstructured non-linear workflows with broad goals. This makes it difficult to pinpoint exactly which workflows users may face difficulty.
Customer-Support Tickets
Mined data from technical support tickets, especially cases where users were unable to discover functionality
Interviews with Sales
Interviewed Customer-Facing Engineers who meet customers on a regular basis
Usability testing
Conducted internal usability tests with engineers, new-Hires, and interns
Initially, I assumed I would need to conduct a full design audit, but I quickly hit a roadblock: the project’s huge scope.
My plan at the start was to document each inconsistency in color use across all 55 tools in Miro. This turned out to be a misstep because:
I attempted the audit solo, when expert knowledge was needed to understand each tool.
The interactions I documented where too detailed, when the solution needed a high-level view
It was painstakingly slow
I pivoted to a "Bug-Bash" approach so that my team could help identify the most pressing usability issues.
I needed to pivot and fast, because I was running out of time in which I could finish the research and get started on ideation and prototyping.
Doing it in a bash meant that everyone from interns to experts added their learned wisdom to my research, making the experience feel like a high-energy hackathon.
I went from solo struggle to team triumph and leadership buy-in.
Since everyone on the team was involved with bug-finding it helped get buy-in from leadership on the extent of the problem and work needed to address these pains.
It also allowed for a breadth and depth of research across all the tools that I never would have achieved if I had worked on it alone.
Lesson learned!
For the bug bash, I designed tasks based on users’ typical workflows, creating a logical mental model around common interaction patterns like building, selecting, and modifying roads.
I worked with a researcher to conduct contextual Inquiry with 2-3 participants to discover user workflows.
We learnt that users take looping, unstructured workflows to achieve the result the want, like building a road network. The iteratively create, adjust and modify as go. This makes it challenging to create a generalized workflow so I mapped out each workflow separately by goal.
Example user flow, documenting mouse-clicks and control-points of curve-editing type tools
I tailored the visual design to support users' goals at each stage, using size, opacity, and shape—not just color—to differentiate elements.
Below is an example these design decisions in action. These acted as the justifying principle behind the color use.
On Hover
User Goal:
User inspects the road span by hovering
User Need:
Clearly identify a modifiable road
Design Decision:
Visibility: Target is at full-opacity against background
Feedback: Target size increases in response
Clarity: Increase in target size so that its clear which span has been selected.
User Goal:
Users selecte a road to be modified. They need to have an overview of the whole scene to adjust the span location.
User Need:
Distinguish between selected and unselected points
Design Decision:
Visibility: The line should not obscure the scene, but it should be clear that it is active
Feedback: Target size decreases to default size, border and fill invert
Clarity: Decrease in target size so that the whole scene is clear
I also aligned with MathWorks’ brand colors and patterns, introducing new patterns where necessary.
Blue, used for primary interactions like selection was used because of clear associations to established interaction patterns in MathWorks' other platforms.
Purple and Green were new additions to the visual vocabulary, and chosen to depict lesser-used interaction patterns.
This left Red, Orange and Yellow to be reserved for warning and error colors, matching real-world applications of there colors.
Throughout the process, I prototyped and documented my work simultaneously.
This allowed me to review progress with accessibility experts, developers, and other designers across the organization who would use these components.
Prototyping in Figma
I started prototyping the components in Figma. This worked well for standard components like buttons, checkboxes, and text, but failed when it came to complex interactions like creating or selecting road spans.
Testing contrast ratios in Figma
I started looking for alternatives to Figma to prototype these interactions, but fell short.
In the meantime, I leveraged Figma plugins like Stark to test for contrast ratios, ensuring we met WCAG 2.2 AA Accessibility standards for graphics (3:1 Ratio). While this helped with the visual aspects, the interactive elements remained a challenge.
Creating a Sandbox for testing reduced Figma prototyping time by an entire week.
I needed a more flexible tool that would help me prototype rapidly, so I reached out to our development team for help.
They helped me create a sandbox environment that allowed me to directly test complex interactions in real-time though simple CSS style changes, using a mirror of the actual codebase of Roadrunner.
This helped me:
Accurately simulate complex road span interactions with the exact colors and sizes used
Test and refine user flows in a realistic environment with grass, trees, and vehicles.
Our new approach was much faster and more importantly, it provided a more accurate representation of the final product, allowing for better design decisions and smoother implementation.
I documented the reasoning behind each design choice, created reusable components and styles in Figma, and built a sandbox version of the product to test the coded design changes directly.
I iteratively improved the documentation based on developer feedback. It includes reusable Figma components organized by user goals, with mock-ups demonstrating how the components behave and why.
In the final weeks of the project, I opened up the RoadRunner component library to other designers to pilot so that any bugs or implementation issues could be sorted out.
This is the largest project I've taken on in both size and impact.
I learned to involve experts early, keep stakeholders updated, and share challenges openly.
This approach prevented bottlenecks and fostered a supportive team environment.
Less documentation, more co-creation
Instead of working solo to create lengthy documentation, I co-wrote design documentation with developers prioritizing the information they would need to reference in their work.
This collaborative approach reduced the effort to understand and implement the designs.
Choose the right prototype fidelity
My experience partnering with developers to create a sandbox environment highlighted the value of cross-functional collaboration and thinking outside the traditional design tool box.
It bridged the gap between design and development early in the process, and we not only saved development time but also created a more accurate solution.