Search the site
What we do
Little Springs Design is a mobile product, research, design, and usability testing consultancy. We help wireless operators, associations, manufacturers, and application & website providers with product and UI design, patterns, training, research and strategy.
Contact us today.
Downloads
Sign up to get a free copy of our Mobile Widgets Whitepaper or almost-monthly newsletter. Or buy mobile Java or web design guidelines.
Recent blog entries
Blog topics
Blog archives
measuring the mobile user experience
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.
1 Comment »
RSS feed for comments on this post.
Just a few things I’ve noted:
A big issue I have during usability testing is that the user experience differs so much between phones, even though it might be the exact same application. I’m talking mainly MIDlets using the high-level UI. Using Canvas or e.g. J2ME Polish takes away some of the pain, but then you instead can shock the user with a UI and behavior that’s quite different from other applications on the same phone, but even so this might be better, creating consistency between phones.
Keys and menu items are placed in a more or less phone dependent way, which makes it hard to describe in a user’s guide or integrated help information. I have to write something like “depending on phone some of the listed commands may be placed on soft keys or in the More menu”, noting that “command” is not a very intuitive word, but “MIDlet correct”, and that some phones say something other than “More”.
One direct advice here is that you should never use both the short and long name of a command (which is supported in MIDP2). That makes it even more confusing to users, especially if they need to refer to help information for using the application, and I’ve even seen some phones select the long name, but still have no room to display all of it. Hence, use the short name only.
The selected UI theme of the phone might affect the user’s ability to read text etc in a quite noticeable way. E.g. SEMC’s phones use the background of the theme as application background, which is almost never what you want. Plain white would be much better, despite being boring, or customizable through J2ME Polish or similar.
Whether text input is inline or in a separate window also differs a lot between phones. Simply put, older phones with less display resolution use a separate window. Note also that when using J2ME Polish, whatever styling you’ve given your application using CSS, that’s replaced by the phone’s theme when editing text, as the phone’s own text input is invoked to give access to T9 etc. I think you can turn this off, but then you don’t get T9.
Providing screenshots of how the application will look on a display might be more confusing for the user than not showing any sample at all, unless stylized/drawn.
My experience of usability testing is that users should not have access to any user’s guide at all (which takes away some of the mentioned issues as well). Rather the application needs to be intuitive and self-explanatory enough for the user to achieve what they are asked to do. In other words, when doing usability testing the task should be something like “write and send an e-mail to this address” rather than “press this and then that…”. The latter is not a usability test, it’s a way to test whether the person in question can follow orders.
The last point then also requires usability testing to be done on a few different phones, e.g. different brands (which is a good way to get different behavior).
Comment by Anders Borg — January 27, 2007 @ 5:18 am