Creating a Design System for Property and Casualty Insurance

While design systems are gaining traction, especially in the enterprise software application world, we are still learning about the value they bring.

Many people, including designers and developers, question why we need them. There is a perception that design systems may box you in, or that development is quicker using native UI languages.

This is my second time making a design system and UI framework. I also used a design system in one of my applications before they became a thing. Here is why I feel design systems are valuable.

Consider the business reality of designing and developing software applications. It’s a simple equation that rules in the business world: profit and loss.

1. People expect consumer-like, engaging, and usable applications that help them get their jobs done.
2. A poor user experience results in lost sales, lost productivity, increased training and support costs, and low customer satisfaction.
3. Crafting bespoke application UI (enterprise or consumer) is expensive and slow. Build time increases by approximately 45%, maintenance 37%.
4. There are not enough UX developers and designers around in the world of enterprise software application development.

So, how does this translate into the Property and Casualty insurance space?

“Insurance consumers” seek insurance that meets their personal needs. Insurance is NOT a front of mind topic for this user segment — if you ever did user research in this space you know what I mean.

Their needs are quite simple and predictable: Help me understand what insurance I need, give me some coverage options, let me pick a suitable policy, and set up my preferred payment option. Occasionally, I might want to check a bill, get proof of insurance, call on roadside assistance, or update my personal information. On the off chance that I have an incident, I may need to file and settle a claim, but hopefully that will be a rare occurrence. Most of all, I just want to feel peace of mind.

In fact, the goal in insurance is to prevent incidents from happening in the first place.

Although the needs of insurance consumers are simple, the business requirements of P&C insurance providers are more complex.

Often, we encounter beautifully themed, user tested, bespoke user experiences that are carefully crafted and mobile first … only to subsequently learn that they don’t address key business specifications, legal requirements, or the realities of a heavily regulated industry.

Complex business requirements inform P&C designs.

We may have missed a few things in our initial designs:

What about multiple cars, multiple drivers? Or what if we need to offer four payment options instead of one? Is the age of the insured a consideration? Are there any exclusion criteria that would deny coverage?

Assuming we have time, we go back to the drawing board and design the flows and options.

In the meantime, we’re also meeting with IT. They tell us, sure, we can implement this user experience, but we’ll need three UI developers for six months, and two of them are on other projects …

Your business analyst tells you that accessibility needs to be considered and your product manager chimes in that based on the target segment, the UI also needs to be available in Spanish.

We have reached a crossroads — where do we go from here? How do we balance a good user experience with business reality and market needs?

Design systems are one solution. Why?

They help accelerate your design work by leveraging user experience best practices, and let you focus on delightful differentiators.

A “driver’s pattern” or “policy view pattern” are established use cases — give or take a field or two. There’s no need for designers to spend their time and energy reinventing the wheel.

Instead, your designers can focus on crafting business differentiating patterns, and flows, based on existing components.

Well-established patterns free designers to tackle sticky problems.

Design systems also empower your developers to focus on building applications, not assembling pixels.

Teams can re-use pre-made components instead of building them from scratch.

Take a confirmation pattern, or a simple list. These combine all of the elements that you would need, such as text input fields and action buttons, to solve for a common user problem. They frequently appear throughout digital experiences.

Patterns reduce build time by solving for common design challenges.

Developers can take advantage of the grid to position elements onscreen, instead of painfully aligning components on a page manually.

Theming also becomes so much easier since it is usually done at the app level, rather than component by component. By integrating theming into the foundations of a design system, teams can take advantage of pattern libraries and meet the needs of different audiences, contexts, brands, and products.

Theming enables designers and developers to apply company branding to their applications.

What’s in it for the people using applications?

Design systems improve both consumer and business user satisfaction by leveraging a familiar set of interaction patterns and components consistently throughout the user experience.

We’ve also found UI metadata can be a powerful capability that helps with translatability, accessibility and upgradability of applications.

Most importantly, design systems redirect the efforts of designers towards solving user needs, and applying their creativity to challenging use cases and patterns.

So — which fork in the road will you take when designing your next insurance application?

Interested in working for a dynamic company that is revolutionizing the cloud space for P&C insurers? Check out our open positions and follow Guidewire UX on Medium.