Do mobile-device users behave differently, depending on whether they have a history of using desktop computers before they got a smartphone? We can’t answer this question from user research in developed countries, because most mainstream users have experience with both types of device: for example, only 10% of US adults rely on their smartphone as their only way to access the internet at home, according to a Pew Internet Survey. This tiny group of people must differ from mainstream users in many ways, so it does not offer a fruitful way of studying desktop heritage.

In contrast, in developing countries, we often encounter the phenomenon of technology  “leapfrogging,” in which users bypass older technologies and directly adopt newer ones. Specifically, we know that many mainstream users in India use smartphones despite never having used a desktop computer.

To better understand mobile behavior in emerging markets, we conducted a mobile-usability study in India. The study involved 10 users, split into two user groups (each with 5 people):

  1. Mobile-only users, who accessed the internet mostly through their phones and who had never used desktop computers before.
  2. Desktop-heritage users, who had had significant experience using the internet on a desktop before using a smartphone and who were frequently using a computer to access the internet, in addition to their mobile device.

Our study had two main goals: (1) to uncover differences between mobile-only and desktop-heritage users, and (2) to investigate mobile features and behaviors unique to countries such as India.

Desktop Habits Carry Over          

Our testing in the Western world shows that, in general, users rarely bookmark web pages on their mobile phones — possibly because bookmarking is a buried feature in most mobile browsers. Overall, we found a relatively low incidence of bookmarking in India as well, but we observed that bookmarking was more frequent among the desktop-heritage users compared to mobile-only users. These participants seemed to have carried over their bookmarking habits from the desktop browser to their mobile one.

However, none of the mobile-only users reported using bookmarks on their phones. Some were even unaware they could bookmark websites, and many mentioned that, instead of bookmarking a site, they would just redo the same search again and rely on the history suggestions to recover a previously visited page.

Concerns About Storage and Data Consumption

Many of our study participants had inexpensive Android phones with low internal memory (~512MB) and low internal storage (8–16 GB). Additionally, mobile data plans are usually limited in India, and unmonitored use can get expensive. Performance, storage space, and data costs heavily influenced user behavior.

While these issues affected both mobile-only and desktop-heritage users, desktop-heritage participants seemed to care less about data consumption, possibly because their more data-intensive browsing was done on their computers.

Users addressed the problem of limited storage by restricting the number of native apps installed on their phones. As a result, many users used websites or web apps instead of native apps for their mobile use. Desktop-heritage and mobile-only users differed in how they decided which native apps to install.

Desktop-heritage users tended to download native apps only for a limited number of frequent tasks. (This same finding holds true of users in other parts of the world, but to a less extreme degree: apps are for activities performed often, and mobile-web use is reserved for occasional needs.)

One of the users encountered an insufficient-storage issue when she tried to download the Zomato app. While she was making space on her phone for it, she said: “I used to have this app but because my phone ran out of memory I just use the website whenever I need it.”

In contrast, mobile-only users also considered the opportunity cost of not installing an app; in other words, they were also influenced by the availability and quality of a service in the browser. For example, one of our study participants chose not to install the Facebook native app, although she did use Facebook quite frequently; instead she used Facebook in the browser, because she felt that its mobile site was good enough. However, she did download MiniMovie, an application for creating slideshows, which she was using only occasionally, because, even if she had been able to find a slideshow web app, the experience would not have been as good.

Possibly as a result of their prior experience with the desktop environment, desktop-heritage users did more task management than mobile-only users: to address the problem of limited phone memory, many engaged in systematic killing of background apps by swiping them away as often as possible “to prevent the phone from crashing.”

Mobile-only users had a different solution that tackled both the low memory and the need for data efficiency: they used lightweight browsers and services that supported off-network sharing of apps and other files among users. Browsers such as UC Browser and Opera Mini use data-compression technologies and cloud services (that determine the closest server from which to download data) to reduce the page load and minimize the data consumption.  One user explained that [Opera Mini] “is less data consuming. Chrome consumes more data. My RAM is too low so I didn't download the Facebook app.”

Lightweight browsers’ features allowed users to receive notifications from services such as Facebook without having to install the native app. Above is the Facebook login page as seen in the UC Browser. One user explained, “Because it is faster and it consumes less data, I have the Facebook [web] app in UC Browser only. Whatever notification I will get in Facebook, it will automatically show in the mobile screen [notification bar]. Like any friends’ birthdays or if I get any messages.”

Users also took advantage of the ability to “save” apps to an SD card and thus expand their phone’s memory. Some even used the browser to download compressed versions of the apps on the SD card, and then expanded and installed those apps locally, thus minimizing data consumption:

“If you use UC Browser, you can save apps [i.e., bookmarks to web apps] to the SD card. I can then install it without the net. I never keep too many apps on my phone.”

Services such as SHAREit were used to transfer apps and files between phones located in close proximity without using the internet. In this way, apps could be downloaded from a friend instead of using precious data to do so over the network.

(Left) The SHAREit app allowed users to transfer files to a nearby phone without using the network. (Right) The files that could be transferred included downloaded apps. One user noted that he uses SHAREit: “for sending and receiving apps... Sometimes when there's no network, I can use SHAREit. And SHAREit consumes less time. If you download on the network, it takes time. SHAREit is faster. I also use it for sharing media files.”

Because Indian users are so picky with the apps they choose to download on their phones, companies devise special incentives to convince people that their apps do provide enough added value. Many websites advertise special promotions that are available only in the corresponding app in order to entice users to download the app.

Companies such as Lenskart attempted to convince users to download apps by offering special promotions or features available only in the app.

Other companies such as Flipkart have embraced the users’ needs and provided strong web apps that can work offline and whose user experience is comparable to that of native apps. (Such mobile web apps are sometimes called “progressive.”)

In this world of expensive data and limited storage, bloatware installed on the phone by device manufacturers is particularly hurtful. Smartphones often come with a large number of useless preinstalled apps that cannot be deleted. Our study participants resented these default apps that burdened the phone’s already cramped storage space.

Out of the 17 Google apps preinstalled on one user’s phone, she only used 3: Chrome, Gmail, and YouTube. (Stills from usability-testing video.)

Device Sharing and App Lockers

Shared access to a phone is common in India. Often, there are fewer smartphones than people in the household, and family members share the device at some points in the day. Further, due to cultural differences in the notion of privacy, it is acceptable to borrow a friend or relative’s phone to browse through the picture gallery or to make a call. In these situations it becomes important to have a privacy-control feature that limits access to sensitive information such as text messages, contacts, or Facebook.  

In our study, the most frequent solution to this problem was the use of app lockers. App lockers are applications that, once installed, enable users to completely or partially “lock” certain other sensitive apps and allow access only if the user enters a pin or pattern. App lockers can also be configured to hide sensitive data within an application — for example, they may hide a subset of the pictures in the phone’s gallery.

​(Left) NQ Vault provided both tapp-locking and data-hiding features. (Right)  A password screen controlled access to a locked app. One of our users who used this app explained, “I use Vault for locking. I specially use it to lock the WhatsApp and [Facebook] Messenger...to maintain privacy. So if I open the app I will first have to enter password. Even in notifications it will hide the message...I can also hide the pictures. If any private pictures are there.”

App lockers are somewhat of a paradox. In our usability studies, we often see people complaining about login walls, yet here’s an instance where they voluntarily raise one to prevent unwanted intrusions into personal information in a world where sharing devices is common. 

One-Time Passwords (OTP) for Registration and Login

Not every mobile user in India will have an email or a Facebook account, but, by definition, all mobile users will have a phone where they can receive text messages. So apps and websites in India provide the ability to register with a phone number. When the user enters a phone number, the site will text to that phone a numeric code serving as a one-time password (OTP). Users can enter that OTP to register or log in to the site. Often they won’t even have to type the OTP: the site will grab the OTP from the received text message and will enter it into the login screen.  

(Left) Users could enter a phone number to register on the Swiggy app. (Right) Once the number was entered, the user was texted an OTP. For future logins, the user could use either a password entry or OTP verification.

OTP is also used to facilitate login and registration on the desktop, provided that the user has a mobile phone nearby. The site sends the OTP to the phone, and the user can copy that code on the computer. (This is an example of a good omnichannel experience, in which users of one channel take advantage of the capabilities of another available channel.)

Quickr.com, a site for buying and selling preowned products, offered an email-login option and an OTP option. During each login, a new OTP was generated. No need for remembering passwords!

Note that the OTP also provides a reasonable solution to the notoriously hard problem of remembering passwords. It also saves users the effort of typing passwords, which is especially difficult on mobile — regular passwords often involve a combination of special, lower- and upper-case characters that are rarely available on the same mobile keyboard.

Mobile Phones for Payments:  Cash and Online Wallets

In India, not everybody has a credit card or a bank account. Mobile phones serve as a substitute for people without these financial instruments.

ICICI Bank allowed users to send money to others through a text message.

Users can send money to others via a text message that contains transaction and authentication details. The receiver then uses those details to withdraw cash from an eligible ATM machine; no bank account or ATM card is needed for this transaction.

Some payment-portal applications like Freecharge allow users to deposit money into an online wallet and use it to make payments in physical stores. In Freecharge, this can be done using the Pay Merchant feature:  The user enters a registered mobile number and an app-provided PIN into the point-of-service (POS) machine of the vendor. At the time of payment, the user only needs a mobile phone; no cash nor card.

Conclusion

Our study of mobile use in India found few differences in behavior and concerns between mobile-only participants, who relied solely on their phone to access the internet, and desktop-heritage participants, who used both a phone and a computer. While desktop-heritage users were more likely to transfer behaviors learned on the desktop (e.g., bookmarks, managing multitasking) to mobile, both types of users were concerned with storage and data consumption and limited the number of native apps installed on their phones. Desktop-heritage users decided which native apps to install mainly based on expected frequency of use, but mobile-only users also considered the opportunity cost of not installing an app — that is, how likely they were to find the same functionality and experience on the web. Both desktop-heritage and mobile-only participants engaged in phone sharing and used app lockers to protect sensitive information from people who occasionally borrowed their phones.

Our international studies tend to find cultural nuances as opposed to major cultural differences in user behavior: people are the same everywhere, and the biggest usability issues stem from the gap between human thinking and computer features which is much greater than any differences between people from different countries.

Unlike earlier studies, this study with mobile users in India apparently departs from the norm: common Indian solutions that we report in this article (e.g., use of app lockers or lite browsers) are almost never seen in our mobile-usability studies with Western audiences. However, these solutions address behaviors encountered everywhere: many of us have occasionally handed our devices to someone else to take a picture or read a headline — just long enough for an embarrassing notification to pop up on the screen. And although in developed countries only a relatively small percentage of users resort to using lite browsers, people do care about their phone storage capability and install applications only if they expect to use them frequently.

Studying and understanding these problems and their solutions in India not only gives us insight into catering to international mobile audiences in developing countries, but it also teaches us how to design better products for a subset of our user demographics (e.g., those who rely on their phone to use the internet) and gives us ideas for solving general-audience problems such as keeping our information safe from accidental, but embarrassing disclosures, and dealing with the difficulties of remembering and typing passwords on the go.