The journey is more important than the destination
The psychology behind a beautiful onboarding flow
--
This is Part 6 (phew! last one) of a 6-part series where we share everything that went into building our product, Crew. Since last year, we’ve gone through this process a full time again for a brand new Crew. You can read all about it here.
It’s hard to change someone’s behavior.
Yet any new product requires people to change. If someone wants to use your product instead of whatever they’re currently using it means they will need to change.
One of your jobs as a product designer is to help people easily make this switch.
This is why the way you get someone started using your product is so important — a process that’s often called an onboarding flow.
One example of a memorable onboarding flow for me was when I downloaded the to-do list app Clear.
After swiping through a few screens, I landed on this screen:
I loved it.
By giving me pre-filled to-do items to play with I learned how to interact with Clear.
Learning by doing is a common tactic used to increase player engagement in game design. Many games like Super Mario for instance start with easier levels to help players get comfortable with controls while creating a sense of mastery and challenge at the same time.
In his book, The Art of Game Design, author and video game designer Jesse Schell describes how games must always balance challenge and success to keep players engaged,
“If play is too challenging, the player becomes frustrated. But if the player succeeds too easily, they can become bored. Keeping the player on the middle path means keeping the experiences of challenge and success in proper balance.”
Here’s a figure from the book that illustrates this theory:
In game design, the goal is to keep people in the Flow channel where there’s an equal feeling of challenge and success.
Early levels of a game are usually designed to be easier on purpose. The game designer wants you to learn the skills you’ll need later to beat other levels of the game.
One of the main reasons creating a balanced game is hard is because players have many different skill levels. What one person finds hard, another person finds easy.
This is similar to the challenge of designing the right onboarding flow for a product.
Clear’s onboarding process is like the early level of a game. You learn how Clear works by playing with the pre-set to-do items and by the time you’ve taken care of all the to-dos, you feel a level of comfort with the product and are ready to make your own list.
For me, this method was so effective that since then Clear has been my default way to make to-do lists.
Because Clear’s main difference compared to other to-do apps was how it’s gesture-based design worked, teaching people how to use the new gestures during the onboarding flow was likely a top priority for them.
In your product, however, there might be a different key point that’s a high priority to help someone make the switch.
In our case, Crew is a two-sided marketplace business model, so we have two types of members to onboard:
- Members who post projects
- Members who work on projects
Right now, we’re focusing more on improving the onboarding flow for our members posting projects. This is because we need to increase the number of projects on Crew to match the number of creative professionals who have already signed up to work on projects. Once the projects to professionals ratio evens out, we’ll re-focus our attention toward the onboarding flow for members who want to work on projects.
Early on, we noticed that one of the barriers for people who wanted to start a project was understanding what things they needed to know.
What’s the best way to build my idea?
Should I build a website or mobile app?
Do I need a designer, a developer, or both?
How much will it cost?
So one of the things we did from day one is try to offer some insight into these questions as you submitted a project on Crew.
Here was our first form (April 2013):
Because Crew was young, we focused more on making sure we were building something people want rather than a clever onboarding flow. So we chose to build the minimum amount possible to confirm our business model was valid.
Our first form was built without code using the Wufoo online form builder. We tried to add enough helper text that would offer guidance for people posting projects.
We soon realized many people were still having trouble completing the form so we offered to help through email and phone calls. We documented all the most common questions.
This was the start of our research for designing a better onboarding flow in Crew.
The next form we used took into account the findings from our research.
It worked like this:
1. You select the type of project you’re building:
2. You pick the features you want:
3. You get a budget recommendation:
The data used to make this estimation came from thousands of projects submitted and done successfully on Crew.
However, one of the things we noticed with this version of the project submission flow was there was still a large number of people that didn’t complete the form.
About 75% of people who started a project submission didn’t complete it on the first attempt. About 10% came back and completed their project submission later but the 75% incomplete percentage was a sign that there was likely something we could be doing better.
One of our assumptions was, since almost all the questions are asked on one page, it may look like there’s a lot of information to complete. This can seem daunting and cause people to abandon completing their submission.
At the same time, we thought,
“Maybe a longer form like this could be a good thing?”
We want to make sure people posting projects on Crew are serious about following through. Our hunch was, if you were serious about your project, completing a longer form would have less of an impact on your motivation to move forward. And it may weed out projects that are less serious.
The only way to find out which form design was better was to test.
An early experiment of a much different version of this estimation form was our mini-site How Much To Make An App:
One of the main reasons we made How Much To Make An App was to try a more ‘fun’ way of creating a budget estimate.
How Much To Make An App was a visual, step-by-step process that asked you 8 questions, one-at-a-time, to define what you want to build. And each question has only 3 options. For instance:
After seeing How Much To Make An App in use for over a year, we noticed this type of estimation flow resonates with people. Over 80,000 estimates have been generated with How Much To Make An App. That’s 5 times the number of submissions on Crew.
Granted, How Much To Make An App’s main focus is generating estimates while people coming to Crew are looking to actually start working with a talented mobile or web professional.
We then looked at the ratio of estimates that complete the How Much To Make An App flow compared to the ratio of submissions that become completed projects on Crew.
Of the 80,000 estimates from How Much To Make An App, about 5% of those become completed projects on Crew. This is similar to the conversion rate of our current estimator on Crew so not a significant difference.
But then we dug deeper and found a telling stat — about 3 times the number of people who use How Much To Make An App complete their project submission compared to the people who use the current flow we have in Crew.
This is a substantial difference and points more to the positive impact of how How Much To Make An App is designed compared to the design of the project submission flow within Crew.
There seems to be something good about making an onboarding flow enjoyable and fun as long as it doesn’t get in the way.
Balancing useful and fun
With this knowledge in hand, our main focus with the new estimation flow was to strike the balance between being useful and fun.
Some people who come to Crew are familiar with building a digital product and know what they want. They want to get through the setup quickly and get on with it.
But other people come to Crew not knowing exactly how things should work. These members want to be walked through a flow that helps with these things.
To create the right onboarding flow, we started by focusing on what details we needed to collect to create an accurate ballpark budget for one type of project.
Because different types of projects (web design, iOS development, etc.) can be posted on Crew, we needed to change the flow for each type of project to make it useful. For instance, the questions we ask to come up with a budget for design and development of a new iPhone app would be much different than the questions to estimate the design of a custom WordPress blog.
So we sorted each flow using a folder hierarchy:
Our goal was to ask enough questions in the right way to get an accurate budget estimate for each type of project but not too many questions that would make you not want to complete it.
The first flow we made was for the most complex project type: Designing and developing a new mobile app
We figured if we began with the most complex project type, the other flows would be easier to do. And we could re-use similar questions and logic.
We thought of all the questions we possibly needed to create a budget recommendation:
- What’s your name?
- What’s your e-mail address?
- What type of app are you building? (Android, Apple iOS)
- Do you need a designer, developer, or both?
- Describe your idea in a few sentences or attach a brief summary.
- What features do you need?
- When are you looking to get started?
- Is there an existing app you like the style of?
- Would you like to work with someone from a select city?
We added in questions about your name and email so we could make Crew feel more personal and so you could access your project submission later.
Then, we cut and re-ordered the questions down to the essentials. Our thinking was,
“If we can get you an accurate budget range asking 5 questions instead of 9, then we should ask 5.”
Here’s what we came up with:
Ask these questions to get a budget recommendation:
- What’s your name?
- What’s your e-mail address?
- What type of app are you building? (Android, Apple iOS)
- Do you need a designer, developer, or both?
- Describe your idea in a few sentences or attach a brief summary.
- What features do you need?
— Give the budget recommendation —
Ask these questions later because they aren’t needed to get a budget estimate:
- When are you looking to get started?
- Is there an existing app you like the style of?
- Would you like to work with someone from a select city?
Once we had this, we created the budget formula from data we’ve seen from all the projects completed on Crew.
The formula looked like this:
Budget ($) = ($ Constant) * (Product of complexity factor for each feature)
The formula for a mobile app for instance starts at a baseline dollar value of $10,000 and changes as you add more features.
Each feature has a complexity factor that multiplies the constant. Each feature you want to build, adds a level of complexity to all features. The more features you add, the more complex everything gets and the budget increases as a result.
Here’s the onboarding flow we came up with. The visual design has since changed with our latest release but the philosophy remained the same. So we felt it still might useful for you to see one way this philosophy on onboarding design was put into practice.
It wasn’t easy coming up with the flow for this first project. Although it may seem like a simple series of questions, there were plenty of trade offs and hard decisions to make it seem straightforward.
Things to think about when designing your onboarding flow
If you’re building a product, here’s a few of the key things we learned from creating this onboarding flow:
- Make your onboarding flow enjoyable but not too fun where it’s annoying.
- The fewer the questions the better. Ask the minimum number of questions you can (any nice to have questions, ask later or don’t ask at all).
- Always show a sense of progress.
- Make questions easy to answer. Reduce input fields down to yes/no options or checkboxes so people don’t have to think.
- Offer a way out of every question. A ‘Skip’ or ‘I’m not sure’ option is helpful to keep the rate of completion high if someone doesn’t know an answer.
- Make sure people can go back and edit answers.
- Start with easy questions and build to harder ones.
We don’t know if we made all the right decisions but we’ll watch the data, see how it goes, and change things to try and improve.
Once we had this design direction roughly figured out for this first project type, we created the flow design and formulas for the rest of the project types. Thomas worked on developing the flows to work with the different formulas while Angus re-structured the site architecture and database.
And with that final piece of the puzzle in hand…
After pushing live, one thing we reflected on during the process was the impact of deadlines. There’s a good side and a bad side to deadlines. On the good side, they help you focus on what’s most important.
When you have a tight deadline, you know you can’t spend too much time on low impact items. The highest priority items naturally draw your attention.
On the bad side, this same focus has the potential to hurt the quality of the product because it may not allow enough room for alternative routes to be explored. If there was an error in your original thinking, a tight deadline may not give you the time to course-correct. This can lead to less optimal ways of solving a problem, rather than a more novel approach that may require a longer incubation period.
To get the best of what deadlines have to offer, here’s rough formula we’ve come up with for setting ours:
Your immediate reaction to how long you think it will take X 2 = A realistic deadline that keeps you focused but also allows for enough time to explore different routes
This is how we came up with the deadline we used for this release of Crew.
While, it still felt a bit tight, the timeframe did allow us to explore many different alternatives and think deeply about the right way to build a system that solves our member’s problems.
Building Crew in Public
Privacy be damned. Building Crew in Public is a series of 6 short essays on product design philosophy and the struggles we faced designing our own product. You can read the original, On The Road-inspired version on the Crew Backstage blog.
1. We’re all selling experiences
2. Start with problems. Not solutions.
3. Constraints, not barriers
4. Ask lots of questions
5. Anatomy of a homepage
6. You made it! :)
P.S. The new Crew
I hope you enjoyed reading this series and that you found a few useful things to think about if you’re designing your own product. We recently went through this process again for a brand new version of our product at Crew. You can read all about it here.
