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. Served as the sole designer responsible for research and UI / UX design. Timeline: 1.5 months

Methods & Techniques

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

---

The Problem to be Solved

Discussions with claims adjusters (our target users) over the course of building v1 of the BriteClaims system revealed that one of the most important things for them to do their job effectively is the ability to keep track of the different tasks they needed to complete to work on the insurance claims their customers would submit.

Incorporating task tracking functionality directly into the BriteClaims system would empower our users to do their jobs more efficiently and with less error.

Assumption Declaration

To kick off the project, I got our product team (consisting of product owner, engineers and designer -me) together to do an assumption declaration session. This helped our team move forward on the same page about the definition of our fledgling feature and gave us a baseline of ideas to validate with users.

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 workflow is enhanced by this feature and made more efficient and less error prone

Survey

With hypothesis in hand, we wanted to validate these ideas with users.

We sent out a survey to target users with a focus on laying out the assumptions we had declared collaboratively and seeing if users agreed that those were things they were interested in seeing in a future task management feature or not.

This survey gave us a view into which of our assumed functionality would be most important to potential users (Due dates, tagging tasks, task priority) which would be extremely helpful for me in knowing what to prioritize when moving into the design phase.

Interviews

While collecting survey responses we were simultaneously conducting user interviews. With the interviews, we were focused on understanding how users currently tracked the tasks associated with their work, what pain points they were experiencing and what they desired out of a future task tracking solution.

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." 

Wireframing

When beginning wireframing, I invited the product owner and engineers into some collaborative wireframing sessions. These 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.

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. In one of our first click tasks with users, we asked them to click where they believed would complete an open task. We had ~30% of our users click on the batch selection item, which led us to incorporating a batch completion feature into the design that wasn’t there initially.

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.

Results

Following our design process we had:

• Strong shared understanding across a product team on what we assumed an integrated task tracking functionality needed to be.
• A testable hypothesis to deliver functionality against.
• Validation of our hypothesis from direct conversations and data collected from users.
• A prototype that had been evaluated by users for usability.
• Stories written for development to build the feature.