Blog by Paul Golding

This seems obvious, yet it's a hugely common oversight. What this usually boils down to is design and remembering to design-for-mobile. Think about task-centric design that enables the user to get results fast. Minimize the number of options and the amount of information to the bare minimum. Minimize the number of clicks required to complete tasks. Minimize the amount of inputs on a form. Minimize the complexity of information that you require a user to enter (or keep in their heads). Let the user drill down for more information, if they need it, recognizing that every visit to the server is going to incur a delay, so mimimize trips to the server too. 

Are you getting the hint here? Minimization (or optimization) is the name of the game, which is really about economy of effort across the entire mobile experience. Think of the archetypal mobile user as being insanely impatient. Of course, minimization will naturally lead to coding and design styles that enable a sleek experience, such as heavy use of CSS for styling web apps, not graphics, and so on. The methods for optimal design and coding and too many to mention. Again, consult the references above.

In many mobile applications, function has proven to be far more important to the user than the visual appeal, especially superfluous eye-candy and esoteric user interfaces. You might be surprised by the aesthetic crudeness of the UI in some very popular mobile apps, but where the user is still able to get the results they want. Many mobile dating applications are like this. In fact, in many such cases, the app providers have found that the path to monetization was to simplify the experience considerably and widen device compatibility.

Don't be fooled into thinking that things have moved on so far in mobile, thanks to 3G and faster mobile processors, that we can now dispense with design optimization of the sort that characterized early web design strategies. This isn't true. There's a difference between some of those glitzy playful apps in the iPhone app store and the apps that are out there today serving large numbers of users and making some money. Most money-making mobile apps are very crude in design, yet do the job well.

By the way, 3G does not speed up most web transactions! As users of the 3G iPhone have no doubt already discovered, accessing a 'typical' web page over 3G often incurs similar delays to 2.5G. That's because for small chunks of information, the actual transport delay only accounts for a small percentage of the overall transaction. Processing, buffering, parsing, context-switching, network access and a raft of other delay steps dominate the delay budget. Also, a 3G pipe can often be as skinny as a 2.5G pipe, if the cell is loaded.

3G comes into its own for moving large amounts of data. So, on the flip side, don't attempt multimedia apps without it!

Oh yes. Don't forget the cost of data. Despite the availability of various flat-rate tariffs, most mobile subscribers have to pay for their data by the Megabyte. It's your job to minimise the data sent back and forth, not only as a courtesy to the user (and the success of your service) but as part of good design for mobile.

Consult Barbara Ballard's excellent list of Mobile Design resources, including design patterns for once you're ready to design.

Exploit the multi-modal capabilities of the mobile device. It's a phone, a PIM, a camera, a video recorder, a games machine, a messaging device, an email device (perhaps), a payment device, a browser, a music player, a GPS device. There's so many ways of engaging the user in the mobile context. For just a sample of the common touch-points for mobile, see my list of mobile touch-points.

Given the need to be pithy with the user experience, it often pays to recognise that there are probably more than one type of user archetype, often called personas (in several theories of UI design). Therefore, you might want to consider variants of the user experience to target each persona separately.

If you're trying to reach a multi-national or regional market, be aware that these personas can vary dramatically from one region to another.

For all kinds of reasons that we won't go into, you simply can't design a mobile app to work well on all devices. Depending on the complexity of the application, it's difficult to get a mobile app to work well on even a small subset of devices. One approach, often a useful one, is to target the top 10, say, devices for your target audience in your target geography. Recognize that once you cross from onecountry to another, the device preferences in that market can change considerably.

One source of device type penetration is your operator, assuming that they want to share such information. Historically they didn't, but this is changing with the new thirst for applications. Operators are learning to be a lot more developer friendly.

Too many mobile apps fail in unintended ways on devices that don't quite fit the vanilla mould for that device. A firmware tweek here, a slight model change there, and an app that works well on the device in your hands doesn't work on the 'same' device in the hands of the users. Poor device targeting can lose you a lot of users from the outset. Don't forget, mobile users are impatient. They won't comeback, they won't try again, they won't seek out help. They will delete the app and leave.

Don't fall into the trap of assuming that certain devices are the same because they have the same basic appearance or belong to the same family. In my experience, it is safer to assume that apparently 'similar' devices are not the same. This is often the case.

Moreover, if you assume some kind of variation in device performance, then you need to think carefully about graceful degradation of function where device performance is lacking or unexpected. Don't forget that graceful degradation also applies to the never-to-be-overlooked problem of losing a connection.

Ultimately, the best way to deliver a high quality experience is to test rigorously on the intended target devices. This is not easy, especially for resource-strapped Micro-ISVs. Consult your operator to see what testing services they offer and if they can recommend any testing houses. There is a recent emergence of community-based device testing, which seems like a useful direction for Micro-ISVs to support.

Just as with good Javascript coding, if your application needs a certain API for it to work, then you should ideally implement code to test for the existence of that capability on the run-time device. Don't rely on device-type checking and then assuming that APIs exist just by looking them up in a device capabilities database.

That said, it is not easy on many mobiles to test for capability. A good resource is the WURFL project from my good friend Luca Passani, or its more commercialized cousin, Device Atlas (which is really a WURFL that you pay for).

This has two dimensions. It is a major issue if you intend to sell your mobile application to an operator. It comes as a rude awakening to many application designers that operators expect all kinds of other nuts and bolts when they license an application, such as alarm generation, billing hooks, provisioning hooks and so on. These requirements take many inexperienced ISVs by surprise. See Chapter 3 in Next Generation Wireless Applications for tips on selling/presenting apps to operators.

It is also important generally to think of a solution, which goes hand in hand with tip 1 about being kind to your user. For example, as I have been pointing out since the early days of mobile apps, a POP3 email client is not a complete solution for the 'mobile email problem.' A mobile email user needs easy data entry, easy access to the address book, effective filtering or searching, and so on. Hence, a complete mobile email solution, for example, would include a number of other support functions besides composing and reading messages in a POP3 mailbox. RIM understood this from the outset with their elegant and successful Blackberry email solution.

This is so important, especially for mobile, given the mobile user's relative intolerance of any shortcomings in the experience. Don't forget that any awkwardness in the UI will lose you customers very quickly. 

It is incredibly easy to conduct some basic usability testing of the design. Simply put it in the hands of some users and watch them use it. In the first instance, it really is that easy.

I am a relative expert in mobile technology, yet I am repeatedly defeated by various mobile applications because I can't figure out how to get to the next step. If I can't figure out, then think about those poor souls who don't know a bit from a byte.

What you will find very quickly - I almost guarantee it - is a disconnect between what you think is obvious in your UI and what the uninitiated users think is obvious. They will, for sure, hit the wrong button, make the wrong assumptions and so on. These disconnects can be very frustrating to developers because their design just seems so 'obvious' to them. The reason for that is that the developer is the one who has used it several hundred times during development and testing. There is a difference between obvious and intuitive.

If the mobile application is critical to your business plan, then consider hiring someone else to do the design, or at least to write the copy for you (i.e. the wording). So many coders end up doing the design and insisting on their own quirky view of the task in hand. I find this to be a frequent issue with many mobile apps. Don't forget that on a very small screen, there is often very little context to provide additional visual cues to usage, so the user can get lost very easily indeed.

There are all kinds of design considerations, but consistency is important. This has a number of dimensions. Self-consistency within the application, which usually means that the navigation and persistent visual widgets (i.e. menus, breadcrumbs) are in the same place and act in the same way across all screens.

There is consistency with the conventions of a theme or worldview. So, if your application is mobile note-taking, then don't start calling notes 'Memes' or something unusual. Stick to fairly conventional names for things like address books, contacts, and for actions, like uploads, downloads, etc. However, avoid generic terms ('Submit message') where a specific one is more meaningful ("Send text message") and lets the user know more about what is going on.

Be consistent with your own conventions and desktop worldviews. If your mobile application works alongside a desktop application (installed or online), make sure that the mobile version is consistent in naming and operational conventions used on the desktop. That does not mean that you copy the desktop app and try to squeeze it into the mobile. Don't forget, you need an economical mobile solution that is kind to the mobile user.

By the way, be careful about assuming that your user will know how to use the mobile version of a desktop app because they are familiar with the desktop app. If it is possible to sign up to your service via mobile, then it has to work 'out of the box' from the mobile. Increasingly, many users might find your mobile app first, so be prepared for this.

Although users are becoming more familiar with using mobile applications, there is still resistance due to costs and various perceived 'risks' of using mobile apps. Users want to know how much they expect to pay for using an application. If you're charging the user, such as through the use of a charging gateway or premium text message, then make sure that the user knows how much, how often and how to opt out.

If you're accessing data local to the device, make sure that the user knows what's going on. This is inevitable on many devices because of permission-locks on sensitive APIs, requiring the user to grant permission (such as to the PIM or to location information). You should honor such conventions where possible. Don't try to work around them. Give the user the choice. 

Finally, be aware of any local codes of conduct or laws applicable to mobile applications in your region, such as anti-spamming conventions, age-checking, opt-in clauses and so on.

Best of luck with your mobile application.