Select Page

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.

UX Case study

Streaming restocking decisions

Coolblue found itself in a difficult place where it realized that its restocking process was slow, unreliable and sluggish. Internal research showed that the majority of the problems came from the part of the process where a buyer (A Coolblue employee) would decide whether to restock, how much and from whom. This decision process has a direct effect on whether a customer can purchase a product or not.

Core of the problem

The problem with the restocking process was how the interface was made. The buyer would need to collect over 17 different data points to make a decision. Some data points were very specific and buried in the old interface. Because of the architecture of the software, a buyer could take about 30 minutes to collect all the necessary data points to make a decision. Then it would take another couple of minutes to input the information in their spreadsheets and make the necessary calculations to make a decision. After all this, the buyer would again open the provided old interface, and fill in all the necessary information about the product that needed to be restocked. Each decision could consume between 30 – 45 minutes for the buyer. Naturally, not all products managed to be restocked, and the ones that did? They would often be overstocked, meaning that Coolblue had to occupy its limited warehouse space, and have a higher degree of risk if an accident happened.

Restocking application main screen

Sold out product

The main issue we tried to resolve

Having a product sold out is not only frustrating for the user but also has a significant impact on the brand.

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.

Sold out product

The main issue we tried to resolve

Having a product sold out is not only frustrating for the user but also has a significant impact on the brand.


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

Team’s setup

The team consisted of 1 front-end developer (XAML for Windows applications), 1 product owner, 3 back-end developers (.NET) and I (UX Designer).

The application was meant to work only on Windows in Desktop since it was the official hardware configuration supported by the company. 

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


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.


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 experience map of Coolblue

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.

Checking whether a product should be restocked

Buyers checking necessary data points

Through these sets of screens, a buyer was able to determine whether a product was worthy of being further researched for restocking. A buyer would generally keep his own instruments (e.g. an excel sheet) to generate other important data points. All buyers had a collective wiki to navigate this process.

4. Wireframing

I made the initial wireframes that would display the process of the tool. Because of pressure from the CEO we had to design “something so simple that you could control it with an Xbox gamepad”. In the beginning, I did not believe that he meant that the tool should be controlled with an Xbox controller literally, but as the design proposals were put, it became obvious that the Xbox controller capabilities had to be built-in no matter the reason. 

That being said, I made sure that the tool was “office-friendly”, meaning working well with a keyboard and a mouse.

Early concept of how it could work

Early concept (pre-feedback)

This early concept was done to place the ideas of the ideation sessions.

Purchandez: Concept wireframe

Late concept with feedback

Once feedback from stakeholders and key users was gathered I developed the concept further in pen and paper until I felt confident enough to do the Hi-fi prototype.

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.

Restocking application main screen

Main restocking screen

This was meant to be a one-page application (unless you are a manager). And this screen was meant to repeat many times until a queue of low-stock products has been cleared.

User administration

User management screen

This portion of the application was meant only for employees with special rights. They would be able to set up new buyers and assign them to the right teams.

Dashboard of tasks to be done

Tasks to resolve today

This screen was designed with the intention of summarising and guiding the buyer in her/his daily restocking tasks so the team that depends on the buyer does not fall behind schedule.

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.




Buyers would now spend 1-3 minutes on average on producing a decision in our app. Down from 30 -45 minutes (self-reported).


On average buyers self-reported to have used the app around 50-60 minutes daily with the difference of the number of purchase decisions being made.

In the span of 6 months the availability rate increased by 36% over the complete portfolio of products. The figure also includes automated orders.

Unfortunately, we did not track over-restocking. So there was no KPI that we could make out of this. We were in contact with logistic employees who track incoming goods. But they did not notice a change in the buyer’s behaviour.



We learnt that the philosophy of making it so simple that you could control the app with a gamepad was the way to go. But making it compatible with a gamepad was not necessary.  Unfortunately, there were external pressures that lead us there despite our best efforts.


Automation is hard (and difficult to notice to the end-user), and it does not happen fast enough, especially with external dependencies. While we eventually achieved nearly a quarter of the portfolio, the time that it took proved frustrating to many.

The shipping industry at large remains behind technologically. And they tend to distrust sharing their data. Internal bureaucracy with suppliers as well as with Coolblue, inadequate agreements made previously hindered part of our progress. Our direct engagement with external parties proved very significant.  

The idea of presenting one task per screen had strong fundamentals. However, our buyers quickly realized that was not a way that made them feel in control. The screen needs further design to allow for multiple decisions to be made at once (or in real-time). 

Looking for me on LinkedIn?

Get to know me

Let's work together

If you liked what you saw, and want to work with me, please send me a message. I am always open for new challenges.

I live and work in the Randstad area of the Netherlands (Amsterdam, Rotterdam, Utrecht, The Hague, Leiden, Delft, Harlem, etc).

For the SEO optimization guys. Thank you for your offers. But I am not interested in your services. This is a personal portfolio. I do not seek to have millions of visitors.