Introduction
My team was trying to bring a new user group (suppliers) into the ecosystem of the company.
The main workflow that linked suppliers to our existing user group (merchants) was ordering. The goal of the project was to create a way for merchants to order directly from suppliers.
Purchase orders already existed in our legacy product. The purchase order is one of the oldest workflows in the company and was poorly maintained. The workflow was used for updating inventory levels, and suppliers were not connected. There was an enormous amount of UX and technical debt issues.
Through user research, we found that:
- Purchase orders were vital to merchants, so they had to do anything to make it work
- Merchants created their own custom workarounds, which often required information management outside of the software and impossible to support
- The communication between merchants and suppliers to complete an order was scattered across a variety of spreadsheets, emails and documents which made it difficult to keep track
The current implementation did not fit the needs of the merchants and we found that the underlying data model for the existing workflow did not accurately reflect what it was like to order from a supplier.
The existing workflow only allowed orders to progress in series.
This model was limited because suppliers often fulfilled orders in multiple shipments, and could not account for delays or other common logistical issues. Orders were almost never fulfilled in a single shipment and financial reporting was always linked to individual shipments. We created a more accurate data model for ordering.
Data model that accounted for multiple shipments progressing in parallel.
More research
Learning the ropes
I interviewed merchants to learn their ordering process. I wanted to understand how they worked and their daily tasks, not just how they interacted with software.
The general steps to ordering. Yes, I made that weird backwards S connector so it would fit better on this page.
I often build a core group of users to validate and test ideas out all throughout the design process. I’ve never been fortunate enough to work with researchers so I have to create my own ways to quickly validate ideas.
I created a series of prototypes to demonstrate proposals. I encouraged them to really go into detail about the motivation behind each task, and issues that commonly appear.
The project manager and I started to speak with more customers to understand their priorities and which features would bring them the most value. We shaped the definition of our MVP through these series of conversations and interviews.
Picking up steam
Gearing up for a private beta
The beginning steps to placing an order followed a standard e-commerce flow: product to cart to order.
A product page designed to fit any product added to the catalog. I hate looking at this backpack.
The cart needed to scale for orders being sent to multiple suppliers.
I designed a scalable version of the cart that would be able to carry items from multiple suppliers.
Merchants also needed to use it as a holding area until they were ready to place an order. The deciding factor that led merchants to submit orders was typically reaching a minimum purchase amount in order to waive shipping fees.
The order page
The shipments section allowed merchants to keep track of how their order is being fulfilled.
The order page with a summary and shipment tab was designed using the new data model. The individual shipments allowed merchants to be more organized with their records and to reconcile inventory levels more accurately.
The MVP was enough to begin testing and give more insight into prioritizing the backlog of additional features.
Lessons learned
Some thoughts
The importance of defining an MVP
I learned a lot about prioritization and continue to learn the purpose of making small meaningful steps. Mitigating as much risk as possible while still creating something useful is the balance you have to strike when defining an MVP.
Advocate for your users to all audiences
There was always pressure from leadership to deliver something fast or different than what users needed. It was important that I presenting the research as objectively as possible in order to steer the direction towards creating something truly useful.
Get everyone on your team more involved in product
In most of the teams I have worked with, there was typically a much more vocal technical side. The developers had very little understanding about product. I worked hard to teach the members on my team how I design and the importance of research. We were much stronger as a team because every single member became fluent in understanding how users would be impacted with their efforts.
