Case Study: BriteClaims – Tasks

Summary

With an emphasis on generative user research and collaborative design techniques, designed a task list system (think, Todoist, Asana, etc.) inside a SAAS claims processing tool.

Methods & Techniques

Assumption declaration, hypothesis creation, survey, focus groups, user interviews, wireframing, prototyping, first click testing


The Problem to be Solved

In discussions with claims adjusters (our target users) over the course of building v1 of the BriteClaims system, we were made aware that one of the most important things for them to do their job effectively is the ability to keep track of the different tasks associated with all of their claim files.

When building out the BriteClaims system, we knew we wanted to incorporate functionality for claims adjusters to create and track tasks directly inside their claim files in a way that rivaled best in class task tracking tools like Todoist and Asana.

Assumption Declaration

To kick off the project, I got our project team (consisting of product owner, engineers and designer -me) together to do an assumption declaration session. I love kicking off projects with this exercise because it puts all of our collective ideas about what this feature should be out in the open so we can all understand each other’s headspace. It’s also great because it helps lay out the gaps as well.

Perhaps the best part of this exercise is that it forces the team to reframe what they think the feature should be into an assumption. We assume this is what we should build, but we won’t be certain until we validate it.

Hypothesis Creation

Once all our assumptions were declared, we collaboratively distilled those assumptions into a hypothesis statement.

After using stickies on Miro to collaborate on the hypothesis creation, our hypothesis was distilled into:

We believe claims adjusters need a way to track tasks so that they can ensure proper protocol has been followed and claims get closed

To support this need, we will build task tracking functionality into the claims system with features like:
- The ability to add tasks
- A filterable list of tasks

We will know this hypothesis is correct if end users validate that this fits their needs and expectations for a claims system

It’s great to go into a project with a hypothesis like this because it pushes a team to think about what they are building as a potential solution to a user problem that shouldn’t be actively considered for development until it is validated.

Generative Research

With hypothesis in hand, we went full tilt into a generative research phase. This phase included a survey, user interviews and a focus group.

Survey

Our survey was taken by 10 of our target users (Claims adjusters, claims managers etc.) Something that drove our line of questioning in the survey was laying out some of our assumptions we had declared and seeing if users agreed that those were things they were interested in seeing in a task management feature.

Interviews

While collecting survey responses we were simultaneously conducting user interviews (5 participants). With the interviews, we were focused on understanding how users currently tracked their tasks on their open claims and understanding the pain points in their current processes and listening for opportunities for how a new task feature could alleviate those pain points.

I used Google Sheets to track our interview findings which made it easy to take notes in one cohesive spot for each interview and then see the data collectively across the board.

From these interviews, we had a handful of participants mention how helpful it would be to have a calendar integrated into a future task solution. This would inform a large focus of how we would end up designing the feature.

"I'd like to be able select a task on my calendar and drill down directly into the claim." 

"I want a task list with a calendar to live entirely in the claims sytem. If it overlaps with my Outlook / Gmail, then that's ok, but mostly I want it in the claims system." 
Focus Group

Another aspect of our generative research was facilitating a discussion with a focus group of our claims users on what a potential task solution should look like. For this session, we asked mainly the same questions as we were asking in the interviews but the focus group nature allowed our participants to bounce ideas off of each other which led to some interesting insights. I would highly recommend to any researcher to pair 1:1 interviewing alongside some focus groups to maximize insights and understanding.

Wireframing

Our generative research phase proved to be incredibly productive in validating some of our assumptions and giving us direction on what to build. From here, I started doing some wireframing and invited the product owner and engineers into some collaborative wireframing as well. These collaborative wireframing sessions were great because they allowed us as a team to continue building shared understanding on how we wanted to build this feature. A technique I used for these sessions was to encourage my team to use screenshots of other tools / software to build out their rough wireframes for what our tasks feature could be.

For example, in the screenshot below a team member was playing with the idea of having a task list alongside a calendar so they just screenshotted Google Calendar and put it alongside another roughed out task list.

Prototyping

After going back and forth on some wireframes for a while, we got our ideas to a point where we were ready to polish them and start looking into how some interactions might work with our tasks feature. Enter, protyping.

I used Figma to build out some higher fidelity mockups for how this feature could operate as well as using Figma’s built in prototyping tools to illustrate how the software should interact and behave.

You can see this prototype for yourself here.

Our final design for the tasks feature was made up of three main parts:

  • Search bar / header
  • Task list
  • Filter menu

The task feature itself lives inside a right sidebar that slides over to reveal itself when the tasks icon is clicked. This allowed the tasks function to be accessible anywhere inside a claim file without the user having to lose context of where they were when accessing the tasks list.

Evaluation

Our final phase before feeling ready to start developing our design into live software was to evaluate the polished designs with our end users. For this, we took our design back to our focus group and gave each participant a link to the prototype and asked them some questions about it’s design and if it included all the elements needed to allow them to successfully track their tasks.

Following this we had some tweaks that needed to be made. we reworked our calendar component to be more focused on ranges of dates as opposed to a calendar and also were able to clarify some logic around the completion and cloning of a task.

We also prepped a first click test which was sent out to the same audience as our initial survey to further evaluate the usability and discoverability of the design we created. The design performed well in this test, but again had some difficulty as far as the calendar was concerned which further led us to want to rework that piece.

Following these evaluations, our team felt ready to start building out our first development version of this feature. I wrote up the stories needed to support its development and put it into our backlog.

Lessons Learned

Designing for this feature was an absolute joy because of how much we honored the idea of treating the design like a hypothesis. I worked hard with this design process to create a sense of shared understanding across the team that paid off in a design that met user needs and looked and interacted in a delightful manner as well.

If I could do anything different, I would have spent some more time doing dedicated usability testing alongside our focus group and first click testing for the prototype. I think it could have revealed a few more insights that could have aided in the design. I decided against this because usability testing on a prototype usually has it’s fair share of caveats unless the prototype is incredibly thorough, which is something I tend to shy away from in the spirit of moving a little faster into development.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s