Case Study
Bringing Structure to Stratly: Redesigning Roles Management
Product Designer - Stratly
Feb, 2025
Product & Problem
Stratly is an enterprise B2B fundraising and financial data platform serving nonprofits. Stratly’s original permission system was hardcoded. Developers had to manually update the codebase just to give a staff member "view-only" access. As we scaled to enterprise clients, this became a bottleneck. I designed this centralized Roles Management system to give admins full control, allowing them to define exactly who can see, edit, or delete sensitive data across the platform.
My Role & Contributions
I led the product design for the roles and permissions architecture from initial concept to production. My objective was to replace the hardcoded backend logic with a scalable, centralized interface that gave administrators full granular control over sensitive data access without requiring engineering support.
Key Design Decisions
Granular Permission Trees & Role Inheritance
To move away from simple binary roles (Admin vs. User), I designed a granular permission tree that separates access at the module level (e.g., "Donations") and the action level (View, Edit, Delete). To accelerate setup time and ensure organizational consistency, I introduced Role Inheritance. Administrators can select an existing template and modify only the necessary nodes, reducing configuration time from minutes to seconds.
Safe Deletion Guardrails
In data-heavy systems, deleting a role introduces severe security risks and the potential for orphan accounts. I engineered a "Safe Delete" flow to intercept destructive actions. If an administrator attempts to delete an active role, the system acts as a strict guardrail, forcing the user to bulk-reassign all affected profiles to a new role before the database deletion is allowed to execute.
The Guardrail: The system intercepts the delete action if it detects active users assigned to the role, preventing accidental data loss or "orphan" accounts.
The Resolution: Before deletion can proceed, the admin is forced to reassign affected users to a new role, ensuring continuous access and security compliance.
Optimizing for Power Users
Knowing the permission schema would expand rapidly, I integrated a dedicated search architecture directly into the role editor. Instead of forcing administrators to navigate deeply nested accordion menus, they can instantly query specific micro-controls like "Export Reports," bypassing UI friction completely and keeping cognitive load low.
Engineering Workflow & Handoff
To ensure the complex permission logic was accurately reflected in the UI, I maintained tight alignment with the backend engineering team. I provided detailed state diagrams and edge-case documentation alongside the Figma UI specs. We conducted weekly design QA sessions to map the new UI components directly to the updated API endpoints, ensuring the visual states mathematically matched the database rules before merging into production.
The Outcome
Restructuring the hardcoded permissions into a centralized, scalable architecture delivered immediate operational improvements:
80%
Support Reduction
Cut access-related support tickets by over 80% by giving administrators direct, error-free control.
99%
Task Efficiency
Raised administrator task completion rates for complex role assignments to near 99% by utilizing Role Inheritance templates.
System Scalability
Eliminated the engineering bottleneck, allowing the platform to securely handle complex, multi-branch access models without developer intervention.
Challenges & Trade-offs
The most significant challenge was mapping legacy user data to the new granular permission tree. We could not simply overwrite the existing binary roles without risking access lockouts for active users. I had to design a transitional mapping phase where legacy "Admin" and "User" profiles were automatically converted into custom template roles. This ensured continuity of access while forcing all new role creation to use the upgraded granular architecture.