A
Work / CPQ research-led
Contact
100% ▾
PAGES
Home Work / CPQ About
CASE STUDIES
Disputes Workspace 360 Control CPQ Design System
SECTIONS
00 · Cover
01 · Overview
02 · My Role
03 · The Problem
04 · Research
05 · System First
06 · The Solution
07 · Impact
08 · Learnings
PROJECT
CPQ · Configure, Price, Quote
clientZywave
roleUX Designer
usersBrokers + ops
domainInsurance quoting
OUTCOMES
18 → 10 min
avg. time per quote
↓ training costs
faster broker onboarding
↑ adoption
platform usage increased
UP NEXT
Disputes Workspace →
AI-assisted dispute management
◇ 00 · Cover
CASE STUDY 03 · ZYWAVE

CPQ: untangling an enterprise quoting platform, one finding at a time

CPQ (Configure, Price, Quote) tools exist to simplify complex quoting for sales and operations teams. But when the product itself becomes the obstacle, the whole point falls apart. This is a research-led redesign of Zywave's enterprise quoting platform, measured against success metrics we defined before design started.

CPQ, improving the user experience of a fintech product
◇ 01 · Overview

Project overview

The product

The platform had been in use for years, and it showed. Features had been added over time without a consistent design direction, workflows required too many steps, and users had learned to work around the system rather than with it. Brokers and ops staff were spending more time navigating the tool than working their cases.

The challenge

Errors were common, onboarding took weeks, and support tickets kept piling up about things that should have been obvious from the interface. Experienced users had built so many workarounds, spreadsheets, sticky notes, that the actual inefficiency had become invisible. The product needed a rethink, not a visual refresh.

GOALS · DEFINED BEFORE DESIGN STARTED

Map where users actually got stuck and why · reduce the steps to complete a standard quote · make patterns learned in one area carry to another · cut onboarding time · give visibility into quote status and pending actions · reduce navigation-related support volume.

◇ 02 · My Role

My role

I was the only designer on this product. In our team, each designer owned one project end to end, so I was responsible for every part of the design process, while weekly design critiques kept the quality honest and the thinking sharp.

I worked directly with the product owner from day one, attending roadmap sessions and translating business requirements into design briefs the team could act on. Research ran the same way: I ran the interviews and contextual inquiry sessions myself, and brought findings back to critique for interrogation.

User research & synthesis Requirements partnership Design system from scratch End-to-end screen design Weekly critique
◇ 03 · The Problem

The problem

Years of feature additions with no consistent design language meant brokers spent more time navigating than quoting. Key details were buried in unexpected places, error states were confusing, and the interface punished new users hardest.

PAIN 01

Information buried, clicks everywhere

Brokers hunted for basic quote information that should have been immediately visible. A standard quote took a minimum of 12 clicks.

PAIN 02

Pricing errors at scale

Complex commission structures and unclear validation led to systematic mistakes, quietly eroding trust in every number the system produced.

PAIN 03

No duplication, so spreadsheets

The system had no way to duplicate or version a quote, so brokers tracked variations in external spreadsheets instead.

PAIN 04

A brutal learning curve

New brokers needed 2–3 weeks to get productive because the interface followed no predictable patterns, every screen its own little system.

◇ 04 · Research

Research first, with real users this time

Unlike pure stakeholder-constrained projects, here I had direct access to users, and used it. Spending real time with brokers before touching the UI prevented assumptions from driving decisions. Several things we thought were problems turned out not to be; the real blockers were hiding elsewhere.

1:1
Interviews + contextual inquiry
Shadowed brokers and ops staff working real quotes in their real environment.
6 mo
Analytics review
Six months of platform usage data to find patterns users couldn't self-report.
7
Stakeholder workshops
Aligning the product owner and sales team on priorities and success metrics.

The findings that set the agenda

82%

of brokers used external spreadsheets to track quote variations, because the system had no duplication feature.

12 / 18

clicks minimum and 18 minutes on average to generate a single quote.

28%

of quotes contained pricing errors, traced to unclear commission logic and weak validation.

2–3 wk

for a new broker to reach productivity, the cost of an interface with no shared patterns.

◇ 05 · System First

A design system from absolute zero

Before any screen design started, the product had no design system at all: colors hardcoded, components built independently on each screen, no shared language between design and engineering. I built one from scratch, reusable components, semantic color, spacing and type scales, before redesigning a single workflow.

The investment paid for itself: consistency made patterns transferable for users, development moved faster against a shared vocabulary, and the system became the foundation engineering still builds new features on.

Early concept sketches, selection and wizard patterns
early concept sketches, selection & wizard patterns explored on paper before any hi-fi work
◇ 06 · The Solution

The solution

The redesign focused on reducing unnecessary complexity, making the most important information visible without clicking, and creating a consistent experience new users could pick up quickly, while keeping core workflows recognizable for the long-time users who'd built habits around them.

S·01

Quote duplication: the #1 request, finally

Brokers can duplicate any quote and create variations in seconds, killing the spreadsheet workaround used by 82% of them.

S·02

Key information surfaced, not buried

Quote status, pending actions, and pricing details visible at a glance, the data brokers hunted for now leads the layout.

S·03

Validation that explains itself

Clear commission logic and inline validation attack the 28% pricing-error rate at its source, instead of letting errors surface downstream.

S·04

Responsive, because deals happen everywhere

A fully responsive interface lets brokers review and modify quotes on tablets and mobile, not just at their desks.

CPQ quotes workspace, duplicate a quote from the actions menu
the quotes workspace, recent quotes surfaced up front, duplicate available straight from the actions menu
◇ 07 · Impact

Impact

18 → 10 min
Average time per quote
A 44% reduction in the platform's core task.
↓ costs
Training & support
Consistent patterns cut onboarding time and navigation-related tickets.
↑ adoption
Platform usage
Workarounds retired; the design system became engineering's foundation for new features.

"Finally! Quote duplication was our #1 request. Now I can create variations for clients in seconds instead of starting from scratch."

— SENIOR ACCOUNT MANAGER
◇ 08 · Learnings

Learnings

Let research redirect you

Some of the most important findings came from things we weren't specifically looking for. Several assumed problems weren't problems at all.

Critique keeps quality honest

Bringing work-in-progress to the team weekly meant other designers caught what I was too close to see, and pushed the work further.

Define metrics before designing

Success criteria set up front kept the team focused on whether things were actually improving, not just whether the new design looked better.

Balance familiarity with improvement

Long-time users had habits. We kept core workflows recognizable while modernizing the patterns around them.

What I'd do differently

01

Involve engineering earlier. A few screens needed rework when technical constraints surfaced later than they should have. I adjusted the process mid-project to include engineering from the design phase.

02

Keep better decision logs. More thorough design documentation would have helped onboard future team members and made the reasoning behind choices easier to revisit.

03

Plan a phased rollout from the start. Launching everything at once was risky; a staged rollout would have let the team learn from real usage and iterate faster.

NEXT CASE STUDY
Disputes Workspace: AI-assisted dispute management
© 2026 Abhikant Nirbhavane case study · cpq