Coutts Employee Portal

At a glance

Configuring a new administrator in Coutts' commercial platform required jumping across five separate areas of the system. One step had to be repeated for every account a client held. For organisations with hundreds of accounts, that was hundreds of repetitions.

I rebuilt it as a single flow, anchored around a pattern hidden in plain sight: 95% of new administrators need identical permissions to someone already set up. Copy from an existing user, confirm the exceptions, done.

The redesigned Create user screen showing user-level permission toggles, with a magnified callout revealing the approval limits section: fields for a £10,000 unrestricted limit and £40,000 dual authorisation limit, alongside payment type toggles.

Context

I work on a complex platform serving private, non-personal and commercial clients, many with complex organisational structures spanning dozens or hundreds of accounts and layered access requirements.

Internal colleagues use this journey to create and configure administrator setups. Those administrators then manage users within their own organisations. Permissions determine who can view a client's financial data, approve payments, and access accounts. Over-permissioned users represent a compliance and financial risk. Under-permissioned ones can't do their job. The stakes of getting it wrong are real in both directions.

The problem

It takes too long, steps get missed, the system crashes between transitions, and there's so much learned behaviour that training a new colleague would be a nightmare. Setup spanned five separate areas of the system. Step four, configuring account access, had to be repeated for every account a client held. In the team's own words:

For every single account, we click the tiny link, click all five checkboxes, submit it, and then repeat for every single account the client has.

Alice, power user of the current system

For organisations with hundreds of accounts, this was repetitive and mentally draining. More importantly, "user created" didn't mean "user ready." Configuration, approval and activation were spread across separate journeys, with no single place to confirm that the task was complete.

Whiteboard sketch mapping the existing Coutts admin setup journey. 'User created?' sits at the centre with arrows branching out to edit details, user permissions, account permissions, approval, and login setup. A note at the bottom reads 'Should be linear, but can it?' with next steps listed below. — Early journey mapping. The hub-and-spoke structure of the existing system visible before any wireframe was drawn.

Flow diagram of the old Coutts admin setup journey. A central User overview hub connects to five separate areas: user edit, contract permissions, third-party accounts, account permissions, and login method, each requiring a return loop. An Issues panel lists three problems: highly repetitive setup, fragmented workflow, and inefficient approval handovers. — The existing journey: fragmented across five separate areas, with repeated edit and return cycles at step four.

The redesigned admin setup as a single left-to-right linear flow: Request details, Personal details, Digital details, User level permissions, Account level permissions, Review details, Confirmation, Display new user. — The redesigned journey: a single completion-focused flow. Request details, personal details, digital details, permissions, review, confirmation. One direction.

5 separate systems to
complete one setup

95% of administrators need
identical permissions

4 clicks to configure
any number of accounts

My approach

Understand the problem, then break it down

Working with a Business Analyst and a legacy-platform SME, we mapped the full end-to-end setup process. Two problems emerged clearly: structural fragmentation at the journey level, and accumulated legacy debt at the individual screen level.

Rather than modelling everything at once, I stabilised a simplified base journey excluding permissions first, giving engineering a stable foundation while I unravelled the more complex permissions logic separately.

A Zoom session with an ops team colleague. A notebook is visible showing handwritten notes mapping the happy paths through the existing permissions logic, with three patterns identified: Dual, Unrestricted, and Approved admin, each with different configuration requirements. — Regular working sessions with ops colleagues who use the system daily. The happy paths through permissions emerged from these conversations, not from the system documentation.

Rethink both what we ask and how we ask it

A field-level audit found inputs nobody could fully explain. Some were permanently disabled, always-on features that every user now gets by default: they couldn't be turned off, so they had no business being on the form at all. The site was littered with this kind of historical plastering over, each layer added at the time to solve a problem without removing what came before. Significant backend investigation was needed to establish what each legacy field actually did. Some were redundant and went. What remained also needed rethinking.

Many interaction patterns didn't reflect the underlying governance model.

Example: Administrator status

Two options for setting admin status: Dual and Unrestricted. Only one could logically apply, but neither was also valid, for users who weren't administrators at all. That third state was hidden: you just left both unchecked and hoped you knew that's what it meant. Unrestricted added its own confusion: on a page full of permission toggles, it read like another permission you could grant rather than an administrator type.

The legacy Coutts permissions form showing a Customer Admin section with two checkboxes (Dual authorisation and Unrestricted) with no explicit way to indicate a user is not an administrator other than leaving both unchecked. — Before

The redesigned User roles and access section with four toggle switches all off: Administrator access, Audit log access, Paperless, and Main client. Not being an administrator is now an explicit, visible default state. — After: not an admin

The same screen with Administrator access toggled on, revealing a Level sub-panel with two radio options: Sole approval (selected, described as 'Admins can approve changes independently') and Dual approval ('Changes will need an additional approval from another admin'). — After: admin, level revealed

I renamed it Sole, which pairs cleanly with Dual and reflects what it actually means, and replaced both checkboxes with a single explicit three-option role selection: Sole, Dual, or not an administrator. All three states visible and deliberate.

The first three steps of the new create-user journey mapped with their fields: Request details (client no, client name, work request, comments, client type), Personal details (title, first name, surname, delivery name, salutation, phone, email), and Digital details (username, authentication type, address if smartcard, mobile banking registration, log-in method). — Fields from the old fragmented journey themed and grouped into logical pages. A field audit ran alongside this: some were permanently on by default and removed entirely.

Listen for the pattern the system was hiding

I spent weeks in ongoing conversation with the team who live in this tool every day. The frustration they kept returning to was the account-by-account repetition. But the more important thing that emerged was a pattern the old UI had obscured:

Around 95% of the administrators being set up need identical permissions, at both user level and account level, to other admins already in the system. Only edge cases need bespoke configuration.

The old flow didn't know that. At user level, colleagues were manually working through a permissions list that was almost always the same: all off. At account level, they were repeating the same five clicks for every account a client held. The system treated every setup as unique, even when it was effectively identical to dozens already in place.

That insight became the foundation for the redesign of both pages.

Redesign around the 95% pattern

Once I knew the majority shape of the work, I could rebuild both permissions pages around it. The default stayed deliberately off throughout: over-permissioning has worse consequences than under-permissioning, so every permission granted should be a conscious decision.

User-level permissions got a single full-permissions toggle: since the answer was almost always "all off", one action reaches the right state. Account-level permissions got four patterns, covering every scenario from the routine 95% to complex edge cases.

The account-level payment permissions screen in its default state, showing the full permissions toggle, Copy user set up and Add other accounts buttons, the accounts table with bulk-select checkboxes, and tabs for All, Own, and 3rd Party accounts. — The account permissions screen: four ways to configure access, each designed around a different scenario.

The account-level payment permissions page with the full permissions toggle switched on, showing all 15 accounts with varying access states: Full access, Custom access, and No access displayed as colour-coded badges. — Full permissions toggle on: a single switch grants full access across all accounts at once. The colour-coded permission states make the before and after immediately legible.

The account permissions table with 3 of 15 accounts selected via checkboxes, showing mixed permission states. A floating action bar at the bottom shows 3 out of 15 accounts selected, with Select all 15 and Bulk Edit buttons. — Select and bulk edit: accounts checked, floating bar surfaces. One operation replaces the per-account loop.

The bulk edit permissions drawer open with 2 accounts selected. Controls for Account visibility, Payment and transfer permissions, UK payments, International payments, and Transfers, each with a Keep as is dropdown. Cancel and Apply Changes buttons at the bottom. — The bulk edit drawer: one set of controls applies to all selected accounts at once.

The Copy Existing User Setup modal with a user search field showing results for Sarah: Sarah Smith, Sarah Johnson, Sarah Brown, Sarah Davis, Sarah Wilson. — Copy from an existing administrator: search, select, and duplicate their full setup in one action.

The Add Third Party Accounts modal showing TechStart Solutions Ltd with 2 of 2 accounts available: Operating Account and Reserve Fund, both selected, with an Add 2 Accounts button. — Third-party account lookup: search for a client, select accounts, add in one step. Progress is visible throughout.

The prototype in action: enabling full permissions, copying an existing user, adding third-party accounts, and bulk-editing permissions.

Prototype rapidly to validate

For ideas I didn't know would work until I could see them, building properly first would have been a real faff. Figma Make let me scaffold close-enough visuals quickly, test whether the direction worked, then invest the time to rebuild it properly once I knew it did.

When I walked the team through the interactive prototype, the colleagues who had lived with the old flow for years called it a complete game-changer. Development were on board too, so I moved straight into high fidelity having saved a significant amount of time getting there.

Collaborate across time zones, early and often

The engineering team spans India, Switzerland and the UK. Overlap is limited to mornings, so that's when we met: feasibility checks, edge case sessions, design QA. The rest was async, sharing work in progress early rather than waiting for something polished. The solution that reached build was shaped by those conversations, not just handed over.

Building a new component accessibly

The floating action bar didn't exist in the design system. Before anything went near engineering, I did extensive research into how this kind of pattern should work for keyboard and screen reader users, then collaborated with the lead on the design systems team to build it properly from the ground up.

Early Figma Make prototype of the account-level permissions table. Three accounts are selected via checkboxes. A dark floating action bar at the bottom shows the selected count, Select All (15), and Bulk Edit, the interaction that went into the design systems conversation. — The early Figma Make prototype: three accounts selected, floating bar surfaced at the bottom. This is what went to the design systems conversation.

Rather than creating something new from scratch, we built it from existing accessible components: the primary and secondary CTAs that already had the right keyboard behaviour and focus styles baked in. Accessibility was inherited rather than retrofitted, which is a meaningfully different thing.

A few decisions only became visible through that process. A floating bar sitting at the bottom of the screen can cover whatever row the user is currently focused on, so the bar's position and the table's scroll behaviour had to be thought about together. The fix was making the table treat the bar's footprint as occupied space, so focused rows always scroll into view above it rather than disappearing behind it. The selected count shown visually in "3 accounts selected" needed to reach screen reader users too, not just sighted ones. And when the bulk edit drawer closes, focus needed to return to the table, not drop the user back at the top of the page.

Trade-offs

Three trade-offs shaped the final design. Each was chosen deliberately rather than by default.

Simplification
vs flexibility

Around 95% of setups followed predictable patterns. The alternative was to optimise purely for the majority and push complex scenarios into a separate edit journey.

Chose: context-aware defaults with bespoke configuration available within the same flow.

Upfront investment
vs downstream efficiency

Rebuilding into a completion-focused flow required greater upfront effort. We could have kept a lightweight creation step and relied on separate edit and approval flows.

Chose: consolidate permissions, validation and activation into one flow. A secondary benefit: the create-user screens are reusable for the edit-user journey.

Editing flexibility
vs engineering effort

Ideally the summary screen would allow direct navigation back to specific sections. The edit action returns colleagues to page one of the form instead.

Chose: accepted the constraint. Colleagues are experienced users working from client forms; rework is expected to be low.

Outcomes

The broader journey redesign is in build, with phased delivery planned over the next 18 months. The step-four redesign was validated in prototype and is heading to engineering.

The time saving is significant enough to be worth naming. The old journey took roughly an hour: colleagues knew this, lived it, and said so directly. After seeing the prototype, those same colleagues estimated the new flow would take around five minutes. Five separate systems collapsed into one, the account-by-account repetition replaced by a four-switch bulk operation, handovers reduced, and the cognitive overhead of learned workarounds gone.

~5 min

User-estimated setup time for the redesigned journey, down from a known ~1 hour under the old flow

Estimated by colleagues during prototype validation

The responses from prototype validation and design crit were direct enough to quote.

A complete game-changer.

Colleague, on seeing the bulk edit pattern for the first time

This is something new. How did you iterate so quickly?

Designer, Coutts design crit

A note on confidentiality: Due to the sensitive nature of the platform, specific interface elements and data structures have been generalised in this write-up. Diagrams and screens shown represent interaction structure rather than production UI.

Reflection

Complex systems work isn't about hiding complexity. It's about deciding where it should live.

Absorb complexity into logic, not interfaceThe wrong answer is to push it into the interface. The right answer is to absorb it into defaults and give the user a coherent, completion-focused task in return.

Design for the 95%, without abandoning the edge casesResisting the urge to make setup look simple by stripping capability. Making it feel simple by aligning the interface with how the task actually works.

The people who live in the tool are the best source of insightWeeks of ongoing conversation with the team uncovered a pattern the old UI had obscured entirely. No amount of analytics would have surfaced it.