Archive for November, 2010

Never tell the user off.

Sunday, November 21st, 2010

Do not let them get into trouble in the first place.

You don’t like being told off do you? You wouldn’t like it if someone you were working with explained your next task to you so badly that you were bound to get it wrong – and you were guaranteed to get a ticking off? Too right you wouldn’t. Then why should you allow your software to do that to someone who has paid you to help them?

There is an old adage “the customer is always right” – well I don’t believe it. In fact the customer is pretty well always wrong. But you don’t need to rub their noses in it. And they have paid you, so they do need indulging. They have a task to perform or require a result and they may think they know what is required to achieve that result. In fact most of them won’t have a clue as to what the steps required to get there are – but somehow they will know how to get there. It’s intuitive – and you must not break that unconscious link otherwise your user will be brought up sharply and uncomfortably. He won’t thank for that at all.

It may well be harder to create a workflow for your users that always guides them correctly to where they need to go but surely that is a good investment in time? People may only remember a good software time for minutes but they will remember a bad software time for ever. Never assume that your users won’t walk, and never hope that they understand the software as well as you do. However well they understand it you must understand that they will never ever use it the same way that you do. I promise you that the biggest learning curve here is for you, not for your user.

The only way to catch more paths through your software than you can think of is to test it with real people. Other people. Get them to try to use the latest feature with varying degrees of help, but once they start using the software don’t help them anymore, don’t stand behind them, do not guide them, just let them get on with it in as relaxed an atmosphere as you can arrange. But do watch them – and don’t ignore one single hiccough, slip, difficulty or stupid choice that they make.

Every single mistake they make could be blamed on you. If your code hadn’t let them build up to the error then the error itself could not have been made.

I’m not going to talk about the mechanics of testing here for long, but never underestimate how important it is. During a software meeting once a manager came in and asked the programmers “why do we keep releasing crap software?” He wanted us all to come to the next week’s meeting with two reasons each. Of course no one did, except me (*sigh*), who came back with nearly 20, written up in an essay called “Why we keep releasing crap software”. I have to admit that this didn’t go down too well and not one single thing got implemented until after I had left the company – and then some of it was implemented. And after my ex-boss left the company some more of it was implemented. A large number of my points concerned test, and the lack of it within the company. One of their favourite responses to “We can’t test because we have no hardware to test on” was always “well there is currently an exceptionally high need for test hardware so you’ll have to wait”. Actually you’ll hear a very similar excuse nearly every time you phone a call centre – just before you are put on music on hold at 20p per minute and the magnitude of stupidity of the comment is identical. If you are repeatedly told “this is an exceptional need” then it is clearly not “exceptional”, merely inconvenient – and probably then only according to the accounts department.

Always try to ensure that everyone has enough resource to carry out proper test.

So how do you avoid telling the user off?

There are a number of ways in which a user can feel as if he is being told off and some of these have nothing to do with programming, but everything to do with programmers. Programmers – generally  – are highly skilled at writing code. Writing code is – generally – a lone occupation and programmers are – generally – not brilliant communicators with non-programmers. Telling a user that their “Input is invalid” is nigh on pointless. Particularly if it is displayed as a result of clicking an OK button on a form with 20 fields. Which of the 20 fields of data is (or are) invalid? In what way is it (are they) invalid? What does the user have to do to correct its invalidity? What (if any) damage has been done to the user’s other data? Was anything saved? Was anything lost? How far back will the user have to start again? And was the data on the last form actually valid, but some part of it was inconsistent with something entered three screens back?

There are two options here:

  1. Work out all the complex patterns available to the user via the form (and any others before and after), filter the ones that do (or may) cause a problem, then communicate the problem fully, accurately and gently
  2. Don’t allow the user to enter data that won’t make sense to your code in the first place

We’ll leave error reporting to another time – it’s a big subject. Here we’ll look at designing your screen forms properly. Because if you do it properly then the error reporting can be saved for reporting errors rather than advertising programmer incompetence.

The fundamental aim here is to allow the user as little choice as possible while completely fulfilling his needs in order to progress through the program. The next thing that can be done is fully, completely and clearly describing what is required by every field. Offering help that merely fills out the name of a field is a waste of everybody’s time. You will see this over and again – a handy question mark placed near an input field. You hover the mouse over it and about three words appear, or a simple rewording of the title of the edit box. Believe it or not, the title “User name” next to an edit box is not enhanced by a tooltip that says “Enter user name” is it? Is it?? No, it isn’t. If you are going to offer help then show the user you understand the problems associated with filling out the form you have put in front of them. Show the user (or at least pretend to them) that you care about them. Think about the user names that your customer may have had to get this far. An example – my email requires two user names, my broadband login and my email login. Make absolutely sure there is no ambiguity as to which is required on this form in front of the user right now. If you get asked “which name do I enter here?” during test then it doesn’t mean that the user is being thick (actually it doesn’t even matter if he is) it is not clear. But it might mean that the programmer is. Consider looking back through your interface and give the two user names two clearly different titles such as “login name”, “user name”, “registered name”. Maybe don’t even use the word “name” in one of them. Think longer. Think harder. Set out to make the user have a good time.

If it is possible offer a drop down list of all possible entries (this may not be a good idea where security is an issue such as this instance, when dealing with user names) – obviously it is then utterly impossible to put rubbish in that field. Remember to update any other drop downs once any selections have ben made that may cause any entry to become an illegal combination. This simple effort will sidestep a huge number of problems that have otherwise to be dealt with when the user clicks the OK button. With a bit of thought so many places where a user would normally enter data can be replaced with a fixed set of choices – if a little planning has gone on first.

So don’t tell users off. Don’t belittle them. Don’t ignore their needs. Do realise they think differently and while neither your way nor their way is wrong, their way is valid.