Creating Positive Experiences on Mobile Apps While Users Wait

No one likes to endure the frustration of waiting. Hence, we often like to find ways to beat the ticking hand of time. We go out of our way to find the quickest option or any other means to reduce our wait. One of my previous posts talked about the pain caused by long waits and how skeleton screens solved the wait problem to some extent. In this post, I take a step back to figure out what other methods could be employed to make long waits, worth enduring.

Purpose of Loading Indicator and its problem

Traditional folklore suggests that if we keep users waiting, we must let them know:

• It will take a while
• They need to be patient as they wait

Loading indicators were, hence, born. As this trend caught up, developers and designers put their blood and sweat into developing the 'Next Best Progress Bar/ Spinner Of The Year' elements. And then, we had a bunch of innovative items. Google 'Best Loading Icon' and see it for yourself. While design and functionality of these icons was good, they failed to fulfill the fundamental need of 'waiting'. Looking at these icons only made users feel that time is moving even slower than before. The purpose of ‘progress’ was lost!

Techniques to shorten long waits

1. Transitions

Consider hamburger menu on any mobile app. Tap on the menu only to see a loading icon, hinting that the next screen is loading .................... slowly. You end up waiting.

Consider  using an interactive 3D transition that slowly collapses existing screen and makes way for the new screen. Ctrip app does it really well. As soon as user taps on hamburger menu, the home screen slides animatedly to the right making way for the menu items on the left side of the screen, eventually taking up 3/4th of the mobile screen.

Hamburger Menu Transition on Ctrip app

Transition not just helps in making apps feel better, but also reduces perceived wait time.

2. Skeleton Screens

Another way to avoid loading screens and focus on progress is to use Skeleton Screens. I have covered this in good depth HERE and will not include it here, in the interest of digital real estate.

3. Offers / Ancillary Services / Advertising New Features

Long wait times can be monetized. You heard that right! You can utilize wait times by showcasing content. Relevant personalized content! This content could be: a)Lucrative deals and offers, b)Ancillary services or c)Advertisements. Airline booking apps use this extremely well by offering additional paid services, known as ancillary services, to users while users wait.

Hipmunk app uses the wait time to:

A. Educate Users

Hipmunk posts useful #Tips on specific topics. E.g., How to complete a particular task or activity, or even a random quote related to travel.

Useful Tips displayed while Hipmunk app looks for suitable flights

B. Introduce New Features

While relevant flight results are loaded, Hipmunk introduces an existing feature, ‘Fare Alerts’ wherein user is asked to subscribe to free fare alerts. An assuring statement, ‘This will not interfere with your search.’ is displayed, just in case user fears that his search operation will be abandoned. If user taps on ‘Subscribe to this alert’ button, the button is replaced by ‘Adding fare alert…', followed by ‘Fare alert added!’ message. Throughout this activity, Hipmunk’s maskot dances on the screen, hinting that flight search results are on their way. This is a classic usage of channeling frustrating wait times to positive experiences.

Hipmunk app using wait times by displaying 'Fare Alerts' to users 

Summary

The focus of loading indicators should be more on the progress rather than making wait times longer and intolerable.

To summarize, we can create better wait experience by using:

1. Transition screens
2. Skeleton screens
3. Offers / Ancillary Services / Advertising screens

When speeding-up a process is not an option, giving extra care to a customer makes the experience of waiting more tolerable. I appreciate the free cookies and other samples in line at the Whole Foods store during the Thanksgiving season as the checkout queue snakes across the entire store. Saving time is thus the trade-off between the quantitatively fast versus the qualitatively fast.

John Maeda

Waiting is what people do in this world, most of the time. As they wait, telling them how much time they have left and how they can utilize it better, is only humane!

Do you make the wait time more tolerable and engaging? How?

Minimize Errors in Mobile App Forms Using Interaction Design Patterns

Majority of errors on mobile apps occur on input forms. Users can input information with utmost ease and flexibility, if only input forms were designed better. In an old post ‘Contextual Keypad – Engaging Users via Mobile Inputs’, I highlighted the need for displaying context-sensitive keypad based on the input field type – alphabetic, numeric, email, password and so forth. A little after that, I found Luke Wroblewski’s work on design patterns that helps reduce form errors significantly. In this post, I will highlight Luke's three interaction design patterns that help reduce errors form fields:

Inline Validation

Inline Validation provides real time feedback as users enter values into corresponding fields. Let’s consider an example. On Dashlane iPhone app, if a first time user creates an account, the password field has a placeholder text, ‘Enter a strong password’. As user types the input, the app provides real time instructions on what rules the password field should comply with. This helps users to enter password without forgetting to enter a specific value or making a mistake.

Password Hints on Dashlane mobile app

Luke Wroblewski’s team ran a study by comparing forms with inline validation with those which do not have any inline validation. The forms with inline validation had 42% completion rate and a 22% decrease in errors. This shows how a small step towards good user experience helps apps succeed in the real world.

Input Types

Specifying input types helps reduce errors by many folds. One of my old posts ‘Contextual Keypad – Engaging Users via Mobile Inputs’ addresses exactly this topic. Consider ‘Reset Password’ feature on Ctrip mobile app.

Reset Password behavior on Ctrip mobile app

If user taps on ‘Email’ input field, three things can happen:

1. The keypad displayed is not email-friendly keypad. For user to search and locate ‘@’ symbol, he has to change the keypad where ‘@’ symbol is present (note that the keypad complexity increases further if many non-English languages are involved)
2. User might end up typing his first name or user name or the email id before ‘@’ symbol (i.e., if the email id is Parimala@gmail.com, user might enter just ‘Parimala’)
3. Since there is no real-time validation, user assumes that the given value is correct and taps on ‘Reset password’ button. Boom! An error, ‘Invalid Email: Please provide correct email address’ is displayed.

As you see, changing the input field type to display ‘email’ keypad could avoid user to perform 1st step mentioned above. It might be good to place place holder text 'user@example.com' inside the email field, so user becomes aware of the format. One might ask, ‘what kind of a user would enter invalid values despite knowing it’s an email field.’ It is a valid question. Yet, time and again, it has been proven that many users would do that. As Don Norman says, ‘An error that can be made will be made.’ Hence, we need to validate checkpoints in right fashion, to reduce such errors, if it’s in our control.

Input Masks

Consider a phone number field. Depending on your country, country code, changes. In such a case, phone number field would have 2 components: Country Code>Phone Number>. In below screenshot, can you guess if user needs to enter phone number with country code or not? It’s hard to tell. This could lead to errors.

If formats for input fields are such a big deal, why aren’t we taking them seriously? In ideal scenarios, it is advisable to insist users to enter input values in specific formats by implementing input masks.

Input mask is a mechanism by which one specifies the format in which the input will be accepted. For e.g. Phone number can have 2 input fields: Country code and phone number, as displayed below:

Whatsapp has clear demarcation of Country Code and Phone number

Similarly, date fields, credit card fields, social security number, bank account number and others can use input masks. 

Input masks not only help reduce errors, but also guide the user to enter input in the right format.

Input masks can be taken a step further by revealing the input pattern at the beginning itself. Consider the screenshot below. User would enter a 16 digit card number and keep checking constantly at your credit card and the field just to ensure you have not missed any numbers (Note that the credit card will have space in between every 4 digits). Instead if the below card number field could show 'XXXX-XXXX-XXXX-XXXX', it would be helpful to the user.

To summarize, reduce errors by:

1. Using Inline Validation
2. Specifying Input Types and
3. Using Input Masks for formatting and accuracy

Have you thought about reducing errors on your mobile app forms lately?

Can Error Messages have a Personality?

Murphy's Law states that "Anything that can go wrong will go wrong". While things go wrong, adding a little bit of humor to error messages can lighten up the environment, at least for that moment. Given this context, organizations have started to build error pages with enchanting personalities.

The World of 404s

Consider a common case of 404 Error. Huwshimi has figured an interesting way to display 404 error pages. One of them is this:  “A ninja stole this page. You must return when the moon has friends and the fox is borrowed.”

http://huwshimi.com/ 

Frye/Wiles Creative Agency, displays the same error using the metaphor of a missing bird.

Frye/Wiles Creative Agency

Mobile App Hipmunk uses their mascot to deliver error messages in a soothing way. When hipmunk app stops responding due to possible internet issues, this is the error message: "Whoops! We can't reach Hipmunk. Please make sure you're connected to the internet, or try again later."

When the app needs additional information, the app asks for it. In below screenshot, the app needs potential travel dates before displaying results. This is asked in a nice way, by mentioning that its difficult to show results based on existing criteria and hence, would need travel dates to show appropriate results.

One anonymous marketer at Everyday IX once, quoted,

“Imagine if all products treated digital communication as a conversation with a real human being that possesses thoughts, goals, and emotions, not just the recipient of a conglomeration of technology restraints? It wouldn’t cure all design ailments, but it would certainly soothe frustration along the way.”

As quoted above, An error message is a sensitive conversation the product initiates with a human being, at a time when something has gone wrong, sometimes, terribly wrong. At such a point in time, error message need to be emphathetic, information and helpful. Of course, error messages are life-less and non-human. Yet, they can be made human in the way they work. In short, error messages need to have a strong personality - of being a torch bearer to the user. 

Do your error messages have  a lively personality?

User Experience Design & other Overlapping Disciplines

This article was originally published on Test Insane website.

The term user experience was coined by Donald Norman in the 1990s. A review of his earlier work suggests that the term "user experience" was used to signal a shift to include affective factors, along with behavioral concerns, which had been traditionally considered in the field. Every product/service solves an unmet need or a glaring problem. Solving an unmet need or a critical problem is one thing. Creating a delightful experience while getting work done is another thing. While any user might start using the product to accomplish some tasks, one of the aspects that might retain users or improve loyalty is user experience. 

User experience is not a single discipline, but a gamut of disciplines put together. While some people think of Usability and UX as same things, many don't know about several other disciplines that intertwine with UX itself. Dan Saffer, appeared to take that first step towards summarizing that in a pictorial format. Below mindmap is a brief  summary of Dan's idea:

UX is Collective Genius

In a typical project, some of us blindly assume that UX is designer or creative head's responsibility. In reality, UX is not about solo genius. UX is about collective genius. One needs to think of users and their experiences while doing feasibility study, developers have to empathize with users while developing technical design, designers have to study if users would use this product and be happy about it, testers have to consider testing for specific pain points in the product that might drive users away and implementation / maintenance teams have to hold the customer to high standards while customizing the product for them. In short, each and every team member contributes to UX in his/her own way, based on the understanding they have, of the product and the users.

In that sense, UX is everyone's responsibility. 

Testing for Errors

This article was originally published on passbrains blog HERE.

Great designs transform the way we live and we all act as designers in our own simple ways. When we rearrange objects on our desks, the furniture in our living rooms, and the things we keep in our cars, we are designing. Through our designs, we transform houses into homes, spaces into places and things into belongings. While we may not have any control over the design of the many objects we purchase, we do control what we choose to purchase.

Faulty Designs

A year ago, at least 40 people were killed in a tragic accident involving a private Volvo bus on the Bangalore-Hyderabad National Highway. The incident happened when the bus was reportedly trying to overtake a vehicle at high speed and hit a culvert and caught fire. Before the passengers could realize what had happened, they were charred to death. Investigations revealed that this accident was a result of poor design and absence of safety measures in the bus.

Faulty Designs

The point here is that design can play a key role in making or breaking products. Volvo bus was never designed to hit the culverts nor was it tested for that. However, the driver ended up hitting the culvert. If faulty designs are not tested in multiple contexts like these, it can wreak havoc. Faulty designs are a result of inaccurate mental models perceived by designers and users contrary to system images of products that exist in real. Let’s take a brief look at what mental models are and how they can help us in creating better designs that handle error situations effectively. 

Mental Models

A mental model is an explanation of someone's thought process about how something works in the real world. It is a representation of the surrounding world, the relationships between its various parts and a person's intuitive perception about his or her own acts and their consequences. Mental models can help shape behaviour and set an approach to solving problems (akin to a personal algorithm) and doing tasks (from Wikipedia).

Mental Models

According to Don Norman, there are three aspects to mental models:

• Designer’s model: The model present in a designer’s mind
• User’s model: The model a user develops when he sees/attempts to operate the system
• System image: The way a system operates, the way it responds, manuals, instructions etc.

Every designer builds a model of the system or product while the user will have a mental model of his own. Any inconsistencies in these models lead to errors. But errors should be easy to detect, they should have minimal consequences, and if possible, their effects should be reversible.

Testing for Errors

While speaking, we can correct ourselves if we stumble or mess up. Products and systems often do not correct themselves because they are only as intelligent as the people who built them. This leads to “slip” which is the most common error – when we intend to do one thing and accidentally do another.

Well-designed products allow us to detect slips through feedbacks. For example, in a delete operation, it is good to ask for a confirmation to verify if the user wants to proceed. If that operation is irrevocable, it is better to warn him of the consequence and take his consent. A general heuristic is to never take away control from the user.

Recoverability of errors is a key aspect in designing products. When errors do occur, the following should happen:

• Give visibility to the user of what was done
• Do/Show/Tell the user what went wrong
• Indicate how the user can reverse unwanted outcome
• If reversibility is not possible, indicate this to the user

  

Error Messages Coverage

Error messages coverage can be achieved at multiple levels:

Errors-based Scenarios Testing

Testers could get a list of all error messages programmed into the product and design scenarios for each and every error message

Negative Testing 

Negative testing is not the same as error messages testing. In error messages testing you start with known error handling and test it. This is essentially "positive" testing for error handling code. In negative testing, however, you think differently. Negative testing means to "negate" required conditions. In other words, you consider all the things that the programmer/designer requires for his code, then systematically block those conditions. Example: the program needs memory, so reduce memory

Recoverability Testing Matrix

Every error message needs to be tested for Recoverability. 

• Visibility to the user of what was done
• Do/Show/Tell them what went wrong
• How the user can reverse unwanted outcome
• If reversibility is not possible, indicate to the user what needs to be done next

Some Examples

Failure Usability Heuristic by Ben Simo

Error Elimination Testing by David Greenlees

Feedback Parser by Santhosh Tuppad

** This article is inspired by Don Norman’s book “The Design of Everyday Things”

** Negative testing input was provided by James Bach

Regards,

Pari