Case Study: BriteClaims – Tasks


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.


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


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.

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.

Case Study: BriteClaims – Vendor Management


Using a collaborative design approach and a focus group based validation method, built out a vendor management tool inside a SAAS claims processing application.

Methods & Techniques

Assumption declaration, wireframing, prototyping, focus groups

The Problem to be Solved

A large element of the claims module in BriteCore is managing contacts that are associated with a claim. These contacts can be insureds, claimants, witnesses and vendors. Collectively, these contacts are often called ‘parties’ in a claims system.

Vendors represent contacts that provide a service for a claim (auto repair, property inspection, consultation, etc.) and require payment. Since vendors act as points of contact and potential payees on a claim, their management inside a claim file needs to be handled carefully.

Continue reading “Case Study: BriteClaims – Vendor Management”

Case Study: Addiction Services Center (Full Site Design)


Did a full site design and branding refresh for an addiction services center

Methods & Techniques

User story mapping, wireframing, prototyping, logo and asset design

The Problem to be Solved

eXclusive Services provides a handful of vital services to those struggling with addiction in the Cincinnati area. They are also the only group in the Cinci area providing primary care medical services alongside addiction services. The eXs team was wonderful and when they cited their need for a UI/UX designer, I was happy to jump headfirst into helping them build a solution. eXs needed a new, modern website to help communicate the services they offered to their potential clients.

The site would need to be easy to update as the eXs team had no easy way to update their old site in its current state.

The eXs team was also looking to update some of their branding to be more versatile.


The solution we landed on was to create the eXs team a new WordPress site. WordPress would afford us the flexibility to quickly design and develop a solution that was powerful enough to encompass the full scope of the new site we were designing but also give the eXs team a simplistic CMS to make any changes to the site going forward.


Building a full site in a weekend certainly creates a challenge. Every second is vital when running on such a tight timeframe. Our small team size, while advantageous for shared understanding, also required our skill sets to be stretched to create the needed solution.


Having such a delightful and talented team made the pressure of delivering a great solution in the timeframe of a weekend not only possible, but a lot of fun too.

Mac (Myself) – Design

Beverly & Suraj – Developers

Markku – Project Manager

Lakshmi, Erin & Ron – Forms & Additional Dev

Tracy & Sean – eXs Team

L-R: Sean, Tracy, Erin, Beverly, Mac, Suraj, Markku, Lakshmi, Ron

Activities Responsible

Getting a whole site off of the ground in the span of a weekend gives an excellent opportunity as a designer to build upon a variety of skills.

My first role as a designer on the project was to work with the eXs team and Markku, the project manager, on understanding the scope of what we were building. The eXs team came to SWOGC prepared and with already validated assumptions of their user base’s needs which helped us quickly get an idea of what exactly we would need to build and (more importantly) what we could put aside and not spend time building. This involved drawing out rough sketches of UI possibilities and charting out a site map.

After turning our story mapping session into a Scrum board, my next task consisted of creating rough wireframes of each view we were looking for. I took these wireframes and turned them into a clickable prototype using Marvel which allowed our team to get a really solid visualization of the solution and get fully aligned before we even wrote a line of code. These wireframes would continue to be tweaked as we revised our solution.

As our developers began working on setting up the backend of the site, I began working with the eXs team on developing some new branding for the site. I am not a logo designer, but I have an eye for consistency and decided to spin up a very simple text based logo using Roboto Slab from Google Fonts. Add in a couple of lines on top and bottom of the text and you’ve got yourself a versatile logo system.


We also determined the site would use the Roboto Slab font for headers and Open Sans for body text. Nothing beats a FREE serif / sans-serif font pairing right? After we grabbed some colors that the eXs team had already been using, we felt we had a solid branding put together. I then pivoted back into working on translating our wireframes into high fidelity mockups.

I built our high fidelity mockups directly on top of the wireframes that had already been made. This allowed me to update our clickable prototype on Marvel in real time. This was my first time using Marvel as prototyping tool and it won’t be the last. I love the snappiness and speed of Marvel’s editor and it’s Sketch plugin works wonderfully.

Hi-Fi Mock of eXs landing page

With high fidelity mockups in hand, the developers went to work coding them into reality. Some difficulties here were encountered in battling our selected WordPress theme, but with all hands on deck testing the site as it came together our team was able to quickly and efficiently tackle bugs and fixes. Getting a refresher on the joys and terrors of WordPress development is always fun.

We also worked with the eXs team to find content to fill the site. The eXs team is working to get a photographer into their facility to get some personalized content onto the site. But until then, we decided upon some great, royalty free stock photography. Thanks Pexels!

With the final hours of our weekend long race to the finish, we squashed bugs, optimized for speed and tested, tested, tested.

Lessons Learned

A website is never technically finished, but we are very proud of the solution we delivered to the eXs team and I’m grateful for the experience of getting to work with them and the lessons I was able to learn.

Givecamp was a crash course in just how valuable time is to the delivery of a digital product. When you have only a few days to deliver a solution, every second matters. However, I am astounded at how much time we saved by NOT cutting any corners.

You would think that when time is so tight, skipping wireframes and going straight to hi-fi mockups would have been the way to go. However, I can’t imagine our team would have landed on as solid of a solution as we did as fast as we did had we not followed a design process that involved low fidelity mockups first.

I was also again reminded that a UX designer’s role involves wearing many hats. It’s just as important to be able to ideate and clarify the scope of a project as it is to be able to build out prototypes at a rapid pace.

Check out our finished site at! I’m excited to return to the SWOGC next year and I highly recommend you check it out as well!

Case Study: Designing a Better Mobile Navigation

I was reminded during last week’s Apple Keynote reveal extravaganza of one of the more obscure features of iOS.

It was on the slide where they were discussing the iPhone’s home button where there was a brief mention made of “Reachability”.

With two taps to the iPhone’s TouchID sensor (See: Home button), the bottom part of your screen is folded down, giving you easier access to the top part of your screen. This was implemented in 2014 with the iPhone 6 and has quietly existed inside iOS ever since.

Continue reading “Case Study: Designing a Better Mobile Navigation”