A novel approach to onboarding

The article is interesting, but what intrigued me the most was the carefully coordinated marketing:

- Medium article to capture inbound and not make it look like an ad, but a "We want to share this discovery with you"

- Hacker News submission to get audience

- (probably) team upvote boost to trigger front page

- 50% off promotion ending in ~4 hours with the tagline "you'll never see this offer again".

Cost of advertising: $0. Nice job!

Great article about mental models! I commend the OP on sharing their experience to really understand what people are thinking, feeling, and expecting. This is exactly how you make tools that people love to use.

> The line in the background depicts how a user is feeling at a particular gate. Might cover this in a future post.

I understand the sentiment here, but trying to map real human feelings and emotions is tricky - it's rife with personal assumptions that once visualized, always fail to capture what people really feel.

Having taught Service Design at a big design school, this was something my students would try to convince me on when crafting service blueprints and journey maps... that they could create a 'happiness' or 'sadness' curve to depict what humans feel when interacting with a product or service. It never really works very well and can end up creating a false sense of emotional superiority within the designer's mind. Approach with caution!

The short version:

Our Aha moments, the features that made us different, were also the reason people weren’t sticking around. People expect an email client to work a certain way. Our unique features made us too different. They made the interface unfamiliar — if you didn’t engage with our onboarding, chances are, you were lost.

We took all of these features out. Every single one of them. And by doing so, we created a bog standard email client. It did everything a regular email client did, and nothing else. It worked exactly as users expected it to — so we didn’t need our complicated on-boarding anymore. But that’s not exactly a compelling proposition.

We took them out of the UI, but we put them somewhere else. We created a ‘Skills Center’. You accessed it via a button that we highlight early in the user journey. It is the only thing that stands out from an otherwise familiar UI. Now, when a user played with Hiri for two minutes and realised that there’s nothing new or different, inevitably they clicked on the one thing that was. And when they do — we have them.

In the Skills Center, you can add the features that make Hiri unique. In your own time, you can explore these features and turn them on.

It reduced our time-to-Aha moment from one week to one hour. Our conversion rate shot up from 1 in 50 to 1 in 10.

I'm so happy that the idea of not shoving all your feature to the user is paying off.

I've been trying to make people at my workplace understand that. You don't want a complicate product, you want a modular one.

I really like your take on the "skill" page.

I could see a little toast with a text like "let us help you with your inbox" as a way to nuge the user to check your skill page.

I see a ton of novelty in this approach, and frankly, I'm not sure how others don't. Separating the leaning curve from the onboarding curve is a UX specialist's nirvana, and this seems like an innovative way to do it. It feels like a risk to trust your users to discover through their own initiative, and perhaps it is one, but it seems to be paying off in this case.

So this seems to be getting slated as a submarine, but the underlying insight is good: users don't like change. They want an app "exactly like X, but ..." So you start with a familiar interface and let people choose when they're ready to make it less familiar.

Rather like how game tutorials work with locked-down interfaces and gradual introduction of more mechanics.

This is really great and there are some interesting takeaways.

The reality was that most users paid little attention to our onboarding. They weren’t reading our precious copy.

We found exactly the same, and we had somewhat of an advantage in this regard of having a completely new interface to most people (Mobile AR). So we expected people would take more time to learn our UX. Nope.

People want to blaze through onboarding even if they have no clue what to do and have never done it before. They wanted it to just be so simple that there was zero learning curve. That ended up being enlightening for us and forced us to radically simplify and copy.

Your product should work the way I expect it to

How I expect your product to work is largely based on my experience using other products

This is a great way to look at it. Now ask yourself, what if it's a new interface that people haven't dealt with before? Answer: You're conversion is going to be bad until your UX makes it orders of magnitude easier to accomplish a very important task.

I've always felt that complex software should have a "simple" and an "advanced" UI. Hiri's approach is like having a "complexity scalable" UI, but with the added benefit that the user only has to deal with those things they are really interested/ready for. The key is making it very easy for users to discover what features/functionality are available (ex., keyword search and categories, maybe even some pop-up suggestions) that matches their current task need. If you think about it like game power unlocks, it would allow a user to build on current knowledge to do more advanced things. Throw in some metrics, and you could get a good picture of which features are important to a user, suggest/highlight others that might be related, remind a user of features they haven't used in a while (or have never gotten around to looking at), etc.

Thanks for the writeup.

I like this approach as it's a slightly different way of something that's always been a dream for most designers to have UI's that evolve as you evolve over time.

I have myself an app which is very unique and have had to find ways to make people understand what is unique and why they should download it. My primary method is video and that works out fine but maybe I should try this method out.

Thanks.

My take from this is:

Know your users.

Know what features they use the most and make those prominent. Every other feature is noise.

Don't hide stuff for UI / design / style sake. Use #2 point to make that decision.

Make it extremely easy for power users to decide what features they want to show.

Last point not mentioned in the article.

Customizability comes with a price - it makes it easy to screw things up.

So include a UI reset button - either globally or for categories.

Hi all - I'm the author of this article. Happy to answer any questions you might have - Dave

> A novel approach to onboarding

I thought this article was about onboarding new employees, a difficult problem that everybody faces.

Not related to the article but the show stopper for me trying to install/test this email reader is that it won't work with just a generic IMAP server. I've got to be using Outlook or Office365 or whatever.

The lesson they learned is a perfect example of:

To sell something surprising, make it familiar; and to sell something familiar, make it surprising.

- Raymond Loewy

https://www.theatlantic.com/magazine/archive/2017/01/what-ma...

Not sure I understand what exactly is novel about your approach.

It sounds like your opening pitch was for solving problems that your visitors didn't have. That's an age old problem. You fixed that. Then, once you got a bit more of their attention, you started to elaborate on the product. This too is not much of a novelty. That's good old gradual on-boarding, "gentle introductions" and what have you.