Wildcard had proven the 'make your pay last' stream a success. Now it was time to add that same standout value to the savings account.

A quarter of our young Australian target market have less than $1000 in savings. Many of the financial products available to them are built around 'spend-to-save' features like round ups. While this can encourage you to add money to your savings account, it doesn't do anything to stop you from taking money out.

At Wildcard, we wanted users just to do the saving part.

The idea is simple - you add a family member or friend as your “defender”, and lock away your savings. When you want to take money out, you send a request to your defender, which they can either approve or reject.

I was the lead designer on the project, responsible for the interface and experience in product and website, as well as the creative for marketing.

This is one of many features I worked on at Wildcard. I've made a Dribbble projectthat shows off other parts of my work.

USERFLOW

The importance of handling the request for money in all the right ways

We mapped out the user flows to make sure we closed all possible loopholes, and to ensure the end result of any experience was a logical one. A few examples:

A defender is supposed to approve or reject the request - what if the defender is unavailable?

If the defender is unavailable, do we make the user wait? How long do they wait?

If we make the user wait, and they need the money for a serious matter - at what point are we responsible?

Figuring out how long a user should wait if their defender is unavailable led to some lengthy discussions in the team. Working with an original concept meant we didn't have much research to draw upon, so we used personas and real life circumstances. And this led us to explore times on each side of the spectrum.

Say the time to wait before a transfer is automatically approved is 1 hour. A user could send a request fully aware their defender is unavailable (working, asleep). On the other side, making the waiting period 24 hours seemed too harsh, since money transferred from Wildcard to an external bank account can take one business day itself. We settled on a 12 hour window.

It covered the loopholes a user could exploit in shorter timeframes. It gave the defender time to consider their choice and discuss it with the user, and for a user to reflect on their own choices too. Maybe the flash sale at their favourite store wasn't worth the impulse request.

WIREFRAMES

Making sure we don't tease or antagonise the user if it's an emergency

As I started the wireframes based on the user flow above, a question came to mind - what's our tone of voice in all this?

Sure, a user could want a pair of shoes that are finally on sale, and consider that an "emergency situation". But another user could need the money for an actual emergency, like urgent car repair or medical expenses. For every opportunity to playfully dismiss a flash shoe sale, there was one that could unintentionally laugh in the face of someone in an unfortunate circumstance.

So whether it was informing the user that their defender approved or rejected, or how we communicated via support with a user whose defender had not responded, there was one tone we stuck to: functional, clear copy in the product and thoughtful, practical messaging in support.

To reduce potential apprehension to such a new and different concept for a savings account, we made the following interface decisions to ensure it was seen as secure and flexible throughout:

The defender is an optional savings feature, and can be removed at any time without needing the defender's consent
The defender has to opt-in via a personalised link sent by the user
The defender can never see how much money is in the user's savings account, nor how much is being requested to withdraw
A user can contact us in regards to their account, defender and all requests

DESIGN

Conveniently using what we already have

Designing the interface was relatively straightforward, thanks to the high-fidelity wireframes and designed components in Figma from previous projects. Most of the interface was drawn from the wireframes, as they already reflected layouts I used elsewhere in other features.

We also launched a page on our website detailing how the savings defender works. The pages to add a defender and approve or reject requests were also on the website, as dynamic pages generated with the details of the request.

The interface was mobile-driven as the transfer requests are sent to via text, so it was highly likely the link would be opened on such device.

RESULTS

After 2 months, the amount of funds in savings accounts increased by 580%
It gave us another unique messaging angle to draw people to the top of the funnel, and is now a core concept in our advertising to generate leads (3000+ signups via ads about defender)
After 6 months, 68% of funds in savings accounts were locked with a defender
We also received plenty of positive feedback, with users telling us that the feature had helped them save more and become more thoughtful about impulse purchases

WHAT I LEARNED

Creating a high impact feature like this required input from the entire team. Everyone being across the board on what we were doing and why helped us make something as fully realised and prepared as it ended up being.
Speaking of multifaceted, all areas of the project running synchronously made the project run more efficiently. Back-end started as we were mapping the user flow, knowing the logic that needed to be set up. Front-end began as I wireframed - seeing structures identical to already built screens, and knowing what components to use. Marketing was already running as I designed, to test copy variations for the website and advertising.
Be functional and clear in UX copy, and leave the flair and fun for marketing.

Sadly, Wildcard closed down in 2020, after being affected by COVID-19.

That means there's no website link to share for this project, but know it was one of my favourite things I've ever been apart of.