Kelsey Mustra

Case Study: Designing Flexible & Secure User Management

Background

Project
User Management

Tools: Figma, HotJar, Azure DevOps, Jira, Confluence

Role
Lead Product Designer at The Myers-Briggs Company

Year
2024 – 2025

As our platform prepared for a global rollout to replace legacy systems, a critical gap became clear: users needed the ability to collaborate within organizations, sharing inventory and projects, while maintaining their own individual accounts. Not only would this feature enhance usability and collaboration, but it would also improve our security compliance standards by eliminating the need for shared logins.

The Impact
  • Increased customer retention
  • Ensured renewal of six-figure contracts and million dollars annual revenue
  • Improved security for ourselves and our customers
The Opportunity

How might we enable secure collaboration across teams without overwhelming users with complex permission settings?

Behind the scenes, we already had backend functionality to support this use case, but it was managed manually by technical support and engineering on a per-customer basis for nearly a decade. This ad hoc setup meant that while the logic existed, the infrastructure was fragile, complex, and largely undocumented. Our challenge: turn this hidden backend feature into a scalable, intuitive user experience on a tight timeline and with minimal engineering rework.

Screenshot of an admin login management interface with user details, including email addresses, names, registration status, and last logon times.
Backend system we were leveraging for this project.
Research & Discovery
Getting Grounded in Constraints and Capabilities

I kicked off the project by meeting with our lead engineer and technical support specialist who had been managing the backend toggles. I mapped out what was technically possible and uncovered five toggle-able settings that defined each user’s access within an organization. However, I quickly learned that only three toggles were commonly used:

  • View shared projects
  • Purchase/consume shared inventory
  • Purchase from catalog
Understanding the users

To design effectively, we first needed to understand who would use sub-accounts and why. From CS tickets and sales conversations, three main persona groups emerged:

  • Cost-conscious clients who valued reduced administrative overhead.
  • Enterprise clients focused on security and compliance needs.
  • Legacy users who needed to migrate from the EU/UK system.

To keep the project scope manageable, we prioritized addressing the core need of sub-accounts, with the intention to iterate later and add features to reach parity with the legacy system.

Because sub-accounts controlled sensitive areas, such as access to PII, certifications, and billing, our early design exploration included mapping different feature combinations against levels of user access. Initially, it seemed feasible to expose flexible toggles that mirrored the backend. However, feasibility reviews with engineering revealed that some combinations (e.g., enabling shared projects but not shared inventory) weren’t technically viable without significant rework. Based on these findings, we streamlined the design by focusing on two core capabilities, using them as the foundation to define a small set of clear, practical roles.

Screenshot of an 'Add Admin Login' form featuring fields for First Name, Last Name, Email Address, and options to enable full project and catalog access.
Ideation & Concepts
Shifting from Granularity to Clarity

To gather some more ideas, I turned to competitive research. While tools like Figma offered extensive permission controls, they often overwhelmed users with complexity- something I had experienced firsthand. In contrast, Hotjar consolidated abilities into a few clear, role-based presets, creating a more intuitive experience.

Collage of user interface designs showcasing user management features, including member listings, permission settings, and an invite people form.

Inspired by this approach, I reframed our UX challenge: instead of exposing every permission toggle, we could define three clear sub-user roles that bundled permissions in a way that was technically feasible and easy to understand.

Proposed Roles:
  • Assistant – Limited permissions, view-only access to projects.
  • Practitioner (Independent) – Full access, but no shared content.
  • Practitioner – Full access, with shared projects and inventory.
A flowchart illustrating three user roles in a user management system: Account Owner, Practitioner (Independent), Practitioner, and Assistant, with details about their permissions and access.

This simplification reduced interface complexity, minimized error states, and drastically cut down on the documentation required to explain how permissions worked. Also, since the release of this project, Figma has also simplified their user management across products to a few roles.

Screenshot of user interface for adding sub-accounts, displaying fields for first name, last name, email, and permissions selection with project visibility and inventory usage settings.

At this stage, a large enterprise customer required sub-accounts to meet their company’s compliance standards. They began using the roles we had created, with Customer Support temporarily managing account setup on their behalf. This arrangement opened a valuable feedback loop: the customer provided direct input on the functionality of the roles, while also serving as an early tester for the upcoming UI features. As a result, we were able to gather frequent, real-world feedback early in the process, which helped us refine the experience before a broader rollout.

UI Explorations

With this decision made we began exploring how to surface the content to the user in the most intuitive way. We explored a few different visual options of how to allow users to view sub-accounts and add new ones. To make the final decision we based it on the data we had showing that most users infrequently added accounts, and most likely had fewer than 5 sub-accounts.

A user management interface showcasing sub-account management features with a list of users, including their names, roles, statuses, last active dates, and action menus for managing accounts.
Screenshot of a user interface for sub-account management, displaying two layouts for managing user permissions and statuses.

From exploring the pros and cons of varied approaches, we settled in on the expanding section mockup, reducing cognitive load on users and working well for adding a few sub-accounts. It also followed the style of adding users to MBTIonline teams, and was similar to adding users to projects, so should be intuitive for our users.

Stakeholder Buy-In & Go-To-Market Planning
Ensuring business value

Because the B2B Assessment platform charges $195 per user annually, stakeholders were concerned that introducing free sub-accounts might erode revenue. At the same time, free sub-accounts were critical for a few groups, international customers accustomed to this model on the legacy platform, and budget-sensitive industries (e.g., education) where adoption could otherwise be cost-prohibitive.

To address these concerns, we partnered with marketing and business analysts to review usage data. The findings were reassuring: only a small percentage of accounts globally used sub-accounts, yet those accounts generated over $1M in recurring revenue through ongoing assessment and report purchases.

As an additional safeguard, we launched the feature behind a feature flag. This gave sales and support control to enable sub-accounts only for customers who needed them, while also allowing us to reduce perceived risk while still meeting the needs of key customers.

Testing & Iterating
USER FEEDBACK

I built a Figma prototype and began ad hoc usability testing with coworkers across departments. Through these sessions, I discovered confusion around the role titles- particularly the distinction between “Practitioner” and “Practitioner (Independent).” Based on user mental models developed with our product, “Practitioner” already implied independence, making the “Independent” label redundant and “Practitioner (Shared)” unclear.

We adjusted the naming to better align with user expectations:

  • Assistant
  • Practitioner (Shared)
  • Practitioner

This change brought immediate clarity during follow-up tests and helped cement a shared language we could use across the org.

Image of a UX design interface showcasing user permissions for project collaboration, detailing roles like Assistant, Practitioner (Shared), and Practitioner.
Handoff
Engineering walkthrough

I held a call with the front- and back-end engineerings working on this task to walk them through the updated designs, where they confirmed feasibility and that the interactions were supported by the database. We ensured all edge cases were documented and designed for. This covered the possibilities of new users being added, users being sub-accounts for multiple organizations, or any issues that may occur in the registration and invite process.

A user management interface displaying a table for sub-account management with user permissions and status for various accounts.
Screenshots of a user management interface depicting the sub-account management feature, showcasing the view before and after adding a sub-account, and an email template for inviting users.
Release
Training

I partnered closely with our technical support specialist to ensure a smooth rollout across global teams. Together, we developed training materials and hosted live sessions to educate sales and support staff on how the feature worked, how to guide customers in selecting the right roles, and how to troubleshoot common questions.

We provided internal training and guidance materials on Confluence, and I ensured our Salesforce Knowledge help articles were live for internal and external use.

Outcome & Impact

A Seamless Experience with Instant Adoption.

✅ Early delivery: Shipped ahead of schedule despite backend constraints
💲 Ensured revenue: New capability ensured a large customer renewed their account
🔐 Improved security compliance: Eliminated shared logins and manual backend setup
🚀 Instant adoption: Enterprise users immediately began using the new feature post-release
💼 Global enablement: Key feature for migrating international customers off legacy systems
🤝 Cross-functional alignment: Solution was vetted and supported by engineering, support, and sales