Amplitude Data Access Controls
Created a data access control system that increased enterprise deals
A restricted chart view when a user doesn’t have access to sensitive data
Role
Lead designer, researcher, and product strategist
Team
Collaborated with a core team of PM and engineers, and facilitated alignment with every product team
Skills
User research interviews, Information Architecture, Enterprise UX
The Problem
The rapid pace of Amplitude growth left customers with a disjointed product experience. Customers could not limit which users had access to sensitive data across the platform, which limited product usage.
The product
Amplitude began as a product analytics tool and expanded to a digital analytics platform with several product areas to gather insights and take action based on customer data.
Existing product areas for the initial launch
Enterprise and privacy-conscious customers needed more granular access controls to remain compliant with privacy laws and business regulations. Existing capabilities only allowed data restrictions by projects. When a user has access to a project, they have access to that data across the platform and all product areas.
How a customer maps their product’s data in Amplitude
Customers wanted to be able to restrict access to events and properties within a project. For example, a PM for Product A (Project A) should have access to revenue data but not PII data.
The competition
Many customers mentioned a wide range of products with more robust access controls. This included direct competitors (Adobe Analytics and Mixpanel) and data-heavy tools (Tableau and Salesforce).
Competitor examples of managing data access controls
Approach
Empathize with customers to learn what they need
We worked with Enterprise Customer Success Managers to identify eight customer development partners. I led discovery interviews and tested design concepts to refine the solution.
A design concept I tested with customers
Key Insights
- Most customers only need three default classifications: PII, Sensitive, and Revenue.
- Customers needed flexible and robust controls to limit access that maps to their org structure.
- The disjointed workflow between permission groups and data management is unfamiliar to users.
A visualization to analyze research insights
Persona map that emerged from customer calls
Balance the conflicting needs of different users
Restricting data access to adhere to compliance could impact the experience for end users. How might we balance a customer’s need to be compliant without eroding the value of the platform for end users?
A diagram to visualize the admin and end user experiences
I collaborated with every designer on their product area to create a system that provided clarity to the end user.
Design an intuitive experience for admins and end users
Admins needed to be able to classify data, create permission groups to limit who has access to sensitive data, and easily manage access controls.
Workflow to classify data as PII, Sensitive, or Revenue
End users needed the restrictions to not interfere with their workflows of gathering insights. If they didn’t have access, they needed to know why and be able to request access.
View of a chart for a user without access to sensitive data
Admins needed a scalable solution to manage access for a large number of users.
Admin view to manage data access controls
Design a system that is future proof
After facilitating workshops and collaborating with every product team, I realized that teams needed a framework to use as a guideline for how to incorporate data access controls in new features.
The Impact
Launching Data Access Controls impact on the business in multiple ways:
Retained multiple enterprise customers
Convinced customers to upgrade their plan and expand platform usage
Landed new enterprise customers
Customers in privacy-conscious industries quickly adopted the feature
“DAC is the most used acronym of the year”
Learnings
This project uncovered many technical architecture limitations that inhibited an intuitive user experience. Timelines kept shifting. In hindsight, I would have asked more questions about technical constraints early on so that we could have escalated to leadership earlier.