My Role
UX and visual design, primarily.
I also worked with the CEO on experience strategy. In addition, I led a design intern to collaboratively add visual delight across all flows. I also worked on UX writing. At the end, I combined my experience designing this feature with my love for writing into an SEO focussed playbook for early-stage SaaS builders as part of our content marketing.
Target customer
Beachhead market: Small/medium enterprises with 10-100 employees
Target user: Admins/HRs/founders of small orgs
Goal
Business: To make Pause’s onboarding short, flexible and functional for our customer’s data, while ensuring that it helps admins successfully bring their organisation’s policies and legacy of leaves onto Pause. While this was aimed at reducing drop-offs, our goal was also to make this a self-serve experience to reduce our customer care costs.
User: To register their organisation on Pause with minimal effort.
Version 01: 37 steps long (and technically unfeasible)!
After signing up for several products to analyse their onboarding experiences, we started designing ours. We listed all that our product offered and what an admin needed to do to set it up. We incorporated wizards and progressive disclosure to try and break down systemic complexity. We considered this experience to be more of a setup than an onboarding– big mistake.
What we didn't do was question who our customer organisation truly was, what the admin cared about most during onboarding and the least amount of input that the system required to function aptly.
We had jumped the gun. We simply amalgamated every feature into actionable chunks, leading to a cumbersome experience. This flow had 5 core sections broken down into multiple sub-steps. It also wasn't technically feasible as we would learn post a conversation with engineers.
Next steps: start with a hypothesis
20% of our organic target audience from whom we would gain maximum revenue (80%) have one leave type only.
User research: onboarded 20 organisations manually into our system
Before we jumped to design again, it was imperative for us to gather a deeper understanding of our customer's and the data they were bringing into Pause. We fed data– an org's leave policy, employee emails and their time-off balances–directly into the backend.
This gave us invaluable insight into what we needed to build. It also helped us validate and refine our hypothesis. We found:
Rethinking the user flow
For this iteration, our goal was to create a flexible experience with as few steps as possible, yet keeping the integrity of a leaves management system intact. After designing V0, we had started to understand the system better ourselves, including the constraints we had to account for:
Leave management's attributes are all inter-related and greatly impact how effectively the tool works for the user. Many of these need to be set up during onboarding; else the tool fails to accomplish what it's set out to do. But, to what extent? We started by creating a list of these attributes and their dependencies:
We also realised that an accurate calculation of leaves is based on multiple dates in the system, which influence one another:
For instance, if a new leave type is created half the year in, should members still be allocated leaves from the beginning of the year or from when the leave type was created prorata? Furthermore, any changes to these policies mid-year would alter the number of leaves available for members to use. How would the system handle these changes?
This conundrum lead to deep collaboration with our backend and frontend engineers, resulting in a table of decisions for all scenarios.
Redefined product strategy
After understanding our constraints and defining the backend system, we articulated our breakthrough strategy:
Onboarding should take users just about a minute
This would align with our product ethos of being lightweight and give us a competitive advantage.
Version 02: 21 steps and 1 minute long
How did we do this? We started with our JTBDs and prioritised them into must-haves and good-to-haves:
Must-have:
Good-to-have:
Getting to the above experience was complex. We often found ourselves tangled up within the system at hand. Design principles and mental models came to our rescue to strengthen our decision making and helped us make the required trade-offs.
Version 03 (shipped): A 4-step onboarding!
A user would take far lesser time to navigate V1 than V0, and could finish onboarding in about 1-1.5 minutes. Yet, our team felt the flow could be more concise.
Onboarding could be improved to build familiarity, ease engineering effort and give users a walking tour of the product before they commit entirely.
We further prioritised our JTBDs and only retained the steps that were needed to create the core organisation in the backend. The rest was summarised into a checklist that linked to different modules of the product.
Through our checklist, we also managed to push our good-to-have, competitive features like Slack and calendar integration to our users.
Business impact
Through rigorous iteration and ruthless prioritisation, we not only used Onboarding to grow our signup rate and reduce customer queries, but also enhanced the experience for active users. With the checklist being permanently incorporated into the product's architecture, we have now created a space to promote new features seamlessly, without bombarding users. Empathy for the win! It acts as a 'what you can do' guide– how we might in person– for existing and new users alike.
Personal learnings
For me, onboarding was one of the most fulfilling projects to work on. While I harboured an interest in growth design, and had delved a fair bit into the theory of onboarding best practices, getting my hands dirty raised the bar on my learnings.
Navigating ambiguity
Product strategy
Tenacity when iterating