Context

To expand into regulated industries, our software needed to comply with 21 CFR Part 11, which governs how electronic records and signatures are managed. A key part of this compliance is User Management needs to control who can access the system, defining permissions, and ensuring security through authentication.

As the UX/UI Designer, my role was to translate regulatory requirements into a usable, practical design for scientists and administrators, while collaborating closely with engineers and the PM to ensure technical feasibility.

Understanding the Problems

The regulation itself is broad, covering everything from audit trails to electronic signatures. After a detailed review, we narrowed our focus to User Management, because every aspect of security flows from who is accessing the system and what they’re allowed to do.

This raised key design questions:

• How do we restrict access with roles and permissions?

• How do we enforce unique user accounts and prevent shared logins?

• How do we implement authentication and password rules that meet compliance but remain usable?

CFR Clauses and Design Considerations

To translate regulation into design requirements, I mapped each relevant clause to UX implications.

This exercise gave us a clear blueprint: instead of treating compliance as abstract rules, we could anchor each one in a concrete design decision that users would see and interact with.

Discussion with Internal Team

With this blueprint, I facilitated technical discussions with several stakeholders to define what we could realistically deliver in the first version.

We agreed on core features for release one:

• Login & Authentication – unique usernames, password creation and reset, strength validation, and change-password flow.

• User Management Page – create, edit, activate/deactivate, and search users.

• Predefined Role Permissions – Admin, Operator, and Support roles with clear default access.

We have allocated points for the next iteration.

• Custom Role Management – define, edit, and delete roles.

• Global Security Settings – rules for password and login management.

• Ownership Management – define protocol/advanced setup owners and handle ownership transfer.

• Session Controls – timeouts and duplicate login prevention.

By separating immediate must-haves from future features, we could deliver compliance fast without blocking progress.

PM Alignment

After defining the initial scope with the internal team, I discussed it with the PM to confirm priorities. Together, we agreed to:

• Provide three predefined roles (Admin, Operator, Support) since role management wasn’t ready yet.

• Define clear permissions for each role to control what they can and cannot do.

• Keep the workflow simple and ready for handover to users.

• Mark advanced features (custom roles, global security settings, ownership transfer) as excluded for this release, but planned for later.

This alignment gave us a clear boundary for the initial version: focused, compliant, and achievable within the timeline.

Designing the Solution

I translated requirements and scope into design artifacts:

• User workflows for positive, negative, and corner cases.

• High-fidelity mockups and prototypes for login, password, and management pages.

• A role-permission document that spelled out what each role could do.

• A design document for handover to development.

The Outcome

The first release delivered:

• A secure user management foundation with roles and permissions.

• Stronger authentication and password rules.

• Compliance coverage for critical 21 CFR Part 11 clauses.

It also gave customers in regulated industries greater confidence and positioned us to expand the system with more advanced features in future iterations.