Performing discovery research to determine product strategy

Executive Summary:

An insurance client, who I will keep anonymous, wanted to change their current disaster relief claims business model from part time employees to work on demand. They wanted an app that would support their claims adjustments both in the office and in the field.

Challenge

How might we design a mobile application that allows users to know when an opportunity for claims work is available and walk them through the claims process in a way that satisfies the needs of both the company and it’s consumers.

Results

The discovery process allowed us to identify a team whose role was to copy data from one platform into another, literally, a manual API. The team had been overlooked as they had done they work with remarkable accuracy causing no one to question how the data went from one system to another.

By connecting the two systems via API we were able to transform the team’s role from copying data from one system to another to entering the claim data directly into the system. The data entered was sent to on demand’s adjusters who were able to walk a claim with minimal training as all the steps and instructions were included in the app.

This enabled the agency of on demand employees to perform more evaluations in a shorter period of time with less training.


The Journey

As a consultant, I was asked to work with the client to perform a three week discovery process. My deliverable would be a comprehensive strategy document that would include a service blueprint detailing the teams, processes and systems needed to fulfil an insurance claim.

Getting Started

We spent a week with the executive team whiteboarding (I love whiteboards) all the processes that we could identify. If you’ve worked with me, you’ve heard me say, “I love a good process”. Well, as you can imagine, I was in heaven.

The following week was spent documenting and analyzing the processes from the prior week and we kept noticing that there was a gap between the incoming system and the outgoing. How did the data flow through, there had to be a data base somewhere, or an API. It was a mystery but one that would have to wait.

Note: If you are on mobile it will be very difficult to view the deliverables on this project. You’ll also notice that I use infinite canvas on LucidChart. I prefer to focus on the process without the need to fit it in a predefined space, but I’m nerdy like that.

Contextual Inquiry

The second part of the research involved learning the adjuster process. We started by performing phone interviews with adjusters of different experience levels and had video interviews which were recorded and again analyzed and documented. There’s a lot to it and the app was going to have to provide abilities a large range of tasks.

In addition to the interviews a survey was sent asking for adjusters expectations from a mobile app.

But before we could get started on that we needed to take a trip to the field and see the process ourselves. There’s no better way to understand what someone does for living than walking a mile in a persons shoes.

Service Blueprint

As much as I enjoy a good process, I enjoy a service blueprint more. It paints a clear picture of each part of multiple processes including tracking data and services. By continuing to add layers you can draw conclusions by seeing patterns and connections that were never visible before.

This is also where we took all of our finding from the previous efforts a placed them into once space so that we could get a full view of what was needed.

Logic

This was the final deliverable. While onboarding the designers I used these diagrams to walk through the requirements for the entire app. Upon completion the same document was shared with the development and data science teams so they could construct the backend in parallel with the UI design and development.

That may not look to tough, but I quickly realized all the adjustment activities were going to need to be in a separate document. However, constructing the logic this way would do two things. Allow the order entry teams to input the information in a way that triggered the rooms that needed to be inspected and for the adjusters on site to be able to pick the room they were in. Giving each team autonomy to complete the same goal in the order that worked best for them.

I put a full export of the document to give an idea of the scope. However, having all the app logic mapped out drastically reduced development time. I’ll put a smaller portion below so you can see the diagram a bit better.

So many thanks

This was one of those projects where teamwork and collaboration made every day great. I can claim a good percentage of the work done on the deliverables you’ve seen here, but I worked with a great team of product managers, designers and tech leaders to ideate and iterate on every one of these deliverables.