Optional Critical Illness Insurance

How might we improve the way users learn about and purchase critical illness insurance through their benefits provider?

What does it mean? Nobody knows what it means. It's provocative. It's gets the people going.

Critical illness insurance is claimed upon diagnosis with a... covered critical illness (this includes many diseases, certain types of cancer, and/or strokes). This project is focused on optional critical illness insurance which means that the user already has benefits with Sun Life and is able to purchase critical illness insurance as an add-on to their benefits package.


I met with our team's product owner and UX writer to align on next steps. For me, it was research — specifically into our users' mental models and needs. In this case, we were looking at a rather broad target demographic: group clients (users who have benefits with Sun Life) who do not already have optional insurance products. I conducted user interviews, a competitive analysis, and an assessment of our current state flow to better understand how we can improve the experience. Later, these insights would inform and shape our design.

User Interviews

"My biggest worry if I get diagnosed is not being able to take care of my family."

After creating a discussion guide and interviewing ten users, some key observations were made. While clients tend to avoid thinking about a diagnosis for themselves, many have seen a friend or family member effected by a serious illness. It's a personal, emotional topic with often minimal transparency in terms of financial impact. Product comprehension is incredibly low and I observed that users are primarily focused on the cost of insurance — an important distinction between this and its retail counterpoint (where users are focused on needs). Due to the nature of optional critical illness, users have more of an "add-on" mentality with purchase.

Current State

After mapping out our current state flow, I discovered some major insights. The journey users experienced at the time was unintuitive and disparate. A client interested in the product goes from a marketing email, to a micro-site, to a PDF, to potentially their own online research, to napkin math, to signing into their Sun Life account — all before finally arriving at the online application. There were a lot of simple, structural changes that could easily improve this flow.

User Needs

We heard a few core needs from users: I need to understand what critical illness is and the value of the purchase, I need to quickly know how much it will cost without a hassle, I need to be spoken to in a way that's empathetic, considerate, and informative, and I need a straightforward path to purchase. These were kept in mind when discussing solutions.

Defining the Problem

Equipped with a better understanding of the problem, I filled out a lean canvas. This helped to create a clear, shared understanding of our problem with my team. Conversations with our business partners helped me get alignment on potential use cases and discussions with our product owner helped me get a better understanding of our scope, constraints, and timelines. This would be a short build — moving from discovery to production in about four months. This quick turn around would enable us to test our solution with real clients during an upcoming campaign period. We could watch how the new micro-site performs and iterate.

How might we help group clients better understand the value of optional critical illness insurance, quickly surfacing the cost, while building a more streamlined experience?


I love the ideation phase because its bursting with creativity and collaboration. One choice I wanted to highlight was our intentional involvement of front and back-end developers as early as possible. I facilitated a session with our entire squad to discuss initial ideas, walking through user research and our approach to design. These types of sessions were invaluable, providing the team with agency and insight into the design process (which can too often be a black box) and helped us to identify technical challenges earlier than usual. One major design challenge was balancing the need to provide the user with a thorough overview of the product and calculating the cost of coverage in a flow with strong momentum.

Design, Test, Repeat...

First, I defined a basic user journey that solved for our stated use cases and scenarios and then produced a set of lo-fidelity wireframes. I'm a big proponent of iterative validation and so my first instinct was to take this to UserTesting.com to collect high-level conceptual feedback. Over the course of the ideation phase, I conducted four rounds of testing to shape the direction of the design. This process involved the following steps: synthesize and prioritize feedback from users; gain insights from the usability tests and share them out with our team and stakeholders; integrate new content from our UX writer into the designs; iterate on the design, create a new test plan, and launch a new unmoderated test for feedback.


Our updated experience was streamlined, focused on price rather than need, supported by clear, informative content that showcased the value of the product, and provided a personalized cost of coverage within a few clicks. We not only showed the user how much coverage can cost but contextualized that number in terms of the potential financial impact that a major illness could have on them and their families. This feature was something that stood out from competitors, and made for a compelling narrative leading into a purchase.


Part of what I love about this role are the opportunities for collaboration. I want to highlight a few of these moments: I spoke to senior stakeholders bi-weekly at our Sprint Reviews to gather feedback on our design decisions, I worked with our behavioural economics specialist to learn how to position coverage results as to influence purchasing behaviour (this actually interested me so much that I took a course on it afterwards), I worked with our UX writer to craft meaningful content that is free of legalese, and I worked with our design lead to ensure that my wireframes properly utilized our design system and were approved.


While the design thinking process was technically over, my job was not done. I documented the project and prepared the wireframes for a hand-off with developers. I also tackled new challenges as they emerged during the development process (such as defining the handling of specific errors, addressing accessibility concerns, conducting a visual QA, and dealing with the implications of changes to our scope and/or timeline). I balanced all of this with preparing for our next epic. This time it involves our virtual assistant, Ella.

Back to Projects