4x Product Design
3x PM
3x Compliance
4x Customer Success
2x Data
2x Marketing
3x Leadership
The Problem
To understand what was frustrating people, we interviewed Traders and Finance Managers in companies currently onboarding with us. Very quickly we found 3 main problems
When we shared this in our weekly cross-department call, we learned these problems weren’t just frustrating for users, but for our staff too.
To prioritise improving onboarding for both users and staff, we needed to show what impact these problems were having on the business. Digging through the data, we found 3 major insights.
With the impact clear, something had to change.
Siloed teams unifying to solve 1 problem
As the problems we found touched many areas, to solve them, we formed a cross-functional team with people from account management, onboarding, compliance, sales and customer success.
Product, design and engineering often worked closely as a Scrum team; however, other teams tended to be more siloed.
To make sure everyone was comfortable, we ran a kick-off call:
Competing sources of truth
From the initial user feedback, one clear problem stood out — people didn’t know what they needed to give us.
When we dug into why, we found that each team had different sources of “truth”, from product screenshots to four years’ of documents owned by different people.
From these sources, we made a master list of requirements. Over several sessions, we went through it line by line and asked one question: “Why do we need this?”
For some info such as “Company name” it was clear why we needed it. Other details took longer clarify.
We found 3 reasons why:
By giving people time away from their busy schedule and a safe space to ask questions, the confusions started to disappear.
Learning from how others solved similar problems
Tesler’s Law states that in any system, there’s a certain amount of complexity that can’t be reduced. If a business needs to give us 20 pieces of info as part of anti-money laundering checks, that can’t change, but it can be made easier.
Looking into competitors, we found 5 main principles that drove our design direction:
“Do we really need to ask them for this much?”
As our users (West African businessmen) were hard to schedule for usability testing, we did the first round with stakeholders.
As subject matter expects, this had 3 benefits:
With stakeholder’s newfound empathy for users, we looked at each requirement again and asked “do we really need this?”. How can we strike the right balance between what we legally needed & a good user experience?
What we thought they wanted, and what they actually want
With the new requirements defined, our team of three product designers (including myself) used our Figma design system to quickly iterate high-fidelity prototypes until we had 2 routes we were happy to test with users.
After the first round of 5 tests, we added 2 more guiding design principles:
Additionally, since the project first started there’s been an elephant in the room: to help onboard busy users our staff need to manually complete their profiles on their behalf.
Delivering 1 sprint at a time
After one last iteration we had a solution that users, stakeholders and developers were happy with.
However, there was one bump in the road: building everything would take a long time and shift focus from other high-priority projects.
To get priority, we split the solution into smaller slices that could be delivered and validated one sprint at a time:
Good UX is good business
One year later, the metrics speak for themselves, each month;
Additionally, an unexpected but big win, teams that were previously siloed were now working closer together
3 Years Wiser — If I Did This Project Today
Overall, the project was a success, but it wasn’t without a few snags. With my current experience as a senior product designer, there are a few things I’d do differently.
