Lacey_6dim_00 From Usability Matters by Matt Lacey

This article discusses different ways data is entered into an app and how you can use this to improve your UX design.

Save 37% on Usability Matters. Just enter code intomobux into the discount code box at checkout at manning.com.

  • The underlying principles behind good form design
  • Alternatives to typed entry
  • Optimizing form entry
  • Performing validation and reporting errors

Focusing on how people make contact with the screen is a small part of handling input. For a simple app that shows a list of items and allows you to tap one to view more information, it’s sufficient to only use intent and basic touch events to give a person value. The usefulness of such apps is dwindling and you’ll need to do more with your apps going forward. Ensuring that users don’t get lost in your app is an important consideration for how you construct the interface as well. Having the common UX design mistakes (click here for more information) in mind when thinking about usability will improve your chances of making an enjoyable app to us.

Your apps will need the person using it to provide more complex and different types of input to enable them to obtain the desired value. Whether filling in forms, typing messages, or altering settings, capturing data is easy. Doing it in an intuitive way that’s easy for every person who uses your app understands takes more work. A great, intuitive experience requires you to execute the basics perfectly, and then add sophisticated refinement. Doing nothing but the basics is unlikely to be enough to make your app remarkable. If you go beyond the triviality of what’s required and find the balance of adding a level of smart logic to the app, without making it seem too clever, you’ll create an app which is both easy and effortless to use.

To help you create such an app, this article covers:

  • Understanding the goals of the person using the app.
  • Tailoring forms within the app to aid intuitiveness and ease of use.

The goals of the person using the app

In the diagram below you see the interaction of a person using the app. The actions start with the person, their expression of intent, and the provision of other input to the app. The end goal of the person is to receive value. Having them provide input, and any work performed by the app, stands between the person and that value. You’ve the power to reduce both.

lacey_how-is-data_01

Figure 1 Many forms of input are given to the app, but the aim is to provide value to the person using the app.

The primary goal of the person using your app is to obtain value. Whether this is finding out the latest news, listening to music, making a purchase, or being entertained, the primary goal of your app is to meet this desire.

Beyond the primary goal, your app, and the people using it, will have many secondary goals. My primary goal using a social network app is to keep up with what friends and family are doing. My secondary goals include responding to what they’re sharing, sharing my own updates, and gaining an awareness of relevant wider news. When using a music and podcasting app my primary goal is to receive entertainment and information. My secondary goals include the ability to record and track what I’ve listened to, and to share and comment on what I’m hearing. Secondary goals vary based on who, where, and when the app is used and the device it’s used on, but one of the goals everybody using the app has is that the app be as easy and quick to use as possible. This may seem obvious to you, but it’s a goal that often goes unstated. Because people rarely verbalize their desire for this goal many apps overlook it, and this provides an opportunity for you to set your app apart.

Jef Raskin worked at Apple and was a key part of the team that developed the Macintosh. He’d strong views about software, and in his book The Humane Interface (Addison Wesley, 2000) he defined two rules of interface design. His first rule, clearly inspired by Asimov’s first law of robotics, but it’s the second law I’ll focus on now.

Raskin’s rules of interface design

  1. A computer shall not harm your work or, through inaction, allow your work to come to harm.
  2. A computer shall not waste your time or require you to do more work than is strictly necessary.

Consider the computer as your app running on a device. The “time and work” are what’s required to input data by the person using it. Make them as small as possible. Three approaches to reducing the input required by an app are:

  • Avoid requiring the input altogether
  • Minimize the input requirement as much as possible
  • Use an alternative input method

I’ll now explain these options.

Improve tasks by avoiding input

Avoiding input because it’s part of a rule someone has created, or because it’s written in a book, isn’t enough of a reason to do so. Instead, avoid unnecessary input because it’s desirable, and preferable, for the person using the app.

By requesting unnecessary information, you increase the chance the person you are asking will be put off by the volume of data, decide not to provide any, and go elsewhere. Even if the person has no choice but to use the app, and must provide the information that’s asked for, the request to provide data that’s seen as unnecessary or irrelevant creates frustration and disappointment. Additionally, the more you ask of a person the less likely they’re to do it successfully. Any such failures reflect poorly on the app as it makes the person using it feel bad about themselves for not being able to use it successfully. As I’ve said repeatedly in this book, creating negative feelings in the person using your app doesn’t create a positive experience and leads to diminished use of your app.

The key word here is ‘unnecessary’. You don’t want to, and probably can’t, remove everything. If it doesn’t contribute directly to the functionality of the app or service, it’s not needed. Be careful you don’t remove the ability to provide the information people want to give you or that the business needs.

Two ways exist to avoid input:

  • Remove the need for a piece of information
  • Provide defaults and suggestions

Avoiding input by reducing what’s asked for

If less input’s better, it follows that no input’s best. You’ve already heard how it’s rare for apps to require no direct input, but this doesn’t mean individual components of that input can’t be avoided. That mobile devices have become creation devices, as much as they’re used for consumption, shows people want to provide input, and if you were to avoid input entirely, you may be preventing people achieving their goals.

The value of data to a business has grown in recent years as advances in data science and machine learning have increased what’s possible with data, and made those possibilities more widely available. Because of this it has become desirable for businesses to capture, store, and use as much information as they can gather. This has led to apps like the one in figure 6.2, where unreasonably large amounts of data are asked for and extend far beyond what’s relevant to the app.

lacey_how-is-data_02

Figure 2 A Large form spread over many screens is harder to use, and by including fields not directly relevant to the app it creates more work for the person using it and creates a barrier to their goals.

Figure 2 is an example of how what’s best for the business creating an app and what’s best for the person using it can be in conflict. The business wants as much information as possible and the person using it wants to provide only what’s necessary. Focusing on what’s best for the person, and not the business, can be the difference between a large number of happier customers, and a smaller, less happy, number who you know more about.

There’ll be times when the requirements of a business, or the opinions of a stakeholder, demand that specific input is gathered. In such scenarios, ensure the business or stakeholder is aware of the potential negative consequence of increasing the amount of information that’s asked for. The best way to make this clear is with data for your actual app. If you’ve permission, use A/B tests to show how the inclusion of extra input requirements affect how many people complete the form and the number of validation errors they experience. Once you’re clear you want to avoid as much input as possible, you must decide which input to ask for. When all data is potentially useful, you decide what to ask for based on what adds value. I summarize the guidance this way:

Only ask for input which is necessary to immediately perform a task that provides value to the person using it.

Notice this guidance is to only ask for what’s needed. You may be tempted to use optionality as a compromise when trying to avoid imposing large input requirements upon the person using the app. It’s understandable to argue for requiring a person to provide all the information a business desires, but only make what’s necessary required. Negatives to this approach are:

  • It isn’t always immediately obvious that parts are optional, and the negative feelings associated with being presented with a large form are still experienced.
  • It may be considerably less valuable to the business to have lots of partial information. This provides significantly less insight and is harder to work with.
  • Regardless of how much is optional, larger forms are significantly harder to create and test accurately. On almost every app I’ve encountered that includes a large registration process, it’s this area of the app which has the most bugs raised on it.

Avoiding input by using defaults and providing suggestions

The second way to avoid input is to not ask for things you can make an informed guess about. Two common scenarios for this are:

  • Configuring default settings when first using an app
  • Making suggestions for what to search for

Making an app configurable, or allowing personalization of the way an app looks or performs is often a desirable feature. Some people like to change color schemes, control the frequency new content is loaded, or arrange the order items are listed, but forcing a person to make decisions about every setting the first time they use an app is unlikely to be valuable or useful. Rather than having the person using the app specify settings they don’t have sufficient knowledge or experience to answer, provide sensible default settings and inform the user that settings can be changed, if desired. Many people choose not to customize or personalize the apps they use and presenting options they’ll skip is an avoidable obstacle to obtaining value from the app.

Search is another common feature easily improved with a zero input approach. Where identical searches are often performed, either by other people or the same person, you save them having to type, or retype, a search term by automatically displaying appropriate options.

These suggestions won’t always be appropriate or relevant, and in such cases a person ignores them and begins typing to search for whatever they wish. When a suggestion is relevant it won’t only save that person a little bit of time, but also gives the impression the app knows what they want.

Improve tasks by minimizing input

When input can’t be avoided, reduce it to the absolute minimum that’s required. The corollary to the idea that people are less likely to do long, complicated, error-prone tasks is that if you make something easier for a person, they’re more likely to do it. This doesn’t only apply to apps, but to all parts of life. Want someone to do something for you? Make it easy for them and they’re more likely to help you. Want someone to answer your question? Make it easy for them to understand and allow them to answer at their own pace.

The simplest way to minimize required input is to only ask for something when it’s needed or when you’re in a position to do something with it. If you don’t need to send a person something in the post, wait until you do before asking for their address. If a person will get value from an app without registering, don’t require that they do in order to use the app.

You might think it’s better to ask for more information earlier because you’ll have it ready when it’s needed, but this ignores two important points.

  1. You may never need it. In this case, you’ve asked someone to do something for no reason and wasted their time.
  2. Asking for more than is currently necessary degrades the experience for the person using the app and a degraded experience will decrease the likelihood they’ll still be using the app when you need the data.

Don’t worry, people will provide the information you need when it’s relevant and provides value to them.

Even when you only ask for information at the most relevant time, you can further improve the experience if you:

  • Minimize the effort involved in providing the input.
  • Don’t ask for the same thing more than once.

Minimize the effort involved in providing input

It’s useful to have a measure for the effort involved in providing input. A simple and easy way to do this is to count the number of taps or touches needed to provide the desired input. This means how many times does a person have to tap or swipe the screen, press a button, or click a mouse. A number of approaches to reducing this number are shown in Table 6.1.

Table 1 Approaches to reducing effort of providing required input

Approach Example
Select instead of type If you need a piece of information that’ll be one of a small number of options present buttons for each option. A person need only make a single touch for any input rather than a number of touches relative to the length of the word.
Shortcuts Scrolling through long lists to find the desired value will require a number of touches impacted by the number of swipes that must be made to scroll to the value based on its position in the list. Using a sorted list combined with fast scrolling, indexes, or jump lists get a person much closer to the desired value with a single swipe or a couple of taps.
Auto-suggest/ auto-complete Instead of typing a whole value (one or more words) or scrolling through long lists, a person reduces their total required touches if the app displays a shortened list of possible values filtered to those starting with (or containing) what’s been entered. This allows a person to type the first few letters and then tap on the desired value, and is usually shorter than typing the value completely.
Combine inputs Where two related values are needed it’s simpler to capture them both with a single control. Consider a need for providing start and end dates. It’s easy to have one calendar control for the start date and another for the end date. A simpler alternative is to have a single calendar control that displays both dates. The earlier date would be the start one and the later the end. Ignore the order the dates are selected and there’s no potential for the start to come before the end.

Or consider the need to specify a range between two values. Simpler than two lists to select from is a slider representing the entire possible range with two handles to select start and end values within the range.
Auto-focus If an app presents a series to input controls for a person to provide their data, and nothing else on that page, it’s unnecessary to also have them first tap on the field. Instead, remove the need for the first tap and set focus appropriately so a person can start typing.
Auto advance If the app requires multiple values be entered, once known values of a specific length are entered, automatically advance the focus to the next. Care needs to be taken to consider a person who doesn’t realize the app does this and tries to advance focus by tapping the tab or enter button. My utility provider allows me to enter my meter readings to accurately charge for the gas and electricity I use. For each meter, I must enter a six-digit number and they provide six text entry fields, one for each value. A second after I type the figure in a field, the app automatically advances the focus to the next field. I’m capable of typing at a much faster rate than this and manually advance the focus to enter the next digit. The app doesn’t recognize this and will try to move the focus. This results in difficult and slow manual inputs of a six-digit number. Possibly more importantly, each month I become frustrated with a company who should be trying to make something easy for me when there are many competitors who’d be grateful for my business. If nothing else changes, it’s unlikely I’ll still be their customer when you read this.
Advance until submit When focus can’t be advanced automatically it should still be possible for a person to move it from the keyboard. Consider a form containing three mandatory fields and a submit button. In a worst case scenario: a person moves their finger to the first field to set focus; moves to the keyboard to enter the value; moves their hand to set focus on the next field; goes back to the keyboard for the second value; moves again to set final focus; uses the keyboard to enter the last value; and finally moves to tap the submit button. On a desktop, such a scenario is exacerbated by transitioning between mouse and keyboard but even on a small, handheld, touchscreen device the changing of hand positions between holding for typing on a soft keyboard at the bottom of the screen and tapping fields at the top of the screen is unnecessary. A better alternative to the above is to use the enter key to move from the first to second fields and then again to the third. When the focus is on the third field, it should perform the same action as tapping on the submit button directly. The worst thing for an app doing this is that a person still sets focus by tapping on a field directly. They don’t lose anything, but for the increasing number of people who expect such functionality, your app will meet their expectations and not frustrate them.

Minimize input by avoiding duplication

As you strive to remove the need for unnecessary input in an app, duplicated input is an obvious place to make improvements. Consider these three ideas:

  • Not asking for something that can be calculated or inferred.
  • Not asking for something twice as a way of detecting accidental typos.
  • Not asking for something to be retyped unnecessarily.

Remove the need to provide something you can calculate or infer from another response. Examples include asking for a person’s age and date of birth when one can be calculated from the other. Or asking if a person is employed and the name of their employer when ‘none’ for an employer name indicates they’re not employed.

Asking for exactly the same data twice is an obvious candidate to remove, but that requires addressing the reason the duplication exists. The most common examples of this are for the avoidance of accidental mistakes or typos when entering email addresses and passwords. It’s important these values are entered correctly but asking for something to be entered twice has issues:

  • Many people will copy the first value they enter and paste it into the second field, copying the original mistake.
  • It can be used as an excuse for not providing more sophisticated analysis of the entered value or addressing common mistakes. Telling someone they didn’t type the same thing twice isn’t as helpful as pointing out or automatically correcting: common domain misspellings; the use of a comma instead of a dot; commonly confused symbols such as quotes, apostrophes, or the number 2 instead of the at symbol; or identifying possible errors based on other information such as highlighting if I entered ‘mtt@example.com’ (note the missing ‘a’ from the local part) when I’ve already said my name is Matt.
  • If used with passwords that are obscured when entered, it doesn’t address the issue of being unable to see what was incorrectly entered.
  • The intention of avoiding the entry of incorrect credentials can be used as an excuse for not optimizing the process for recovering details. Even if details were previously entered correctly they can still be lost or forgotten, making recovery handling still essential.
  • Having two fields takes up more space. Having a single, larger display of the entered value makes mistakes easier to spot and correct without prompting.
  • Duplicate entry tends not to work well with platforms that support the automatic completion of forms, and the app ends up working against the platforms attempts to make entry easier.

If you want to know if having duplicate entry makes things easier for the people who use your app track how often errors are detected during validation, how often people edit what they’re entering, and the number of invalid or unusable email addresses you receive.

The most impactful issue with duplicate content is with apps that lose or forget what’s been entered. Setting focus on a text input control shouldn’t clear any data that’s already there. Don’t automatically delete data that fails validation. It’s normally easier to correct a minor error than to retype the whole thing.

Similarly, if a person leaves part way through a task where they’ve entered some data, have it be still there when they later return. Save partially completed forms to avoid data entry duplication. Passwords may be an exception to this rule depending on the particular security requirements of the app. Save all other data that’s entered on a single user device. If the person may not want the saved data, giving them an option to clear it, as in Figure 3, is better than forcing them to enter it again.

lacey_how-is-data_03

Figure 3 Prompt people upon returning to an app in which they’d previously entered data rather than assuming if they want to keep or delete it. This keeps them in control and avoids any unnecessary duplication of effort.

Save all entry, not only traditional forms, if they’re partially completed. If you’re part way through typing a message to someone, but leave the app to answer a phone call, when the call’s completed and you return to the original app you’d expect to be able to complete the message. If you chose to save the partially completed original message in a separate area, make it obvious to the person using the app how to access and retrieve the draft. If the app is used by the same person on multiple devices, having drafts roam to allow a document to be started on one device and finished on another is an additional way to help the people using your apps as part of their busy, multi-device lives.

Improve tasks with alternative inputs

Faster experiences lead to happier users as they get the value they desire sooner. Measuring how much time it takes to get a desired result, the number of clicks/taps/touches taken to get there, and minimizing both, is great, but consider how conditions vary and the specific contexts of use for your app. In this section I’ll cover:

  • Alternatives to typing
  • Manually and automatically correcting mistakes

Even when touching the screen is the quickest way to enter data into an app, it isn’t always possible or practical. Cold and wet conditions, or a small screen, make it hard to type accurately. In these scenarios and more, you improve the experience with the app by supporting, where the device permits, the entry of text in the ways shown in Table 2.

Table 2 Different ways of entering text into an app.

Method Notes
Typed with keyboard Supported by all devices, but not always the most practical.

Normally the best option for fine grained alterations and editing.
Dictation (voice input) Can be faster and more accurate than typing but produces mixed, or no results with some languages and accents, or in a noisy environment. Potentially limited by the network connectivity needed for translation and it’s hard to edit what’s entered.
Handwriting (with stylus) Can work with a finger but normally works better with a stylus. Accurate interpretation of input can vary greatly and editing entered values is often easier with a keyboard. Works well if already using a stylus with the app or wanting to enter text that’s hard with a standard keyboard, such as mathematical formulas.
Optical character recognition (from image or camera) Requires a network connection and good lighting if using a camera. Most effective for large or complex text.

Whatever method is used to enter text in an app, it’s necessary for people to be able to correct any mistakes. Even better than making it easier for a person to correct invalid entry is for your app to cope with errors in entry. Supporting partial matches and being able to make intelligent suggestions for alternatives is expected from web-based search, but there’s no reason your app can’t do this.

Sometimes the most appropriate form of alternative input isn’t about how text is entered, but with an entirely different approach. The most common example of this is seen in capturing a location. The text-based approach is to provide an address or location name, but alternatives exist.

  • Use a geographic lookup based on the public IP address of the device.
  • Use the location settings on the device to provide a location.
  • Allow a person to specify a location on a map.
  • Select an address from a contact in the device’s address book.

Summary

The capturing of information from the person using the app is necessary for providing the value they seek, but it can be complicated and covers many varied scenarios. Some fundamental issues to be aware of and common approaches available to make the process simple and intuitive for the person providing the data exist.

  • When it comes to entering data into forms, less is better, none is best.
  • Typing accurately is hard – avoid the need for it where possible.
  • Adjust keyboards appropriate to the type of information asking for.
  • Don’t ask for things you don’t need.
  • Ask for things when you need them.
  • Selecting is easier than typing.
  • Passwords are harder to type accurately and impossible to verify when you can’t see them.
  • Getting info for the business and doing what’s easiest for the person using the app isn’t always the same thing – you must find a balance.
  • Make required fields and error messages clear.
  • Giving feedback as quickly as possible. Do this without calling a remote server when you can.
  • Don’t rely on typed/text input. Consider the many alternatives available, some of which are simpler and easier to use than typing.

That’s all for this article.

If you want to learn more about making your UX the best it can be, check out the book on liveBook here and see this slide deck for.