Knack No-code Web Application

Approach & Design

Phase 1: Pre-defined Permissions

This was a technically complex project with a lot of backend setup work required, so we split it into two phases. The first phase included allowing users to set up basic, pre-defined permissions per table based on the role. The custom permissions, including the filters and field-specific permissions, were deferred to Phase 2.

For phase 1, we focused on a new matrix-style table (in line with industry standards and best practice) in a separate Data Permissions area in the part of the builder where User roles and Users were managed. From this table app-builders would be able to select a pre-defined permission level for each role per data table.

The pre-defined options were limited to start with, including Full Access, View Only, or No Access. For each table the permission could be set for records owned by the user, and separately for records owned by other users. For example, in an appointments management app for a GP practice, the Care Coordinator role might have full access to the patient records they own, which would be the patients assigned to them, but view-only access to patient records owned by other coordinators.

Phase 2

Fixes based on Feedback

The first set of phase 2 designs addressed the problems identified in the feedback with the matrix grid:

• Grouping user tables and data tables into collapsible row groups to reduce visual load. This allowed for more focused working and also meant I could move the icons indicating the table type to the row group headers rather than repeating them per row, which also helped with the visual load problem.
• Allowing users to set permissions for groups of tables from the row group headers. This reduced the time taken to initially set up permissions, and gave builders a way to set a broad default and then adjust the individual tables that needed to differ. We can expand on this in the future by including batch editing options in a later phase.
• Adding in missing functionality, such as search and filter options, which became necessary once apps had more than a handful of tables.
• Adding a summary of the access levels (Add, View, Edit, Delete) on row for specific user role tables (not the overall matrix, as this would add too much content to that table), so builders could easily see permission levels at a glance.

Alongside the main matrix table showing all user roles, each user role has its own Data Access tab showing a version of the same matrix but limited to that specific role. This gives a summary of what that specific role can access across every table and is used for more specific workflows e.g. when builders are checking 'what can Care Coordinators access?'' this view is more targetted. Keeping the same matrix pattern in both places meant builders were familiar with the UI, but could approach access permissions from either direction depending on their goal (e.g. 'what can Care Coordinators see' vs 'who has access to the Patients table?').

Adding a Custom Option

The Custom option had been planned for phase 2 and required a user testing of the designs to ensure we were creating something intuitive that builders were able to use confidently. To restrict access based on conditions as well as user role, I reused an existing pattern we have elsewhere in the Builder which allows users to set up filters and filter groups. The Custom option also allowed users to set up field-level permissions, so that certain user roles would have permission to view and/or edit records but would also be able to exclude certain fields from that. This was particularly important for HIPAA customers who might want to restrict sensitive data in records to only be visible or editable by certain roles, whilst keeping the rest of the record visible/editable.

We identified several problems with the first (Figma) versions of the Custom option design:

• Relationship between the View, Edit and Delete sections wasn't obvious. A user can only edit records they can view, but the UI in the initial design did not make this dependency visible, so it was possible to set up an edit rule that looked like it granted access it didn't actually grant. This is obvious when thinking about it (e.g. I can't edit something I can't see) but that required extra cognitive load on the user, and the fact this was not spelled out could lead to a lack of confidence in the Custom permission being created.
• Wording used was too technical. It was closer to the underlying data structure and not close enough to how builders describe what they want. It led to confusion and made the feature harder to use for less technical users.
• Rules/filters had to be built from scratch. We identified a common use case of needing to restrict a role's view/edit permissions to their own records. Showing this as a pre-built option not only meant users could then add that option with a single click, but also provided an example for how these filters could be used.
• Field-level permissions at the bottom of each section were not obvious enough and were easy to miss.

Reflections & Learnings

Splitting this into two phases was necessary because of the backend work needed but it did mean releasing something that was incomplete/did not have the full functionality our users needed and much of the phase 1 feedback was about problems we already had solutions planned for. The phased roll-out meant it was at times difficult to separate the issues from the design itself from issues that were simply due to the implementation not being complete. However, what was useful was where the feedback shows us where the phase 1 approach did not work at scale, which we improved in the phase 2 designs.

Building a working prototype rather than static designs was useful for this project because the access permissions had many possible setup combinations, flows and dependencies. Being able to click through those combinations surfaced problems that wouldn't have come up in a static Figma design. I still used Figma to spec out more detailed components and UI patterns, but the prototype was much easier to talk through with engineers, user and other team members. With hindsight, it would have been useful to have the prototype for the phase 1 designs.

Reusing the existing filter group patterns we already had elsewhere in the Builder reduced the learning curve for the user because the pattern was familiar - taking the approach to reuse patterns wherever we could, even where a purpose-built pattern might have been slightly more efficient in isolation was a simple, efficient way to reduce cognitive load.

Phase 2 has not yet been implemented, so the designs above are the tested prototype rather than the shipped feature. The main open question is whether the Custom option gives builders enough confidence to use it without needing support - this is something we will be able to measure once the feature has been rolled out.