Coolblue is one of the 3 largest electronics retailers in the Netherlands and Belgium. They have made their brand known based on their excellent customer service, and their friendly comedic-style marketing. During the time I worked for them Coolblue was overhauling all their back-office systems to make them more efficient.

Problem

Why this project?

This project had to happen because our business analysts at the time detected that this was the biggest choking point for revenue in the company. Product unavailability happened quite often in our product portfolio and therefore it reduced our opportunity to sell and compete in the market.

Desired outcome

We had 3 overarching goals in mind:

1. Increase the frequency in which a product is restocked.
2. Reduce over-restocking (ergo more warehouse space).
3. Automate the process when decisions were easy.

Our goal as a team was to initially fulfill the restocking frequency and reduce the rate of over-restocking of course. But we wanted to create a system that would learn from the user. We detected dozens of easy decisions that our buyers made daily that did not need their attention. We wanted to free their time on tedious tasks so they can focus on the more important decisions.
For example: making sure to secure a stock of barbecues in black, red and green in the winter so they can sell them in the summer of next year. This is an example of how the skills of a buyer can be better applied since it requires active communication with manufacturers, negotiation about price, signing of deals, etc.
Additionally, we wanted to lessen the burden in the memory of a buyer. People grow, move to other companies, get sick, forget things. All these circumstances hinder the performance of stock availability in a store.

Audience

For who are we building this?

The customer would always benefit from a well-stocked store of course. But this tool was not intended for the customer, but Coolblue’s employee. Specifically, —The buyer— meaning, the person who manages restocking orders. Each buyer is also equipped with a standard desktop PC, with a monitor and mouse, and a gamepad controller.

Roles and responsibilities

My responsibilities

I had a diverse array of responsibilities. I was the first UX designer who ventured into the back-office systems of Coolblue at the time. I had to understand how the business works. How the partners operate. What are the needs of the users (Restocking buyers). Who are the stakeholders, what are their opinions, and why do they have such opinions. This last one was of particular interest since the CEO of the company had a strong influence on some of the decisions that were made.

Scope and constraints

Limitations

The product was not A/B tested. Instead, we measured its performance based on the business KPIs. Fortunately, my entire user base consisted of 12-24 people, so it was relatively easy to reach 100% of my user-base via qualitative tests and user interviews.

Process

Step by step description

This represents a snapshot of the product at the time I was working in Coolblue. I’m sure that the product nowadays looks very different. For instance; the product I designed was meant to work on a Windows machine (desktop) only. I know that Coolblue has since moved to a web-apps model.

1. User interviews

I started this project before there was a product owner, I decided to have talks and understand the work processes of many of Coolblue’s employees. In this stage, I learned everything there was about how the internal logistics of Coolblue are, what is the intended customer experience, how does the process (or processes) that I’m examining involved, etc.

Customer journey map

The image above represents the entire customer journey that the user goes through in its purchase. This process aids the customer journey before the journey even begins.

2. Work as them

Once I could understand the process in an abstract form, I attempted to make orders as if I was a buyer with their existing tools. That is the moment that I began understanding deeply the work process, and the little details that prompt them to make a purchase decision. In this step, I figured that every decision is the result of 3 questions.

1. Should I restock now?
   Well, this a function of the software, we had the data of the stocks that were running low. We could simply bring the product in question to the buyer’s attention.
2. If yes, how much should I restock?
   This is a bit more complicated but not impossible. It was based on how much space we had available (data that was not available at the time) and how much stock a given supplier has (also, not always complete data). 
• Some suppliers would publish their stock, others would not. 
• Some suppliers would have special or seasonal contracts with Coolblue, others would not. 
• Some suppliers would be able to publish their delivery date to our warehouse, others would not. 
3. Can I restock from my selected supplier?
   This depends on the points mentioned above, contracts, delivery time, stock transparency.

It is also worth mentioning at this point that Coolblue has warehouses, so our team was sent to work for a day in the warehouses twice to learn about the limitations of the space and how the current tools were used.

3. Ideation sessions

Through ideation sessions and now with a product owner present we found out that we could produce a product that would automate most of these decisions in time all while leaving the hard decisions to the buyer. During these sessions is there we found as a team the extent to which this business process is involved in the whole machinery that is Coolblue.

3.1. Mapping the old process

It was very important for us to understand both the physical and system interactions that our users were having in different parts of the business. I created this sequence of screens to make a consistent story to our team about what were the steps that a buyer would take to decide whether it was the right moment to restock that particular product.

5. Guerilla testing

Fortunately testing with the end-users of the application would not be difficult at all in this situation. And all it took is to produce a link in InVision and let them walk through the prototype. I would write down their comments and bring them back to the team for analysis.

6. Hi-fidelity prototyping

The tool turned out to be extremely simple. A single pager where only a single decision could be assessed. The objective was to include as much processed information as necessary for our users to be able to make the most correct decision in the least amount of time. The tool would collect all the items that needed to be restocked, and the buyer would assess whether, how much and from whom it wanted the stock (the mvp only allowed for a single supplier). 

After the buyer made the decision, the screen would refresh, and the process would repeat until there are no more items to restock for the day.

7. Probing after release

After each sprint, I would repeat the process of gathering feedback from the buyers to improve the product. After a few sprints, we decided to invite the buyers to our team room. We would have a large screen displaying the application (called Vanessa Purchandez) so they would be able to show the entire team how they interact with the app and ask questions directly to the developers.

8. Demo

Each sprint we had a demo where buyers and other parts of the business were invited. The objective was two-fold. Announce the changes in the app, and discuss the KPIs that we were trying to achieve.

Conclussion

Results

Learnings