30% less incorret payments for partners
Designing a tool to manage partner fees
My role
Product Designer
context
Project overview Lead end-to-end design solution based on user insights and business needs.
Duration
6 months
PROBLEM
Millions $$$ on incorrect payments for partners
99.6% accuracy but still more than a million euros in avoidable corrections.
The main cause for incorrect payments are wrong data entry for contract creation due to misleading user experience and icorrect Affiliate ID (AID) attribution.
I discovered that with:
- User interviews
- 5 Why's exercises
- Problem Tree
- Data analysis
PROBLEM
130+ tickets
To handle issues in the legacy Tool and incorrect contracts
I discovered that with:
- Data analysis
CHALLENGE
Legacy systems
Dependencies
Lack of integrations
Different personas
How might we
Improve user experience to avoid incorrect payments
- Data entry for contract creation and management
- Data display for AID attribution
- System feedback
- Automatization of the flow
Outcomes
Increase correct payments for partners to 99.8%
the user
Contract user
- Creates, edit and approve contracts
Payment user
- Investigate and correct an error in payments
the Problem by Business side
9 separated internal tools to investigate payment errors making payment and correction process too long
Long/wrong payment: Partner insatisfaction.
Partner could get paid incorrectly or not even get paid at all.The contract setup is a very sensitive part of the full partner cycle. It is an area that is formed of multiple processes and performed by several teams. Plus there's a huge gap of integration.
I discovered that trought
User interview
User journey mapping
Impact: I identified the problem and aligned the solution with business goals.
Exploring the problem
the Problem by User side
Poor user experience and manual workload leading to data entry errors
We discovered that trought
User inteview
designing with users
Ideating with users and prioritizing some ideas
1 - A better visualisation of current contracts
User need: When creating or editing a contract - Garantee there's no overlaps with other contracts at the same period of time.
2 - A better user experience to entry contract data
User need: When creating a contract- Data entry validation to flag errors on contract dates, fee and duplicated Id's before contract is published.
3 - Peer approval system
User need: When publishing a contract - Confidence in the system with right info and validations at approval phase to garantee the contract is correct and without overlaps.
We discovered that trought
How might we exercise
Ideation workshop with PM and team
Prioritization workshop
Ideation workshop with PM and team
Prioritization workshop
Impact:
Collaboration with different groups of stakeholders, presenting the UX Case to leadership.
Defining primary and secondary metrics
Increase correct payments for partners by 99.8%
- Reduce time to find and correct a payment error [Investigation] from 2 weeks to 1 day.
We discovered that trought
- Metrics exercise with the team
- Data collection for baseline
- Business objectives aligment
- Data collection for baseline
- Business objectives aligment
Decrease contract error rate from 23% to 5%
Reduce tickets for dev team from 130 to 10/year
Increase confidence in the new tool from 3.0 to 4.6%
Validation
With that set, I started de prototypes
and got to the usability tests, where we had the some findings:
Visualisation problem
some user tests findings
Users felt more confident with list visualisation vs timeline view. They also want more integrations and clear user flow, all in one tool.
The main user need for the user was to be able to see contracts that overlap dates so they can create and edit wirh confidence of not creating errors. This was solved by system flag, inline validation and clear visualisation all in one place.
We discovered that and many other insights trought
22h of user tests and interviews validating every iteration
A/B testing
A/B testing
Also with the tests, we discovered that users have different visibility needs, so we priotised which persona focus first: the one who creates the contracts as it is the source of the data.
user tests results
The first version didn't have much impact on the problem as expected and has a bigger learning curve.
Visualisation problem
user tests results
The second version using list view, side panel and clear contract structure had much more impact on the user experience
User loved the new integrations and all the system validations so they can do everything whitout leaving the tool.
Create and edit flow problem
A/B test results
The first version was overwhelming for the user and had higher tech cost
User needs:
Easier to check all conflicts the change might create
Too much info for the user
Hard to develop
A/B test results
The second version offer a focus experience with more scalable framework and fast feasibility
User needs:
Flag all possible conflicts
Dedicated page / Focus mode
Using same structure as creation / Less development needed
Support multiple changes
Outcome
30% less incorrect payments for partners
99.72% accuracy due to improved user experience, system feedback/flags, integrations
We solved that with:
- Improved user experience to create, edit and approve a contract
- System flags and validations
Outcome
- than 10 tickets/y
We solved that with:
- Automony for the user to create, edit, delete and approve contracts and attributions
- System validations, tons of them
- Tons of API integrations with other tools
Outcome
Migration of legacy systems
Ownership
API integrations
User needs for different personas
UX Vision
With the discovery and research insights, I could design a full UX vision for this tool, covering all the user needs. The vision is divided into 4 main deliveries for the next 2 years, with indications for more research needed and metrics follow-up.I also built a design library for internal tooling for later reference.I also built a design library for internal tooling later reference.
With this project, I've learned that, as much as the project needs an intense discovery, the delivery needs to meet the team's roadmap. I need to break the deliveries into short milestones so the team can start working sooner.
Lessons learned
The delivery was delayed in a few weeks due to long discovery phase. I learned to wrap outcomes faster.
Reach out to see more about my UX Process for this project.
lia.silvans@gmail.com
next
