American Family Insurance
“We want to be the Lemonade of Commercial Auto insurance.”
– the interview hook that sold me
Lemonade leads a growing list of digital-first providers disrupting the personal insurance market by replacing agents with clean web apps that ask fewer questions – written in English, not insurance jargon. Complete a short form, purchase, done. You’re insured.
Next Insurance has applied this model to small business insurance. But a small business owner can’t just pop online and purchase a commercial auto policy (business insurance for work vehicles). No one’s created an automated solution for that yet. Many in the industry don’t believe it’s possible.
But this management team had a history of startup successes, and I instantly connected with them. I was confident that we could do it.
Several insurance companies have commercial auto application forms online. But they just collect your information for an agent to contact you.
That feels very bait and switch.
Our product would be an application, not a simple collection form.
The goal was to produce the first commercial auto quote that can be directly purchased by customers right after completing their application.
The first challenge: Applying for coverage is a Process with a capital P
Business customer information is gathered by an agent through various methods. Many are disqualified during this intake process; the ones who initially qualify will be reviewed.
Applications are reviewed before being sent to underwriting. A business owner might expect days of requests for additional information about their business, employees, and vehicles.
Proprietary software determines eligibility and pricing based on rules and risk analyses. But underwriters are likely to clarify details with the customer before making a final, human decision to approve or deny.
That’s a lot of human touchpoints to automate.
The market opportunity
Commercial auto insurance for small business is a market that’s imploding. Every few months, another insurer stops selling it because they’re losing money. But small businesses are the largest growth market, and four out of every ten vehicles operated by them aren’t insured – an opportunity worth billions.
The reason this product makes sense, is because it would only work for a segment of the market that’s very low risk and low maintenance. In other words, the most profitable segment.
The product plan
Let’s be clear: this won’t be Lemonade. But I’ll go into that below. We were building a consumer face on top of our underwriting platform. That platform analyses risk and calculates pricing, so a small percentage of ideal candidates should be able to directly purchase a policy. With proof it works, we’d continue making improvements to our product.
Using the underwriting platform as our backend meant that our first release would have a lot of form fields. But we knew that going in, and had an iterative plan to address the issue moving forward.
How we’d accomplish it
We began like a small startup within the Seattle office of Homesite, an American Family subsidiary. It was an experiment, aiming to replicate the rapid progress and accomplishments of small, focused teams. It felt like a startup; meetings were short and purposeful, communications were limited to our team, and early sprint successes made an impression.
My role
My arrival was the unofficial start of this project, which hadn’t been funded yet. I quickly became immersed in the insurance industry and the prior research and special challenges related to this product. I then created conceptual designs, and co-led biweekly presentations and discussion in front of 20-30 director-level leaders, managers, and members of the tech team, and our in-house client, the insurance product team. The success of those presentations greatly contributed to funding approval, and we began building a development team.
I led the product design and strategy, producing all work myself for the first eight months. I then hired another designer that I managed.
I created all of the screen designs and deliverables chosen for this case study unless noted.
4 out of every 10 vehicles operated by small businesses aren’t insured.
That’s a market opportunity worth billions.
Concept designs and reality checks
Lemonade had established a vision of what’s possible. It’s what everyone in our group desired the commercial auto product to be: a clean design aesthetic, a limited set of questions to answer, followed by a hassle-free purchase experience.
We weren’t going to build that vision, though. Not now, anyway. We were an insurance company building a tech product for highly complex business insurance. Lemonade is a tech company that raised $500 million in funding over 5 years to build an AI-heavy insurance product for comparatively simple personal insurance. Perspective.
The goal of the product we’d build is to prove it can work. If successful, we’d be able to iterate over time into something closer to our shared vision.
But, what might a Lemonade-inspired commercial auto product look like, and what can we learn from conceptualizing it?
Quite a lot, as it turned out.
A couple of the things we learned
While researching Next Insurance for this exploration, I realized that their coverages are limited compared to other business insurers. This likely means they’re able to achieve success with a Lemonade-like model by only being a good match for low-risk businesses that have simple coverage needs – a hypothesis supported by several business insurance reviewers on YouTube. It follows that fewer options also have performance optimization benefits for their technology, which we could also learn from. Response times eventually became a serious issue for us, partially because of so many options that trigger pricing recalculations. I’d cycle back to lessons learned here on several occasions.
Our long term plan is to prefill enough information throughout our product from data services, that applicants would only have a few remaining questions left to answer. But a debate whether to show applicants all of the information we’d discovered, or only show them what’s necessary, continued to resurface. This concept helped visualize the argument that less is probably better.
These are issues I would have loved to research, test, and work on.
The product we’d (start to) build
I arrived at the overall design to satisfy a business requirement for a white label product that would be used by all of AmFam’s subsidiaries, and other insurers such as Geico and Progressive under license.
It’s also a mobile-first solution. Few people are likely to complete this long form on a phone. But if planned future iterations are successful, phones could become the primary use case.
It seems strange to say, but we anticipated that the product we were building would probably only have a 1-2% success rate. And that was okay. Because that would mean we’d proven we could sell a commercial auto policy online, and future iterations were assured.
Some elements of the navigation sidebar were contributed by another designer in this, and other screen views.
Product features
The header and sidebars [A] are fixed, providing easy access to controls and features; only the central column scrolls.
Sidebar navigation [B] was conceptualized as a multi-purpose app within an app: Its most important role is to unify multiple (bundled) insurance quotes and products from business partners. Previous bundle packages would bounce applicants through a succession of forms, with no idea where they were in the process. Running on a new platform, this solution would unify all business insurance quotes into one seamless experience.
In the initial release, fields would auto-complete for some items, such as vehicles [C], after applicants entered its VIN number. In future iterations, we’d work to prefill most of the fields throughout the application form with information from data services. The goal is for applicants to mostly be reviewing the form, rather than filling it out.
In response to common complaints from agents about challenges they face preparing quotes, I proposed a suite of agent tools [D]. These tools would not be part of the initial release, but I’ve added them here to demonstrate how I think about product design in terms of scalability for future features and integration with other products. Advanced features and integrated products often have nowhere to ‘live’ within apps that hadn’t anticipated the realities of growth, partnerships, or acquisitions.
Forms were an unexpected challenge
I’d designed several enterprise SaaS products and business tools, so I was very familiar with forms. But prior to this product, they’d never been something I had to research solutions for and map to datasets to make sure they’d work.
The underwriting platform serving as our backend, and the raw data that fueled it, had descriptive text in addition to field labels, and used an inconsistent mix of popovers, checkboxes, and radio buttons for selections. Everything had also been written for underwriters, so industry speak was everywhere. I couldn’t change the backend, but had to figure out something more consumer-friendly. This had become an interface and language translation project, not form design as I’d previously known.
Snippets of the underwriting platform.
Solutions
I determined that fields with static infield labels would solve the problem of having, or needing descriptive text in addition to field labels, making it simple to create groupings of related fields. All selections would be dropdowns, with a few unavoidable exceptions. I also established alternate text requirements so that descriptions and labels could be understood by consumers. My team and product managers wrote the new copy, and there was a lot of middle-tier work to make these frontend changes work with the backend.
Alternate text was added to the data files so that questions, descriptions, and labels could be understood by consumers.
Examples of the form field final designs
Large text and lots of padding increased page lengths that were already long. But it was an informed consideration for better usability and for aging vision. The average age of small business owners is 53, while the average age of insurance agents is 46.
Advanced feature designs
In future iterations of the product, we’d minimize the number of fields that applicants need to manually complete by acquiring information from data services. But that information was expensive, and not always complete, so we continually researched additional ways to either acquire data, or ways to help customers make more accurate manual selections.
– section in progress –
Design system
“We’re not going to be able to integrate that.”
“But there’s another solution that will work.”
Things don’t always (seldom?) work exactly the way we want them to in product design and development. One of the hallmarks of creating a great designer-developer relationship that I learned in startups, is a willingness for both to find compromise that achieves a goal without creating disruption, or worse, slow-brewing resentments. So I worked with a developer to build our components in Storybook.
The ability to be flexible and easy to work with pays off for those times when compromise isn’t an option.
Communication and collaboration
The high-level result of a weeks-long workshop including the UX team, front end and middle tier development teams, product managers, and stakeholders to define the commercial auto product roadmap and estimate realistic timelines for both an MVP, and for the final product.
Communicating design is great. Design collaboration is better.
Time management was crucial in startups, so I learned to create just what’s needed to communicate designs. But I’d discovered additional, unexpected benefits to this practice.
With simple, low-barrier documents like this flow diagram, our non-tech stakeholders were better able to follow discussions, and make edits and suggestions. And our dev lead appreciated simple documents, because I was showing him ‘what has to happen, not how to do it.’ By approaching documentation with a collaborative mindset, rather than just trying to communicate the design, I save a lot of back-and-forth time, resulting in a better product.
Cultivating inclusion and informed decision-making
Our in-house client, the insurance product team, wasn’t used to working with designers and development teams.
From previous experiences, I’d learned the value of creating documentation that explains the choices design and development have made and why, or to plainly describe options for decisions we need stakeholders to make.
It’s more effort than firing off an email. But I’ve found it creates a better sense of client ownership, teamwork, and basic goodwill. The product also benefits from better-informed decisions.
The end of the commercial auto road
Just months into product development, the managing director leading our product left the company. There were two rounds of leadership change in the following months. One day, we were informed that our work on commercial auto was “done, for now,” and we’d instead focus on redesigning the existing business insurance products. Then the pandemic hit, and our in-house frontend dev team left one-by-one.
The pivot detour
It was always the plan that we’d rebuild the dated business insurance quotes after commercial auto had launched. That plan changed.
The pivot to business insurance products, offshore development, and a “hybrid” platform solution
Commercial auto had been designed for a new platform being developed simultaneously by our hosting solutions partner. But they’d fallen behind schedule. We’d already lost time, and changed priorities to regain momentum, so a management-level decision was made to build our new products on top of the legacy platform that hosted our existing business products. A platform that had been sunsetted six months earlier.
Aside from some aesthetic compromises, the decision wouldn’t greatly affect the design work my team had already done for commercial auto. But some features and interactions that defined our product as a modern app were out. We didn’t know what the full impact would be.
The original new platform design
Created for a new platform, our design included a sticky header and sidebars, with advanced navigation features. The right sidebar had been designed as a multi-purpose space, displaying different things to consumers and agents.
Visually similar. Under the hood, no so much.
As built on the legacy platform
Owing to the simplicity of the commercial auto design, the move to the legacy platform appeared to be an easy transition, but there were hidden problems. A pain point for me was that the entire page scrolled with the form.
The business insurance product lines
The business insurance products (or lines) consist of four individual insurance protection plans for small businesses, including Business Owner’s Policy (BOP), General Liability (GL), Workers’ Compensation, and Umbrella.
These flows include work by another designer.
We were designing and developing multiple business lines simultaneously, continually adding new features and updating existing ones for each. Master flow diagrams were created, but there were hundreds of path variants based on individual selections. Creating and continually updating diagrams for every variant was unrealistic, so we designed and documented individual paths from the point of deviation until it rejoined the master flow.
There were a surprising number of obstacles trying to communicate designs to the offshore development teams. And with only one other designer and myself, we simply didn’t have availability to maintain an organized developer guide in addition to our workloads and meetings. We needed an all-in-one solution that would allow us to share designs for review, comment, approval, development, and QA. So Confluence became my best option, which meant that we’d be doing a lot of additional old school redlining.
Edits and updates were also posted on the same page, newest to oldest, allowing us to easily track version histories. It wasn’t a perfect solution, but it worked, and provided easy insight to process for the insurance product teams and senior management.
These pages include work by another designer.
All basic interaction details were also captured and shared in Confluence:
– additional examples in progress –
Scope creep: new and enhanced features, and partner product integrations
Aside from some occasional maintenance, the original business quote products had remained more or less the same as the day they launched six years earlier. But the insurance industry is dynamic, constantly changing. So one of the primary reasons to redesign the legacy business insurance products was to add new policy coverages and other improvements.
At some point, we’d quietly stopped building an iterative MVP product. Everything was now expected to be fully complete before release.
But as more features continued to be added and modified, the further our release date kept being pushed back. So we never really finished working on products that had been in development for over a year.
Conclusion
This section is in progress.