Sandbox (Soldo)
Soldo
Soldo is an expense management platform designed to help businesses simplify their spending. Companies create Soldo cards with prepaid balances and spending limits, then assign them to their employees, projects and teams. This lets them manage budgets, spending and reconciliation with ease.
Background
A sandbox is a demo or test account that exists in a different environment to the live account. Users can use their sandbox to do things like test integrations, train employees and experiment with new configurations. The sandbox exists in an isolated environment, so users can test and experiment with confidence, knowing their actions will have no impact on their live account, or on their real company data or funds.
The problem
When we set out to build this feature, the Soldo sandbox environment was available for some users. It was not accessible for all users however, and could not be set up by users on their own. Users wishing to access the sandbox environment had to contact our Soldo support team, who would set up a sandbox account on the user’s behalf.
This was a very manual and time-consuming activity for our support team, and one which required continuous effort, as the account had to be actively managed and maintained by them, rather than the user.
Visibility was also an issue. As the sandbox environment was not mentioned on the Soldo website, web app or mobile app, the majority of our users simply did not know it existed.
The solution
To solve these problems, we decided to build a feature that would be visible on the web app, and would allow users to create and manage their own Soldo sandbox, without any manual intervention or assistance from us. We believed this would create many benefits, including:
Increased adoption of sandbox accounts, which should lead to increased adoption of other Soldo features, as users will likely be more prone to adopting new features having had the opportunity to test them already.
More autonomy for users, who should feel more confident to test and discover the Soldo product knowing their actions will have no real-world consequences.
Reduced risk of errors made by users in the live environment, including potentially costly ones.
Greatly reduced workload for our support team, who will only need to assist the user if something goes wrong.
Naming
One of my first tasks was to decide on a name for this new feature. My initial reaction was that ‘sandbox’ was an unfamiliar term to me, so might be unfamiliar to some of our users too. I started by doing some research in-house, speaking to the support team responsible for letting customers know about the feature, and asking questions around the language they used. Did the team use the term ‘sandbox’ when first mentioning the feature to the customer? What was their reaction? Did they immediately understand the term and the general functionality behind it, or were they confused? Despite not having the research resources we’d have liked on this project to speak to our users directly, this approach still indirectly allowed me to understand a bit more about their thought processes and understanding, and guided me on where to go next.
The next thing I did was do some research around other demo environments. Despite my initial reservations, I found ‘sandbox’ to be a common term, used widely by our direct and indirect competitors. Although UX copy should be clear, free from jargon and accessible for all, I recognised the need to weigh that up against the potential confusion that could be caused by replacing a term most of our users would be expecting to see (‘sandbox’) by something more simple, but less commonly used in this scenario (‘demo’ or ‘test’). While there was a higher probability that ‘demo’ or ‘test’ would be understood by all of our users, there was also a strong possibility that using one of these terms could make us appear less relevant or professional. In the world of expense management where the majority of our users work in accounting and finance, I recognised the importance of using terms they trust, trading the possibility that the term ‘sandbox’ could be unclear to a small percentage of users, for what I believed to be the benefit of achieving more of an affinity with the majority of them, giving them confidence that Soldo knows its stuff and understands their world, and is therefore a safe space for them to deposit and manage their money.
‘Learn more’ redesign
Another thing I wanted to address early on was how we would present and ‘sell’ this feature to our users within the web app. From an awareness of our Soldo business goals and user research done before the project began, I knew this feature needed to work for a number of different personas:
The developer, who might use the environment to create, test and iterate on custom integrations before building them in the live account.
The company admin, who might want to find out more about the Soldo functionalities, or practice setting new rules and configurations.
The manager, who might use the environment to train new company admins or accountants before allowing them to manage real company money in the live account.
I wanted to make sure my copy spoke directly to these personas, and was readily available as soon as they landed on this new feature to encourage interest and exploration. I felt like our current ‘Learn more’ popup could be improved, so I put together a new content-led solution and took it to the UX and UI designers for discussion.
We all agreed we could do better. We checked that we’d have the developer capacity to introduce a new ‘Learn more’ concept for this project, and that the project stakeholders were happy, then went ahead with the redesign.
Technical restraints
As with any project, to design the sandbox feature, we had to collaborate with the developers, weighing user needs against business goals to decide how best to use their time and resources.
One of the biggest technical restrictions we faced was that the sandbox and live environments would not be able to speak to each other. While this would keep a user’s confidential data safe and allow them to experiment freely in a space where their actions had no real-world consequences, it also meant that the sandbox environment would need to be populated with dummy data. As users had no real money to spend, they wouldn’t be able to make purchases, so no transaction data would be generated.
To solve this, we needed to give users a way to manually generate and add transactions to their sandbox account. However, time and resource restrictions meant the development team weren’t able to make any changes to the existing sandbox environment. Transactions manually added to the environment by our support team could now be added by the user, but we’d need to find a way of letting them know this, and do this, that didn’t require any changes to the current sandbox design. We couldn’t give the sandbox environment a different dashboard, for example, or add any buttons or modals, or new sections to the navigation menu.
The UX designer, UI designer and I collaborated to propose a banner, which could be easily laid over the top of the current sandbox design by the developers, without using too much time or too many resources to build.
There were many factors to consider when designing the banner, particularly from a content perspective:
The banner was the only differentiator between a user’s live environment and their sandbox one. I had to make sure it was absolutely clear which environment was which, so users always felt completely confident about which space they were in.
For this reason, the banner also had to convey multiple messages in a very small space. It needed to call the environment out as the demo one, introduce the environment to the user, let them know they needed to generate and add transactions manually, and give them a button to do so.
At Soldo, we localise copy for multiple markets, including Italian, Spanish, French and German. As copy is often at its shortest when written in English, and the Soldo UI kit states that banner copy must not exceed one line, I needed to ensure the content I wrote would fit comfortably in all languages, and on multiple screen sizes.
We knew we wanted to add a small illustration to the banner to help it stand out and signify that the user was now in the sandbox environment. This meant even less space for copy, particularly when localised in other languages.
Taking all these challenges into account, I designed the content and we came up with a solution:
In summary
Designing the sandbox feature presented numerous challenges, including it needing to work for multiple personas, needing to address a lack of awareness of the benefits of using the demo space, and technical time and resource restraints. Working on this project gave me an opportunity to get creative, challenging me to solve problems in new ways, and present solutions that worked within the limitations set while still meeting and exceeding user needs and expectations.