QR Code Scanner — Reduce complaints by 54% through in-app instructions

Hangry Scan QR Instructions — UI

The Outcome

QR Scanner Instructions is a feature to help users who have problems scanning QR code to get Hangry points. I was the design PIC of this project and this feature has successfully reduced complaints by 54%.

Quick Intro About Hangry

Hangry is a multi-brand virtual restaurant company based in Jakarta, focusing on serving great food through food delivery channels.

👀 Intro to QR Scanner Feature

QR Scanner is a feature in Hangry App that allows users to scan their QR code from the receipt after buying Hangry’s product through online food delivery app such as Go and Grab Food. The receipt will be given to the users alongside with the food, usually the receipt will be placed inside the plastic bag.

Fig.1 — Project Details

🤔 Project Background

The number of complaints from users reported by the Customer Experience (CX) team include:

• Receipt is difficult to scan
• A lot of complaints

🧐 Project Goals

The project goals are:

• To help users who have problem scanning QR code
• To reduce complaints

Deep dive into the problem 👀

Hypotheses

Based on the project background, there are some possibilities that cause this QR code to be difficult to scan, but not limited to:

• Printers quality
• Users’ phone camera quality
• The QR Code density

Based on the hypotheses above, we conducted an experiment to check whether our QR is really difficult to scan. In this experiment, we tried to print a few QR Code with a different size (small and big) and scan them by using Android (Infinix) and iOS (iPhone 6s).

Fig.2— QR Code Experiment

👀 The Experiment Results

1. Flattening QR receipt DRASTICALLY improve success rate
2. Small QR or Big QR print area DID NOT affect scan success rate
3. iOS tends to have higher success rate on bent/arched QR receipt
4. Both on Android and iOS, Hangry App camera has better response & higher success rate compared to native camera app/google lens

Conclusions

1. Focus on asking users to Flatten & Stretch the QR.
2. There is no proof that less QR payload & bigger print area provides higher scan success rate

The Challenges

• How might we help users scanning their QR Code properly by providing in-app instructions
• How might we reduce users’ complaints

Existing Design

Fig.3—Existing Flow

As you can see from the design above, especially on the scan — help page. There’s no other options unless “claim points manually” and “Try again”. We didn’t provide clear instructions to help users who have problem in scanning their QR Code. Thus, we received a lot of complaints.

Benchmarking

I then conducted benchmarking to our primary and secondary competitors which have adapted Scan QR on their app to see other apps as recommendations and opportunities on how to implement the instructions.

Fig.4— Competitor Lists

Benchmarking Summary

Fig.5— Benchmarking Summary

Benchmarking Findings

• Not all applications who have adapted scan QR Code provide “instructions”
• Instructions usually marked with the “?” icon as help function (see fig.6 & 7)
• I found that there are two main important things that the application must have at this very point that is to provide an explanation the use of Scan QR and Scan QR Instructions
• Only Dana and Grab of all applications listed above who have those 2 important things
• They provide illustrations on the “help” page to ensure users notice and help users to get more context on how to scan QR code properly.

Dana

Fig.6— Dana App

Grab

Fig.7 — Grab

As you can see from DANA and Grab above, they both explain the use of scan QR code (what you can do with this feature) and provide “Help ?” to explain on how to use this feature properly.

First Flow & Wireframe Proposal

Fig.8 — First Flow Proposal

Sketching

After I conducted benchmarking, I decided to sketch my ideas to get feedback as early as possible.

Fig.9 First Sketch

As you can see above, I added a question mark “?” on this page. This icon is actually an entry point to the instructions page. I get this idea after benchmarking, where “instructions” usually marked with a question mark “?”.

At that time, the reason why I put a question mark “?” on this page was to make users aware to click on the icon if they have problem in scanning QR code. But we actually have “help” on this page already, which is located at the bottom of this page.

After receiving feedback, I was considering to put scan instructions under “help” which is located at the bottom of the page. So the “help” feature both for “scan instructions” and “claim point manual” are under the same entry point.

Wireframing

After I received so many feedbacks from the sketch that I made, I decided to jump to wireframe where I changed the design based on the feedback given by my team.

Fig.10— First Wireframe Proposal

Above was my first flow & wireframe proposal, I want all users read the instructions first before they can enter the main “scan” page. Thus I force them to read while also give them the flexibility whether they need to read or to be shown this page again or not at all by checking the checkbox.

But, there’s one cons from our point of view…

As a user, I wouldn’t expect that I will be redirected to the “Read Scan QR Instructions” first after clicking the “scan” whether from the Homepage or point page. Our view is that this page will blocking users to get their job done, besides not all users will have problem in scanning their QR Code.

So from the POV above, we decided that we should not force user to read the instructions and give them more control and freedom on how and when they should read the instructions.

Second Flow & Wireframe Proposal

Fig.11 — Second Flow Proposal — Iteration

Fig.12 — Second Wireframe Proposal — Iteration

As we’ve agreed that we wouldn’t force users to read the instructions after clicking the “Scan” button. So I came up with the new wireframe. On the “Scan QR Instructions” page, I provide step-by-step on how to scan the QR code properly and I also provide the CTA to “re-scan” after they read all the instructions.

The Output — UI

Fig.13— The Output — Written in Bahasa 🇮🇩

There are some minor changes on the final UI where I changed the copywriting on the bottom sheet to make it more contextual, whether they need help because of their receipt is folded or wet/damaged.

Are we done here?

Not yet — I decided to conduct a usability testing first before the feature is live. I conducted usability testing both to internal (outside the tech team) and external users.

Usability Findings

Fig.14 — UT Finding — 1

Based on our analytic tool, there are 7.388 users in total from Jun 17 — July 16 2022 who have landed on the “Scan” page but there are only 691 users who clicked the “Scan QR Instructions” meaning only 9.35% of users who have landed on the “scan” page need to read the instructions. We can assume that we have successfully informed users to flatten the receipt before they scan the QR Code on this page.

Fig.15 — UT Finding — 2

Fig.16— UT Finding — 3

The Outcome

I collected the data 3 months before & after the feature was released. Here are the data.

Fig.17— Data the last 3 months before the feature was released

Based on the data above, we can see that there were 15 complaints max we had per month or 11 complaints on average per month.

Fig.18 — Data 3 Months after the feature was released

Based on the data above, we can tell that there are 5 max complaints we had per month after the feature was released. Some of the problems (after we release) are still unclear because some of the users who complained did not answer or explain why this could happen when contacted by the CS team.

Fig.19 — Data Comparison (Before & After)

We have successfully reduced complaints by 54% after the feature was released on Mid March 2022 🥳

The Takeaway

• Take everything with a grain of salt
• A guidance would be very helpful for users

Thank you for reading my article! If you have any questions, feel free to contact me on Email at wiryanaw@gmail.com or you can find me on LinkedIn and Instagram 🙌🏻