Usability Testing for Mobile

It is useful to see how user's will react to your app in terms of ease of use, finding features etc.
Most apps nowadays also will be used on devices of different screen resolution and sizes. How should we test across these kinds of different domains?
The Nielson group has a good website for all things usability-related.
They have a nice article on setting up a test environment for testing app usability.

Recording your Tests

Generally, when conducting tests you should record a video of your subject using the app. This allows you to play it back later and figure out what was happening.
For mobile, unlike web UX, you really need to record the hands interaction with the device.
To do this you can mount on a tripod a second mobile device and have it record looking down at the device your user is actually testing on.
Another issue that comes up is the room itself for testing.
At least for baseline tests this should be well lit (but not too bright) and should have good access to wireless and cellular reception.
Once you have done initial testing you can vary the environment for lighting, nearby distractions, reception, etc to see how the user experience might change in "real-world" environments.

Typically, you will be interested in how well people can use your app, not how well they understand Android, iOS, etc.
So if you have an Android (iOS) app you should test on people who are comfortable using Android (iOS).
If your target audience is tablet users, make sure the people you test are already familiar with the given kind of tablet.
You don't need a large number of people to do testing on. You will probably learn 90% of what's wrong with your app by just testing on 4-5 people.

You should probably come up with a list of a few simple things you would like users of your app to be able to do or figure out.
For example, will users discover that eating the big yellow circle means that ghosts can also be eaten by them?
You should of course order these by importance to your app.
Pick the top three or four of these things. Give your users some specific goals for what they should do with your app, then record them trying to do that.
For example, find the time of a movie using the Cinequest app.
When giving a set of goals for the user to accomplish, avoid giving hints as part of the goal. For example, find the time of a movie is better than look up the time of a movie in Schedules.

For iOS there are six main screen size to consider:
1. iPhone4, older iPod touch and below
2. iPhone 5/5S, most recent iPod touch
3. iPhone 6
4. iPhone 6 Plus
5. iPad Mini
6. iPad
The 1-3 are more traditional phone sizes, the last 3-6 can support to varying degrees tablet style interfaces.
For Android, we have four main classifications:
1. Small Screen (maybe geared towards 3in-ish size screens)
2. Normal Screen (geared towards 4-5 inch screens)
3. Large Screen (geared toward 7 in screens)
4. Extra Large Screen (9in or larger)
For both platforms have different pixel resolutions one can consider. For android these range from 120dpi up to 300+ dpi.
Generally, if you have an interface, you want to test that it works at the extremes of the range you want to use. I.e., if you have a tablet like interface, does it still work on an iPhone 6 or 6 plus?

Consider the old fashioned technology called the book.
Several key inventions beyond the invention of the printing press made it possible to read books silently and find things quickly: using pages rather than scrolls, having spaces rather than run together text, having tables of contents, indexes, concordances, etc.
Before these inventions finding things in a book was more of a linear search problem.
Consider the case of screen size and ability to find what your looking for.
With a smaller screen, there is a tendency to visually chunk things at only one level of resolution. I.e., we might forgo displaying both an email list and a particular email and instead just display one thing or the other.
Long lists tend to result in linear like search.
Many clicks to things is also bad, because humans can only natural remember things in groups of 5+/-2 and so path length whereby something is found is not only tedious, but exerts a cognitive load.
Further attention on a mobile device is quickly lost, someone will switch to a different app very quickly. According to one study mentioned of the Nielson site, you have slightly over a minute's worth of attention available to get the user to what they want.

Mobile apps often have a navigation bar at the top and an action bar at the bottom.
Apps also can support to different degrees single or multi-pane views.
The use of multi-pane views tends to be more restricted as the device size decreases.
I.e., You might only be able to have it in landscape mode on smaller devices.
An app might make use of navigation bar to organize the data into different categories. As part of the interface you might then allow the nav bar to horizontally scroll in order to keep the path from the top level view to a given detail view as shallow as possible.
An action bar or pop up list can then be used to say what can be done in a given view.
I.e., we separate navigation from action in this can of design pattern.

Nielson's group considers the case of whether is better in a mobile setting to have a long text list or to have a Pinterest style list of images.
This sort of illustrates some of the ideas of cognitive load of small interfaces we mentioned a couple slides backs.
What they found is that even when people are browsing just to kill time, the text-based list tended to perform better.
Only if you had a short list with large clearly distinct category images did images seem to work better. Tiny thumbnail images in a long list did not help.
This might have had something to do with the goals being asked, but the main reason seemed to be that the lists were shorter and maybe also more specific.
In both cases, the users end up performing a linear search. To show the same number of items the length of this search was longer for images. Further, it was harder to distinguish between items when presented as images than as text.
This suggests that images work better in detail views rather than for navigation.