Designing for MUA

Multi-user access (MUA) allows business customers to add team members with different permissions to their account.

Follow these guidelines to make sure your designs work for all team members with different levels of access.

multi user access
Introduction

MUA

MUA is a feature on the business account that allows customers to invite other users to have access to their account.

These invited users are called team members.

Permissions

Each team member has a set of permissions that determine what they can see and do on the account.

For example, they could have permission to view all transactions. Or they could have permission to convert money between currencies. For a full list of the permissions team members can have, see the permissions table in resources.

Customers choose the permissions they want their team members to have when adding them to the account.

They can also update a team member's permissions at any time on the Team page.

Biz Owner invites team members to Wise account
Team members permissions
Each team member is given different permissions on the permissions configuration page in the ‘Add team member’ flow.

Permission dependencies

Some permissions are dependent on others. This can be because some features require multiple permissions to work, or because of technical limitations.

For example, someone with permission to download statements will also need permission to view all transactions.

Dependent permissions are automatically selected on the permissions configuration screen.

Permissions dependencies
Principles
Principle eye open
Show anything that users have permission for

If users have permission to see or do something, make sure they can see and do it throughout the product.

For example, if a user has permission to set up or make payments via transfer, they should be able to see and select the Send button on every screen it could appear on.

Eye closed
Hide anything that users don’t have permission for

Users shouldn’t see entry points, screens or CTAs that they can’t view or take action on. Don’t disable them or show empty states – just hide them.

For example, if someone doesn't have permission to view recipients list, they shouldn't see the Recipients tab.

When to consider MUA

MUA should be considered at two points in the design process: while preparing designs for handover and during QA before release.

Consider MUA use cases during design handover and QA before release. Review core flows, error screens, empty states and edge case. During QA state review feature complexity to see if it needs MUA testing. QA MUA use cases with the team.
Considering different MUA use cases in Figma
How you might consider MUA use cases alongside your current flows in Figma
Design process

Follow these steps to help you design with MUA in mind.

Step 1 – Start with full access

Team members with full access have all account permissions. This means they can access all screens and surfaces, and perform all actions.

Use the experience of a user who has full access as a starting point for considering MUA. This is likely just your current design.

When designing for full access:

  • Users should be able to see everything — all entry points, screens, sections and CTAs

Step 2 – Consider view only access

Team members with view only access only have permission to view the screen or section, but not to take any action.

Consider how your full access experience may differ for a user with view only access.

When designing for view only:

  • Hide any CTAs that perform an action

  • Adjust any copy that mentions taking an action

  • Review the UX and UI — does the experience still work with things hidden? Does anything look misaligned?

Transaction details  full access, user with all permissions can see everything
Full access experience of transaction details screen
Transaction details user who has view only can not see cancel transfer button and can not edit transaction category
View only experience of transaction details screen
Table with approach on ho to manage View and Full access. If they have view but no manage you should hide CTA's and adjust copy. - aIf they don't have view and manage you should hide all - pages. entry points and CTAs
Manage = perform an action e.g. add, edit, delete, create, order etc.

Step 3 – Consider other relevant permissions

Identify which specific permissions are relevant to your feature.

Consider how your experience will work for team members with and without these permissions.

For example, for the Send flow, a relevant permission would be ‘Set up or make payments via transfer’.

You need to consider what the Send flow looks like for someone who:

  • Has this permission, and their payments aren’t subject to approval

  • Has this permission, but their payments are subject to approval

  • Doesn’t have this permission

When designing for specific permissions:

  • Hide any entry points, screens or sections they don’t have permission to view

  • Hide any CTAs relating to actions they don’t have permission to perform

  • Adjust any copy that mentions taking an action they don’t have permission to do

  • Review the UX and UI — does the experience still work with things hidden? Does anything look misaligned?

Success screen with no need to have approval on payments says all is done and payment has been sent
Success screen for users who don’t need approval on payments
Success screens for someone for who's payments need approval has additional information that they transfer needs to be approved before it gets sent
Success screen for users who need approval on payments
Further examples

Here are some further examples to demonstrate how you should change your designs for users with different permissions.

Empty state on Scheduled transfer page show everything for users who have permissions to view page and set up or make payments via transfer
Full access experience of scheduled transfers screen
Scheduled transfer empty state for uses who have view only. Updated copy to reflect user can not take an action. The CTA schedule transfer got removed
View only experience of scheduled transfers screen
Payment task component shows everything for users who have a full access
Full access experience of request notification
Payment task component for users who have view only access. Updated copy to reflect that the user can't take an action. Review CTA changed to View to emphasise view only action.
View only experience of request notification
Cards tab for users with full access shows your cards section and team card section
Cards tab experience for user with full access and permission to order their business debit card
Cards tab for users with view only and no permission to order a card only shows  team cards section and your cards section is hidden.
Cards tab experience for user with view only access and without permission to order their business debit card
Risks of not considering MUA

It’s important to consider MUA while you’re designing to make sure all team members have a smooth and consistent experience.

Below are two examples of what has happened in the past when MUA use cases haven’t been considered.

When MUA use cases were not considered users with view only access could see cancel transfer CTA which then lead them to an error

Example 1

Here, because the user has view only access, they can’t cancel transfers.

However, they’re still able to select the Cancel transfer button, and they’re shown a generic error message.

This is confusing for the user, because they’re able to start a journey but can’t complete it. Ideally, they shouldn’t be able to see the button in the first place.

When view only uses case was not considered on Approvals page user could click on transaction which needs to be approved and presented with a jarring error

Example 2

Again, in this example the user has view only access, so they don’t have permission to approve payments created by other team members.

When they select a payment to approve, they’re presented with a jarring broken screen.

The copy on this first page also encourages the user to try and approve or reject payments, even though they can’t.

In this case, the user shouldn’t be able to select the transfer needing approval, and the copy should be changed.

Resources