At SupplyShift, our users are Buyers who are able to communicate with their Suppliers on the platform. The answers that the Suppliers send as a response provide increased clarity and transparency between Buyer and Supplier. Sometimes these responses may lack clarity, or need to be edited in some related way. At SupplyShift, Buyers are able to request a change to a response by issuing a Correction request. But at the time of this project, there was no way for a Buyer or Supplier to see how many times a Correction was requested, or how many back-and-forth messages occurred.
As with the start of all UX projects, I wanted to make sure I was doing research in order to properly empathize with our users. In order to do this, I completed some competitor analysis around how other tools managed showing the history of a document or a conversation. I also wanted to make sure that we interviewed internal team members who worked closely with our users, as well as external users who used our platform frequently.
For competitor analysis, I wanted to see if there were any existing patterns in the UX sphere to show the history of a conversation. Luckily, there were quite a few platforms who used this sort of functionality, so I was able to find quite a few examples of this.
For user interviews, I made sure to interview a handful of members from our internal implementation team, who frequently work with our users to help them navigate the platform. I also was able to interview three external users to discuss their needs when it came to understanding how they used Corrections and if understanding the history of a Correction would be useful to them.
After my research, my product manager and I began to think about what our project goals were:
I also nailed down a couple of How Might We statements to help myself and my product manager really focus in on the problem we were solving as we began to move into the design phase.
With those goals and statements in mind, I started with sketching out some preliminary low-fidelity ideas on my iPad. This helped me to try different layouts and different solutions without feeling like I was spending too much time or effort on early stages.
Once I had some preliminary sketches thought out and I had a chosen direction, I moved to Figma. This was the phase where I started sharing with my product manager what I was starting to think about. With his help, I checked with my engineering counterparts to get their feedback as well.
Because it was a relatively simple project and straightforward design, I felt okay with pushing forward to high-fidelity mocks before testing. Because so much of interpreting the timeline was related to colors and icons, I wanted the timeline to be as close to complete as possible before testing. That way, I could test the page as close to the final result as possible.
Every Correction would start with the status of Drafted, as there is a critical step between a Correction being created and a Correction being sent that allows a Buyer to delete the Correction if they make a mistake. Once the Correction is sent to a Supplier, it then moves to the “Sent” status. Any statuses that include messages sent between the Buyer and Supplier can also be expanded to show relevant information, such as the message, the expected correction, or any file attachments.
Once a Supplier has viewed a Correction, they have the option to respond to it by correcting their answer. At this stage, they can also add any documentation they want to provide. The Correction then moves into the “Responded” status. When viewing the response in the Corrections module (as seen below), the Buyer can see the question, the updated answer, any comments from the Supplier, and any added documentation.
The final status stages that a Correction can move through is the “Accepted” state, which indicates that a Buyer accepts the Correction that was made by their supplier. This effectively ends the communication with the Buyer’s sign-off. Another status that can be used by the Buyer is “Rejected,” which allows for the Buyer to issue another version of their Correction for the Supplier to see. The cycle begins again, with the Supplier responding as necessary, until the Correction is settled and Accepted by the Buyer.
Because we wanted to move as quickly as possible, I conducted five usability tests with internal team members who had never seen the designs before. My goal with testing was to assess whether the timeline was readable and made sense to the users. The tasks for each test were:
All tests were easily completed. Testers believed that the product enhancement would provide great value to our users. There was some initial feedback about potentially reversing the order of the timeline, but testers ultimately decided that it made more sense to them to have the newest status at the top of the list. Since test results were so good, this project was quickly able to move to the hands of the engineering team.