How to Avoid 9 Common

Mobile UX Mistakes

No one sets out to create a poorly designed app. Every project begins with high hopes and great expectations, but it’s amazing how quickly app design can start to unravel. Typically the problems with the user experience (UX) result from the accumulation of seemingly minor issues -- compounding imperfections that ultimately cause users to quit the app and never come back.

Many of these small mistakes emerge early on in the process, long before the visual design is even considered. Early decisions, like the initial feature set and how your backend system will work, can have a dramatic impact on the UX of the entire project.

This eBook explores nine of the most common UX pitfalls in mobile app design. It highlights the traps so that app developers know how to avoid them. But if you’ve made any of these mistakes, no need to worry. The eBook also explains how to overcome the setback.

Mistake 1: Not Simplifying The Feature Set

If you want to build a product that is simple to use, then creating a simple product is a good place to start. We tend to think of all the wonderful things our app could do, but then things get messy when we try to implement the entire list of possible features. So the trick is to plan everything you might want in the application, then pare down the list to only the most important items. This is sometimes referred to as arriving at your MVP, or Minimum Viable Product, but I prefer the following characterization by Dan Cederholm of SimpleBits: “Dream big, implement small.”

Analog as it is, for me it works best if I write everything down on paper and then circle the absolutely critical features. I do this rather WKDQ�FURVVLQJ�RXW�WKH�RSWLRQDO�IHDWXUHV��ΖW�VHHPV�OLNH�D�PLQRU�GLHU-ence, but if you pick out the mandatory features you will end up with a much shorter list.

When working from the short list of mandatory features you can set the bar for user experience very high. Then later as you add more features you can work hard to maintain your high standards.

The designers at 37signals say, “It’s better to build half a product than a half-assed product.” Cutting features at the beginning is the best way to start building a great product.

Mistake 2: Forgetting State

A few weeks ago I was trying to get some work done on my iPhone. Hunting for a particular piece of data required me to drill a few layers deep into the app’s navigation. Then, realizing I needed something from the web as well, I quickly switched over to Safari.

When I returned to this app moments later, I was shown the top-level dashboard. Wait, what?

:KDW�KDSSHQHG�WR�WKH�SDJH�Ζ�KDG�ZRUNHG�VR�KDUG�WR�ȴQG"�$OWKRXJK�no data had been lost, because the app hadn’t remembered my navigation state, I felt as if the app had wasted my time. It created a frustrated user.

Your app should always try to act on behalf of the user. It should remember the last screen the user was visiting so they can immedi-DWHO\�SLFN�XS�ZKHUH�WKH\�OHIW�R�ZKHQ�WKH\�UHWXUQ�

Remembering state can also work across devices. Since a single person may use multiple devices in which the apps sync between them automatically, then the user will expect the data to sync as well.

For example, if an Angry Birds player clears multiple levels on his iPhone, then he shouldn’t be set to the beginning on his iPad.

State is a prime example of a UX issue being heavily impacted by backend functionality. If you (or a collaborator) don’t have backend development skills, you might want to try a back-end-as-a-service provider that has

pre-built this capability for you.

Mistake 3: Not Using Finger-Sized Tap Targets

Literally the biggest thing you can do to improve the usability of your app is to increase the tappable area for every button. You’re design-LQJ�IRU�ȴQJHUV�DQG�WKXPEV��QRW�PRXVH�FXUVRUV��ZKLFK�KDYH�D�KLJKHU�pointing accuracy).

Apple recommends a minimum of 44px by 44px for any element with which the user is expected to interact. The same recommendation applies to other smartphone platforms.

Of course, this guidance doesn’t mean that the button needs to appear that large. The tappable area can extend beyond the visible borders of the button. This will help users avoid the frustration of trying multiple times to tap an element. Just be careful if you position several buttons close to each other. Make sure that your extra tappable area doesn’t overlap with other buttons.

Mistake 4: Overcrowding Views

If you are used to designing for desktop computers, you’ll be VXUSULVHG�DW�MXVW�KRZ�OLWWOH�FRQWHQW�\RX�FDQ�ȴW�RQ�D�PRELOH�SKRQH��Because the screens are so much smaller, and tap targets need to be larger, views quickly become overcrowded. The solution is not to make elements smaller. That will just frustrate your users. Instead you need to add more views.

Whenever I start designing a new mobile app, I underestimate the number of required views. I start out thinking it will be a relatively VLPSOH�DSS�ZLWK�IHZHU�WKDQ�ȴYH�views, but then the views start DGGLQJ�XS��%HIRUH�ORQJ�Ζ�ȴQG�Ζ�QHHG�as many as 20 views to handle all the necessary tasks (registration, IRUJRW�SDVVZRUG��VHWWLQJ�QRWLȴFD-tion times, etc).

But that’s okay. It’s better to add more views than it is to overcrowd MXVW�D�IHZ�YLHZV��'HGLFDWLQJ�DQ�HQWLUH�YLHZ�WR�VHWWLQJ�D�QRWLȴFDWLRQ�WLPH�LV�MXVW�ȴQH��-XVW�PDNH�VXUH�WKDW�\RXU�WUDQVLWLRQV�DUH�TXLFN��buttons are clear, and that it’s easy to get back to the previous view.

Mistake 5: Keeping The User Waiting Without Feedback

Users have very little patience with mobile applications. As a mobile app developer, you might be frustrated with a user’s impatience because you understand that some tasks are always going to be slow, especially when the user has a weak network connection or an older device.

If your app is too slow or feels unre-sponsive, it only takes a single tap of the “home” button before your user is gone and never revisits your app. Luckily there is an easy way to help your users become more patient: Simply keep them informed.

Typically the problems with the user experience (UX) result from the accu-mulation of seemingly minor issues

/HWV�VD\�\RX�DUH�WU\LQJ�WR�SRSXODWH�WKH�GDWDEDVH�RQ�WKH�ȴUVW�UXQ�RI�D�newly installed app. By default, iOS shows a splash screen while the app is installing. Instead of the generic splash screen, you could display a simple message with a loading animation that reads, "Installing ..."

That step alone will grant you several seconds of patience. If it takes longer you can buy more time by changing the message. Next set it to "Loading database ..." If you need even more time wait several seconds and update the message again. "Loading interface ..." will give you still more time. Change the messages to what makes sense for your application, but keep the user informed.

You see, the user is just worried that your app has locked up. No one wants to keep staring at a screen that isn't going to do anything else. By changing the messages it shows that your application is still working on their behalf.

Mistake 6: Displaying The Wrong Keyboards

Have you ever typed in a URL and been happy to see a button on the keyboard that has “.com” on a single button? That single button saved you three additional keystrokes.

That little shortcut is possible because we know what type of data is H[SHFWHG�LQ�D�WH[W�ȴHOG��VR�ZH�FDQ�FKDQJH�WKH�NH\ERDUG�WR�PDNH�WKDW�easier. This means that you can add an “@” button on the main keyboard for entering emails or showing that “.com” button for URLs.

There are actually HLJKW�GLHUHQW�NH\ERDUG�YDULDWLRQV�available to you on L26��:KHQHYHU�\RX�SXW�LQ�D�WH[W�ȴHOG�\RX�FDQ�VHOHFW�ZKLFK�NH\ERDUG�should be used to input the content. These range from the default NH\ERDUG�WR�QXPEHU�NH\ERDUGV�WKDW�DUH�HQWLUHO\�GLHUHQW��ZLWK�ORWV�RI�subtle variations in between. Look through the options and choose the RQH�WKDW�PDNHV�WKH�PRVW�VHQVH�IRU�HDFK�ȴHOG�

You can also choose the keyboards on mobile web apps by changing the LQSXW�W\SH��1RUPDOO\�IRU�IRUP�ȴHOGV�we use <input type=”text” /> and <input type=”password” />, but in HTML5 even more options are avail-able. The one you should use most often is <input type=”email” />. 9LVXDOO\�LW�GRHVQȇW�ORRN�GLHUHQW�IURP�a standard text input, but iOS and Android will automatically display a

keyboard with a period and an @ symbol to make it quicker to enter email addresses.

Mistake 7: Failing To Do Usability Testing (Or Ignoring The Results)

Typically when you develop an app you know the product so well that you can’t accurately judge how easy it is to use for someone experi-HQFLQJ�LW�IRU�WKH�ȴUVW�WLPH��<RX�DUH�VLPSO\�WRR�FORVH�WR�LW��&RQFHSWV�WKDW�are intuitive to you, since you designed them, may need more expla-nation for a new user. The solution is to conduct usability testing.

That may sound like a fancy term, but it really can be quite simple. Find a friend or unsuspecting stranger who can give unbiased feed-back. Hand them a phone running your app and ask them to com-SOHWH�D�VSHFLȴF�WDVN��VXFK�DV�Ȋ&UHDWH�D�QHZ�WR�GR�LWHP�ȋ�Resist the urge to coach them. Just watch what they do, FDWDORJXH�ZKHUH�WKH\�JHW�FRQIXVHG��DQG�JDXJH�KRZ�TXLFNO\�WKH\�ȴQG�the necessary buttons.

It’s best if you can get them to verbalize their thoughts in this process.

Take notes as you watch them. Once they complete a task give them another one and keep watching. This process can be invaluable, provided the participant feels free to share his or her unvarnished opinion.

$IWHU�\RXȇYH�FDSWXUHG�IHHGEDFN�IURP�D�IHZ�SHRSOH��PDNH�WKH�ȴ[HV�before testing with others. Generally there’s little need to conduct user testing with lots of people. You’ll reach the point of diminishing returns quickly. I’ve consistently found that users encounter 90% of the same issues.

Using potential customers or at least people in your target market is best, but almost anyone will do. Just weigh the value of their feedback based on how close they are to your target customer.

Pitfall 8: Ignoring Speed & Caching

When implementing features and designing a great user experience, it can be easy to forget that VSHHG�LV�D�IHDWXUH. In fact, if your app is slow, your users may become frustrated and never even try the DSS�GLHUHQWLDWLQJ�IHDWXUHV�\RX�VSHQW�VR�PXFK�WLPH�EXLOGLQJ�

Facebook recently released an update to their iOS app. This update dramatically improved the user experience, but visually very little was GLHUHQW��6R�ZKDW�PDGH�WKH�GLHUHQFH"

Their entire update focused on making the app fast. Facebook, like many apps, needs to get almost all of their data from a server that

was slowing down the entire experi-ence. By decreasing requests and implementing caching, the speed of the app improved so much you could see user reviews on the App Store pointing it out. Caching your data to improve load speed is another area that a thoughtfully architected backend can provide -- and, in doing so, radically improve the user experi-

ence of your application.

3LWIDOO����2YHUXVLQJ�3XVK�1RWLȴFDWLRQV

Many apps need to be used actively in order for the developer to generate revenue (e.g., increasing views for advertisements or enticing users to make in-app purchases). So how do developers get users to come back?

3XVK�QRWLȴFDWLRQV�DUH�RQH�RSWLRQ��EXW�PDQ\�GHYHORSHUV�XVH�WKHP�poorly. Do you really want to be reminded to use that app you never FDUHG�DERXW�LQ�WKH�ȴUVW�SODFH"�ΖQ�WKDW�FDVH�D�SRRUO\�WDUJHWHG�SXVK�QRWLȴFDWLRQ�PD\�EH�WKH�ȴQDO�VWUDZ�QHHGHG�IRU�WKH�XVHU�WR�XQLQVWDOO�the app.

7KDWȇV�QRW�WR�VD\�\RX�VKRXOGQȇW�XVH�SXVK�QRWLȴFDWLRQV��EHFDXVH�\RX�should. Just be smart about it.

ΖI�\RX�VHQG�WDUJHWHG�QRWLȴFDWLRQV�EDVHG�RQ�D�XVHUȇV�SUHIHUHQFHV�RU�location it can help make your app more sticky and keep them coming back. This is just another reason to have a server-side com-ponent to your application. The better your information about your

customers, the more targeted you can be in your interactions with them.

$OO�WKLV�ZLOO�VDYH�\RX�IURP�VHQGLQJ�D�PDVV�SXVK�QRWLȴFDWLRQ�LQ�D�desperate attempt to get some of your users back.

Wrapping Up

Many of these mistakes are easy to make, but luckily most are easy to ȴ[�DV�ZHOO��ΖW�WDNHV�DQ�DWWHQWLRQ�WR�GHWDLO�WKURXJKRXW�HYHU\�VWHS�RI�WKH�DSS�FUHDWLRQ�SURFHVV�WR�ȴQLVK�ZLWK�D�JUHDW�XVHU�H[SHULHQFH�

1HDU�WKH�ODXQFK�RI�D�QHZ�DSS�Ζ�ȴQG�LW�KHOSIXO�WR�JHW�DZD\�IURP�P\�normal design process and try to see the application as a user. Start

at the beginning and go through the VHWXS�VWHSV�H[DFWO\�DV�\RXU�ȴUVW�users will. Take notes at every juncture, paying special attention to SODFHV�LQ�WKH�ȵRZ�WKDW�GRQȇW�PDNH�complete sense or could cause confusion.

Write down a to-do item for each spacing issue, every sentence of copy that isn’t clear, and each bug you encounter -- especially the

things you didn’t have time to deal with when you were building the feature.

<RX�GRQȇW�QHFHVVDULO\�KDYH�WR�ȴ[�HYHU\WKLQJ�RQ�WKDW�OLVW��EXW�LW�LV�important to be aware of everything your users may encounter. Then when you are back in your design or development mindset you can power through many of those tasks quite quickly.

Though if you take nothing else away from this, I want you to start doing usability testing. It really does not have to be complicated. Just watch your users as they use your product. You will learn so much in very little time.

The 9 Most Common UX Mistakes in Mobile App Design

1. Not simplifying the feature set

2. Forgetting state

�����1RW�XVLQJ�ȴQJHU�VL]HG�WDS�WDUJHWV

4. Overcrowding views

5. Keeping the user waiting without feedback

6. Displaying the wrong keyboards

7. Failing to do usability testing (or ignoring the results)

8. I gnoring speed and caching

����2YHUXVLQJ�SXVK�QRWLȴFDWLRQV

No one sets out to create a poorly designed app. Every project begins with high hopes and great expectations, but it’s amazing how quickly app design can start to unravel. Typically the problems with the user experience (UX) result from the accumulation of seemingly minor issues -- compounding imperfections that ultimately cause users to quit the app and never come back.

Many of these small mistakes emerge early on in the process, long before the visual design is even considered. Early decisions, like the initial feature set and how your backend system will work, can have a dramatic impact on the UX of the entire project.

This eBook explores nine of the most common UX pitfalls in mobile app design. It highlights the traps so that app developers know how to avoid them. But if you’ve made any of these mistakes, no need to worry. The eBook also explains how to overcome the setback.

HOW TO AVOID 9 COMMON MOBILE UX MISTAKES 1

Mistake 1: Not Simplifying The Feature Set

If you want to build a product that is simple to use, then creating a simple product is a good place to start. We tend to think of all the wonderful things our app could do, but then things get messy when we try to implement the entire list of possible features. So the trick is to plan everything you might want in the application, then pare down the list to only the most important items. This is sometimes referred to as arriving at your MVP, or Minimum Viable Product, but I prefer the following characterization by Dan Cederholm of SimpleBits: “Dream big, implement small.”

Analog as it is, for me it works best if I write everything down on paper and then circle the absolutely critical features. I do this rather WKDQ�FURVVLQJ�RXW�WKH�RSWLRQDO�IHDWXUHV��ΖW�VHHPV�OLNH�D�PLQRU�GLHU-ence, but if you pick out the mandatory features you will end up with a much shorter list.

When working from the short list of mandatory features you can set the bar for user experience very high. Then later as you add more features you can work hard to maintain your high standards.

The designers at 37signals say, “It’s better to build half a product than a half-assed product.” Cutting features at the beginning is the best way to start building a great product.

Mistake 2: Forgetting State

A few weeks ago I was trying to get some work done on my iPhone. Hunting for a particular piece of data required me to drill a few layers deep into the app’s navigation. Then, realizing I needed something from the web as well, I quickly switched over to Safari.

When I returned to this app moments later, I was shown the top-level dashboard. Wait, what?

:KDW�KDSSHQHG�WR�WKH�SDJH�Ζ�KDG�ZRUNHG�VR�KDUG�WR�ȴQG"�$OWKRXJK�no data had been lost, because the app hadn’t remembered my navigation state, I felt as if the app had wasted my time. It created a frustrated user.

Your app should always try to act on behalf of the user. It should remember the last screen the user was visiting so they can immedi-DWHO\�SLFN�XS�ZKHUH�WKH\�OHIW�R�ZKHQ�WKH\�UHWXUQ�

Remembering state can also work across devices. Since a single person may use multiple devices in which the apps sync between them automatically, then the user will expect the data to sync as well.

For example, if an Angry Birds player clears multiple levels on his iPhone, then he shouldn’t be set to the beginning on his iPad.

State is a prime example of a UX issue being heavily impacted by backend functionality. If you (or a collaborator) don’t have backend development skills, you might want to try a back-end-as-a-service provider that has

pre-built this capability for you.

Mistake 3: Not Using Finger-Sized Tap Targets

Literally the biggest thing you can do to improve the usability of your app is to increase the tappable area for every button. You’re design-LQJ�IRU�ȴQJHUV�DQG�WKXPEV��QRW�PRXVH�FXUVRUV��ZKLFK�KDYH�D�KLJKHU�pointing accuracy).

Apple recommends a minimum of 44px by 44px for any element with which the user is expected to interact. The same recommendation applies to other smartphone platforms.

Of course, this guidance doesn’t mean that the button needs to appear that large. The tappable area can extend beyond the visible borders of the button. This will help users avoid the frustration of trying multiple times to tap an element. Just be careful if you position several buttons close to each other. Make sure that your extra tappable area doesn’t overlap with other buttons.

Mistake 4: Overcrowding Views

If you are used to designing for desktop computers, you’ll be VXUSULVHG�DW�MXVW�KRZ�OLWWOH�FRQWHQW�\RX�FDQ�ȴW�RQ�D�PRELOH�SKRQH��Because the screens are so much smaller, and tap targets need to be larger, views quickly become overcrowded. The solution is not to make elements smaller. That will just frustrate your users. Instead you need to add more views.

Whenever I start designing a new mobile app, I underestimate the number of required views. I start out thinking it will be a relatively VLPSOH�DSS�ZLWK�IHZHU�WKDQ�ȴYH�views, but then the views start DGGLQJ�XS��%HIRUH�ORQJ�Ζ�ȴQG�Ζ�QHHG�as many as 20 views to handle all the necessary tasks (registration, IRUJRW�SDVVZRUG��VHWWLQJ�QRWLȴFD-tion times, etc).

But that’s okay. It’s better to add more views than it is to overcrowd MXVW�D�IHZ�YLHZV��'HGLFDWLQJ�DQ�HQWLUH�YLHZ�WR�VHWWLQJ�D�QRWLȴFDWLRQ�WLPH�LV�MXVW�ȴQH��-XVW�PDNH�VXUH�WKDW�\RXU�WUDQVLWLRQV�DUH�TXLFN��buttons are clear, and that it’s easy to get back to the previous view.

Mistake 5: Keeping The User Waiting Without Feedback

Users have very little patience with mobile applications. As a mobile app developer, you might be frustrated with a user’s impatience because you understand that some tasks are always going to be slow, especially when the user has a weak network connection or an older device.

If your app is too slow or feels unre-sponsive, it only takes a single tap of the “home” button before your user is gone and never revisits your app. Luckily there is an easy way to help your users become more patient: Simply keep them informed.

Typically the problems with the user experience (UX) result from the accu-mulation of seemingly minor issues

/HWV�VD\�\RX�DUH�WU\LQJ�WR�SRSXODWH�WKH�GDWDEDVH�RQ�WKH�ȴUVW�UXQ�RI�D�newly installed app. By default, iOS shows a splash screen while the app is installing. Instead of the generic splash screen, you could display a simple message with a loading animation that reads, "Installing ..."

That step alone will grant you several seconds of patience. If it takes longer you can buy more time by changing the message. Next set it to "Loading database ..." If you need even more time wait several seconds and update the message again. "Loading interface ..." will give you still more time. Change the messages to what makes sense for your application, but keep the user informed.

You see, the user is just worried that your app has locked up. No one wants to keep staring at a screen that isn't going to do anything else. By changing the messages it shows that your application is still working on their behalf.

Mistake 6: Displaying The Wrong Keyboards

Have you ever typed in a URL and been happy to see a button on the keyboard that has “.com” on a single button? That single button saved you three additional keystrokes.

That little shortcut is possible because we know what type of data is H[SHFWHG�LQ�D�WH[W�ȴHOG��VR�ZH�FDQ�FKDQJH�WKH�NH\ERDUG�WR�PDNH�WKDW�easier. This means that you can add an “@” button on the main keyboard for entering emails or showing that “.com” button for URLs.

There are actually HLJKW�GLHUHQW�NH\ERDUG�YDULDWLRQV�available to you on L26��:KHQHYHU�\RX�SXW�LQ�D�WH[W�ȴHOG�\RX�FDQ�VHOHFW�ZKLFK�NH\ERDUG�should be used to input the content. These range from the default NH\ERDUG�WR�QXPEHU�NH\ERDUGV�WKDW�DUH�HQWLUHO\�GLHUHQW��ZLWK�ORWV�RI�subtle variations in between. Look through the options and choose the RQH�WKDW�PDNHV�WKH�PRVW�VHQVH�IRU�HDFK�ȴHOG�

You can also choose the keyboards on mobile web apps by changing the LQSXW�W\SH��1RUPDOO\�IRU�IRUP�ȴHOGV�we use <input type=”text” /> and <input type=”password” />, but in HTML5 even more options are avail-able. The one you should use most often is <input type=”email” />. 9LVXDOO\�LW�GRHVQȇW�ORRN�GLHUHQW�IURP�a standard text input, but iOS and Android will automatically display a

keyboard with a period and an @ symbol to make it quicker to enter email addresses.

Mistake 7: Failing To Do Usability Testing (Or Ignoring The Results)

Typically when you develop an app you know the product so well that you can’t accurately judge how easy it is to use for someone experi-HQFLQJ�LW�IRU�WKH�ȴUVW�WLPH��<RX�DUH�VLPSO\�WRR�FORVH�WR�LW��&RQFHSWV�WKDW�are intuitive to you, since you designed them, may need more expla-nation for a new user. The solution is to conduct usability testing.

That may sound like a fancy term, but it really can be quite simple. Find a friend or unsuspecting stranger who can give unbiased feed-back. Hand them a phone running your app and ask them to com-SOHWH�D�VSHFLȴF�WDVN��VXFK�DV�Ȋ&UHDWH�D�QHZ�WR�GR�LWHP�ȋ�Resist the urge to coach them. Just watch what they do, FDWDORJXH�ZKHUH�WKH\�JHW�FRQIXVHG��DQG�JDXJH�KRZ�TXLFNO\�WKH\�ȴQG�the necessary buttons.

It’s best if you can get them to verbalize their thoughts in this process.

Take notes as you watch them. Once they complete a task give them another one and keep watching. This process can be invaluable, provided the participant feels free to share his or her unvarnished opinion.

$IWHU�\RXȇYH�FDSWXUHG�IHHGEDFN�IURP�D�IHZ�SHRSOH��PDNH�WKH�ȴ[HV�before testing with others. Generally there’s little need to conduct user testing with lots of people. You’ll reach the point of diminishing returns quickly. I’ve consistently found that users encounter 90% of the same issues.

Using potential customers or at least people in your target market is best, but almost anyone will do. Just weigh the value of their feedback based on how close they are to your target customer.

Pitfall 8: Ignoring Speed & Caching

When implementing features and designing a great user experience, it can be easy to forget that VSHHG�LV�D�IHDWXUH. In fact, if your app is slow, your users may become frustrated and never even try the DSS�GLHUHQWLDWLQJ�IHDWXUHV�\RX�VSHQW�VR�PXFK�WLPH�EXLOGLQJ�

Facebook recently released an update to their iOS app. This update dramatically improved the user experience, but visually very little was GLHUHQW��6R�ZKDW�PDGH�WKH�GLHUHQFH"

Their entire update focused on making the app fast. Facebook, like many apps, needs to get almost all of their data from a server that

was slowing down the entire experi-ence. By decreasing requests and implementing caching, the speed of the app improved so much you could see user reviews on the App Store pointing it out. Caching your data to improve load speed is another area that a thoughtfully architected backend can provide -- and, in doing so, radically improve the user experi-

ence of your application.

3LWIDOO����2YHUXVLQJ�3XVK�1RWLȴFDWLRQV

Many apps need to be used actively in order for the developer to generate revenue (e.g., increasing views for advertisements or enticing users to make in-app purchases). So how do developers get users to come back?

3XVK�QRWLȴFDWLRQV�DUH�RQH�RSWLRQ��EXW�PDQ\�GHYHORSHUV�XVH�WKHP�poorly. Do you really want to be reminded to use that app you never FDUHG�DERXW�LQ�WKH�ȴUVW�SODFH"�ΖQ�WKDW�FDVH�D�SRRUO\�WDUJHWHG�SXVK�QRWLȴFDWLRQ�PD\�EH�WKH�ȴQDO�VWUDZ�QHHGHG�IRU�WKH�XVHU�WR�XQLQVWDOO�the app.

7KDWȇV�QRW�WR�VD\�\RX�VKRXOGQȇW�XVH�SXVK�QRWLȴFDWLRQV��EHFDXVH�\RX�should. Just be smart about it.

ΖI�\RX�VHQG�WDUJHWHG�QRWLȴFDWLRQV�EDVHG�RQ�D�XVHUȇV�SUHIHUHQFHV�RU�location it can help make your app more sticky and keep them coming back. This is just another reason to have a server-side com-ponent to your application. The better your information about your

customers, the more targeted you can be in your interactions with them.

$OO�WKLV�ZLOO�VDYH�\RX�IURP�VHQGLQJ�D�PDVV�SXVK�QRWLȴFDWLRQ�LQ�D�desperate attempt to get some of your users back.

Wrapping Up

Many of these mistakes are easy to make, but luckily most are easy to ȴ[�DV�ZHOO��ΖW�WDNHV�DQ�DWWHQWLRQ�WR�GHWDLO�WKURXJKRXW�HYHU\�VWHS�RI�WKH�DSS�FUHDWLRQ�SURFHVV�WR�ȴQLVK�ZLWK�D�JUHDW�XVHU�H[SHULHQFH�

1HDU�WKH�ODXQFK�RI�D�QHZ�DSS�Ζ�ȴQG�LW�KHOSIXO�WR�JHW�DZD\�IURP�P\�normal design process and try to see the application as a user. Start

at the beginning and go through the VHWXS�VWHSV�H[DFWO\�DV�\RXU�ȴUVW�users will. Take notes at every juncture, paying special attention to SODFHV�LQ�WKH�ȵRZ�WKDW�GRQȇW�PDNH�complete sense or could cause confusion.

Write down a to-do item for each spacing issue, every sentence of copy that isn’t clear, and each bug you encounter -- especially the

things you didn’t have time to deal with when you were building the feature.

<RX�GRQȇW�QHFHVVDULO\�KDYH�WR�ȴ[�HYHU\WKLQJ�RQ�WKDW�OLVW��EXW�LW�LV�important to be aware of everything your users may encounter. Then when you are back in your design or development mindset you can power through many of those tasks quite quickly.

Though if you take nothing else away from this, I want you to start doing usability testing. It really does not have to be complicated. Just watch your users as they use your product. You will learn so much in very little time.

HOW TO AVOID 9 COMMON MOBILE UX MISTAKES 2

No one sets out to create a poorly designed app. Every project begins with high hopes and great expectations, but it’s amazing how quickly app design can start to unravel. Typically the problems with the user experience (UX) result from the accumulation of seemingly minor issues -- compounding imperfections that ultimately cause users to quit the app and never come back.

Many of these small mistakes emerge early on in the process, long before the visual design is even considered. Early decisions, like the initial feature set and how your backend system will work, can have a dramatic impact on the UX of the entire project.

This eBook explores nine of the most common UX pitfalls in mobile app design. It highlights the traps so that app developers know how to avoid them. But if you’ve made any of these mistakes, no need to worry. The eBook also explains how to overcome the setback.

Mistake 1: Not Simplifying The Feature Set

If you want to build a product that is simple to use, then creating a simple product is a good place to start. We tend to think of all the wonderful things our app could do, but then things get messy when we try to implement the entire list of possible features. So the trick is to plan everything you might want in the application, then pare down the list to only the most important items. This is sometimes referred to as arriving at your MVP, or Minimum Viable Product, but I prefer the following characterization by Dan Cederholm of SimpleBits: “Dream big, implement small.”

Analog as it is, for me it works best if I write everything down on paper and then circle the absolutely critical features. I do this rather WKDQ�FURVVLQJ�RXW�WKH�RSWLRQDO�IHDWXUHV��ΖW�VHHPV�OLNH�D�PLQRU�GLHU-ence, but if you pick out the mandatory features you will end up with a much shorter list.

When working from the short list of mandatory features you can set the bar for user experience very high. Then later as you add more features you can work hard to maintain your high standards.

The designers at 37signals say, “It’s better to build half a product than a half-assed product.” Cutting features at the beginning is the best way to start building a great product.

Mistake 2: Forgetting State

A few weeks ago I was trying to get some work done on my iPhone. Hunting for a particular piece of data required me to drill a few layers deep into the app’s navigation. Then, realizing I needed something from the web as well, I quickly switched over to Safari.

When I returned to this app moments later, I was shown the top-level dashboard. Wait, what?

:KDW�KDSSHQHG�WR�WKH�SDJH�Ζ�KDG�ZRUNHG�VR�KDUG�WR�ȴQG"�$OWKRXJK�no data had been lost, because the app hadn’t remembered my navigation state, I felt as if the app had wasted my time. It created a frustrated user.

Your app should always try to act on behalf of the user. It should remember the last screen the user was visiting so they can immedi-DWHO\�SLFN�XS�ZKHUH�WKH\�OHIW�R�ZKHQ�WKH\�UHWXUQ�

Remembering state can also work across devices. Since a single person may use multiple devices in which the apps sync between them automatically, then the user will expect the data to sync as well.

For example, if an Angry Birds player clears multiple levels on his iPhone, then he shouldn’t be set to the beginning on his iPad.

State is a prime example of a UX issue being heavily impacted by backend functionality. If you (or a collaborator) don’t have backend development skills, you might want to try a back-end-as-a-service provider that has

pre-built this capability for you.

Mistake 3: Not Using Finger-Sized Tap Targets

Literally the biggest thing you can do to improve the usability of your app is to increase the tappable area for every button. You’re design-LQJ�IRU�ȴQJHUV�DQG�WKXPEV��QRW�PRXVH�FXUVRUV��ZKLFK�KDYH�D�KLJKHU�pointing accuracy).

Apple recommends a minimum of 44px by 44px for any element with which the user is expected to interact. The same recommendation applies to other smartphone platforms.

Of course, this guidance doesn’t mean that the button needs to appear that large. The tappable area can extend beyond the visible borders of the button. This will help users avoid the frustration of trying multiple times to tap an element. Just be careful if you position several buttons close to each other. Make sure that your extra tappable area doesn’t overlap with other buttons.

Mistake 4: Overcrowding Views

If you are used to designing for desktop computers, you’ll be VXUSULVHG�DW�MXVW�KRZ�OLWWOH�FRQWHQW�\RX�FDQ�ȴW�RQ�D�PRELOH�SKRQH��Because the screens are so much smaller, and tap targets need to be larger, views quickly become overcrowded. The solution is not to make elements smaller. That will just frustrate your users. Instead you need to add more views.

Whenever I start designing a new mobile app, I underestimate the number of required views. I start out thinking it will be a relatively VLPSOH�DSS�ZLWK�IHZHU�WKDQ�ȴYH�views, but then the views start DGGLQJ�XS��%HIRUH�ORQJ�Ζ�ȴQG�Ζ�QHHG�as many as 20 views to handle all the necessary tasks (registration, IRUJRW�SDVVZRUG��VHWWLQJ�QRWLȴFD-tion times, etc).

But that’s okay. It’s better to add more views than it is to overcrowd MXVW�D�IHZ�YLHZV��'HGLFDWLQJ�DQ�HQWLUH�YLHZ�WR�VHWWLQJ�D�QRWLȴFDWLRQ�WLPH�LV�MXVW�ȴQH��-XVW�PDNH�VXUH�WKDW�\RXU�WUDQVLWLRQV�DUH�TXLFN��buttons are clear, and that it’s easy to get back to the previous view.

Mistake 5: Keeping The User Waiting Without Feedback

Users have very little patience with mobile applications. As a mobile app developer, you might be frustrated with a user’s impatience because you understand that some tasks are always going to be slow, especially when the user has a weak network connection or an older device.

If your app is too slow or feels unre-sponsive, it only takes a single tap of the “home” button before your user is gone and never revisits your app. Luckily there is an easy way to help your users become more patient: Simply keep them informed.

Typically the problems with the user experience (UX) result from the accu-mulation of seemingly minor issues

/HWV�VD\�\RX�DUH�WU\LQJ�WR�SRSXODWH�WKH�GDWDEDVH�RQ�WKH�ȴUVW�UXQ�RI�D�newly installed app. By default, iOS shows a splash screen while the app is installing. Instead of the generic splash screen, you could display a simple message with a loading animation that reads, "Installing ..."

That step alone will grant you several seconds of patience. If it takes longer you can buy more time by changing the message. Next set it to "Loading database ..." If you need even more time wait several seconds and update the message again. "Loading interface ..." will give you still more time. Change the messages to what makes sense for your application, but keep the user informed.

You see, the user is just worried that your app has locked up. No one wants to keep staring at a screen that isn't going to do anything else. By changing the messages it shows that your application is still working on their behalf.

Mistake 6: Displaying The Wrong Keyboards

Have you ever typed in a URL and been happy to see a button on the keyboard that has “.com” on a single button? That single button saved you three additional keystrokes.

That little shortcut is possible because we know what type of data is H[SHFWHG�LQ�D�WH[W�ȴHOG��VR�ZH�FDQ�FKDQJH�WKH�NH\ERDUG�WR�PDNH�WKDW�easier. This means that you can add an “@” button on the main keyboard for entering emails or showing that “.com” button for URLs.

There are actually HLJKW�GLHUHQW�NH\ERDUG�YDULDWLRQV�available to you on L26��:KHQHYHU�\RX�SXW�LQ�D�WH[W�ȴHOG�\RX�FDQ�VHOHFW�ZKLFK�NH\ERDUG�should be used to input the content. These range from the default NH\ERDUG�WR�QXPEHU�NH\ERDUGV�WKDW�DUH�HQWLUHO\�GLHUHQW��ZLWK�ORWV�RI�subtle variations in between. Look through the options and choose the RQH�WKDW�PDNHV�WKH�PRVW�VHQVH�IRU�HDFK�ȴHOG�

You can also choose the keyboards on mobile web apps by changing the LQSXW�W\SH��1RUPDOO\�IRU�IRUP�ȴHOGV�we use <input type=”text” /> and <input type=”password” />, but in HTML5 even more options are avail-able. The one you should use most often is <input type=”email” />. 9LVXDOO\�LW�GRHVQȇW�ORRN�GLHUHQW�IURP�a standard text input, but iOS and Android will automatically display a

keyboard with a period and an @ symbol to make it quicker to enter email addresses.

Mistake 7: Failing To Do Usability Testing (Or Ignoring The Results)

Typically when you develop an app you know the product so well that you can’t accurately judge how easy it is to use for someone experi-HQFLQJ�LW�IRU�WKH�ȴUVW�WLPH��<RX�DUH�VLPSO\�WRR�FORVH�WR�LW��&RQFHSWV�WKDW�are intuitive to you, since you designed them, may need more expla-nation for a new user. The solution is to conduct usability testing.

That may sound like a fancy term, but it really can be quite simple. Find a friend or unsuspecting stranger who can give unbiased feed-back. Hand them a phone running your app and ask them to com-SOHWH�D�VSHFLȴF�WDVN��VXFK�DV�Ȋ&UHDWH�D�QHZ�WR�GR�LWHP�ȋ�Resist the urge to coach them. Just watch what they do, FDWDORJXH�ZKHUH�WKH\�JHW�FRQIXVHG��DQG�JDXJH�KRZ�TXLFNO\�WKH\�ȴQG�the necessary buttons.

It’s best if you can get them to verbalize their thoughts in this process.

Take notes as you watch them. Once they complete a task give them another one and keep watching. This process can be invaluable, provided the participant feels free to share his or her unvarnished opinion.

$IWHU�\RXȇYH�FDSWXUHG�IHHGEDFN�IURP�D�IHZ�SHRSOH��PDNH�WKH�ȴ[HV�before testing with others. Generally there’s little need to conduct user testing with lots of people. You’ll reach the point of diminishing returns quickly. I’ve consistently found that users encounter 90% of the same issues.

Using potential customers or at least people in your target market is best, but almost anyone will do. Just weigh the value of their feedback based on how close they are to your target customer.

Pitfall 8: Ignoring Speed & Caching

When implementing features and designing a great user experience, it can be easy to forget that VSHHG�LV�D�IHDWXUH. In fact, if your app is slow, your users may become frustrated and never even try the DSS�GLHUHQWLDWLQJ�IHDWXUHV�\RX�VSHQW�VR�PXFK�WLPH�EXLOGLQJ�

Facebook recently released an update to their iOS app. This update dramatically improved the user experience, but visually very little was GLHUHQW��6R�ZKDW�PDGH�WKH�GLHUHQFH"

Their entire update focused on making the app fast. Facebook, like many apps, needs to get almost all of their data from a server that

was slowing down the entire experi-ence. By decreasing requests and implementing caching, the speed of the app improved so much you could see user reviews on the App Store pointing it out. Caching your data to improve load speed is another area that a thoughtfully architected backend can provide -- and, in doing so, radically improve the user experi-

ence of your application.

3LWIDOO����2YHUXVLQJ�3XVK�1RWLȴFDWLRQV

Many apps need to be used actively in order for the developer to generate revenue (e.g., increasing views for advertisements or enticing users to make in-app purchases). So how do developers get users to come back?

3XVK�QRWLȴFDWLRQV�DUH�RQH�RSWLRQ��EXW�PDQ\�GHYHORSHUV�XVH�WKHP�poorly. Do you really want to be reminded to use that app you never FDUHG�DERXW�LQ�WKH�ȴUVW�SODFH"�ΖQ�WKDW�FDVH�D�SRRUO\�WDUJHWHG�SXVK�QRWLȴFDWLRQ�PD\�EH�WKH�ȴQDO�VWUDZ�QHHGHG�IRU�WKH�XVHU�WR�XQLQVWDOO�the app.

7KDWȇV�QRW�WR�VD\�\RX�VKRXOGQȇW�XVH�SXVK�QRWLȴFDWLRQV��EHFDXVH�\RX�should. Just be smart about it.

ΖI�\RX�VHQG�WDUJHWHG�QRWLȴFDWLRQV�EDVHG�RQ�D�XVHUȇV�SUHIHUHQFHV�RU�location it can help make your app more sticky and keep them coming back. This is just another reason to have a server-side com-ponent to your application. The better your information about your

customers, the more targeted you can be in your interactions with them.

$OO�WKLV�ZLOO�VDYH�\RX�IURP�VHQGLQJ�D�PDVV�SXVK�QRWLȴFDWLRQ�LQ�D�desperate attempt to get some of your users back.

Wrapping Up

Many of these mistakes are easy to make, but luckily most are easy to ȴ[�DV�ZHOO��ΖW�WDNHV�DQ�DWWHQWLRQ�WR�GHWDLO�WKURXJKRXW�HYHU\�VWHS�RI�WKH�DSS�FUHDWLRQ�SURFHVV�WR�ȴQLVK�ZLWK�D�JUHDW�XVHU�H[SHULHQFH�

1HDU�WKH�ODXQFK�RI�D�QHZ�DSS�Ζ�ȴQG�LW�KHOSIXO�WR�JHW�DZD\�IURP�P\�normal design process and try to see the application as a user. Start

at the beginning and go through the VHWXS�VWHSV�H[DFWO\�DV�\RXU�ȴUVW�users will. Take notes at every juncture, paying special attention to SODFHV�LQ�WKH�ȵRZ�WKDW�GRQȇW�PDNH�complete sense or could cause confusion.

Write down a to-do item for each spacing issue, every sentence of copy that isn’t clear, and each bug you encounter -- especially the

things you didn’t have time to deal with when you were building the feature.

<RX�GRQȇW�QHFHVVDULO\�KDYH�WR�ȴ[�HYHU\WKLQJ�RQ�WKDW�OLVW��EXW�LW�LV�important to be aware of everything your users may encounter. Then when you are back in your design or development mindset you can power through many of those tasks quite quickly.

Though if you take nothing else away from this, I want you to start doing usability testing. It really does not have to be complicated. Just watch your users as they use your product. You will learn so much in very little time.

HOW TO AVOID 9 COMMON MOBILE UX MISTAKES 3

No one sets out to create a poorly designed app. Every project begins with high hopes and great expectations, but it’s amazing how quickly app design can start to unravel. Typically the problems with the user experience (UX) result from the accumulation of seemingly minor issues -- compounding imperfections that ultimately cause users to quit the app and never come back.

Many of these small mistakes emerge early on in the process, long before the visual design is even considered. Early decisions, like the initial feature set and how your backend system will work, can have a dramatic impact on the UX of the entire project.

This eBook explores nine of the most common UX pitfalls in mobile app design. It highlights the traps so that app developers know how to avoid them. But if you’ve made any of these mistakes, no need to worry. The eBook also explains how to overcome the setback.

Mistake 1: Not Simplifying The Feature Set

If you want to build a product that is simple to use, then creating a simple product is a good place to start. We tend to think of all the wonderful things our app could do, but then things get messy when we try to implement the entire list of possible features. So the trick is to plan everything you might want in the application, then pare down the list to only the most important items. This is sometimes referred to as arriving at your MVP, or Minimum Viable Product, but I prefer the following characterization by Dan Cederholm of SimpleBits: “Dream big, implement small.”

Analog as it is, for me it works best if I write everything down on paper and then circle the absolutely critical features. I do this rather WKDQ�FURVVLQJ�RXW�WKH�RSWLRQDO�IHDWXUHV��ΖW�VHHPV�OLNH�D�PLQRU�GLHU-ence, but if you pick out the mandatory features you will end up with a much shorter list.

When working from the short list of mandatory features you can set the bar for user experience very high. Then later as you add more features you can work hard to maintain your high standards.

The designers at 37signals say, “It’s better to build half a product than a half-assed product.” Cutting features at the beginning is the best way to start building a great product.

Mistake 2: Forgetting State

A few weeks ago I was trying to get some work done on my iPhone. Hunting for a particular piece of data required me to drill a few layers deep into the app’s navigation. Then, realizing I needed something from the web as well, I quickly switched over to Safari.

When I returned to this app moments later, I was shown the top-level dashboard. Wait, what?

:KDW�KDSSHQHG�WR�WKH�SDJH�Ζ�KDG�ZRUNHG�VR�KDUG�WR�ȴQG"�$OWKRXJK�no data had been lost, because the app hadn’t remembered my navigation state, I felt as if the app had wasted my time. It created a frustrated user.

Your app should always try to act on behalf of the user. It should remember the last screen the user was visiting so they can immedi-DWHO\�SLFN�XS�ZKHUH�WKH\�OHIW�R�ZKHQ�WKH\�UHWXUQ�

Remembering state can also work across devices. Since a single person may use multiple devices in which the apps sync between them automatically, then the user will expect the data to sync as well.

For example, if an Angry Birds player clears multiple levels on his iPhone, then he shouldn’t be set to the beginning on his iPad.

State is a prime example of a UX issue being heavily impacted by backend functionality. If you (or a collaborator) don’t have backend development skills, you might want to try a back-end-as-a-service provider that has

pre-built this capability for you.

Mistake 3: Not Using Finger-Sized Tap Targets

Literally the biggest thing you can do to improve the usability of your app is to increase the tappable area for every button. You’re design-LQJ�IRU�ȴQJHUV�DQG�WKXPEV��QRW�PRXVH�FXUVRUV��ZKLFK�KDYH�D�KLJKHU�pointing accuracy).

Apple recommends a minimum of 44px by 44px for any element with which the user is expected to interact. The same recommendation applies to other smartphone platforms.

Of course, this guidance doesn’t mean that the button needs to appear that large. The tappable area can extend beyond the visible borders of the button. This will help users avoid the frustration of trying multiple times to tap an element. Just be careful if you position several buttons close to each other. Make sure that your extra tappable area doesn’t overlap with other buttons.

Mistake 4: Overcrowding Views

If you are used to designing for desktop computers, you’ll be VXUSULVHG�DW�MXVW�KRZ�OLWWOH�FRQWHQW�\RX�FDQ�ȴW�RQ�D�PRELOH�SKRQH��Because the screens are so much smaller, and tap targets need to be larger, views quickly become overcrowded. The solution is not to make elements smaller. That will just frustrate your users. Instead you need to add more views.

Whenever I start designing a new mobile app, I underestimate the number of required views. I start out thinking it will be a relatively VLPSOH�DSS�ZLWK�IHZHU�WKDQ�ȴYH�views, but then the views start DGGLQJ�XS��%HIRUH�ORQJ�Ζ�ȴQG�Ζ�QHHG�as many as 20 views to handle all the necessary tasks (registration, IRUJRW�SDVVZRUG��VHWWLQJ�QRWLȴFD-tion times, etc).

But that’s okay. It’s better to add more views than it is to overcrowd MXVW�D�IHZ�YLHZV��'HGLFDWLQJ�DQ�HQWLUH�YLHZ�WR�VHWWLQJ�D�QRWLȴFDWLRQ�WLPH�LV�MXVW�ȴQH��-XVW�PDNH�VXUH�WKDW�\RXU�WUDQVLWLRQV�DUH�TXLFN��buttons are clear, and that it’s easy to get back to the previous view.

Mistake 5: Keeping The User Waiting Without Feedback

Users have very little patience with mobile applications. As a mobile app developer, you might be frustrated with a user’s impatience because you understand that some tasks are always going to be slow, especially when the user has a weak network connection or an older device.

If your app is too slow or feels unre-sponsive, it only takes a single tap of the “home” button before your user is gone and never revisits your app. Luckily there is an easy way to help your users become more patient: Simply keep them informed.

Typically the problems with the user experience (UX) result from the accu-mulation of seemingly minor issues

/HWV�VD\�\RX�DUH�WU\LQJ�WR�SRSXODWH�WKH�GDWDEDVH�RQ�WKH�ȴUVW�UXQ�RI�D�newly installed app. By default, iOS shows a splash screen while the app is installing. Instead of the generic splash screen, you could display a simple message with a loading animation that reads, "Installing ..."

That step alone will grant you several seconds of patience. If it takes longer you can buy more time by changing the message. Next set it to "Loading database ..." If you need even more time wait several seconds and update the message again. "Loading interface ..." will give you still more time. Change the messages to what makes sense for your application, but keep the user informed.

You see, the user is just worried that your app has locked up. No one wants to keep staring at a screen that isn't going to do anything else. By changing the messages it shows that your application is still working on their behalf.

Mistake 6: Displaying The Wrong Keyboards

Have you ever typed in a URL and been happy to see a button on the keyboard that has “.com” on a single button? That single button saved you three additional keystrokes.

That little shortcut is possible because we know what type of data is H[SHFWHG�LQ�D�WH[W�ȴHOG��VR�ZH�FDQ�FKDQJH�WKH�NH\ERDUG�WR�PDNH�WKDW�easier. This means that you can add an “@” button on the main keyboard for entering emails or showing that “.com” button for URLs.

There are actually HLJKW�GLHUHQW�NH\ERDUG�YDULDWLRQV�available to you on L26��:KHQHYHU�\RX�SXW�LQ�D�WH[W�ȴHOG�\RX�FDQ�VHOHFW�ZKLFK�NH\ERDUG�should be used to input the content. These range from the default NH\ERDUG�WR�QXPEHU�NH\ERDUGV�WKDW�DUH�HQWLUHO\�GLHUHQW��ZLWK�ORWV�RI�subtle variations in between. Look through the options and choose the RQH�WKDW�PDNHV�WKH�PRVW�VHQVH�IRU�HDFK�ȴHOG�

You can also choose the keyboards on mobile web apps by changing the LQSXW�W\SH��1RUPDOO\�IRU�IRUP�ȴHOGV�we use <input type=”text” /> and <input type=”password” />, but in HTML5 even more options are avail-able. The one you should use most often is <input type=”email” />. 9LVXDOO\�LW�GRHVQȇW�ORRN�GLHUHQW�IURP�a standard text input, but iOS and Android will automatically display a

keyboard with a period and an @ symbol to make it quicker to enter email addresses.

Mistake 7: Failing To Do Usability Testing (Or Ignoring The Results)

Typically when you develop an app you know the product so well that you can’t accurately judge how easy it is to use for someone experi-HQFLQJ�LW�IRU�WKH�ȴUVW�WLPH��<RX�DUH�VLPSO\�WRR�FORVH�WR�LW��&RQFHSWV�WKDW�are intuitive to you, since you designed them, may need more expla-nation for a new user. The solution is to conduct usability testing.

That may sound like a fancy term, but it really can be quite simple. Find a friend or unsuspecting stranger who can give unbiased feed-back. Hand them a phone running your app and ask them to com-SOHWH�D�VSHFLȴF�WDVN��VXFK�DV�Ȋ&UHDWH�D�QHZ�WR�GR�LWHP�ȋ�Resist the urge to coach them. Just watch what they do, FDWDORJXH�ZKHUH�WKH\�JHW�FRQIXVHG��DQG�JDXJH�KRZ�TXLFNO\�WKH\�ȴQG�the necessary buttons.

It’s best if you can get them to verbalize their thoughts in this process.

Take notes as you watch them. Once they complete a task give them another one and keep watching. This process can be invaluable, provided the participant feels free to share his or her unvarnished opinion.

$IWHU�\RXȇYH�FDSWXUHG�IHHGEDFN�IURP�D�IHZ�SHRSOH��PDNH�WKH�ȴ[HV�before testing with others. Generally there’s little need to conduct user testing with lots of people. You’ll reach the point of diminishing returns quickly. I’ve consistently found that users encounter 90% of the same issues.

Using potential customers or at least people in your target market is best, but almost anyone will do. Just weigh the value of their feedback based on how close they are to your target customer.

Pitfall 8: Ignoring Speed & Caching

When implementing features and designing a great user experience, it can be easy to forget that VSHHG�LV�D�IHDWXUH. In fact, if your app is slow, your users may become frustrated and never even try the DSS�GLHUHQWLDWLQJ�IHDWXUHV�\RX�VSHQW�VR�PXFK�WLPH�EXLOGLQJ�

Facebook recently released an update to their iOS app. This update dramatically improved the user experience, but visually very little was GLHUHQW��6R�ZKDW�PDGH�WKH�GLHUHQFH"

Their entire update focused on making the app fast. Facebook, like many apps, needs to get almost all of their data from a server that

was slowing down the entire experi-ence. By decreasing requests and implementing caching, the speed of the app improved so much you could see user reviews on the App Store pointing it out. Caching your data to improve load speed is another area that a thoughtfully architected backend can provide -- and, in doing so, radically improve the user experi-

ence of your application.

3LWIDOO����2YHUXVLQJ�3XVK�1RWLȴFDWLRQV

Many apps need to be used actively in order for the developer to generate revenue (e.g., increasing views for advertisements or enticing users to make in-app purchases). So how do developers get users to come back?

3XVK�QRWLȴFDWLRQV�DUH�RQH�RSWLRQ��EXW�PDQ\�GHYHORSHUV�XVH�WKHP�poorly. Do you really want to be reminded to use that app you never FDUHG�DERXW�LQ�WKH�ȴUVW�SODFH"�ΖQ�WKDW�FDVH�D�SRRUO\�WDUJHWHG�SXVK�QRWLȴFDWLRQ�PD\�EH�WKH�ȴQDO�VWUDZ�QHHGHG�IRU�WKH�XVHU�WR�XQLQVWDOO�the app.

7KDWȇV�QRW�WR�VD\�\RX�VKRXOGQȇW�XVH�SXVK�QRWLȴFDWLRQV��EHFDXVH�\RX�should. Just be smart about it.

ΖI�\RX�VHQG�WDUJHWHG�QRWLȴFDWLRQV�EDVHG�RQ�D�XVHUȇV�SUHIHUHQFHV�RU�location it can help make your app more sticky and keep them coming back. This is just another reason to have a server-side com-ponent to your application. The better your information about your

customers, the more targeted you can be in your interactions with them.

$OO�WKLV�ZLOO�VDYH�\RX�IURP�VHQGLQJ�D�PDVV�SXVK�QRWLȴFDWLRQ�LQ�D�desperate attempt to get some of your users back.

Wrapping Up

Many of these mistakes are easy to make, but luckily most are easy to ȴ[�DV�ZHOO��ΖW�WDNHV�DQ�DWWHQWLRQ�WR�GHWDLO�WKURXJKRXW�HYHU\�VWHS�RI�WKH�DSS�FUHDWLRQ�SURFHVV�WR�ȴQLVK�ZLWK�D�JUHDW�XVHU�H[SHULHQFH�

1HDU�WKH�ODXQFK�RI�D�QHZ�DSS�Ζ�ȴQG�LW�KHOSIXO�WR�JHW�DZD\�IURP�P\�normal design process and try to see the application as a user. Start

at the beginning and go through the VHWXS�VWHSV�H[DFWO\�DV�\RXU�ȴUVW�users will. Take notes at every juncture, paying special attention to SODFHV�LQ�WKH�ȵRZ�WKDW�GRQȇW�PDNH�complete sense or could cause confusion.

Write down a to-do item for each spacing issue, every sentence of copy that isn’t clear, and each bug you encounter -- especially the

things you didn’t have time to deal with when you were building the feature.

<RX�GRQȇW�QHFHVVDULO\�KDYH�WR�ȴ[�HYHU\WKLQJ�RQ�WKDW�OLVW��EXW�LW�LV�important to be aware of everything your users may encounter. Then when you are back in your design or development mindset you can power through many of those tasks quite quickly.

Though if you take nothing else away from this, I want you to start doing usability testing. It really does not have to be complicated. Just watch your users as they use your product. You will learn so much in very little time.

HOW TO AVOID 9 COMMON MOBILE UX MISTAKES 4

No one sets out to create a poorly designed app. Every project begins with high hopes and great expectations, but it’s amazing how quickly app design can start to unravel. Typically the problems with the user experience (UX) result from the accumulation of seemingly minor issues -- compounding imperfections that ultimately cause users to quit the app and never come back.

Many of these small mistakes emerge early on in the process, long before the visual design is even considered. Early decisions, like the initial feature set and how your backend system will work, can have a dramatic impact on the UX of the entire project.

This eBook explores nine of the most common UX pitfalls in mobile app design. It highlights the traps so that app developers know how to avoid them. But if you’ve made any of these mistakes, no need to worry. The eBook also explains how to overcome the setback.

Mistake 1: Not Simplifying The Feature Set

If you want to build a product that is simple to use, then creating a simple product is a good place to start. We tend to think of all the wonderful things our app could do, but then things get messy when we try to implement the entire list of possible features. So the trick is to plan everything you might want in the application, then pare down the list to only the most important items. This is sometimes referred to as arriving at your MVP, or Minimum Viable Product, but I prefer the following characterization by Dan Cederholm of SimpleBits: “Dream big, implement small.”

Analog as it is, for me it works best if I write everything down on paper and then circle the absolutely critical features. I do this rather WKDQ�FURVVLQJ�RXW�WKH�RSWLRQDO�IHDWXUHV��ΖW�VHHPV�OLNH�D�PLQRU�GLHU-ence, but if you pick out the mandatory features you will end up with a much shorter list.

When working from the short list of mandatory features you can set the bar for user experience very high. Then later as you add more features you can work hard to maintain your high standards.

The designers at 37signals say, “It’s better to build half a product than a half-assed product.” Cutting features at the beginning is the best way to start building a great product.

Mistake 2: Forgetting State

A few weeks ago I was trying to get some work done on my iPhone. Hunting for a particular piece of data required me to drill a few layers deep into the app’s navigation. Then, realizing I needed something from the web as well, I quickly switched over to Safari.

When I returned to this app moments later, I was shown the top-level dashboard. Wait, what?

:KDW�KDSSHQHG�WR�WKH�SDJH�Ζ�KDG�ZRUNHG�VR�KDUG�WR�ȴQG"�$OWKRXJK�no data had been lost, because the app hadn’t remembered my navigation state, I felt as if the app had wasted my time. It created a frustrated user.

Your app should always try to act on behalf of the user. It should remember the last screen the user was visiting so they can immedi-DWHO\�SLFN�XS�ZKHUH�WKH\�OHIW�R�ZKHQ�WKH\�UHWXUQ�

Remembering state can also work across devices. Since a single person may use multiple devices in which the apps sync between them automatically, then the user will expect the data to sync as well.

For example, if an Angry Birds player clears multiple levels on his iPhone, then he shouldn’t be set to the beginning on his iPad.

State is a prime example of a UX issue being heavily impacted by backend functionality. If you (or a collaborator) don’t have backend development skills, you might want to try a back-end-as-a-service provider that has

pre-built this capability for you.

Mistake 3: Not Using Finger-Sized Tap Targets

Literally the biggest thing you can do to improve the usability of your app is to increase the tappable area for every button. You’re design-LQJ�IRU�ȴQJHUV�DQG�WKXPEV��QRW�PRXVH�FXUVRUV��ZKLFK�KDYH�D�KLJKHU�pointing accuracy).

Apple recommends a minimum of 44px by 44px for any element with which the user is expected to interact. The same recommendation applies to other smartphone platforms.

Of course, this guidance doesn’t mean that the button needs to appear that large. The tappable area can extend beyond the visible borders of the button. This will help users avoid the frustration of trying multiple times to tap an element. Just be careful if you position several buttons close to each other. Make sure that your extra tappable area doesn’t overlap with other buttons.

Mistake 4: Overcrowding Views

If you are used to designing for desktop computers, you’ll be VXUSULVHG�DW�MXVW�KRZ�OLWWOH�FRQWHQW�\RX�FDQ�ȴW�RQ�D�PRELOH�SKRQH��Because the screens are so much smaller, and tap targets need to be larger, views quickly become overcrowded. The solution is not to make elements smaller. That will just frustrate your users. Instead you need to add more views.

Whenever I start designing a new mobile app, I underestimate the number of required views. I start out thinking it will be a relatively VLPSOH�DSS�ZLWK�IHZHU�WKDQ�ȴYH�views, but then the views start DGGLQJ�XS��%HIRUH�ORQJ�Ζ�ȴQG�Ζ�QHHG�as many as 20 views to handle all the necessary tasks (registration, IRUJRW�SDVVZRUG��VHWWLQJ�QRWLȴFD-tion times, etc).

But that’s okay. It’s better to add more views than it is to overcrowd MXVW�D�IHZ�YLHZV��'HGLFDWLQJ�DQ�HQWLUH�YLHZ�WR�VHWWLQJ�D�QRWLȴFDWLRQ�WLPH�LV�MXVW�ȴQH��-XVW�PDNH�VXUH�WKDW�\RXU�WUDQVLWLRQV�DUH�TXLFN��buttons are clear, and that it’s easy to get back to the previous view.

Mistake 5: Keeping The User Waiting Without Feedback

Users have very little patience with mobile applications. As a mobile app developer, you might be frustrated with a user’s impatience because you understand that some tasks are always going to be slow, especially when the user has a weak network connection or an older device.

If your app is too slow or feels unre-sponsive, it only takes a single tap of the “home” button before your user is gone and never revisits your app. Luckily there is an easy way to help your users become more patient: Simply keep them informed.

Typically the problems with the user experience (UX) result from the accu-mulation of seemingly minor issues

/HWV�VD\�\RX�DUH�WU\LQJ�WR�SRSXODWH�WKH�GDWDEDVH�RQ�WKH�ȴUVW�UXQ�RI�D�newly installed app. By default, iOS shows a splash screen while the app is installing. Instead of the generic splash screen, you could display a simple message with a loading animation that reads, "Installing ..."

That step alone will grant you several seconds of patience. If it takes longer you can buy more time by changing the message. Next set it to "Loading database ..." If you need even more time wait several seconds and update the message again. "Loading interface ..." will give you still more time. Change the messages to what makes sense for your application, but keep the user informed.

You see, the user is just worried that your app has locked up. No one wants to keep staring at a screen that isn't going to do anything else. By changing the messages it shows that your application is still working on their behalf.

Mistake 6: Displaying The Wrong Keyboards

Have you ever typed in a URL and been happy to see a button on the keyboard that has “.com” on a single button? That single button saved you three additional keystrokes.

That little shortcut is possible because we know what type of data is H[SHFWHG�LQ�D�WH[W�ȴHOG��VR�ZH�FDQ�FKDQJH�WKH�NH\ERDUG�WR�PDNH�WKDW�easier. This means that you can add an “@” button on the main keyboard for entering emails or showing that “.com” button for URLs.

There are actually HLJKW�GLHUHQW�NH\ERDUG�YDULDWLRQV�available to you on L26��:KHQHYHU�\RX�SXW�LQ�D�WH[W�ȴHOG�\RX�FDQ�VHOHFW�ZKLFK�NH\ERDUG�should be used to input the content. These range from the default NH\ERDUG�WR�QXPEHU�NH\ERDUGV�WKDW�DUH�HQWLUHO\�GLHUHQW��ZLWK�ORWV�RI�subtle variations in between. Look through the options and choose the RQH�WKDW�PDNHV�WKH�PRVW�VHQVH�IRU�HDFK�ȴHOG�

You can also choose the keyboards on mobile web apps by changing the LQSXW�W\SH��1RUPDOO\�IRU�IRUP�ȴHOGV�we use <input type=”text” /> and <input type=”password” />, but in HTML5 even more options are avail-able. The one you should use most often is <input type=”email” />. 9LVXDOO\�LW�GRHVQȇW�ORRN�GLHUHQW�IURP�a standard text input, but iOS and Android will automatically display a

keyboard with a period and an @ symbol to make it quicker to enter email addresses.

Mistake 7: Failing To Do Usability Testing (Or Ignoring The Results)

Typically when you develop an app you know the product so well that you can’t accurately judge how easy it is to use for someone experi-HQFLQJ�LW�IRU�WKH�ȴUVW�WLPH��<RX�DUH�VLPSO\�WRR�FORVH�WR�LW��&RQFHSWV�WKDW�are intuitive to you, since you designed them, may need more expla-nation for a new user. The solution is to conduct usability testing.

That may sound like a fancy term, but it really can be quite simple. Find a friend or unsuspecting stranger who can give unbiased feed-back. Hand them a phone running your app and ask them to com-SOHWH�D�VSHFLȴF�WDVN��VXFK�DV�Ȋ&UHDWH�D�QHZ�WR�GR�LWHP�ȋ�Resist the urge to coach them. Just watch what they do, FDWDORJXH�ZKHUH�WKH\�JHW�FRQIXVHG��DQG�JDXJH�KRZ�TXLFNO\�WKH\�ȴQG�the necessary buttons.

It’s best if you can get them to verbalize their thoughts in this process.

Take notes as you watch them. Once they complete a task give them another one and keep watching. This process can be invaluable, provided the participant feels free to share his or her unvarnished opinion.

$IWHU�\RXȇYH�FDSWXUHG�IHHGEDFN�IURP�D�IHZ�SHRSOH��PDNH�WKH�ȴ[HV�before testing with others. Generally there’s little need to conduct user testing with lots of people. You’ll reach the point of diminishing returns quickly. I’ve consistently found that users encounter 90% of the same issues.

Using potential customers or at least people in your target market is best, but almost anyone will do. Just weigh the value of their feedback based on how close they are to your target customer.

Pitfall 8: Ignoring Speed & Caching

When implementing features and designing a great user experience, it can be easy to forget that VSHHG�LV�D�IHDWXUH. In fact, if your app is slow, your users may become frustrated and never even try the DSS�GLHUHQWLDWLQJ�IHDWXUHV�\RX�VSHQW�VR�PXFK�WLPH�EXLOGLQJ�

Facebook recently released an update to their iOS app. This update dramatically improved the user experience, but visually very little was GLHUHQW��6R�ZKDW�PDGH�WKH�GLHUHQFH"

Their entire update focused on making the app fast. Facebook, like many apps, needs to get almost all of their data from a server that

was slowing down the entire experi-ence. By decreasing requests and implementing caching, the speed of the app improved so much you could see user reviews on the App Store pointing it out. Caching your data to improve load speed is another area that a thoughtfully architected backend can provide -- and, in doing so, radically improve the user experi-

ence of your application.

3LWIDOO����2YHUXVLQJ�3XVK�1RWLȴFDWLRQV

Many apps need to be used actively in order for the developer to generate revenue (e.g., increasing views for advertisements or enticing users to make in-app purchases). So how do developers get users to come back?

3XVK�QRWLȴFDWLRQV�DUH�RQH�RSWLRQ��EXW�PDQ\�GHYHORSHUV�XVH�WKHP�poorly. Do you really want to be reminded to use that app you never FDUHG�DERXW�LQ�WKH�ȴUVW�SODFH"�ΖQ�WKDW�FDVH�D�SRRUO\�WDUJHWHG�SXVK�QRWLȴFDWLRQ�PD\�EH�WKH�ȴQDO�VWUDZ�QHHGHG�IRU�WKH�XVHU�WR�XQLQVWDOO�the app.

7KDWȇV�QRW�WR�VD\�\RX�VKRXOGQȇW�XVH�SXVK�QRWLȴFDWLRQV��EHFDXVH�\RX�should. Just be smart about it.

ΖI�\RX�VHQG�WDUJHWHG�QRWLȴFDWLRQV�EDVHG�RQ�D�XVHUȇV�SUHIHUHQFHV�RU�location it can help make your app more sticky and keep them coming back. This is just another reason to have a server-side com-ponent to your application. The better your information about your

customers, the more targeted you can be in your interactions with them.

$OO�WKLV�ZLOO�VDYH�\RX�IURP�VHQGLQJ�D�PDVV�SXVK�QRWLȴFDWLRQ�LQ�D�desperate attempt to get some of your users back.

Wrapping Up

Many of these mistakes are easy to make, but luckily most are easy to ȴ[�DV�ZHOO��ΖW�WDNHV�DQ�DWWHQWLRQ�WR�GHWDLO�WKURXJKRXW�HYHU\�VWHS�RI�WKH�DSS�FUHDWLRQ�SURFHVV�WR�ȴQLVK�ZLWK�D�JUHDW�XVHU�H[SHULHQFH�

1HDU�WKH�ODXQFK�RI�D�QHZ�DSS�Ζ�ȴQG�LW�KHOSIXO�WR�JHW�DZD\�IURP�P\�normal design process and try to see the application as a user. Start

at the beginning and go through the VHWXS�VWHSV�H[DFWO\�DV�\RXU�ȴUVW�users will. Take notes at every juncture, paying special attention to SODFHV�LQ�WKH�ȵRZ�WKDW�GRQȇW�PDNH�complete sense or could cause confusion.

Write down a to-do item for each spacing issue, every sentence of copy that isn’t clear, and each bug you encounter -- especially the

things you didn’t have time to deal with when you were building the feature.

<RX�GRQȇW�QHFHVVDULO\�KDYH�WR�ȴ[�HYHU\WKLQJ�RQ�WKDW�OLVW��EXW�LW�LV�important to be aware of everything your users may encounter. Then when you are back in your design or development mindset you can power through many of those tasks quite quickly.

Though if you take nothing else away from this, I want you to start doing usability testing. It really does not have to be complicated. Just watch your users as they use your product. You will learn so much in very little time.

HOW TO AVOID 9 COMMON MOBILE UX MISTAKES 5

No one sets out to create a poorly designed app. Every project begins with high hopes and great expectations, but it’s amazing how quickly app design can start to unravel. Typically the problems with the user experience (UX) result from the accumulation of seemingly minor issues -- compounding imperfections that ultimately cause users to quit the app and never come back.

Many of these small mistakes emerge early on in the process, long before the visual design is even considered. Early decisions, like the initial feature set and how your backend system will work, can have a dramatic impact on the UX of the entire project.

This eBook explores nine of the most common UX pitfalls in mobile app design. It highlights the traps so that app developers know how to avoid them. But if you’ve made any of these mistakes, no need to worry. The eBook also explains how to overcome the setback.

Mistake 1: Not Simplifying The Feature Set

If you want to build a product that is simple to use, then creating a simple product is a good place to start. We tend to think of all the wonderful things our app could do, but then things get messy when we try to implement the entire list of possible features. So the trick is to plan everything you might want in the application, then pare down the list to only the most important items. This is sometimes referred to as arriving at your MVP, or Minimum Viable Product, but I prefer the following characterization by Dan Cederholm of SimpleBits: “Dream big, implement small.”

Analog as it is, for me it works best if I write everything down on paper and then circle the absolutely critical features. I do this rather WKDQ�FURVVLQJ�RXW�WKH�RSWLRQDO�IHDWXUHV��ΖW�VHHPV�OLNH�D�PLQRU�GLHU-ence, but if you pick out the mandatory features you will end up with a much shorter list.

When working from the short list of mandatory features you can set the bar for user experience very high. Then later as you add more features you can work hard to maintain your high standards.

The designers at 37signals say, “It’s better to build half a product than a half-assed product.” Cutting features at the beginning is the best way to start building a great product.

Mistake 2: Forgetting State

A few weeks ago I was trying to get some work done on my iPhone. Hunting for a particular piece of data required me to drill a few layers deep into the app’s navigation. Then, realizing I needed something from the web as well, I quickly switched over to Safari.

When I returned to this app moments later, I was shown the top-level dashboard. Wait, what?

:KDW�KDSSHQHG�WR�WKH�SDJH�Ζ�KDG�ZRUNHG�VR�KDUG�WR�ȴQG"�$OWKRXJK�no data had been lost, because the app hadn’t remembered my navigation state, I felt as if the app had wasted my time. It created a frustrated user.

Your app should always try to act on behalf of the user. It should remember the last screen the user was visiting so they can immedi-DWHO\�SLFN�XS�ZKHUH�WKH\�OHIW�R�ZKHQ�WKH\�UHWXUQ�

Remembering state can also work across devices. Since a single person may use multiple devices in which the apps sync between them automatically, then the user will expect the data to sync as well.

For example, if an Angry Birds player clears multiple levels on his iPhone, then he shouldn’t be set to the beginning on his iPad.

State is a prime example of a UX issue being heavily impacted by backend functionality. If you (or a collaborator) don’t have backend development skills, you might want to try a back-end-as-a-service provider that has

pre-built this capability for you.

Mistake 3: Not Using Finger-Sized Tap Targets

Literally the biggest thing you can do to improve the usability of your app is to increase the tappable area for every button. You’re design-LQJ�IRU�ȴQJHUV�DQG�WKXPEV��QRW�PRXVH�FXUVRUV��ZKLFK�KDYH�D�KLJKHU�pointing accuracy).

Apple recommends a minimum of 44px by 44px for any element with which the user is expected to interact. The same recommendation applies to other smartphone platforms.

Of course, this guidance doesn’t mean that the button needs to appear that large. The tappable area can extend beyond the visible borders of the button. This will help users avoid the frustration of trying multiple times to tap an element. Just be careful if you position several buttons close to each other. Make sure that your extra tappable area doesn’t overlap with other buttons.

Mistake 4: Overcrowding Views

If you are used to designing for desktop computers, you’ll be VXUSULVHG�DW�MXVW�KRZ�OLWWOH�FRQWHQW�\RX�FDQ�ȴW�RQ�D�PRELOH�SKRQH��Because the screens are so much smaller, and tap targets need to be larger, views quickly become overcrowded. The solution is not to make elements smaller. That will just frustrate your users. Instead you need to add more views.

Whenever I start designing a new mobile app, I underestimate the number of required views. I start out thinking it will be a relatively VLPSOH�DSS�ZLWK�IHZHU�WKDQ�ȴYH�views, but then the views start DGGLQJ�XS��%HIRUH�ORQJ�Ζ�ȴQG�Ζ�QHHG�as many as 20 views to handle all the necessary tasks (registration, IRUJRW�SDVVZRUG��VHWWLQJ�QRWLȴFD-tion times, etc).

But that’s okay. It’s better to add more views than it is to overcrowd MXVW�D�IHZ�YLHZV��'HGLFDWLQJ�DQ�HQWLUH�YLHZ�WR�VHWWLQJ�D�QRWLȴFDWLRQ�WLPH�LV�MXVW�ȴQH��-XVW�PDNH�VXUH�WKDW�\RXU�WUDQVLWLRQV�DUH�TXLFN��buttons are clear, and that it’s easy to get back to the previous view.

Mistake 5: Keeping The User Waiting Without Feedback

Users have very little patience with mobile applications. As a mobile app developer, you might be frustrated with a user’s impatience because you understand that some tasks are always going to be slow, especially when the user has a weak network connection or an older device.

If your app is too slow or feels unre-sponsive, it only takes a single tap of the “home” button before your user is gone and never revisits your app. Luckily there is an easy way to help your users become more patient: Simply keep them informed.

Typically the problems with the user experience (UX) result from the accu-mulation of seemingly minor issues

/HWV�VD\�\RX�DUH�WU\LQJ�WR�SRSXODWH�WKH�GDWDEDVH�RQ�WKH�ȴUVW�UXQ�RI�D�newly installed app. By default, iOS shows a splash screen while the app is installing. Instead of the generic splash screen, you could display a simple message with a loading animation that reads, "Installing ..."

That step alone will grant you several seconds of patience. If it takes longer you can buy more time by changing the message. Next set it to "Loading database ..." If you need even more time wait several seconds and update the message again. "Loading interface ..." will give you still more time. Change the messages to what makes sense for your application, but keep the user informed.

You see, the user is just worried that your app has locked up. No one wants to keep staring at a screen that isn't going to do anything else. By changing the messages it shows that your application is still working on their behalf.

Mistake 6: Displaying The Wrong Keyboards

Have you ever typed in a URL and been happy to see a button on the keyboard that has “.com” on a single button? That single button saved you three additional keystrokes.

That little shortcut is possible because we know what type of data is H[SHFWHG�LQ�D�WH[W�ȴHOG��VR�ZH�FDQ�FKDQJH�WKH�NH\ERDUG�WR�PDNH�WKDW�easier. This means that you can add an “@” button on the main keyboard for entering emails or showing that “.com” button for URLs.

There are actually HLJKW�GLHUHQW�NH\ERDUG�YDULDWLRQV�available to you on L26��:KHQHYHU�\RX�SXW�LQ�D�WH[W�ȴHOG�\RX�FDQ�VHOHFW�ZKLFK�NH\ERDUG�should be used to input the content. These range from the default NH\ERDUG�WR�QXPEHU�NH\ERDUGV�WKDW�DUH�HQWLUHO\�GLHUHQW��ZLWK�ORWV�RI�subtle variations in between. Look through the options and choose the RQH�WKDW�PDNHV�WKH�PRVW�VHQVH�IRU�HDFK�ȴHOG�

You can also choose the keyboards on mobile web apps by changing the LQSXW�W\SH��1RUPDOO\�IRU�IRUP�ȴHOGV�we use <input type=”text” /> and <input type=”password” />, but in HTML5 even more options are avail-able. The one you should use most often is <input type=”email” />. 9LVXDOO\�LW�GRHVQȇW�ORRN�GLHUHQW�IURP�a standard text input, but iOS and Android will automatically display a

keyboard with a period and an @ symbol to make it quicker to enter email addresses.

Mistake 7: Failing To Do Usability Testing (Or Ignoring The Results)

Typically when you develop an app you know the product so well that you can’t accurately judge how easy it is to use for someone experi-HQFLQJ�LW�IRU�WKH�ȴUVW�WLPH��<RX�DUH�VLPSO\�WRR�FORVH�WR�LW��&RQFHSWV�WKDW�are intuitive to you, since you designed them, may need more expla-nation for a new user. The solution is to conduct usability testing.

That may sound like a fancy term, but it really can be quite simple. Find a friend or unsuspecting stranger who can give unbiased feed-back. Hand them a phone running your app and ask them to com-SOHWH�D�VSHFLȴF�WDVN��VXFK�DV�Ȋ&UHDWH�D�QHZ�WR�GR�LWHP�ȋ�Resist the urge to coach them. Just watch what they do, FDWDORJXH�ZKHUH�WKH\�JHW�FRQIXVHG��DQG�JDXJH�KRZ�TXLFNO\�WKH\�ȴQG�the necessary buttons.

It’s best if you can get them to verbalize their thoughts in this process.

Take notes as you watch them. Once they complete a task give them another one and keep watching. This process can be invaluable, provided the participant feels free to share his or her unvarnished opinion.

$IWHU�\RXȇYH�FDSWXUHG�IHHGEDFN�IURP�D�IHZ�SHRSOH��PDNH�WKH�ȴ[HV�before testing with others. Generally there’s little need to conduct user testing with lots of people. You’ll reach the point of diminishing returns quickly. I’ve consistently found that users encounter 90% of the same issues.

Using potential customers or at least people in your target market is best, but almost anyone will do. Just weigh the value of their feedback based on how close they are to your target customer.

Pitfall 8: Ignoring Speed & Caching

When implementing features and designing a great user experience, it can be easy to forget that VSHHG�LV�D�IHDWXUH. In fact, if your app is slow, your users may become frustrated and never even try the DSS�GLHUHQWLDWLQJ�IHDWXUHV�\RX�VSHQW�VR�PXFK�WLPH�EXLOGLQJ�

Facebook recently released an update to their iOS app. This update dramatically improved the user experience, but visually very little was GLHUHQW��6R�ZKDW�PDGH�WKH�GLHUHQFH"

Their entire update focused on making the app fast. Facebook, like many apps, needs to get almost all of their data from a server that

was slowing down the entire experi-ence. By decreasing requests and implementing caching, the speed of the app improved so much you could see user reviews on the App Store pointing it out. Caching your data to improve load speed is another area that a thoughtfully architected backend can provide -- and, in doing so, radically improve the user experi-

ence of your application.

3LWIDOO����2YHUXVLQJ�3XVK�1RWLȴFDWLRQV

Many apps need to be used actively in order for the developer to generate revenue (e.g., increasing views for advertisements or enticing users to make in-app purchases). So how do developers get users to come back?

3XVK�QRWLȴFDWLRQV�DUH�RQH�RSWLRQ��EXW�PDQ\�GHYHORSHUV�XVH�WKHP�poorly. Do you really want to be reminded to use that app you never FDUHG�DERXW�LQ�WKH�ȴUVW�SODFH"�ΖQ�WKDW�FDVH�D�SRRUO\�WDUJHWHG�SXVK�QRWLȴFDWLRQ�PD\�EH�WKH�ȴQDO�VWUDZ�QHHGHG�IRU�WKH�XVHU�WR�XQLQVWDOO�the app.

7KDWȇV�QRW�WR�VD\�\RX�VKRXOGQȇW�XVH�SXVK�QRWLȴFDWLRQV��EHFDXVH�\RX�should. Just be smart about it.

ΖI�\RX�VHQG�WDUJHWHG�QRWLȴFDWLRQV�EDVHG�RQ�D�XVHUȇV�SUHIHUHQFHV�RU�location it can help make your app more sticky and keep them coming back. This is just another reason to have a server-side com-ponent to your application. The better your information about your

customers, the more targeted you can be in your interactions with them.

$OO�WKLV�ZLOO�VDYH�\RX�IURP�VHQGLQJ�D�PDVV�SXVK�QRWLȴFDWLRQ�LQ�D�desperate attempt to get some of your users back.

Wrapping Up

Many of these mistakes are easy to make, but luckily most are easy to ȴ[�DV�ZHOO��ΖW�WDNHV�DQ�DWWHQWLRQ�WR�GHWDLO�WKURXJKRXW�HYHU\�VWHS�RI�WKH�DSS�FUHDWLRQ�SURFHVV�WR�ȴQLVK�ZLWK�D�JUHDW�XVHU�H[SHULHQFH�

1HDU�WKH�ODXQFK�RI�D�QHZ�DSS�Ζ�ȴQG�LW�KHOSIXO�WR�JHW�DZD\�IURP�P\�normal design process and try to see the application as a user. Start

at the beginning and go through the VHWXS�VWHSV�H[DFWO\�DV�\RXU�ȴUVW�users will. Take notes at every juncture, paying special attention to SODFHV�LQ�WKH�ȵRZ�WKDW�GRQȇW�PDNH�complete sense or could cause confusion.

Write down a to-do item for each spacing issue, every sentence of copy that isn’t clear, and each bug you encounter -- especially the

things you didn’t have time to deal with when you were building the feature.

<RX�GRQȇW�QHFHVVDULO\�KDYH�WR�ȴ[�HYHU\WKLQJ�RQ�WKDW�OLVW��EXW�LW�LV�important to be aware of everything your users may encounter. Then when you are back in your design or development mindset you can power through many of those tasks quite quickly.

Though if you take nothing else away from this, I want you to start doing usability testing. It really does not have to be complicated. Just watch your users as they use your product. You will learn so much in very little time.

Click to tweet

“Typically the

problems with the

user experience

result from the

accumulation of

seemingly minor

issues.”

HOW TO AVOID 9 COMMON MOBILE UX MISTAKES 6

No one sets out to create a poorly designed app. Every project begins with high hopes and great expectations, but it’s amazing how quickly app design can start to unravel. Typically the problems with the user experience (UX) result from the accumulation of seemingly minor issues -- compounding imperfections that ultimately cause users to quit the app and never come back.

Many of these small mistakes emerge early on in the process, long before the visual design is even considered. Early decisions, like the initial feature set and how your backend system will work, can have a dramatic impact on the UX of the entire project.

This eBook explores nine of the most common UX pitfalls in mobile app design. It highlights the traps so that app developers know how to avoid them. But if you’ve made any of these mistakes, no need to worry. The eBook also explains how to overcome the setback.

Mistake 1: Not Simplifying The Feature Set

If you want to build a product that is simple to use, then creating a simple product is a good place to start. We tend to think of all the wonderful things our app could do, but then things get messy when we try to implement the entire list of possible features. So the trick is to plan everything you might want in the application, then pare down the list to only the most important items. This is sometimes referred to as arriving at your MVP, or Minimum Viable Product, but I prefer the following characterization by Dan Cederholm of SimpleBits: “Dream big, implement small.”

Analog as it is, for me it works best if I write everything down on paper and then circle the absolutely critical features. I do this rather WKDQ�FURVVLQJ�RXW�WKH�RSWLRQDO�IHDWXUHV��ΖW�VHHPV�OLNH�D�PLQRU�GLHU-ence, but if you pick out the mandatory features you will end up with a much shorter list.

When working from the short list of mandatory features you can set the bar for user experience very high. Then later as you add more features you can work hard to maintain your high standards.

The designers at 37signals say, “It’s better to build half a product than a half-assed product.” Cutting features at the beginning is the best way to start building a great product.

Mistake 2: Forgetting State

A few weeks ago I was trying to get some work done on my iPhone. Hunting for a particular piece of data required me to drill a few layers deep into the app’s navigation. Then, realizing I needed something from the web as well, I quickly switched over to Safari.

When I returned to this app moments later, I was shown the top-level dashboard. Wait, what?

:KDW�KDSSHQHG�WR�WKH�SDJH�Ζ�KDG�ZRUNHG�VR�KDUG�WR�ȴQG"�$OWKRXJK�no data had been lost, because the app hadn’t remembered my navigation state, I felt as if the app had wasted my time. It created a frustrated user.

Your app should always try to act on behalf of the user. It should remember the last screen the user was visiting so they can immedi-DWHO\�SLFN�XS�ZKHUH�WKH\�OHIW�R�ZKHQ�WKH\�UHWXUQ�

Remembering state can also work across devices. Since a single person may use multiple devices in which the apps sync between them automatically, then the user will expect the data to sync as well.

For example, if an Angry Birds player clears multiple levels on his iPhone, then he shouldn’t be set to the beginning on his iPad.

State is a prime example of a UX issue being heavily impacted by backend functionality. If you (or a collaborator) don’t have backend development skills, you might want to try a back-end-as-a-service provider that has

pre-built this capability for you.

Mistake 3: Not Using Finger-Sized Tap Targets

Literally the biggest thing you can do to improve the usability of your app is to increase the tappable area for every button. You’re design-LQJ�IRU�ȴQJHUV�DQG�WKXPEV��QRW�PRXVH�FXUVRUV��ZKLFK�KDYH�D�KLJKHU�pointing accuracy).

Apple recommends a minimum of 44px by 44px for any element with which the user is expected to interact. The same recommendation applies to other smartphone platforms.

Of course, this guidance doesn’t mean that the button needs to appear that large. The tappable area can extend beyond the visible borders of the button. This will help users avoid the frustration of trying multiple times to tap an element. Just be careful if you position several buttons close to each other. Make sure that your extra tappable area doesn’t overlap with other buttons.

Mistake 4: Overcrowding Views

If you are used to designing for desktop computers, you’ll be VXUSULVHG�DW�MXVW�KRZ�OLWWOH�FRQWHQW�\RX�FDQ�ȴW�RQ�D�PRELOH�SKRQH��Because the screens are so much smaller, and tap targets need to be larger, views quickly become overcrowded. The solution is not to make elements smaller. That will just frustrate your users. Instead you need to add more views.

Whenever I start designing a new mobile app, I underestimate the number of required views. I start out thinking it will be a relatively VLPSOH�DSS�ZLWK�IHZHU�WKDQ�ȴYH�views, but then the views start DGGLQJ�XS��%HIRUH�ORQJ�Ζ�ȴQG�Ζ�QHHG�as many as 20 views to handle all the necessary tasks (registration, IRUJRW�SDVVZRUG��VHWWLQJ�QRWLȴFD-tion times, etc).

But that’s okay. It’s better to add more views than it is to overcrowd MXVW�D�IHZ�YLHZV��'HGLFDWLQJ�DQ�HQWLUH�YLHZ�WR�VHWWLQJ�D�QRWLȴFDWLRQ�WLPH�LV�MXVW�ȴQH��-XVW�PDNH�VXUH�WKDW�\RXU�WUDQVLWLRQV�DUH�TXLFN��buttons are clear, and that it’s easy to get back to the previous view.

Mistake 5: Keeping The User Waiting Without Feedback

Users have very little patience with mobile applications. As a mobile app developer, you might be frustrated with a user’s impatience because you understand that some tasks are always going to be slow, especially when the user has a weak network connection or an older device.

If your app is too slow or feels unre-sponsive, it only takes a single tap of the “home” button before your user is gone and never revisits your app. Luckily there is an easy way to help your users become more patient: Simply keep them informed.

Typically the problems with the user experience (UX) result from the accu-mulation of seemingly minor issues

/HWV�VD\�\RX�DUH�WU\LQJ�WR�SRSXODWH�WKH�GDWDEDVH�RQ�WKH�ȴUVW�UXQ�RI�D�newly installed app. By default, iOS shows a splash screen while the app is installing. Instead of the generic splash screen, you could display a simple message with a loading animation that reads, "Installing ..."

That step alone will grant you several seconds of patience. If it takes longer you can buy more time by changing the message. Next set it to "Loading database ..." If you need even more time wait several seconds and update the message again. "Loading interface ..." will give you still more time. Change the messages to what makes sense for your application, but keep the user informed.

You see, the user is just worried that your app has locked up. No one wants to keep staring at a screen that isn't going to do anything else. By changing the messages it shows that your application is still working on their behalf.

Mistake 6: Displaying The Wrong Keyboards

Have you ever typed in a URL and been happy to see a button on the keyboard that has “.com” on a single button? That single button saved you three additional keystrokes.

That little shortcut is possible because we know what type of data is H[SHFWHG�LQ�D�WH[W�ȴHOG��VR�ZH�FDQ�FKDQJH�WKH�NH\ERDUG�WR�PDNH�WKDW�easier. This means that you can add an “@” button on the main keyboard for entering emails or showing that “.com” button for URLs.

There are actually HLJKW�GLHUHQW�NH\ERDUG�YDULDWLRQV�available to you on L26��:KHQHYHU�\RX�SXW�LQ�D�WH[W�ȴHOG�\RX�FDQ�VHOHFW�ZKLFK�NH\ERDUG�should be used to input the content. These range from the default NH\ERDUG�WR�QXPEHU�NH\ERDUGV�WKDW�DUH�HQWLUHO\�GLHUHQW��ZLWK�ORWV�RI�subtle variations in between. Look through the options and choose the RQH�WKDW�PDNHV�WKH�PRVW�VHQVH�IRU�HDFK�ȴHOG�

You can also choose the keyboards on mobile web apps by changing the LQSXW�W\SH��1RUPDOO\�IRU�IRUP�ȴHOGV�we use <input type=”text” /> and <input type=”password” />, but in HTML5 even more options are avail-able. The one you should use most often is <input type=”email” />. 9LVXDOO\�LW�GRHVQȇW�ORRN�GLHUHQW�IURP�a standard text input, but iOS and Android will automatically display a

keyboard with a period and an @ symbol to make it quicker to enter email addresses.

Mistake 7: Failing To Do Usability Testing (Or Ignoring The Results)

Typically when you develop an app you know the product so well that you can’t accurately judge how easy it is to use for someone experi-HQFLQJ�LW�IRU�WKH�ȴUVW�WLPH��<RX�DUH�VLPSO\�WRR�FORVH�WR�LW��&RQFHSWV�WKDW�are intuitive to you, since you designed them, may need more expla-nation for a new user. The solution is to conduct usability testing.

That may sound like a fancy term, but it really can be quite simple. Find a friend or unsuspecting stranger who can give unbiased feed-back. Hand them a phone running your app and ask them to com-SOHWH�D�VSHFLȴF�WDVN��VXFK�DV�Ȋ&UHDWH�D�QHZ�WR�GR�LWHP�ȋ�Resist the urge to coach them. Just watch what they do, FDWDORJXH�ZKHUH�WKH\�JHW�FRQIXVHG��DQG�JDXJH�KRZ�TXLFNO\�WKH\�ȴQG�the necessary buttons.

It’s best if you can get them to verbalize their thoughts in this process.

Take notes as you watch them. Once they complete a task give them another one and keep watching. This process can be invaluable, provided the participant feels free to share his or her unvarnished opinion.

$IWHU�\RXȇYH�FDSWXUHG�IHHGEDFN�IURP�D�IHZ�SHRSOH��PDNH�WKH�ȴ[HV�before testing with others. Generally there’s little need to conduct user testing with lots of people. You’ll reach the point of diminishing returns quickly. I’ve consistently found that users encounter 90% of the same issues.

Using potential customers or at least people in your target market is best, but almost anyone will do. Just weigh the value of their feedback based on how close they are to your target customer.

Pitfall 8: Ignoring Speed & Caching

When implementing features and designing a great user experience, it can be easy to forget that VSHHG�LV�D�IHDWXUH. In fact, if your app is slow, your users may become frustrated and never even try the DSS�GLHUHQWLDWLQJ�IHDWXUHV�\RX�VSHQW�VR�PXFK�WLPH�EXLOGLQJ�

Facebook recently released an update to their iOS app. This update dramatically improved the user experience, but visually very little was GLHUHQW��6R�ZKDW�PDGH�WKH�GLHUHQFH"

Their entire update focused on making the app fast. Facebook, like many apps, needs to get almost all of their data from a server that

was slowing down the entire experi-ence. By decreasing requests and implementing caching, the speed of the app improved so much you could see user reviews on the App Store pointing it out. Caching your data to improve load speed is another area that a thoughtfully architected backend can provide -- and, in doing so, radically improve the user experi-

ence of your application.

3LWIDOO����2YHUXVLQJ�3XVK�1RWLȴFDWLRQV

Many apps need to be used actively in order for the developer to generate revenue (e.g., increasing views for advertisements or enticing users to make in-app purchases). So how do developers get users to come back?

3XVK�QRWLȴFDWLRQV�DUH�RQH�RSWLRQ��EXW�PDQ\�GHYHORSHUV�XVH�WKHP�poorly. Do you really want to be reminded to use that app you never FDUHG�DERXW�LQ�WKH�ȴUVW�SODFH"�ΖQ�WKDW�FDVH�D�SRRUO\�WDUJHWHG�SXVK�QRWLȴFDWLRQ�PD\�EH�WKH�ȴQDO�VWUDZ�QHHGHG�IRU�WKH�XVHU�WR�XQLQVWDOO�the app.

7KDWȇV�QRW�WR�VD\�\RX�VKRXOGQȇW�XVH�SXVK�QRWLȴFDWLRQV��EHFDXVH�\RX�should. Just be smart about it.

ΖI�\RX�VHQG�WDUJHWHG�QRWLȴFDWLRQV�EDVHG�RQ�D�XVHUȇV�SUHIHUHQFHV�RU�location it can help make your app more sticky and keep them coming back. This is just another reason to have a server-side com-ponent to your application. The better your information about your

customers, the more targeted you can be in your interactions with them.

$OO�WKLV�ZLOO�VDYH�\RX�IURP�VHQGLQJ�D�PDVV�SXVK�QRWLȴFDWLRQ�LQ�D�desperate attempt to get some of your users back.

Wrapping Up

Many of these mistakes are easy to make, but luckily most are easy to ȴ[�DV�ZHOO��ΖW�WDNHV�DQ�DWWHQWLRQ�WR�GHWDLO�WKURXJKRXW�HYHU\�VWHS�RI�WKH�DSS�FUHDWLRQ�SURFHVV�WR�ȴQLVK�ZLWK�D�JUHDW�XVHU�H[SHULHQFH�

1HDU�WKH�ODXQFK�RI�D�QHZ�DSS�Ζ�ȴQG�LW�KHOSIXO�WR�JHW�DZD\�IURP�P\�normal design process and try to see the application as a user. Start

at the beginning and go through the VHWXS�VWHSV�H[DFWO\�DV�\RXU�ȴUVW�users will. Take notes at every juncture, paying special attention to SODFHV�LQ�WKH�ȵRZ�WKDW�GRQȇW�PDNH�complete sense or could cause confusion.

Write down a to-do item for each spacing issue, every sentence of copy that isn’t clear, and each bug you encounter -- especially the

things you didn’t have time to deal with when you were building the feature.

<RX�GRQȇW�QHFHVVDULO\�KDYH�WR�ȴ[�HYHU\WKLQJ�RQ�WKDW�OLVW��EXW�LW�LV�important to be aware of everything your users may encounter. Then when you are back in your design or development mindset you can power through many of those tasks quite quickly.

Though if you take nothing else away from this, I want you to start doing usability testing. It really does not have to be complicated. Just watch your users as they use your product. You will learn so much in very little time.

HOW TO AVOID 9 COMMON MOBILE UX MISTAKES 7

No one sets out to create a poorly designed app. Every project begins with high hopes and great expectations, but it’s amazing how quickly app design can start to unravel. Typically the problems with the user experience (UX) result from the accumulation of seemingly minor issues -- compounding imperfections that ultimately cause users to quit the app and never come back.

Many of these small mistakes emerge early on in the process, long before the visual design is even considered. Early decisions, like the initial feature set and how your backend system will work, can have a dramatic impact on the UX of the entire project.

This eBook explores nine of the most common UX pitfalls in mobile app design. It highlights the traps so that app developers know how to avoid them. But if you’ve made any of these mistakes, no need to worry. The eBook also explains how to overcome the setback.

Mistake 1: Not Simplifying The Feature Set

If you want to build a product that is simple to use, then creating a simple product is a good place to start. We tend to think of all the wonderful things our app could do, but then things get messy when we try to implement the entire list of possible features. So the trick is to plan everything you might want in the application, then pare down the list to only the most important items. This is sometimes referred to as arriving at your MVP, or Minimum Viable Product, but I prefer the following characterization by Dan Cederholm of SimpleBits: “Dream big, implement small.”

Analog as it is, for me it works best if I write everything down on paper and then circle the absolutely critical features. I do this rather WKDQ�FURVVLQJ�RXW�WKH�RSWLRQDO�IHDWXUHV��ΖW�VHHPV�OLNH�D�PLQRU�GLHU-ence, but if you pick out the mandatory features you will end up with a much shorter list.

When working from the short list of mandatory features you can set the bar for user experience very high. Then later as you add more features you can work hard to maintain your high standards.

The designers at 37signals say, “It’s better to build half a product than a half-assed product.” Cutting features at the beginning is the best way to start building a great product.

Mistake 2: Forgetting State

A few weeks ago I was trying to get some work done on my iPhone. Hunting for a particular piece of data required me to drill a few layers deep into the app’s navigation. Then, realizing I needed something from the web as well, I quickly switched over to Safari.

When I returned to this app moments later, I was shown the top-level dashboard. Wait, what?

:KDW�KDSSHQHG�WR�WKH�SDJH�Ζ�KDG�ZRUNHG�VR�KDUG�WR�ȴQG"�$OWKRXJK�no data had been lost, because the app hadn’t remembered my navigation state, I felt as if the app had wasted my time. It created a frustrated user.

Your app should always try to act on behalf of the user. It should remember the last screen the user was visiting so they can immedi-DWHO\�SLFN�XS�ZKHUH�WKH\�OHIW�R�ZKHQ�WKH\�UHWXUQ�

Remembering state can also work across devices. Since a single person may use multiple devices in which the apps sync between them automatically, then the user will expect the data to sync as well.

For example, if an Angry Birds player clears multiple levels on his iPhone, then he shouldn’t be set to the beginning on his iPad.

State is a prime example of a UX issue being heavily impacted by backend functionality. If you (or a collaborator) don’t have backend development skills, you might want to try a back-end-as-a-service provider that has

pre-built this capability for you.

Mistake 3: Not Using Finger-Sized Tap Targets

Literally the biggest thing you can do to improve the usability of your app is to increase the tappable area for every button. You’re design-LQJ�IRU�ȴQJHUV�DQG�WKXPEV��QRW�PRXVH�FXUVRUV��ZKLFK�KDYH�D�KLJKHU�pointing accuracy).

Apple recommends a minimum of 44px by 44px for any element with which the user is expected to interact. The same recommendation applies to other smartphone platforms.

Of course, this guidance doesn’t mean that the button needs to appear that large. The tappable area can extend beyond the visible borders of the button. This will help users avoid the frustration of trying multiple times to tap an element. Just be careful if you position several buttons close to each other. Make sure that your extra tappable area doesn’t overlap with other buttons.

Mistake 4: Overcrowding Views

If you are used to designing for desktop computers, you’ll be VXUSULVHG�DW�MXVW�KRZ�OLWWOH�FRQWHQW�\RX�FDQ�ȴW�RQ�D�PRELOH�SKRQH��Because the screens are so much smaller, and tap targets need to be larger, views quickly become overcrowded. The solution is not to make elements smaller. That will just frustrate your users. Instead you need to add more views.

Whenever I start designing a new mobile app, I underestimate the number of required views. I start out thinking it will be a relatively VLPSOH�DSS�ZLWK�IHZHU�WKDQ�ȴYH�views, but then the views start DGGLQJ�XS��%HIRUH�ORQJ�Ζ�ȴQG�Ζ�QHHG�as many as 20 views to handle all the necessary tasks (registration, IRUJRW�SDVVZRUG��VHWWLQJ�QRWLȴFD-tion times, etc).

But that’s okay. It’s better to add more views than it is to overcrowd MXVW�D�IHZ�YLHZV��'HGLFDWLQJ�DQ�HQWLUH�YLHZ�WR�VHWWLQJ�D�QRWLȴFDWLRQ�WLPH�LV�MXVW�ȴQH��-XVW�PDNH�VXUH�WKDW�\RXU�WUDQVLWLRQV�DUH�TXLFN��buttons are clear, and that it’s easy to get back to the previous view.

Mistake 5: Keeping The User Waiting Without Feedback

Users have very little patience with mobile applications. As a mobile app developer, you might be frustrated with a user’s impatience because you understand that some tasks are always going to be slow, especially when the user has a weak network connection or an older device.

If your app is too slow or feels unre-sponsive, it only takes a single tap of the “home” button before your user is gone and never revisits your app. Luckily there is an easy way to help your users become more patient: Simply keep them informed.

Typically the problems with the user experience (UX) result from the accu-mulation of seemingly minor issues

/HWV�VD\�\RX�DUH�WU\LQJ�WR�SRSXODWH�WKH�GDWDEDVH�RQ�WKH�ȴUVW�UXQ�RI�D�newly installed app. By default, iOS shows a splash screen while the app is installing. Instead of the generic splash screen, you could display a simple message with a loading animation that reads, "Installing ..."

That step alone will grant you several seconds of patience. If it takes longer you can buy more time by changing the message. Next set it to "Loading database ..." If you need even more time wait several seconds and update the message again. "Loading interface ..." will give you still more time. Change the messages to what makes sense for your application, but keep the user informed.

You see, the user is just worried that your app has locked up. No one wants to keep staring at a screen that isn't going to do anything else. By changing the messages it shows that your application is still working on their behalf.

Mistake 6: Displaying The Wrong Keyboards

Have you ever typed in a URL and been happy to see a button on the keyboard that has “.com” on a single button? That single button saved you three additional keystrokes.

That little shortcut is possible because we know what type of data is H[SHFWHG�LQ�D�WH[W�ȴHOG��VR�ZH�FDQ�FKDQJH�WKH�NH\ERDUG�WR�PDNH�WKDW�easier. This means that you can add an “@” button on the main keyboard for entering emails or showing that “.com” button for URLs.

There are actually HLJKW�GLHUHQW�NH\ERDUG�YDULDWLRQV�available to you on L26��:KHQHYHU�\RX�SXW�LQ�D�WH[W�ȴHOG�\RX�FDQ�VHOHFW�ZKLFK�NH\ERDUG�should be used to input the content. These range from the default NH\ERDUG�WR�QXPEHU�NH\ERDUGV�WKDW�DUH�HQWLUHO\�GLHUHQW��ZLWK�ORWV�RI�subtle variations in between. Look through the options and choose the RQH�WKDW�PDNHV�WKH�PRVW�VHQVH�IRU�HDFK�ȴHOG�

You can also choose the keyboards on mobile web apps by changing the LQSXW�W\SH��1RUPDOO\�IRU�IRUP�ȴHOGV�we use <input type=”text” /> and <input type=”password” />, but in HTML5 even more options are avail-able. The one you should use most often is <input type=”email” />. 9LVXDOO\�LW�GRHVQȇW�ORRN�GLHUHQW�IURP�a standard text input, but iOS and Android will automatically display a

keyboard with a period and an @ symbol to make it quicker to enter email addresses.

Mistake 7: Failing To Do Usability Testing (Or Ignoring The Results)

Typically when you develop an app you know the product so well that you can’t accurately judge how easy it is to use for someone experi-HQFLQJ�LW�IRU�WKH�ȴUVW�WLPH��<RX�DUH�VLPSO\�WRR�FORVH�WR�LW��&RQFHSWV�WKDW�are intuitive to you, since you designed them, may need more expla-nation for a new user. The solution is to conduct usability testing.

That may sound like a fancy term, but it really can be quite simple. Find a friend or unsuspecting stranger who can give unbiased feed-back. Hand them a phone running your app and ask them to com-SOHWH�D�VSHFLȴF�WDVN��VXFK�DV�Ȋ&UHDWH�D�QHZ�WR�GR�LWHP�ȋ�Resist the urge to coach them. Just watch what they do, FDWDORJXH�ZKHUH�WKH\�JHW�FRQIXVHG��DQG�JDXJH�KRZ�TXLFNO\�WKH\�ȴQG�the necessary buttons.

It’s best if you can get them to verbalize their thoughts in this process.

Take notes as you watch them. Once they complete a task give them another one and keep watching. This process can be invaluable, provided the participant feels free to share his or her unvarnished opinion.

$IWHU�\RXȇYH�FDSWXUHG�IHHGEDFN�IURP�D�IHZ�SHRSOH��PDNH�WKH�ȴ[HV�before testing with others. Generally there’s little need to conduct user testing with lots of people. You’ll reach the point of diminishing returns quickly. I’ve consistently found that users encounter 90% of the same issues.

Using potential customers or at least people in your target market is best, but almost anyone will do. Just weigh the value of their feedback based on how close they are to your target customer.

Pitfall 8: Ignoring Speed & Caching

When implementing features and designing a great user experience, it can be easy to forget that VSHHG�LV�D�IHDWXUH. In fact, if your app is slow, your users may become frustrated and never even try the DSS�GLHUHQWLDWLQJ�IHDWXUHV�\RX�VSHQW�VR�PXFK�WLPH�EXLOGLQJ�

Facebook recently released an update to their iOS app. This update dramatically improved the user experience, but visually very little was GLHUHQW��6R�ZKDW�PDGH�WKH�GLHUHQFH"

Their entire update focused on making the app fast. Facebook, like many apps, needs to get almost all of their data from a server that

was slowing down the entire experi-ence. By decreasing requests and implementing caching, the speed of the app improved so much you could see user reviews on the App Store pointing it out. Caching your data to improve load speed is another area that a thoughtfully architected backend can provide -- and, in doing so, radically improve the user experi-

ence of your application.

3LWIDOO����2YHUXVLQJ�3XVK�1RWLȴFDWLRQV

Many apps need to be used actively in order for the developer to generate revenue (e.g., increasing views for advertisements or enticing users to make in-app purchases). So how do developers get users to come back?

3XVK�QRWLȴFDWLRQV�DUH�RQH�RSWLRQ��EXW�PDQ\�GHYHORSHUV�XVH�WKHP�poorly. Do you really want to be reminded to use that app you never FDUHG�DERXW�LQ�WKH�ȴUVW�SODFH"�ΖQ�WKDW�FDVH�D�SRRUO\�WDUJHWHG�SXVK�QRWLȴFDWLRQ�PD\�EH�WKH�ȴQDO�VWUDZ�QHHGHG�IRU�WKH�XVHU�WR�XQLQVWDOO�the app.

7KDWȇV�QRW�WR�VD\�\RX�VKRXOGQȇW�XVH�SXVK�QRWLȴFDWLRQV��EHFDXVH�\RX�should. Just be smart about it.

ΖI�\RX�VHQG�WDUJHWHG�QRWLȴFDWLRQV�EDVHG�RQ�D�XVHUȇV�SUHIHUHQFHV�RU�location it can help make your app more sticky and keep them coming back. This is just another reason to have a server-side com-ponent to your application. The better your information about your

customers, the more targeted you can be in your interactions with them.

$OO�WKLV�ZLOO�VDYH�\RX�IURP�VHQGLQJ�D�PDVV�SXVK�QRWLȴFDWLRQ�LQ�D�desperate attempt to get some of your users back.

Wrapping Up

Many of these mistakes are easy to make, but luckily most are easy to ȴ[�DV�ZHOO��ΖW�WDNHV�DQ�DWWHQWLRQ�WR�GHWDLO�WKURXJKRXW�HYHU\�VWHS�RI�WKH�DSS�FUHDWLRQ�SURFHVV�WR�ȴQLVK�ZLWK�D�JUHDW�XVHU�H[SHULHQFH�

1HDU�WKH�ODXQFK�RI�D�QHZ�DSS�Ζ�ȴQG�LW�KHOSIXO�WR�JHW�DZD\�IURP�P\�normal design process and try to see the application as a user. Start

at the beginning and go through the VHWXS�VWHSV�H[DFWO\�DV�\RXU�ȴUVW�users will. Take notes at every juncture, paying special attention to SODFHV�LQ�WKH�ȵRZ�WKDW�GRQȇW�PDNH�complete sense or could cause confusion.

Write down a to-do item for each spacing issue, every sentence of copy that isn’t clear, and each bug you encounter -- especially the

things you didn’t have time to deal with when you were building the feature.

<RX�GRQȇW�QHFHVVDULO\�KDYH�WR�ȴ[�HYHU\WKLQJ�RQ�WKDW�OLVW��EXW�LW�LV�important to be aware of everything your users may encounter. Then when you are back in your design or development mindset you can power through many of those tasks quite quickly.

Though if you take nothing else away from this, I want you to start doing usability testing. It really does not have to be complicated. Just watch your users as they use your product. You will learn so much in very little time.

HOW TO AVOID 9 COMMON MOBILE UX MISTAKES 8

No one sets out to create a poorly designed app. Every project begins with high hopes and great expectations, but it’s amazing how quickly app design can start to unravel. Typically the problems with the user experience (UX) result from the accumulation of seemingly minor issues -- compounding imperfections that ultimately cause users to quit the app and never come back.

Many of these small mistakes emerge early on in the process, long before the visual design is even considered. Early decisions, like the initial feature set and how your backend system will work, can have a dramatic impact on the UX of the entire project.

This eBook explores nine of the most common UX pitfalls in mobile app design. It highlights the traps so that app developers know how to avoid them. But if you’ve made any of these mistakes, no need to worry. The eBook also explains how to overcome the setback.

Mistake 1: Not Simplifying The Feature Set

If you want to build a product that is simple to use, then creating a simple product is a good place to start. We tend to think of all the wonderful things our app could do, but then things get messy when we try to implement the entire list of possible features. So the trick is to plan everything you might want in the application, then pare down the list to only the most important items. This is sometimes referred to as arriving at your MVP, or Minimum Viable Product, but I prefer the following characterization by Dan Cederholm of SimpleBits: “Dream big, implement small.”

Analog as it is, for me it works best if I write everything down on paper and then circle the absolutely critical features. I do this rather WKDQ�FURVVLQJ�RXW�WKH�RSWLRQDO�IHDWXUHV��ΖW�VHHPV�OLNH�D�PLQRU�GLHU-ence, but if you pick out the mandatory features you will end up with a much shorter list.

When working from the short list of mandatory features you can set the bar for user experience very high. Then later as you add more features you can work hard to maintain your high standards.

The designers at 37signals say, “It’s better to build half a product than a half-assed product.” Cutting features at the beginning is the best way to start building a great product.

Mistake 2: Forgetting State

A few weeks ago I was trying to get some work done on my iPhone. Hunting for a particular piece of data required me to drill a few layers deep into the app’s navigation. Then, realizing I needed something from the web as well, I quickly switched over to Safari.

When I returned to this app moments later, I was shown the top-level dashboard. Wait, what?

:KDW�KDSSHQHG�WR�WKH�SDJH�Ζ�KDG�ZRUNHG�VR�KDUG�WR�ȴQG"�$OWKRXJK�no data had been lost, because the app hadn’t remembered my navigation state, I felt as if the app had wasted my time. It created a frustrated user.

Your app should always try to act on behalf of the user. It should remember the last screen the user was visiting so they can immedi-DWHO\�SLFN�XS�ZKHUH�WKH\�OHIW�R�ZKHQ�WKH\�UHWXUQ�

Remembering state can also work across devices. Since a single person may use multiple devices in which the apps sync between them automatically, then the user will expect the data to sync as well.

For example, if an Angry Birds player clears multiple levels on his iPhone, then he shouldn’t be set to the beginning on his iPad.

State is a prime example of a UX issue being heavily impacted by backend functionality. If you (or a collaborator) don’t have backend development skills, you might want to try a back-end-as-a-service provider that has

pre-built this capability for you.

Mistake 3: Not Using Finger-Sized Tap Targets

Literally the biggest thing you can do to improve the usability of your app is to increase the tappable area for every button. You’re design-LQJ�IRU�ȴQJHUV�DQG�WKXPEV��QRW�PRXVH�FXUVRUV��ZKLFK�KDYH�D�KLJKHU�pointing accuracy).

Apple recommends a minimum of 44px by 44px for any element with which the user is expected to interact. The same recommendation applies to other smartphone platforms.

Of course, this guidance doesn’t mean that the button needs to appear that large. The tappable area can extend beyond the visible borders of the button. This will help users avoid the frustration of trying multiple times to tap an element. Just be careful if you position several buttons close to each other. Make sure that your extra tappable area doesn’t overlap with other buttons.

Mistake 4: Overcrowding Views

If you are used to designing for desktop computers, you’ll be VXUSULVHG�DW�MXVW�KRZ�OLWWOH�FRQWHQW�\RX�FDQ�ȴW�RQ�D�PRELOH�SKRQH��Because the screens are so much smaller, and tap targets need to be larger, views quickly become overcrowded. The solution is not to make elements smaller. That will just frustrate your users. Instead you need to add more views.

Whenever I start designing a new mobile app, I underestimate the number of required views. I start out thinking it will be a relatively VLPSOH�DSS�ZLWK�IHZHU�WKDQ�ȴYH�views, but then the views start DGGLQJ�XS��%HIRUH�ORQJ�Ζ�ȴQG�Ζ�QHHG�as many as 20 views to handle all the necessary tasks (registration, IRUJRW�SDVVZRUG��VHWWLQJ�QRWLȴFD-tion times, etc).

But that’s okay. It’s better to add more views than it is to overcrowd MXVW�D�IHZ�YLHZV��'HGLFDWLQJ�DQ�HQWLUH�YLHZ�WR�VHWWLQJ�D�QRWLȴFDWLRQ�WLPH�LV�MXVW�ȴQH��-XVW�PDNH�VXUH�WKDW�\RXU�WUDQVLWLRQV�DUH�TXLFN��buttons are clear, and that it’s easy to get back to the previous view.

Mistake 5: Keeping The User Waiting Without Feedback

Users have very little patience with mobile applications. As a mobile app developer, you might be frustrated with a user’s impatience because you understand that some tasks are always going to be slow, especially when the user has a weak network connection or an older device.

If your app is too slow or feels unre-sponsive, it only takes a single tap of the “home” button before your user is gone and never revisits your app. Luckily there is an easy way to help your users become more patient: Simply keep them informed.

Typically the problems with the user experience (UX) result from the accu-mulation of seemingly minor issues

/HWV�VD\�\RX�DUH�WU\LQJ�WR�SRSXODWH�WKH�GDWDEDVH�RQ�WKH�ȴUVW�UXQ�RI�D�newly installed app. By default, iOS shows a splash screen while the app is installing. Instead of the generic splash screen, you could display a simple message with a loading animation that reads, "Installing ..."

That step alone will grant you several seconds of patience. If it takes longer you can buy more time by changing the message. Next set it to "Loading database ..." If you need even more time wait several seconds and update the message again. "Loading interface ..." will give you still more time. Change the messages to what makes sense for your application, but keep the user informed.

You see, the user is just worried that your app has locked up. No one wants to keep staring at a screen that isn't going to do anything else. By changing the messages it shows that your application is still working on their behalf.

Mistake 6: Displaying The Wrong Keyboards

Have you ever typed in a URL and been happy to see a button on the keyboard that has “.com” on a single button? That single button saved you three additional keystrokes.

That little shortcut is possible because we know what type of data is H[SHFWHG�LQ�D�WH[W�ȴHOG��VR�ZH�FDQ�FKDQJH�WKH�NH\ERDUG�WR�PDNH�WKDW�easier. This means that you can add an “@” button on the main keyboard for entering emails or showing that “.com” button for URLs.

There are actually HLJKW�GLHUHQW�NH\ERDUG�YDULDWLRQV�available to you on L26��:KHQHYHU�\RX�SXW�LQ�D�WH[W�ȴHOG�\RX�FDQ�VHOHFW�ZKLFK�NH\ERDUG�should be used to input the content. These range from the default NH\ERDUG�WR�QXPEHU�NH\ERDUGV�WKDW�DUH�HQWLUHO\�GLHUHQW��ZLWK�ORWV�RI�subtle variations in between. Look through the options and choose the RQH�WKDW�PDNHV�WKH�PRVW�VHQVH�IRU�HDFK�ȴHOG�

You can also choose the keyboards on mobile web apps by changing the LQSXW�W\SH��1RUPDOO\�IRU�IRUP�ȴHOGV�we use <input type=”text” /> and <input type=”password” />, but in HTML5 even more options are avail-able. The one you should use most often is <input type=”email” />. 9LVXDOO\�LW�GRHVQȇW�ORRN�GLHUHQW�IURP�a standard text input, but iOS and Android will automatically display a

keyboard with a period and an @ symbol to make it quicker to enter email addresses.

Mistake 7: Failing To Do Usability Testing (Or Ignoring The Results)

Typically when you develop an app you know the product so well that you can’t accurately judge how easy it is to use for someone experi-HQFLQJ�LW�IRU�WKH�ȴUVW�WLPH��<RX�DUH�VLPSO\�WRR�FORVH�WR�LW��&RQFHSWV�WKDW�are intuitive to you, since you designed them, may need more expla-nation for a new user. The solution is to conduct usability testing.

That may sound like a fancy term, but it really can be quite simple. Find a friend or unsuspecting stranger who can give unbiased feed-back. Hand them a phone running your app and ask them to com-SOHWH�D�VSHFLȴF�WDVN��VXFK�DV�Ȋ&UHDWH�D�QHZ�WR�GR�LWHP�ȋ�Resist the urge to coach them. Just watch what they do, FDWDORJXH�ZKHUH�WKH\�JHW�FRQIXVHG��DQG�JDXJH�KRZ�TXLFNO\�WKH\�ȴQG�the necessary buttons.

It’s best if you can get them to verbalize their thoughts in this process.

Take notes as you watch them. Once they complete a task give them another one and keep watching. This process can be invaluable, provided the participant feels free to share his or her unvarnished opinion.

$IWHU�\RXȇYH�FDSWXUHG�IHHGEDFN�IURP�D�IHZ�SHRSOH��PDNH�WKH�ȴ[HV�before testing with others. Generally there’s little need to conduct user testing with lots of people. You’ll reach the point of diminishing returns quickly. I’ve consistently found that users encounter 90% of the same issues.

Using potential customers or at least people in your target market is best, but almost anyone will do. Just weigh the value of their feedback based on how close they are to your target customer.

Pitfall 8: Ignoring Speed & Caching

When implementing features and designing a great user experience, it can be easy to forget that VSHHG�LV�D�IHDWXUH. In fact, if your app is slow, your users may become frustrated and never even try the DSS�GLHUHQWLDWLQJ�IHDWXUHV�\RX�VSHQW�VR�PXFK�WLPH�EXLOGLQJ�

Facebook recently released an update to their iOS app. This update dramatically improved the user experience, but visually very little was GLHUHQW��6R�ZKDW�PDGH�WKH�GLHUHQFH"

Their entire update focused on making the app fast. Facebook, like many apps, needs to get almost all of their data from a server that

was slowing down the entire experi-ence. By decreasing requests and implementing caching, the speed of the app improved so much you could see user reviews on the App Store pointing it out. Caching your data to improve load speed is another area that a thoughtfully architected backend can provide -- and, in doing so, radically improve the user experi-

ence of your application.

3LWIDOO����2YHUXVLQJ�3XVK�1RWLȴFDWLRQV

Many apps need to be used actively in order for the developer to generate revenue (e.g., increasing views for advertisements or enticing users to make in-app purchases). So how do developers get users to come back?

3XVK�QRWLȴFDWLRQV�DUH�RQH�RSWLRQ��EXW�PDQ\�GHYHORSHUV�XVH�WKHP�poorly. Do you really want to be reminded to use that app you never FDUHG�DERXW�LQ�WKH�ȴUVW�SODFH"�ΖQ�WKDW�FDVH�D�SRRUO\�WDUJHWHG�SXVK�QRWLȴFDWLRQ�PD\�EH�WKH�ȴQDO�VWUDZ�QHHGHG�IRU�WKH�XVHU�WR�XQLQVWDOO�the app.

7KDWȇV�QRW�WR�VD\�\RX�VKRXOGQȇW�XVH�SXVK�QRWLȴFDWLRQV��EHFDXVH�\RX�should. Just be smart about it.

ΖI�\RX�VHQG�WDUJHWHG�QRWLȴFDWLRQV�EDVHG�RQ�D�XVHUȇV�SUHIHUHQFHV�RU�location it can help make your app more sticky and keep them coming back. This is just another reason to have a server-side com-ponent to your application. The better your information about your

customers, the more targeted you can be in your interactions with them.

$OO�WKLV�ZLOO�VDYH�\RX�IURP�VHQGLQJ�D�PDVV�SXVK�QRWLȴFDWLRQ�LQ�D�desperate attempt to get some of your users back.

Wrapping Up

Many of these mistakes are easy to make, but luckily most are easy to ȴ[�DV�ZHOO��ΖW�WDNHV�DQ�DWWHQWLRQ�WR�GHWDLO�WKURXJKRXW�HYHU\�VWHS�RI�WKH�DSS�FUHDWLRQ�SURFHVV�WR�ȴQLVK�ZLWK�D�JUHDW�XVHU�H[SHULHQFH�

1HDU�WKH�ODXQFK�RI�D�QHZ�DSS�Ζ�ȴQG�LW�KHOSIXO�WR�JHW�DZD\�IURP�P\�normal design process and try to see the application as a user. Start

at the beginning and go through the VHWXS�VWHSV�H[DFWO\�DV�\RXU�ȴUVW�users will. Take notes at every juncture, paying special attention to SODFHV�LQ�WKH�ȵRZ�WKDW�GRQȇW�PDNH�complete sense or could cause confusion.

Write down a to-do item for each spacing issue, every sentence of copy that isn’t clear, and each bug you encounter -- especially the

things you didn’t have time to deal with when you were building the feature.

<RX�GRQȇW�QHFHVVDULO\�KDYH�WR�ȴ[�HYHU\WKLQJ�RQ�WKDW�OLVW��EXW�LW�LV�important to be aware of everything your users may encounter. Then when you are back in your design or development mindset you can power through many of those tasks quite quickly.

Though if you take nothing else away from this, I want you to start doing usability testing. It really does not have to be complicated. Just watch your users as they use your product. You will learn so much in very little time.

HOW TO AVOID 9 COMMON MOBILE UX MISTAKES 9

No one sets out to create a poorly designed app. Every project begins with high hopes and great expectations, but it’s amazing how quickly app design can start to unravel. Typically the problems with the user experience (UX) result from the accumulation of seemingly minor issues -- compounding imperfections that ultimately cause users to quit the app and never come back.

Many of these small mistakes emerge early on in the process, long before the visual design is even considered. Early decisions, like the initial feature set and how your backend system will work, can have a dramatic impact on the UX of the entire project.

This eBook explores nine of the most common UX pitfalls in mobile app design. It highlights the traps so that app developers know how to avoid them. But if you’ve made any of these mistakes, no need to worry. The eBook also explains how to overcome the setback.

Mistake 1: Not Simplifying The Feature Set

If you want to build a product that is simple to use, then creating a simple product is a good place to start. We tend to think of all the wonderful things our app could do, but then things get messy when we try to implement the entire list of possible features. So the trick is to plan everything you might want in the application, then pare down the list to only the most important items. This is sometimes referred to as arriving at your MVP, or Minimum Viable Product, but I prefer the following characterization by Dan Cederholm of SimpleBits: “Dream big, implement small.”

Analog as it is, for me it works best if I write everything down on paper and then circle the absolutely critical features. I do this rather WKDQ�FURVVLQJ�RXW�WKH�RSWLRQDO�IHDWXUHV��ΖW�VHHPV�OLNH�D�PLQRU�GLHU-ence, but if you pick out the mandatory features you will end up with a much shorter list.

When working from the short list of mandatory features you can set the bar for user experience very high. Then later as you add more features you can work hard to maintain your high standards.

The designers at 37signals say, “It’s better to build half a product than a half-assed product.” Cutting features at the beginning is the best way to start building a great product.

Mistake 2: Forgetting State

A few weeks ago I was trying to get some work done on my iPhone. Hunting for a particular piece of data required me to drill a few layers deep into the app’s navigation. Then, realizing I needed something from the web as well, I quickly switched over to Safari.

When I returned to this app moments later, I was shown the top-level dashboard. Wait, what?

:KDW�KDSSHQHG�WR�WKH�SDJH�Ζ�KDG�ZRUNHG�VR�KDUG�WR�ȴQG"�$OWKRXJK�no data had been lost, because the app hadn’t remembered my navigation state, I felt as if the app had wasted my time. It created a frustrated user.

Your app should always try to act on behalf of the user. It should remember the last screen the user was visiting so they can immedi-DWHO\�SLFN�XS�ZKHUH�WKH\�OHIW�R�ZKHQ�WKH\�UHWXUQ�

Remembering state can also work across devices. Since a single person may use multiple devices in which the apps sync between them automatically, then the user will expect the data to sync as well.

For example, if an Angry Birds player clears multiple levels on his iPhone, then he shouldn’t be set to the beginning on his iPad.

State is a prime example of a UX issue being heavily impacted by backend functionality. If you (or a collaborator) don’t have backend development skills, you might want to try a back-end-as-a-service provider that has

pre-built this capability for you.

Mistake 3: Not Using Finger-Sized Tap Targets

Literally the biggest thing you can do to improve the usability of your app is to increase the tappable area for every button. You’re design-LQJ�IRU�ȴQJHUV�DQG�WKXPEV��QRW�PRXVH�FXUVRUV��ZKLFK�KDYH�D�KLJKHU�pointing accuracy).

Apple recommends a minimum of 44px by 44px for any element with which the user is expected to interact. The same recommendation applies to other smartphone platforms.

Of course, this guidance doesn’t mean that the button needs to appear that large. The tappable area can extend beyond the visible borders of the button. This will help users avoid the frustration of trying multiple times to tap an element. Just be careful if you position several buttons close to each other. Make sure that your extra tappable area doesn’t overlap with other buttons.

Mistake 4: Overcrowding Views

If you are used to designing for desktop computers, you’ll be VXUSULVHG�DW�MXVW�KRZ�OLWWOH�FRQWHQW�\RX�FDQ�ȴW�RQ�D�PRELOH�SKRQH��Because the screens are so much smaller, and tap targets need to be larger, views quickly become overcrowded. The solution is not to make elements smaller. That will just frustrate your users. Instead you need to add more views.

Whenever I start designing a new mobile app, I underestimate the number of required views. I start out thinking it will be a relatively VLPSOH�DSS�ZLWK�IHZHU�WKDQ�ȴYH�views, but then the views start DGGLQJ�XS��%HIRUH�ORQJ�Ζ�ȴQG�Ζ�QHHG�as many as 20 views to handle all the necessary tasks (registration, IRUJRW�SDVVZRUG��VHWWLQJ�QRWLȴFD-tion times, etc).

But that’s okay. It’s better to add more views than it is to overcrowd MXVW�D�IHZ�YLHZV��'HGLFDWLQJ�DQ�HQWLUH�YLHZ�WR�VHWWLQJ�D�QRWLȴFDWLRQ�WLPH�LV�MXVW�ȴQH��-XVW�PDNH�VXUH�WKDW�\RXU�WUDQVLWLRQV�DUH�TXLFN��buttons are clear, and that it’s easy to get back to the previous view.

Mistake 5: Keeping The User Waiting Without Feedback

Users have very little patience with mobile applications. As a mobile app developer, you might be frustrated with a user’s impatience because you understand that some tasks are always going to be slow, especially when the user has a weak network connection or an older device.

If your app is too slow or feels unre-sponsive, it only takes a single tap of the “home” button before your user is gone and never revisits your app. Luckily there is an easy way to help your users become more patient: Simply keep them informed.

Typically the problems with the user experience (UX) result from the accu-mulation of seemingly minor issues

/HWV�VD\�\RX�DUH�WU\LQJ�WR�SRSXODWH�WKH�GDWDEDVH�RQ�WKH�ȴUVW�UXQ�RI�D�newly installed app. By default, iOS shows a splash screen while the app is installing. Instead of the generic splash screen, you could display a simple message with a loading animation that reads, "Installing ..."

That step alone will grant you several seconds of patience. If it takes longer you can buy more time by changing the message. Next set it to "Loading database ..." If you need even more time wait several seconds and update the message again. "Loading interface ..." will give you still more time. Change the messages to what makes sense for your application, but keep the user informed.

You see, the user is just worried that your app has locked up. No one wants to keep staring at a screen that isn't going to do anything else. By changing the messages it shows that your application is still working on their behalf.

Mistake 6: Displaying The Wrong Keyboards

Have you ever typed in a URL and been happy to see a button on the keyboard that has “.com” on a single button? That single button saved you three additional keystrokes.

That little shortcut is possible because we know what type of data is H[SHFWHG�LQ�D�WH[W�ȴHOG��VR�ZH�FDQ�FKDQJH�WKH�NH\ERDUG�WR�PDNH�WKDW�easier. This means that you can add an “@” button on the main keyboard for entering emails or showing that “.com” button for URLs.

There are actually HLJKW�GLHUHQW�NH\ERDUG�YDULDWLRQV�available to you on L26��:KHQHYHU�\RX�SXW�LQ�D�WH[W�ȴHOG�\RX�FDQ�VHOHFW�ZKLFK�NH\ERDUG�should be used to input the content. These range from the default NH\ERDUG�WR�QXPEHU�NH\ERDUGV�WKDW�DUH�HQWLUHO\�GLHUHQW��ZLWK�ORWV�RI�subtle variations in between. Look through the options and choose the RQH�WKDW�PDNHV�WKH�PRVW�VHQVH�IRU�HDFK�ȴHOG�

You can also choose the keyboards on mobile web apps by changing the LQSXW�W\SH��1RUPDOO\�IRU�IRUP�ȴHOGV�we use <input type=”text” /> and <input type=”password” />, but in HTML5 even more options are avail-able. The one you should use most often is <input type=”email” />. 9LVXDOO\�LW�GRHVQȇW�ORRN�GLHUHQW�IURP�a standard text input, but iOS and Android will automatically display a

keyboard with a period and an @ symbol to make it quicker to enter email addresses.

Mistake 7: Failing To Do Usability Testing (Or Ignoring The Results)

Typically when you develop an app you know the product so well that you can’t accurately judge how easy it is to use for someone experi-HQFLQJ�LW�IRU�WKH�ȴUVW�WLPH��<RX�DUH�VLPSO\�WRR�FORVH�WR�LW��&RQFHSWV�WKDW�are intuitive to you, since you designed them, may need more expla-nation for a new user. The solution is to conduct usability testing.

That may sound like a fancy term, but it really can be quite simple. Find a friend or unsuspecting stranger who can give unbiased feed-back. Hand them a phone running your app and ask them to com-SOHWH�D�VSHFLȴF�WDVN��VXFK�DV�Ȋ&UHDWH�D�QHZ�WR�GR�LWHP�ȋ�Resist the urge to coach them. Just watch what they do, FDWDORJXH�ZKHUH�WKH\�JHW�FRQIXVHG��DQG�JDXJH�KRZ�TXLFNO\�WKH\�ȴQG�the necessary buttons.

It’s best if you can get them to verbalize their thoughts in this process.

Take notes as you watch them. Once they complete a task give them another one and keep watching. This process can be invaluable, provided the participant feels free to share his or her unvarnished opinion.

$IWHU�\RXȇYH�FDSWXUHG�IHHGEDFN�IURP�D�IHZ�SHRSOH��PDNH�WKH�ȴ[HV�before testing with others. Generally there’s little need to conduct user testing with lots of people. You’ll reach the point of diminishing returns quickly. I’ve consistently found that users encounter 90% of the same issues.

Using potential customers or at least people in your target market is best, but almost anyone will do. Just weigh the value of their feedback based on how close they are to your target customer.

Pitfall 8: Ignoring Speed & Caching

When implementing features and designing a great user experience, it can be easy to forget that VSHHG�LV�D�IHDWXUH. In fact, if your app is slow, your users may become frustrated and never even try the DSS�GLHUHQWLDWLQJ�IHDWXUHV�\RX�VSHQW�VR�PXFK�WLPH�EXLOGLQJ�

Facebook recently released an update to their iOS app. This update dramatically improved the user experience, but visually very little was GLHUHQW��6R�ZKDW�PDGH�WKH�GLHUHQFH"

Their entire update focused on making the app fast. Facebook, like many apps, needs to get almost all of their data from a server that

was slowing down the entire experi-ence. By decreasing requests and implementing caching, the speed of the app improved so much you could see user reviews on the App Store pointing it out. Caching your data to improve load speed is another area that a thoughtfully architected backend can provide -- and, in doing so, radically improve the user experi-

ence of your application.

3LWIDOO����2YHUXVLQJ�3XVK�1RWLȴFDWLRQV

Many apps need to be used actively in order for the developer to generate revenue (e.g., increasing views for advertisements or enticing users to make in-app purchases). So how do developers get users to come back?

3XVK�QRWLȴFDWLRQV�DUH�RQH�RSWLRQ��EXW�PDQ\�GHYHORSHUV�XVH�WKHP�poorly. Do you really want to be reminded to use that app you never FDUHG�DERXW�LQ�WKH�ȴUVW�SODFH"�ΖQ�WKDW�FDVH�D�SRRUO\�WDUJHWHG�SXVK�QRWLȴFDWLRQ�PD\�EH�WKH�ȴQDO�VWUDZ�QHHGHG�IRU�WKH�XVHU�WR�XQLQVWDOO�the app.

7KDWȇV�QRW�WR�VD\�\RX�VKRXOGQȇW�XVH�SXVK�QRWLȴFDWLRQV��EHFDXVH�\RX�should. Just be smart about it.

ΖI�\RX�VHQG�WDUJHWHG�QRWLȴFDWLRQV�EDVHG�RQ�D�XVHUȇV�SUHIHUHQFHV�RU�location it can help make your app more sticky and keep them coming back. This is just another reason to have a server-side com-ponent to your application. The better your information about your

customers, the more targeted you can be in your interactions with them.

$OO�WKLV�ZLOO�VDYH�\RX�IURP�VHQGLQJ�D�PDVV�SXVK�QRWLȴFDWLRQ�LQ�D�desperate attempt to get some of your users back.

Wrapping Up

Many of these mistakes are easy to make, but luckily most are easy to ȴ[�DV�ZHOO��ΖW�WDNHV�DQ�DWWHQWLRQ�WR�GHWDLO�WKURXJKRXW�HYHU\�VWHS�RI�WKH�DSS�FUHDWLRQ�SURFHVV�WR�ȴQLVK�ZLWK�D�JUHDW�XVHU�H[SHULHQFH�

1HDU�WKH�ODXQFK�RI�D�QHZ�DSS�Ζ�ȴQG�LW�KHOSIXO�WR�JHW�DZD\�IURP�P\�normal design process and try to see the application as a user. Start

at the beginning and go through the VHWXS�VWHSV�H[DFWO\�DV�\RXU�ȴUVW�users will. Take notes at every juncture, paying special attention to SODFHV�LQ�WKH�ȵRZ�WKDW�GRQȇW�PDNH�complete sense or could cause confusion.

Write down a to-do item for each spacing issue, every sentence of copy that isn’t clear, and each bug you encounter -- especially the

things you didn’t have time to deal with when you were building the feature.

<RX�GRQȇW�QHFHVVDULO\�KDYH�WR�ȴ[�HYHU\WKLQJ�RQ�WKDW�OLVW��EXW�LW�LV�important to be aware of everything your users may encounter. Then when you are back in your design or development mindset you can power through many of those tasks quite quickly.

Though if you take nothing else away from this, I want you to start doing usability testing. It really does not have to be complicated. Just watch your users as they use your product. You will learn so much in very little time.

Written by

Nathan Barry

Barry is a software designer and author of two books: The App Design Hand-book and Designing Web Applications. He enjoys teaching design, creating new products, and writing about the entire process on his blog, NathanBarry.com.

Nathan lives in Boise, Idaho with his wife and one year old son. A favorite pastime is traveling and showing the world to little Oliver, though he won't remember any of it.

What is Kinvey? Kinvey makes a fully-featured Backend as a 6HUYLFH�VROXWLRQ��RHULQJ��UG�SDUW\�GDWD�LQWHJUDWLRQV��PXOWL�SODW-IRUP�VXSSRUW��SXVK�QRWLȴFDWLRQV��DQG�FXVWRP�EXVLQHVV�ORJLF�RQ�D�

platform where it's free to get started and you only pay when your app is successful.

Build your backend todayBuild your backend today

Project Manager

Joe Chernov

Designed by

Jake McKibben and Lauren Pedigo

HOW TO MAKE AN APP: iOS EDITION