02%

Users don’t want to repeat their actions multiple times.

Swissquote’s Customer Care received an increasing number of complaints from long-term investors being frustrated about having to repeat the placement of their orders multiple times a month and relying on external tools as reminders.

Learning about our users

Starting our project, we had to learn more about the users concerned about this problem. I hosted a workshop to fill up our CSD (Certainties, Suppositions, Doubts) Matrix and assess what we already knew and what we needed to uncover. Then, we prepared an external survey targeting people who DCA that would be rolled out by our UX research team.

I started exploring possibilities

We identified two possible answers to our users’ problems within our previously defined scope:
1. The possibility to create portfolios made of different assets that you could then recurringly invest in.
2. Introducing a new recurring order type allowing users to invest in one asset at a time.
We started exploring the first version motivated by our survey result showcasing that our target users were likely to automate more than 1 order. We developed a prototype and then conducted usability testings.

Though Option 1 gathered really good feedback during User Research, we ran into a technical constraint.

Swissquote did not offer the possibility to buy a fraction of shares, and this system was really clunky without it. We then knew we had to move to option two but we couldn't ignore the fact that 95% of users noted they'd invest an amount of money rather than a quantity of shares of a variable price for budgeting purposes.

I started exploring a 'Maximum amount' system

Brainstorming with the Product Analysis, we tested the possibility for the user to set a maximum amount of money they'd invest every week or month and our system would match that amount with as many shares of the product as possible. That way, people could actually manage their finances without any unexpected surprise at the end of the month but this system was also implementable straight-away from a technical constraint.

How to access the feature?

Moving on from this discovery, I now had to find how users would encounter the feature and from where it'd be actionnable. We decided to conduct a Tree testing and asking users which path they would take to place a recurring order.
The results offered a lot of insight and we learnt that 45% of them would access it through the trademask while 35% would first go to their orders which was were they would be able to find the previously set recurring orders.

From this realisation, we decided to add recurrence as an order type in the trademask but also offer a second point of entry through the orders tab that displays an empty state when users have no recurring orders set with hints on how to access the feature. While conducting usability testing, we found that all users were able to find the feature on the first try.

Users need affordance to correct past actions

If a user is still lacking the fund before his recurring order, what happens? From looking at competitors, we observed three options:
1: Link the recurrence to a credit card to avoid any funding problem
2: Alert the user some time before to let him know his trade might be cancelled
3. Do nothing and wait for the order to fail

Considering our target users, the first option was very interesting to our team but was quickly dropped for this version because of technical and legal issues. We then opted for the second option as the third one didn’t adress our users’ lack of liquidity problem.