20 May, 2016

Mobile App Study using GOOB Heuristic

A few years ago, when I started working on mobile apps, the traditional approach was to sit at a cubicle and use the app. As a small extension, I would install the app on my personal phone or corporate device and take it to my neighbors, friends and family, who I thought belonged to potential user groups. In few projects, I had the luxury to on board real users  to our usability lab where we could watch them using our app in a controlled environment. While my team and I were able to get new perspectives with each of the above approaches, deep down in my heart, I felt that I was missing something; something very fundamental.

GOOB Heuristic

A while later, some of my peers and colleagues inspired me to take mobile apps on a real tour of the real world, while it was in its initial stages. I remember waiting at a bus stop , with the app in hand, making random acquaintances with teenagers and middle-aged people, and asking them to use my app or take a survey with me, in exchange for some flowers and chocolates. The onlookers would wonder how a well-dressed individual like me could do this 'cheap' on-the-road surveys. This was in Q4 2014.
Image Source: www.leanuxtools.com
This experiment helped me see that apps have to be used in uncontrolled, real-time environments if we had to get genuine feedback from users. Of course, random users have huge risks, but a smart user recruitment initiative might mitigate some of these risks.
From thereon, my way of doing things changed dramatically. I started "Getting Out Of the Building (GOOB)" more often. I started observing how people user their apps. A child is playing a game while she swings on a cane swing at home. An old man is looking closely at the app because of poor sight. A teenager is trying to select a green colored dress online, although she cannot seen green color as it is, due to color blindness. A daily commuter is taking online courses on a mobile phone as he carries a laptop bag on his back, lunch bag in his hand, while standing in a crowded, moving, metro train. Now, these might sound like corner cases, until the point that there is a rising majority using apps in this way, which is a fact today.

Follow Me Home

The simple GOOB heuristic was revolutionized by Intuit with their 'Follow Me Home' approach. The founding team at Intuit, during their initial days, strongly believed that the best way to build a great product is to observe users in their real environment. They observed their users use their finance based products like taxation, payroll and others in their homes, offices, and other locations to determine how exactly the products are used. Some users were filing tax returns at the kitchen table while few others were doing payroll in their office. This helped them see that usability labs, in controlled environments doesn't provision users to be their 'natural best' where interruptions are very common. Even today, Intuit stays very close to customers and hooks on to their pain points early on in their product development life cycle. Good for intuit!
People are at their best in their natural habitats.
It is important that people are observed while they are using apps in their natural habitats. We must be aware that we may not get everything right, not at all times. Yet, attempts like 'Follow Me Home' or 'GOOB' can help organizations to understand what user wants, a little better.
The complexity of app usage is only going to increase, which is why app developers have to Get Out Of the Building or Follow Users Home if they want their apps to be acknowledged, adopted and appreciated.
Do you GOOB enough?

21 April, 2016

What is Lean UX and why you should adopt it for your startup

This article was originally my guest article for YourStory
User experience design (UXD) was traditionally governed by wireframes, prototypes, experience maps, visual mockups and others. But, in today’s constantly changing world, designing products at a faster pace is critical. The need of the hour is ‘Lean UX’.
What is Lean UX?
In Jeff Gothelf’s words, “Lean UX is the practice of bringing the true nature of UX work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed. The inspiration for Lean UX came from Lean Startup and Agile Development methodologies.”
Until a few years ago, when projects were run in waterfall style, a linear, siloed UX process seemed to work well. However, as organisations made the shift from waterfall to agile methodology, there was a huge gap in the way UX teams coped with their work. The expectation was essentially to get UX work done a little faster, in shorter time and under a huge budget constraint. Essentially, it had to be done NOW. This called for a huge shift in mindset and way of life itself. The Lean Startup concept made it further more challenging to embed UX into software development lifecycle in an efficient way.
How Lean UX works
A few teams headed by Jeff Gothelf experimented with the idea of tying the knot betweenAgile/Lean and UX. During this experiment, they realised that the productivity and efficiency of UX teams skyrocketed, because Lean UX paved the way for designers to open up UXD process for non-UX folks, who could review and provide inputs/better ideas faster. This eventually helped teams deliver better quality products with great experiences in a short span of time.
Lean UX is the fundamental belief in getting critical work done, without focussing on perfect design documentation. In a typical Lean UX team, design studios are set up with cross-functional teams where everyone presents their ideas, and critiques others’. They might even create vague sketches of their ideas. At the end of this exercise, there is a repository of ideas. This kind of early team involvement instills a sense of ownership and a ‘one team, one product’ goal. This process would be iterative in that the team member would go back and forth to identify top ideas and start building them. The team will create features, put out the app in the market and ensure that users are exposed to it as early as possible to gather feedback.
Lean UX implementation by an e-commerce player – a case study
An e-commerce giant wanted to re-design its website as a seller platform. It was already following the lean methodology in most teams, but its major concern lay in getting Project Management and UX teams aligned on work plan and schedule. The entire development team was sent to a lean awareness workshop, after which the team got together to discuss how to align UX with Lean. In one such case, the team followed the below approach:
Cross-functional teams
Teams from different disciplines collaborated over design decisions by bringing their perspectives to the table. Once everyone contributed, the team would decide on final designs based on input from developer, Quality Assurance, Business Analytics and UX teams.
Getting out of the building
A saying goes, “If you are in the UX business, GOOB (Get Out of The Building).” Following that simple piece of advice, the teams then validated their designs by talking to real users and gathering feedback about designs. Nordstorm Innovation Lab published Sunglass iPad App, a case study they conducted that demonstrated ‘GOOB’ heuristic very well.
Fewer deliverables
The team had fewer deliverables in the form of paper prototypes, and low fidelity wireframes that did not need take too long to create. Additionally, Big Designs Up Front (BDUF) were consciously avoided. This helped to iterate and build better designs.
This focus on Lean UX paid off in a great way. A survey that was run thereafter showed that sellers found the on-boarding process very easy on the new seller platform. Today, this e-commerce player thrives on the revenues from sellers and has recorded great profits.
Benefits of Lean UX, therefore, include:
  • Optimum design strategy
  • Projects delivered faster
  • Fewer and relevant deliverables
  • Happy customers

One good start to implementing Lean UX can be as simple as setting up small teams where everyone is exposed to UX early on, from beginning to end. where team members work together and converse as and when there is a need, instead of scheduling meetings several hours or days later. There is never a “I’ll check this with architect ‘X’ later.” That person ‘X’ should, in fact, be an integral part of the team.
Today, there is a strong need to co-own and co-make products that needs designers, developers, product managers, testers etc., to collaborate and solve problems collectively. As Jeff Gothelf says, “You are in the problem-solving business. And you don’t solve problems with design documentation. You solve them with elegant, efficient and sophisticated software.”
So what business are you in?

07 April, 2016

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 
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?

23 March, 2016

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?

10 March, 2016

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.”
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?

24 February, 2016

Facilitating Better Interactions using Skeleton Screens

Several years ago, I was performing a funds transfer operation online, for the first time. Until that day, I was a cheque-writing person at heart. Immediately after the transfer on a prominent bank website, the web page blanked out. I was nervous if the transaction had completed or not. The page remained blank for 2 full minutes. I panicked. I clicked on 'Refresh' icon, as if luck was desperate to be on my side. I was slapped with a message, "Don't be impatient. Please wait...". It was a painful moment.  Why was I scolded for feeling nervous about something very important while the bank website hadn't taken any pain to tell me what happened with regard to my transfer. 
A few months later, I noticed a message pop-up that read, 'We are processing your payment. Please wait. Do not click on the "Refresh" button or close the window.' This message compensated for my hurt, in the past. I thought, this time, luck probably was on my side.
Perennial Spinners
Traditional folklore suggests that if we keep users waiting, we must let them know:
  1. It will take a while
  2. They need to be patient as they wait
Thus, the progress indicators and spinners were born. If you are a frequent user of mobile apps, you have seen the perennial spinners, loading for eternity at some point in your life. You may have seen them innumerable times. Sometimes, you are cursing the app; sometimes you are cursing the network and at other times, you are cursing your own self and taking the blame for things that don't work as per your expectations (False-Blame).
As this trend of Progress indicators/spinners, 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.
Skeleton Screens
Recently, I noticed this screen while accessing Facebook app on my phone. This screen indicated that the app is loading the screen real slow, BUT bit by bit. While the app worked this way, it made sure that each UI element's 'skeleton' was loaded beforehand and then content was loaded one after the other in a lazy loading manner. I didn't know what to call it at the time, but a little later, I found out this is called a Skeleton Screen
"A skeleton screen is essentially a blank version of a page into which information is gradually loaded."
Luke Wroblewski
A skeleton screen gives a visual cue that content is loading one after the other into each UI element area. It has been found that skeleton screens play a major role in the perception of users who appear to think that these are not as slow as spinners or progress bars. In fact, many users seem to love them for its look and feel. More power to Skeleton Screens.
Have you used skeleton screens in your products? Share your story!