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.
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.
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.
With hypothesis in hand, we went full tilt into a generative research phase. This phase included a survey, user interviews and a focus group.
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.
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."
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.
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.
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.
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.
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.