This is a very quick post about usability & informing your users.
As you’ve seen on my home page I do indeed have a quick testing tips section which due to my normally excessively long posts, has been neglected of late. Thankfully I had some time tonight to write about a brief chat I’d had in work today, which can join that small pile of quick testing tips
The question
So today one of my testing colleagues approached me to ask what our minimum allowed browser response times were. 1.5 seconds I replied. He went on to tell me about the scenario he’d been testing which had exceeded this time limit.
Essentially the scenario was taking our live environment & exporting it to a format which could later be re-imported. In other words allowing our database to be extracted & imported into another environment or database type. Obviously the 1.5 second limit was a little short for such an intensive scenario & in the past with similar intensive administrative tasks we’ve agreed upon a much larger time limit, which is fair; one rule doesn’t fit all of course.
So I’d explained as it was a pretty large task it would be acceptable for it to exceed this 1.5 second time limit. He’d agreed & said he’d thought the same but just wanted to be sure. I suggested that he should run it past the stakeholder to determine what its new upper limit should be.
Informing your users
Simple question, easy answer right? I then went on to ask him about how the user was informed about the task being labour intensive. It’s good manners after all for a program to let you know if it’s going to take some time. In fact, as Jakob Nielsen famously suggests a user’s attention will switch to other tasks at hand after only ten seconds.
So he went on to tell me that his team had placed a dynamic component which indicated graphically to the user how many percent complete the task was. Cool! It informs us, so everything is just fine and dandy right? Well not quite!
Blocking a users work flow
This program places a glass pane over the task at hand, which essentially indicates to the user that the program is busy & while it’s busy they are not allowed to do anything else.
I can’t recall what the exact waiting time for this task was, but it was into the several minutes & not seconds. So tomorrow I’ll sit down and chat with him & see if there is a better way to do this that will allow user to continue with their tasks whilst this task works away in the background.
How can you improve a users experience?
Tips for labour intensive tasks:
- Always consider your users emotions when using your application.
- How would they feel in this situation?
- How would they react to delays to their working process?
- How often would they use this?
- Does the fact that they use it more often change anything?
- Would something upset them over time?
- If it’s seldom used, would things be less of a problem?
- If they are going to be left waiting for some time.
- Allow them to continue to interact with the application, whilst the task works away in the background
- Would you be happy being interrupted by a program?
- Would you like to have to wait for it to complete before you could do anything else?
- Inform them prior to the task that it may take some time (proactive information, not reactive)
- Try to avoid information via a popup dialogs.
- Will the dialogue interrupt their work flow?
- How many times per day with they use it?
- Is there a better way to present this information?
- Try to avoid information via a popup dialogs.
- If possible inform on the tasks progress.
- Allow them to continue to interact with the application, whilst the task works away in the background
- Informing the user when the task has completed will improve the users experience.
- Is this method of informing usable?
- Is it invasive to their workflow?
- Does it improve the experience?
Not just GUI’s
Of course this isn’t just limited to GUI’s! I remember a few years back I was asked to run a script. I can’t recall what the script was or even what it did, however I can remember what its output looked like when I executed it!
I kicked it off and waited for around a minute for something to happen & nothing did. I switched my window to some other tasks I had to complete & after about five minutes I returned. There it was still doing something; I just didn’t have a clue what. So I went to talk to my colleague who’d asked me to run this script & then he told me “Yeah its rubbish isn’t it! I was wondering what it was doing the first time I’d run it as well. Just leave it running & it’ll be finished in about an hour.” Oh! Now he tells me how long it takes!
So the point I’m getting at is even scripts should consider their users. If it’s labour intensive & will take some time, then inform the user about that prior to executing those labour intensive actions. Better still! If you can run it in the background then do that, so that they can continue to use their interface uninterrupted. I can’t recall how many a times I’ve run a script & had to open up a new interface because it’s taken over my console doing its tasks.
So please do consider your users feelings when you leave them waiting around. You could do it better, couldn’t you?
No related posts.
Hi Darren,
Interesting post. It occurs to me, though, that sometimes the information we present is actually much help.
I am reminded of progress bars that give you an idea of how far through the particular step of the task the computer is but do not give you any feedback about how many steps remain so actually you are none-the-wiser about how much longer you have to wait.
Everybody laughs at some point at what has been dubbed “Microsoft time” but with good reason. The issue there is that the time is extrapolated from processor clock cycles which vary depending on processor utilisation as time goes on but unless you read up on how ‘time remaining’ is calculated you are not going to know that.
In summary I think another thing to think about is how useful the information we plan to give will really be to our users.
Thanks again for a great post.
Regards,
Stephen
Hi Stephen,
I agree with your thoughts on progress completion. While I was writing this I pondered on the topic of estimated completion times. Like yourself I immediately recalled my experiences with “Microsoft Time”. So I decided to leave it out & I’m glad I did, as you’ve summed it up better than I would have.
There are so many aspects to usability that it’s often very hard to get things right first time around. You could also argue who is it usable for? Something you’ve done to please one persona may upset another.
Cheers,
Darren.
Great post, Darren.
IMO response time is one of the most important factors in user experience. The system can be difficult to understand, have cluttered dialogues, or just be plain ugly, but if it responds quickly, most users learn to live with it. But performance problems will continue to bug them over and over again. I don’t think it has much to do with feelings, more something like neural feedback, but of course slow response will result in bad feelings.
By the way: This is one place where think aloud tests fail. They usually make users accept longer response times and focus more attention on design, wording etc. Which, of course, can be very relevant too
/Anders
Hi Anders,
Thanks for taking the time to comment I agree that response times are one of the most important factors in user experience.
I’ve seen people visibly upset from poor response times. In fact I sit just behind someone who actively projects his frustrations whenever something is slightly unresponsive. I don’t even think it has to break Neilson’s 10 second rule before his anger is verbally projected to our team
I’m not sure about “think aloud tests” failing when considering response times. Perhaps this is just my inexperience in actually using this technique. In theory I can’t see why it should matter? Perhaps I just have to try them out at some point & take this into consideration.
Cheers,
Darren.
Projecting ones frustrations is a great way to get emotions under control! User: “This system is killing me, it is SOOO slow, WHO MADE IT!???” (developer is hiding behind his screen). Tester: “Where is that bug now?? WHO HID IT!?”
Regarding the think aloud. It’s a few (hmm, maybe it’s actually 10, I’m getting old) years ago since I last did one. But IMO, when speaking their thoughts users (1) think more slowly and (2) tend to be more polite, accepting. The think aloud test is great for finding the things in the UI that confuse users, but not that good to show the emotional side of things, frustrations etc. But of course it depends on the situation!
Hi Anders,
Your first paragraph made me laugh It’s actually very funny. Myself I do get upset and curse at my computer sometimes. I do try to keep it under control though, but we all get those WTF! moments now and again, when you just can’t take it any more Or at least me & some others I know. I know a whole bunch who are just too nice to their computers! I wonder if they ever suffer from built up computer rage? Hmm…
Now you’ve explained think aloud a little more I can understand why delays would be less apparent. It does sound like a good concept and certainly it’s something I think everyone does to a lesser extent on a daily or weekly basis, or at least I’d hope so. I’ve never set about doing an evaluation with a feature using only this technique nor have I ever tried the technique even. Sounds like it could be a worthwhile experiment.
Perhaps even with some good requirements specification, with nice little wire frames it could become a proactive testing technique? Think about it! It’s not uncommon for usability testing to be done from requirements specification & that in itself is proactive testing right?
Let see how good our requirements are next release & I’ll update you on how it goes.
Nice one Anders!
Cheers,
Darren.