The digital claims application is a B2B and B2B2C product that empowers customers to make insurance claims easily and efficiently. The product is a configurable, white-label, and multi-lingual platform that can be used as a responsive web product, as a standalone chat interface, or directly integrated within the customer's website. The product is accessible at Level II of the WCAG Guidelines.
How a user selects their product to claim for
Discovery and Definition
Claims are typically and traditionally a non-digitised product. It's a telephone-based process that offers little transparency or empathy and often fails to keep customers up-to-date with the progress of their claims.
My aim was to discover and understand business and customer needs in order to digitize this process and deliver a product that would disrupt the marketplace. I attended insurer conferences that allowed me to speak directly to claim handlers and learn about the issues they face when obtaining claim information and, more importantly, the frustrations of their own users with the existing claim process.
Key user requirements:
Users want the ability to report claims from any device
Users want to feel a connection and empathy with the claim assistant, as claims are an emotional event
Users want the ability to view their claim progress at any point
Key insurer requirements:
Customisable and white-label to allow the insurer to apply their own product branding and to change the content to be in line with their TOV guidelines.
Empower their users to easily provide all information that's required in order to process a claim to resolution.
Key business requirements:
To offer a product that would be device-agnostic—one that could be implemented directly into the insurer's website, a standalone chatbot, or a separate web application.
To create a way for new insurers to be added as clients and to configure their personalised version of the product.
To enable rapid production of the same product for different insurer lines of business (home, motor, etc.) and different peril types (theft, accidental damage, etc.).
Organising customer workshops was another way in which we understood our customer's requirements. We organised several workshops with customers from different regions, including those in Europe and Asia in order to understand and learn more about their requirements as claim handlers and also about their customer requirements—those making the insurance claim. I played an integral role in these sessions as I wanted to achieve two key goals. The first was to understand as much as possible about the claim handlers' current pain points and to prevent discussions from leading to potential solutions. The second was to help create empathy and consideration for their user (the claimant) to prevent claim handlers from identifying the information they want and instead consider the information the claimant may have.
Discussing user flow with NN Group customers
Creating a new flow during the customer session
The session we had with the NN Group is a prime example of this. Here, I prepared the customer journey ahead of time and printed their key steps in individual green callouts. This allowed us to easily and rapidly organise and create a customer journey during the workshop that would accommodate the customer's needs. As discussions relating to the journey were underway, I quickly created some high-fidelity sketch flows of this journey (see laptop) so I could present the proposal at the end of the session. This enabled the customer and claim handlers to see the journey in order for further refinements to be made.
These sessions also enabled us to discuss the client's tone of voice and brand identity guidelines. When working with insurer carriers as large as the NN Group, their standards are strict and therefore, the ability to discuss their guidelines face-to-face with the head of marketing enabled me to better understand the rules and smaller details in order to successfully implement their brand into our product.
Design Research and Concept Generation
Initial design research and concept generation
As a key customer requirement was to provide a product that could be used across a multitude of devices, I researched ergonomic factors related to device interaction. This helped me understand easy-to-reach and hard-to-reach areas depending on how users hold devices.
I then began exploring how a feeling of empathy could be translated into the product. After investigating different ideas, I discovered that empathy is an emotion felt based on one's feelings and interactions with others. I decided that, in order to achieve this, a standard practice of form-based UI would not be successful, and I needed to make the most of written language. I decided a conversational UI would provide a greater likelihood of success for this requirement and one that could be customised to suit different insurers' tone of voice guidelines.
Exploring how conversational UI works with the ergonomic research
The next step was to consider how a conversational UI could be designed in line with ergonomic research. This was a very iterative process that used both Sketch and Balsamiq Mockup to explore ideas. Ensuring key call-to-actions were within comfortable reach on all device types but still visually related to the question became the key balance at this phase of the design.
Design Development and Product Integrations
Once the design direction was agreed upon, the design phase moved exclusively into Sketch and the focus was placed on creating high-fidelity designs and clickable prototypes to test various user flows. This design stage also had to consider the impact of customer branding and how different languages could impact our user interface design. Designs were tested internally with key product stakeholders and externally with POC clients. The research was gathered, and designs were iterated in order to achieve a design that we could begin to engineer with our engineering team.
A high-fi design showing how the product responds at larger resolutions
How branding could be incorporated into the UI
An additional step at this phase of the design was the consideration of external product integrations that would enhance the commercial value of RightIndem's product and also improve the end user's experience. An example of this was the integration with SilverCloud. SilverCloud offers a product lookup service that enables products to be easily identified once the user has entered a minimum of three characters. This offers an improved user experience as the user can simply begin to enter a product name, and a list of matching products is returned for the user to select from. This prevents the user from having to provide additional product data such as IEM number, Model number, etc., as this exists in SilverClouds product database and is tied to the product that the user selected.
'Unhappy paths' were also considered at this stage of the design, as research suggested that users don't always know the exact model for their item, which would prevent them from selecting one. For instance, many users don't know the exact model of their television; they simply know the manufacturer and screen size. For these scenarios, we offered a fallback that would allow the user to enter as much or as little information as they had about their product.
Product look-up concepts
Design System and Component Library
To support product design, I also created a design system that included a component library and a style guide.
The component library was based on Brad Frost's Atomic Design principles, and components were organised into:
Atoms. Individual instances of a component such as a button, text input, etc
Molecules. Groups of two to three components, such as a search field with a 'clear' icon and a search button
Organisms. Larger groups of molecules, such as forms
Templates. Reusable patterns that consist of any combination of the aforementioned components
Component Library - Partial Modal
The advantage of this design system was that it would create a consistent user interface both visually and behaviorally, which in turn reduces user learning and cognitive effort and helps increase their confidence in using the product. It also allowed us to build accessibility directly into individual components. The advantage of this approach is that:
It reduces time as accessibility features are part of a targeted component and not an entire page or feature of the product
Accessibility testing can be done at the component level
Accessibility is built outward and does not become a large retrospective task
There were also internal advantages to this, including reduced regressional testing and improved sprint velocity as once components were built, they were reused repeatedly.
The style guide included visual patterns such as typography rules and a colour palette that offered a range of hues, each available in 300, 500 and 800 values that were compliant with the WCAG Level II contrast ratio.
RI product colour palette
Claim conversation design
My intention throughout the design process was to create a conversational interface that would empathise, inform, acknowledge, and communicate.
Empathise: Reporting a claim is an emotional time for a claimant. It may be significant motor damage that comes at a cost to the claimant, or it may be the loss of a sentimental item, such as a wedding ring. I, therefore, wanted the claimant to feel empathy from the claim assistant and not feel as though they were engaging with another internet chatbot.
Inform: Making a claim is a process that a user does not choose to do; it's one they have to do as a result of an incident. Therefore, they're unlikely to have previous knowledge or expectations of the information they need to supply. I wanted to ensure that our conversation told the claimant upfront what information they would need to supply as part of the process in order to prevent frustration and potential journey dropouts.
Acknowledgement: I discovered, from my research into voice assistant conversation, that a key interaction aspect is device acknowledgement. Users need to be aware that their voice command has been heard. I wanted to incorporate this into the claim conversation too, so the user had confidence that the information they supplied had been successfully received.
Communicate: Claims are not a single, linear process, so I also made it a requirement to communicate the next steps that the claimant is likely to face. This would set expectations and timescales relating to the resolution.
Once I had these requirements, I soon realised that the claim conversation could not be fully automated. I wanted this to present a human interaction, and I did not have the confidence that a generated chatbot model could satisfy the above criteria. Therefore, I carefully crafted a full, manual conversation for each claim type (motor, home, etc.) and also the peril (accidental damage, theft, etc.). After discussions with our CTO and engineering team, we did agree that we could automate some aspects of the conversation, such as the acknowledgements (thanks, got it, that's great, etc.), so I produced a bank of these acknowledgements that could be selected after each candidate response.
Manually created script for property claims
Claims Portal Design
The RightIndem product is a product with multiple user types. In addition to claimants using the product to make a claim, there is also a claim handler view of the product that shows all claim data and the relevant information needed for the claim handlers to bring the claim to a resolution.
The process for creating the claims portal followed the same process as the creation of the claims application used by the customer (the claimant). Multiple workshops were held with claim handlers from a wide range of insurer clients, and the information gathered was turned into user flows and personas, which were used to help facilitate the creation of low-fidelity mock-up designs. At RighIndem, all low-fidelity design mockups were created using Balsamiq Mockup.
Once mockups were created, they were discussed between myself and the product owner before moving into Sketch for high-fidelity design work to commence. This was important as the claim handler portal contained multiple product integrations, and it was therefore imperative that, in order to assist the claim handler in bringing the claim to a successful resolution, we could quickly consider the best location for these integrations. One example of these integrations is the image lookup service. The image lookup service inspects images that have been provided by the claimant and checks that:
The image has not been modified in any external tool or editing software
The image is not from Google
The date the image was taken is checked against the reported incident date to monitor potential fraud
Image integration tool designed at different resolutions
Integrations such as these were designed in a partial high-fidelity design mode. I wanted the ability to test their UI hierarchy and positioning on the page while also designing how they would respond to different resolution breakpoints; however, at this stage in the process, I did not need to consider their wider positioning in the whole product.
Once I was confident with the behaviour of these elements, along with all other requirements of the handler portal, the design moved exclusively into Sketch, and the high-fidelity design for the handler portal concluded.
Claims portal - claim list
Claims portal - claim overview
Once all designs were finalised, they were added to Invision and these were added to the user stories. I worked closely with our Business Analyst to ensure all design details were captured, and I was part of every sprint ceremony meeting to explain the design and user journey to our engineering team. I created a story template within Azure that included a 'User Needs Statement'. This provided all team members with the context of the feature, the user scenario, and the insurer scenario, and this helped to align everyone's knowledge and understanding of the problem and the goal we set out to achieve. As with all projects, I took an active role in the sprint demo and testing environment to ensure that the delivered item matched the original design.
Towards the end of my time with RightIndem, the company sourced a new external team of developers. As our relationship now sat across different time zones and countries, the communication channels between design and engineering changed. Because of this, I needed to adjust our tooling and ways of communicating. I, therefore, chose to adopt the use of Zeplin. I chose Zeplin because designs could be inspected and design properties could be obtained in the hours that sat outside the working hours of both teams. The addition of Zeplin helped to maintain our current level of sprint velocity, and it was a tool that the engineers enjoyed using.
To support the product and ensure that, although customisation could be made by the insurers, the integrity of the claim conversation needed to be maintained. To achieve this, I created a series of supporting guidelines that explained the principles and structure of the language used within the conversation and defined rules when writing content. I also created separate guidelines and support documents that detailed:
How to provide the correct brand assets for brand customisation
How to build unique customer journeys
Rules around the use of emojis within the claim conversation
Claim conversation guidelines
Within the claimant side of our product, we installed several performance metrics that would allow us to understand and measure customer engagement and interaction. This data would be interpreted by myself and the product owner in order to assess and identify areas for improvement. The key measures we identified were:
Overall completion time
Individual step completion time
Time from 'making the claim' to starting our claim journey
We also tracked technological stats such as browser, device, and location in order to further understand user demographics.
When analysing this data, we compared individual step completion time with interaction complexity, and if we felt the two did not align, we explored the information further to mark it as a potential area for improvement. For instance, the step that asks for the claimant's name is relatively easy. The claimant only enters their name and then continues to the next step. Therefore, we made the assumption that this is a task that should take < 30 seconds to complete. However, the step that asks the user to enter the details of their claimed item and select it from a set of returned items is more complex and requires more user effort. By looking at the mean average, we assumed that this is a step that should take no longer than 2 minutes to complete. For any interaction that was greater than this, we would take explorative action, as this was also a critical step in the journey for both the claimant and the claim handler.
Identifying failures and iterating improvements
The aforementioned step is an example of an area that we selected for improvement. Many claimants were taking longer than 2 minutes to enter and select their claimed item from the returned list. I returned to our original hypothesis, and I believed this was still true. At this point, I wanted to return to the users for feedback. I discovered that the UI touchpoint for scrolling the list was poorly designed. It wasn't easily discoverable, it wasn't obvious as to how it operated, and it was also difficult to use. Also, the list only returned 1-2 items depending on the browser or device width, and it wasn't always clear that more items could be scrolled to be seen.
Original design (left) and updated, more discoverable and affording design (right)
I, therefore, chose to go back to low-fi mockups and design some alternative solutions. These were presented back to our team and product owner, keeping the original hypothesis and newly discovered research in mind. Once we were confident in a potential solution, this was turned into a high-fidelity prototype and shared with users. Their feedback was a great deal more positive, and these improvements were then scheduled for release in an upcoming sprint.
The RightIndem digital claims product is a big success thanks to all the team members who contributed their hard work and dedication. I was proud to be part of a product team that shared the same goal of delivering a new, digitized way of empowering customers to create claims in an easy and efficient manner. The product won several awards during my time with RightIndem and it has continued to grow and develop to this day.
AA Vehicle Selection
Esure Incident Location
As Head of Design, my responsibilities for this product were:
Working alongside the CPO and PM, identify customer needs for raising insurance claims.
Run and participate in user workshops with external clients
Set product design direction and create design values.
Identify a scalable UI that would allow for personalised content and branding.
Identify a design solution that would be scalable, device-agnostic, and open to different implementations, e.g., a chatbot, a mobile-responsive web app, and direct integration with a partner site.
Working alongside the CTO to help identify a technology framework that would deliver our chosen UI approach.
The creation and responsibility for all product design work that included a design system, a manual claim conversation transcript, product user guides, and brand and tone of voice implementation guides
My responsibilities for individual team members included:
Mentoring designers and assisting with their day-to-day work.
Biweekly and quarterly appraisals.
Team mentoring and setting team direction for different squads.
Identifying an individual's future goals and ambitions and creating a development framework that would help them achieve these.
Software and Tools
The following tools were used to help take the product from ideation to live production:
During my time as Head of Design, the RightIndem claims application won:
Winner at the 2020 UK Customer Service Excellence Awards: Best Customer Service Product for Business
The Insurance Times ‘Best Use of Technology for Customer Experience award in 2017 and 2018