I’m continuing my discussion of the O2 registration process, and showing how it’s a good example of how testers can bring a more creative approach to testing than just ticking off the test cases. See the previous two posts from which this one follows on; “Usability and O2 Registration” and “O2 website usability: testing, secrets and answers”.
The next problem with the registration form was clearing valid input fields when an error was detected.
This is something that really bugs me. Ok, if I’ve entered something invalid then I deserve to be punished by the application. I’ll take it like a man. Just give me the snotty error message, and clear that field. But clearing other fields that are fine? Well that’s just mean.
Now I’m straying outside my comfort zone here and if this were a real project I’d be asking questions that coders might consider really dumb. On the other hand, they might be shifting uncomfortably in their seats. Fortunately I spent a few years as a computer auditor asking exactly those sort of questions. It’s not that I developed a thick skin (though I did). It’s more that I realised you can get a pretty high hit rate with questions starting “sorry if I’m being a bit dim here but …”.
Server side validation?
Wiping correctly completed fields looks rather like developers are relying on server side validation. If there’s a problem they then have to regenerate the form with an error message.
Does server side validation mean that they’d have to send the password and validation code back from the server to rebuild the form? Is that considered a security exposure? I don’t see why, but I’m not sufficiently technically aware to know for sure. Please someone, enlighten me.
If that is a potential weakness, why are they doing all the validation at the server? Sure, the definitive validation has to be at the server, or you’re leaving yourself wide open, but really, all of the validation? I don’t know the answers. I’m just asking. “Maybe I’m being dumb, but …”.
A further problem with server side validation is that users are given the chance to choose an account name. O2 have over 20 million customers. The chances are that a user’s first choice will have been taken. The validation code and passwords will be removed from the form each time the user asks unsuccessfully for an account name.
This is quite a common problem and there are solutions. You don’t have to make your users suffer. You can use Ajax to communicate with the server in the background without having to refresh the form. Applications can therefore check proposed account names as the user is typing, and provide immediate feedback. Maybe there’s a good reason why Ajax hasn’t been used, maybe not.
The point is to ask, and force developers to justify whacking the users over the head. You mustn’t do it in an aggressive or sarcastic way. People often do things in certain ways because it’s convenient, without questioning their motives. It’s helpful to be forced to sit back and think just why we’re doing it that way, what the implications are, and if that route really is the best.
It’s also vital that you don’t come across as telling the developers that their technical solution is wrong and that you know better. Almost certainly you don’t. You’ve just got a different perspective. If the developers think you’re fronting up to them in a technical showdown then they’ll humiliate you, and frankly that would serve you right!
Do we really need all of these fields?
Next, why are O2 asking for my name and address? At first that seems like a daft question. I’m registering. Of course they want these details. It’s a no brainer. That seems to be the extent of the thought O2 gave to the matter.
However, I’ve got contracts for both phones. O2 already know my name and my address. There’s no validation of the name and address against the details that are already held. Will O2 treat my input as a change to my account details? Actually, they won’t. I know that from experimenting with the site.
So why bother capturing the details? Why bother risking confusion later when they realise they have two addresses for the same account, or when the customer is puzzled that O2 aren’t using the new address? These shouldn’t be rhetorical questions. Testers should be asking questions like that.
Something else that puzzles me is the large number of text boxes to capture the address. Why do they need the address pre-formatted like this? Is this just for the convenience of the coders?
The postcodes should be validated, and should be captured in a separate box. At a pinch it can be justified having the house number, or name, captured separately, especially if the correct postal address is being generated. I’ve seen only two half-way convincing arguments for multiple address boxes.
Firstly, there’s the “users are idiots” argument. They will enter garbage in the address field given half a chance. Secondly, fraudsters love to mangle addresses to make investigation more difficult.
The first argument has some merit, but multiple input boxes don’t help much. Users can still enter rubbish, and that’s why the second argument doesn’t really stand up. I’ve worked on many fraud investigations, and separate input boxes is no handicap to a fraudster.
Insisting that users input their address in a certain way risks annoying them. O2 are not guilty of it here, but some companies use drop down menus with errors in them. My address on Ebay and PayPal is wrong because they’ve made it impossible to enter my correct address. They don’t understand how the system of Scottish postal addresses works. Stuff still gets here, but it annoys me every time I see it.
Splitting the whole address up into a series of separate boxes looks very much like inertia. That’s the way it’s always been done – no need to question it.
Did anyone question why O2 need to capture all the other mandatory fields? Are these genuinely essential, or just nice to have? It’s not as if users have to provide the information. They might react by cancelling the registration process, and denying O2 any benefit at all. Or when they realise they can’t continue without entering anything, then that’s just what they’ll give you; anything! What value does management information have if you’ve goaded users into entering false data?
I recommend this blog piece by David Hamill on the subject. His blog has lots of other good ideas and discussions.
Forms should not be designed by throwing every possible field that could be captured at a wireframe and then telling the coders to crack on. Each question should have to be justified because each extra question will tip some users over the edge.
There’s a trade-off between capturing information and making things easy and pleasant for customers. If your customers think you’ve gone too far in the wrong direction then they’ll punish you.
What’s the big picture?
Specialists focus on their own area of expertise, in which they are supremely confident. They expect others to defer to them, and in turn they defer to other experts in different areas.
Sometimes the whole process needs someone to ask the pertinent questions that will open everything up and help people to see the big picture. Testers can do that.
This look at the O2 registration process has been more interesting than I expected, and I’ve had more to say than I ever thought at the start. However, I promise to pull it all together with my last piece, “The O2 registration series – wrapping up”.