All posts tagged as "Design Tips"

We had indicated on the mobile design resources page that we would be adding design recommendations and style guide information. This information would be recommendations that don’t constitute a design pattern, but nevertheless are good or best practices. And of course, the information is free and you are encouraged to add or edit content.

We just loaded a long page on mobile game design. It’s the chapter on game design from my 2003 User Interface Guidelines for J2ME MIDP 2.

We’re still working on getting other major information providers (a quick call-out to dotMobi, W3C, Nokia, SonyEricsson, Sprint, Vodafone, and others) to provide support and/or information. If you provide support in the form of a lot of content and/or money to defray our expenses, you’ll get your logo built into the templates.

Over on the mobile design resources wiki, we’re adding some new content, as well as moving some of our older essays into the public space. Specifically, check out Design Tools. Right now there is only a list of web emulators & simulators and a full design suite; please add your favorite tools.

And since I haven’t ranted about this recently …

Simulators (which attempt to duplicate the experience of the device on the desktop) and emulators (which use the same code as what runs on the device recompiled for the desktop) are crucial tools in application development. They do a very good job of giving the developer an idea of how the application will feel to the user, and allow the developer to do unit testing. They’re also handy for demos.

Unfortunately, these tools must not be used as the exclusive means for testing the application for either functionality or usability. Do your unit testing, but then test on actual devices either in hand or via services such as DeviceAnywhere.

There are a variety of known differences between most simulators and the devices that they simulate. Usability testing using emulators, while less expensive than testing using real devices, is also fraught with problems:

• Normal device usage involves holding the device at a comfortable angle, and even gesturing with it. The unnatural use of a computer will cause your test to miss nuances in user interaction.


• The speed of transmission and rendering on the computer is faster than on the mobile device.


• Dropped calls and dropped packets do not happen as frequently on the computer.


• User input is different on the computer. Typing will be easier, unless you restrict the user to using the mouse (in which case it will be harder).


• User context is different. Sitting at a desktop computer is a fairly formal experience. Sitting on a sofa using a device is an informal experience. Users will behave differently.

This is a statement I see all the time; it's explicitly stated in documentation for software, but is increasingly implied for all sorts of consumer products.

Instead, I think complicated things are just complicated.

It used to be that it was okay to let the machine do the work, just push a button and behind the scenes the right thing happens. But at some point it seems the problem of feature creep has made its way out into the wild, such that a product without a long list of features is not worth as much as a product that does a few things really well.

And complex interfaces are not just going to reduce usability and usefulness for your consumer product. Lots of aircraft- and industrial accidents have poor interface design as at least a contributing factor. Even well-trained, experienced operators can get confused or miss the key component when confronted with too many conflicting or unclear signals.

So, how do you solve this? The pat answer is "hire designers." Engineers (and developers) do a fine job engineering and developing, but tend to want to throw every feature right up top.

But specifically, there are processes anyone can follow. When I am designing very strictly, I make sure to explicitly:

• Gather the features (from marketing and technical requirements, user research or competitor product evaluations) and turn them into functions or information to be presented
• Filter out all the functions that are easier to just let the system deal with, or don't need to be done
• Group all the remaining functions and information logically
• Prioritize so that the most key functions and info are the most visible and easily accessed

As you might expect "filter" is the hardest step, entirely because you have to justify everything to every stakeholder.

But you can apply the rest of the process anyway. A few years ago I had to redesign the desktop web interface for a 2-way SMS system. It ended up being fearsomely simple; there's no longer a help system and the only error messages are for system outages. But aside from the basic sending and receiving components, there were another fifty requirements that just "had" to be included — difficult things like blocking, international sending and network-type selection. So a few went into a contact management system, and the rest into settings. Once the user gets into these sections, large hierarchically-organized groups of information and selectors are presented. The vast bulk of the users (way over 99%) are not burdened with it at all.

And this is successful. Hundreds of thousands of messages a day, practically no abandoned sessions, and certainly no complaints for either simplicity or complexity from anyone.

You never have a second chance to make a first impression.

Now that we’ve disposed of the homily, we should note that it is true. For many web sites and most mobile web sites and applications, complexity in setup process should be avoided. Get your customers to the content as quickly as possible. Get your example from lots of “Web 2.0” sites which let you get started just by signing up. Profiles come later.

Perhaps the most striking method of doing this was done by a client whose third-party application was pre-loaded onto devices by the operators. Unfortunately, the application required around 3 minutes of setup. They recognized that the purchase and setup of a mobile phone is a complex and frequently confusing process, and was focused on voice, SMS, and perhaps web. Certainly not their little application.

So they set the application to wake up around 10 days after the phone was activated, and provide the user the value of setting up the application. This delayed setup of a minor application ended up providing the user greater perceived value of the phone service. Had it been buried along with all the other setup processes, confusion, dismissal, or even anger may have occurred.

A common pattern in any type of social networking, including mobile social networking, is to rate content or comments. Too bad it is frequently done poorly.

A star rating system must have the following components:

Other features are optional. #1 is usually done okay; #2 sometimes hides #1, even though its still valid data. #3 is frequently broken or hidden. #4 should be the simplest of all, but many of the biggest sites still break it, one way or the other.

I am thrilled to announce that we have announced the first of the speakers, more details, and the registration page for the first North American conference focused on mobile design, Design for Mobile.

Speakers include researchers, visual designers, interaction designers, UI developers, and design strategists. They work in operators, device manufacturers, open source, academia, content companies, technology companies. They work on web, applications, services, devices, and best practices.

We've more in the works, so stay tuned.

Register now!