Customer Success Score
Categories
Design Library
Dashboard Design
Date
Client
Salesforce
The Stakes: Trust and Speed
Customer Success Score is an engagement tool used by Salesforce clients to evaluate how effectively they are using their products. Teams rely on the score to assess adoption and decide where to focus their efforts, which makes trust and transparency critical.
The product followed a quarterly release cadence with limited margin for rework. Internally, the design workflow depended on a component library that had accumulated inconsistencies over time, directly affecting handoff quality and delivery predictability.
Opaque Data & Systemic Debt
Despite its importance, many users reported that they did not understand how the score was calculated. This uncertainty reduced trust and made it harder for teams to confidently act on the data.
At the same time, the internal component library structure allowed outdated components to propagate into new releases. Each quarter introduced additional inconsistencies, increasing QA friction and slowing delivery. The team was spending time correcting legacy issues instead of refining the core experience.
The Velocity vs. Quality Trap
There was a clear tension between maintaining quarterly release velocity and rebuilding trust in a score that users relied on for decision-making. Improving transparency required thoughtful iteration, but the delivery system itself was introducing friction every cycle.
Architecting a Better Foundation
As the main product designer, I led the restructuring of the component library to stabilize the delivery foundation. I redesigned how components were structured, versioned, and documented to prevent outdated patterns from recurring across releases.
While my design lead owned final stakeholder approvals, I heavily influenced decisions around improving score transparency. We used unmoderated user testing to validate how users interpreted the score and to guide the treatment of explanatory content.
Solving for Systems, Not Symptoms
I implemented a new versioning workflow and structural logic for the component library. Instead of patching inconsistencies file by file, I addressed the systemic cause that allowed outdated components to reappear in active designs. This prevented further accumulation of design debt across quarterly releases.
I prioritized the score explanation as a core product concern rather than supporting copy. The informational treatment was designed to reduce ambiguity and help users understand how their actions affected their score.
I made tradeoffs in feature interactions to balance usability, accessibility, and technical feasibility within release constraints. More complex interaction patterns were intentionally deferred to protect delivery stability.
Predictable Handoffs, Clearer Insights
After restructuring the component library, recurring component inconsistencies were eliminated from new releases. Design QA discussions shifted from correcting legacy issues to refining interaction details for new features. Handoff predictability improved, and future iterations no longer inherited structural debt.
The transparency improvements reduced ambiguity around how the score functioned. While the solution was incremental rather than a full conceptual redesign, it introduced clearer guidance and improved user confidence in acting on their data.
From Reactive to Proactive Design
Initially, I addressed inconsistencies reactively. Over time, I recognized the structural cause and shifted my focus toward preventing recurrence rather than fixing symptoms. If I had not intervened, inconsistencies would have continued compounding each quarter, requiring a significantly larger refactor under tighter constraints.
If I owned the roadmap moving forward, I would deepen the integration between score insights and recommended actions to create a more contextual and personalized decision layer.
Customer Success Score
Categories
Design Library
Dashboard Design
Date
Client
Salesforce
The Stakes: Trust and Speed
Customer Success Score is an engagement tool used by Salesforce clients to evaluate how effectively they are using their products. Teams rely on the score to assess adoption and decide where to focus their efforts, which makes trust and transparency critical.
The product followed a quarterly release cadence with limited margin for rework. Internally, the design workflow depended on a component library that had accumulated inconsistencies over time, directly affecting handoff quality and delivery predictability.
Opaque Data & Systemic Debt
Despite its importance, many users reported that they did not understand how the score was calculated. This uncertainty reduced trust and made it harder for teams to confidently act on the data.
At the same time, the internal component library structure allowed outdated components to propagate into new releases. Each quarter introduced additional inconsistencies, increasing QA friction and slowing delivery. The team was spending time correcting legacy issues instead of refining the core experience.
The Velocity vs. Quality Trap
There was a clear tension between maintaining quarterly release velocity and rebuilding trust in a score that users relied on for decision-making. Improving transparency required thoughtful iteration, but the delivery system itself was introducing friction every cycle.
Architecting a Better Foundation
As the main product designer, I led the restructuring of the component library to stabilize the delivery foundation. I redesigned how components were structured, versioned, and documented to prevent outdated patterns from recurring across releases.
While my design lead owned final stakeholder approvals, I heavily influenced decisions around improving score transparency. We used unmoderated user testing to validate how users interpreted the score and to guide the treatment of explanatory content.
Solving for Systems, Not Symptoms
I implemented a new versioning workflow and structural logic for the component library. Instead of patching inconsistencies file by file, I addressed the systemic cause that allowed outdated components to reappear in active designs. This prevented further accumulation of design debt across quarterly releases.
I prioritized the score explanation as a core product concern rather than supporting copy. The informational treatment was designed to reduce ambiguity and help users understand how their actions affected their score.
I made tradeoffs in feature interactions to balance usability, accessibility, and technical feasibility within release constraints. More complex interaction patterns were intentionally deferred to protect delivery stability.
Predictable Handoffs, Clearer Insights
After restructuring the component library, recurring component inconsistencies were eliminated from new releases. Design QA discussions shifted from correcting legacy issues to refining interaction details for new features. Handoff predictability improved, and future iterations no longer inherited structural debt.
The transparency improvements reduced ambiguity around how the score functioned. While the solution was incremental rather than a full conceptual redesign, it introduced clearer guidance and improved user confidence in acting on their data.
From Reactive to Proactive Design
Initially, I addressed inconsistencies reactively. Over time, I recognized the structural cause and shifted my focus toward preventing recurrence rather than fixing symptoms. If I had not intervened, inconsistencies would have continued compounding each quarter, requiring a significantly larger refactor under tighter constraints.
If I owned the roadmap moving forward, I would deepen the integration between score insights and recommended actions to create a more contextual and personalized decision layer.
