SupplyShift Documents

UX Research & design

View Prototype
SupplyShift Documents module header image


On SupplyShift’s platform, our primary users, Buyers, send questionnaires called Assessments to their Suppliers. These Suppliers, in turn, answer the Assessments to the best of their ability and provide information that increases transparency between Buyer and Supplier. In the process of filling out these Assessments, a great deal of documentation is usually required in the process. This means that many types of files are attached to the Assessment responses. Because files are attached in individual assessment responses for each Supplier, it was difficult for a Buyer to preview each document – and impossible to search for a specific document that they might need. Our goal in this project was to create a central place in SupplyShift’s platform for documents to live – a place that would be easy to work with multiple documents, and to search for very specific documents, if required.


Before beginning designs, I knew that I wanted to do competitive research around potential features for this new part of our product. I also knew that I wanted to interview members of our team that regularly work with customers so that I could quickly uncover user pain points when it came to working with documents.

Competitive Analysis

Competitive analysis table for documents applications.

For competitive analysis, I looked for platforms that help users to manage their documents online. While we weren’t necessarily looking to create something complex, I wanted to make sure that we were balancing the right amount of features with simplicity. Some of the questions I kept in mind were:

User Interviews

For our user interviews, I had the opportunity to interview both our implementation team members who have the most contact with our users, as well as some of the users themselves. It was during this interview process that I was able to gain the most information about the current pain points our users experienced while working with documents on our  platform.

Navigating to the exact document they needed was difficult.

Because of the complexity of SupplyShift’s assessment system, finding a specific document (if a user actually knew where that document was) took navigating through multiple pages and clicks to get to a location where they could download it. And there was no way to look at the document directly on the platform itself.

There was no way to search for a specific document directly.

SupplyShift had no central place to store documents, and no platform-wide search functionality. So if a user didn’t know where a document was stored, it was impossible to find it. Ultimately users would need to reach out to their suppliers outside of the platform and request the documentation again.

There were platform bugs that caused documents to disappear after they were added to the platform.

During our research phase, we stumbled over several bugs that were in the system that caused documents to disappear and not be resurfaced.

There were multiple ways to add documents to the platform, causing confusion about the correct way to do it.

At some points in the process, there were multiple fields for suppliers to add documents, each field doing something different with said document. This bred confusion for the users of the platform, and we knew that we had to simplify.

User Journey Map

User journey map showing the user journey of working with Documents in the SupplyShift product.

Using information from our interviews, I created a user journey map to cover all our findings during the research process. I’ve found that user journey maps are great to encapsulate all the pain points and clearly convey them to all stakeholders.


Project Goals

After my research, my product manager and I discussed what our goals were for the project. We came up with the following:

Design a central place for users to access all their documents from across the platform.
Ensure that there were ways to both filter and search for the documents that the user needed.
Fix any bugs that were causing document errors on our platform so that users knew they could rely on the platform to keep their information safe.


Sitemap showing where the Documents module is located in the SupplyShift product.

With our project goals clear, I started working on a mini site map for where I wanted our documents module to exist in the product. I also mapped out how I wanted the pages for the documents module to interact with each other.

User Flows

My next step was to create some user flows and task flows around what I wanted the experience to be like for our users. I shared these with my product manager, as well as the engineers on my squad, to make sure everything made sense before moving forward.

User flow showing how a user would navigate to find a document.User flow showing how a user would download a single documentUser flow showing how a user would bulk download multiple documents.


Low-Fidelity Wireframes

With everyone on the same page after sharing the task and user flows, I started working on my low fidelity wireframes in Figma. Depending on the project and how good I’m feeling about a direction, I will either start with sketches on my iPad or work in Figma from the beginning. This time I was feeling pretty solid about a direction, so I started with wireframes in Figma. During this phase I regularly checked in with my product manager and the engineers on my team to make sure everything made sense and was feasible.

Medium-fidelity wireframe showing documents list Medium-fidelity wireframe showing documents list and an open filtering side panel.Medium-fidelity wireframe of document view.

High-Fidelity Wireframes

At SupplyShift, we work with the MUI (Material Design) library, so figuring out the look and feel of the UI for each design is relatively straightforward. I was able to quickly move into high fidelity wireframes to prepare for user testing.

A list of documents organized by document name first.

Most of SuppyShift’s interface is made up of lists of various objects that are related to each other or interact with each other. In this instance, it made the most sense to show all documents in a list as well, with different columns showing different bits of metadata to help associate each document with its related Assessment and question (indicator). The date the document was added to the platform was also included.

A list of documents organized by document name first, with the filtering panel open.

Along with the columns of meta data, it made sense to include applicable filters to allow users to whittle down the list to what they are specifically looking for. Users could choose to filter by the Supplier’s company name, the Assessment the document belonged to, the question (also known as an indicator) it was used to answer, as well as the start and end dates of the assessment’s time period.

A document view of a pdf with the side panel open.

If a user clicks on an individual item in the documents list, the interface takes them to the individual page for that document. In a right side panel, various pieces of information about the document are available to view. The user also has the option to minimize the side panel. This allows them more space to focus on the document itself while scrolling through pages or panels.


Testing Plans

I conducted five usability tests with the high fidelity prototype. My overall goal was to assess the usability of the product and to see if the users ran into any issues while completing their tasks. The tasks for each test were:

Testing Results

Users were able to complete the tests without any issues. The feedback I received about the designs was positive, and users agreed that it was going to make things substantially easier to find documents in the future.

However, additional feedback I received during the testing phase was that users didn’t really need to be able to search or filter by the title of the document itself. Because the suppliers were the users who originally uploaded the documents, our buyers knew that they would not have knowledge of the title of the documents. They said it would actually be much easier to find the documents they needed if we allowed them to search and filter by the assessment title, the question title, and the Supplier name.


With that feedback in mind, I went back to my designs and revised the list view and filter options. I changed the information in the list view to show the Supplier name, the assessment title, and the question (indicator) title. The date remained, as users initially said that being able to search by the assessment date would be helpful. I also changed the filter options to match the fields available in the list view.

A list of documents organized by suppliers first.A list of documents organized by suppliers first, with the filtering panel open and the list items filtered.