Know Your Customer (KYC) for DHL

Table of Contents

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.
Back to Top
  • UX Lead
  • UX Strategist
  • Assisting the Product Manager
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.

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
  1. Stakeholder Interviews
  2. Hypothesize problem statement
  3. Secondary market research & competitor research
  4. Conduct social surveys
  5. Conduct usability interviews
  6. Refine problem statement based on data
  7. Usability testing of existing application
  8. Document current Information Architecture (IA)
  9. Define Critical Flow
  10. Create a User Persona
  11. Create a Journey Map
  12. Heuristic Evaluation
  13. Heuristic Frequency Breakdown
  14. Lessons learned, including pain points and opportunities
  15. Document Future IA
  16. Create paper prototypes with cutouts
  17. Usability test paper prototypes
  18. Create mid-high level fidelity prototypes
  19. Usability test mid-high level fidelity prototypes
  20. UX Specifications Document/Style Guide
  21. Handover to development team along with knowledge transfer
  22. Hypothesize opportunities for future iterations
Back to Top
UX Research Strategy
This is an overview of how the main user (the courier) will go through the app. The courier is later named "Sandeep" in the User Persona. This combined flowchart + sitemap helped me understand the relationship between the different functions of the app.
Current Information Architecture
Back to Top
"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.
Back to Top
The Happy Path
The goals of this process flow are to:
  • Show the flow of the app as it is now
  • Take a viewer through the app in the simplest way possible while still accomplish Sandeep's needs.
  • Lay the groundwork for the Sandeep's Journey Map
Back to Top
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.
Back to Top
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:
  1. Users & Their Goals
  2. Flexibility & Efficiency
  3. Recognition Rather than Recall
  4. Error Prevention
  5. Help Users Recover From Their Errors
  6. User Control & Freedom
  7. Visibility of System Status
  8. Consistency & Standards
  9. 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.
AWB Screen
This is another screen that has a greater total of errors than the number of elements included on the screen (just like the first one given above). My direct reports questioned the strategic reasoning for having this screen in two steps, because of error prevention being given a high priority than anything else. Below a second button to get to the point where Sandeep can scan the AWB number, there is an option for Sandeep to enter the AWB number manually. The point of Sandeep entering the number manually is in case the scan fails. However, there is no way for Sandeep to know if the AWB scan will fail or not on this screen.

The above point, in addition to the heuristic evaluation, as well as a large number of errors on the last screen, lead us to decide on a restart from scratch of the two screens.
Heuristic Frequency Analysis

The purpose is of this table is to count and the total errors. Errors are counted across each of the screens encountered in the case study and ordered according to their frequency. The severity of the errors is determined and prioritized. As a majority of the errors encountered are usually the top 2 or 3 heuristics factors, those are the ones we will focus on learning from and fixing in this iteration of the design.
Back to Top
"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
Back to Top
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.
Back to Top
Updated Happy
Goals of New Process Flow
  • Take the user from point a to Z in the app
  • Accomplish the simplest but most important task
  • Start the process of fixing at least 80% of the pain points mentioned in the initial journey map
UX Research Findings
  • Sandeep does not have to log in
  • Sandeep's courier training has been completed
  • Sandeep has internet connectivity
Back to Top
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.
Back to Top
Style Guide
The handover of the design process to other elements of the business begins (such as the developers) with this document. The UX Specifications Document is supposed to thoroughly examine all elements of the UX Design from a developer context. The purpose of this is to have a reference guide for developers to refer to. It also creates better communication and shows all the different elements involved in the design in one place.
Overview of the UX Specifications Document
  • Detailed forms with redlines are given, including completed, incomplete, and empty text forms
  • Button redlines are given
  • Iconography is mentioned
  • Primary navigation documented
Back to Top
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
Back to Top
Next Iteration(s)
Future UX Research
  • Card sorts could be conducted to find the IA. Whatever results would be given from these could be confirmed with a Tree Tests. I would normally do these in Optimal Workshop.
  • A mobile app version of the website could be created.
  • Additional personas could be added, with associated journey maps for those personas.
  • The IA & general functions of the application could be added to. Additional features could be determined by a UX research study surveying the existing users.
Future Design
  • A design system could be created that would allow for multiple designers to work on this more easily.
  • A style guide could be created for the same reason.
Back to Top