Recent Blog Posts

I ran across this summary of a fascinating study that suggests that instant messaging is starting to take over from SMS among the younger crowd.

This goes along with a point I’ve been making about the different mobile markets, especially USA vs. Japan/Korea vs. Western Europe: these markets are structured differently, which results in their different uses. Voice calls are cheap in the US and we spend a lot of time driving, so we have strong voice demand. Western Europe had very expensive voice calls and Internet connections when SMS was young and cheap, and SMS took off there. Japan has long train rides in which talking is considered impolite, so non-voice is important; a very large chunk of iMode use is the equivalent to (but not actually) SMS.

One thing I find especially interesting about the above report is it was run by Orange: not a US operator at all. So this is not some hokey “Americans are addicted to IM” type finding. Tomi Ahonen who regularly reports on SMS statistics, including in the US. He regularly asserts that US SMS usage follows in lockstep with Europe, except with a 4 year delay. Is it possible that Europe will follow IM in lockstep with the US, except with some sort of delay? And what happens when they collide?

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.

One of my favorite niche blogs is AAS, or All About Symbian. Saturday (my birthday!) they posted this commentary on what exactly is the difference between a featurephone and a smartphone, anyway.

The commentary is more enlightening than the original post, so read all of those as well. I tend to agree with the bulk of the statements; its about customization, customization and also customization.

Most of the people I know have classic smartphones — some Blackerries, and lots of Window Mobile devices, as we're in the U.S. Most of these are of the new, cheap variety — like the Centro or Moto Q. And they are used like the featurephones they replaced. They make calls, add up to 15 people to the address book, take photos, and download a game or two from the operator store. They are terribly excited to show off that this phone can browse the web(!)

When I show off how much more they can do with their phone by whipping out my phone, and showing off some of the 27 (yes, I counted) apps I have downloaded and use all the time, I mostly get blank stares, but sometimes hand waving that its all too complicated.

So, I have to add another facet to what defines a smartphone, the user. Designing around user-intent is not impossible, but I have yet to figure out how to to get a device data repository to encode that.

And I could seriously use a header for "savvy user." Among the biggest design worries I have is getting people to understand that their device — whatever it is called — is almost certainly capable of doing other than those core items, so that the app I am designing gets downloaded, and used.

I remember several years ago, the Nielsen Norman Group published a field usability study looking at WAP usability. They made a number of assumptions, many of which were questionable. Their assumptions yielded incorrect results. One chain of reasoning went as follows: data services in the UK are more developed than in the US, Nokia & Ericsson devices are the best designed, so we’ll look at Nokia & Ericsson mobile web access in the UK and draw our conclusions for the entire industry.

A chief complaint in the study: you had to have an uninterrupted data connection to successfully complete any task, so WAP is crap. Never mind the fact that the Phone.com/Openwave browser was explicitly and multiply designed to not have that problem.

It wasn’t really their fault. They didn’t know mobile and its ecosystem. But they damaged an industry with their research. (No, I’m not claiming they killed WAP.)

We continue to get this. A company who has done design work for a manufacturer at one point will assert “our designers know mobile.” They do, a little bit. But they don’t know how the industry has shifted, nor do they know anything outside of handsets. Device design is a different environment than application design: in the former you get to set the environment, in the latter you have to optimize for whatever environment the application finds itself in.

We’ve done web, application, and device design. When we don’t have to worry about the environment shifting underneath us, I get a little giddy. It will work exactly as we plan it? Wow! We don’t have to worry about distribution? Wow! We can rely on certain hardware and data resources to be available? Great!

The users, of course, don’t know the difference and don’t care.

Mobile interaction design is not a separate profession from interaction design. But it is a complex space, with a similar degree of complexity as health care. As I’ve focused on keeping up to date with the users, devices, technologies, platforms, and industries in mobile, my web and desktop application skills have dropped. Sure I can design a web site, but it won’t be as good as somebody who really knows the space.

Khoi Vinh has asserted the need for the new designer to be able to successfully design native to web, mobile, print, and more. I agree, to a minor degree: any of us claiming a degree of seniority need to be able to understand each of these channels, how they can interact with each other, basics of design for each, and what is an appropriate degree of consistency between them. And to have deep expertise in at least one of them.

We need to have a good understanding of what each channel can do, set the strategy for each channel, then let specialists in each channel detail out the design.

Strategy will involve how to use each channel and how to have them interact. That is one design discipline. Each channel interaction is another design discipline. All are the same profession.

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.