The first experience people have with your mobile app is the most critical. If they cannot get it working right away, they won’t finish setting it up and won’t come back.
As UX professionals, we often talk about problems with app tours, pound our fists and say “no splash screens,” or discuss the overall onboarding experience. However, there’s still far too little information available about even the basics of designing for security.
Some of the most visible aspects of app security—and those that are most badly done—are registration and sign-on screens. So, in this column, I am going to discuss how to create registration, sign-on, and other related security functions of mobile apps.
Champion Advertisement
Continue Reading…
Why focus just on mobile apps? Because apps are different from Web sites, and a lot of what makes mobile apps bad involves using outmoded, Web-centric design concepts and widgets—especially for security features. Instead, we need to design mobile apps to take advantage of the unique features and expectations users have of these apps.
Because new platforms such as wearables, ambient home devices, and smart TVs are so new, some modes of interacting with them are still less well defined. However, these are generally app-driven or app-like experiences as well. Therefore, designing them from an app-centric baseline—rather than, for example, assuming that a thermostat should behave like a Web site—results in much better experiences.
Naming the Task
A company’s security practices are largely invisible to users, work in the background, and rely on faith and trust. So, when you do make these parts of a system visible, it is important that you communicate clearly what is happening so users trust your system and provide the information both the system and they require.
Communicate clearly with users by using simple, unambiguous wording. Rely on research rather than people’s personal preferences in choosing this terminology. Research has shown that the best-performing terms are, in order of preference:
Sign On / Sign Off
Sign In / Sign Out
A distant third is Log In/On or Out/Off. If you were to use any of these, it wouldn’t matter whether you used Log In, Log On, or any other variation because all of these options work poorly. So avoid using them despite their being the most common terms in technical circles.
Most important, always use parallel terms: In/Out or On/Off.
Use an entirely different word for account registration such as Register or Create Account. People might misread Sign Up as Sign On. However, don’t make terminology choices based only on your app. Remember, people have other app experiences and do not perceive your app in isolation. Of course, make sure that the terms you choose are not confusing and accurately reflect the specific situation. For example, don’t use Register if that might cause confusion with some other action such as registering for events, and don’t use Create Account if the user already has an account and is just setting up mobile access.
Whatever terminology you settle on, use the same terms all the time—both when labeling the function and in descriptive text, page and dialog box titles, and button labels. Don’t get creative and use various terms or synonyms because consistency seems boring and repetitive. In this case, repetition is a good thing because it ensures that users understand a term refers to the same action or function.
Don’t use vague or general terms such as Submit for button labels. Actually, never use Submit as a button label. Instead, use a specific label such as Sign On—again, to make sure users understand what will happen when they click a button.
Registering Accounts
If your app includes account creation, it is time to admit that you’re not just providing an app, you’re providing a service, and one way of interacting with your service is through a mobile app. You need to handle users’ credentials from that perspective.
But if you’re really providing just an app that doesn’t do much and doesn’t send or gather data, why would you make users sign up for a service at all? To receive payment? You can solve that problem in much easier ways—for example, with validation codes. Don’t use a complex account-creation process just to allow payment. Don’t confuse payment validation with actual security tasks.
Registration must be as quick and easy as possible. Especially if many of your users must register on their mobile device, after downloading the app, and registration is part of the onboarding process, the more steps in the process, the less likely they are to use it at all.
Figure out what data is really necessary to create an account that works for users. Don’t add more fields just because the company wants to gather more information. Remind everyone in the business that what you need most is more users. You can always ask for additional information later, by applying lazy-registration principles and requesting users to add more information to their profile.
Tumblr is a good example of the most extreme way of providing access—immediately gathering data about users’ basic interests and showing them how cool the app can be. Only if users try to post items themselves do they have to create a Tumblr account.
Creating Passwords
The best way of dealing with passwords for mobile apps is not to have them at all. Users do not want to have to sign into mobile apps every time they use them. If people don’t use a password every day, there’s a good chance they’ll forget it and need to recover their password by getting a new code via SMS.
So, why not have only a username and recovery methods? This is a tactic you can actually use in place of username and password creation. As shown in Figure 1, the Square Cash app just asks for the user’s phone number, then sends an SMS with an activation code, and the user provides the code and is in. Depending on the phone, network operator, and user permissions, the app may be able to read the code automatically, so the user doesn’t even have to type it in.
Figure 1—Square Cash phone and code-entry screens
However, phone-level security does not allow a mobile app to automatically retrieve the number of the phone on which it is installed.
If you must create a password for your mobile app, there is very good data on actual security risks and human-factors failings. Here is a short list of things to do and to avoid:
Provide a single field for entering the password. Do not require dual entry.
Do not mask the data in the Password field. Let users see what they are typing. Shoulder surfing—that is, people stealing information by looking over the user’s shoulder—doesn’t really exist with phones.
If either you’ll demo an app, allowing everyone to see the screen, or corporate security won’t listen to reason and insists on masking password data, add a function that lets users toggle between hiding and showing their input. But try to leave masking off by default.
Do not define a maximum length for passwords.
Avoid complex password rules. Follow the NIST guidelines for what characters are allowed in passwords.
Naming Fields
You may also want the user to establish a username, but be sure that this is really necessary and label the field properly. For example, if you don’t need to use the username within the app, but just want it for security or account-management purposes, label the field for the data it contains: Phone number, Email address, or whatever.
You will immediately see how much simpler this makes your design because you don’t need to explain in hint text that the Username field is actually an email address.
Do not call a numeric pin or other code a password. Passwords may or may not be words. But passcodes cannot ever be words.
As Figure 2 shows, Tumblr does an excellent job of labeling the fields that let the user create an account. Email and Username are clearly different. Plus, the page title What should we call you? makes it clear that the point of account creation is to give the user a unique presence in their ecosystem.
Figure 2—Tumblr profile account screen
Registering Devices
When users open any mobile app for the first time, they sign on. But do they really?
From here on, I’ll be talking about how mobile apps differ from Web sites. Signing onto an app is one of those differences. One of the key values of mobile apps is that they retain user information. The user just taps the app’s icon and can use the app immediately.
Users do not sign onto mobile apps. Signing on is a session-based activity. Instead, users register their account for the app instance. Okay, that would be a mouthful, so you can keep labeling the screen Sign On, but make sure that you specify and build the system to be app-instance registration instead.
Even if a username and password pair exists for the service—probably because you have a Web site—that doesn’t mean you have to use it in your mobile app. The other day, I set up the Dish Anywhere app on an iPad so my toddler could keep watching a TV show as he went to sleep. Instead of asking me enter a password, Dish had me go to the TV, where a PIN had popped up on the screen.
This is similar to sending an SMS message, but used their satellite network as a secure delivery mechanism. Clever—and just one of many ideas to make things simple and quick for users.
If you do end up having to make the user type a password, empower the use of keychain apps, and do not block data entry by pasting into Password fields.
Signing onto App Sessions
So you may ask: How do users sign onto an app session? They don’t. Okay, they might, but session-level security is very rarely necessary. People keep their phones secure, so there’s no reason to make users sign onto a session just for your app. Ask for passwords or other secure validation only in the following cases:
if a user’s account information has changed
if a user’s credentials have expired
to satisfy another need such as identifying users in a multiworker environment, where someone may not personally own a mobile device
if you work for a bank—or someone who won’t listen to reason and just wants more steps to make the process harder
Don’t allow your product team to claim that the service needs the user’s username and password at the beginning of every session for security reasons. That just means they don’t know why they want the information and are operating out of fear instead of gathering good data. The end result of complying with this demand would be that you’d just build in a way to ensure that people don’t use your app. Or at best, they’d just cheat and keep their phone from locking to prevent their having to sign on again.
If your app allows access to truly secure information, the best solution is actually to require users to lock their phone. Your app manifest could require the user to set this up before the app installs or runs. Then, you’d get full security without having to build an access-control system. Plus, remember that, because an app is not a Web site, locally stored or downloaded files may be at greater risk. Whole-device locking is much safer in such cases.
Mobile-Friendly Signons
However, if you simply must have session-level security within your app, try to approach this as we did password-field masking. Don’t turn it on by default, but allow users to enable extra security if they feel they need it. Sometimes, this feature can be a valuable differentiator, and you can sell your having a secure app. But it’s important that security not get in the way of usability, so use mobile-friendly security methods such as a short PIN, a pattern, or biometrics.
The Telegram messaging app shown in Figure 3 does this very well. It does not default to a sign-on screen every time, but lets the user set up a PIN or fingerprint, set the time until auto lock occurs, and quickly lock the app with a single button push when the user next backgrounds it.
Figure 3—Telegram security settings and biometrics unlock screen
Web Registration? Web Signon? Absolutely!
Any time people use an online system to create or modify their account information or to sign on, a very valid way of doing this is with a Web-based system.
However, make sure that you design these Web pages to integrate well with the app framework. Many third-party systems do not allow much customization or claim they won’t work as WebViews for vague security reasons. The end result is either poor emulations of native apps or users’ having to go to a Web site that is branded for some other service.
As UX designers, it is our job to fight such outcomes. Security is more than a technical solution. As for any other part of a product, users matter. If you get people used to giving their credentials to any old Web site, bad things will happen. If you have security-conscious users, they may refuse to sign onto the app because it may appear that an attack is taking place.
As a customer, I have myself caused trouble multiple times by refusing to give information to accounts-payable departments, banks, rental-car companies, and others. Companies may have a terribly designed system, merge, or change their name, or actually use a third-party system for processing without saying so.
Account, Profile, and Settings
It is important that UX designers have a clear understanding of the differences between accounts, profiles, subscriptions, and the personal data that is associated with each of these. But you’ll probably need to figure out how to automate and obscure as many of these layers and relationships as possible.
I’ve worked on a lot of complex systems, and most users neither care about nor understand the difference between an account and a user profile. Just as you should not confuse the terms sign on and registration, be sure to use the right words in a user interface for each tier. However, do not require users to understand these distinctions to sign on or change their preferences.
Registration and profile data should never ever exist only on a phone. Be sure to synchronize any information about users and their preferences, and use it to create a cloud-based user profile.
When Pebble was the king of smart watches, I used their app a lot. Because I switch phones often, I had to install the app many times. Every time I did this, the app asked for my region, my height and weight, and other data that, while necessary for a good experience, had not changed. An app should not ask for such data at each installation.
Don’t burden users by having them back up and restore their data. Instead, automatically sync any changes with the profile on your server. Then, automatically load existing settings and data to any new installations of the app on other phones.
Signoffs
Around 1989, I was trying to do something at the University of Kansas computer center. I was one of the rare people who actually had a computer in my room, but I needed access to something else—no, I don’t recall what. Anyway, it wasn’t working, so I went to stand in line at the help counter. Yup, the help desk was an actual desk with a person behind it back then.
When it was my turn, the support guy refused to talk to me until I put a sleeve on my 3.5-inch floppy disk—the one with the sliding door, so it was totally safe to have it out in the open.
These guys also stuck signs on every computer and every wall, imploring everyone to complete various other mindless tasks. One was to be sure to log off when finished working. Otherwise, dire things would supposedly happen. But even back in the ‘80s, no one did this.
Technical staff are the only people who even think about logging off systems. But we end up with requirements for signoff on every single system we design. We should be designing for people, not systems. Since people rarely use signoff on the Web and it simply doesn’t make sense for mobile apps, let’s think harder before defining requirements for signoff.
On the Web
In the old days—starting long before the Web—logging off a session was actually important because shared systems allocated resources poorly. If you created a session, then just walked away, the session would persist, so no one else could use those resources. Today, do you know why people encourage signing off your system? Inertia. It was always done that way.
The most recent reasoning advocates affinity-based load balancing and session expiry for server efficiency. But it’s not entirely likely that your Web servers work that way. Plus, that’s not a security-driven function anyway.
In Mobile Apps
Mobile apps are not at all like the Web. If you have configured your app to remember the user’s profile, what would Sign Off even mean? Maybe nothing. Maybe this just confuses the user. However, there are three legitimate things for which your app may need functions to which your product team may be referring when they say, “As the user, I want to have the ability to log off.”
Locking Apps
Requirements often specify Sign Off in the mistaken belief that this capability will automatically improve the security of an app. But people don’t sign off and, as I mentioned earlier, phones have many other security measures that work better. While I have encountered this requirement many times, I have rarely designed such a feature into an app myself. If you must, call the feature Lock App or something similar, and use a session-based PIN or biometrics to unlock the app. When locking the app, don’t cancel the user’s session. Just lock the app in its current state.
Changing Profiles or Accounts
Many services such as YouTube support multiple profiles or accounts, as shown in Figure 4. But they do not require the user to first sign off from one account, then sign onto another. Instead, they allow the user to switch to another profile or account.
Figure 4—Account switch dialog in the YouTube mobile app
Unregistering Accounts
It is possible that users may want to remove their account. Think about the overall context in which this could occur. Often, there is no need to remove an account or profile because users can instead simply remove the app from their phone or clear their app information. If the profile that an app uses is associated with a phone, there is no need for a special unregister function to be built into the app itself. For example, YouTube provides a link at the bottom of the Switch Account dialog, which goes to the phone’s settings screen shown in Figure 5, facilitating account management.
Figure 5—Android Account Settings screen
Perhaps the worst part of the Sign Off function is that product teams and developers think of it merely as a button, so one that they can add at any time.
Designing for Security
Don’t let your product team take any security requirements for granted—as though they are features that they can tack on at any time. Make sure that design for security is deeply considered from the very start of a project. It lies at the heart of the whole product design.
While this article has touched on a large number of issues pertaining to mobile-device security, it really just scratches the surface. For example, I haven’t discussed the pros and cons of single signon versus federated authentication systems or how to account for them in your designs. I’ve just mentioned session expiration in passing and haven’t discussed credential expiration or the appropriate behavior of authentication systems when a phone is disconnected from the network.
As consumers become more accustomed to security risks and come to expect that they own their account information, designing for security behavior and assuring users that their experiences are secure and private will first be a competitive differentiator, then simply table stakes.
Don’t let traditional best practices or old, out-of-the-box defaults or legacy behaviors rule the design of your next mobile app. Instead, design and build apps that satisfy users’ current expectations and needs for security and create great user experiences.
For his entire 15-year design career, Steven has been documenting design process. He started designing for mobile full time in 2007 when he joined Little Springs Design. Steven’s publications include Designing by Drawing: A Practical Guide to Creating Usable Interactive Design, the O’Reilly book Designing Mobile Interfaces, and an extensive Web site providing mobile design resources to support his book. Steven has led projects on security, account management, content distribution, and communications services for numerous products, in domains ranging from construction supplies to hospital record-keeping. His mobile work has included the design of browsers, ereaders, search, Near Field Communication (NFC), mobile banking, data communications, location services, and operating system overlays. Steven spent eight years with the US mobile operator Sprint and has also worked with AT&T, Qualcomm, Samsung, Skyfire, Bitstream, VivoTech, The Weather Channel, Bank Midwest, IGLTA, Lowe’s, and Hallmark Cards. He runs his own interactive design studio at 4ourth Mobile. Read More
