Alan is the first 100% digital health insurance in France, and the first independent insurer to be regulated in the last 30 years.
You can learn more about us on Techcrunch.
A year ago, I left Withings to join Alan as the “first and only” designer in a team of 9 people.
Looking back on our first 9 months, here are four important lessons we learned, that helped us achieve our goal of launching a fully functioning health insurance company in just 9 months:
🤗 Be in contact with users all along the way
🏃 Start with a Design Sprint
💪 Take radical decisions
👨🔧 Build only what is needed and nothing more
Our goal was to build a product with users in mind and break with the tradition among health insurance companies of designing products around technical and legal constraints.
Even so we did not have a user research team, we needed to fully understand the users needs.
How to build customer knowledge with limited resources?
For us that meant to solely focus on building a health insurance product, and limit our target market as much as possible. We narrowed our scope to small to medium sized companies of up to 200 employees, and mostly startups.
Even on that limited scope, we still had several different types of customers:
Recruiting users for user research depends a lot of your type of users.
Doing that recruiting exercise is also a great training step. At some point, you will have to push your product to your target, so you’d better know how to get in touch.
Depending of the type of product you can:
Once you have launched and have a large user base, use your own integrated systems like Intercom to recruit and get user’s feedback.
At Alan, given our target users, we used mostly team’s network and Facebook. It worked great. We are now starting to use our user base for user research as well.
Once you know your target, and know how to get in touch with a sample of users, start interviewing some of them before working on any part of your product..
🎯 Your goals will be:
For us at Alan:
The CEO’s pain points were : Choosing / managing the health insurance is time consuming, heavy on paper work, legally complex.
They ignored most of the rules surrounding health insurance, felt it shouldn’t be their focus (it was distracting them from running the company). They did not know how to choose or compare. Most of them weren’t very price-sensitive, even if they have different opinions.
They wanted a “no brainer”; “many people recommend it, coverage is good, price is ok”.
The HR’s pain points were : Spending time dealing with employees’ insurance problems, onboarding / removing employees, integration to the payroll system. They felt it was repetitive and an unnecessary duplication of informations.
And so on…
Interviewing users is a team effort, everyone should pick people they know (in the target), and ask questions. It needs to become a habit.
Doing this will help you understand which features of your product is central and needs to be worked out perfectly, and ensure that you are building a product that has value.
To give you an idea, our CEO, Jean-Charles Samuelian, talked to 30 to 40 CEOs / HR specialists before we started working on the product.
Afterwards, we performed 5 people tests at three different times on the “onboarding for companies” process only.
We’ll explain how to conduct a proper user testing in a dedicated article.
In the meanwhile, just get a few users, ideally 5.
Have them try your product with just a small introduction.
Don’t say more than a final user is supposed to know.
Talk as little as possible, and let them use it.
User tests are great way to get the discussion started and users involved with your project.
At Alan we have always conducted at least a series of 5 to 10 user tests for every release of any major piece of interface. We made critical decisions based on those.
The “Design Sprints” methodology has been put together by people with decades of experience in ideation (now working at Google Ventures) as a way to help companies find the right solutions to the right problems. As they describe it:
“The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers”
At Alan, the sprint helped us do just that.
But it is also great for other reasons, especially at the beginning of a project because:
As a result, it will put you on the right track to think your product long term.
If you want to know more about this method, it’s here.
We were considering designing 100% of the discovery of our product / onboarding process as a conversational interface. Our first round of tests had left us under the impression that it was really powerful from a user standpoint.
Screencast of our conversational discovery / onboarding prototype
It was also shiny, new, fashionable and very different from the competition.
We loved it.
On the second round of tests, although the feedback was still positive and we had successfully solved part of the problems, we realised that it would not drive a significant impact on conversion (note that on prototypes, it’s rarely possible to have quantitative data, so this is more of a qualitative, gut feeling perception).
The technical difficulty would have grown exponentially along with the complexity of the product (more and more possibilities are difficult to manage conversationally), and it raised interaction challenges (conversational is a very new type of UI, without many established patterns to work on).
We decided that although we loved it and it was interesting, it was not valuable enough to spend months solving design and technical challenges around it since it would not be a game changer.
We decided instead to go for a more traditional approach and build simple pages that would present our product and a more traditional step-based onboarding. It allowed us to:
Since we were able to launch just in time and did multiple iterations on that part of the product in the first few months, we clearly made the right choice.
Radical is not good in itself, but it is important as a team to be able to see through personal desires, cut short and be able to trash a few weeks of work if necessary.
Everyone knows the words “Minimum Viable Product” (MVP).
Few are capable of applying it well, because it is so difficult to understand what “minimum” and “viable” mean. Answer: it really depends on your users and the type of products you are building.
It does not mean build something shitty or ugly; it has to be “viable”, remember ?
“Viable” has to be taken in conjunction with your targeted users and the type of product your are building. It can be summed up like that:
For example, when the Sony Walkman launched, it offered a very poor audio quality compared to discs or radio. But it was not a problem; the walkman was the only way to get audio while moving, and “poor quality” was much better than nothing. Audio quality was not MVP.
Later, as nomad audio became the norm and audio quality a differentiator, audio quality became MVP to all nomad audio products at a certain level of price.
It means you need to carefully select what “minimum viable” means to your product.
Imagine you are in 6 month from now.
Your product failed.
Why did it fail?
Then ask yourself how you can test solutions to all those problems using the minimum possible amount of resources. Don’t rush doing code or looking for technical solution, sometimes an email or a phone call is the most efficient to test an assumption.
Everything you can avoid to build and test is great.
Once again, what you can fake depends on the product you are building.
On that regard, insurance has some interesting characteristics:
We fully automated the essential use cases.
For the rare use cases, we faked automation.
Alan’s very first beneficiary dashboard version.
Because we were not waiting for explosive growth at the very beginning and were counting on a low contact rate, we could fake in a nice way. There would be buttons in the interface, like “add an administrator”, or “hospital care”, or “remove a user”, but instead of triggering an API call, it would just open a chat box with a pre-filled message (we use Intercom, an integrated chat accessible from every page in our webapp).
It allowed us to:
Some features will never be automated, because they are so rarely used it will never be worth the engineering time to automate them.
It doesn’t matter!
The experience is great, our response time on chat is below a minute.⏱
Building an insurance is building lots of “blocks”.
By building only portions of the product when needed, we were able to launch very early.
🗓 To give you an idea:
We effectively cut down “launch an insurance” in 3 large sequential launches allowing us to meet important deadlines (companies willing to switch their health coverage for ours needed to do so before Oct 31st), test, and improve step by step.
After that first year, what is to come?
Alan is doing really good and we are growing very fast.
My next challenge as the “one and only” designer in the team is not to be the “one and only” designer any more. Grow a team that manages to keep the practical knowledge and proximity to the users, as well as maintaining team spirit and collaboration at top level.
Maybe more on that later!