Jakob Nielsen's latest Alertbox summarises the results of the Nielsen Norman Group's second study into the usability of iPad apps and websites accessed on an iPad.

For me the most interesting insight was that unless the primary user lives alone, their tablet is likely to be shared with their partner, children and visiting friends. NN/g concludes that "Tablets are shared devices" and that when designing apps for a tablet "you should assume that you're designing for a multi-user device."

Yet few tablet operating systems provide good support for shared use (driven by its need to control access to sensitive business data, the Blackberry Playbook is a rare exception). And this can lead to significant problems for users. Young children accidentally change settings, delete work emails and reset the game scores of older siblings. Teens move apps between folders, access age-inappropriate games and media, and use stored account and payment information to make unauthorised purchases. Partners must frequently log in and out of each other's Facebook, Twitter, Google and other accounts.

Working your way through these sharing problems is hard work for even the geekiest of us. And while some apps do provide simple ways to control access to multiple Facebook, Twitter and eMail accounts, users must learn the sharing features of each app and create a separate profile in each one.

This again demonstrates how important it is to investigate and understand people’s real behaviour and contexts of use when designing for new platforms.

So when we design tablet apps, we must consider carefully, whether and how to support shared use. Will users each want their own settings and data? Will adults need to protect some sensitive data from their children? If your app connects to a website or web service, will different users need to connect to different accounts? If you do need separate user profiles, how will you store and how will your users manage them?

NN/g's research and the multi-user support within many apps, suggest that better support for shared use should be a priority for tablet operating systems. The access experience could be very simple: tap your name and enter a password/code, or even just show your face to the camera. And while each app would still need to decide how it handles multiple users, standard APIs and common interface guidelines would make life easier for designers and developers. And most importantly, make the experience of sharing more simple and more consistent for users.

2 comments

Working with users during the design process will untie project knots and boost team productivity and focus. But there always seems to be an excuse for not testing. Here are 4 ways to counter the excuses and make usability testing happen.

Excuse 1: “It’ll slow us down”

Finding users, building prototypes and working through hours of research takes time. Why not spend that effort on writing more code?

Counter argument. You say: “Our business objective is to reach profitability as quickly as possible. To do that, we need to understand what our customers really need and make sure we’re all agreed on the direction. A usability test might take some time in the short term, but it will help us reach our overall business goal quicker.“

Usability testing, like many UCD tactics, is an investment. You put in time and money, but you get back a product that sells better and costs less to support. But usability testing is also beneficial during the design process…

1. Design the thing better, quicker: Trying to design a product for target users, without ever meeting any, is like pulling teeth. But if you just watch a few users using a prototype, a competitor product or their current system, they’ll tell you what you really need to know quickly, effectively and (comparatively) effortlessly.

2. Manage the politics more easily: Successful designs come from teams all pulling in the same direction. Usability testing results will reduce squabbles, give confidence to management and get people to focus on improvements rather than feature creep. Even the most sceptical team members can’t ignore videos of 5 or 10 real people battling with their software.

3. Get a team energy boost: Seeing ideas succeed makes the team feel positive. Seeing them fail motivates people to sort things out.

Excuse 2: “Our product is already perfect”

You and your team will become so deeply familiar with the product you’ve designed that you will think it is perfect.

Counter argument. You say: “We believe the product is perfectly easy and useful. But can we prove it? How many problems exist that we’re not aware of? What impact might they have? Developers may think their code has no bugs, but we still hire testers to prove it. What evidence do we have that our design is perfect first time?”

This behaviour is often referred to as “drinking your own Koolaid“. It means you’re doubly ignorant…

In a thought-provoking piece a few years back called The Five Orders of Ignorance, software engineering expert Philip G Armour says,

“The hard part of building systems is not building them, it’s knowing what to build — it’s in acquiring the necessary knowledge… A functioning system is the by-product of the activity of finding things out.”

Excuse 3: “We already have lots of feedback”

Listening to customer feedback via email, call centre or the web is vital. Analytics and search log analysis is great, too. And it can seem like you’re getting all the user input you need.

Counter argument. You say: “We’re only getting feedback on major issues and from committed product users – lots of other people encounter our product and never feed back. So we’re getting a skewed perspective. Usability testing will let us observe and discuss all sorts of things that customers and non-customers would never actually feed back about. It will also explain what to do about the strange patterns we’re seeing in our web analytics. This extra insight will give us a competitive edge, because it’s not obvious stuff that our competitors also know.”

Excuse 4: “This concept is not ready to test yet.”

It’s easy to tell yourself that you’re not ready to work with target users yet – that your ideas haven’t settled down to something stable and complete which users will approve of.

Counter argument. You say: “Don’t worry if it’s not ready. We’ll test what we’ve got, and won’t worry much about the areas where we know things aren’t finished. It can give us reassurance that we’re heading in the right direction and stop us from spending loads of time designing a blind alley.”

The truth is, your ideas will never be stable and complete until you’ve had the input from users. Until then, they are just hypotheses. Better to test your hypotheses when they are young and flexible, rather than when you’ve spent weeks on refining them, and publicly declared them as “finished and ready”.

How to run that test

Doing the perfect usability test is no doubt hard. But doing a useful test is really easy…

As Bruce Tog says, without iterative usability testing “you’re going to throw buckets of money down the drain”. So just get out there and test.

2 comments