A novel approach to onboarding(blog.hiri.com)
blog.hiri.com
A novel approach to onboarding
https://blog.hiri.com/a-novel-approach-to-onboarding-4a6c952a3e62
40 comments
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.
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.
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.
I've come to associate those things with snake oil. They're right up there with "Free trial, but you need to put in a credit card." Sure, some legit services use those techniques, but they're a red flag that they might be a pain to deal with if you choose to back out.
A lot of legit services take a cc with trial sign up to separate the people who might pay from the people who would pay if it was the right solution. The right thing to do when taking a cc for a trial is to send reminder emails that they will be charged.. Which not enough do.
I see more and more startups using stripe, between that and the ability to do chargeback with that cc company, I worry less about it. The chargeback dispute is quite powerful.
I see more and more startups using stripe, between that and the ability to do chargeback with that cc company, I worry less about it. The chargeback dispute is quite powerful.
> The right thing to do when taking a cc for a trial is to send reminder emails that they will be charged.. Which not enough do.
Not sure about that. Wouldn't the "right thing to do" be to not auto-renew the account? Suspend the account after the trial until the user logs in and confirms the renewal?
Not sure about that. Wouldn't the "right thing to do" be to not auto-renew the account? Suspend the account after the trial until the user logs in and confirms the renewal?
> The right thing to do when taking a cc for a trial is to send reminder emails that they will be charged.. Which not enough do.
> Wouldn't the "right thing to do" be to not auto-renew the account?
I suspect we sometimes conflate "right" and "convenient". I am curious, don't most people (especially those with technical chops) just drop a calendar event as a reminder?
> Wouldn't the "right thing to do" be to not auto-renew the account?
I suspect we sometimes conflate "right" and "convenient". I am curious, don't most people (especially those with technical chops) just drop a calendar event as a reminder?
Those would also be good ideas.
The worst scenario is when the subscription begins and the user has forgotten the cancelation date. A link could be embedded in the email to say yes or no. It must be profitable not to do this for some.
The worst scenario is when the subscription begins and the user has forgotten the cancelation date. A link could be embedded in the email to say yes or no. It must be profitable not to do this for some.
- (probably) team upvote boost to trigger front page
Nope - the HN algo would murder us for this. Don't risk it.
- 50% off promotion ending in ~4 hours with the tagline "you'll never see this offer again". You'll see this if it's your first visit to the site, been that way for a while. But that's another article...
- 50% off promotion ending in ~4 hours with the tagline "you'll never see this offer again". You'll see this if it's your first visit to the site, been that way for a while. But that's another article...
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 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!
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.
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.
For users, perception and interpretations can definitely be reality.
+1 for the use of mental models.
+1 for the use of mental models.
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.
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.
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.
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.
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.
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.
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'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.
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.
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.
Rather like how game tutorials work with locked-down interfaces and gradual introduction of more mechanics.
> 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.
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.
Users want to be able to onboard at their level of familiarity and competency and move forward.
It's kind of like how users grew up with Facebook, it began simple and became complex over time. Except allowing users to onboard at any point in that timeline.
It's kind of like how users grew up with Facebook, it began simple and became complex over time. Except allowing users to onboard at any point in that timeline.
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.
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.
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.
How did the video work? Any words of wisdom?
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
You can see it here.
https://www.youtube.com/watch?v=FfrNrkyGw_k
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.
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.
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.
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.
That's very unusual, normally IMAP is the easy one and Outlook is horrendous. What does it use under the hood?
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).
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...
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.
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.
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.
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.
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.
You can innovate on a known concept by using it in a novel way. I believe that's what's happening here, and I find the idea intruiging, smart and novel indeed.
I think an added benefit is that it makes it trivial to see what are indeed the benefits of the tool : it's what you expect from an email client plus those things, nicely presented together. Just by reading the article and seeing the screenshot, I could evaluate if I was interested in this tool, which is a very rare thing.
I think an added benefit is that it makes it trivial to see what are indeed the benefits of the tool : it's what you expect from an email client plus those things, nicely presented together. Just by reading the article and seeing the screenshot, I could evaluate if I was interested in this tool, which is a very rare thing.
Nice out-of-box thinking, I think. But I wonder, ...
If there's nothing novel in the initial version why would people think they would want to switch? What would be the reason?
Could it be that your product without any unique features is cheaper than competition, and adding features costs something?
If there's nothing novel in the initial version why would people think they would want to switch? What would be the reason?
Could it be that your product without any unique features is cheaper than competition, and adding features costs something?
- 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!