The Application is the Product; Make it Simple, but Maybe Not So Short
Part 6 of the Insurance Onboarding Series
Can you imagine building a successful business selling a product that people ignore? Shipping them a package that they never open? That’s insurance. And immigration. And taxes, permitting, licensing, and more. In industries with middle-men where the customer is primarily pursuing a status like “covered,” “filed,” “legal,” “licensed,” or “approved,” the product being sold (in our case, the insurance policy) is rarely a big part of the user’s experience of your business.
You know what is a big part? The application and quote.
One quick question
I joined Vouch, a startup selling business insurance to technology startups, as their first hire. In the earliest days, when we were still choosing a name, building the team, and getting licensed to sell coverage, we had a board member who often posited “What if it was just one-click? One question, and you could buy insurance?”
This was a tantalizing prospect for a designer trained to make things frictionless, and initially sounded like a worthy goal.
Our competitors were rocking applications that were forty to sixty questions long, and read like they were written by a very suspicious robot-lawyer. We knew we could do better. With a mix of data integrations that basically answered questions on behalf of an applicant, and some serious word-smithing, we managed to create one application that worked for all 10 of the coverages we planned to sell, that was 16-20 questions long.
But that’s where we stopped - far short of our board member’s “one question” goal.
If you’re building a product that gets ignored after purchase and is really more about getting a status like “covered” or “approved,” here are some things to consider before you dramatically shorten your onboarding or application;
It’s likely one of the largest chunks of “face time” you’ll get with your customer. That application process is your first chance to establish a relationship, learn about your new customer’s most recent insurance experience (so you can reset their expectations appropriately), and demonstrate your tone and vibe with the customer.
Your application is your voice. If you’re “disrupting" an industry with middle-men, you’re using tech to do what was classically done by a guy in slacks. Do you want to sound like the guy you’re disrupting? You might. But you might also want to sound markedly different. What you ask about, and how you phrase those questions, is helping your customer suss out “who sits behind their laptop screen” so to speak.
It’s also how you mimic your customer’s voice. Say you’re writing an application that only asks questions that can be answered with paragraphs custom written by the applicant in big empty text boxes. Well that sounds like a hell of a lot of work, so in most cases, designers try to provide the common answers they expect to see, whether that’s yes or no, or a list the applicant can select from.
Those answers - that’s us putting words in our customer’s mouth. The button labels the customer has to click to advance to the next screen - that’s them talking too. We’re writing a dialogue on the page - our question, their answer. If we provide answers in their words, it’s easier for them to move quickly and confidently through the application, and helps the customer feel like they are in the right place.Customer-reported data is uniquely valuable.
How your customer describes themselves, in their own words, teaches you a lot. The number they copy-paste from their bank account, decimals and all, instead of settling for your close-enough prefilled answers, the quick answer describing how they categorize their business, or how they feel about their taxes this year - you’ll never know if you don’t ask.
The application is part of how they infer what the product is all about. Say you’re a founder renting desks at a nearby coworking space, applying for the Business Property coverage the landlord requires. If an application question asks “What is the age of the office roof?”, then you’ll assume the insurance policy - which we know you’re probably not gonna read - has something to do with the roof of the WeWork you’re renting desks in? You’re on the third floor, and it’s a seven story building. You just wanted coverage for your laptops and stuff that might get swiped while you’re grabbing coffee.
The application questions are helping you understand what the policy might be about. If you hid all of those questions, and answered them with a data integration, your customer would know a lot less about the product they plan to ignore after purchase.Tailored costs more. To get a suit that fits perfectly, you endure the slowness of being measured. A slightly slower onboarding denotes a bespoke, premium product, and shows the effort needed to do things well.
That effort becomes an exchange all its own. I often asked our partnership team why we needed to create one-pagers and presentation decks to attach to emails when my design team could easily spin up an interactive landing page on our website. It’s not just customary - it demonstrates work. A tit for tat that builds rhythm of giving and requesting well before a big deal is won.
Designers intentionally add minor delays in products, kind of a like a drumroll before a grand reveal. Depending on the price of the product being offered, you may need a bit of a drumroll to build up that perception of grandness.Personalization requires proof. You can’t sell a product that you claim is personalized and not collect and display everything you know about the customer you are selling it to. This was doubly important at Vouch, where we were selling to founders, who notoriously believe that the precious thing they own - the startup that they are building - is unique.
If we had created a one-question application, we would have made our product feel “off the shelf,” making it easier for competitors to claim their product was a better fit.
Too much, too little, just right
And here we have another one of those “Goldilocks problems.” Making insurance applications short and simple is a worthy goal to some degree, but there is a line past which it’s too hot or too cold.
Your application is a major part of your customer’s experience of your product. It’s where you establish your tone and mimic the way your customer speaks, hopefully reinforcing that they are in the right place. It’s where you communicate how personalized your product is, tease what it might be about, and build toward the high price you might charge for all of that custom tailoring. And it’s where you demonstrate the work you did, so that your customer might do a little work for you.
Remember in a previous post where I said to “avoid delight” in insurance product design? I’m not going so far as to say “avoid making it frictionless” too. A good tailor knows how to make the slow experience of being measured feel good. Make your application feel good…but maybe not so short.
Halfway through the series!
Carrie
Ready for Part 7?
Risky Business; Dealing with Applicant Rejection
In the last post we talked about the application and the many roles it serves in insurance products, other than simple data collection. Today we’ll focus on the most challenging feature of an insurance application; full rejection by the company; in which the application ends by saying to the applicant “We don’t feel comfortable selling you any coverage.”…
🤔 Why am I writing this series?
We need - and especially America needs - more designers, product people, and strong tech talent to care about insurance. In this short series, listen and learn how the major customer-facing touchpoints of insurance work so that you can get involved in fixing the mess. Start here, with a deeper read on why it matters;





