Data Portal - Request Access

CVS

Overview

Users wanting to use different data provided in Data Portal must go through a governance process to be approved. At this point the Data Portal is set up in an e commerce manner in order to support the future enhancements of cross division data sharing. Certain cross division sharing will need to provide payment or have a number of credits to use certain data.

Once a user finds a piece of data they wish to access and use they must go through the access request flow. This flow will show different access control groups that can grant access. The user must select a control group which they will fit into and give a business justification to see if they qualify to be granted access.

 

Where we started

The Problem

Users are requesting access on any level of data, however when you request access on a child you are actually requesting access for the entire parent schema. There is not enough information to make a good decision on which group to correctly request access through. On the tech side the problem was different types of data were set up differently so the metadata on which you would choose to gain access through was not consistent across all data thus making the scalability of this current design not feasible

MVP - Request access request step 1

MVP - Request access request step 2

MVP - Request access request step 3

 

Competitive Analysis & User Feedback

I was able to track down the governance side of multiple different types of data to see what metadata was presented for users to make a decision. Then I grouped items of similar models.

  • Control group

  • Permissions

  • Restrictions

I put together some quick wireframes to get feedback from users. After understanding the vastness and just how many items you can request access through (over 100 per data point), it became clear the problem wasn’t just that users needed more information to make a correct decision, they also needed a filtered down list to what would be useful to them based on their user profile.

I was able to partner with the engineers closely to pull the correct metadata from the users profile based on their log in to the Data Portal and create a matrix of access they could see vs. key metadata from their profile. This brought the number of choices down significantly.

Through the user feed back I was also able to put in perspective that the top tier of data is grouped based on projects. However there is and experience gap when a user switches from one project to the another, they can be on a project for weeks without their profile being updated.

Therefore I couldn’t put the project into the matrix of access. Instead I needed to bring a visual element to give the user control. The project dropdown menu allows users to choose which project they are working on.

For this iteration I wanted to start easing the user into the understanding of the hierarchy that their data lives in. I implemented an easy to develop notification bar at the top of the page.

 

User testing

After making updates I ran a few moderated user tests to validate and get feedback.The access request process was improved greatly but there was still one part that every user touched on and that was current access.

This is how I landed on the table display for the access request. This way I can show what you already have access to and what you don't. I was also able to work in a pending access status as I learned from previous experience there can be a time lag.

 

Final design - Request access

 
 

Next Steps

  • Create a governance process where the business justification given has enough detail to understand if the user should be granted access.

  • A way for owners of access groups to add/create new access groups with different permissions and restrictions