iwocaPay is a short-term credit solution for B2B transactions. The product has 2 primary user types, buyers and sellers. Sellers are those who use iwocaPay to offer their B2B customers credit terms and buyers are those who are using those terms to make the purchase.
For this project we were having problems in retaining buyer customers to make repeat transactions using iwocaPay. How might we do that?
Employer: iwoca | Involvement: Lead Product Designer
The first port of call was to ensure the team were aligned on the problem and what the current state of play was.
What functionality does our product currently offer which are related to this problem? What are our technical restrictions? Are there any legal restrictions that need to be considered? Has there been any previous research which we can learn from? What’s the current process?
Working with the Product Manager we agreed the key outcomes that we wanted to generate from the project:
Repeat buyer usage
Allow buyers to use iwocaPay again and again to spread out their payments. Key metric: Non-unique buyer loans
Unlock new seller segments
Enabling multiple transactions should allow us to better serve other segments of sellers. The main one that has been mentioned so far is wholesalers. Other segments to think about may be services on retainers. Key metric: Number of seller signups
More buyer usage from existing sellers
Unblocking buyers from making multiple payments should also allow our existing sellers to utilise iwocaPay more as their repeat buyers can use us more easily, but the impact from this may be modest if the majority of our current sellers usually have one off buyers.
Our approach was to go ‘tech first’. We knew it was a large project with a number of dependencies on other teams in the business. It meant that there was a high risk that we could hit delays or unexpected complexities. Therefore our principal for this project was to “Get a solution out to unblock multiple transactions”.
This means that we prioritised getting any working solution out rather than trying to build the best possible solution.
To better understand the restrictions from a technical standpoint, I created a list of the user scenarios that the different types of buyer could encounter to ensure that we had all avenues covered.
This was developed in collaboration with the engineers and the Product Manager to ensure no key edge cases were missed.
With the scenarios all laid out and clarification from engineers on technical limitations on the backend and how the structure could work, I was able to put together the user flow for a buyer wanting to make a repeat / concurrent transaction.
This was shared early and often with the tech team and the Product manager to ensure everyone was aligned, and was iterated as discussions were had.
You can see a larger Figma prototype version here.
We quickly prototyped up some possible avenues for the feature in Figma. We decided to make these relatively fleshed out in terms of UI due to the low level of technical knowledge of our customers and the testers we were using.
We created 2 options, asking the users to go verbalise their thoughts and understanding of the information presented to them as best they could. We were able to get an idea of their preference for the 2 options fairly quickly which matched out initial hypotheses of option 1 (single screen layout with plans on the left and info on the right) being the preference for users.
You can see the prototypes here.
The current product wasn’t fit for purpose for the new concept. So working closely with engineering we worked backwards from the “North Star” design to create an iteration plan.
This would allow us to step towards the final design steadily, providing time for tech to discover any unknown issues along the way and to ensure it’s a steady evolution for our users.
It also meant that if the tech team ran out of engineering time before the planned release of the feature, as long as they had reached one of the agreed iterations, the design and UX were sound and nothing would be “unfinished”.
It also meant that we would definitely a Figma design which matched what was released to production whichever iteration that was released.