Wave Matrix
Simplifying the Matrix Configuration Flow
From confusion to clarity, driving a 16% lift in sales
Scroll to explore ↓
My Role
Sr. Product Designer
Responsibilities
Defined the problem with PM and stakeholders, led research, validated feasibility and priorities early, and contributed to sprint planning.
Duration
6 Weeks
Collaborate
This wasn’t a design-only problem. so I collaborated closely with Product team(1 VP of Product, 1 Project Manager, 2 Junior Designer), Engineering team(1 Technical Lead, 3 Developers), Support team(1 Support Manager & 1 Support engineer), Sales team(1 Sales Manager & 4 Account Executives), and Customer Success team(1 CS Manager) because Matrix directly affected demos, onboarding, and ongoing usage.
About Matrix
Valorx Wave is a Salesforce analytics product used mostly by the people like CPQ specialists, analysts, and forecasting teams. They deal with a lot of structured data every single day. One of the most important features in Wave is called Matrix. You can think of it like a pivot table for Salesforce data. This is where users compare numbers, spot patterns, and make decisions for their business.
Problem
Users were dropping off early while setting up the Matrix, and many left midway and restarted, which usually indicated they were stuck or confused in configuration part.
How it all started
Why We Looked Into This
While we were getting ready for the next Wave release, we started by checking our analytics dashboard.
And one thing stood out immediately which is Around 40% of users were dropping off within the first two or three minutes of setting up Matrix. Another 28% were leaving halfway and restarting — which usually means they were stuck in configuration part of matrix.
User Problems → Business Impact
Matrix’s complexity made it harder for sales to close deals, resulting in an 8–10% drop in license upgrades and upsell opportunities, and longer onboarding cycles
So we started to talk with teams who interact with users every day. So every team felt the pain, just in different ways.
Support team
told us they received 182 Matrix-related tickets in last three months.
Sales team
shared that in 7 out of 12 demos, prospects disengaged during setup and sometimes AEs skipped Matrix entirely.
Customer Success team
added that Matrix onboarding consistently took longer and needed multiple follow‑ups.
So we focused on goal that Grow Matrix revenue by 10% in Q3 by improving sales conversion and expansion through higher license upgrades and upsells.
Business Objective
Increase Matrix adoption by improving configuration clarity, reducing setup friction, and helping customers realize value faster during implementation.
Executive Intent
Stakeholder Envision
Since Matrix was directly impacting demos, onboarding, and expansion opportunities, stakeholders aligned on the need to redesign the configuration experience.
The expectation was not just to improve usability, but to:
help users complete setup without friction
improve first-time success during demos and onboarding
increase confidence while configuring Matrix
ultimately support better sales conversion and license expansion
Strategic Priorities Defined with Leadership
Through early discussions with Product, Sales, Support, and Customer Success teams, we aligned on key focus areas:
◍ Improve successful completion of Matrix configuration
◍ Reduce user hesitation and restart behavior during setup
◍ Support clearer understanding while making configuration decisions
◍ Avoid adding additional complexity to existing workflows
Clarifying What Success Looks Like
Before starting redesign, stakeholders aligned on what success should look like:
◍ More users completing Matrix setup without abandoning
◍ Reduced restart patterns during configuration
◍ Faster progress during demos and onboarding sessions
◍ Increased confidence while making setup decisions
Success Metrics
These success signals were translated into measurable indicators:
● Configuration completion rate
● Setup restart frequency
● Time taken to configure Matrix during demos
● Support dependency during setup
● License upgrade and expansion signals linked to Matrix usage
Alignment Outcome
Across teams, one thing became clear:
The problem was not fully understood yet.
While multiple teams experienced friction during Matrix setup, there was no clear visibility into:
where users were getting stuck
why they were restarting
which decisions caused hesitation
This created alignment that the redesign should first focus on understanding the problem deeply before defining solutions.
Strategy
Design Strategy
Since Matrix was an existing feature with visible business impact, the project started with high ambiguity.
Before moving into solutions, I defined a design strategy to:
Align stakeholders on
what we don’t know
To structure how we
investigate the problem
Identify where design
could create impact
Key unanswered questions included:
Through early discussions with Product, Sales, Support, and Customer Success teams, we aligned on key focus areas:
◍ Where should the Matrix redesign create the most impact to support revenue growth through adoption and expansion?
◍ Which and what assumptions about configuration complexity and hesitation required validation?
◍ How should design contribute to improving Matrix activation during demos, onboarding, and early configuration usage?
◍ What knowledge gaps needed to be resolved before making configuration changes?
Current Matrix Configuration Screen
Observable User Struggles (Initial Assumptions)
At this point, before doing any formal research, we sat together as a design team with stakeholders and simply walked through the screens. Based on that, we formed some early assumptions about what might be going wrong.
Interface felt dense and overwhelming
Lack of clear visual hierarchy
Unclear structure and navigation
The screen felt crowded, with preview and configuration shown together, which may create conflicting focus. It wasn’t clear whether users should focus on configuration or preview first, and the high volume of inputs and live updates may lead to cognitive overload.
Strategy Hypothesis
Based on stakeholder discussions and initial assumptions, we framed working hypotheses:
◍ Users may be struggling due to unclear configuration structure
◍ Users may hesitate because they cannot predict outcomes of their inputs
◍ Users may restart because they lack confidence in their decisions
◍ Configuration complexity may be perceived rather than purely technical
These hypotheses guided what needed to be validated through research.
Capability Direction (Exploration Scope Defined with Stakeholders)
Before research, we aligned on key areas to investigate.
• How users understand and approach configuration steps
• How users make decisions during setup
• How users interpret system response while configuring
Constraints Considered Early
o ensure feasibility and adoption, a few constraints were identified:
• Matrix supports complex, flexible data configurations
• Users include both new and experienced personas
Knowledge Gaps Identified
Stakeholder Knowledge Gaps
◍ Didn’t have knowledge of how this problem impacted other teams.
◍ Didn’t know what priority level this issue had for their teams.
◍ Didn’t know how Matrix performed within their teams.
User Knowledge Gaps
◍ How users approach Matrix configuration for the first time
◍ How they decide what to configure first
◍ What makes them feel confident or uncertain during setup
Product Knowledge Gaps
◍ Which configuration steps contribute most to abandonment
◍ Where users spend the most time or effort
◍ What triggers restart behavior during setup
◍ How configuration behavior impacts activation and usage
Strategy Execution Plan
To reduce uncertainty before defining experience directions, I structured a staged investigation plan. Each phase was designed to answer specific knowledge gaps identified during stakeholder alignment and early walkthrough assumptions.
Phase 1 — Configuration Journey Understanding
Goal
Build a shared understanding of how users currently move through Matrix configuration and where hesitation or breakdown may occur during setup.
Approach
Use early stakeholder walkthrough observations and available behavioral signals to map the configuration journey and identify potential friction zones that require deeper investigation.
Why this phase matters
Before identifying causes, the team first needed visibility into where configuration challenges may be happening across the setup flow.
Phase 2 — Cross-Team Experience Signal Alignment
Goal
Understand how different teams experience Matrix configuration challenges.
Approach
Synthesize signals from teams interacting with users throughout the Matrix lifecycle to identify recurring patterns and align on priority investigation areas.
Why this phase matters
Different teams observe different moments of friction. Aligning these perspectives helps determine which parts of the experience require closer validation.
Phase 3 — Assumption Validation Planning
Goal
Validate whether early assumptions about configuration clarity, decision confidence, and setup structure are contributing to configuration difficulty.
Approach
Plan targeted validation activities to test configuration-stage by usability testing
Why this phase matters
This phase ensures that redesign directions are based on validated understanding rather than initial walkthrough assumptions.
Research insights
Finding What Was Really Breaking
Following the signals to uncover what was truly causing friction.
The Question That Triggered Research
At this point, the numbers were clear — but the reason behind them wasn’t. So the real question became
Was Matrix actually too technical for users?
Was the product asking users to make configuration choices without clearly showing what would happen next?
We studied both qualitative and quantitative data using the SPEAR framework.
Ticket analysis and internal
interviews
I decided to work with internal teams to gather data on Matrix. By combining support ticket analysis and internal interviews, we aimed to understand exactly where the experience was breaking down and what's going related to matrix in different teams. Here’s what we found:
What the study revealed
Once we synthesized users interview feedback, into codes and themes, and three themes kept coming up again and again.
Key themes
No Confidence & Decision Assurance
Cause–Effect Visibility
Cognitive Load Management
Theme → Behavior Mapping
Low confidence → frequent restarts & external help
Poor cause–effect visibility → trial and error configurations
High cognitive load → slower completion & abandonment
Root Cause Identified
Matrix combined too many decisions at once, provided too little feedback, and offered no clear sense of progress, forcing users to guess outcomes instead of confirming them.
How others reduce configuration friction
I wanted to see how other configuration-heavy products handle this better.
Key Learnings
Insights that stood out out was that they guide users step by step, ask for structure before data, and let users validate their setup before showing results. These patterns directly addressed the same issues we were seeing in Matrix
Concept Sketch's
From insights to ideas
Using above insights, explored multiple layout directions with the design team. Our goal was to clarify the structure, provide feedback only when useful, and build user confidence step by step. We aligned with PMs on this direction before moving into detailed design — the reasoning becomes clear in the UI solution below.
Design
Building confidence through guided setup
Users weren’t sure if they were doing things right, which led to hesitation and drop-offs. To address this, we introduced a guided step-by-step setup (layout, settings, filters), grouping related decisions into clear steps. Progress indicators and check icons showed what was completed and what comes next, making the setup feel simpler and more manageable.
Testing & Validation
what didn’t work.
We tested the new flow with both first‑time and experienced Matrix users. Overall, users moved faster and felt more confident. But testing also showed gaps — especially around understanding which objects controlled which axis, and how filters were applied
Disconnected Object → Table Relationship
Couldn't quickly understand which object influenced which axis and confusion Between X-axis & Y-axis.
Lack of Visibility for Applied Filters
Wanted upfront clarity on how many filters were active.
Inconvenient Filter Management
Switching filter scopes took too many steps.
Final changes
Clear axis mapping
During testing, users struggled to tell which object controlled which axis and often confused the X and Y axes. To fix this, we assigned each object a distinct color and matched it in the table, along with clear axis labels. This made relationships instantly clear and reduced confusion.
Before
After
One-click active filter control
Users lacked visibility into active filters, and switching scopes took too many steps, breaking their flow. We fixed this by showing active filter counts upfront and enabling one-click switching between X and Y filters with a wizard-style setup, keeping the workflow smooth.
Before
After
Impact
In the end, setup time dropped by about 30%, successful configurations increased from 60 to 72%, which helped more
users reach value faster and support dependency went down. More importantly
we saw a 16% improvement in Matrix-related sales, along with fewer support requests and higher successful configurations.
Before
After
