Designing Access People Can Trust
Evolving a basic access model into a platform-wide system where customers could confidently manage who had access to what.
The Challenge
Like many enterprise SaaS companies, the product portfolio had evolved as a collection of separate offerings, each supporting a different part of a customer's cybersecurity programme. As the strategy shifted towards becoming a unified platform, one of the most fundamental problems was also one of the least visible: access.
A platform needed a single way to sign in, but a single login was only useful if customers could also manage access consistently across the products behind it. That meant moving away from separate product-level experiences towards a shared model for users, roles and permissions.
Access control is also a table-stakes capability. Customers rarely buy cybersecurity software because of its user management experience, but they expect it to be secure, predictable and easy to understand. When it works, it disappears into the background. When it doesn't, the consequences can be significant.
That made research particularly important, and particularly difficult. Customers could tell us they needed more granular control, but understanding how they expected access to behave required looking beyond feature requests and stated preferences to how they actually configured, interpreted and verified access.
The challenge wasn't simply giving administrators more control. It was making complex access understandable enough that they could trust the decisions they were making.
Understanding the Problem
Access control started with a deliberately simple goal: one login, with one place to manage access across the platform.
But access needs don't stay simple. As the platform and its customers evolved, the model had to evolve with them. I led the design of the access model through several major evolutions, introducing new capabilities as customer and business needs became more sophisticated.
Over several years, that meant repeatedly asking the same fundamental question in increasingly complex contexts:
Who should have access to what, and how do we make that unmistakably clear?
Access evolved with the platform
Unify access
Single login and a shared way to grant access across previously separate products.
Enable basic account security
Support customisation of password policies and MFA settings to improve account security.
Support complex accounts
Extend the access model across customers with multiple organisations.
Enable access requests
Allow users to request products they couldn't access, start trials where permitted, and give administrators somewhere to review and act on those requests.
Manage access through groups
Move beyond configuring every user individually by enabling administrators to manage shared access patterns.
Integrate enterprise identity
Introduce SSO and identity-provider driven access for organisations managing users outside the platform.
Rethink the interaction model
As the platform grew, earlier patterns stopped scaling. Multi-step workflows across products and organisations had become slow and cumbersome, while the wider design system had evolved around them.
Make conflicts understandable
Access could now be inherited from different places. Individual and group permissions could conflict and, because the system defaulted to the lowest permission, unexpected combinations could cause users to lose capabilities.
Multi-tenant access
The same access foundations eventually had to support users operating across entire customer estates.
Each addition solved a real customer need. Together, they created an access model far more powerful, and far more complex, than the one we started with.
My Role
I joined the programme as a Senior Product Designer and led the design work required to move from separate product experiences towards a shared platform access model.
For the first five years, I was the sole designer responsible for Platform Access Control, leading the experience through multiple generations as the platform and its customers became more sophisticated. I worked closely with Product and Engineering throughout that time, building deep shared domain knowledge and evolving the model together as new access needs emerged.
My work spanned interaction design, customer research and usability testing, alongside the less visible work of modelling permissions, edge cases and system behaviour. Because access control crossed product boundaries, decisions often required balancing customer expectations with security requirements, technical constraints and the needs of individual product teams.
As the programme entered its next major evolution, I brought a more junior designer into the work. Over the following three years, my role shifted towards supporting their ownership: helping them build domain knowledge, facilitating research and workshops, providing design direction and critique, and giving them the context and support to lead increasingly complex parts of the experience.
Measuring the Expected
Access control is a foundational capability, but rarely the reason someone buys a cybersecurity platform. Customers expect it to be secure, understandable and reliable, and ideally they spend very little time thinking about it.
That makes traditional product metrics difficult to interpret. More engagement isn't necessarily a positive signal, and more time spent managing permissions may indicate complexity rather than value. Success often means completing an infrequent task correctly, understanding the resulting access, and moving on.
I used a combination of sentiment, behavioural data and task success to understand these experiences rather than relying on a single measure. For example, before redesigning access conflicts, I established a baseline across customer satisfaction, time spent within the experience and the proportion of administrators encountering it.
When satisfaction and behaviour disagree
The importance of combining these signals became particularly clear while testing a new data-access model. The customer need was strongly validated: all seven participants could describe situations where they needed to restrict access to specific data.
When asked how well the proposed design met their needs for managing access, participants gave it an average score of 8.2 out of 10.
Their behaviour told a very different story.
Six of the seven participants needed help to complete the flow, despite reporting that the task itself felt easy. The underlying access states were also poorly understood: five of seven participants couldn't correctly interpret the different levels of access from the interface alone.
This became an important principle in how I evaluated access-control experiences: confidence had to be demonstrated through behaviour, not just reported through feedback.
Customers could value a capability, understand its purpose once explained and rate it highly, while still being unable to configure access correctly. For foundational experiences like access control, sentiment mattered, but it needed to be considered alongside comprehension, task success and behavioural data.
Reflection
Over years of working on access control, my definition of success became increasingly simple: customers shouldn't have to think about it.
They should be able to give the right people the right access, understand the result when they need to, and trust that the platform will behave as expected. The complexity of roles, groups, data permissions, identity providers and conflicting access shouldn't become their complexity to manage.
Achieving that simplicity required increasingly sophisticated design work behind the scenes. Every new capability introduced new relationships and edge cases, making it more important to understand how customers behaved rather than simply asking whether they liked a feature.
Ultimately, the goal was to let customers get on with the job they actually came to the platform to do.