Designing a Demand Forecasting for an Inventory Management

TradeGecko is an inventory and order management software for small businesses with multi-channel



My Role

Product Designer

Skills I Used

User Experience

Why Demand Forecasting?

TradeGecko users are small businesses. They are owners of a successful products-based businesses but limited resources on their hands, including warehouse space. As such, our customers need to strategize when and what to order so that they meet their customer's demand, while maximizing precious warehouse space.

Our customers need to be able to find the sweet spots for each product. This is called Demand forecasting, and it is one of the top requested features on TradeGecko when it comes to the Intelligence section. If not done correctly, this could lead to either overstocking or going out of stock, which are two of the biggest challenges faced by our customers in regards to inventory management.

My role

In this project, I worked as product designer in a team of five: a Product Manager, one designer (yours truly), and three engineers. I worked with the same team that delivered the improved reporting experience.

My responsibilities include:

  • Create an initial wireframe, taking into account all the other feedbacks from the team members
  • Creating a testable prototype from initial wireframe for user testing
  • Translating wireframe to high-fidelity design for further user testing
  • Iterating on the high-fidelity design after user testing and for handover to development

Design Sprint

For this project, the team based our process on the design sprint approach: a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. The week went as follows:

  • On Monday, we observed how customers plan for demand and mapped out the challenges faced regarding demand forecasting. We visited two of our customers that are based in Singapore to ask them about their forecasting procedures and see them in action.
  • On Tuesday, we looked at our current competitors. Then, based on what we've learned so far, each of us sketched our own solutions.
  • On Wednesday, we took a look at each of our sketches, critique them, and agreed on a elements that will be used to move forward.
  • On Thursday, we turned the sketches that we worked on yesterday into an interactive prototype.
  • Lastly on Friday, we circled back with the customers we met earlier this week and sought their feedback on our prototype.

The Prototype

During the design sprint, we discovered the elements customers needed to do their forecasting: While they want to see our recommended reorder number for a product based on past sales, they also wanted to see historical sales number, so they can feel for themselves whether the number is correct or not.

After showing the first prototype to our customers, we also realized they needed to see additional information such as the available stocks and how many are already in a draft Purchase Order. We also noted that while they want to see the recommended reorder numbers, customers still want to edit these numbers based on their knowledge of the stock before adding it to a Purchase Order.

I then wireframed our design as a low fidelity prototype to be sent to customers. The initial prototype includes a two-step process: Reviewing the forecast number and generating POs to fulfill this number.

The Design

Once customers have validated the protoypes, I got to work with the high fidelity designs.

Clicking on each product variant will bring up the following graph. We also explain how we calculate the forecast number

Clicking on Add will create a draft Purchase Order (PO) with the product specified. However, if there is already an existing draft PO from the same supplier to be sent to that location, we consolidate the POs.

Customer can view the list of POs created from forecasting by accessing the Purchase Order tab

What happened after the beta launch

While demand forecasting is still a top problem to solve of our customers and our prototype was well received, it was still long ways from achieving a product-market fit. Specifically, we needed to improve on the forecasting models to accomodate events like seasonality to be up to par with our competitors.

However, the company went with another direction and the demand forecasting efforts were shelved. A year later, TradeGecko was acquired by Intuit.

← Back to list of works