As a design-driven Product Manager, working on Project Comet is a surreal experience—the momentum and excitement from the UX/UI community has been nothing short of humbling, all before we even launch a product. Great expectations come with a heightened sense of getting it right since when we release (soon!) everyone is using this for the first time. Along with building amazing design and prototyping features, we’ve been developing the first-use onboarding experience to help make the first launch of Project Comet a good one.
For onboarding, I’m talking about the in-product experience users see as they use Project Comet for the first time. Onboarding is undoubtedly a critical part of the development process for any product and our team has been heads down figuring out what works and what doesn’t.
In its simplest form, the Project Comet workflow is fairly straightforward:
The tl;dr Project Comet workflow
Our task is to dissect the complexities of this workflow to keep key concepts easy to digest, reducing any ambiguity on how to navigate the Project Comet interface. Making things easy isn’t easy (but where’s the fun in easy anyways).
Where do we start
Onboarding customers to an entire product for the first time is a big task. Go too broad and no one understands what they’re supposed to do. Go too narrow and you end up getting in the way by micro-managing the interface with annoying messages. We took a look at onboarding experiences we liked and didn’t like, noting patterns and trends generally used in products used by UX/UI designers.
Design should never say “look at me”. It should always say “look at this”. — David Craib
Many onboarding experiences we saw lead you through a scripted set of interactions with messages or attractor animations. This works well for something like a mobile app which has a single workflow — but at design time comes at the cost of deliberate attempts to interrupt the user for the sake of promoting a message. This often works for the product but not for the user, and people generally get pissed off when you block them from doing something.
For freeform design applications like Project Comet, the workflow is more of a choose-your-own-adventure experience. It’s not up to us to prescribe where you’ll be in the design process. We expect you’ll constantly dip in and out of each mode as you iterate on a project.
After looking at the onboarding landscape and conducting user research, we evaluated how we could improve our approach to onboarding. We decided to explore methods which would give zero interruption to the user while they’re trying to work.
Starting with research
To break any mold of convention takes research. We wanted to better understand how people would approach the Project Comet interface and where they were most likely to learn.
After a series of in-person research and testing, it turns out there’s no one-size-fits-all method to discovery (no one on our team was particularly surprised by this). We took all of our data and observations and found patterns in the way people approach learning a new product. Some learn from tutorials, some learn just by working, and some learn by kamikaze-clicking every button they see.
From better understanding how people discover and learn, we know we can’t rely on a single approach and declare success. We can’t assume people are wired to learn in the way we want them to learn. Sure we could pop up a message that says “Hey, use feature x! You’ll like it we promise!” but if we don’t offer help at the right time, in the right way, for the right reasons, all we’ve built is a really expensive close button.
Understanding learning behavior
A side effect of working on a product is knowing all the intimate details of how to achieve success. For us, we could design and prototype with our eyes closed as self-made Project Comet power users. This knowledge starts to work against you when making assumptions for onboarding experiences; it becomes much more difficult to differentiate between the obvious and the hard to find.
To combat our own assumptions, we dissected the customer journey into a series of behavior maps to understand that success is not necessarily linear. What if someone tries to make a prototype without creating artwork? What if someone tries to share a prototype without adding any interactive elements? By breaking down all the nuances of conditions it was clear a popup saying, “Hey, make a prototype!” isn’t going to cut it.
Our straightforward workflow from above, after behavior mapping, now looks like this:
Behavior map showing the possible steps a user could take to share a Project Comet prototype
These maps serve as a great cheat sheet for knowing where to introduce contextual, reactive messaging — and to evaluate which cases we would even need to use that for.
We moved away from proactive messaging towards an “onboarding with features” model. This allows us to help users as part of the design process instead of interrupting them. An issue with the in-app messaging approach to onboarding is it’s very difficult to know when said message is actually helpful. Even with engagement engines and intelligent predictive behavior, a pop-up which says “Hey, check this out!” errs on the side of annoying rather than valuable. Since experience is a core value proposition of Project Comet, we want to avoid any experience which would be perceived as aggravating… even if it would be useful in the short term.
This model led us to consider a reactive, instead of a proactive approach to onboarding. Reactive onboarding places a certain amount of trust in the user that they will try and do something on their own. For example, if we want to tell someone about how to make a prototype, we assume they’ll click on the big “Prototype” button at the top of the workspace.
The difference is subtle but significant. With proactive messaging, you’re pulling the user away from a task they’re currently performing. This is hit or miss because they may or may not do what you want them to do. With reactive messaging, the user has already opted-in and this is your opportunity to educate them on next steps.
Carmen Ruse, an experience designer on the Project Comet team, helped create what we have lovingly called “The Pancake”. The Pancake acts as a hub for contextual keyboard shortcuts to discover as you use Project Comet.
The Pancake lets you discover keyboard shortcuts as you use Project Comet
In this approach to onboarding we can surface discoverability of features in a way people actually want to use. The Pancake reacts to the actions taken inside Project Comet. For example, if you select an object we can tell you the keyboard shortcut for using Repeat Grids (one of my personal favorite features). If you’re using the pen tool, we show keyboard shortcuts for manipulating anchor points. We chose to omit the obvious commands such as Cmd+V for the sake of redundancy but keep the useful actions present. We’ve heard from hundreds of designers learning keyboard shortcuts can be painful when learning any new application, and want to solve this problem with the added benefit of discoverability.
The version in the picture above evolved from many iterations which had accompanying messages, such as “Use repeat grids to duplicate objects” or “Now that you have some artboards, try prototyping.” This type of messaging goes against our core value of “don’t annoy the user”. In the end we decided to trust the intelligence of our audience by removing as much messaging as possible.
Drive action through empty states
Keyboard shortcuts help in feature discoverability, but we still had a problem helping users understand the conditions they need to meet to be successful to create a prototype, or share that prototype. Our behavior maps led us to use the Pancake — very selectively — to help give guidance when you need to do something to move forward.
For example, you need to have artwork to bind interactions for prototyping (i.e., click a button to show a screen). If you try and make a prototype without any artwork, we instruct you to draw something first. This method is reactive to a user exploring the interface or just learning the workspace, educating them on features in the process.
As of this writing, we’re still working on the final design but the intent is to make all empty states actionable. No one likes an empty state.
Actionable empty states with the Pancake
Product experience > onboarding
At the end of the day no amount of onboarding beats a strong, intuitively designed product. When the onboarding process goes beyond a single click, we take a step back to ask if the feature needs improvement instead of papering over the problem with onboarding. We’re a little obsessed with the details of user experience. Nir Eyal, one of my favorite experience experts, says it best:
“Influencing behavior by reducing the effort required to perform an action is more effective than increasing someone’s desire to do it. Make your product so simple that users already know how to use it, and you’ve got a winner.”
― Nir Eyal
Onboarding is just another consideration of user experience; done right it’s transparent, done poorly it’s painfully obvious. With any luck you won’t even notice our work.