Adding a major feature to an existing product

Design challenge

Before we started working on our “Organizations” feature, our enterprise customers could create APIs and API packages which could then be accessed, modified, or deleted by any employee with an administrator account. The design challenge was to design a feature which would let customer administrators define Organizations and sub-organizations, define ownership of system objects like APIs, and then indicate which users had access to which Organization.

This was the user interface before we added the Organizations feature

It seems pretty simple here, all we did was add a new column. But there was a lot more to it!

Our goals for this feature were:

The feature should be simple and flexible so that any customer can use it regardless of size or shape.
The UX should support the user in making decisions that they understand and feel confident about. Since confidentiality and access to resources is of critical importance, the ability of users to understand what they’re doing and what has already been done is of critical importance. The UX should never create a situation where ownership or access to a resource is unclear, ambiguous or misleading.
The impact on the existing UX of the product should be minimal, so that the feature can be turned on or off at will.

Design process

I worked closely with Product Management, Engineering, and Customer Success on all aspects of designing the feature both in terms of how it works and the user’s experience.

Illustration that I made to communicate the conclusions we reached

‍

I collaborated with the Customer Success team to work with customers to learn about how their organizations are structured and their needs were for designing access control, and then tested the designs with them to ensure we were meeting our project goals.

I worked with Product Management and Engineering to understand the existing system and how it worked, and the impact that the new feature would have. We examined how the new concept of ownership would affect everything a user could do and create, and what affect making changes to ownership would have down the line, both technically and in terms of user cognition. This was critical to ensure that my designs were feasible, realistic and effective.

This is how I determined the best language to use

Sometimes it's faster and more effective to write something out instead of focusing on making it pretty

In this project I created an Axure prototype that allowed me to demonstrate and test a realistic experience, from setting up organizations, to assigning user roles, and then seeing the filtering of objects from view. This helped all stakeholder groups imagine and work towards the same goal.

I designed this interactive prototype to show how roles would be displayed, added, and removed

In the course of the design I determined that global updates could be made to the UX to make the entire interface more organized and easier to use. These updates were all implemented due to my advocacy.

Why UX was important in this project

I made this illustration to explain to the Product team why it was important to let me help them design this; it worked!

‍

Outcome

This feature has been available for customers for several years and we have got excellent feedback. Recently a customer success team member who was wondering if it was possible to set up read-only access only for certain user roles, which technically we could not support, but which I was able to describe a workable solution using the existing feature. The flexibility of the feature allows it provide value even in ways we didn’t think of when designing it.