AreYouKiddingMeOk, I admit it.  The headline was a bit of link bait given how obvious it is.  That being said, it’s surprising how often the mistake is made by app developers to add more features and screen activity than is necessary.  This is especially true of developers porting a PC app to the mobile form factor.  It’s actually really easy to fall into the trap of making an app busier than it needs to be.  Good mobile app design is more than an appealing UI.  It’s even more important to understand the purpose of the app and how it will be used.  Take your cues from that and your app will be more usable to the masses.  This post is the first in a five-part series on creating awesome mobile UIs and creating your app with mobility-first in mind.  The second post is on placement of controls in your UI to be most effective for frequent use.  The third post will be on the size of UI assets on the screen and why it is important.  The fourth post will be on when to use an app bar vs. populating controls on your app’s screens.  The fifth and final post will be on implementing gestures and animations to make them useful to the app.

A little while back, I wrote a 5-part Metro Primer blog post series that has received some pretty great reviews (thanks to those who shared your feedback on this series!).  The intent of this series was to introduce you to Microsoft’s Metro Design Language if you hadn’t yet seen it as an app developer and if you had seen Metro before, to help you craft great Metro experiences.  Metro is powerful and expressive and you can really create amazing and artful experiences for your apps with it.  Like any other user interface paradigm, however, it’s just as easy (actually, maybe even easier) to create truly horrible experiences that ultimately hurt your app’s chances of being adopted.

This series of 5 blog posts (the others will be posted throughout the next few days on the Canadian Mobile Developers blog) is meant to be a companion to the Metro primer in that its purpose it to provide some good practices to use for your apps’ screens so that they are effective, intuitive and make your users come back to the app.  Even if you never read the Metro Primer series, you might want to read this series as I will dive into tips that will make you think critically about how to build the UI for your app.  And a little hint here – a lot of what I’ll talk about is actually platform agnostic.  So if you are an Android developer, iOS developer or any other mobile platform developer, this content could be very useful to you.

The Smartphone is not a PC

Again, duh.  Clearly they are not the same.  Even the smallest of laptops are distinctly different from mobile devices.  Yet many app developers make the fatal mistake of assuming a mobile app is just:

  • A scaled-down desktop
  • A smaller screen
  • A PC with less computing power.

In the back of our heads, we all innately understand the concept that mobile devices and PCs are fundamentally different.  But when we make the mistakes like the ones listed above (and trust me, app marketplaces across all platforms are littered with examples), it becomes clearer that the issue is not as cut and dry as it first seems. 

Let’s face it.  Even app developers that are currently in high school have earned a pedigree in understanding their way around a computer.  In many cases, that history with PCs is long and full of experience building technology solutions that target PCs.  When we make the change to becoming mobile app developers, we have a bias (whether or not we are aware of it) towards building apps that adhere to traditional PC software design principles, at least in part.  Children in grade school are seeing a very different technological reality.  Their first experiences in technology are just as likely to be on a mobile device (phone or tablet) than on a PC-form factored device.

If you take a look at the PC, it is a true workhorse tool capable of doing almost infinite things.  It also has a lot of power behind it.  It also has the ability to provide a huge amount of screen real estate.  Mobile devices are by nature almost the opposite.  They are capable of doing amazing things, but the use case is generally much more limited than that of a PC.  Likewise, the power of the device, while equivalent in modern smartphones to PCs even just 5 years ago, is limited and the intent is to have it untethered from power sources for much larger amounts of time.  Finally, screen real estate is generally fixed and often small. 

As developers of traditional PC or web solutions, our mindset must change from creating apps that are scaled down versions of PC apps.  That just doesn’t work.  And believe me, it’s tough to remove yourself from a PC mindset when designing a mobile app.  Instead, try to watch grade school children use mobile technology and try to understand the patterns they employ to get tasks done on those devices.  The activities that grade school children do on mobile devices are much more pure to the spirit of the mobile form factor as they have no real past history on the PC form factor and provide hints as to how to best implement functionality in your mobile app.

Designing for motion

The last point I will bring up in this post is to always keep in mind that we need to design for motion.  By motion, I don’t mean crazy animation on the screen (that’s a topic for the fifth post in this series).  I mean we have to design our app with the understanding that our users are always in motion.  Your app will be used by someone that is just as likely to be walking to an elevator or shifting in the cold waiting for a bus as someone who is sitting at his/her desk.

In other words, this is what we think mobile experiences are like:

MobileExperiences1

When, in fact, mobile experiences are more like this:

MobileExperiences2

Busy user interfaces on mobile apps simply don’t work in truly mobile conditions.  Users are not going to pay 100% attention to your app if they are on the move, so designing the user interface to take this in mind will make your app exponentially better to your users.