Wise • 2021
Request money for businesses
Context
Wise is a fintech that’s challenging the status quo in international banking. Used by millions to save millions, it offers bank accounts and low-cost transfers to consumers and businesses.
For this project, I was a product design lead on the Receive team. This team looks after things like the bank details issued to customers.
I started off establishing the project on my own, and was later able to onboard a product designer. I reported to the VP of Design at Wise and was supported by a full-stack team that built for web, iOS, and Android.
Problems to solve
For our users
Businesses were our highest volume receivers on Wise. But the tools available to them were minimal — the Wise app simply provided some bank details. So how could we help these businesses users achieve their goals more easily and effectively?
For the company
The Receive team was focussed on increasing the volume of payments into Wise. But how?
They knew that businesses was one area to target, but didn’t have a whole lot of conviction.
Project overview
Building the business case for businesses
When I joined the team, I realised I had a series of biases to overcome.
The team had a background primarily in building for the consumer side of Wise and saw other UK fintechs, such as Monzo, as an indication of where the market was going.
But our data suggested otherwise — it was our businesses customers driving volume and, ultimately, growth.
Workshops and research tools
An assumptions workshop. Did everyone really already agree on building for consumers? As it turns out, no.
Interviewing personal and business customers.
Going through the data and working out the types of transactions that Wise was helping with already.
Output from research and workshops
We knew who we wanted to help:
We saw an opportunity to help small businesses that would request high-value, low-frequency payments — typically invoices. These users were already trying to use to Wise, and our data reflected it.
This work helped me decide what areas to focus on for our MVP, and what would be left for later.
And how we could help:
-
We found users would design their own email flows using automated tools for Gmail or Outlook. This took a lot of time that business owners wanted back.
-
Bank transfers are much cheaper for businesses to handle. But payers preferred to go for more convenient options such as card payments. These carried additional fees. Could we move some payers back to bank transfers?
-
A lot of the businesses we talked to, didn’t understand the differences between sets of account details. And would often give out the wrong ones, leading to non-payment or other issues.
-
Because they used email, a lot of business customers had to spend time explain to their users how their payers could use bank details issued by a company called “Wise” instead of a traditional bank.
-
Small businesses often pay for yearly subscriptions for full accounting software packages. So rather than try to fully replace established players like Xero, we focussed on reducing the friction when sharing details or requesting payments.
Existing artifacts
A design challenge I had to solve was that account details were previously a passive part of the Wise experience.
When you asked for account details, the Wise app or website would show these in an accordion or full-screen modal, ready for you to copy out.
Areas to design for
Breaking down the work
-
The Wise account was built around the idea that every currency was its own bank account, with its own associated features. But this meant that a lot of functionality lived on the currency ‘card’ view. Other teams were also adding functionality to this view as well.
-
My aims for this work:
Help a user select the right set of bank details
Input enough information for the payer, so they know that the request is legitimate.
Generate and confirm that the information entered was correct and to send it to the payer.
-
Upload a PDF from another accounting tool.
-
Wise already had an excellent notification system that let me build fine grained payment notifications, using a custom markup language.
But I also wanted to present a list of created requests, so that a requestor could stay on top of their payments, and know when to chase for payment.
-
My aims for this work:
Clearly present the bank details and payment information, so a payer know who its from.
Give confirmation of payment, and allow the payer a signup route to Wise for future convenience. (Wise offers free transfers between accounts).
Input enough information for the payer, so they know that the request is legitimate.
Generate and confirm that the information entered was correct and to send it to the payer.
UI exploration
When I started working on this project, Wise’s in-house Design System, Neptune, was starting to take shape. This made it a lot easier to experiment and rapidly prototype ideas.
Testing and validation
-
I design and tested an alternative layout for the balance card that would move certain management tasks to a ‘Manage’ tab within the cards UI. While this test performed better than the alternative — adding an action sheet with additional options — it was proposed just as a broader IA rethink was underway. So we didn’t progress with it in the end.
-
From a UI standpoint, the payer flow was fairly straight forward. But what mattered most was the content that would live inside a few pages. How could we build trust? How could we build understanding? Me and my team’s designer would run frequent Usertesting.com sessions to try and gain conviction as to the right solution.
It led to use settling on terms such as “Request”.
-
In our initial interviews, many of the users had been keen to express their frustration over the state of invoicing on the Wise app. So when we were closer to a beta product, I reached out to some of these users to get their honest feedback.
-
Wise has a few Facebook user groups that discuss things such as the product, exchange rates, etc. I used this group as a way to gather beta testers for our app as well. It also was a useful way to research common invoicing issues and the language people naturally use to describe issues such as invoices and requests.
Impact
-
Within a month of release, we were seeing ~2,000 users per day setting up requests.
-
This gave my team the confidence to continue to build for businesses — and eventually they span off another team to focus on these customers specifically.
-
For this project, we were the first to use their new contribution framework. So the upload components we designed for them, was released across the Wise app as well.
