Design Versions

Overview

This is a new feature that will allow makers to save and revert to their previous app designs without compromising user-generated data.
It is part of a greater effort to eliminate maker stress.

Role

Product Designer
User Research, Interaction, Visual Design, Prototyping & Testing
February 2022 - May 2022

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 Design

Released Feature Walkthrough video ⬆️

High-Fidelity Designs Breakdown

Here’s what users will see if they have 9 design versions created ⬇️

Here’s what functionality lives in the overflow ⬇️

When users exceed Design Version limit ⬇️

Validating the designs

The public launch was a success. Our makers were super excited to get this feature as “it will save me from me”, and “you are reading my mind, Adalo!” because we all can use a little reassurance and your precious work won’t go anywhere:)

Results and takeaways

Since the release of the Design Version, we have had a lot of positive feedback from our community.

Some key takeaways from this project are:

Last-minute changes are okay. The handy banner that lets users know if they had any changes done since the last design version had to go. It was too big of a chunk for devs to tackle, and it was removed last minute.
Keep Could Haves close. Some features can be dropped along the way, because of technical complexity, unexpected difficulties, and time. Usually, they will end up in the Could Have feature pile. Use it as a tag time project inspo, or a way to validate your design direction.

The Process

Understanding the problem

As an active Adalo user, I experienced some frustrations without the autosave functionality that saves your work progress automatically. While working on the app template I was paranoid that I would lose all the progress while exploring different designs and functionality, so I would copy or clone the app to have something to fall back to. So we decided to see what our makers had to say.

The Design Team interviewed 5 Adalo makers who signed up for our Maker Research Program and discovered these top frustrations:

Editor anxiety. Making changes to published app designs resulted in a lot of stress.
Autosave malfunctions. Adalo automatically saves your progress, but sometimes it doesn’t save it correctly and misses chunks of progress.
Control+Z fear. Going back to undo mistakes adds more anxiety because you can’t be 100% sure what will you see after.
Simple changes are irreversible. A simple color change in the branding tab doesn’t allow you to go back to previously set colors and can be stressful if you don’t have hex codes written somewhere.

Defining the problem statement

After gathering the findings from the research, I worked with the team to define the problem statement.

Problem statement:
‍Top Adalo users are frustrated with requests from their clients because they don't have the ability to save the current app design and revert back to it when needed. There is also no way to notify team members about the recent changes.

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:

Manual Versioning. Allows makers to manually save a new design version of their app whenever they like.
Reverting version. A maker can select a previously saved version and revert to that state. This should restore everything about the app at the time it was saved.
Limit Versions Access. Limit feature access depending on the maker payment plan, and limit the number of manual versions for the rest.

User Flow

The team made a maker flow to help us see how many steps were needed to get through the flow successfully.

Designs

Sketches

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

Brainstorming where the feature will live
Visual design
Interactions planning

I quickly sketched out some basic wireframes to gather feedback on the overall versioning flow from Product and Engineers. This involved establishing standardized visual signifiers that would fit into the current editor design.

I came up with a couple of options for where the feature could live and how it could look:

High-Fidelity

User testing showed that option 4 was the most viable - easy to understand, intuitive, and familiar. Feature placement is also future-proof and can be easily added to if there is ever a need to add more options.

Version History tab
I wanted the versions history tab to look familiar and re-use the existing UI.