Digital Transformation Leroy Merlin: Designing an Interface for Working with Customer Calls


They say repairs are worse than a fire. Fortunately, we have Leroy Merlin, so putting out a repair fire is much easier. We rush to the nearest Leroy and randomly buy up plaster, drywall, fittings and a lot of very necessary things. At home, it turns out that the faucets do not fit under the sink, and the color of the floor tiles is not blue enough. Or the repair is over, and unopened cans of paint occupied the entire balcony.

Such unsuitable, defective or excess goods can be returned to Leroy Merlin within 100 days at any store in the network. Previously, a store employee worked with applications using a paper application book, and an attempt to transfer everything to digital came across the creation of a complex, not at all user friendly interface based on Microsoft Dynamics. But Leroy Merlin decided to try again to solve this problem and enter from the other side. We tell how we designed the interface for working with customer requests and transformed the business by introducing digital technologies.

Customer and project objectives

The Leroy Merlin retail chain has more than 100 hypermarkets in 60 cities of Russia. The entire network employs more than 35 thousand employees. The number of customers is in the millions, the turnover in billions.

Sometimes buyers have complaints about the quality of the goods. Someone wants to return an unused punch or exchange a laminate. Appeals were collected everywhere: on the site, by phone, through a call center, in stores. Appeals from different channels were processed in different business processes. Everything was very long, there was no single space for storing the whole story.

For example, a customer filed a written complaint at a store. The employee processed the appeal and gave it to the manager. The manager consulted with a competent specialist and sent a response to the client.

The process consisted of many steps and nuances. For employees of a particular store, everything was transparent, but not for the head office. Everything that happened in the store remained in the store.
The team decided to create a system that automates the processing of customer requests. The goal of the project is to create a simple and intuitive step-by-step interface for working with customer requests in Leroy Merlin stores. Written requests from the book of records must be transferred to the global system, processing must be automated.
It was necessary to design the system interface and develop a design.

The first step to design

We translated the data from the brief made by the Leroy Merlin team and additional input to user scripts. They made User Story and described business requirements without going into details of the system itself.

11 short basic scenarios were singled out, which they took as a basis for the work. The length of the script varies from 3 to 9 steps.

List of working scenarios:

  • Registration of a new appeal.
  • Response on the appeal.
  • View appeal with correspondence.
  • Search appeal.
  • Pass the appeal to CLAIM.
  • Printing, export circulation.
  • Creating a new client as part of the registration of the appeal.
  • Create a new task as part of viewing the appeal.
  • Reassign appeal.
  • View and complete tasks.
  • Performing the task of printing a circulation decision.

Design and prototypes

The project was done in Adobe XD. We started with a conceptual prototype – this is the stage when we figure out the basic interface elements and navigation. We made several key screens and discussed them with business customers before starting a more detailed work.

Design Principles

In multi-page systems, there are several options for solving the same problem. There is no single way to create a table or form. We sought to make a good working tool and identified key metrics for ourselves. We were guided on the metrics of comprehensibility, learnability, ease of use.

Our goal was this: to create an interface using familiar patterns that would not require significant training time and at the same time remain flexible and extensible.

At the interface level, this resulted in the rules that we tried to adhere to:

  • There should not be hidden actions, everything should be visible.
  • We use captions for icons, fields to be clear.
  • Not small, we prefer large text.
  • If there is a lot of information, then we are not trying to fit everything into one screen. Let the user scroll the page, this is familiar to everyone.
  • We make error messages with human signatures in order to understand what is happening.

Designing scenarios, not screens

We focused not on individual pages, but on related chains of screens.

Scenarios have several advantages:

  1. Checking the quality of work. You can put yourself in the place of the employee who will use the system. This is a convenient way not to forget about important points.
  2. Discussion of prototypes with business customers, involving employees of various departments in the discussion.

Thanks to the scripts, good communication is built up, the participants quickly immerse themselves in the project, and we can additionally evaluate the correctness of the work done.

Prototype Intermediate Testing

The project was driven by weekly sprints. The results of the sprint were discussed by an expanded working group: we are executors, representatives of the business customer and technical specialists. The prototype end-to-end testing took place at these discussions, but … After the demo release, it became clear that we had missed an important stage: an interview with end users before the start of work and it almost turned out to be sideways.

Representatives of the business customer broadcast end-user requirements that they considered important. And yet, despite all attempts to be objective, their opinions still distorted expectations from the system.

The interface could be better if we talked with users not after the demo release, but at the stage of collecting and clarifying requirements.

Design that changes everything

While we were working on design, the concept of the project has changed. Functionality remained, but navigation changed.

We made two design options: the first was very similar to the prototype, but turned out to be unappealing in appearance. The second took into account changes in the navigation approach. We left the functionality and stuck to the second option.

Over time, I got used to looking at such a course of things philosophically: the designer cannot create the product himself – you need to let colleagues make changes to it. So you can make any project really good.

Implementation Results

Updated interfaces were introduced in one of the customer’s stores. Testing showed that the basic tasks were successfully solved, the interfaces were clear and easy to use.

True, we found that additional business processes require automation. One clings to the other and system users begin to expect more.

You can learn more about this project in the AGIMA case.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *