Chuck Shin
/ Surcharging Case Study
← Back
Case Study
Empowering Users Through Self-serve Surcharging
Designing Safe Self-Serve Experiences in High-Risk Financial Systems
Role
Lead Product Designer
Team
PM, Engineering squad 1
Timeline
4 weeks
Overview
Surcharging is a feature that directly impacts money, legality, and user trust.
A single mistake can result in financial disputes, legal exposure, or customer churn.
This project focused on turning a high-risk, rules-based configuration into a safe, understandable, and self-serve experience—without hiding complexity or shifting liability onto the system.
The Problem
At first glance, surcharging looked like a UI complexity problem without context.
In reality, it was a much deeper tension between:
- Business risk
- User anxiety
- Compliance complexity
The existing model relied on a flat-rate configuration managed through Customer Support.
This created a broken operating model:
Business pain
- Supplier churn
- CS ticket overload
- Legal and compliance risk
- Competitive disadvantage
Supplier pain
- No self-serve control
- Heavy CS dependency
- Anxiety around compliance and mistakes
The real challenge wasn’t how to make the UI simpler. It was how to let suppliers move fast without exposing them—or the company—to legal and financial risk.
How might we let suppliers move fast without exposing them to legal and financial risk?
My Role
I was the Lead Product Designer on this project and owned:
- Problem framing
- UX strategy
- Design decisions and trade-offs
- Cross-functional alignment through delivery
Constraints
- Legacy product → No mature design systems
- Limited engineering capacity(resources)
- Legal and regulatory risk
- Tight delivery timeline
Challenges → Solution
Three Critical Challenges
1. A broken operating model
Flat-rate surcharging led to CS dependency and supplier churn.
2. Enabling self-serve without increasing risk
Suppliers needed self-serve control, but compliance anxiety remained high.
3. Shipping under real constraints
No design system, limited resources, and the need to ship quickly.
Challenge 1: What Users Actually Needed
Insights gathered from:
- Interviewing Customer support team
- Customer support team’s records with customers
- Supplier feedback
- Legal team guidance
They weren’t asking for a fully flexible rule engine.They wanted to understand what would happen—and trust that they weren’t making a costly mistake.
Users didn’t want more complexity. They wanted safe control.
Solution: Safe, Scoped Self-Serve Setup
Instead of designing maximum flexibility, PM and I intentionally scoped the solution.
Key design decisions
- State / province-level configuration
- Explicit condition building
- Visible maximum surcharge percentages (US & Canada)
- Review-first mental model before saving
Challenge 2: Guardrails Where It Matters
Not all friction is bad.
In high-risk financial flows, removing friction everywhere can create serious problems.
I focused on adding protection only at critical moments.
Solution: Guardrails included
Instead of designing maximum flexibility, PM and I intentionally scoped the solution.
- Legal-aligned disclaimers
- Confirmation modal before saving
- Clear awareness of where rates would apply
These moments slowed users down intentionally. Not to block progress, but to prevent irreversible mistakes.
Challenge 3: Shipping Fast Under Real Constraints
The solution still needed to ship quickly.
No design systems + Lacking resources
→
Reused familiar UI patterns
Engineer-friendly components
→
2 weeks delivery (Design)
1 sprint implementation (Eng)
Faster than PM expectation
Outcome & Proof
While long-term metrics were still evolving, early signals were strong:
These outcomes validated the approach without over-claiming final impact.
26%
Reduced Customer Support team dependency (tickets)
70K+
in revenue during the first week
Positive
qualitative supplier feedback
Kudos
Strong recognition from Product and CS teams
Reflection
What This Project Demonstrates
- Designing for risk, not just usability
- Strategic scoping under technical and legal constraints
- Turning regulatory complexity into clear mental models
- Knowing when to add friction intentionally
- Owning discovery → delivery → storytelling
Warning modal before user saves the surcharging
Surcharging reinforced something critical for me:
Good UX isn’t always about speed—it’s about confidence, clarity, and accountability, especially when money and compliance are involved.
Chuck Shin
/ Surcharging Case Study
← Back
Case Study
Empowering Users Through Self-serve Surcharging
Designing Safe Self-Serve Experiences in High-Risk Financial Systems
Role
Lead Product Designer
Team
PM, Engineering squad 1
Timeline
4 weeks
Overview
Surcharging is a feature that directly impacts money, legality, and user trust.
A single mistake can result in financial disputes, legal exposure, or customer churn.
This project focused on turning a high-risk, rules-based configuration into a safe, understandable, and self-serve experience—without hiding complexity or shifting liability onto the system.
The Problem
At first glance, surcharging looked like a UI complexity problem without context.
In reality, it was a much deeper tension between:
- Business risk
- User anxiety
- Compliance complexity
The existing model relied on a flat-rate configuration managed through Customer Support.
This created a broken operating model:
Business pain
- Supplier churn
- CS ticket overload
- Legal and compliance risk
- Competitive disadvantage
Supplier pain
- No self-serve control
- Heavy CS dependency
- Anxiety around compliance and mistakes
The real challenge wasn’t how to make the UI simpler. It was how to let suppliers move fast without exposing them—or the company—to legal and financial risk.
How might we let suppliers move fast without exposing them to legal and financial risk?
My Role
I was the Lead Product Designer on this project and owned:
- Problem framing
- UX strategy
- Design decisions and trade-offs
- Cross-functional alignment through delivery
Constraints
- Legacy product → No mature design systems
- Limited engineering capacity(resources)
- Legal and regulatory risk
- Tight delivery timeline
Challenges → Solutions
Three Critical Challenges
1. A broken operating model
Flat-rate surcharging led to CS dependency and supplier churn.
2. Enabling self-serve without increasing risk
Suppliers needed self-serve control, but compliance anxiety remained high.
3. Shipping under real constraints
No design system, limited resources, and the need to ship quickly.
Challenge 1: What Users Actually Needed
Insights gathered from:
- Interviewing Customer support team
- Customer support team’s records with customers
- Supplier feedback
- Legal team guidance
They weren’t asking for a fully flexible rule engine.They wanted to understand what would happen—and trust that they weren’t making a costly mistake.
Users didn’t want more complexity. They wanted safe control.
Solution: Safe, Scoped Self-Serve Setup
Instead of designing maximum flexibility, PM and I intentionally scoped the solution.
Key design decisions
- State / province-level configuration
- Explicit condition building
- Visible maximum surcharge percentages (US & Canada)
- Review-first mental model before saving
Challenge 2: Guardrails Where It Matters
Not all friction is bad.
In high-risk financial flows, removing friction everywhere can create serious problems.
I focused on adding protection only at critical moments.
Solution: Guardrails included
Instead of designing maximum flexibility, PM and I intentionally scoped the solution.
- Legal-aligned disclaimers
- Confirmation modal before saving
- Clear awareness of where rates would apply
These moments slowed users down intentionally. Not to block progress, but to prevent irreversible mistakes.
Challenge 3: Shipping Fast Under Real Constraints
The solution still needed to ship quickly.
No design systems + Lacking resources
→
Reused familiar UI patterns
Engineer-friendly components
→
2 weeks delivery (Design)
1 sprint implementation (Eng)
Faster than PM expectation
Outcome & Proof
While long-term metrics were still evolving, early signals were strong:
These outcomes validated the approach without over-claiming final impact.
26%
Reduced Customer Support team dependency (tickets)
70K+
in revenue during the first week
Positive
qualitative supplier feedback
Kudos
Strong recognition from Product and CS teams
Reflection
What This Project Demonstrates
- Designing for risk, not just usability
- Strategic scoping under technical and legal constraints
- Turning regulatory complexity into clear mental models
- Knowing when to add friction intentionally
- Owning discovery → delivery → storytelling
Warning modal before user saves the surcharging
Surcharging reinforced something critical for me:
Good UX isn’t always about speed—it’s about confidence, clarity, and accountability, especially when money and compliance are involved.
Chuck Shin
/ Surcharging Case Study
← Back
Contents
Overview
The Problem
My Role & Constraints
Challenges → Solution
Reflection & Learnings
Case Study
Empowering Users Through Self-serve Surcharging
Designing Safe Self-Serve Experiences in High-Risk Financial Systems
Role
Lead Product Designer
Team
PM, Engineering squad 1
Timeline
4 weeks
Overview
Surcharging is a feature that directly impacts money, legality, and user trust.
A single mistake can result in financial disputes, legal exposure, or customer churn.
This project focused on turning a high-risk, rules-based configuration into a safe, understandable, and self-serve experience—without hiding complexity or shifting liability onto the system.
The Problem
At first glance, surcharging looked like a UI complexity problem without context.
In reality, it was a much deeper tension between:
- Business risk
- User anxiety
- Compliance complexity
The existing model relied on a flat-rate configuration managed through Customer Support.
This created a broken operating model:
Business pain
- Supplier churn
- CS ticket overload
- Legal and compliance risk
- Competitive disadvantage
Supplier pain
- No self-serve control
- Heavy CS dependency
- Anxiety around compliance and mistakes
The real challenge wasn’t how to make the UI simpler. It was how to let suppliers move fast without exposing them—or the company—to legal and financial risk.
How might we let suppliers move fast without exposing them to legal and financial risk?
My Role
I was the Lead Product Designer on this project and owned:
- Problem framing
- UX strategy
- Design decisions and trade-offs
- Cross-functional alignment through delivery
Constraints
- Legacy product → No mature design systems
- Limited engineering capacity(resources)
- Legal and regulatory risk
- Tight delivery timeline
Challenges → Solution
Three Critical Challenges
1. A broken operating model
Flat-rate surcharging led to CS dependency and supplier churn.
2. Enabling self-serve without increasing risk
Suppliers needed self-serve control, but compliance anxiety remained high.
3. Shipping under real constraints
No design system, limited resources, and the need to ship quickly.
Challenge 1: What Users Actually Needed
Insights gathered from:
- Interviewing Customer support team
- Customer support team’s records with customers
- Supplier feedback
- Legal team guidance
They weren’t asking for a fully flexible rule engine.They wanted to understand what would happen—and trust that they weren’t making a costly mistake.
Users didn’t want more complexity. They wanted safe control.
Solution: Safe, Scoped Self-Serve Setup
Instead of designing maximum flexibility, PM and I intentionally scoped the solution.
Key design decisions
- State / province-level configuration
- Explicit condition building
- Visible maximum surcharge percentages (US & Canada)
- Review-first mental model before saving
Challenge 2: Guardrails Where It Matters
Not all friction is bad.
In high-risk financial flows, removing friction everywhere can create serious problems.
I focused on adding protection only at critical moments.
Solution: Guardrails included
Instead of designing maximum flexibility, PM and I intentionally scoped the solution.
- Legal-aligned disclaimers
- Confirmation modal before saving
- Clear awareness of where rates would apply
These moments slowed users down intentionally. Not to block progress, but to prevent irreversible mistakes.
Challenge 3: Shipping Fast Under Real Constraints
The solution still needed to ship quickly.
No design systems + Lacking resources
→
Reused familiar UI patterns
Engineer-friendly components
→
2 weeks delivery (Design)
1 sprint implementation (Eng)
Faster than PM expectation
Outcome & Proof
While long-term metrics were still evolving, early signals were strong:
These outcomes validated the approach without over-claiming final impact.
26%
Reduced Customer Support team dependency (tickets)
70K+
in revenue during the first week
Positive
qualitative supplier feedback
Kudos
Strong recognition from Product and CS teams
Reflection
What This Project Demonstrates
- Designing for risk, not just usability
- Strategic scoping under technical and legal constraints
- Turning regulatory complexity into clear mental models
- Knowing when to add friction intentionally
- Owning discovery → delivery → storytelling
Warning modal before user saves the surcharging
Surcharging reinforced something critical for me:
Good UX isn’t always about speed—it’s about confidence, clarity, and accountability, especially when money and compliance are involved.