November 28

How We Built a Mobile App for Detsky Mir Retail Store Employees from Scratch

(Detsky Mir is the largest children's retail chain in Russia, Belarus, and Kazakhstan. It comprises over 1,300 stores, three brands, more than 20,000 employees, and handles up to 300,000 online orders daily. The company has become a leading player in the region's retail sector, offering a wide variety of children's products from toys and clothing to educational materials and baby care items.)

Detsky Mir offers numerous internal digital services. A year ago, we decided to support the company in developing one of these areas by forming a dedicated B2E (Business-to-Employee) project team. The team’s first project was creating a new mobile app for store employees.

The zone to working with online orders at Detsky Mir Stores

Project Preparation

Why do store employees need an app?

Store employees handle a variety of tasks. For example, an online order manager picks items from shelves for online orders, consults on stock availability, checks price tags in the sales area, helps locate orders in the pickup zone, and clarifies product availability information.

Most of these tasks are supported by a SAP-powered computer located in the store. However, in busy stores with high customer traffic and many online orders, this single computer often becomes a bottleneck. First, employees form queues to use it, and second, running across the store to the terminal to check details can be inconvenient.

In 2019, as an experiment, Detsky Mir launched the "Mobile Cockpit" project, allowing some SAP functions to be accessed through the first mobile app for store employees.

Initially, the app was developed by a single developer who handled both the front-end and back-end, as well as studied store processes. The app was built as a classic cross-platform solution using React Native.

The experiment was successful, and employees appreciated the benefits of mobility. Various internal departments began to express interest in adding their own features to the app. Store research also indicated the need to optimize processes to speed up employees' work, reduce queues, minimize errors, and ultimately improve the NPS (Net Promoter Score). The app needed scaling and deeper integration into the company’s processes.

Thus, a dedicated team for this direction began to take shape.

"The icon is an artifact that needs to be ready for the very first release. We decided to draw inspiration from the Detsky Mir style—it’s our product, after all. We explored various ideas: the arches that frame every store entrance, the metaphor of an order as a package, a warehouse-like building, and more. Together with the art director and the team, we chose the traditional house icon, symbolizing the store in our graphic system."

Develop the old app or create a new one?

By the time a dedicated team was formed, the existing employee app already had a rich set of features. And it worked! However, we decided to move away from it in favor of developing a new one.

Why?

  1. The original app’s developer had left the company.
    Understanding, modifying, and extending someone else’s code without breaking it is challenging.
  2. We planned to make the app even more functional.
    To achieve this, we needed a stable and scalable platform that could be maintained by most developers. We decided to transition from React Native to native Android and iOS development.
  3. A dedicated team was already in place.
    By that time, Detsky Mir Group had established a specialized team of developers, QA specialists, and designers experienced in Android and iOS platforms.
  4. Distribution through official app stores.
    Unlike the old app, the new one would be distributed via the App Store and Google Play, rather than through direct links.

Goals for the Product Team

The future internal digital product team was given three objectives:

  1. Make the new app as functional as the old one.
  2. Improve its features using UX research in stores, employee feedback, and analytics.
  3. Build a flexible platform for future scalability to meet department needs with minimal effort.

Assembling the Development Team

We were approved for a minimally required team of 8 members:

  • Product Manager,
  • Project Manager,
  • UX Researcher,
  • UX/UI Designer,
  • iOS Developer,
  • Android Developer,
  • Backend Developer,
  • QA Engineer.

We spent a long time searching for a UX researcher. Initially, we brought in specialists from other Detsky Mir Tech teams for this role. They had to visit stores, talk to employees and managers—a process that turned out to be a fascinating story on its own. Let us know in the comments if you'd like to hear more about it.”😀

The project started with an incomplete team. The team was partially composed of internal employees from 🔗Detsky Mir Tech and partially hired externally. Initially, it included only a project manager, a product manager, and a backend developer.

We retrained a support team member to take on the QA engineer role. Her deep understanding of how store employees interact with customers proved to be incredibly valuable.

Finding stakeholders within the company

While team members wrapped up their previous projects and transitioned to the new team, the product manager and backend developer began analyzing the old app.

They immediately encountered the typical development chaos of a large company. There was the backend of the old app, the backend of the Detsky Mir website, and the SAP backend where all processes were managed. The team met with developers and product managers from related teams to make sense of everything.

In parallel, the product manager spoke with everyone in Detsky Mir who might be interested in contributing to the employee app. Before long, HR, logistics, inventory, warehouse, and other departments began reaching out on their own when they learned that a dedicated team was being formed in Detsky Mir Tech for the app.

Retail was the easiest to deal with: the old app worked and met the needs of store employees. In all other departments, the requirements were vastly different. It was crucial for us to understand what was missing for each group, the processes behind their needs, the problems they faced, and how to translate all of this into user stories.

"For instance, today we discussed an app for warehouse employees with the warehouse team. They want an app that details their earnings. Their wages are performance-based and calculated using complex formulas. Employees want to be able to see at any time how much they’ve earned and why they’ve been fined.”

The product manager created an impact map that outlined stakeholders and their desires. This helped us gather ideas for the development backlog.

Diving into the processes of retail stores

We had to start with a backlog of critical features that needed to be transferred from the old app to the new one and improved.

Once a week, we visited Detsky Mir and Zoosaurus stores. It was essential to understand firsthand how they operated. We also had frequent meetings at the office with retail representatives, who explained store processes from a business perspective.

It turned out that this field has a high entry threshold because it uses its own terminology, and some store processes differ from the business perspective. It’s also not always easy to find someone who knows the critical details, documentation is scarce, and a lot of research is required.

"For example, you suddenly learn that retail has 'pickup.' And there’s also 'in-store.' In both cases, the customer collects their order from the store. However, in the first case, we deliver items from the warehouse to the store, while in the second, the manager picks them directly from the shelves in the store. Sitting in the office, you have to figure out the related processes: how 'pickup' differs from 'in-store, ' their respective shares, and how all of this impacts the business.

At some point, you think: 'Aha, I’ve got it! They’ve explained how pickup works, and we’ll implement it in the new app! ' But then you visit a store and realize things work a bit differently. Store employees don’t follow the documented processes or what was explained in the office. Instead, they have developed their own practices due to specific constraints: limited storage space, low throughput, few visitors, or a high volume of 'pickups.'

You return to the office thinking, 'Now I really understand how to digitize the pickup process. I have a few hypotheses to speed it up—great! ' But then you visit another store in the chain, and it’s completely different again!" 🤯

Store visits became our primary source of information. We gathered insights through conversations with employees, working alongside them, and systematically collecting and analyzing data. A large number of insights emerged during these visits.

We came to accept that no one in the office has complete information about how stores operate.

What to do when employees "fraud"?

What happens when employees bypass business processes ("fraud")?

It’s challenging to ensure uniformity of processes across all stores in the chain. The stores are different. There are over a thousand Detsky Mir stores, located in various regions and countries. Even neighboring stores in Moscow can differ. One may have a lot of customers due to being near a metro station, while another may have fewer. Store managers also have different management approaches.

The network is growing and evolving. The goal isn’t to rigidly enforce rules and force employees to follow them at all costs. Some instances of "fraud," where employees try to game the system, can actually be beneficial. Not every attempt to bypass the system is harmful. But to understand this, you need to delve deeply into each specific case.

Example

When assembling an online order, a store employee could see the customer’s phone number in the app. If a product was hard to find, the employee would call the customer to inform them that the order would be marked as fully completed, but the item would be missing. If the customer agreed, the employee would improve their KPI by closing an incomplete order as a complete one. If the customer refused, the employee would ask them to cancel the order, thus maintaining their KPI.

This trick skewed the statistics for the business, as the actual situation wasn’t visible. So, in the new app, we decided to hide the customer’s phone number from employees. This led to a surge of support requests 🤬, but it was necessary.

Reverse Example

When a new order arrived, the system calculated the time by which it needed to be assembled. The employee saw the allotted time for assembly in the app. If they failed to meet the deadline, their KPI would suffer.

To avoid this, employees "frauded" the system. They would mark orders as “fully assembled” in the system on time, even if they hadn’t been assembled, and would later add the missing items. As a result, in some stores, many incomplete orders piled up, and employees had to keep track of them.

After understanding the process, we gave employees the option to extend the assembly time legally in the new app.

Our task is not only to impose restrictions or provide leniency at the app level, but also to study whether the time allocated for order assembly in the system is calculated correctly. The formula may be outdated and not take into account new factors that have arisen since it was introduced. Yes, this task is largely for cross-functional teams, but we assist our colleagues with real data from the stores.

Employees "fraud" because it is often easier for them to work that way, and sometimes it's the only way to handle their tasks. Through this kind of on-the-ground optimization, they are actually improving the business.

What to Do When Employees Create Their Own Business Processes

When "fraud"—the bypassing of established processes—actually benefits the business, it becomes an insight.

This signals to us that we need to analyze the "gray" process and legitimize it. We gather all insights into our repository. Some we implement directly within the app, while others are first discussed at the business or company level.

“We accidentally learned of a case through a conversation with an employee. When a lot of small items (pencils, erasers, pens) are delivered to a store, they’re stored in large boxes. And when an online order comes for a pencil with kittens on it, it’s impossible to find among thousands of other pencils. In one of the stores, employees decided to sort the pencils into smaller boxes and document their location in a special Excel file.

One of our tasks is to identify such local processes and digitize them in the app. We also offer business improvements on the physical level. For example, in this case, we proposed scaling the box labeling system.”

We don’t just identify problems in stores but also strive to understand and address their root causes at a higher level.

Implementing the App in Stores

Currently, there are two similar apps for store employees: the old one, which is still more functional, and our new one. Naturally, most users still use the old app.

At the start of the project, the idea was not to promote the new app or force employees to switch to it. We simply wanted to inform them about the new app while still supporting the old one. Later, we realized that managing two apps was challenging and expensive.

So, we decided to discontinue support for the old app. We set a date for its deactivation, by which all its functions would be available in the new one.

To gain the first users necessary for gathering statistics, we held several meetings with store directors where we introduced the new app and its already available features.

Later, we conducted a series of informational events: calls with directors, email newsletters, and physical communications in stores. This led to more users and data, which helped us develop the new app further. The most rewarding part was that some store directors began reaching out directly to our team, offering suggestions for research in their stores.

Many New Employees Start Using the New App Right Away, and the Old One Slowly Fades Away

End of the Article and Just the Beginning of Our Work

We feel that we've accomplished a lot already, but in terms of product work, we're just at the beginning. Some things are clear, but much is still uncertain. There’s a lot of work ahead. It’s diverse work, requiring people with different skill sets.

Right now, we're expanding and hiring. We hope you've read this post to the end, feel inspired, and are ready to join us.


🔗Join the Great Team at Detmir Tech


Authors of the article:
Product Designer Sergey Bulatov, Product Manager Vadim Kopytin, Editor Kirill Yegerev