It seems to me that the answer is not as clear as we might at first think.
In software products we tend to think about “responsiveness”. This is a typical focus on the functionality rather than the need, the symptom rather than the cause.
Philosophy gives us two opposing views of what time is. One is that time is a fundamental part of the universe, a dimension in the spatial-temporal fabric. The opposing view is that it is no such thing, but simply an intellectual concept that helps us to make sense of things, order events in a sequence and compare them.
Time is an illusion. Lunchtime doubly so.
Douglas Adams (1952 – 2001)
What has this to do with our users’ experience of time?
I think in software we tend to focus on the former: elapsed time rather than the later: perceived time. The former is absolute; the latter is relative and context related.
One common experience is that a user has to complete a particular task by a particular time. It might appear that the only thing that matters is the total amount of time it will take the user to complete the task. But is that right? Do we ever start a task at the moment we are given it? Do we ever work on a task without a break and to the exclusion of everything else?
Time flies like an arrow. Fruit flies like a banana.
Groucho Marx (1890 – 1977)
For example, here I am, writing this article, at the same time thinking about two others, helping my son with his Java programming and my wife to prepare for a lecture; who says men can’t multi-task? Good software products allow us to multi-task with them in achieving our goal.
Who is doing what, when?
Users go through cycles of activity during their work, from intense focussed work through to, well frankly, messing about.
| User Activity | |
| Messing About | Apparently wasting time, where they appear to be doing random activity without much direction. This could equally be a very creative period where the user is hoping to find synergy and serendipity. |
| Frantic Activity | The user has finally figured out what to do and is very focussed on that activity. They are likely to have a train of thought that they are following in order to achieve a clear objective. |
| Daydreaming | Having worked through that train of thought, the user kicks back and stares at the ceiling whilst they try to figure out what to do next: save the world or make another cup of tea? |
Meanwhile software products tend to be written to go through an analogous series of activities from overheating the CPU through to wasting cycles.
| Product Activity | |
| Awaiting User Action | The product is primed and on the starting blocks, ready for whatever task the user is going to throw at it. |
| Busy | The user has given the product something to do, so now it is off doing it. That’s got to be the right thing to do hasn’t it? Even if it is going to take seven and a half million years, right? |
| Awaiting User Decision | The “Oh, forgot to ask whether you wanted sugar in your tea” moment, as the product comes to a point where it needs the user to make a decision. Typically this happens just after the user has left for a long weekend. |
The user and the product tend to cycle through these different stages in an unhelpful and asynchronous manner. Let’s look at the impact of various collisions.
|
User Activity |
||||
|
Wasting Time |
Daydreaming |
Doing Stuff |
||
|
Product Activity |
Awaiting User Action |
OK |
Bad |
Good |
|
Busy |
Good |
OK |
Bad |
|
|
Awaiting User Decision |
OK |
Bad |
OK |
|
Design Principles
So what does all this mean in practice? Looking at each of the “Bad” states in the activity table we can make some simple, generic principles about how to deal with them.
- If the user has not been doing anything for a while it is ok to go off and get on with something else, a slight pause in responsiveness when switching back to the user’s activity will seem quite natural.
- If the user is actively engaged in interacting with the product, all activity which may take more than a few microseconds should be delayed, however hard this might be.
- When a user decision is going to be required, or may be required, ask for it first whilst you have their attention, even if this will increase the total elapsed time that the activity takes.
I believe that what matters most to users is that when they give the product their attention, it returns the favour by being responsive. It should not nag for constant attention, but should ask up front for the information it needs and then be honest about how much time it is going to take before completing the task or needing more input. That way the user can move on to other activities, day dream, make a cup of tea, etc. Saying that the application is going to take “some time”, whether explicitly or implicitly through an inaccurate progress bar, could mean almost anything. For Captain Oates, the definition of “some time” was extreme.
Other ideas
Beyond the micro management of our daily activities there are wide cultural differences in the perception of time and approach to it as described by Philip Zimbardo, Professor Emeritus of Psychology at Stanford University in “The Time Paradox”. Even better, follow my good friend Bridget’s advice and watch the RSA Animate video of him talking about “The Secret Powers of Time”: http://www.youtube.com/watch?v=A3oIiH7BLmg. Fabulous! There has to be a whole raft of ideas here.
Half our life is spent trying to find something to do with the time we have rushed through life trying to save.
Will Rogers (1879 – 1935), New York Times, Apr. 29, 1930
