Supplier Vetting

Case Study

Project Brief

Overview

Role

Lead UX Designer

Teams

Compliance Solutions

Platform & Architecture

Includes

UX Research

Usability Testing

Application Design

Project

Supplier vetting is an application which will allow buyers on our platform to successfully “vet” their suppliers. This would enable buyers to send recorded compliance documentation to their suppliers, view any relevant documentation uploaded by the supplier, and allow suppliers to answer a standardized questionnaire for subscribed buyers consumption.

Challenge

After initial discovery, we uncovered some core challenges our users where facing when it came to vetting.

Buyers found it difficult to attain relevant documents when they are audited. They had to dig through archived emails, and if any of the documentation where out of date, they would have to notify the supplier to receive an updated version.

Suppliers where frustrated at having to issue multiple certificates and documents to an array of different buyers. This drove up operating times & costs.

Outcomes

A Synergetic Compliance Platform
A platform that allows both buyers and suppliers to interact with, to ensure that both parties have correct documentation & certificates.

Up-to-date compliance information
A holistic supplier questionnaire, which includes a combined & standardized selection of our buyers vetting questions, with the ability for buyers to view this information on demand.

Platform Compliance involvement
A “back office” application which would allow our compliance team to view any information submitted by the supplier, change the status of their vetting profile, and confirm any adjustments needed.

The Process

Discovery

This project was part of the compliance roadmap due to it being a reoccuring pain point for many of our clients. When kicking off this project, i suggested we do a round of conversations with potential users. This would help to validate the problems, and guide our solution. I was able to speak to two buyers & two suppliers.

Though their processes were different, they shared common pain points. I took the time to also speak with some of our internal teams, to get their input on how their customers are currently vetting, and how it relates to our platform.

Since the scope of this project was quite broad, and involved lots of different types of users, it was important to gather requirements for each user base, along with other information i needed to ensure the design worked for our users and the business.

Definition

At this point, we were able to clearly define what we was trying to achieve, and could communicate it effectively. i took the the team through PRD session, so we could get everything documented, and used it touch base with Head of UX. The compliance team started to put together the questionnaire whilst i started moving into ideation phase.

The PRD (Products requirement document) was a process I introduced to the organisation. It helped us gain requirements from the product owner, and get cross functional alignment on the justification for the project. We continue to use PRD’s for all projects involving UX.

i spent some time putting together an initial user flow, which documented the clear decisions points in the journey and where compliance involvement was required. We ended up tweaking this flow a little toward the later sprints, but the core idea remained the same.

I put together a lose user flow for buyers and suppliers – so we can align on the way we see users moving through their journey. This was slightly revised by project completion, but still served as a valuable tool in this project.

Ideation

With all of the requirements I’ve gathered and information at hand, i started to do some early ideation. I explored a few different ways we could solve the users problems, whilst still keeping our platform integrity. I did have a few conversations this time regarding feasibility, technical challenges, and information contained in master data.

During ideation, i had to keep in mind how this will integrate with the platform on a more global level. I know what we had in master data, and what information we could pre populate. Understanding how this worked with the permissions layer, and our new back-end architecture was important to the success of the project.

Once i was happy with some of the key art, i opened up the design for critique. I got some very valuable feedback in which i was able to iterate on. We passed this initial prototype onto our customers for some light usability testing. They found some of the initial navigation a little difficult, however they understood the main flow, and saw immediate value to their auditing process.

A small selection of my sketches and low fi’s for this project. A little rough – however i used them to explain my thinking, and give the team an understanding of how i can see this working. Explaining some edge cases we hadn’t fully explored yet. This directly translated into a higher fidelity version which was slightly more detailed.

Iteration

With some of the broader art done, I now moved into some of the more detailed and technical specifications of the project. I needed to also design & detail some of the components we used. Some global components where used for this project (such as the table, filters etc.) however i had to create some new global components (such as a the Yes/No Questionnaire component)

Creating a new local component for the questionnaire. This was flexible enough to account for all 164 questions asked in the questionnaire. I created this component because none of our current components were able to handle this use case.

The Solution

Some screenshots of the MVP solution to Supplier Vetting. including the “Back Office” using Components from the global library. Some screens have been excluded to protect valuable company information or strategy