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.

Initial Feature Definition

Prior to sitting down and really digging in with the feature, our team captured it as a requirement when planning out and designing the parties functionality in BriteClaims. We knew that our users would need to be able to add vendors to a claim and be able to pay them in a smooth process. 

In the spirit of MVP, we designed our parties screen (essentially the contacts list for your claim file) to house a vendors section, but didn’t build out any of the necessary flows to support how it would operate at that time.

Assumption Declaration

In order to better understand what was needed for vendor management, we decided to have a design discovery session attended by the product owner, business analyst, designer (me) and two developers.

During this meeting, we did an assumption declaration exercise to address our teams’ assumptions and questions about vendor management.

Some of the questions we sought to answer together were:

  • How do we define a vendor?
  • What do we think needs to be built for MVP?
  • Where in the architecture of the application do we store vendors?
  • Where in BriteClaims do vendors need to appear?
  • What is our ideal vendor management flow?

From these questions, we were able to have some free flowing conversation that was captured and outlined using sticky notes on the miro board. 

Coming out of this discussion, all the participants in the session had a shared understanding on what we believed we needed to build and some inklings of how we needed to build it.

Outlining and Wireframing

Our next step was to take what we learned from our discussion, and start making it into something we could validate with users. The first step in this process was to outline the process we were seeking to build.

Asynchronously following our initial design discovery session,  we used Miro to make outlines for the different processes associated with vendors. The simple outlines looked like this:

These outlines were then turned into some wireframes:


Following discussion and collaboration on the wireframes and outlines with the project team, I was able to take the wireframes and turn them into a high fidelity prototype using our design system ( and Figma. That prototype can be found here.

For ease of discussion and feedback, I also laid out that prototype as a workflow on the same Miro board we had been using to work on up to this point:

Keeping all the discussion and notes on the design centrally located in Miro helps create a record of the design and discussion on the subject in an easy to explore and discover location.

Validation and Revision

Following the creation of a more polished design, we wanted to ensure that what we had designed out truly met the needs of our customers. We scheduled some time with a focus group of our end users and had them click through our prototype and take a critical look at the flow we had created.

After the users had studied the design we asked them the following questions:

  • Does this meet your needs for vendor management?
  • Is there anything you would have expected out of this feature that is missing?
  • In what ways / scenarios could you see this breaking down?

In addition to these guiding questions. We kept the conversation loose and open as well, allowing the users the opportunity to help guide conversation.

From this, we learned of a large blind spot that we had missed when designing out the feature. That blind spot being: how do we deal with vendors that are organizations with potentially hundreds of employees? This prompted us to update the design with the ability to create and attach employees to organizations like so:

After asynchronously validating this with our focus group after the fact, the design was ready to be broken into stories and pulled into development.

Lessons Learned

Designing out this feature was a good lesson in the importance of design as a constant, ongoing process. Although we designed and built out the framework around this feature months earlier, this feature in and of itself needed a full design process including discovery, prototyping and evaluative research.

It also taught our team that bringing in users as early as is feasible is always the best move and prevents any rework (which makes the product team happy) and also makes for a better product faster (which makes the users happy). If I had a time machine, I would have talked to users during the wireframing phase to validate the rough ideas before taking them higher fidelity.

Leave a Reply

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

You are commenting using your 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