Recent Blog Posts

Why is it that companies don't seem to want to keep customers happy?

15 months ago, I acquired a phone on my own. I then activated it on my existing Sprint account. The Sprint information system then reset my timer counting down to my new phone, even though I only had a couple months yet. Now this phone's battery has dropped to 10 hours of standby time, and I have to decide between a new phone and $60 for a battery. I could get a new phone with the carrier discount, which they have effectively robbed from me. Do they not want to keep me around?

Similarly, I moved a phone line away from Sprint with approximately 2 months left on the contract. Sure, the contract says I have to pay a $150 penalty (Verizon has eased this in their new contracts) ... but I'm keeping a line on the account. Do you really want to irritate a current customer that much?

In that same transaction I moved away a line whose phone had never been able to actually work at home. Did this matter to Sprint? No. Sure, I should have mentioned something earlier, but we were limping by. We decided we couldn't any longer.

Cingular activated three phones for me, and it was a great experience. Until I found out that they had decided that all three phones needed voice dialing ($5/month) and roadside assistance ($3/month). Yes, that's $24 per month for services that replicated what we had through other means and we didn't sign up for.

Honestly, Sprint has irritated me enough as a customer that I am seriously considering eating the separation fee ($150) and moving to a new carrier. And I'm an ex-Sprint employee and a Sprint vendor. That's a serious amount of frustration.

How often do you sit down at a computer with an unfamiliar operating system with an unfamiliar browser, and immediately attempt to use an unfamiliar web site or application?

You did that once? Or when you have a new operating system do you instead explore around a little bit?

Usability testing of desktop web sites generally use Windows computers and a major browser. If testing an application, the participants are screened to have the proper operating system experience.

So why is it that I've seen so often a complete avoidance of this issue in the mobile space? The first two issues are simple ... you don't really have to worry about the problem in the desktop space (in other domains you generally provide the hardware as well as the software), and mass-market phones aren't really seen as having an operating system.

I've seen four basic approaches to handling devices when testing mobile applications or mobile web sites:

1. Ignore it. Choose a common phone and have everybody use it during the test.
2. Make everybody a novice. Require that participants have NOT used the device being tested.
3. Use the user's own device. Have them download and run the application or web site.
4. Match devices. Select three or so devices that represent a large portion of your user population. See what other devices in your user population have a user interface largely identical to one of the selected three. Select participants who use any of the above devices. Test the application on a device that matches the participant's device.

Oh - with the increasing popularity of add-on browsers like Opera Mini, be sure your test devices also have the other browser for a mobile web usability test. Let the user choose.

The first option, "ignore it", is not only not realistic, it will wreak havoc with your data. Some of your users will have an experience that matches their comfort levels, the others won't. At a minimum, note which ones are which and adjust your statistics accordingly.

The second option also has its challenges. How many phones has the user used before this one? Did they have a matching OS? Are you testing the OS, or just the application? Will users perform the task you are testing with a brand new device?

The third option, using the user's device, runs into problems with data plans and device management. Does the user have a data plan? Which one? What about a theme? Perhaps a theme that affects the performance of the application? Maybe there is insufficient data available? Maybe the user already has your application or a previous version? How's the battery level?

For most situations, I recommend the last option, match devices. This provides a fair amount of control over the test environment, while allowing you to test your application and not the device. You still get to know where the device and your application don't get along together. You keep costs and recruiting complexities down. It improves the quality of your results.

This post is part of a series on mobile user interface design patterns, excerpted from Designing the Mobile User Experience, John Wiley & Sons, 2007. This last set of patterns will address application management design for mobile applications.

The application state includes what screen is being displayed, what data the user has entered, and any user settings.

Design

Good state management involves four practices:

• Save all user input except passwords.
• Discard task-related input only after the task is complete.
• Save application state, including which screen is being displayed.
• When re-entering the application, return the user to that state is appropriate. It might not be appropriate if the user was viewing transient data or if the application has not been used for a few days.

Applicable Devices and Platforms

All devices, any application platform or web.

When Used

Application state management should be considered for any application.

Rationale

The user, and hence the application, is readily interruptible. The application can be interrupted at any time, by real life people, an incoming call, or a coverage hole. Thus an exited application does not indicate the user's intent to end a task.

Tags: Design,  Mobile applications,  Mobile web,  UI Design Patterns, Permalink | Comments (0)

We will soon be announcing the first of a series of products and services to enable testing the mobile user experience. We're starting simple: usability testing with full video capture with the device on a sled.

In the meantime, however, we'd like to hear from you. What mobile user testing problems are you having? What user experience measurement problem are you having? Maybe I already know the answer to your question, or maybe we'll develop an answer for you.

This post is part of a series on mobile user interface design patterns, excerpted from Designing the Mobile User Experience, John Wiley & Sons, 2007. This last set of patterns will address application management design for mobile applications.

Application acquisition is one of the first touchpoints the application has with the customer. If this is not handled through a carrier or third party aggregator, the following measures should be implemented.

Design

From a desktop web site, the fastest method to get an application onto a personal communications device is to send the URL to the device using SMS. Ideally the URL will have encoded any personal information the user entered on the web site to be pre-entered in the application. Unfortunately, some carriers have disabled the user's ability to click on a URL found in a text message. For example, the Motorola RAZR on Verizon's network in 2005 and 2006 blocked the capability.

WAP Push accomplishes the same goals as sending SMS with a URL, but with some advantages and disadvantages. These messages are designed to not be forwardable, which protects a bit from piracy. They also may not cost the user, depending on carrier settings. Carriers that block URLs from SMS messages likely allow them from WAP Push messages. However, users must have WAP Push (or "Service messages") enabled with the phone user interface, which may not be true by default.
From a mobile web site, a simple link to download the application is sufficient.

Applicable Devices and Platforms

Downloaded applications.

When Used

Applications available off of the carrier's deck.

Rationale

URL entry is difficult and tedious. Many users can not find the URL entry mechanism on their mobile browser. This includes the most sophisticated users. Journalists and bloggers have repeatedly accused certain carriers of having a "walled garden", with access only to approved sites, even though free URL entry is allowed and a search engine allows access to both mobile optimized and all sites.

Tags: Design,  Java ME,  Mobile applications,  UI Design Patterns, Permalink | Comments (0) January 22, 2007

One of the reasons I use the term "user experience" rather than "user interface" is because the UI is limited to what is painted on the screen and how to manipulate that painting. This is of course an important component, but the full user experience includes more.

In the next set of design patterns, I'll be discussing application management patterns. These are non-UI mechanisms for affecting the user experience. How to purchase and download, cookies, and state management. I should add one on techniques to replicate cookies in a non-cookie environment, but I'll do the Designing the Mobile User Experience patterns first.