
A novel approach to onboarding - kevkav
https://blog.hiri.com/a-novel-approach-to-onboarding-4a6c952a3e62
======
rekshaw
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!

~~~
ntumlin
Not to mention every comment dpower has made is on a post related to Hiri.
Maybe HN should just explicitly allow and tag accounts made to promote a
company. It makes sense that people who create products want to talk about
them, and they can certainly have valuable advice or insights. That might give
them a platform to share more without people feeling there's some hidden
motive.

~~~
dpower
I'm a lurker, not a poster for the most part. And as you can see from our
blog, we don't write that often. We don't really do content marketing. Any
revenue we make as a result of this post certainly won't cover the time I've
spent writing it. Hiri is a bit specialist.

Would be happy to tag the posts - think it's pretty clear this is a company
blog though. Your point is well taken/made all the same.

------
objcts
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!

~~~
kevkav
I completely agree on the feelings map. It isn't something that you could rely
on and take meaningful actions from the data.

However, it is useful to consider the fact that people's experience and
comfort isn't linearly increasing with time. Understanding that there are
peaks and troughs can be useful for user experience design.

------
Animats
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._

~~~
Animats
This is something you could A/B test. Some new signups get the old interface,
some get the simplified one.

There's a famous failure of this approach. Many years ago, there was a
Macintosh graphics application designed by Kai Krause. It started out with a
very simple interface. After you'd been using it successfully for a while, a
new tool would appear. As the user demonstrated competence to the program,
more tools would unlock.

Users hated that. When a rumor started that Krause was going to redo the API
for Photoshop, user groups petitioned Adobe to stop him.

~~~
crooked-v
The big difference in the described case, of course, is that it's the user in
control of the on/off toggles rather than it being uncontrollable.

~~~
marcosdumay
Microsoft Office extensively tried that one too. I have never met anybody that
liked their hidden menu items, but it didn't get such an strong reaction as
that Apple app.

------
Belphemur
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.

~~~
kevkav
Thanks @Belphemur. Modular is a good way of putting it. Being modular allows
users to add complexity at their own pace and never be overwhelmed by it.

------
darkerside
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.

------
pjc50
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.

~~~
pmontra
> People expect an email client to work a certain way. Our unique features
> made us too different. They made the interface unfamiliar

Agreed. It applies to many fields, also to programming languages. Elixir and
Phoenix were designed ostensibly to look like Ruby and RoR and onboarded many
developers from those environments. Still some parts of Elixir are too Erlang
-ish. Example: the cryptic handle_* methods of GenServer. They could have had
the courage of using a class like notation, make them crystal clear for the
vast majority of developers and grow much more.

------
AndrewKemendo
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.

------
cowb0yl0gic
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.

------
ThomPete
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.

~~~
talkingtab
How did the video work? Any words of wisdom?

~~~
ThomPete
The video just showed how the notes app is different than others. Which it
really is.

You can see it here.

[https://www.youtube.com/watch?v=FfrNrkyGw_k](https://www.youtube.com/watch?v=FfrNrkyGw_k)

------
vezycash
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.

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

------
gwbas1c
> A novel approach to onboarding

I thought this article was about onboarding _new_ _employees_ , a difficult
problem that everybody faces.

------
john-foley
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.

~~~
dpower
IMAP is on the way (I'm using it now) but not quite ready for showtime. If
you'd like access to the upcoming beta email dave (at)hiri(dot)com.

~~~
pjc50
That's very unusual, normally IMAP is the easy one and Outlook is horrendous.
What does it use under the hood?

~~~
kevkav
You're right. It is unusual. We went with Exchange Web Services first instead
of IMAP. Our initial target market were larger companies and we wanted to have
deep integration with their Exchange servers (Calendars, Contacts, etc).

------
andrenotgiant
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...](https://www.theatlantic.com/magazine/archive/2017/01/what-makes-things-
cool/508772/)

------
huhtenberg
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.

~~~
dpower
We stripped every feature that made our product different and put them in an
'app store'. This was a huge change (a lot of work and a big risk), and not
something I've seen others do as an on-boarding strategy. Thus, novel. I
believe this approach could be repeated by others. It's a far cry from the
usual walkthroughs, carousels and prompts.

~~~
huhtenberg
So basically putting advanced features into a separate section, making them
togglable and calling this section an App Store?

They are still mentioned on the homepage and in a form of a carousel at that.

I appreciate that this must've been a significant rework, with all edge cases
considered, but sectioning off parts of a software and making them
discoverable in a course of normal use is not exactly novel... I mean that's
just too bold of claim to be thrown around lightly. The story is still
interesting, but something a bit more exact like "Here's what worked for us
remarkably well" would've been more suitable.

