Intro

• Why mobile design?
• Why do we surf on mobile?
• Desktop vs. Mobile design

Mobile UX: the strategy

• Mobile first
• Writing for mobile
• One action on one screen
• Above the fold, below the fold
• Touch hierarchy
• Size matters
• Beware of overcrowding
• Big Pictures, Small Screens
• Never make them use the keyboard
• Responsive web page vs native app
• Push notifications

Why mobile design?

Let's start with some numbers. 

• There are 3.5 billion smartphones in the world; an average adult spends 2 hours a day on their smartphone.
• In 2020, mobile advertising on a global scale accounted for two-thirds of all advertising spending on digital.
• Globally, the percentage of web access via mobile in the last year was 62%, and it is expected to reach 75% in the next five years.

Just numbers.

These numbers are an average, and to tell the truth, there are areas where these statistics are lower, because it depends on the market, the target and the way a user makes use of a particular site: but what is certain is that we surf from our smartphones, and we do it every time we have to make a decision. And this is not just me saying it, but Google, which is reminding us that 90% of users cross-use desktop, tablet and mobile devices to make a purchase.

And what does this mean? It means that we go to the mall and we see a pair of shoes that we like, and we quickly search for it on our cell phone to read the reviews. Maybe we're not so convinced, and we go home, until we see an advertisement for that brand on our tablet reminding us that those shoes are waiting for us: then we go into the living room, turn on the computer, pull out our credit card and buy. Boom. Shoes bought.

Are we mobile users? Are we desktop users? Are we tablet users? What’s the meaning of life? Where are we going? What did I have for breakfast this morning? Questions that no one knows the answer to, but this teaches us that every time we imagine or design or develop a website and find ourselves in front of a computer, we're already seeing the wrong screen. What we have in front of us is not the screen that many of the users will see to get a feel for our site.

These considerations give us a precise indication, they convey to us an imperative, a moral duty, which is: we must take care of the mobile experience, treat it as a separate discipline, as a separate project, to which we must devote attention, time and money— preferably the money of the client—and that's why mobile design exists, meaning the design of the user experience of a responsive website or a native mobile app.

And a designer who is specialized in mobile design is one who is able to design interfaces with in-depth knowledge of the problems and needs of a mobile user. And even if we said that there is no such thing as a mobile user separate from a desktop user, it's true that when we pick up this mesmerizing device our needs magically change, we become more inattentive, we buy less than when we use the computer but we are more loyal, more demanding, more exacting. We have less time, we forget what we were reading, what page we were on, where we were, we can’t click the links with precision, and for each navigation error we tend to publicly curse at whoever designed that site: in short, we become what is called "a mobile user".

But who is the mobile user, and why do they choose to browse from mobile? What are the differences from the desktop user? What are they looking for in a responsive page or a mobile app? How do they use the cell phone, where do they look, where are the keys they statistically press the most? What is their relationship with the phone's keyboard; when was the last time they used it and why do they never fill out a form? How should we arrange the elements on the page to get them to actually read it and press that damn call to action? How should we design the main navigation, the menu, the tabs, the splash screen, the filters?

Questions, questions and more questions—who do you take me for, a fortune teller?? My name is Luca Panzarella, and for the past 13 years I've been helping companies of all sizes create positive experiences for the users of their digital products or services through their mobile websites or apps, and in this course we're talking about mobile design.

Let’s start.

Why do we surf on mobile?

So, let's start here. 

What does our brain tell us when we become a mobile user? Why do we choose to use a cell phone instead of a computer or a tablet? Sure, there can be thousands of reasons why we do this, and we certainly can't list them one by one, but we can summarize them into three major macro-categories. Here they are.

Micro-tasks

We use cell phones when the task we need to do is extremely small, both as cognitive and physical effort, for example:

• We're standing in line at the grocery store and need to jot something down;
• We're in a mall and need to read a product review;
• We just woke up and want to see what the weather is like;
• We need to add an event to the calendar. 

In short: we are micro-tasking, we have a goal in mind that we need to accomplish and we want to achieve it as efficiently as possible. It's a goal that has a definite beginning and end: after all, we want to jot down our shopping list, not write our first novel. 

A responsive website or mobile app that takes advantage of this motivation must optimize navigation by having the user's goal in mind, that single action that is worth opening our site or app for them, and remove, remove, remove everything else.

In the Accuweather app, the current temperature data takes up about 50% of the screen.

For example, a weather app needs to communicate one thing: what the weather is like right now. 

Certainly, the app will do other things as well: maybe inform us about tomorrow's temperature, about wind, the sea, lightning, you name it. But we have to be aware that those who get to that kind of information are a small percentage compared to those who just want the primary information. 

People who access a train reservation app want one thing: to book a train going from one station to another, as easily as possible. 

Any additional information will be perceived as an obstacle, and the more frequent these obstacles are, the closer we get, dangerously, to the final straw and to them closing the page or app. 

Here and now

The second reason we surf from mobile is this: we want to know what's going on, here and now. For example:

• We open Google Maps and look for a nearby gas station; 
• We open TripAdvisor and look for a restaurant nearby;
• We open Eventbrite looking for an event in the next few days; 
• We open Justeat because we want them to deliver a decent Japanese lunch, at the best price and at the time we decide;
• We open Trenitalia because we have to book the train that leaves in 10 minutes at platform 5 because we missed our connection. 

While computer browsing is dedicated to long tasks that have no temporal connotation, mobile browsing implies an urgency, the need to find something as close as possible, as soon as possible, as convenient as possible. 

The integrated GPS allows us, with a simple tap, to sort the data by proximity, an operation that is easier and more accurate from mobile than from desktop, and we should never underestimate how ease of use can influence the choice of a device instead of another, or, even worse, of a site that provides a better experience. 

The site Deliveroo.co.uk allows us to add our location with a simple tap instead of typing the address manually.

The camera on our device has been able to read any QR code for a few years now, and although this technology has never really caught on, during the coronavirus pandemic thousands of restaurants had to transform their paper menu into a digital one, available via QR code. 

In short, the technology inherent in smartphones beats any PC processor when it comes to searches that are bound by time and space. 

A responsive website or mobile app that solves this need has a duty to make mobile search as easy as possible, for example by making us avoid typing an address or selecting activities to do nearby.

The main page of the TripAdvisor app suggests to us to "see what's nearby". to avoid manual typing. 

Entertainment

The spread of smartphones and their omnipresence has turned so many introspective moments into playful ones, like when we’re walking, or when we’re waiting for the bus, and even when we’re at the table with someone. 

In this book, we won't talk about the social problems of our time, but it's a fact that we pick up our cell phones whenever we feel the slightest bit bored, just like the previous generation used to put themselves in front of the TV, zapping away; only we do it everywhere, in situations where we're not necessarily alone. 

And while before, with the TV, we were simple passive spectators, today we can participate, chat, influence whoever posted that content for better or for worse. 

When I talk about entertainment, I'm not simply referring to the world of video games, even though it's a market that has also grown thanks to smartphones, given that 60% of the entire video game industry specifically concerns mobile gaming. 

Entertainment also includes newspapers, music, social media: today, the way of using these forms of entertainment has fragmented and we no longer read a newspaper but a single article, just as we no longer listen to an album but download a single song. 

A responsive site or mobile app that meets this need can leverage gamification, ease of use and emotional design to convince the user to stay "just one more minute," watch one more episode on Netflix, one more related video on YouTube, one more borderline porn clip on Tik Tok, one more unmissable story on Facebook that will self-destruct in 24 hours. 

On the left - the playlist suggested by YouTube, Netflix related videos on the right. 

In conclusion

These are the three macro-categories to which the website or mobile app you're designing probably belongs. And sure, they're rules that, at least in part, apply to desktop users as well, and so the question is, what's the difference in the browsing experience I can have on a smartphone versus a desktop experience? We'll talk about that in the next chapter.

 Desktop vs. Mobile design

Let's go into more detail and ask: what's different between a desktop and a mobile experience? We can encapsulate the differences into five broad categories: size, orientation, navigation, environment, and focus. 

Let's look at them together. 

1. Dimensions

I don't know if you've noticed: the smartphone screen is smaller than the computer screen. 

In a desktop version, we have space, lots of space, and we can afford to: 

• Use two columns side by side and make sure that the element on the left is logically connected to the one on the right;
• Invent a sidebar where you can put less important content or where you can put the main call to action;
• Put a descriptive text with a form next to it; 
• Use maps and create a logical link between the content on the left and the map on the right. 

Airbnb.com lists apartments on the left  conceptually tied to the map on the right. 

On mobile, we need to forget about this freedom. 

Everything is stacked up and we don't have much room to put content sideways. This means that, while before we had the possibility to put a primary and a secondary piece of content more or less on the same level, on mobile we have to make a choice: either one or the other. 

And whether it's a responsive site or a mobile app, it doesn't matter: a war is being waged on the device to grab every single pixel available. 

And what are the possible solutions? We can design a layout starting from the mobile view. Or we can work on the content, inserting only what is essential and removing everything else. 

We'll talk about how to make this difficult choice in the next section about mobile UX. 

2. Orientation

The second point concerns the orientation of the screen: not only is the screen smaller, but it is vertical instead of horizontal. What does this entail? 

• We can no longer arrange our message in multiple columns, but on mobile each one must be a monolithic block. We can't rely on the image next to the text to be able to explain or emphasize what we just described in words.

Does the center image refer to the text above or below? To know this, we have to read the text for a few seconds. 

• We're forced to do a lot of scrolling, going down and up several times in order to logically connect what we've read with the image we're seeing or the button that asks us to buy. 

Verticality forces us to make an effort of memory, an effort that doesn't exist in the desktop world because, having more space available, we can logically connect texts, images and buttons. 

In short, the vertical orientation is a tough nut to crack, because not only is the layout smaller, not only is it different, but we have to provide one that can coexist with both orientations: vertical on mobile, horizontal on desktop. 

And the fact that a native mobile app doesn't have this requirement is already a great reason why we can design an app more easily than a responsive website. The solution to this issue is to create layouts on mobile that are not just a responsive version, but layouts that are different altogether from the desktop layouts. 

We'll talk about this at length in future chapters as well. 

 
3.  Navigation and keyboard 

Just so we don't overlook anything: when we navigate a site on desktop we have a mouse and a keyboard at our disposal; instead, on mobile, the only tool we can rely on is our hand. 

49% of users browse using only one hand and only their thumb. 

36% use two hands, but one holds the phone and the other navigates, almost always with the thumb. This brings us to 85% of users who use their cell phones in this way.

85% of users use only one hand and only the thumb to navigate.

On the desktop, we are free to go all over the screen with practically no effort: we can go up, down, I can do precision work and click on the microscopic "x" that has appeared in the right corner. Also, thanks to the keyboard, we can easily fill out forms that ask everything about us: email, password, our biography, whatever. 

We can right-click, create multi-selections, hover and see a change in the interface that helps me realize that I can do something with the area I'm in.

On mobile, we can't do any of that, and the ease with which we reach certain areas of the screen depends on only one thing: the size of our thumb. 

A finger, by its very nature, is a dumb, primitive and imprecise tool that gets in the way between our sight and the screen. This is also one of the main reasons why we end up tapping on the wrong button, or tapping when we simply wanted to do some scrolling. 

Remember that these are not exceptions: this is the usual way.

The solution to this mess is to change the way we prioritize things: we discuss this in the chapter on the "Touch Hierarchy".

4. Environment

The fourth point concerns the environment in which the user is located. 

When we are on desktop, we are likely to be in a room in our house or a place where we feel safe; maybe we are listening to our favorite music, we feel more open to face possible risks and we have all the time available to analyze the page we are reading in detail. It's no coincidence that today, the desktop version remains the preferred version for users when they have to buy something. 

When we browse on mobile, we find ourselves in dynamic, confusing environments where it's difficult to even hear our own voice, or our reading has to be interrupted by the arrival of the subway or an accidental bump. 

Even if we are at home, and thus in familiar environments, we don't necessarily have the same amount of time available as when we surf on the desktop; think, for example, of situations at home where our surfing is interrupted by an external factor: lunch is ready, the intercom is ringing. The ‘enemy’ sometimes comes from the phone itself: phone calls, text messages, notifications. 

In short, mobile browsing is by nature more fragmented, more chaotic, more superficial. The solution to all of this is to create pages that put essential content at the forefront of the user's mind. It's not that there's no room for niceties, there's not even room for all the menu items, so to speak. 

We must cut away, without mercy, anything whatsoever that is not essential for the user to decide to perform the action that will take them to the next step. 

A very difficult job, because it presupposes knowing with absolute certainty what the user wants, and we hardly know what we ourselves want in life. But that is a theme for another book. 

5. Multi-tasking

The last point is multi-tasking. 

On the desktop, we're used to doing a little bit of everything we want: we have a tab open with YouTube and our favorite songs. Our software with which we write text. The website we are browsing because we needed the answer to a technical question we had. The open chat with one of our friends. 

On mobile, we don’t. 

Not only does each application compete with all the others, but the user must then choose, in a linear and exclusive way, which application to open first. 

The mobile user is forced into a small space, no mouse, no keyboard, usually in dynamic environments and can only focus on one thing at a time. 

In short, the mobile user is like most of us men: they can't do more than one thing at a time. 

In conclusion

Impatient, distracted, clumsy and without precision tools: the mobile user is significantly less well equipped than a desktop user, and less likely to finish the task they set out to do. 

And that's where our professionalism comes in: whether you're making a responsive site or a native app, you owe it to yourself to learn how to communicate for the specific needs of the mobile user, and you'll need to make sure that every single element in the layout has a good reason to be where you put it. 

In a nutshell, you'll have to communicate in the simplest and most immediate way possible, and since I already know you haven't paid that much attention to these words, I've created an entire section dedicated to this for you: let's talk about Mobile UX design. 

Mobile UX design

Mobile first

In 2010, Eric Schmidt, CEO of Google, made one of those announcements that tend to cause no small amount of trouble for designers around the world. 

What did Eric say that was so bad? He said something like this: "Dear sirs, we get a lot of mobile search here. How much? A lot. An unimaginable number. So, from now on, we’ll do one thing: we’ll put the sites that aren't optimized for the mobile experience on the back burner in favor of the optimized ones". 

Is that all? No. Eric went on and said, "We’re starting to design all of our software with a mobile-first philosophy".

Boom. 

From that moment, hundreds of thousands of calls were made at lightning speed around the world, to the homes of designers who were woken up early in the morning – around 11am – by customers who wanted a "mobile first" site. 

And at this point, you're probably wondering, "What the heck does it mean to make a mobile first site?" Which is what all the designers asked themselves at the time. Fortunately, many years have passed since that day, and today we know precisely the principles of this design philosophy, which are two. 

Design first on mobile, then on desktop

The first: design directly with a mobile screen size in mind, and only then design for a desktop. 

What would be the advantage of this strategy? If I start from a small space, as problematic as the mobile one, it means that I will be forced from the beginning to stick to what is essential, to decide a precise hierarchy for texts and images. Title first? Image first? Paragraph first? Button first? On mobile, we can't help but answer these questions. And once we have everything set up properly on mobile, only then do we move on to the desktop version.

After all, it's like living in a small apartment and after a few years buying one that's twice as big: you'll see how many things you can fit into it.

The hierarchy of information changes

The second point: watch out for the hierarchy of information, because if on desktop we have much more space available and can afford imprecision and inefficient spaces, on mobile we can't. 

Here, we need to make what the user is looking for highly visible right away and make them use that functionality easily and painlessly. 

For this reason, you will often find the concept of "mobile first" associated with that of "content first", i.e.: let's focus on the core of the content or functionality to be shown to the customer. 

In a "content first" philosophy, every time we deal with a text, we ask ourselves the following questions:

• Are we really sure this functionality is necessary?
• Are we sure that the loading of this feature or graphic effect is worth the loading time for a user opening that content in the middle of the Molise countryside? 
• What is the core of this functionality? Can we show only this part to mobile users and show everything else to those using the desktop version?
• Of all this text we want to communicate, what is the single truly essential sentence?

And after this binge of theory, let's take a few practical examples of "mobile first" and "content first".

Youtube

Since it was Google that first mentioned it, let's take a closer look at its sites, and in particular YouTube, undoubtedly one of the most successful.

We have a mobile version that looks a lot like a native app: it has a tab bar at the bottom, it doesn't have any hamburger menu, although this is present in the desktop version, along with other menu items that extend into the top right menu, including the "Add video" button, which is not there on mobile. Even the notifications icon disappears in the mobile version: after all, on mobile we have push notifications. 

The differences between the web and mobile versions of YouTube.

Tomorrowland

Another successful example is a music festival, Tomorrowland.

Tomorrowland's "mobile first" philosophy.

 Let's start, as usual, with the mobile version: a tab bar at the bottom, as if it were a mobile app. A layout full of one- or two-column cards. Two menu items in evidence: the radio and the link to access, and on the left a logo that works as a hamburger menu, containing items that are most likely not that important for the client's business. 

Let's take a look at the desktop version. 

The tab bar has become a vertical bar: that's right, just like the one for YouTube. 

The logo no longer has a drop-down menu, because this has become an expanded menu. The rest of the layout, being a card layout, is easy to imagine. 

"Mobile first" is not "Everything mobile first" 

Be careful not to confuse the "Mobile first" philosophy with "Let's make a mobile experience for any screen resolution". 

Someone should tell the Huffington Post, for example: taking a layout designed for mobile and copying it pixel by pixel on desktop, only adding a horizontal menu—well, that can't be an effective solution. 

Maybe we'll reward those who come from mobile in this way, but a desktop user deserves better optimization of space than this.

For example, Pitchfork.com, a popular music-related journalism site, does better. 

Huffingtonpost.com does nothing but pick up the mobile version and enlarge everything for the desktop version. 

Pitchfork.com also starts with a very straightforward mobile layout, which is intelligently optimized on desktop.

Let's start, as always, with the mobile version: here we have once again a tab bar at the bottom, showing icons without captions: this approach is always risky, especially when we use unconventional icons like these. 

The undisputed protagonist of all the pages of this site is none other than the content. After all, in a news site, it can’t be otherwise. 

In short, "mobile first" is a design philosophy that is certainly not suited to self-aggrandizing, self-absorbed or self-centered clients, because it's about removing every little element that distracts the user from their goal, and often these little elements are there because someone wants them, and that someone is usually the client. 

So, a "content first" approach puts the user at the center of everything, as usual after all, and forces us to ask what's important to them, what they're looking for, how they behave when they use the responsive site or app we're designing, and this will sometimes lead us to designs that are so optimized that they require a mobile responsive version that is different, and sometimes very different, from the desktop one. 

Yes, I know: it’s a mess of epic proportions. 

But the good news is that we're just getting started. And since we have so much about content first, it's really time to start talking about content. In the next chapter. 

Writing for mobile

We designers have this tendency to snub text.

We care about colors, illustrations, alignments, parallax effects; but for us, text is that thing that has to fit into the grid we have provided. And if it doesn’t, well, that's the client's problem.

Over the years, I've abandoned this utopian vision, especially since I've had to design sales landing pages for my services. So let's stick to the facts. And whenever we talk about facts, we have to quote Jacob Nielsen, the usability guru, who says this: it's more difficult to understand when we read through a cell phone than on a computer screen. How much harder? 108% harder.

But what does difficult mean? It means two things.

Less context

One, in the initial moment, when we haven't scrolled yet, we have less text to read on mobile than our desktop counterparts. Less text means less information, less context: are we reading a headline or a subheadline? What will come after the paragraph I'm reading? Is the image linked to this text above or below? Having less context means we have to interpret more, and interpretation, since it is subjective, can lead us to error.

Using memory more

Two, the mobile user has to do a lot more scrolling than a desktop user and will have to rely on their memory to remember what they read before and connect that information to the text they're reading.

The longer the page is, the more information they have to remember, and if by chance there is a link that goes to a more in-depth text and then back again, the user will have to remember where they came in.

In general, therefore, we can say that with a cell phone in our hands, our brains flit around more, and by flitting around, some pieces are lost along the way.

For this reason, our task is to make sure that the space used on mobile is optimal and avoid filling it with unnecessary or redundant information. On the contrary, a good text must be direct, concise and formatted already knowing that it will not be read but scanned by the inattentive eye of our average user.

But how can we make a text easier to read in concrete terms? Let's take a few examples.

Wikipedia

I'm sure you've seen a Wikipedia detail page thousands of times. We'd be tempted to say that the mobile version of a detail page should show the main column first and then the sidebar, as indeed most sites do, right? But no.

The Wikipedia page on United States.

The sidebar is the first thing we see in the responsive version, and this is because it condenses in a very schematic way the key data of what we are going to read next.

But that's not all: after the introductory text, all the headlines on the page turn into what's called "drop-down menus", which are closed menus that must be opened from time to time via a tap.

This way, we display content efficiently, already knowing that the user will NOT read the page, but will scan it. This is the key mental shift we need to make.

The New York Times

The New York Times, like so many other newspapers, knows this problem well.

An article on nytimes.com

That's why, right after the headline, it inserts a subheading. As if that weren't enough, right after that there is a bullet point where we find "everything we need to know", which is exactly the title of this section. Finally, we have another title, then the image, and only now – now that probably only the author of the article and some of their relatives are still reading – does the actual article start.

IMDb

IMDb is a very famous site that collects virtually every movie in the world, showing trailers and reviews. The web page shows a main column with the video, a sidebar with the movie details, and then a single full-width column showing other content.

The desktop version of IMDb.

The mobile version of IMDb.

The description is deliberately cut after the first three lines, because we know that only a small percentage of users will read this text, while all the others will stop before.

Giallozafferano.com vs Allrecipes.com

The mobile version of a Giallozafferano.com detail card presents the history of the dish instead of the ingredients. So let's imagine ourselves in the kitchen, our hands dirty with flour, the pot boiling: what are the chances that I want to read the history of a dish instead of how it is prepared?

The site GialloZafferano.com begins with a long description of the history of the dish.

This aspect is well known to Allrecipes.com, one of the most clicked-on recipe sites in the world. Between the two sites, there is a substantial difference in the way the recipes are described: in one, we have steps well marked by titles and icons, in the other a dense text that doesn’t ever seem to end.

Now for the litmus test—ready? Let's put ourselves in the shoes of someone who has to read a passage: we take our eyes off the phone, we start chopping, I don't know, an onion, maybe we cry a little, then we go back to the recipe and want to reread from where we were. Which of the two layouts in the screenshots achieves this goal more easily?

On the left Allrecipes.com, on the right GialloZafferano.com. Which one is more readable on mobile?

In short: thinking about text formatting means choosing whether to use titles, subtitles, bullet points, how much text to show and how much to hide. These are choices that, in my experience, are left most of the time to chance or, even worse, to the developer's whim, while actually they are details that can dramatically increase the length of the average page session.

To recap

From the examples we have seen, we have learned that:

• It's better to put the fundamental points of the content we're writing first, and put the less essential or more verbose ones only afterwards, as we've seen with The New York Times;
• Wherever possible, it is good to hide content, and sometimes only the part of the content that we consider non-essential, and allow access to it with a voluntary action by the user. We have seen this well with Wikipedia;
• We should always put ourselves in the shoes of the end user, even simulating the environment or conditions in which they are. We must force ourselves to judge our layout only according to the way the user makes use that content, and not according to our way. Only then can we be objective enough.

One action on one screen 

We mentioned that mobile browsing is often fragmented. 

The user has little time to analyze the whole page, and for this reason, complex operations such as a registration, an advanced search or filling out a form could be a source of many headaches. So maybe we give up there and then, we say "I'll do this when I get home", and then, once home, we kill ourselves with TV series on Netflix. 

That's why the most complex actions on mobile should be rethought from the ground up, and we can define the best technique for doing so with the expression "one action on one screen". What does that mean? It means breaking the mental process into many steps, even at the cost of channeling the user into a very long process, but which has a very precise feature: that of asking for only one decision, and therefore only one action, per single screen. Let's see some examples.

LinkedIn onboarding

The onboarding process, that is the set of data that the user has to enter to be able to try or buy a product or a service, is certainly one of the most delicate moments and the one that deserves more attention during the design. 

The LinkedIn onboarding process is divided into as many as nine screens: 

• In the first one, we are asked only for the email, probably to check that you are not already a registered user.
• In the second one, we are asked for the password: I want to point out that they could have included the email and password request in the same screen, and yet, no, they didn't. First just the email, and then, if the email is verified, the password field appears. The reason? Greater cleanliness, "that's all". 
• In the third one, we are asked for name and surname.
• In the fourth, we have to pass a security check.
• In the fifth, we have a welcome message.
• In the sixth, we are asked the type of work we do, and only after choosing the most recent qualification are we asked for the type of employment and the company. Again, they could have shown the three things together, but no, they didn't.
• In the seventh, we are asked for the location.
• In the eighth, for our photo.
• In the ninth and last screen, for the password confirmation.

Nine steps. There is no technical requirement for us to divide this information into so many screens, other than to lower the user's stress and help them get to the end.

Airbnb Search

But while it might be obvious to break down the steps in an onboarding process, there are those who have gone further and taken one of the absolute most delicate moments in the user's customer journey and broken it down into many small steps.

Searching for an apartment in the responsive version of the Airbnb.com website.

This is the case with Airbnb, whose search is certainly a source of income for the platform: statistically, the more users complete the search, the more they will find homes they like and therefore end up booking more. That's why it can't be left to chance on mobile, and it is broken into four steps: first you tell me where you want to go, and 100% of the screen is dedicated only to this decision, then you tell me what you're looking for, then the check-in and check-out dates, then how many people, and only then does the search really start. This choice is by no means obvious, and in some ways counter-intuitive: we increase the number of steps we make the user take instead of compressing them into one or two steps at most.

Booking on The Fork

The Fork's native app does a similar thing when the user decides to book a table: it takes me down a path made up of four steps where I'm asked for the date, time, number of people, and then the booking confirmation. 

The booking process in The Fork app.

Once again: this information could technically be placed on one or two screens, but the problem, as often happens, is not technical, but following the user's mental scheme.

Think carefully about the block of information to be presented in the single screen. This U2 supermarket app also follows the same logic as The Fork, but, unlike the previous example, here we see both the day and time in a single screen. 

And it's only right that it should be. 

The user who needs to receive the groceries at home might need them in the afternoon, but if the available times are not compatible with their schedule, perhaps they might decide to postpone until tomorrow, or the day after. 

In short, your choice does not depend solely on the first available day, but also on the schedule. That's why the two pieces of information should be presented together. 

The grocery reservation process in the U2 app.

Momondo

Momondo.com is a website for booking flights by choosing from many different companies. 

The homepage of Momondo.com.

On desktop, we have a complex form, where we have to indicate the departure city, arrival city, departure date and return date. This information is all part of the same logical block. Once all of them are provided, the site shows us solutions. 

On the mobile app, the experience is very different. 

In the first screen, we have to confirm that we want to choose a flight—this is because the service also includes hotels and rental cars. 

This is for all intents and purposes an extra tap that the mobile user has to perform, a choice that may not have been easy to make but that probably follows the client's business goal, which is to extend the search to more than just flights. 

It must be said that the app makes up for the extra tap on the next screen: first it locates my departure city, saving me that tap. After that, the only thing it wants me to pay attention to is the question: where do you want to go? As you can see, there is nothing else, I am forced to answer only this question. I choose the city, and only now can I choose the dates. 

The flight selection process in the Momondo app.

The second part of the experience is also different between the desktop and mobile versions. On the first, the experience is more direct: I see a list of results, click on the call to action and end up on the company's website. That's it, that's all there is to it. 

On mobile, I am prompted instead to go through an intermediate screen. Why does this happen? Probably because the site knows how important it is for me to make an informed choice. Not only that, but once I've chosen my flight I would go outside the app and end up on sites full of information and maybe not optimized for mobile. 

For all these reasons, the people who designed this app thought it better to force the user to linger a few more seconds in the app, at the cost of delaying their purchase funnel by one tap, than to make more users go to the next step without them being truly convinced about their chosen flight. 

To recap 

The lesson that we must take home is this: we must not be afraid to increase the number of steps to be taken, provided that the number of screens helps the user focus on the single micro-choice. 

Above the fold, below the fold 

Does the mobile user scroll? To answer this question, let's take a step back in time. Between the 90s and 2000s, there was a strong debate about this, and people thought that most users were not used to scrolling. After all, we were coming from years of installing software from prehistoric CD-ROMs, where there wasn't much scrolling. 

This debate had led many designers to focus on the so-called "above the fold" space, that is, the space we see on the screen before we even do any scrolling. 

Nowadays, after more than 20 years of internet use, we can safely say that the user is perfectly accustomed to use their own finger on the mouse wheel and scroll the page. 

This is even more obvious on mobile, and Facebook has given us a big hand in this, because everyone wants to see the next post, and the act of moving the page has now become a daily workout for our thumbs. 

In light of all this, why would we still care to talk about concepts like above the fold? Because any user, on web or mobile, judges the value of a page within the very first seconds of opening it. And if we add the fact that half of mobile users start scrolling within the first 10 seconds of loading a page, that means a lot of mobile users make an opinion based on what they see without having touched anything on that page. 

So, the content above the fold remains a crucial area for any responsive website or native mobile app, and we need to make sure that within it we can find all—and I mean all—the essential elements that the user needs in order to perform the main action that we want them to do.

But let’s leave mere resolutions for the New Year, when we're still intoxicated by booze and panettone—instead, let’s get some concrete examples here. 

Livechat

Livechat is a service that gives you the opportunity to assist your customers in real time, and the part above the fold is a masterpiece of symmetry: a title, a subtitle, a large space dedicated to the call to action, and at the bottom, almost off-screen, elements that convey confidence. 

The Livechat.com website, in the mobile version.

That's all you need: everything else on the page is made up of all-too-expendable information compared to what we want the user to do: sign up for the 14-day free trial. 

Walmart

Similarly, Walmart offers a product tab that has everything: a title, ratings, product image, price and a buy now button. 

A detail page of the Walmart.com website.

However, there are at least three elements here that could be optimized: the top blue area is not essential for purchasing, yet it is very noticeable; there is poorly used negative space; the side feedback button is unlikely to be used on mobile.

Eventbrite

Eventbrite, whether on its responsive website or native app, is similar: the detail tab of an event has everything I need to decide above the fold: title, image, price, date, location, call to action.

The detail tab of an event in the Eventbrite app.

Weather sites

What is the main goal of the user browsing on mobile weather sites? Well, if we look at weather sites themselves, the answer would seem to be: it depends. 

CBSlocal.com shows a very crowded page with a featured article. Weather.com doesn't do much better. Is it right, is it wrong? We don't know the stats of their site to make a final judgment; what we do know is that not everyone thinks this way, and whoever designed nbcnewyork.com thinks instead that those who visit a weather site are doing so to know the temperature where they are, period. 

On the left weather.com, in the middle cbslocal.com, on the right nbcnewyork.com. Which of the three communicates what the user expects to find?

That's why 50-60% of the space above the fold on nbcnewyork.com is dedicated to that, with no other unnecessary information. 

Google Play

Native mobile apps are thought up like that too: let's take any Google Play detail tab: above the fold we have the name of the app, the name of the producing company, three statistics that should serve to support the main call to action which is downloading the app, a gallery, and last, only last, the app description, which is visible only after a tap.

Google Play devotes much of the space to the app's title, to the main call to action and some statistics.

Observe how much screen space is devoted to the key information. If you think about it, this information could have been arranged more evenly, but it's not the amount of content that dictates the construction in this layout; instead, there's a definite hierarchical choice here about what's essential for the user to actually read. 

My fold is not your fold

There are 4,000 new screen sizes introduced in the market every year, which maybe have very small differences in terms of pixels, but which are still relevant when we take each pixel into account to decide whether or not to put content above or below the fold. 

From left to right: the Yoox app, Zalando, Zara, Asos. Each with their own vision of what goes "above the fold". 

So, be careful not to base everything on the "bigger than big" iPhone or the gigantic Android phone that you just bought as a tech nerd, because chances are that's not the most popular screen size among your users. Otherwise, you'll end up making the same mistake as the Zalando app, which, because of a handful of pixels, fails to show the main call to action above the fold on my smartphone, which is like stumbling to the ground a few steps from the finish line.

Touch Hierarchy

In this chapter, we’ll talk about thumbs, and thumbs, my dear listeners, are a wonderful thing.

They allow us to set our aim when we need to hit a nail with a hammer (not that I have any direct experience with that), to hitchhike and express an unequivocal sign of victory and approval; and, less importantly, it seems that the thumb is the finger that differentiates us from other animals.

All these advantages had to come at a price, and the price is: the thumb has a very small range of motion. This wouldn't be a big deal if it weren't for the fact that, as we've seen, 85% of users use their thumbs as a very high-precision tool for navigating pages. And that, my dear designer, changes everything we knew about the arrangement of elements on a page.

To summarize, in the desktop world we could say that there are two criteria we use to arrange the elements on a page.

• The first is the logical one. We ask ourselves: What is the user looking for? What is the information they have to read in order to decide to go on reading?
• The second one concerns the way the user is accustomed to reading the information. We can call this way of arranging the elements the "visual hierarchy", since we give a precise order to the elements arranged on the page.

Instead, on mobile, what dictates every law is the way we touch the screen, which is generally our thumb. And when we grab a cell phone, our thumb starts from the lower left or right corner and covers only a part of the screen: this is where the user is more likely to use their thumb to tap on some element.

Certain areas of the screen are not suitable to be reached by our thumb.

That's why this is the area where we always find the main buttons, for example the call to action, primary navigation or featured content.

The part in green is always the one where we find the main actions to be taken.

In general, the entire top part should be dedicated to informative content, where, if the thumb doesn't reach, at least the eye can; or to areas that can be tapped, but are not related to the business objective.

To the topmost area, the one that is most inconvenient to reach, we must delegate elements such as search, hamburger menus, notifications, the profile or the back button. Or even no content at all: if we have nothing useful to put there, we must have the courage to put nothing, as Airbnb's advanced search does.

Every time the user taps on these buttons, they will have to make an unnatural movement of their fingers. Of course, we're not asking them to sprain their wrist, but in any case, this kind of movement shouldn't happen over and over, otherwise they'll soon get tired of our site or app.

There's something to be said for the fact that while we're used to seeing tab menus at the bottom in many native apps, it's much less common on responsive websites, though there are exceptions.

The bottom navigation bar in some responsive sites.

Finally, there is one last detail that we have omitted until now, but that we should take into consideration. Our friend the thumb is not only the finger with a more limited range of movement than all the others, but it is also the biggest.

We discuss this in the next chapter.

Size matters

If in the desktop world we like to work on fine details, with those cute, shiny little keys, on mobile, we don't. On mobile we have to go all the way, ignore the fact that we ourselves have thin, tapered fingers, stop regretting our alternative career as pianists and, ladies and gentlemen, design everything for ‘him’: the fat finger. 

Yes, the tool with which the user makes use of our interface has variable dimensions that have nothing to do with technology but with Mother Nature. That's why the rule to follow is: design for the biggest thumb your mind can imagine. Okay, but how big? For lovers of exact data, the number recommended by Apple's guidelines is 44 pixels, while for Android we’re talking about 48 pixels, but I recommend you to double that as a minimum. This is because most of the thumbs out there are the equivalent of 72 pixels. But I'll tell you more: when we press a button exactly as wide as our thumb, we end up hiding it completely, and this is bad because we don't have the certainty that we are actually pressing the right thing in the right way, especially if we are using a digital interface where there is no other physical sensation that can make us understand what we are doing. 

But, beyond the numbers that make little difference in the end, the point is that our goal should be to make the feel of touching pleasant and comfortable. The user shouldn't look at our button and be afraid of making a mistake even for a second, because if that happens, we're driving down the conversion rate. And since at the end of the day what we want from the user is almost always an act of trust—an email, a purchase, a booking—we must do everything we can to never undermine the relationship we've created with them. 

Let's take a few examples. 

There isn't a single button on Airbnb.com that is not fat thumb proof.

Once again, Airbnb does a great job. Throughout the site, there isn't a tappable link that isn't in fact a button: starting with the huge button at the top, the cards, the bottom navigation bar. The "forward" buttons during search teach us that when you can't make a button high for lack of space, stretching its shape can help make it more convenient. And even when we go to the map, where the pins start to be difficult to tap, the bottom card navigation solves this problem. 

Another good example is the Duolingo app: on this app, everything is gigantic: the icons at the bottom, the elements on the page, the buttons. 

Learning a language is something that makes one easily tired: for this reason, the interface can't afford any kind of inconvenience.

Try to miss a tap in the Duolinguo app if you can.

There are negative examples as well.

The onboarding of the Wikipedia app features a forward button that is too small and too close to the edge for comfort. 

The "register" and "sign in" buttons in the pocket app are too close together. 

 In these examples our thumb (red area) is much larger than the tappable area, to the point of encroaching on other tappable areas. 

Sometimes, the use of such skimpy tappable areas is a strategic choice, such as YouTube's "Skip ad" button that intentionally tries to trick us into making a mistake.

But before you start creating interfaces full of 72-pixel icons, I've got a piece of slick designer advice: we can't stick to this rule 100% of the time. So what do we do? We make a distinction between the most used and less used buttons, between those that are closely related to the conversion of the page, for example the call to action, and all the others, and this means that there are no calls to action that do not respect this rule. 

Another solution is to increase the tap-sensitive area, preventing possible user error. For example, instead of putting a giant search icon, we can always keep it small, but we make sure that the tappable area is bigger than the visible one, and this is technically easy to achieve in both responsive sites and native apps. 

The next time you need to create a button, ask yourself how important it is to the client's business objective or how much that button will be used relative to the others: the greater its importance, the more dominant it should be.

In short, in mobile, size matters, but in some cases, even when faced with a large button, the user could still be misled. And this happens when there is another button next to that button. We'll talk about that in the next chapter. 

Beware of overcrowding 

For the series "when it rains, it pours", not only are the small buttons the least used, but when the user taps on an even slightly overcrowded area, the risk of tapping on the wrong link is very high. And the problem is even more subtle than that, because even if the user manages to avoid the error, just having to make an effort to get the right link in the center is already a UX problem, since we are conveying a sense of discomfort. Any examples?

 My finger (in yellow) VS the Italo Treno app. 

Forms are typically the places where you risk having too many things at once, as in the Italo Treno app, for example, where we have three tappable areas one below the other, of varying sizes and even characterized in a different way, so as to make it unclear what is tappable and what is not. We can't afford this; every time the user has doubts about how and which area to tap, we will have done our job badly. As the second screenshot demonstrates, where the "Pay Now" button is dangerously close to the mandatory checkbox, despite the fact that it's certainly the most important call-to-action in the whole app and therefore deserving of more attention.

Instead, a great job is done, if we are to stay on topic, by the Trenitalia app, where any tappable area has a great margin around it, making navigation very natural and pleasant.

In the Trenitalia app, each element has a good margin separating it from the other tappable areas around it. 

Nell'app Trenitalia ogni elemento ha un buon margine dalle altre aree tappabili attorno.

Maps

Maps are the undisputed queens when it comes to overcrowding. When we show too many pins or points of interest within a map, it becomes really hard to untangle the pinch zoom and tap. And if maps can be a problem for native apps, they are much more so on a responsive site. For this reason, on mobile, the map mode is often an advanced feature not reachable without a few more taps. Or even absent, as in The Fork.

A study by the usual Jacob Nielsen leaves no doubts about it: despite the fact that the maps interface is a "sexy" one, during field tests, users who used the "list" mode completed the tasks assigned to them more easily. 

The lesson we’ll take home, then, is: maps are nice to look at, but a little difficult to navigate, and therefore should be used with caution. 

The tablet version of the Zoopla app has the task of showing us ads for houses for rent or for sale. Knowing the exact location is one of the most important data when searching for a house, yet it abandoned the foreground map view in favor of a list view, which allows one to view more apartments with less scrolling. This is a brave move that breaks the habits of the average user in favor of a user experience that, statistically, will lead the user to find what they're looking for faster. 

To the left, the list+map view of the Zillow rental app, on the right the list of the  Zoopla  app

Big Pictures, Small Screens

On desktop, we're used to using huge images: think for example of all the hero images you've seen on virtually every site you've entered today. And the solution adopted by a lot of designers to make a site responsive is to simply resize the image and make it fit inside a smaller screen. This may work on paper, but in practice it's not so obvious that it does.

A smaller screen means less space for both the image and the text. If the text is contained in the image, on mobile the size doesn't remain constant, so we end up with white text on a black background that ends up on a white background, or text that covers the product to be sold, or images that on desktop have a good balance and on mobile are chock full of text, or images that on desktop present a detail, for example a guy surfing, and then lose it on mobile—and, well, I don't know about you, but to me it seems conceptually very different to show a guy surfing than an image of the ocean.

Another often underestimated problem is that images cause the page to be longer to scroll, bringing down the main content that is important for the user to read. 

Some issues with images on mobile. 

Sometimes it can become difficult to figure out which text the image belongs to, whether to the bottom one or the top one, and the user has to resort more to memory to make this connection.

In short, that's why images need special attention when we make a design that will end up on different sized screens. 

And what are the possible solutions we have available?

• The first one: when we consider a mobile layout, let's ask ourselves: is this image valuable? Because if not, then on mobile it should be removed. This is what happens on thefork.it, easyjet.com, Ebay, Zoom.
• The second: use images that contain a lot of negative space. 

This is what happens on intesasanpaolo.com, siteground.com, adobe.com, office.com.

A great way to implement negative space on Office.com.  

• The third: avoid text inside an image altogether and use two columns at 50% of the screen, as avaya.com and ads.google.com do for example.
• The fourth, which is probably the best but also the most time-consuming in terms of design and development: change or simplify the structure of the page on mobile. This is what happens on udemy.com, afronation.com, auditorium.com, istockphoto.com.

In short, every time you put an image in a layout, ask yourself what to do with it on mobile: whether to transform the layout, use a simplified version, or remove it. 

   Thefork.com  and Udemy.com  change the layout, repositioning or removing the image altogether in the responsive version. 

Never make them use the keyboard

Okay, let's start with this simple premise: writing on a cell phone sucks. 

I can't find another way to say it: it's uncomfortable, it often forces us to use both hands, we have to concentrate a lot, isolate ourselves from the physical environment we're in, and yet it's easy to end up making mistakes. 

That's why when we design a mobile interface, we should avoid the appearance of the virtual keyboard as much as possible.

A nice principle which, as usual, clashes with reality: for example, how do we make the keyboard not appear if the user has to perform a search? We probably can't, but we can certainly limit its use. How? Let's take some examples, as usual. 

We can pre-fill the fields of a form with values that are likely to be those that the user will choose. This is how Eventbrite works, which during the search for an event helps us with a pre-selection for the days that might interest us. 

Thefork.co.uk suggests searches not only based on the ones you've performed recently, but also the ones that are most popular across the platform, and so does Skyscanner or Airbnb. 

The Deliveroo app inserted a button that reads our GPS to insert the location inside the form field. 

Always remember that a suggestion that's even potentially useful is always better than no suggestion at all, and this applies to the Ikea app as well, where the example being suggested to me doesn't solve the typing problem in any way. 

 On the left is Eventbrite; in the middle is Skyscanner.com, on the right is Ikea's app: here's how they handle user search. 

So, try to complete these fields with the data that, statistically speaking, may be relevant to the user. I endorse the concept of "statistically relevant to the user". 

The Italo Treno app, in the search for the departure station, tries to help me by offering a list of stations in alphabetical order. But if the first suggestion I get is "Agropoli", a town of 21,000 inhabitants where the Italo service doesn't even go, instead of helping the user, we are leading them into error. Better instead to show a list of the most used stations in the app, at least until we know the GPS position of the user: this is undoubtedly the most useful data that would allow us to suggest interesting stations for the user. 

For the same reason, it’s a problem if a user selects stations where the service is not provided and arrives at a page with no results. In this case, instead of showing an empty page, we could advise the user to widen their search or suggest alternative stations, perhaps as close as possible to the selected locations, rather than forcing them to go back and repeat the search all over again .

If I tap the first two results in the Italo Treno app I'm going to hit a dead end. 

The registration process

Even if using the keyboard on mobile sucks, there are certain sections in an app where we just can't avoid it: such is the case with registration. And while on one hand an app needs to always have new registered users, on the other hand, the user wants to be able to browse the contents without having to give over their data, especially if it’s in an initial phase, when before giving us their email, they want to understand if it's really worth it.

What do you do in these cases? Let's find out together with nine simple tips. 

1. Choose the right time

Especially in native mobile apps, we can be tempted to ask the user to register right away. This can make sense for apps that are used by millions of users, like Facebook, Twitter or WhatsApp, but if your client doesn't represent such a famous brand, then asking them to register right away is like asking a girl you just saw at a bar for her phone number. I know people who succeed in this feat after all, but in our case we need a lot more users for the app we're building to be a success. That's why the best time to ask the user to sign up is one moment before they take an action. 

Do you want to save a piece of content among your favorites? Sign up.

Want to send a message? Sign up. 

Do you want to complete your purchase? Register now.

2. Emphasize why you need to register.

The registration request is the most delicate moment of all, and also the one in which the user might be disappointed or uncertain. To counter possible doubts, it can be useful to remind the user why they should register. It's fine to do this with just a few words or a link to a more in-depth screen.

Ryanair, Easyjet and Tumblr explain why we should register. 

3. Design a streamlined procedure

Make the registration process as streamlined as possible. For example, using social logins: the user can complete the registration with two or three taps instead of typing in their email and password. Another very effective method is to request a phone number, as Dice.fm does. The mobile number is an identifier of an individual user, and at the same time one of those things that is almost impossible to forget. 

4. Use only the necessary fields 

Insert only the fields that are strictly necessary for the registration on the screen and remove everything else. And what are the fields really necessary? Usually, the email and password, or rather, if we want to be precise, first the email, and only after filling this field, if that email is really new and not an already registered user, it makes sense to show the password field.

5. Don't ask for passwords that are too complex

Security is fine, but be careful not to set the parameters too high and end up asking for complicated 10-digit passwords with special characters, because the more complicated the password requested, the more stressed the user will be in having to create a memorable one. And this can make all the difference if we're not talking about an indispensable or ultra-famous site.

6. Give instant access

Once the user enters the data, the first thing they want to do is sign in. You can avoid having the email confirmed, like Udemy.com does.

Slack.com makes a bold choice: in order to simplify the registration phase, it doesn't ask for any password during the registration phase, so the user can enter the system simply by clicking on an email confirmation link. During the login phase, the user can not only request to change his password, but also receive a so-called "magic link" via email. Once again, they can log in without having to remember any passwords. 

7. Divide the registration process into several steps. 

We've seen this before with LinkedIn: get the user to focus on one action at a time so you relieve their stress and lower the cognitive effort. 

8. Remove all distractions

When the registration is open, there should be no standard navigation other than to move from one step to another, if those exist. Leave only the fields that the user must fill in and the forward or submit button. There are usually two exceptions: the login button and a possible help button. 

9. Choose the right keyboard

Finally, if we really have to make the keyboard appear, let's make sure that the most relevant one appears: for example, the one with only numbers, or containing the main symbols for email addresses.

In short, the moral of today is this: we need to be aware that every time the virtual keyboard pops up on our user's phone, we are creating a moment of stress, panic and uncertainty at best. 

Try to make it appear as little as possible and, when you have to, create the simplest process possible. Good luck. 

Responsive web vs app nativa

I invite you to perform this test. Go to Imdb.com from mobile. Done? Okay, now download the native app. Done? How many differences do you notice between the two versions? Very few. And the question is... what's the point of using a native app when the responsive website does the same thing? I knew it: you started this chapter thinking you knew the difference between responsive website and native app, but now you're not so sure. 

But what are the benefits of a responsive site?

• Available to all

A responsive site is available to everyone. You go to Google, type in the name of the site and browse. You don't have to download anything, you don't have to worry about whether you have enough memory to be able to download the app, you don't have to wait for the app to download: these are no small things, since, as we said, the mobile user is always in a hurry.

• It’s economical

A responsive site is significantly cheaper than a native mobile app, both in creation and maintenance. 

Why do we decide to install an app?

If a responsive site has so many advantages, why then should we create a native mobile app? We find the answer to this question by looking at the apps we have installed on our cell phones. Let's ask ourselves: why did we install them? Maybe we've installed the bank app, because it's easier to check the transfers that have arrived, or the food apps such as Just eat, Deliveroo or Thefork because, since we make restaurant reservations at least once a week, it's easier for us to do so from the native app. Or we installed social apps: Facebook, Instagram, Tiktok: their website is so full of features that we find it easier to use them on a mobile app. Or the weather apps: in the morning, with your eyes barely open, do you want to type in the URL of your favorite weather site? And those of newspapers: for these as well, if you consult them daily, you may feel the need to download the app. 

When we start going to a website more frequently and want to read its pages every week or even every day, the efficiency with which we can use it becomes a feature. It takes on an important value for us, and we feel a strong need for it. 

The more times we tend to use the same site, the more we begin to expect speed, rapidity, ease; we don't have all this time to waste, and we certainly don't want to be treated like any other user. 

That's why few sites really need a native app, but those few that do have the opportunity to deliver a high-tech jewel to their "superusers", the users who know that brand, that website, who maybe send an email if something goes wrong, if an image doesn't load, if the site goes down—in short, they become part of the family, of the company, the beta testers.

When it comes to a native app, efficiency is a feature – don't forget that. 

Why do we uninstall an app?

In designing a native mobile app, our task is to create a virtually perfect layout, where every pixel, every space, every text has the task of providing the user with only the information they were looking for in the fastest way possible, and this is worth much more than on a responsive site, because the user will not forgive us for slow loading, too many pieces of information, a hard-to-reach button.

Am I overreacting? I don't think so. According to a study by statistics company Localytics, 26% of apps are only used once before being uninstalled. And what are the main reasons why a user uninstalls an app? Let's go through them in reverse order of importance.

7th place: we don’t give alternatives for registration

In the seventh place we find this problem: we don't give good alternatives to the user who wants to register. For example, they can do it only through social media logins, or, on the contrary, only with the email field. Each user has their own preferences and it is good to let them choose the registration method they prefer. 

6th place: we don’t guarantee privacy

In sixth place we find privacy concerns: isn't this app asking me for too much personal information? Why does it want to know how old I am? Why is it asking for my credit card, bank account or any other sensitive data? That's why many apps offer screens that explain their position on user privacy. 

Apps often inform us of their position regarding our sensitive data from the first screens after logging in.

5th place: too much advertising

Fifth place: advertising. This is true for responsive sites as well, but on a native app it's not acceptable: I downloaded the app, wasted my precious time waiting for the download, and now you're trying to make me lose more time if I make a wrong tap? Free games base their business model on this: on the one hand, the user has a great desire to play, on the other hand they hate any interruption by advertising. And if the desire to play becomes too great, then they will be willing to pay to access an ad-free version. But this model doesn't only apply to games, and some other apps, for example weather apps, use the same mechanism. You want to remove the ads? Then pay me. 

4th place: bad UX/UI

In fourth place we have bad UI/UX and I'd say we've already talked about this at length, so let's get right to the next point and move on to the top three. 

3rd place: loading times

In third place we have loading times. And you'll say: but I'm a designer, wait times are not my problem! Well, it’s not like that. Wait times are part of the user experience, and even if we can't design a wait time, we can talk to the rest of the development team and ask for acceptable wait times for the end user, obviously those which are also realistic for the technical framework we're working with. The only thing worse than long loading times is an app that crashes too many times: it may seem strange to you, but this is also part of the "user experience", and therefore the responsibility of whoever is in charge of this. We'll talk in detail about loading times in the chapter about splash screens.

2nd place: onboarding too complicated

In second place: onboarding that's too difficult. 68% of users delete the app if it's asking them for too many steps or too much information to start using it. As we said, the mobile user is in a hurry, has a specific goal in mind and wants to reach it as quickly as possible. There's no compromise on this: it’s either that or the user will download another app that does the same thing.

1st place: push notifications

And in first place in terms of reasons why a user uninstalls an app, we have push notifications. And we’ll talk about that in the next chapter. 

Push notifications

The perfect friend is the one who lets you talk, who listens to your complaints without a word, and who orders the hamburger of your choice without even asking for what you want. 

Similarly, we also expect something like that from an app: someone who knows what we like and offers us only what we need. 

However, like any human being, every now and then our app friend gets carried away and starts suggesting us something we never wanted, at a time when we just wanted to relax: we're talking about push notifications. 

Push notifications are the number one feature of native apps that every marketer in the world loves: the idea of bombarding the user with messages telling them what to do, whether to tap, buy or do something else; all while sending a message at no cost. If this isn't marketing heaven, tell me what is. 

But not all that glitters is gold, and by now you should know that when we force the user to do something we want them to do and they don’t, the relationship is bound to break down. And when we affect something like that relationship, which is the cornerstone on which every aspect of our work is based, then we really risk compromising everything. 

But what is a push notification? It's a message that sits in the middle or at the top of the screen and takes top priority over anything else, for which the user is forced to stop, read, get it out of the way and continue what they were doing. 

And as a user once put it on Twitter, most elegantly, "If my ass is vibrating, it better be worth it".

It has to be said, though, that while a notification may be too much for one user, for another the same notification might happen right at the right time and convince that user to buy in earnest. So, the question is: what's the right way to ask the user if they want to accept to receive a notification, and which are the cases in which it's better to send one? Let's look at some examples, as always. 

During the onboarding phase, The American Rodeo app helps us decide if and what notifications to receive.

During the onboarding of "The American Rodeo" app, before showing us the classic popup where you have to accept or not whether to receive notifications, we are asked which notifications we want to receive: if we don't want any, or if we want those from a particular category: for urgent notices, or for example when an event is about to start. If we make the user choose which notifications they want, also giving them the possibility to specify "none", we could increase the percentage of satisfied users, because they will receive only the push notifications they asked for.

In the LinkedIn app, if we started the onboarding process but didn't finish it and we close the app, after a few days we get a notification reminding us to complete it. 

The Zalando mobile app reminds us to return to the app to purchase products for any special occasion, for example when Valentine's Day is approaching. Obviously, when tapping on the notification, it makes me go to the Valentine's Day category, and certainly not to the homepage of the app. The user would never forgive us this inefficiency. Note also the use of emojis, which we find in many other apps.

The One Football app, as it knows our favorite football team, since it's one of the first things it asks us when onboarding, sends three types of notifications: one when a game with our favorite team starts, one if someone scores and one when the game ends. 

And for this reason, the world of fans or followers fits very well with push notifications: Twitter sends us updates on the people we follow, and Spotify does the same: after all, if we are fans of a singer, we want to be the first to know if he has released a new album. Netflix alerts us that a new season of the series we watched is out. 

What can we learn from this roundup of examples? That the best notifications are the personalized ones, that is, those based on our tastes and preferences. Sometimes we can infer these preferences based on the user's actions: if I've seen the first season of Breaking Bad, I'm likely to want to know when the second one will be released. 

Other times, notifications are based on specific time elements: a special offer to grab because it's Valentine's Day. 

Other times we have to explicitly ask the user: if you tell me you like Juventus, then I'll send you push notifications about this team. To get maximum clarity: before I send you a popup about accepting those notifications, let's be clear: do you want push notifications when new events start? Yes or no. Because if it's no, then I won't even show it to you. 

The initial choices we make in the One Football app  determine the notifications we receive afterwards. 

In general, we can say that the more notifications are based on the characteristics of those who receive them and the more we give the user even just the illusion of being able to decide whether to receive them, when and which ones, the more these will be appreciated and contribute to the success of your app.

What are the mistakes we should avoid? 

• Avoid making the popup to accept notifications appear without any explanation and, even worse, as the first thing when opening the app. After all, you've just downloaded an app, you have no idea how it works and if you're sold on it, so why would you accept to receive notifications just like that, sight unseen?
• Avoid irrelevant content, but as we know, what is irrelevant to someone may be important to someone else, so the solution here is, as we said, to send personalized notifications, based on the user's interests. 
• Watch out for the time the notification is sent. If you send one at six in the morning, and if the user is woken up out of the blue because of you, well, it's not just a matter of uninstalling an app here, it can even mean the end of a relationship.
• Avoid too many notifications. And what do I mean by ‘too many’? There's no exact number here, because it depends on the market the app operates in, how loyal the user is, how relevant the content they receive is to them. What we do know is that the average user receives about 46 push notifications every day. Make yours relevant, otherwise they will be lost among many others.