From Friction to Flow: Redesigning the Customer Configurator for Clarity and Completion
My Role: Product Designer, Design Operations, QA Lead
Team: 2 Backend Developers, 2 Full-Stack Developers, 1 Software Intern, Junior Designer, and myself
Duration: 4 Months (September-December 2024)
The Challenge
The old configurator caused major friction—inconsistent feedback, unclear dependencies, and outdated visuals.
Our Goal
Modernize the interface, fix usability gaps, and align the tool with our new design system to create a smoother, more confident self-service experience.
Research & Key Findings
I led the discovery phase by surveying 3 senior sales engineers and 3 active configurator users to compile a prioritized list of usability issues and requested features. I supplemented this feedback with user testing sessions and heat map analysis, which revealed both friction points and underutilized opportunities.
Issues Uncovered:
Confusing part dependencies + vague error messages
Missing validation feedback and unclear visual guidance
Accessibility issues from low contrast
Outdated styling that broke brand consistency
Video showcasing the old configurator and user interactions
My Role
I led the design phase, guiding the process from research to final prototypes. I shared user testing and heatmap insights with cross-functional stakeholders to inform decisions. Along the way, I mentored a junior designer in Figma and coordinated with our software intern to review and approve components in Storybook, while I focused on UI refinements and exploring new technical features.
Page Structure, Visual Hierarchy & Branding
Through research, I shaped the final page structure to: Keep what worked, clarify quantities (fixed-quantity vs variable-quantity components), and improve accessibility
Clarified quantity selection (fixed vs variable)
Increased contrast, replaced teal with brand blue
Clearer category headers and grouping
Components rebuilt using our design system for long-term scalability
Keep what worked: Preserved the familiar part-selection flow—testing and heatmaps showed minimal friction with the existing layout.
"The updated colors feel much easier to read. I’m glad we’re moving in this direction"
- Sales Engineer at Exxact Corporation
Interaction Enhancements
Added visual cues showing disabled state until prerequisites are met. Users are not allowed to select a software package unless an OS is selected.

Interaction: Selecting “no thanks” in the OS category parts will showcase parts under the software category in it’s disabled state until an OS is selected
Feedback Improvements
Added loading states for perceived speed, reducing user uncertainty during longer loading
Animation replay when submitting configurations with errors
Error Handling
Improved error messages to clearly explain the issue and guide users toward solutions.
Old Error Message
New Error Message
Before and after of the old error message and new error message
GPU NVLink Support
Collaborated with sales engineers and developers to design new logic and messaging for GPU NVLink compatibility
Added contextual notes and icons to clarify which GPUs support NVLink, how many are required, and when selections are incompatible without interrupting users with error states.
QA
As QA Lead, I ran a month-long internal testing cycle. By creating a comprehensive checklist covering all edge cases, I identified, documented and resolved 15 critical bugs—covering data syncs, calculation logic, and spec formatting with engineers.
| Bug Name | Issue | Solution |
|---|---|---|
| Input validation issues in the contact form | Able to input phone numbers in the "system quantity" field due to its proximity to the phone number field | Implemented dropdown selection limited to numbers 1-10 |
| Category ordering inconsistencies between the configurator and emails | GPU category ordering in emails differed from the configurator interface | Standardized ordering across all customer touchpoints |
| Configuration Data Persistence | Platform and parts information not updating correctly in customer emails | Fixed data passing between configurator and email generation system |
| Memory calculation errors | Total memory calculations were hard-coded and not updating correctly | Implemented dynamic calculations based on actual component selection |
| Product listing display problems | Product listing order inconsistency between builder and final display | Synchronized ordering logic across the entire configuration flow |
| Technical specification formatting issues | - Memory totals displayed even when "No Thanks" option was selected - Incorrect Watts and BTU/Hr specifications in PDFs and emails - Memory dropdown quantities not reflecting minimum configuration requirements | - Modified logic to only display totals for actual component selections - Implemented precise calculation and formatting for power specifications - Implemented dynamic dropdown adjustments based on system requirements |
| Configurator and site sync issues | Configure buttons appearing incorrectly on the website due to partial MPN matches | Implemented exact MPN matching to ensure proper button display |
Results & Impact
Comparing pre- vs post-launch metrics (1 month window):
+22% successful completions
–18% support tickets
–23% engineering time spent clarifying orders
Project Reflection Metrics
A quick look at how this project felt—measured by challenge, teamwork, and personal sanity.

What I learned
Research
Invest Upfront to Reduce Debt
Past quick fixes led to integration issues. Thorough research upfront keeps the system healthy and reduces downstream complexity.
System Simplicity
Prioritize Maintainability
Simplifying component behavior and reducing assumptions created a more scalable design system.
Collaboration
Align Early and Often
Staying closely synced with engineering and QA improved technical decisions and surfaced constraints earlier.
Quality Assurance
Clarify Testing Protocols
Hardware-based edge cases highlighted the need for clearer documentation and a better split between automated and manual QA paths.
Workflow
Build Logic First, UI Second
Earlier in the project, several components broke during integration because they were built with hard-coded text or without real data context







