Recent Blog Posts

I talk to many types of people who are considering working with us. All want a better design for their mobile products. I’ve been noticing trends.

Social networking site success does not seem connected to quality of design. If it is sufficiently “hackable” (can be made to reflect participants’ personality) and gets the right balance of privacy and connection, it can succeed. Well, it can if it has the right business model, the right timing, the right viral components, the right targeting; it’s more about those classic marketing factors than the product itself. My inability to figure out Facebook’s navigation paradigm has clearly not affected their success; or at least their popularity.

When a CEO contacts us, he (it’s always been a he) pretty much doesn’t have the money to invest in a full design process. At best we can review their application and make suggestions. But this type of CEO wants not only design on the cheap, but development as well. So far, the CEO has never invested in a solid design process, with us or anybody else. And of those, only the social networking companies have done well.

Project managers are another group of people who sometimes contact us for help. Unfortunately, this has been because their boss told them to — they weren’t feeling the pain of poor design. In these cases, the company doesn’t invest in design and continues stumbling along with the same problems they did before. This is a case of insufficient leadership: the boss, usually the head of product or marketing, needs to invest her time in improving design.

When CTOs contact us, usually the company doesn’t have a person focused on product, and marketing is focused on sales. These companies frequently run into the same problem as above.

If you want to improve design process by focusing on design and user research, you’ll need to measure your team. Whether doing it yourself or working with an outside resource, your team needs to be measured on the results, the return on investment (ROI): decreased churn, decreased calls to customer support, increase uptake rate, increased purchases, increased page views, increased time on site, decreased bounce rate. Whatever it is, measure it (in a standard manner, and without changing the measurement method halfway through just to meet goals).

Be clear to your team about what you are expecting. Don’t tell your product manager, “go improve the design.” He’ll make it prettier, or more AJAX, or something that doesn’t do much to improve the user experience, or actually hurts it. Then you’ll both go around talking about how easy to use your service is. Measure results with a relevant measure from above.

I use a service that proclaims ease of use. They have nice clean pages, and good features. That’s why I’m using the service. But there are problems. It mostly works in Safari, but breaks (invisibly) deep in the site when you try to save your change. On one page, clicking a cute icon opens an otherwise invisible set of critically important pages. On another page, that same icon in the same place generates a new instance of what is on the page. The “friendly,” “designed” site is breaking down, causing user frustration. And making the user feel stupid, the more so due to frequent proclamations of being friendly and easy. And when your service that looks super-friendly makes users feel stupid, it’s breaking a promise.

Design doesn’t have to be expensive, but it does take investment in a new process. You want a balancing between what is and what could be, between customer stated desires and unmet needs, between user needs and business needs, all in a group of people who can create concepts from existing needs. This a different set of expertise than software development or marketing or graphic design, though not impossible to learn. It’s design.

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 week’s Carnival of the Mobilists is pretty good. Be sure you are up to speed on Adobe freeing Flash Lite and Tomi’s talk on mobiles as the 7th mass media. As always, Tomi is bullish on SMS and I only somewhat agree.

The dotMobi Advisory Group is presenting what looks like a really useful free webinar for mobile designers and programmers. Check it out; I hope they capture the video file for later download.

Left to Your Own Devices
Building Device Aware Content – new tools to simplify the process and increase your business

In case you haven’t noticed, Nuance is now a major player in the mobile space.

• Voice control for smart devices and Embedded Voice engines for some devices


• Interactive Voice Response (IVR) and Call Steering software – it doesn’t have to be as badly designed as it is


• They now own T9 though its not on their front page


• A whole bunch of mobile messaging solutions


• Voice-driven mobile search


• Voice-based navigation services, based on search

In short, they are playing in the most important mobile content spaces these days, and are slowly working towards horizontal integration of input technologies. You probably use more than one of their products.