UX Case Study: OTP's in Web
A tale of DBS' E-mail OTP
A one-time password (OTP), also known as a one-time pin or dynamic password, is a password that is valid for only one login session or transaction, on a computer system or other digital device.
OTP’s are all rage among internet apps of all kinds. The most common use of OTP’s is when verifying a transaction using a VISA card online. Some OTP’s are small while some can be ridiculously long for you to remember. OTP has taken a different name and is used for verification by some companies. It is now called “Verification Code” or “Email OTP”.
When a user logs into the DBS banking web-page, the page generates a digital token (email OTP) that is sent to a user’s email address and comes with a subject that says “iBanking Alert”. The email looks like this …
Screenshot of DBS mail
To help safeguard a user’s security, the OTP gets expired after 6 minutes. While this is great, it took me more than a few seconds just to make sense of the fact that the second line of mail contains the actual OTP.
Is this normal? For something that is related to a user’s financial account, is it fair to put the user’s eyesight and intelligence to test?
I strongly believe that a simple redesign might be the solution.
Challenge
Make the readability of Email OTP threads quick. Users should be spending the least amount of time to get the mail context and get what is needed (OTP).
Come up with an acceptance criterion (metric) to measure it.
Benchmarking Research
Fact: Users often leave web pages in 10–20 seconds.
Weibull Distribution Graph
It’s clear from the chart that the first 10 seconds of the page visit are critical for users’ decision to stay or leave. The probability of leaving is very high during these first few seconds. We can take this and apply to emails but unfortunately, emails are far more important to users since they are more personal and you are bound to spend more time on them.
Data: An average user spends 28 percent of their workweek on email, more than 11 hours a week! With the average user sending and receiving 124 work emails every day, or 620 emails every week, users are spending an average of 1.1 minutes on each email.
This means a badly written e-mail can make the experience frustrating for the users even though they might not delete/dismiss it within 10–20seconds. But it will reduce trust and increase frustration.
Guerrilla Usability Testing
Being in Singapore 🇸🇬 , it is easy to find users on the street who use DBS banking apps daily That is because DBS is the №1 banking firm in Singapore.
According to this research, it takes only 5 users to test and find all your user problems. If you have a lot of different tests then 15 users should be enough to find problems on different levels. I went in with 15 users broken down into 3 iterations of the same activity.
Methodology
As part of this research project, I asked 5 Singaporean residents to tell me what they thought of the DBS OTP verification email. For each user the following information was recorded:
A description of the activity
A rating of how important the email was to the users, on a 1–5 scale, 5 being the most important
How the users felt about email
How long it took
Whether the activity was successful
How easy the final design was for the users, on a 1–5 scale, 5 being very easy
Activity Observations & Iterations
Activity Description: A user is trying to log into his DBS/POSB account through the web. For doing this operation, the bank requires you to enter an email OTP. How quickly can the user get the OTP from email and move to the next steps
Importance of email to the user: 4
How users felt about email: 3 out of 5 users felt confused and said they have to concentrate to read it.
The average time took to understand the original email: 17–20 seconds.
Activity Status: Successful.
Ease of Use: 2
Interesting Bit: 3/5 users said that there are way too many numbers to read. Looking at the mail, a user has to process 7 different numbers in this mail. Out of which only 1 or 2 are important.
Using 20 seconds as the benchmark. I decided to go after reducing this time and also the confusion factor.
Iteration 1
During this iteration, I decided to retain most of the information from the email and design a layout that allows you to quickly understand the email’s context and get to the OTP quickly.
Iteration 01 — DBS OTP Mail
By using a difference in font sizes, I displayed the importance of different elements in the email. Also, since the user was expecting to see an email from DBS, I used a big DBS logo at the start to help the user in knowing that he has indeed opened the right email.
To test this email, I used a different set of 5 random users. I asked them the same questions as the first set.
Importance of email to the user: 5 out of 5 users responded saying that the email is of high importance.
How users felt about email: 5
The average time took to understand iteration-1 of the email: 8–12 seconds.
Activity Status: Successful.
Ease of Use: 3
Interesting Bit: 4 out of 5 users felt that the information below the OTP is useless and served no real purpose to them.
Looking at the data above, I decided to go and test out one more iteration. This iteration was based upon reducing the average time to read, and also cutting out the clutter from the email.
Iteration 2
Iteration 02 — DBS OTP Mail
Importance of email to the user: 5 out of 5 users responded saying that the email is of high importance.
How users felt about email: 5
The average time took to understand iteration-2 of the email: 4–6 seconds.
Activity Status: Successful
Ease of Use: 4
Interesting Bit: 4 out of 5 users felt that this activity was too easy.
Iteration Comparison
iBanking Alert — Email Design Comparison(s)
From the above comparison, it is clear that the third email provides a better flow of information to the user. Banking, in general, is a very frustrating task for most users and something that is done out of necessity. FinTech companies nowadays are heavily investing in design so that it is less time consuming for the users to find value in their services. It is time for these companies to also invest in smaller user interactions like these rather than just the main/big ones (websites/apps).
And DBS already has the moto — Live More. Bank Less.