Background
An increasing number of B2B customers had multiple people managing their accounts but the system limited them to only one admin profile, which led to access problems and security concerns.
Goals
Redesign admin management to allow for multiple admins and resolve access issues.
Ensure the update is clear and can be used without guidance.
Futureproof the design for easy adaption and utilization in other areas.
Outcomes
Positive
Customer care feedback
Low
Time to update
90%
Issues addressed
Role
Led the end-to-end UX/UI design process.
Collaborators
Worked closely with 2 product teams to ensure design was within scope and was technically feasible. Also collaborated with sales support on research and testing.
Audience
Primarily internal support teams but also fleet managers.
Main tools
Jump to
Problem
A limit on admins
EasyPark’s B2B customers were limited to a single admin per account, forcing larger customers with multiple admins to share credentials for their accounts. This was a problem for a few reasons:
There was a security risk due to multiple people sharing credentials.
Auditing was complicated as it wasn't always clear who made a user-initiated account change.
Customers' ability to manage their accounts effectively was hindered.
A growing focus on security and pending migrations from legacy platforms with larger customer accounts amplified this problem as it could impact customer adoption and retention.
Designing for a clear goal
The obvious solution was to allow accounts to have multiple admins but we needed to work out how that would be managed as both customers and support colleagues were used to viewing and managing a single admin at a time.
We also needed to decide if there should be a self-service aspect so that customers could manage admins themselves and we could reduce support contacts.
Discovery
How admins are used
I started by analyzing account setups and admin usage, learning that designs would likely need to focus on clarity as management would be infrequent.
Admin numbers
In reviewing Mixpanel and Looker analytics, I came to understand that accounts with mutiple admins typically had two, while large accounts occasionally had five or more, with edge cases reaching above ten. This insight shaped the assumption that the design needed to be primarily optimized for small-scale management while ensuring compatibility for extensive management.
Managing customer admins
In speaking with colleagues who regularly supported B2B admin needs, I found that customers needing multiple admins usually had them set up during onboarding and subsequent admin changes were infrequent. Given this, I prioritized clarity in flows, ensuring that admin management was easy to understand even if only done occasionally.
Ideation
Changing scope
I started mapping out user flows and rough wireframes for both our internal and customer-facing platforms, gathering early feedback from product and engineering to refine requirements.
However, as discussions progressed, we learned that the next migration project was going to be pushed back and we didn't need to worry about serving the admin needs of incoming legacy platform customers.
This led to an important question: Could we reduce the scope and make room in the quarterly plan for other projects?
Going back over the research, I felt that limiting the management options to our internal platform and pausing development of self-service options would work as admin setup was mostly done by support colleagues during onboarding and changes were infrequent.
Designing for an internal platform
In order to adapt the internal admin management flow for multiple admins, I worked on a number of ideas:
A clear, compact admin list – Since customer support teams rarely needed the full details of each admin, I streamlined the display, emphasizing key information.
Inline actions for efficiency – Previously, admin management required opening a new tab, slowing down workflows. I redesigned the flow to use an inline dialog, allowing quick edits without losing context.
Persistent action visibility – To avoid clutter, I considered hiding actions within a menu or revealing them on hover. However, given that most accounts had only one or two admins and changes were infrequent, I opted to keep actions visible to ensure clarity.
Handling large admin lists – For accounts with more than ten admins, a long list would push down more frequently accessed content. To prevent unnecessary scrolling, I introduced a collapsible section, keeping key areas easily accessible.
Self-service updates within scope
While it wasn't in scope to allow customers to manage admins themselves, I still wanted to give them clear visibility of their current admins so they knew who had access to their business account and how to change them.
I put together a design that was as simple as possible for the engineers to implement and the product manager agreed that the benefit was worth including.
Not an ideal layout
The problem with this update was that it made an already busy dialog even busier, so I wanted to propose a few alternatives. It wasn't possible to scope them in, but I still wanted to suggest them as future improvements to enhance the UX and prepare for a known future update to allow self-service management of admins.
Testing
User testing with colleagues
To validate the internal platform designs, I tested with 5 customer support colleagues to ensure they could quickly identify and manage admins.
The testing process involved:
Short interviews – Understanding their experience with admin management and identifying pain points.
Task-based testing – Having them manage admins in mock accounts of different sizes, ensuring they could easily find, add, and modify users.
Key findings
The designs were well received, giving me confidence in preparing the designs for implementation:
Outcomes
Post-launch feedback
Implementation went smoothly, with no major issues reported. Customer support teams could easily set up multiple admins, reducing security concerns and increasing efficiency around account setup and management.
This positive feedback was reinforced during a later monthly sync with sales support, where we received confirmation that the feature was quick and easy to use and addressed 90% of admin issues that customers had (the remaining 10% being more complex and requiring further enhancements).
A missed opportunity
While the solution was successfully implemented, adding relevant analytics events wasn't part of the Definition of Done at the time. This meant it was harder to monitor feature adoption and usage behavior, ultimately making it difficult to identify usability issues and inform future refinements.
Learnings
The unique challenge of internal testing
It’s an interesting challenge testing with customer support colleagues as they are both highly knowledge of their product and highly sensitive to change.
This means that design and testing both need a different approach than when designing with customers and sometimes it's tricky to remember that, particularly when I'm working on designs for internal and external products simultaneously.
