Mi Cares

Xiaomi Electronics Service Mobile App

Reimagining after sale support experience for consumer electronics used by 2.5 million consumers

Scaling after-sale business for Xiaomi

With the considerably greater usage of the devices during the lockdown 2020, there was a rapid increase in consumer footprint in Xiaomi's aftersale busniess. Xiaomi customers could resolve their device issue through visiting service centre, calling customer care support or even resolve themselves by looking at the frequently asked question. However, with numerous possible ways to resolve their device issues, Xiaomi was still in awkward adolescence stage to address their consumer problem in a more convenient way. Since majority of Xiaomi customers are mobile users, Xiaomi India decided to build a standalone mobile application for their consumers to address after sale issues.

My Role

I was hired as a contractor for 3months in which I primarily collaborated with a product manager and a mobile app lead in understanding the business and technical requirements to ideate solutions that are scalable in the future. I did the whiteboard discussion using FigJam and defined scalable component library and a high fidelity interactive prototype with Figma.

Product Team

1 UX Designer (Myself) (Contract)
1 Product Manager

Engineering Team

1 Mobile App Developer (Flutter)

Duration

May 2021 - Jul 2021 (Summer 2020)

What is after-sale?

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.

Initial Discussion

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 whats 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-requiste 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-requiste 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 continously. 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.

Defining the design principle

Before the product could mature with new features and experiences, some significant ground works were required for scaling. So we 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.

Relooking at 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

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.

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.

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.

Next cluster
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.

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

Intitially 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.

Component level issues

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

Eventhough 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.

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.

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 snd 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.

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.

[1] 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.

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

[3] Talk to a representative: This is connect to representative via interactive voice response (IVR) and get clarified with their doubts.

But how do we pioritize all of these quick resolve mechanism along with "book a service" module?

Designing the
Home Screen

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.

Other 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.

If you don’t care, your customer never will.” – Marlene Blaszczyk

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.

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 simplied 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.