Case Study: BriteClaims Vendor Management

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.

While the flows and designs for how we would manage parties like insureds and claimants had been previously designed and built, vendor management was something that was left to be defined. Vendors represent contacts that provide a service for a claim (auto repair, property inspection, consultation, etc.) and require payment.

Fixed it for ya!

This left us with the challenge to solve how we would tackle vendor management inside BriteClaims.

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 to house a vendors section, but didn’t design out any of the necessary flows to support how it would operate at that time.

Design Discovery Session

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 and two developers.

During this meeting, we did some loose whiteboarding using Miro 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 a crude rendering of how this could appear in the UI called a wireframe:

Prototyping

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 (ui.britecore.com) 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:

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