Design in Security

Jane Saputra at UXDX EMEA. Video: https://youtu.be/rVo8wJFZaz0

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

When easy isn't always good

[00:00:02] As young designers, we were often told that the best designs are the ones that are easy to use. Ones that do not require our users to think, if possible, at all, and are usually completed with just one click or maybe less. And while that's not entirely wrong, today I wanted to talk to you about how easy designs aren't always a good thing, and how sometimes adding a bit of friction to your designs and user journeys can be very beneficial. And really, it's not just for the users; it's also beneficial for the business.

[00:00:41] My name is Jane Haezer [?] Saputra and I'm a Product Design Lead for HSBC. I started my career as an information architect in design agencies in Canada, before joining a startup in Indonesia, and now I'm in London. At HSBC, I lead the security and anti-fraud platform.

[00:01:03] Believe it or not, the sole reason for the existence of the product I'm working with right now, which is a security and anti-fraud platform, is actually to create friction in the design. Over the last years that I've worked closely with it, it has changed a lot of the way I think. It made me question a lot of things that I learned as a designer, and it showed me a very different side of the design coin. Today I wanted to share with you what I have learned so far, and how I've realized that adding that bit of friction can actually be very beneficial, despite what we have been taught.

Lesson one: friction can equal security

[00:01:46] So what is friction, and how does it affect design? And is it really all that bad? Think of your house, or more specifically, think of your front door. Your front door acts as a barrier against the outside world, really. To enter your house, you have to take an additional step or steps. You need to turn the key. You need to open the door and get out. You close the door, and for extra security, jiggle the door handle, making sure that the key works, or that you don't forget to actually lock the door. We all have our own rituals, and it takes a bit of time to do all these rituals every single time you go in and out of your house. But I can still assume that every one of us would prefer having a front door rather than not.

[00:02:44] This really brings me to lesson number one, which is that adding friction can be equal to security. Think of your bank account, and your login page as your front door. Adding a login as part of your user journey is, technically speaking, friction. It adds an extra step before you can see your bank account balances, or any account really. Sometimes it takes a little bit of time to get this step right. Maybe you entered a wrong character in the login details, or in my case, forgot my password, all the time. But overall, no one would not want a login step for their bank account.

[00:03:27] Having this added step, or friction, strengthens the feeling of security for your users. What it does is ensure that nobody else would be able to access their accounts, and strong login protections also increase your users' trust in the product, in my case the bank. Ultimately, I think that can only be a good thing.

Lesson two: friction to make users stop and think

[00:03:44] That brings us to lesson number two that I've learned so far, which is to add friction to make users stop and think. Especially when one is working in the banking industry, sometimes we want our users to actually stop and think before they give their consent. This is, I think, where friction can really help. For example, take money transfer situations. If we follow the thought process that no friction is always best for users, it might go like this: users select who they want to send to from their bank account, and then they enter the amount of money to be transferred. Then they press send and voila, it's all done. Except they just accidentally pressed an extra zero and sent 400 pounds instead of 40 pounds.

[00:04:47] Friction in this case could be an added confirmation screen that lets users review and consent to all the information that they have input, making sure that everything is correct before they send it over to the bank. It can save users from accidentally entering an incorrect amount or sending money to the wrong person. And for the company, it actually saves a call to the customer center.

An extra screen that halved login time

[00:05:17] One of the projects we worked on last year, I think, best describes how having friction isn't always a bad thing, and can be a really great thing. We noticed that one of our login pages wasn't performing well in the analytics. There was a larger drop-off than we expected, and users took a long time to go through the journey itself, which is not a good thing.

[00:05:50] So the design and product team huddled to figure out what the potential issues could be. We scrutinized the design, and then we realized that our initial approach of providing users with a way to log in right away might actually be the problem. It's really mind-blowing: a smooth login is a problem. That was definitely a surprise. This is because the so-called login page didn't just contain the login. It also included other items unrelated to the login steps, and other users might actually come to these screens to do those tasks. The original designs, as you can see here, emphasized login activity, and we suspected that the drop-off happened because of cases where users weren't actually trying to log on.

[00:06:40] Based on this hypothesis, we created an extra screen. You can think of it as an additional step, really, and this screen allows users to easily see all the available functions at a glance. It does not give too much dominance to one or the other.

[00:06:59] As expected, there were concerns with this approach, because it is one extra screen. Users have to click one more time before they can actually log in. So how is this even solving the user problem, the problem where they're taking a long time to log in? And how is this helping with drop-offs if they are given another friction? So we conducted user testing in several different countries to make sure that this was the solution, the answer that we wanted to go with. We also tested it against all the tasks that users coming to this page want to do, to make sure we got a rounded view. And to our surprise, the results were very promising.

[00:07:44] We brought the results to the rest of the stakeholders, and after a couple of discussions, it was decided to launch the new login page in several markets. As everyone knows, it does take a couple of months for analytics data to stabilize, especially if you're releasing on a mobile app. So we huddled back as a group to look at the data after three months, and really to our surprise, we found out that the time to log on had been slashed by 50% compared to the previous design. We also found out that drop-offs had gone down by 10%. So the solution really does work. To this day, it's really mind-boggling to see the addition of an extra screen make users go through their tasks much more efficiently.

The degree of friction matters

[00:08:38] Even though we now know that friction is inherently important, I think it is also important to note that the degree of the friction itself matters. As part of security, our designs usually involve extra steps to ask users many questions and provide them with lots of information. Just to remind you, this is the friction we need to ensure that you are who you say you are, and nobody's trying to impersonate you and do bad things. If you ever opened a bank account or asked for a mortgage, for example, I think you'll be very familiar with it. And of course, our initial experience looked something like this.

[00:09:23] The questions go on and on, and to no one's surprise, lots of drop-offs happened here. We went back into our analytics to see where the drops happened. Then we had a chat with users who actually dropped off, and talked with the frontline agents who ended up having to help these users, to see where the problems actually lay. We found out that the issue lay in our users not having the information needed handy, and feeling overwhelmed by these important-looking procedures.

[00:09:59] It is honestly comical to get these responses from users when we actually designed this experience to need the least clicks, by providing only one page. During rounds of brainstorming and idea generation, someone said this oldie-but-goodie quote by Creighton Abrams: "When eating an elephant, take one bite at a time." I think it perfectly summed up our situation here. We were trying to make users digest mountains of information in one go. Maybe what we needed to do was actually cut it into bite-sized pieces for them.

[00:10:43] The concern that came then, and honestly a very justified one, was: won't users get anxious because they cannot see where the end is? Because what we're basically trying to do is cut up mountains of information on one page into multiple different pages. So we designed against that as well. The end design goes something like this. First, it provides users with clear steps of what they're going to go through, and then it breaks the information that they need to digest into various smaller pieces. And last but not least, it indicates where they are in the process and encourages them to continue.

[00:11:28] As always, we tested the solution first to see if it generated any red flags and concerns from users, and when it didn't, we released it into the wild. Honestly, the results could not be better. While it doesn't necessarily speed up the process, it does bring down our drop-offs and increase the completion rate, which I think is the bottom line. These two designs, the wall of questions and the bite-size questions, actually deliver the same number of questions, yet the receptions are very different.

When to use friction

[00:12:04] So what have we learned? That friction is not the enemy, but a tool. And just like any other tool in our design arsenal, there needs to be a balance in its application. After all, we've learned that too much friction is also not a good thing. So how do we really balance it? When should we use friction, and how can we use this tool at its best? So far in my experience, I've seen it best used in three circumstances: circumstances that require privacy and security, consent, or any irreversible situations.

[00:12:48] In privacy and security, friction is added to keep customers and products safe. It is there to safeguard not just information or assets belonging to customers, but also to maintain customers' trust in the product and company, like our front door analogy, basically. Friction can appear in different ways, such as warning messages, or maybe a reminder about fraud asking users if they really know the person they're sending money to, for example: is this your friend?

[00:13:26] In consent, friction is added to inform users that the product needs to use something of theirs to function. Consent is not only ethical; it also shows goodwill from products to our users. An example of consent could be permission to use the microphone, location, camera, or maybe a terms and conditions agreement.

[00:13:49] And lastly, the most common time I've seen friction used day to day is during irreversible situations, such as a checkout confirmation screen, or a warning message before you leave a page, for example. Its purpose is basically to inform users that this is the end of a journey they're going through, and that changing anything at this point might not be possible. So if they want to proceed, they should only proceed if they are sure.

[00:14:25] The strength of friction used should then also be adjusted depending on needs. One of the best ways to know how much friction is needed, and in what form it should appear, is by understanding the issue one is trying to solve, really. And then, of course, combining that with validation of solutions with actual users, and monitoring the results through qualitative and quantitative data, is always helpful.

[00:14:52] But if there is only one takeaway from this talk, please let it be this: friction does not have to be frustrating. Used in the right way, friction can be your friend in helping users use your product. Thank you for listening. I hope this sharing can be of use in your design journey.