← Back to projects
Authorization feature
Auth0 2018
What problem where we solving?
At Auth0 we had a group of what is called “Extensions”, applications or commands/scripts that allow our customers to extend the functionality of the Auth0 base product to server their particular use case.
Some of the core functionalities started as extensions and then moved to the core product. That’s the case of the Authorization extension, an application that allowed customers to manage their users access to their applications with groups , roles and permissions.
The Authorization extension proved to be providing great value to our customers but had some problems so we needed to move this feature to the core platform.
Team
Product Manager
Engineering Manager
Architect
Back end engineers
Full-stack engineers
Product Design Lead (myself)
Our process
We knew this feature was important to our customers and that there were a lot of technical limitations by it being an external application, but we didn’t know much about how where our customers using it exactly, what was working, what problems they were having with it. So we started with Customers interviews, we conducted between 2 and 3 interviews a week with customers from different sizes, and this helped us understand current pain points and our customers mental maps.
Opportunity Canvas, User Story Mapping and more
After some weeks of work we realized we needed to go back a bit and plan better. As a remote company, all our interactions happened via Slack, zoom, documents and wireframes, but this project needed us to get together. We met with the triad (PM, Engineering and Designer leads) and one of our Product Directors and Architect in one of our offices for a week to plan our MVP and future releases. For this purpose we followed the user Story Mapping framework by Jeff Patton.
The first thing we did was build an opportunity canvas to frame the problem space and answer the important questions of who are we building this for, what are their problems, how can we solve them, and how will we know if they get value from what we build. All our knowledge from the customer interviews we conducted before was extremely useful here and it was a great way to align everybody. Next, we built some basic personas to represent the most likely users of the system and their distinct needs. These were super quick sketches and weren’t intended to be deep, but they allowed us to think about the experience of using the product from different points of view. The personas were based on interviews we had with actual customers.
After our first day we reviewed our Story Map and realized that we were a bit biased by the solutions we already started working on before getting together and leaving a whole lot of possibilities out. So we brainstormed a list of other areas we could elaborate more and prioritized them to work on them the following days. We repeated the same process by doing opportunity canvas and story mapping and later moved the explorations to the bigger map and took turns reading the story map end to end, making sure it flowed evenly. Lastly we identified “delighters”, we looked for the big or small things that make the product feel great to use.
Next we worked on translating those stories for our MVP to wireframes, validated with users and moved to high fidelity.
We released the feature through an Early Access program to validate it in a controlled environment with 18 companies, where we got feedback and improved based on it to release to Beta. Lastly we enable it to all our customers to General availability.
← Back to projects