Custom Roles and Two-person Approval

Project Overview

An extension of our multi-user feature that give the user the ability define custom permissions for individual team members, including the option to have certain team members require their transactions are reviewed and approved by other team members in order for the money to leave the account.

Problem

Potential business customers were unable to use the service due to their internal business rules requiring all transactions - particularly large volume transactions -have one team member set up them up, and another review it before it is processed.

Business Goals

One of the key drivers for this project was identified by the sales team. They found some high-valued prospects were unable to use CurrencyFair for the FX needs because their own internal business requirements outlined that large volume payments from company accounts required two team members review them.

Discovery

Please note: The design process below focuses on the User Management tool for this project. Separate to this was additional research and design related to the experience of the users that had permissions applied to their account access.

To get an understanding of the the impact of this problem, we revisited previous surveys to analysis the feedback, and then sent out another survey to try and understand more.

From the survey results we could breakdown the needs into two cohorts:

• One-third wanted custom permissions and two-person approval so they could control which team members can do what, and define who needed their transactions approved from a senior member before being processed;
• Two-thirds wanted to give other people access to their account that either had full access to all the features, or just view only availability.

Customer interviews

To get a better understanding the need, we contacted some business users via email, phone, and even had a couple of face-to-face catch ups.

On the back of we defined two personas:

• A small business owner that wants to be able add a team member to help with transactions, and also give their accountant view only access so they can save time by not having to regularly provide them account statements; and
• A medium size business that trades larger sums of money and needs the additional security to ensure transactions are only performed by particular team members, and in certain cases, transactions would need to be reviewed by another team member before being processed.

Additional findings

One of the most interesting pieces of information we obtained from the higher volume customers was their businesses required they use two-person approvals for larger transaction.

• One user had developed their own two-person approval system outside of the CurrencyFair product that revolved around emails and screenshots.
• Another said they would transfer more money with CurrencyFair, but couldn't because we didn't have two-person approvals. For these larger transactions they used a competitor.

Ideation

Customer journey

The outcome from reviewing the customer journey of the current product was it made clear there were gaps in the very clear early on that this project needed to be broken down.

• Phase 1 - User management: Before we could offer custom roles, we first needed to add the ability for accounts to have multi-user access. Read more about the design process for this feature here.
• Phase 2 - Custom roles and two-person approval: allow users to define their own roles and permissions, plus the add the option to enable two-person approvals.

Wireframing

Being conscious of big the project was getting, we initially wireframed an MVP version that included predefined roles in an attempt to satisfy the needs for the different users that required custom permissions.

The feedback from the users wasn't overly positive. For some this would have solved their needs, but for others it wouldn't have. The main criticism was the need to be able to set thresholds for much different team members could transfer out of the account. This just reinforced the need for the permissions to be configurable from the users side.

Scope and Planning

Given the feedback regarding an MVP approach from our customers that an MVP option wouldn't sufficient, we asked the engineers to give some high-level estimates on the size of the project taking into consideration we will need customisable permissions.

The estimate was large. The more permissions and thresholds we offered the bigger the project.

The challenge was finding a balance between a product offering that meets the users needs, but also doesn't over extend the size of the project.

The plan at this point was to see if we could find a balance between the MVP approach and the ideal approach of very granular permissions for all the different transaction types. So in order to find a balance between offering sufficient amount of control and permissions, but not offering everything we potentially could in the interest of descoping the size of the project.

Based on the MVP feedback, and previous research regarding the users needs, we descoped some functionality such as the ability to set thresholds for how much someone could exchange, but would offer the ability to set thresholds for how much someone could transfer out, and when or if it requires approval. We then asked the users we had been in close contact if this was sufficient, to which it was.

What we learned from this, that while our initial research highlighted the users high-level needs, had we dug a bit deeper we would have identified more detail about the required permissions to solve their problem sooner.

Prototyping and Testing

One of the challenges for this project was finding users that fit the persona to test it. Generally the people requesting it were very financial savvy. In order to not over burden the handful of customers that had been extremely generous with their time, we did a lot of user testing with people from the office, particularly colleagues from the accounting team. This meant we could test and reiterate quicker to gain confidence in the approach before reaching back out to our real customers to test.

Challenges

One of the main challenges we faced was how the account holder set up thresholds and approval limits. As you can see in the example above, we tried a few different approaches such as getting the user to build the permission in a sentence structure. What we found worked best was just a standard form style with checkboxes because the users said they found it familiar.

The wording of the options was also a challenge. To overcome this we use UsabilityHub to run quick very specific tests with random people. Our thinking was that if people with very little context of the form could make sense of what the selected options meant, then someone actually using the product would be able to understand it a lot better.

Implementation

This feature was first released to the customers that we had been in close contact with throughout the design phase. This gave us the opportunity to sit down with some of them and watch them go through the process of setting up custom permissions for their team members, and for a couple of them we got to see a transfer get set up and approved.

We also had an open invitation for businesses that had not been involved to take part in the beta release.

On the back of this we made some minor changes to the UI and wording, but overall their first experiences with the real product went smoothly.

‍