Capital Rx: Identity Access & Management

Founded in 2017, Capital Rx is the fastest growing healthtech company in America. Capital Rx’s mission is to change the way prescriptions are priced and patients are cared for to deliver enduring social change. In summary, Capital Rx is a combo Pharmacy Benefits Manager and Pharmacy Benefits Admin.

The Identity Access & Management (IAM) module is a core part of Capital Rx’s JUDI software, allowing the creation and modification of user accounts and the permissions associated with them. There were two main goals:

1. Reorganize the IAM module to more easily onboard external teams, regardless of technical background (main stakeholders would be external dev teams and admins)
2. Eventually separate out the settings into a “Basic” and “Advanced” mode to prevent security/viewing mishaps and be a better user experience for both technical (external/internal devs) and non-technical users (admins), i.e. technical users could immediately jump to coding certain settings without the hassle of clicking through a multi-modal wizard (e.g. a JSON update) while non-technical users would be guided through relevant tabs and input fields.

Basic & Advanced views (Updated)

Basic view (Original)

Match Attributes (updated)

Match Attributes (Original)

Personas

• Internal Developers: originally, the IAM module’s only demographic were internal developers—users intimately familiar with the workings of the module as they were the team that created and coded it. However, as the company started to rapidly grow, this became an unsustainable approach as onboarding meetings became necessary, which took away from development time.
• Product Managers: come the Product Managers, who had varying levels of technical expertise. They became the point person for external teams. This was an interim solution until, eventually, the third persona would be non-technical Admins from external teams.
• Non-technical Admins (external teams): the eventual goal was to make the IAM module easily accessible and user friendly for admins to intuitively create users with templated permissions, similar to creating a user on a CMS (Content Management System) or an HR software solution, i.e. easy-to-create and guard-railed from any security mishaps.

Challenges

• Significant designer and PM turnover, leading to a mishmash of components used. When I became the lead designer on this module, nearly all components were custom and/or from an older design system, which often did not mesh well with the newer components in code or aesthetically. Additionally, the user experience was jarring when components worked differently than in other modules, e.g. tabs saving overall vs. in individual tabs.
• Module was maintained as an “internal dev” tool, proving to be unsustainable as Capital Rx gained more clients with increasingly custom requests for permissions
  • The organization of the navigation menu was lacking: there wasn’t a true reasoning to the order besides the order they were implemented, making no sense to users who weren’t the internal dev team working on IAM.
• Staging and the live site were two different sites. However, the two looked very similar and functioned nearly identically, which could temporarily disrupt the live site and/or accidentally cause end users to see data they shouldn’t be able to access.
  • There were user notification and approval flaws with the existing system.
  • There was at least one incident where an external client accidentally received permissions to view and access other Capital Rx clients’ information.

Solution

• Updating the components to be their latest versions while also updating the information architecture so users wouldn’t be confused by the different design patterns across different modules
• Reorganize the IAM module to more easily onboard external teams, regardless of technical background (main stakeholders would be external dev teams and admins)
  • Separate out the settings into a “Basic” and “Advanced” mode to prevent security/viewing mishaps and be a better user experience for both technical (external/internal devs) and non-technical users (admins), i.e. technical users could immediately jump to coding certain settings without the hassle of clicking through a multi-modal wizard (e.g. a JSON update) while non-technical users would be guided through relevant tabs and input fields.
• Add in large banners to warn certain high-level permissions users if they were on the live site vs. the staging site, and also adding in more guardrails, e.g. confirmation popups. Also adding in a more searchable/filterable log to see when a security incident happened and what account it was logged under

Result

The IAM module was going through an iterative overhaul. Old components were being filtered out and layouts were being modified to match design patterns across all JUDI applications. Further plans to improve the overall module navigation and information architecture of the IAM module itself had begun with diagramming work (via Miro) and discussions with the principal engineer and product manager.