Granular Scopes Overview

The introduction of granular scopes allows developers creating third party apps for Asana to specify what type of access their app needs. Therefore, any user authorizing a third party app would no longer be required to give access to their entire organization. This release would impliment this ability for developers to specify permissions (scopes) that are essential to an apps function. This reduces the overall security risk for users and organizations to ensure that apps are only gaining access to the information they truly need.

Problem

Security risk for enterprise clients: Asana apps pre-scopes require a user to give an app access to everything, a level of access few apps actually need. This is too much risk for many enterprise clients, causing them to block the apps.

User Types

Developers can configure permissions scopes during the app creation and registration process.
Admins & IT can review scopes in the admin portal, app detail pages, and Oauth consent screen.
End Users will be presented with scopes/permissions when attempting to authorize app integrations.

Effected Surfaces

Theres four primary areas this update impacts. The first is the developer console where the developers create and register their app so that it can be reviewed by Asana. The most important area is the Oauth screen which is where users approve an app for use, and then there are two app detail pages — one that lives in a public facing app gallery and one that exists in the admin console for admins to approve or deny apps for their whole organization.

Developer Console

We added scopes into our developer app creation flow in a section already available for setting up Oath settings, now devs would have a long list of scopes that could be applied and a search/filter bar to make it easy to find the right scopes to apply.

Oauth Flow

This screen is critical for all app adoption in Asana, it's a sensitive area with high traffic. This is where end users determine whether or not to approve an app. 

We did numerous rounds of UI design, content design, UXR testing, and pressure tested our iterations with real apps to ensure that our designs scaled with real scenarios.

App Gallery Detail Page

When users search for apps in Asana the majority will find them from the app gallery. When they choose which app they want they're presented with this screen. At the bottom is a list of the permissions required for the app to run, reformatted in our new styling.

Admin App Detail Page

When IT admins are evaluating which apps to allow in their organization, they use the Admin Console. Each app has its own page where permissions are listed for review before the app is approved or blocked.

Oauth UI Details

Oauth design involved a UI update, content organization, and lots of pressure testing. Content would be organized into a list format with matching iconography for easy scannability. These lists would be collapsed by default so users who are less concerned won't feel overwhelmed. At the bottom is a dynamic footer that changes based on specific criteria including whether the app has been reviewed by Asana, if other users in their organization have installed this app, or if they should take extra caution.

Before

After

Challenges

Authorization design is a delicate balance because we needed to be able to communicate potential risks to admins, IT, and any concerned parties so that they can make informed decisions. On the flip side, we don't want to discourage our average user from installing apps because of overwhelming warnings for apps that realistically pose no risk to them or their organization. 

This would emphasize extra care on how we present information, when to present different messages, and the type of language we use when we do so. Especially when we consider some of our apps requiring many scopes.

Warnings, Encouragement, and Social Proof

The footer of our new Oauth screen would display one of three ways depending on context: a generic encouragement if an app is low risk and Asana approved, a warning for domains where admins have specified install restrictions, and a social proof device encouraging users when more than 3 other users in their organizaiton have already installed.

Edge Cases

When looking at content groupings and testing, one of the key areas of focus was our apps with long lists of scopes. These apps account for a small portion of Asana integrations, but are in some cases heavily used. This would encourage us to examine our scopes groupings and permission levels to ensure they are legible in larger lists.

Additional Roadblocks

At a certain point in the process of nailing down our content strategy, two approaches were in front of us and there were differing opinions on which one to pursue. Specifically, should we format our content in the Oauth with more conversational language to break down content in a more friendly way for users or the list/table view that itemizes scopes for users.

Our Solution

We developed simple prototypes using both designs to perform unmoderated testing on a small test group of users. We would task users to navigate the prototypes and locate specific information and perform tasks that would allow us to gauge their ability and comprehension throughout. As an additional test we gave users a side by side and asked them to choose their preference, though subjective it provided us a unanimous result.

Results

Based on our tests we were able to move forward with a strong level of confidence in our designs. We used user insights to inform content grouping, UI, and language. These tests helped inform our stakeholders and align on a single direction for the Oauth flow.

Project Stage:
In Development