DHL KYC Appendix

Overview

Problem Statement

This case study (and the others) are from my work about 5 years ago in my career. However they do give a good example of a generalist UX approach that includes user research that I was doing back then vs where I am at now (for that see the rest of the portfolio aside from the case studies). I was not aware of artifacts like card sorts and tree tests back then and mostly focused on user interviews and usability tests supported by heuristic audits. Also, please beware that there might be formatting issues, this is a part of my portfolio I have not revisited in many years. Thank you very much, reader, for getting this far.

"Know Your Customer" (KYC) is legal compliance that is required of banks and delivery companies in many foreign countries. In this case, I (and my UX agency I was running at the time) was tasked with focusing on a DHL app for India. The DHL KYC app is used to gather customer data for law enforcement purposes. DHL is a company that provides international courier services, often the delivery of packages. The purpose of KYC apps is the deterrence and prevention of various crimes: If a crime occurs, associated tracking is empowered through reporting of data in apps like the DHL KYC app.

Although it could be said that there are two users in this app, the person making the delivery (the courier) and the person receiving a package from DHL. I was told by the client that my team and I were to focus on improving the UX for just the delivery person.

Impact on Project

As a result of the UX research work conducted, a deeper understanding of the user mindset was uncovered via UX artifacts like a persona and user journey map. As this was an internal business user project, the metric to measure the the impact of the design work was via average speed of completion. Additionally overall satisfaction on a 1-7 scale was also tracked. The client reported a sizable ROI on expenses versus our costs.

Roles

UX Lead
UX Strategist
Assisting the Product Manager

Opportunities

I would say the largest opportunity stems from no shortage of available data. DHL is a huge multinational company with many delivery people who could be used for usability interviews, tests, and surveys. It would also be easy to have contrasting data for activities such as A/B testing, as DHL has different groups within India based on various states, and is located in many countries outside of India as well.

Challenges

A completely new culture to study and learn from. While exciting and interesting, learning Indian culture would also prove to be a challenge as I wanted a holistic approach and focus on human-centered design in developing the app. Luckily, my team was a majority India based and proved to be great resources about learning Indian culture. To further overcome any possible geographical and cultural challenges, I relocated to India and learned to speak Hindi (the national language of India).

Upon relocating to India, I learned that the existing app, which was previously available only in English, was a nuisance to couriers who often did not speak English.

From a project perspective, scalability was our initial concern as the changes would be rolled to out thousands of delivery people.

Fragmentation was also a concern. The existing DHL app was available only on Android devices and DHL couriers often used their own phones. This creates a design that needed to be effective across almost every kind of screen size, and lightweight enough that even a low-end smartphone could run it.

Project Management Plan

Initial Steps

This is a mindmap, you can click it and any image in this portfolio to expand it. A mindmap take a big concept and breaks it down into its component parts. This is a mindmap of the initial steps, created for my usage during the project. Below is an explanation of what the mindmap shows:

For design team timelines, please see "Design Team Strategy & Execution" below.
Recruit core team members off the bench, such as a development team lead, Database administrator, Quality Assurance Lead, Visual Design Team Lead, and a senior Business Analyst. I had a dual function as the UX team lead/UX strategist and as the overall Product Manager.
The design team was organized by seniority, and by identifying visual vs UX designers. The design team consisted of 3 senior designers at this stage, but I started shortlisting for a total team of 10 designers in the next stage.
The development team was divided into front end developers (with expertise into C#, HTML, CSS Javascript, Java) , middleware (mostly coded in Java), and backend (MySQL initial but later migrated to Oracle 11g).
The software testing was expected to be mostly manual in this project. Although automated testing was evaluated, it was thought to be unnecessary at this stage.
Establish systems thinking approach
Apply Agile & Waterfall model mix
Apply collective knowledge and Systems Thinking strategy to determine of the project is needed and what are the questions that we want to ask.
Create team communication structure to be flat initially and scalable in the long term
Create clear roles and responsibilities for leadership team
Create initial risk management plan
Create initial tentative timelines and tentative sprint plans

Design Team Strategy & Execution

Stakeholder Interviews
Hypothesize problem statement
Secondary market research & competitor research
Conduct social surveys
Conduct usability interviews
Refine problem statement based on data
Usability testing of existing application
Document current Information Architecture (IA)
Define Critical Flow
Create a User Persona
Create a Journey Map
Heuristic Evaluation
Heuristic Frequency Breakdown
Lessons learned, including pain points and opportunities
Document Future IA
Create paper prototypes with cutouts
Usability test paper prototypes
Create mid-high level fidelity prototypes
Usability test mid-high level fidelity prototypes
UX Specifications Document/Style Guide
Handover to development team along with knowledge transfer
Hypothesize opportunities for future iterations

Introduction

"I need to collect customer information quickly so that I can meet my next delivery deadline."
- Sandeep Singh (Experienced driver)

About Sandeep

Sandeep grew up in a village outside Mumbai. His first language was Marathi and learned Hindi in school. Sandeep learned English in late teens. He loves to play basketball and watch WWF.

Primary Roles

Primary Task: Delivery of packages
Secondary Task: Collection of customer information

Known Challenges

English is not Sandeep's first language. Although he is somewhat familiar with it, he reads it slowly and with discomfort.
New to touchscreen phones

Pain Points & Frustrations

Correlating AWB numbers (the barcodes on packages) with customer information manually is time consuming and costly
All work is done by hand
Customers lack trust in the authority and capability of the courier

Sandeep's Needs

Reduce time spent by courier collecting documents from customers
Help courier keep documents organised
App must work in all conditions encountered by couriers

User Persona (DHL Courier Driver)

This research was produced by doing a series of qualitative user interviews. This was early in my career so no other research was done. Of course this data is better supported by quantitative research data like clustering from surveys which could then be followed by qualitative user interviews based off of contextual inquiry. For persona research (assuming resources are available) multistage quota sampling could be an approach.

As with almost any Journey Map, the purpose is to document and understand how Sandeep goes through the app, as per the current process flow (given early), user research, and testing. Although Sandeep Singh is not a real person, we try to put ourselves in his shoes and understand how he feels and what his actions are as he goes through the app. This is a key mechanism to understand and meet his needs. Red text indicates User Pain Points, which are needed areas of improvement.

Initial State Journey Map

Overview of the User Journey Map

The Journey Map covers the points mentioned in the basic process flow, so in turn, this is a simple journey map. This leaves open for more comprehensive journey maps for more complex process flows in future iterations.
Red text throughout the Journey Map indicated problems and/or pain points. The amount of red text indicates the amount of work that needs to be done in this coming iteration of the design revision. It also, in this case, indicates Sandeep's pain and frustration as he goes through the app. The idea is to get other participants of the project to understand and empathize with Sandeep, so that we, as User Experience Designers, can be user advocates. The next phase, the Heuristics Inspection, will further indicate more work that will need to be completed. Both the Journey Map and Heuristics Inspection are intended to scope out the work and then prioritize the pending tasks.
Based on the red text, in some cases, the actions will be changed. Based on the red text, we will try to change the flow, design, and overall user experience to reduce the pain points.

Heuristics Evaluation

A heuristics evaluation is conducted so that a logical approach with UX design factors can be applied. Errors or points of change are noted and marked on each page as per their location. This is necessary for future heuristics frequency analysis. In this case study, we used a 9-point heuristic analysis (taken and slightly modified from the Nielsen Norman Group) which is common in UX and applicable to the design. In the first instance, an example is given of the kind of points we considered when going through the case study.

Not all the factors will be used on every page because not all of them apply but these are the factors that will be considered throughout the case study:

Users & Their Goals
Flexibility & Efficiency
Recognition Rather than Recall
Error Prevention
Help Users Recover From Their Errors
User Control & Freedom
Visibility of System Status
Consistency & Standards
Help & Documentation

Main Menu Screen of DHL KYC App

This case study was easier to evaluate than the other case studies included in this portfolio because there are only two screens. However, this main menu screen is full of heuristic errors: so many that they had to be crammed into the left-side margin of the app wireframe. The purpose of the screen seemed to be so that Sandeep could get everything done in one place, but we were asking ourselves is that really what we want for Sandeep, who is new to smartphones and not so comfortable with English? This becomes a key point for the redesign which will be addressed later in the case study.

The other point to be noted with the screen is the "AWB" button. Sandeep knows what the AWB is because he has been trained on it. The "AWB" is an acronym that stands for Airway Bill Number, which is, for our purposes, simply a barcode. This AWB button leads to a screen where the AWB button is scanned. That's the next screen covered in this analysis.

As with the other case studies included in this portfolio, an example of the detail and logic involved in the heuristics analysis is given in the margin on the left-hand side of this screen.

"Flexibility & Efficiency", "Recognition Rather Than Recall", and "Help & Documentation" are the points that encountered the most errors, and the lessons from those will be carried over into the next iteration of the design.

Most pressing from these would be a design where buttons are consistent and where Sandeep does not have too much to deal with on one screen. Furthermore, lessons were learned from the User Persona and Journey Map, where we learned that Sandeep is not very comfortable with technology or English. Therefore a good redesign should take into account these factors about the user to reduce his pain points. For this, we decided to increase the number of screens that information is given on, in effect reducing the amount of information that Sandeep has to deal with on any one screen.

Furthermore, we added an option for a "Settings" screen, the purpose of which would be to allow Sandeep to choose a language most comfortable to him. That way, Sandeep can better scan rather than read, which is the way that most users interact with mobile apps.

Lessons Learned

Strategic Pivot

I lead the team into accounting for Usability Research, specifically the usability interviews. User interviews (We did 5 in total) had shown that the user wanted an app that gave him more control over the process. This is because he wanted to project more authority to customers when collecting their information. His becoming an authority figure in the eyes of the customers would allow him to collect the information much faster. The purpose of the project was to enhance Sandeep's User Experience, but obviously, that should not come at the risk of DHL's customers having a bad user experience down the line.

I decided that the most benign way for the team (after some healthy internal debate) to project Sandeep as an authority figure would be to redesign the app so that it had a step by step process. A step-by-step process would allow everything to happen formulaically over time so that given enough experience, Sandeep would get to learn the process by rote. This would give him more confidence in his customer interactions.

It would also give the option to Sandeep to choose his language, which would make more comfortable and less anxious, thus projecting more confidence, and therefore more authority.

I decided to loop in the visual designers and technical teams a little early as this was a significant change in plan. I wanted to make sure that if we did large changes, the development team would have the capability to execute them. I updated JIRA accordingly and had a few in-person scrum meetings as well as an open card sort to reinforce this approach.

New Journey Map

This is the Journey Map that the user went through when encountering the future process flow (given above). As before, the Journey Map takes account Sandeep's emotions, thoughts, feelings, and actions and from them draw key points at each stage in the process flow.

In this case, we conducted Usability Testing, Usability Interviews. My direct reports went through post-development reviews and feedback via emails. All of this substantiated the Journey Map below.

Overview of Journey Map

Pain points have been reduced by 80% by targeting lessons learned from the top 3 heuristics and applying the previous Journey Map.
Sandeep doesn't have to think.
Sandeep's stress is reduced.
Sandeep is able to focus on what he is doing without the layout getting in his way.
The DHL KYC App has been simplified so that two screens with a lot of information on each have been broken down into a step by step form with one task to accomplish on each screen.

What Is It?

We created an mid-high level Invision prototype. A clickable interactive prototype is used for:

End Users for Usability Testing. The degree of user testing possible varies based on the fidelity of the prototype. In this case, we have a medium to high-level fidelity prototype,
Designers to collaborate regarding designs, on the cloud, and (in the case Invision and some other prototype tools) simultaneously.
Helps developers to understand the functionality and capabilities of the app to create the logic to make the design usable.

What Did We Do?

Uploaded screens that we created via Sketch to Invision
Created hotspots so that screens would be interactive

Impact Summary

Ability to have a hands-on view of the app and functionality
Simple user testing capabilities without investing a costly and time consuming developer-created PoC.
Business users will understand how the app will generally function and get an idea of the look and feel of the app.

View Prototype

Interactive Prototype

Table of Contents