Reports

Background

SPS Commerce is a supply chain management software company. Retailers like Target, Walgreens, Sheels use SPS’s software to communicate with their many suppliers in order to fulfill products on their shelves. 

The Fulfillment Explorer product was our focus for this project. Fulfillment Explorer's main user is the EDI specialist on the supplier side. Their main responsibility is to maintain EDI compliance with their retailers through their document flow (receiving Purchase Orders, sending other documents like Invoices etc.) What we know about this persona is that they care about improving efficiencies in their process so they can streamline the many document flows they monitor with retailers.

User Research

Through ongoing discovery research, we observed that our users were performing extensive search queries that were the same once a day or multiple times a day, week, or month. To dive further into this research we set out to understand why our users were performing these extensive search queries along with gathering more context of the user through user interviews.

We facilitated in-depth qualitative interviews with users from a range of suppliers that varied in company size. We learned that they were performing long search queries to monitor their document flow in order to see if troubleshooting was needed. Along with this main discovery, we found 3 consistent themes.

Felt like it was cumbersome to log in every time to see this data

More context - they use a large number of other systems for their day-to-day work and Fulfillment Explorer was just another system to add to the complexity.

Preferred email to manage their day-to-day work

More context - They currently use email to manage Retailer relationships and use it to organize their work

The type of document flow data that each user desires varies

More context: Factors like company size, retailer relationship, and job responsibilities alter the type of data desired

Problem Space & How Might We Question

After our discovery phase and before diving into solutioning we decided to frame the problem. We constructed a How Might We question to drive our ideation appropriately. The question was “How might we help EDI specialists be more efficient in maintaining a healthy document flow with their retailers?” We wanted this question to be broad enough to generate many ideas but not too broad that we lose sight of the problem.

Approach

Our initial approach was to stop these errors EDI specialists would have to troubleshoot in the first place. We quickly learned through stakeholder interviews with internal customer success representatives who helped EDI specialists troubleshoot these errors that these are system errors that can’t always be proactively stopped. 

After this realization, we held a workshop to align and ideate solutions together. Leveraging the key user insights, we constructed our key approach which was to send EDI specialists a consolidated view of their document flow through email every day, week, month or year depending on the cadence they needed. We would call these emails reports. This solution fulfilled the first 2 key user insights.

1. The user didn’t have to log in to see this data

2. The user could utilize their preferred and existing application, email, to manage retailer relationships

Lastly, we determined that these reports needed to be customizable. Fulfilling the 3rd key user insight.

Process

Alignment on requirements

I needed to design the management of these reports that would be in the UI of Fulfillment Monitor. The three main functions that this UI needed to accomplish were…

1. Create reports

2. Edit reports 

3. View reports that have already been sent out

Sketch

After defining what main functions the UI needed to accomplish I started exploring different user flows and interactions. At this stage of my process, I like to brainstorm as many ideas as possible and then start whittling down. Early on, I like to incorporate the whole team (product and engineering partners) in the discovery process. I’d facilitate weekly design critiques and brainstorming sessions.

Wireframe

After brainstorming different user flows and interactions, two different user flows and interactions surfaced that I decided to explore through wireframing for further critique and feedback.

The main difference between these two different paths is that flow A has the creation of a report in a step-by-step wizard and user flow B has the creation of a report in the same UI as editing a report. The reason I found this path worth investigating was because I believed a wizard can help guide and focus the user on one step at a time in a complex sequence.

Flow A

Flow B

However, after further critique and feedback we concluded that the wizard wasn’t ideal because it created a disjointed experience for editing and creation. Also, we learned that wizards can be too rigid, especially for power users. Through our user research we learned that EDI specialists are technically advanced and could find this UI too limiting and rigid. This led us to our final user flow where the editing and creation experience is similar.

Final Prototype

Once the final design was ready, I applied our pattern library. Our pattern library is a system developed and maintained collaboratively with myself and the other 3 product designers in order to create scalable experiences across our products.

Impact

We gathered qualitative attitudinal data through customer interviews and learned that this feature helped EDI specialists be more efficient in maintaining healthy document flow with retailers by… 

1. Eliminating multiple steps in their process (reducing approximately 6 steps)

2. Reducing the number of systems they need to log into every day to do their job

3. Keeping important data flow information in their preferred centralized place (email)

Original HMW Question: “How might we help EDI specialists be more efficient in maintaining a healthy document flow with their retailers?”

What did I learn?

Quantitative KPIs

I would have liked to set quantitative KPIs up from the start so we could measure more of the business impact which we could use to report back to the organization. Sometimes quantitative research can be more persuasive and give a more impactful glimpse of the success of your work.

Team Collaboration 

I learned to keep including the team in design discovery to gather feedback and buy-in. I believe it also created a better solution as critique and feedback drove us forward.