Recent Blog Posts

I've practiced usability and human factors since around 1995. Last month, I added an MBA to my credentials. I've come to the conclusion that the two groups do not effectively talk to each other. Business executives want to know what the ROI is for a usability investment, usability people end up spending a lot of time developing flawed ROI numbers.

The usability people are talking to the wrong department. It is certainly the case that good usability can decrease support calls, decrease returns, increase sales, and increase efficiency, depending on the exact situation. But it's the Marketing department that has the tools to determine the value of usability (and interaction design, and user-centered design in general) to the customer.

One thing marketers and economists understand (that engineers and accountants do not) is that the cost is unimportant, as long as the price that must be charged to make a profit is somewhere less than, but near, what the customer values the product or feature. At one point in time for me, this was a truism that was irrelevant because it is unmeasurable.

It turns out that the marketing profession has developed tools to measure the unmeasurable, in dollars. My favorite, invented by psychologists, is conjoint analysis (also see Wikipedia). In this process customers can determine the relative value of different features, which can include things like size, overall design (like usability!), and brand.

The magic of conjoint analysis is revealed when you include price as one of the variables being studied. Since you can reasonably assume that the customer values $15 at approximately $15, you can see whether the improved design is valued at more, or less, than $15. You can even interpolate and get an exact value for the improved design.

Once you have a value for the improved design, you can work backwards. If your customers value your design at $25, you price the product at an extra $24, and your company requires a minimum ROI of 20%, then the investment is good if you can deliver the design at no more than $20.

Obviously this analysis needs to be done after a test program is complete, otherwise you won't have any designs to compare. But the analysis can be generalized for future decisions.

Mobile UI design is fundamentally the same profession as desktop UI design, but that doesn't mean that the skills transfer or that a desktop UI designer can turn out a good mobile UI.

In many ways, it depends on what sort of research you do. If you spend several weeks understanding your users when they are mobile, then another few weeks studying exactly what is and is not possible and useful in mobile technologies, then you can do a pretty good user interface for mobile even if you had no previous experience.

It's difficult enough to understand the technology ("what do you mean it doesn't render on that phone! it has the correct browser/MIDP/screen size!"), but understanding the users is more challenging.

So many portions of design practice are rules of thumb, unless you are very rigorous (read: "willing to spend time and money"). In the desktop internet world, there at least used to be the "8 second rule", in which you wanted your page to render in 8 seconds (down from 10 seconds, and a far cry from common practice).

What is the corresponding rule in the mobile space? Why? Or does it vary?

I find myself telling my phone to fetch something (email or internet), then continuing with my real-world activities for a few moments. That's fine, unless I'm in the middle of a process. But if I launch a J2ME application, I do not want to wait even 5 seconds for the application to launch!

When I made the transition from desktop design to mobile design, I had to understand an entire new universe of users - one that is evolving more quickly than computer users, and varies across continents more than computer users. And I don't see most designers even realizing this process is necessary.

Too often, an organization decides to create or obtain a mobile web site, instead of a mobile web service. The difference: the former is a collection of XHTML (or WML) pages; the latter is an intelligent combination of various mobile technologies including XHTML, SMS, location, J2ME, and even desktop web sites.

Mobile applications enable sophisticated interaction with the user, either on a push or a pull basis. Think about the difference between a desktop email application that checks the server for new messages, compared with an email web site that you have to think to check for new messages - but extend the difference in both scope and intensity.

For example, if you go to the MapQuest desktop web site and get a map or directions, you can send your map to your mobile phone. You get a link to a J2ME application - they even automatically detect your carrier, and your map will be available as one of the items in it.

The really nice thing here is I can use my desktop for what it is good at, and my mobile for what it is good at. This application is a combination of desktop web, SMS, and J2ME. Better would be to provide an option for a mobile web presentation of the map, which could also be sent to other devices via SMS.

Side note: I've got MIDP2 installed on my Treo 600, but it was not detected as a supported device. Some more work needs to happen here. Of course, the entire J2ME (and to some extent, BREW) universe has promised but not delivered true cross-device development, so this isn't terribly surprising.

Optionally, this map application could detect progress in the driving directions, seek out traffic, construction, food, and weather information for the regions ahead, and alert the user when plans ought to be changed. This sort of functionality goes beyond a simple website, and is definitely a useful mobile application.