Giving enterprise customers control over who sees what
SCALAR's role model was too rigid for real organizations — 25 fixed roles, all-or-nothing, no granular access. I led the discovery and problem framing, defined the new role-and-permission concept, and guided the high-fidelity design. Now shipped.
Company
ZF SCALAR
Date
2025
Duration
4 months
Stage
Shipped
Role
Lead Product designer
Team
1 Lead, 4 Product Designers, UI Designer, Solution Architect, PM
Explore the full FigJam board to walk through the discovery, benchmark, and solution definition.
Company overview
The challenge
SCALAR is migrating enterprise customers off a legacy platform, and access control is where large organizations hit a wall. Customers like TIP needed to model complex structures — many users wearing several hats — but the platform only offered fixed, predefined roles.
The problem
SCALAR’s current role and permission model is too rigid to support real-world organizational needs. Users can only be assigned predefined roles, with multiple fixed roles stacked on the same user, resulting in an “all-or-nothing” access model. This prevents customers from defining granular permissions, enforcing least-privilege access, and accurately reflecting complex organizational structures.
Discovery
I led a mixed-methods discovery: stakeholder interviews to understand how customers actually structure access, and a competitor benchmark (Samsara, Geotab, Verizon Connect, Volvo Connect) to see how mature platforms solve it.
The takeaway
SCALAR had too many fixed roles and no granularity, while competitors offered scoped, customizable access. That gap was the brief.
Defining the solution
I framed the solution around three questions: who (roles), can do what (permission levels), and on which data (scope). The model keeps a small set of clear default roles, adds fully custom roles, and applies the permission levels already living in SCALAR's backend but never exposed to users.
Multiple roles per user — no more near-duplicate roles for every combination
Custom roles — admins tailor access without waiting on the product team
Feature-level permissions (none / view / full) — reusing what the backend already supported
Who
Can do what
On which data
We defined what each default user role can do, and on which data, in the FigJam board.
Validation and testing
We validated the journey and wireframes internally across the team, iterating before going external. I then guided the UI designer through the high-fidelity screens, and we ran a final test with three large customers. The model held up — it mapped cleanly to how their organizations actually work.
High fidelity
Once the model was validated, I guided the UI designer through the high-fidelity screens. Below is the flow for adding a new custom role — from the roles overview to defining feature-level permissions (none / view / full) for the new role.
Impact
The new role and permission model is now shipped. It replaces 25 rigid roles with a flexible system customers configure themselves — reducing the operational cost of adding fixed roles for every request, and giving enterprise customers the scoped, least-privilege access their structures require. Roles are no longer something SCALAR adds to the product; they're something customers build.