30% less incorret payments for partners
60% faster approval
Designing a tool to manage partner fees
30% less incorret payments for partners
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.
the Problem by User side
Takes times to find the fee and overlaping dates.
Manual validations of complex data.
We discovered that trought
User inteviews
designing with users
Ideating with users and prioritizing some ideas
1 - Clear visibility od dates overlap
User need: When creating or editing a contract - Garantee there's no overlaps with other contracts at the same period of time.
2 - Creation of a flag system
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
I did externsive usability and AB/testing to validate how the solutions proposed solve the problem.
Visualisation problem
some user tests findings
Users could find the fee and overlaping dates in seconds.
The new UI was a success.
The main user need for the user was to be able to see contracts that overlap dates so they can create and edit with 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
Design decisions, trade-offs
- To move the timeline visualisation to V2 and keep the MVP scope smaller while keeping the user satifiscation and solving the main problem
- To design more data assets than planned to help the user with payment predictions
- Mine design decisions on unifing the entire tool navigation changed the way users and stakehodler see the tool, reaching a much bigger rule in the department.
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 3 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
