View Data Permissions

Problem

In KickUp’s platform we have a concept of an “instance”. An instance has:

• a form that people can fill out and
• a list of observers (users who can fill out the form)

Each observer has a list of people they can fill out the form for – we call this list their “roster”. Critically, an observer can only see the data of people on their roster.

Principals were a good example of users who needed access to all data within an instance, but didn’t need to fill out any of the forms. Since we didn’t have a way to grant them permissions, we were just adding the principals as observers and setting up their rosters to grant them access to user data. The process of adding them to the instance was the same as adding an observer and wow wow wow it was time consuming. At times, setting up a district could take up to 2 hours for a single school district.

Research & analysis

The workaround for granting data access permissions quickly became a friction point as larger and larger school districts were onboarded onto our platform. The client success team surfaced the frustration and inefficiencies with the current workarounds and the product team decided we needed to address it.

The product team identified the key personas as principals and curriculum and instruction leads. Efficiency and user-friendliness were also identified as key requirements for this feature due to the repetitive nature of granting permissions and the time-consuming nature of the current workarounds. Since we compete with legacy ed-tech platforms that are clunky and overly-restrictive, people expect and hope for a smoother and more streamlined user experience with KickUp.

Design process

The design process started by spending time understanding the requirements and research. The problem space was largely just a configuration problem, since the result of granting these permissions would be that a “data” tab shows up and can be navigated to.

In the first design iteration, I started by reviewing some designs from a previous project that we originally wanted to use as the basis for this feature. The previous project allowed the granting of a single permission, but it was clear that the UI wouldn’t scale well to multiple permissions. So, we had an idea of a dialogue modal which would let you search for and select a user, select the permissions, and then grant the the selected permissions to the selected user.

I got feedback that this was still going to be time consuming since you had to grant permissions 1 user at a time. So, using Coda's sharing feature as a reference, we had an idea of making the search input more like a multi-select input. After searching and clicking on a user, it would select them and they'd show up as a tag in the input. You could then keep searching and add more people, but no permissions would be granted until you pressed the "grant permissions" button. This way, you could select the people you wanted, select the permissions, then grant them. I tested this design in a Figma prototype.

Coda reference and updated design

There was some feedback that email addresses were important to surface, since in some large school districts two people can have the same name. So, rather than displaying selected users as tags, we changed to a list UI for selected users. This way we’d have more space to display the name and the email. At this point in the process, I switched to building to a code prototype. The ability to search users, select users, and grant permissions would be much easier to visualize if you could actually use it.

In the prototype exploration, I found that selecting a large number of people would quickly make the dialogue modal tall and you'd have to scroll to select the permissions or click the "grant permission" button. We came across an idea to make the list of selected users be a nested scroll container. This way, you could select 100 people and the modal would stay the same size. With this nested scrolling though, we wanted to add an indicator that there were more people selected than only what you could see. I experimented with showing a "23 selected" number somewhere, but it still wasn't clear that you could scroll. Ultimately, I added an overlay and badge to the bottom of the scroll container that said something like "7 more". This both informed you that there were more items to be seen if you scrolled and also told you a general number of how many users in total were selected.

React prototype

After sharing the prototype with a team of stakeholders for feedback, it was time to run through the Design QA checklist . Design QA is a process I use to ensure that the design spec I’m delivering to engineering:

• Meets functional and accessibility requirements
• Captures edge cases, different permissions, feature flags, and various application states
• Is tidy and clear, explaining how screens flow together

I also use this document to call out any remaining open questions and any new frontend components that we’ll need to build for this project.

Solution & results

The final solution was a “Grant permissions” modal that lets you

• search for and select individual users or bulk select users within a group
• select the permissions you want to grant and
• easily grant all selected permissions to all selected users.

This solution will obviate the need to add principals as observers and will make access management more scalable, reducing the time and effort required to give people access to view the data they need to see.

Conclusion & lessons learned

This project had a lot of trade offs. There were a few technical conversations we had related to to bulk granting permissions for groups, and the decision we went with definitively has its drawbacks. It was a decision mostly driven by technical debt, which makes it feel like a bandaid solution in some regards. That said, the solution will still save many people time and result in much simpler permission management.