4 designer’s tricks to launch an online insurance in less than 9 months

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.

1*JU0E22FnicubqIWZ2Ly0fw

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

🤗 Be in contact with users all along

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?

1* lsOVimLEUHXs3m23QSXTQ

1. Limit the number of customer types you will be targeting at first

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:

  • CEO: for small companies, CEOs choose the insurance and manage employees
  • Head of HR: they are professionals of the subject, they have technical questions and go into deeper analysis
  • Employees: Our final user! They will interact with us on a regular basis, have a highly variable knowledge of the field

2. Find your users

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:

  • Use your team’s network and yours
  • Find them in the streets; Go to the nearest Starbucks and offer coffee for questions; People are very welcoming in general; Present yourself, explain your situation.
  • Post on Facebook, Linkedin, Twitter, Instagram, asking for 20 min to anyone fitting the description. Ask your team and friends to do the same.
  • Use ebay, craigslist, leboncoin, and offer vouchers against time.
  • Last resort: recruiters.
    Some recruiters are specialised in finding people in a certain target, it costs about 100€/user in Paris. I really prefer the first 3 options though.

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.

3. Talk to them before doing anything else

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:

  • Understand their pain points
  • Assess their knowledge of your field
  • Get pricing insights
  • Understand their process in taking decisions

For us at Alan:

CEO

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

HR

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…

1*42Lz5Tslo14UJEg5pzIg7A

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.

4. Test your product even in early stages

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.

  • Test using prototypes to check if your assumptions are correct. You can use inVision for instance (we even used Keynote).
  • Do tests on the final interface before releasing any major piece of your product to look for glitches, friction points and optimise the copy.
  • Always have a few days available after the test to implement changes.
    Otherwise, it’s useless.
  • You can also get feedback from users on things such as branding, logo or value proposition.
  • Try to engage with your users during the test as partners, they are your future customers.

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.

🏃 Start with a Design Sprint

1*CKMtIkAXKGoqie4-AbjaFA

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:

  • It helps you build a strong team spirit and kickstart your project. During those five days, we learned how to interact with each other, how to build together, and how to deliver something that made sense to all of us.
  • It contains all the basic elements for good product thinking; Identify key problems, imagine solutions, push solutions through rapid design and prototyping, and user test.
  • A “design sprint” is a collection of useful tools for team work that we’ve been using on a regular basis since then for other purposes, like when we roadmaped our next year.

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.

💪 Take radical decisions

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:

  • Move fast, not spending time solving tech / design challenges on that part of the product
  • Iterate fast, since it was a lot easier to iterate on simple pages than a conversational interface
  • Be innovative on the content and on the flow since we were not exploring totally new technologies

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.

👨‍🔧 Build only what is needed and nothing more

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.

What it does not mean

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:

  • If your user is not in the absolute necessity to use your product, or can find another product that fills the same need very easily, experience is key to your product and having great UX / UI is MVP.
  • If you are in a space with no / few competitors and offering something of immediate value to your user, having great UX / UI is not MVP; you just need an good enough experience (don’t spend time building expensive custom UI, don’t spend money on pricey design firms to build show off UI).

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.

1*BFCMGg3hjrCPy8gvZBM8yQ
The History of the Walkman — The Verge

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.

What it means

It means you need to carefully select what “minimum viable” means to your product.

How ?

Imagine you are in 6 month from now.
Your product failed.

Why did it fail?

  • List the reasons why it failed, based on your understanding of the space from your user interviews
  • Use that to define what you’ll need and when you’ll need it

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.

How we did it at Alan ? We faked as much as possible.

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 wouldn’t face an explosive growth
    Choosing an insurance is a process that takes time, making contact and getting your brand out there does not happen overnight. We wouldn’t go from a 100 to 100.000 users over a month.
  • Few essential use cases
    We have a few use cases that would represent 95% of how our users would interact with us at the beginning
  • Lots of rare use cases
    That’s what users will want to do the other 5% of the time.
    It does not mean it’s not important! (they are sometimes very important)
    Just that it wouldn’t be performed on a regular basis.
  • Low contact rate
    Health insurance is not an everyday product.
    If the essential use cases are well taken care of in the UI, contact rate will be very low.

We fully automated the essential use cases.

For the rare use cases, we faked automation.

1*vumKDVsJoaPNXioWyYbLYA

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:

  • Cover 100% of use cases overnight from a user’s perspective
  • Prioritise future development based on quantitative data on which rare use cases were most used
  • Measure the time it took us to deal with the demands manually
  • Better understand the user’s needs;
    Some use cases had complex ramifications, raising lots of questions on the way we should deal with them. We had the opportunity, talking with users, to understand in depth what the most important use cases were and not do hypothetical designs.

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.

We only built what we needed when we needed it

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:

  • Jun.
    We launched a “wait list” page. No logo, no branding.
  • Aug.
    Branded “wait list” page.
  • Oct. 23th
    We got authorization from the regulators to be an insurance
  • Oct. 24th
    We launched the commercial website on the following scope; A user can understand what Alan is, can register their company with limited options
  • Nov. 15th
    We updated on the following scope; An admin user have access to a company dashboard, an admin user can invite company employees to join Alan, an employee gets an email and can register but can’t do more.
  • Dec. 1st
    We cover a small number of beneficiaries. Users can add spouse and kids, send us documents, have access to some advice on health care.
  • Jan. 1st
    Implemented billing to bill December bills. We cover a much larger number of customers (solved most of the problems met by our first wave of users to avoid a large contact rate).

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.

Conclusion

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!

Please feel free to share, comment and contact us to improve our methodology!