Soldo is a multi-user spending account for business which allows total control over spending and budgeting tasks.
The process used for the below described feature is the one featured in the process page and Medium story.

The starting point an existing implemented feature which allows users to automatically transfer money from the company to the the user wallets.
There were some additional features to be developed and we had received some negative feedback about the implemented version.
In this context, I started thinking about a possible re design of the existing feature that incorporated also a re organization of other  existing features  and new ones. I began scouring for more information (going through Intercom chats and chatting with our UX researcher) and found out why the users were not satisfied with what was available.

The previous implementation

To prove that I then started researching the problem to really understand what was the problem we were trying to find: admins needed to automate the process of topping up the user’s wallets in order not to leave it empty. I started pulling some data on the current situation of the feature and the wider context of transferring money to understand how the users were using the existing feature: the situation showed low engagement (under 9%) and an unclear pattern of use. The assumption was formulated and ready to test with the prototype.

Screen capture of the  prototype during testing

For testing, we recruited some users (with the help of the UX researcher) for half hour Skype interviews to test both the current version and the prototype. I made sure to get a sample that - even though small (recruiting companies is as hard as it gets) - was still representative of the greater user base; I used and gathered the segmentation data our analyst had recently made and used this to position rank these companies on various significant variables.
The results confirmed the assumption and made emerge a range issues while they also gave us an idea which way to proceed in terms of implementation: start simple and add complexity. 

An overview of the new version

The interface was then presented to the stakeholders and refined to integrate inputs from the stakeholders. The design tested was then modified to incorporate the re organization of another existing feature and a new one (which had been in roadmap for awhile).
KPIs were also defined in order to monitor the feature’s success starting at the month mark after the implementation (uses of the feature vs. traditional transfers, overall use and companies that use the feature), another point I made sure to add was improving communication of the feature when released.

Complete flow of the new version

More projects