Platform Experience / Mobile AppShipped

After-Sale Support Experience for 2.5+ Million Xiaomi's Consumer Electronics Users

Timeline: Q2 2021
Focus: UX Design
Focus: Interaction Design
Focus: Design Handoff
Team Size: 3
Xiaomi Electronics Service Mobile App Complete Case Study
Overview

Context

During the 2020 lockdown, Xiaomi experienced a surge in after-sale service demand due to increased device usage. Customers had several options to resolve issues—visiting service centers, calling support, or browsing FAQs. However, these options were fragmented and lacked a unified, mobile-first experience, especially for Xiaomi's predominantly mobile-native customer base in India.

Problem

Despite multiple support channels, Xiaomi's after-sale ecosystem remained disjointed, inefficient, and hard to scale. There was a clear opportunity to consolidate support services into a single, user-friendly mobile interface that streamlined issue resolution and improved customer satisfaction.

My Role

As the sole UX designer contracted for 3 months, I collaborated closely with a product manager and a mobile app developer to:

  • Translate business and tech needs into a user-centered mobile support experience.
  • Conduct ideation workshops via FigJam to align on scalable design directions.
  • Define a scalable component system and deliver a high-fidelity interactive prototype in Figma for development handoff.
Design principles comparison between ideal sales scenario and ideal after-sales scenario
Background

What care a consumer needs after purchasing a new device?

  • Which is the convenient way for the consumer to connect with a service assistant for resolving their device issue?
  • How is the consumer need been addressed?
  • Will a consumer continue their engagement with the brand?

These are some of the critical questions that evaluate the after sale aspect of any device. But the consumer has lot of question after purchasing a device.

Design principles comparison between ideal sales scenario and ideal after-sales scenario
Stakeholder Requirements

Insights from the Internal Stakeholders

I kickstarted by setting up a meeting with all key internal stakeholders, which included product manager, software architect, mobile app developers, tester and people from marketing team to understand what works well in the existing system and what doesn't. This cross functional team discussion helped me to understand the technical and business constraints of the product. Here are some of the important points that we arrived at after our initial discussion.

What's the issue we need to address?

Knowledge about their device and its issues

Xiaomi currently has lot of fruitful after-sale information about each devices for their customers. Consumers with zero device knowledge couldn't find the right lead to approach the customer service. Whereas, power users expected some pre-requisite technical knowledge about their devices before approaching a external resolve mechanism. However discoverability was the key issue here.

Funneling service type by issue severity

In the current scenario, majority of Xiaomi consumers fix any issues (irrespectively of the severity) by simply visiting a service centre nearby. Consumers with zero device knowledge couldn't find the right lead to approach the customer service. Whereas, power users expected some pre-requisite technical knowledge about their devices before approaching a external resolve mechanism. Though there are multiple easy ways to fix the issues, there is no proper funnel for consumers to pick the efficient ways to address their issue.

Engagement and Retention

The after-sale experience flow is incomplete without the retention of the consumer to use the brand continuously. Customers should feel in control on their products while having a prolonged engagement with a brand. So providing a seamless and effortless service touchpoints was one of the necessity in reimagining the experience of the app.

Guiding Design Principles

The team started out to define the design principle by having a high level zoomed out look at the critical touch points in both Xiaomi devices' sales and after sale scenario.

Design principles comparison between ideal sales scenario and ideal after-sales scenario
Restructuring the Information Architecture

We broke down the information architecture into multiple clusters based on the design principle and priority as the product need to hit the market by Nov 2021. Since the development period is very short, instead of setting up the component library in first place, we started to build the first cluster and ensured that it would cover most of the important components so that it can be reused for building the other clusters.

💡 Insightful

Other than device specification, what information the user should know about their device for better usage and quick fixes?

🎯 Convenient

How should we give the flexibility for the users to address their issues?

📈 Progressive

How smooth should be the issue resolving interaction and flow such that it was carry forward with ease?

🔄 Engagement

When should the user be informed about their devices' critical status and how do we get the user focus towards such state?

Grouping the available information from the existing system

Chunking the long form - before and after comparison showing how the booking form was reorganized into logical sections
Feature: Onboarding

How is the device info grouping done?

In the current system, the information are organised feature-wise collectively. In the below example, warranty information of all the devices are grouped together. If it is a catalog in a service centre to view the price list, this grouping makes sense. But for an user who wants to know about their device information, will this be helpful?

This group don't help the user! A Xiaomi Air Purifier customer don't care about hair trimmer spare part price. This grouping brings information overload and user might lost track of what they were looking for.

Chunking the long form - before and after comparison showing how the booking form was reorganized into logical sections

How do we pick out the relevant devices to each user?

From the discussion with the internal stakeholders, we identified that, during the purchase of any Xiaomi devices from an authorized seller, the user had provided either their email address or mobile number or Mi ID for authentication purpose. So when the user login with any of these credentials during onboarding in the Mi Cares app, we import their purchased devices.

Also there were situations where the user might not find the purchased devices in this import list due to various reasons. To cover all such use cases, we enabled importing by scanning/entering the device code which are found in the device or in the device packaging. Overall, this helped us to identify what device is relevant to a particular user.

"Feature-wise" to "Product-wise" grouping

It was evident that we needed a scalable way to hold all the information about a device in a single place rather that collectively showing similar information of all devices So we built "Product Info Page".

In order to be insightful, these "Product Info Pages" should balance prioritizing a variety of customers needs (e.g. What my warranty status vs How much would replacing a screen cost?). They were the most critical architectural change for scaling in terms of the app being insightful. We talked with few Xiaomi product users to better understand what folks needed to know about their device when they have trouble/uncertainty while using it. Then we built the product info page around these hypotheses and ensured that it should be scalable with more information in the coming years.

Chunking the long form - before and after comparison showing how the booking form was reorganized into logical sections

We ensured that components that are being built from the initial design phase are scalable to fit similar use case across the product. This helped us not only to achieve the consistency, but also has great impact in the development cycle.

Chunking the long form - before and after comparison showing how the booking form was reorganized into logical sections
Chunking the long form - before and after comparison showing how the booking form was reorganized into logical sections
Feature: Book a Service

One of the critical feature in the Xiaomi's after sale business model is "Book a service". To interact and resolve a device issue, there are two service options available: "On-door service" and "Walk-In service". Internally there are many factors that funnel various devices to any of these service options. For example, Mi Water Purifier can be serviced only by On-door service. Whereas, earbuds can be serviced only by walk-in service.

Issues Identified

Discoverability

The touchpoint for the booking a service is all the way down in the user interface and has no prominent callout. With more than 15,000 users reaching the service centre daily for their device issue, the feature really needs be easily reachable to the user.

Sudden cognitive overload

Chunking the long form - before and after comparison showing how the booking form was reorganized into logical sections

Initially the form has only one input. As soon as the user chooses the value, the form expands with multiple more than 12 input fields stacked vertically. This creates an information overload as the user is suddenly provided with unexpected number of input items. Reorganising and chunking of information into smaller meaning group is required to make the booking flow more manageable.

Chunking the long form - before and after comparison showing how the booking form was reorganized into logical sections

Component level issues

Xiaomi service booking form showing autofill friction in input fields

Pincode is the only the input the user need to provide in order to choose their preferred service centre. On entering the pincode, the service centre address, city and state gets prepopulated and in non-editable. However, it is placed as an entry in the input field and created confusion for the user especially when trying to edit it.

Xiaomi service form showing validation errors for autofilled fields

Even though the city input field is prepopulated and cannot be edited, the autofilled information has characters which was identified as an issue while validating the input field.

Xiaomi service booking calendar showing complex date selection interface

User can only book appointments for the next 7 days. But a complex calendar was provided to choose from with too much of information and unnecessary navigations.

Xiaomi service form showing marketing consent issues in clickwrap

And also, there is no separate clickwrap for the marketing consents (an optional checkbox). It gets attached to the mandatory clickwrap for confirming the usage of user information for contacting while servicing their device.

Designing the booking flow

We considered various factors in prioritizing steps in the wizard flow of the booking flow. For example, in the old flow, service type was asked first and then user was able to choose the device. This is illogical because device only determines type of service and not the vice versa. And with respect to the layout, bottom sheet was used because it gave the user more reachability and dynamic resize made it more interactive in filling a long form.

Booking flow starting point showing service mode selection, on-door service, and walk-in service options
Booking flow steps: selecting date & time, describing the issue, and booking details
Booking flow completion: reviewing the selection and booking confirmation

But how do we prioritize all of these quick resolve mechanism along with "book a service" module? Can all the device issues be solved only booking an appointment??

There are other easier ways to quickly fix an issue

Apart from the booking a service, Xiaomi offers multiple offer issue resolve mechanism within the app.

Frequently asked question

The simplest issue resolve mechanism that Xiaomi offers is providing list of frequently asked queries for most of their products and services.

Chatbot

This is a 3rd party widget which pulls the data from the frequently asked questions based on the user query.

Talk to a representative

This is connect to representative via interactive voice response (IVR) and get clarified with their doubts.

Other Features

We incorporated all the service mechanisms based on the frequency of usage and importance into the home screen of the app. We segmented the home screen into 3 sections. The primary section holds the key features of this app. The middle section helps user in decision making to perform action in the primary section. And the bottom section holds scope for other key Xiaomi applications.

Booking flow completion: reviewing the selection and booking confirmation

Key features in Home Screen

Frequently asked questions (FAQs)

FAQs section is incorporated into a more embracing and prominent search bar.

Nearby Service Centre

This section helps the user to determine convenient parameter of the primary service.

Future Direction

Customer experience (CX) determines how well the brand serves its community. We have come across brands that are known for good experience from onboarding to exit. This is mainly because they care about their customer value, time, effort and provide experience that make the customer to have prolonged journey with the brand.

It's not just the metrics that measures the success of the product. It's more about how convenient the consumers are able to resolve their issue. Being said that, the next step big step for "Mi Cares" would be to scale the consumer experience to be more localized and accessible as Xiaomi target all user segments across India.

Booking flow completion: reviewing the selection and booking confirmation
Booking flow completion: reviewing the selection and booking confirmation
Reflections

Though it is was a contract basis work that I did for Xiaomi Technologies India, the product & engineering team was always available whenever I had any doubts. Initially I committed only a part of my week for this project. But the problem space inspired me to explore more about the system and eventually spent majority of my time in making the user flow much simplified and efficient.

In terms of user interface, I tried out few newer pattern which I haven't explored before and it turned about visually fluid and gave better control to the user. With Figma, it was even more powerful as it allowed me to experiment and backtrack when required.

Overall I cared a lot about "Mi Cares" in making the experience more straightforward and coherent and it came out really satisfying. Thus it turned out be one of the memorable projects I worked so far.

Next Project

Design Token Adoption