Adalo is a no-code platform that allows makers to design, build, and ship apps without any coding knowledge. Users can use a wide arsenal of drag and drop components, to design and publish beautiful, useful and powerful apps for their businesses, sturtups or side projects.

The Scope

Adalo is a no-code platform that allows users to design, build, and launch their app to the app stores without needing to know how to code.
We have had a number of successful apps that are popular around the world.

Project Goals:

• Eliminate the ability to see any private data in any app

• Provide safer defaults to 100% of new apps

• Communicate to makers of existing apps the value of updating their app’s security and the path to get it done

Known Problems:

• There’s no way for makers to be able to set who can have access (view or edit) to sensitive data, like email addresses.

• There’s no way for makers to permit data access based on first-level data relationships (Trip Owner, Teacher).

• There’s no way to protect second-level relationship data by setting access limits for secondary users (Trip Members, Students).

• CRUD actions are available to all users.
  

The Design

High-Fidelity Designs Breakdown

• Permissions Modal open. Users collection permissions ⬇️

• Permissions Modal. Users Permissions Dropdown open ⬇️

Results and takeaways

Since the implementation of the collection permissions, we have had a lot of positive feedback from our community.

Some key takeaways from this project are:

• User testing doesn't end after development. Always find ways to collect and listen to your user's feedback - forum posts, cx tickets, community managers, and social media.

• Involve engineering upfront. Knowing technical limitations upfront helps to reduce any rework later on and helps to inform your design strategy.

The Process

MoSCoW Method

The product team along with Engineers and QA had a workshop to determine our feature prioritization with the help of MoSCoW method.

We identified the following key features:

• Column Access Control Allows makers to control user access to any record in their collection and be able to read, write, and delete data.

• User Access End-users of any Adalo app can only access data in records that were set up for them to view and/or edit.

• Access Control Actions Allows makers to control the access settings for a record through an update or create action.

• Multiple Owners A maker can assign multiple owners to data

• Roles Maker can assign a role to each user. Each record would have the ability to set which roles can read/write/delete that data.

Team Breadboarding

The team breadboarding exercise helped me understand how many steps it takes for users to set one permission, what actions they need to take and think about CTA UX writing

Example for this exercise - A trip organizing app that has a trip creator who can create, update, and, delete trip data.

Designs

Sketches

Based on the above problems, feature prioritization, and project requirements I started sketching to find the best possible solution

• Reducing the number of steps to minimize time to completion

• Visually represent successful task completion

I quickly sketched up some basic wireframes to gather feedback from the Product, Engineering, and the users on the overall permissions setting flow. This involved establishing standardized visual signifiers that would fit into the existing database table view, dividing the permissions levels by actions, and simplifying the modal interface.
Feedback identified that having permissions be set separately on each collection property is very time-consuming and inefficient so I went back to my drawing board.

High-Fidelity

Insider user testing was an iterative process that was conducted at every milestone of the project to identify usability issues. We asked team members who were not actively working on the project to test our wireframes and once feedback was gathered, I would revisit the prototypes and test them again.

Permissions Modal
‍I wanted the permissions modal to look familiar and decided to re-use the existing UI to make it easier for our users to set permissions to protect - data.

Permissions Options

To set user permissions maker will have to choose from what action is available to what user. User types to choose from: everyone (not signed up users), only logged-in users (users who created an account), and record creator