American Family Insurance
“We want to be the Lemonade of Commercial Auto insurance.”
– the interview hook that sold me
Lemonade and Next Insurance lead a growing list of digital-first providers disrupting the personal and business insurance markets, by replacing agents with AI-powered web apps that are much simpler than typical insurance forms. Answer a few questions, purchase, done. You’re insured.
Business owners can apply for a commercial auto policy (insurance for business vehicles) online, but they can’t purchase it. They fill out the form, then an agent contacts them to complete the process. We’d planned to change that.
The challenge with creating this:
Is this:
Applying for coverage is a Process with a capital P
Business customer information is gathered by an agent manually or from online application forms. 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 analysis. But underwriters are likely to clarify details with the customer before making a final decision to approve or deny.
Creating a first-to-market product
The project
Lemonade established the vision for the future of Insurtech: clean design with limited questions, hassle-free purchasing, and automated claims. But we weren’t going to build that vision. Not to start with, anyway. For context, we were an insurance company building a tech product for the most complex business insurance. Lemonade is a tech company that raised $500 million to build an AI-powered product for comparatively simple personal insurance.
Many in the industry didn’t believe commercial auto could be automated. Our goal was to prove it’s possible by building a consumer app on top of our smart underwriting platform. If successful, an AI-based product could be our next big project.
My role
I was the first hire, brought in to help secure funding by producing conceptual designs. I quickly became immersed in the insurance industry and details of this coverage, then created and presented designs bi-weekly for several weeks to senior management, members of the tech team, and our in-house client, the insurance team. The presentations were successful, and we began building a product team.
I led all product design and was part of all strategy decisions, even operating as one of the Scrum product owners for a time. I produced all design for the first eight months, before hiring another designer that I managed and mentored. All work chosen for this case study is mine, unless noted.
Selling the vision
Before our project was funded, I was hired to visualize product concepts and create prototypes to help convince stakeholders that this could be done.
Ideation & funding phase
Addressing stakeholders’ data quality concerns
Agents and underwriters clarify details of an application before making a decision to approve or reject coverage. But an automated quoting platform has to make this decision based solely on the information provided, so the quality of that information is crucial. For example: a qualified business owner guesses at an answer they don’t understand, and are denied coverage as a result. That’s a bad outcome for everyone.
Design solutions that help clarify ambiguous choices could avoid many of these data quality issues, and I presented several concepts during the ideation phase.
Ideation & funding phase
Rapid concepting for requirements gathering and building enthusiasm
Our in-house client, the insurance team, didn’t have experience working with product designers, so there was a mild instructional component to our design reviews, reminiscent of user workshops I’d helped run at various startups.
We worked through multiple rounds of concepts to define requirements, set realistic expectations, determine the value in creating consumer and agent variants, and evaluate visual designs ranging from utilitarian to mildly decorative.
Ideation & funding phase
Realistic expectations were made clear. But stakeholders still wanted to know what a Lemonade-inspired product might look like, and what we could learn from conceptualizing it.
Because in everyone’s mind, this was our eventual goal:
A lot of conversations and research went into this exercise, igniting enthusiastic discussions about data prefill, iterative phases, and AI. Many of the concept’s ideas and visual elements also found their way into the final design.
Some of what we learned
While researching this design exploration, I realized that Next Insurance’s coverages are limited compared to other business insurers. This means that only low-risk businesses with simple insurance needs are good candidates for their coverage – a hypothesis supported by several business insurance reviewers on YouTube. Fewer options would also have performance optimization advantages for their technology – a lesson we could benefit from, as backend response times became increasingly problematic for us over time.
By working to increasingly gather information about businesses through data services, we’d planned to reduce the number of questions applicants would have to answer with each iteration. But there was internal debate whether to show applicants all of the information that we’d found, allowing them to review it, or to only show them what’s necessary, so they can speed through the application. This concept helped visualize the argument in favor of showing only what’s necessary.
The backend app: a true Frankenform
I’d created several enterprise SaaS products and business tools, so I was very familiar with form design, and thought I’d seen it all. I was wrong.
The platform serving as our backend had been specified by insurance underwriters, and the interface had been ‘designed’ by developers. It was a mashup of long-scroll forms, horizontal tables, multi-selectors, checkboxes, radio buttons, and coded entry fields. Dependencies and forced recalculations created painfully long lag times and blocking issues for our consumer model. And every label and description was insurance jargon.
Prior to this, forms had never been something I had to research solutions for and map to datasets to make sure they’d work. This had become a conversion project with heavy middle tier involvement, not form design as I’d previously known. The design team had to learn to work with our backend, and how to work around it.
The underwriting platform was a Frankenform: a mashup of long forms, tables, multi-selectors, checkboxes, radio buttons, coded entries, and blocking dependencies.
The form field solution that worked
It took some trial and error to find unifying front-end solutions to the form input challenges of our backend.
Fields with infield labels allowed groupings that could accommodate descriptive or instructional text in addition to the field labels. All selectors would be toggle buttons or dropdowns, with a few unavoidable exceptions. And I established plain English alternate text requirements in the raw data files, so that descriptions and labels could be understood by consumers.
The product we’d (start to) build
Our MVP release would have longer pages than anyone wanted. But iterative releases would greatly reduce the number of fields and page lengths.
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 our insurance partners, including Geico and Progressive. The product was designed as a mobile-first solution, because in more streamlined iterations, phones would become the desired primary use case.
This was not simply a cleaned-up version of the backend app. We had to ferret through thousands of data points and options to determine what information was absolutely necessary to generate a quote.
Some aspects of the navigation sidebar were contributed by another designer.
Features of the design
The header and sidebars [A] are fixed, providing easy access to controls and navigation. 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 integrate business partner products. Previous bundles would bounce applicants through a succession of forms with different visual designs, and users had no idea where they were in the process. This solution would merge everything into one seamless experience.
After applicants entered a vehicle’s VIN number, remaining fields for that vehicle would auto-fill [C] with data retrieved from data services. In near-future iterations, we’d work to prefill many more types of fields, with the goal that applicants would have fewer fields to complete, and that pages would be shorter.
In response to feedback from agents, I proposed a suite of tools allowing agents to attach information to the quote [D]. These tools wouldn’t be in the initial release, but are shown here to demonstrate how I think about product design in terms of scalability for future features and integration with other products.
Iterative improvement plan: the prefill initiative
The platform serving as our backend had been specified by insurance underwriters, and the interface had been ‘designed’ by developers. It was a mashup of long-scroll forms, horizontal tables, multi-selectors, checkboxes, radio buttons, and coded entry fields. Dependencies and forced recalculations created painfully long lag times and blocking issues for our consumer model. And every label and description was insurance jargon.
Prior to this, forms had never been something I had to research solutions for and map to datasets to make sure they’d work. This had become a conversion project with heavy middle tier involvement, not form design as I’d previously known. The design team had to learn to work with our backend, and how to work around it.
Phase 1: MVP release
Our initial release would present applicants with more form fields and pages than anyone would have preferred, but the primary goal was to produce a commercial auto quote at the end of the flow.
Still, we were able to greatly reduce the number of total fields seen in our backend, and a first attempt at data prefill meant that some fields would be automatically populated.
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
Our initial product outline was the result of a weeks-long workshop including the UX team, front end and middle tier teams, product managers, and stakeholders to define the commercial auto product roadmap, and to estimate realistic timelines for an MVP, and a mature release for subsidiary and partner distribution.
Communicating design is great. True design collaboration is better.
Time management was crucial in startups, so I learned to create just what’s needed to communicate design intent. But I’d discovered additional, unexpected benefits from this practice.
With simple, low-barrier documents like this flow diagram, our non-tech stakeholders were better able to follow discussions, and more likely to make valuable contributions. Our dev lead also appreciated simple documents, because I was showing him “what has to happen, not how to do it.”
Cultivating inclusion and informed decision-making
Our in-house client wasn’t used to working with product 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 that 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.
Onboarding new people, and making a case for more designers
Like most busy professionals, most of my workload and status reports are simple documents. But for a few months, I plotted UX work and team allocations as a Gantt chart to help onboard a new UX designer, and to communicate workload to two successive directors who’d taken over the project after our managing director left the company. This was part of my attempt at making a case for a larger UX team.
The end of the commercial auto road
Four months after development began, our managing director — the product visionary — left the company. It was a shocking blow to the team.
Work continued. But, two leadership changes in the following months, and emerging problems with the backend slowed progress. Eventually, commercial auto was paused, and our in-house developers began to exit.
The pivot detour
Updating the business insurance quote products, offshore development, and a hybrid platform solution
It was always the plan that we’d redesign the dated business insurance quoting apps onto the new platform after commercial auto had launched. But we’d run into a series of setbacks, and so had our hosting solutions partner working on the new platform. To regain momentum, a management-level decision was made to build our new products on the aging legacy platform – the “hybrid” solution.
Now we’d finish commercial auto after making some easier wins. Or so the thinking went.
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 to display help content to consumers, and quote management tools for agents.
Visually similar. Under the hood, not so much.
As built on the legacy platform
The decision to build on the legacy platform didn’t impact the visual designs my team had already done for commercial auto. But many features and interaction details that defined our product as a modern app were lost.
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.
Above flow includes 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 documented individual paths from the point of deviation until it rejoined the master flow.
Updating aging business insurance products, offshore development, and a hybrid platform solution
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 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 a simple solution that would allow us to share designs for review, comment, approval, development, and QA. So Confluence became our best available option, which meant that we’d be doing a lot of old school redlining.
Edits and updates were also posted on the same page, listed 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:
Scope creep: new features, partnership integrations, and the elusive quest for a feature-complete release
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 content is in progress.