CONTACT
C3: Roles &
permissions
A deep dive into how I redesigned the access architecture of C3, eliminating a separate admin system, building a scalable permissions framework, and connecting role logic to every layer of the product.
Year
2024
Role
Senior Product Designer
Scope
Product Strategy, UI/UX, Prototyping, Design system
context
C3 is a B2B omni-channel platform where support and sales teams manage customer conversations across WhatsApp, Messenger, Instagram, and Email from one unified inbox.
Three user types. Two separate systems. No defined rules for who could do what.
Problem
Two dashboards. Three roles. Zero logic.
The Superadmin operated from a fully separate login interface, disconnected from the main product entirely. Inside the main dashboard, Admins and Agents had almost identical access. There was no system connecting what a role meant to what a user could actually see, do, or control.
The result: agents accessed settings they had no reason to touch.
Admins had no structured way to control who replied from which channel. And the Superadmin had no visibility into live operations because they were locked in a separate system.
Investigation
C3 is a B2B omni-channel platform where support and sales teams manage customer conversations across WhatsApp, Messenger, Instagram, and Email from one unified inbox.
Three user types. Two separate systems. No defined rules for who could do what.
Stakeholder & Developer Interviews
I spoke with stakeholders and developers to understand the real-world impact. Three consistent themes came up: Admins were managing agents manually with no structured permission controls. Developers were hard-coding access rules because no design system existed for it. Bringing a new agent onboard meant a full manual briefing on what to avoid touching.
Step 2
Add your second investigation step content here.
Product Audit
I started by auditing C3 myself navigating every section as each user type, documenting what was accessible, what was blocked, and what should have been blocked but wasn't. The audit revealed the full scope of the problem: it wasn't one broken feature, it was a missing layer across the entire product.
Designing one system, clear permissions, and defined roles.
Text 3
C3 is a B2B omni-channel platform where support and sales teams manage customer conversations across WhatsApp, Messenger, Instagram, and Email from one unified inbox. Three user types. Two separate systems. No defined rules for who could do what.
Text 3
C3 is a B2B omni-channel platform where support and sales teams manage customer conversations across WhatsApp, Messenger, Instagram, and Email from one unified inbox. Three user types. Two separate systems. No defined rules for who could do what.
Any thingxt
C3 is a B2B omni-channel platform where support and sales teams manage customer conversations across WhatsApp, Messenger, Instagram, and Email from one unified inbox. Three user types. Two separate systems. No defined rules for who could do what.
Three roles. Zero overlap
Before designing any screen, the three roles were mapped out and renamed to better reflect function, Superadmin became Admin, Admin became Supervisor, and Agent stayed Agent.
VALIDATION
Before handoff, stakeholder reviews validated the role logic. One refinement: campaign deletion moved to Admin-only after flagging the risk of accidental data loss.
Loom walkthroughs were recorded for the engineering team covering the permissions matrix, role creation flow, and UI response rules, serving as the full technical handoff documentation.
IMPACT
1 system eliminated, Superadmin dashboard fully deprecated.
3 roles redesigned with clear ownership and named functions.
6 feature areas covered by the permissions matrix.
67% reduction in misdirected settings access during internal testing.
3× faster role setup compared to previous manual process.
~40% reduction in new agent onboarding time.
100% of feature actions now governed by role-based permissions.
Reflection
The hardest problems have no UI surface. The roles problem was invisible on screen, you couldn't see it by looking at the product. You had to map the system to find it. Always audit before you design.
Naming is design. Renaming Superadmin → Admin, Admin → Supervisor wasn't cosmetic. It changed how every stakeholder thought about the system and made the permission logic instantly easier to communicate.
A permissions matrix is only as good as its UI response. Designing the matrix was 40% of the work. Designing how every corner of the product responds to it, disabled buttons, hidden tabs, redirect states was the other 60%.