Building a No-Code Access Granting Tool

Data security is a huge concern for organizations with sensitive information. In order to protect their data, these organizations typically employ data owners - users who oversee a given set of data, maintain its quality, and set up permissions to ensure that only certain people can access it.

Okera aimed to streamline this process by giving data owners a single place to manage their data and grant access to it. However, in 2019, data owners were having difficulty granting permissions in the Okera UI. I spent 2 years working with an Agile team to iteratively develop a new permission management tool that would meet users’ needs and keep customer data secure.

Problem Discovery

Data owners weren’t using Okera to manage data access.

In early 2019, data owners had adopted a deeply inefficient workflow. They were using Okera to organize and make edits to their data, but weren’t using Okera to manage data access. Instead, they were manually writing out spreadsheets of required permissions (e.g. grant the user ‘sales_manager’ access to the ‘sales’ database ) and tasking engineers with implementing these permissions.

This process was slow and it often took customers a long time to make changes to data access, which frustrated analysts and data scientists who needed this access to do their jobs.

Additionally, data owners are security experts - they know better than anyone who should and shouldn’t have access to a given set of data. If an engineer made a mistake implementing permissions, the mistake might not be caught for weeks. Thus, this process also threatened data security by making it harder to spot potential breaches.

Okera’s product team talked to customers to figure out why data owners weren’t using the available access management functionality. The answer soon became apparent.

The existing access granting workflow required specific technical knowledge that data owners lacked.

The access granting experience was very barebones. Users could only write, edit, and delete permissions by typing the relevant SQL command into a text box. Users therefore needed to have some degree of SQL proficiency to create or change a permission. 

My product manager found that data owners were often inexperienced with SQL and therefore did not feel confident writing permissions, especially when these permissions were complex or vital to data security. Because of this, data owners were outsourcing permission creation to more technical users like engineers.

I was brought in to design a new access granting feature that didn’t require any SQL and could thus better meet the needs of data owners. We would know that we had been successful in designing this feature if these criteria were met:

• Widespread adoption: The new feature should be adopted by the majority of Okera’s customer base, where adoption means at least one data owner at a customer company is regularly creating permissions with this feature.

• High user satisfaction: Users should report high satisfaction in surveys and provide positive qualitative feedback on the feature.

Defining User Needs

I conducted exploratory research to identify key requirements.

My product manager and I set up calls with 4 data owners and had them describe their responsibilities, their workflows, and what their ideal permission creation experience would look like. I also reviewed some old interviews conducted by my product manager to better understand these users. Based on this research, I identified three key needs.

1. Users need the ability to create very complex permissions.

Though most data access was fairly simple, data owners sometimes had to write highly complex permissions with a number of caveats and exceptions.

One major benefit of the existing permission creation workflow was that SQL is an incredibly versatile language, so users could essentially write any permission they could imagine.

Users expressed concern about losing this ability and stressed that any potential permission creation tool must account for this complexity.

2. Users need insights and context to feel confident.

A consistent theme in user calls was the desire to feel more assured when writing permissions:

Users felt uneasy granting permissions today because the SQL workflow didn’t provide them with any sort of feedback if they made a mistake (beyond a basic syntax error).

Since many of our users worked for companies with highly sensitive data, they wanted to be as confident as possible that their permissions were accurate, secure, and did not conflict with any other existing permissions.

3. Users need a simple UI that provides clear steps.

In calls, users expressed feeling generally overwhelmed by their options when creating permissions:

The current UI didn’t provide any basic scaffolding around permission creation, so users frequently lost track of where they should add certain statements and conditions. These users repeatedly commented that having permission guidelines in the UI would be helpful.

Conversely, other users expressed concern that a potential permission writing tool might easily become too complex, as it would have to deal with highly specific permissions. Either way, it was clear that users desired a straightforward UI that provided some guidance around permission creation.

Now that I had a good sense of users’ requirements for this new tool, I got to work designing it.

Initial Design

I led a design sprint to create an initial concept.

My product manager, another UX designer, and one of our lead engineers sat down with me for a 5-day Design Sprint. The goal of this sprint was to generate some options for the new permission creation UI and ultimately choose one to flesh out and test.

I kicked off the workshop by reviewing the user needs above. We then looked at how other applications were solving the issue of permission management and discussed what we liked and didn’t like about these different approaches. Next, we spent a day sketching and voting on the ideas we liked.

We agreed early on that users should have to type as little as possible when creating permissions. Instead, they should select permission components from menus - like filling out a form.

Working off of this idea, we iterated on many different options before landing on a final design to start testing:

I went with this specific design because it combined multiple features that the team liked during our brainstorming session:

• The clear delineation of permission sections (data, access, role) allowed users to construct permissions in a guided, step-by-step way.

• The horizontal layout of the sections was reminiscent of writing a sentence. Since permissions were presently expressed as “sentences” in SQL, we assumed this would map well to user mental models.

• It included a lot of context to increase user confidence, e.g. a permission summary.

We tested this concept design with 4 users and 3 internal experts. Results were mixed:

Users responded well to the overall concept, and their critiques could be easily addressed in a redesign, so I began planning for an MVP release.

MVP Release

I refined the design according to feedback and MVP requirements.

Since this new tool would be a major design and development investment, the engineering team and I agreed that it would be best to start with an MVP and then make iterative updates to the feature over a series of short releases.

I first worked with my product manager to decide on a set of MVP requirements. I then updated the design based on these requirements and the previous user feedback.

We released this feature in Fall 2019 and called it the Permission Builder:

This MVP was very simple. Users could grant read-only access to a limited set of data objects. They could also apply basic tag conditions and see a text summary of their access before granting.

I made several updates to the design based on feedback, including switching to a vertical UI for improved readability, moving the summary to the right of the screen where it was more visible, and getting rid of unhelpful fields like name and description.

I also reduced visual clutter by simplifying the copy and removing unnecessary visual elements, e.g. replacing the ‘add another role’ button with a simple dropdown menu. However, the cleaner display was mostly due to the stripped-down MVP requirements. I would later have to figure out how to keep the UI simple as the feature scaled up in complexity.

I conducted a survey to benchmark feature success.

Before the MVP release, I created a survey to track the progress of our goals around adoption and user satisfaction. The survey asked users to rate their agreement with various statements on a 5-point Likert scale (with 1 indicating strong disagreement and 5 indicating strong agreement). These statements included:

• ‘I can create a simple permission in Okera with no assistance.’

• ‘I feel confident that the access I’m granting is secure.’

A few months after the MVP release, I sent out this survey again to measure progress. This second survey included two new prompts:

• Rate your agreement with the following statement (1-5): ‘I can use the Permission Builder for all my major access use cases.’

• Rate your overall satisfaction with the Permission Builder (1-5)

Lastly, we measured adoption by checking how many users at each customer company had created permissions with the Permission Builder.

Post-MVP metrics were low but provided promising insights.

Results showed middling user satisfaction and minimal feature adoption:

• Satisfaction was rated somewhat low at 2.0/5

• 0 out of 4 customers had any data owners regularly using the Permission Builder to create permissions

These results weren’t unexpected for a relatively simple MVP and would work well as a benchmark for future improvement. The additional survey questions showed where we were and weren’t meeting our three key user needs:

✅ Provides a simple, guided UI. Despite poor metrics, agreement with the statement ‘I can create a simple permission in Okera with no assistance.’ rose from a 2.5 to a 4.1. This indicated to me that the Permission Builder was fundamentally usable, if only for very simple scenarios.

❌ Doesn’t allow for complex permissions. Use case coverage was rated low at 1.7/5. Even if users liked the basic idea of feature and found it usable, it didn’t allow them to complete most of their work.

❌ Doesn’t inspire user confidence. User confidence in permission creation rose from 1.5/5 to 2.3/5, but this overall score was still low. Users needed to see more than just the permission summary in order to trust that their access was secure.

I reviewed these results with my team. We agreed that the MVP had proven the value of the Permission Builder. We now needed to focus on improving use case coverage and user trust.

Design Iteration

I first focused on accommodating more complex use cases.

My product manager and I decided to tackle permission complexity first. We documented all known access use cases and prioritized them according to importance and ease of implementation. Our highest priority requirements were:

• Users can grant any access type (not just read-only)

• Users can grant access to any data object (not just databases and datasets)

• Users can transform the data they grant access to, i.e. grant access to a dataset but anonymize/mask all sensitive data

• Users can specify which user attributes get access, i.e. grant access only to users with the attribute ‘manager’
  
  

I started with some minor design updates.

The first two requirements were very simple.

To expand access type coverage, I added an Access section with a dropdown menu of available access levels .

To expand the available data objects, I introduced a new dropdown menu called ‘Scope’ that allowed users to select from different data objects.

In each section, I included some explainer text clarifying what each access level and scope meant in order to improve user confidence.

I updated the copy to feel less “sentence-y” (a model users had rejected) and updated the visual designs to make role, access, and data seem more like their own separate sections.

I added a new section for access conditions.

I next had to incorporate data transformations and user attributes. Early on in the concept phase, my team and I had come up with the idea of access conditions, meaning rules or exceptions that altered a permission’s action. For example, specifying that a permission only applies to certain tagged data, or only applies in a certain geographic area.

I came up with two potential options for how to display access conditions. I could either (a) group all conditions together in one big Access Conditions section, or (b) associate different types of access conditions with the relevant object section, i.e. user attribute conditions could be added in the Roles section, while data transform conditions could be specified in the Data section.

I ultimately went with Option A (one big section) because (1) users wouldn’t have to guess which section contained their desired access condition, (2) it was minimally distracting in the case that users didn’t want to add an access condition, and (3) there were overall fewer buttons, which reduced visual clutter.

I updated the Permission Builder designs with an “Add Access Conditions” button at the bottom:

I next focused on improving user confidence in data security.

My product manager and I reviewed past user feedback and spoke to internal experts to get a sense of what information users would need to see in order to feel more confident creating permissions. Two key themes emerged. Users wanted to confirm (i) that the permission they were creating would protect data as intended, and (ii) that their permission wouldn’t conflict with or override existing permissions.

I added new informational copy, but users didn’t like it.

I created a new design that featured a “Warnings” section in the summary. This section would show additional context about permission security that users could review before creating. I tested this design with users and, to my surprise, users actively disliked these changes. This was for several reasons:

• The new copy didn’t provide enough detail to be useful.

• The copy was persistent and static - it didn’t appear when needed or let users know if they had made a mistake.

• The additional copy made the screen more visually overwhelming. Users now just had one more thing to read.

I thus decided to scrap this design and asked my team that we instead prioritize working towards barebones preview and conflict experiences, despite the technical difficulty.

I instead added a simple conflict warning.

After some debate, we compromised on building a simple version of the conflict warning. Permissions previewing was still deemed too technically complex to tackle at this stage.

I designed a conflict warning that would appear if users tried to create a duplicate or overlapping permission. It did not account for all conflict use cases and it only appeared when the user clicked “Add permission”.

The trade-off of adding this feature was an increase in scope and thus a delay in delivering v2.0 of the Permission Builder. Additionally, the team did not have time to address some visual design updates, so the feature did not look as polished as it could have.

v2.0 Release

We released a new version of the Permission Builder to positive feedback and increased adoption.

We released v2.0 of the Permission Builder in the spring of 2020. It included expanded access type and scope options, the new access conditions section, the conflict warning, and some general design improvements like simplified copy and sleeker UI:

I interviewed users following this release to get their feedback. Users were very overall happy with these changes and expressed that the feature was finally usable.

In the months following these updates and the v2.0 release, my team saw a noticeable rise in adoption. Okera gained two new customers who began using the Permission Builder right after onboarding, and 3 out of 4 original customers had at least one data owner begin using the Permission Builder for all of their permission work.

Additionally, one unexpected development was that, for customers where data owners were still offloading permission work to engineers, these engineers started using the Permission Builder as well. Despite their in-depth knowledge of SQL, engineers preferred the UI experience.

At this point in 2020, my team largely de-prioritized Permission Builder work in favor of other projects, but we continued to iterate on some aspects:

I addressed some remaining design issues with access conditions.

There were still some minor issues with the access conditions section - mainly that it took up too much space. Each condition that users added increased vertical space significantly, especially for highly detailed conditions.

Users didn’t seem to mind the spacing issues too much, but it was a problem for the sales team who frequently demoed the Permission Builder. The huge amount of vertical scrolling made the feature look sloppy and unprofessional in demos, and sales reps would often lose their place when talking through conditions.

Another issue was that conditions were also persistently “open” and editable. This meant that users could easily edit a condition without meaning to, or lose track of which condition they were working on.

I addressed both of these issues by giving access conditions a “closed” state. When users added a new access condition, they would have the option to save it before adding another. Saved conditions appeared as summarized blocks of text; users had to actively choose to edit them. This relieved space constraints and removed the possibility for accidental changes.

These design changes were incorporated into a later version of the Permission Builder in 2021.

I improved conflicts and designed an initial permission preview.

In early 2021, my team also returned to work on user confidence. I spent some time standardizing Okera’s messaging states and as part of this work, I designed several “just-in-time” warning messages for conflicts.

I also designed a simplified version of the preview modal. It did not include the toggle capability from my original designs, but users could still view the overall effect that their new permission would have on user access.

Overall Outcomes

I re-tested our success metrics and saw huge improvement.

Following some additional design changes (adding time-based conditions, updating the layout to be more stepwise), my team released a new version of the Permission Builder in mid-2021:

After giving users some time to adapt to the workflow, I sent out the original benchmark survey again in the early 2021. Results were very positive:

• User satisfaction had doubled: users rated their satisfaction at a 4.1, more than twice the previous score of 2.0.

• User confidence had risen: agreement with the confidence statement went from 2.3 to 3.8.

• Use case coverage had greatly improved: agreement with the use case coverage statement went from 1.7 to 3.9.

Lastly, adoption was way up. Okera had gained an additional two customers and now 7 out of 8 customers had at least one data owner using the Permission Builder for their work. For most of these customers, the majority of data owners and engineers alike were using this feature to create all their permissions.

These results confirmed that we had met our original goals of widespread adoption and high satisfaction.

Key Takeaways

Simplify, and then simplify again.

Throughout this process, I had to balance maintaining a clean UI with supporting an every-increasing feature scope - and I often let the scope get the better of me. At each stage of design, I was certain I had made the UI as simple as I possibly could, but users consistently asked for fewer visual elements, less text, etc.

I learned to always simplify the UI a little bit more than I was personally comfortable with, e.g. putting a line of helpful text into an informational tooltip or simply not including something at all if it wasn’t necessary. In future projects, I made sure to always embrace progressive disclosure and just-in-time insights over static information.

No-code tools aren’t just for non-technical users.

My team and I were initially surprised to hear that many data engineers were also using the Permission Builder. We had assumed they would prefer to use SQL since they were familiar with it and used it for most of their work anyway. However, engineers appreciated the error prevention and general ease of use that the Permission Builder provided. Rather than having to type out permissions, they simple had to click a few dropdown menus, and they could still add in custom SQL via an access condition if needed.

I realized that I had been mentally categorizing our users into two types: non-technical users who appreciated a clean, simple UI v.s. technical users who didn’t care. This was, of course, completely untrue; technical users also want seamless workflows. After this experience, I made sure that future Okera features accommodated technical users as well, e.g. by providing optional inputs for custom code or showing a “SQL translation” in addition to a text summary.