Improving the Onboarding Experience for Canonic
PRODUCT DESIGN • INTERNSHIP • END TO END • 2021
This end-to-end project involved the creation of a new onboarding experience for Canonic, a low code backend development platform, its subsequent production, and testing. Completed during my two-month product design internship at Canonic.
Project Details
2 months
Sole designer
End to end project
Work Overview
Problem Identification - Component Design -Iterative Prototyping - Testing - Release - Analysis of collected data.
Introduction
Canonic is a low code backend development platform. It allows users to define their database schema, feed data into their database using a CMS, and use CRUD APIs (or create custom APIs) to fetch that data and display it on the frontend; all while using a graphical interface.
Onboarding experiences for low/no-code platforms serve two purposes: a) they provide the basis for users to evaluate the platform and b) they result in a working knowledge of the platform for the user to create what they'd like to. Therefore, onboarding experiences need to have clarity, display the extensibility of the platform, be inviting and fun to complete as well as take less than 12 minutes to retain user interest.
Problem Identification
I used a combination of existing data and conducted moderated user interviews with new users to create an exhaustive list of problems with the current onboarding experience. Some of these are listed below:
-
Losing user interest in the first out of three total stages. There was a 25% retention rate after the completion of the first stage.
-
The prompts led to a high cognitive load as they displayed lengthy explanations, often irrelevant at some places, adding to the overall time and effort that it took to comprehend a prompt.
For example, this prompt displays loosely relevant information regarding tables as well as the steps required to be completed by the user, information regarding why this step is being done, buttons and support options.
-
The total number of onboarding projects deployed was quite low. This meant that users were skipping onboarding.
-
There was no possibility of learning specific steps. Each user had to go through a generic onboarding project from start to end, undermining the complexity of what they'd want to build on the platform.
-
Users were often stuck as there was no intimation about errors made during the onboarding project. This meant that after certain steps, the users would just have a completely different project than intended leading to flawed communication.
For example, here, I named the table "Author" instead of "Authors" but there was no way of knowing where I went wrong. In complex steps, identifying why a user could not move ahead became a challenging task.
Along with this, other enhancements were made such as: making it developer-friendly, creating a modular structure that could adapt to any project (therefore making any project a tutorial), reducing overall copy to be read, and designing a reusable component system.
All of this was then developed, tested with users on UserTesting, modified, and pushed as part of Canonic's ProductHunt launch on the 21st of August, 2021, and is currently live on app.canonic.dev.
Outcome
A walkthrough of the new onboarding is displayed in the video below. Feel free to try it out yourself by visiting app.canonic.dev and starting the tutorial project. Shoot me an email if you have any feedback regarding the experience.
A small snippet of the Whimsical map for self-identified problems in the onboarding structure.
As this was the first time that I was designing an onboarding experience, I thought it would be wise to study some of the existing onboarding experiences of similar tools and products that were recommended by the team/my network. An onboarding experience that I really enjoyed was that of Grasshopper. I set this as my unofficial benchmark.
A screenshot from the Grasshopper onboarding track, "Fundamentals". The prompts were clear, direct and positioned accurately.
During the next few weeks, I immersed myself in understanding the product. This, along with concept ideas and derived insights, soon led me to the formation of a macro-understanding of the platform. Allow me to explain.
All projects on Canonic follow the same general structure. This can be held true for most backend systems as well. First, you define the database schema, which in this case is the Graph View. Then, you add entries into that database, which in this case is the CMS tab, and then create APIs to fetch that data and incorporate it into your frontend framework through the Documentation (blocks of code that Canonic autogenerates). So, if you think about it, all projects go through the exact same flow; although the content and complexity will vary.
When discussing this, the team encouraged me to think of a flow that could fit multiple use-cases; thereby allowing the structure to adapt to any Canonic project and convert it to a tutorial. I made a list of all variables and constants of the platform and then created an adaptable User Flow on Whimsical. This was tested with three varying types of projects.
Purple fields indicate body copies for the prompts; variables, "X" / "Y" / "Z" can change from project to project.
This structure also allowed variable user journeys. For example, a user could choose not to learn how to create a custom API and, hence, immediately shift onto a different track. This, in turn, would allow users to jump between tutorial steps and in the future, make stage-specific tutorials possible.
When this structure was solidified, I started thinking about how each stage in the user flow could form a system of components. For example, the action of naming anything would have a single prompt design; therefore making development faster since we were on a time crunch. These components were then structured into a design system that mentioned what component was to be used in a specific case.
A small snippet from the component system; this one for Text Box prompts.
A problem when doing this, however, was that there were certain overlaps or places where the prompt would not fit ideally. This was solved by mapping available space on the platform which allowed me to understand common whitespaces on the platform where prompts would be visible. Similar prompts, therefore, would be shown at the exact same place; allowing for a higher level of consistency leading to faster location times after repeated use.
Mapping of the platform to understand where components could fit and what the sizes could be.
Another tricky part was coming up with the copies for the prompts as one of the goals was to reduce the overall copy that a user needed to read. This meant that prompts had to be crisp, clear, and direct and leave no room for misinterpretation. Simranjot & I really scratched our heads on this one and still weren't completely satisfied. However, this is something you learn when working on a time crunch. You prioritize things based on the return on investment of time and effort.
After rounds of A/B testing and discussions with the team, we arrived at something that all of us approved. This was handed off to Pratham who put this into development, which was a completely new experience for me. I had never seen something that I cooked up in my bedroom now ready to be pushed out into the hands of people.
There were several rounds of testing and bug reporting before the final release on ProductHunt. I think I reported over 70 bugs, sometimes staying up for entire nights to simulate all possible usage scenarios. During the time of writing this article, we're collecting data about the new onboarding which I shall report back here later. I can't wait to see the results that it brought for the platform.
Dear bugs, please magically go away.
This project marked an important moment for me. Something that I helped make was released to the public, going through real-time use independent of my inputs. As it was a first for me, I collated my learnings from this experience into this Medium article.
Thank you for reading through this case study :)
Design Process & Reflections
The initial parts of this project were spent on quite a lot of research. Firstly, I had to obtain a brief understanding of backend systems (databases, APIs and Query Languages). Then came problem identification with regards to the existing onboarding experience. This was done through a combination of interviews and self-directed user simulations.
A map of insights along with identified loopholes with the current onboarding experience was then derived. This set the backdrop for the new onboarding experience.