It's me, Sean Patrick Payne!
PAYNEful.co.uk | The Site Where Humour Goes to Die - a Repository of Things by Sean Patrick Payne
Sean's Facebook Wall Sean's Twitter Feed Sean's YouTube Channel Sean's DeviantArt Page Sean's LinkedIn Profile Sean's PSNProfiles.com Page Sean's Steam Profile Sean's GitHub Profile
Return to Main

The PAYNEful Portfolio – UX: The Invisible Developer

Something dawned on me recently and I wanted to put it down on digital paper because although what I’m going to discuss should be obvious, it apparently isn’t.

The Non-Existent “Idiot” User

UX, a ghastly acronym that actually stands for “User eXperience”, was one of my favourite modules at university. It concerned people’s expectations when they use a device or digital interface, and how systems should talk to their users. One of the biggest UX points is always “feedback” – if there’s a problem with what a user has entered into a system, it needs to explain that there is a problem to the user in the hopes that the problem can be rectified with further human interaction. An example of this would be inputting your credit card details into Amazon’s checkout page and accidentally mistyping the number.

Whenever I develop a GUI (Graphical User Interface, like what you’re using to read this) and a system to go with it, I try to make it as simple as possible for the user who is going to interact with it. I could use the phrase “making it idiot-proof”, but that’s offensive on so many levels and would be a discredit not only to the user I’m designing it for but also myself – it would imply that I don’t recognise that technology has accelerated to such an extent that we do have large swathes of the population who simply do not understand computers. They are a foreign concept – imagine taking someone from the 1920s and, once they’ve got over the magic word box you’ve shown them, then explaining that to interact with it you have to use a small plastic thing called a “mouse” and a “key-board” with a seemingly random array of letters and numbers on it1 in order to interact with the magic word box. These are tools that would not make sense in any other context, and they don’t have any obvious application at a glance unlike, say, a steering wheel: you turn it left and a series of physical connections causes the wheels on the car to turn left2.

That’s a long way to go for me to say that to assume the user is an idiot is to yourself be an idiot for being so small-minded. No, instead of imagining an “idiot” interacting with what I’m building, I try to imagine someone who is generally unfamiliar with technology. Stan “the Man” Lee of Marvel Comics says that every comic is someone’s first, well why shouldn’t that apply to other things like websites and web applications too? I actually try to imagine my parents interacting with what I am building; they did not grow up with computers and using such devices are anathema3 to them. If the system I am building needed to provide “feedback” to them, what should the message say? It should be informative and not use any jargon. However, no matter how many simplified and articulated error messages in red font I code into the system to indicate that something has gone wrong, a small niggling voice at the back of my head points out every time that in actuality the error message would flag up on their screen and they would patiently wait for the next time I was available so I could look at it for them as “something has gone wrong“, “we don’t know what we did wrong” and “we think we’ve broken it“.

The Two Stakeholders (and the IT Git in the Middle)

You can boil down system requirements to two things:

  1. Who is the system for?
  2. Who is going to use it?

When you embark on an IT project there are “stakeholders” – much like stakeholders in a company, these are parties who hold some interest within the project, be it monetary or otherwise. If you strip away the chaff, you’re left with Party A – the party that wants a system put in place and Party B, the party that will use the system.

Let me give a really simple example. Party A wants a contact form so interested people can send enquiries to them (possibly for business, we’re not writing a Hollywood screenplay here so you can come up with its purpose yourself). Party B will be the people who use the contact form because they want to contact Party A. It sounds really simple in practice, in that Party B fills in the form and it sends a message to Party A (probably an email) with the details Party B wrote into the form. Unfortunately for both parties, there’s a third party we’ll just call Party C, a.k.a. the aforementioned IT Git in the Middle.

Party C has to build the system – get the input from Party A and output it to Party B. However, this seemingly simple transaction will start to throw up certain questions – here is a handful of the sorts of trivial issues that might crop up:

  • How much info is Party A allowed to enter? You can’t make it unlimited in case some joker decides to hold down a key on their keyboard and try sending that.
  • What special characters is Party A allowed? If we’re going to keep track of their input in a database, certain characters are quite dangerous. Someone who knows what they are doing could even enter special characters in an attempt to access or destroy the database!
  • How little of the form can Party A fill in? Which fields on the form are required? Surely name, address and telephone number at the least?
  • If Party A is going to enter a phone number, there shouldn’t be any letters in it, right? And while we’re at it, nobody has a number in their name, surely…

Before long the simple transaction has bloated out into a series of “what ifs” and “maybes”. This is unfortunately the nature of web design, Party C has to make a lot of assumptions on the behalf of Party A and a lot of these can actually hinder Party B’s use of the system.

The Invisible Developer

The assumptions Party C makes when developing the system are requirements that Party A wasn’t aware of and, for the most part, didn’t care about. However, if the decisions weren’t made, Party A would certainly be quick to complain to Party C about the enquiries containing utter gibberish. There’s a lot Party C can do to ensure that what Party B is entering is of value to Party A, but there will always be those who take an advantage4 and sometimes Party C can go a little bit overboard, making the system so constrained it is actually at the expense of Party B.

Through being overly enthusiastic, the web form can quickly become a nightmare to use. The system expects the telephone number to be numbers only, which means it doesn’t allow spaces which a lot of people naturally enter whenever they type out their phone number5. The system requires all fields to be entered but a lot of people don’t have fax numbers6, and when they try to enter “no fax number” into the field it complains about the fax number containing letters. Party B can’t enter their address properly because they live on O’Bannon High-field Lane (I’ve made this address up for purposes of example, by the way) and the address fields only allow letters, numbers and spaces.7

Web developers don’t realise that they are imposing restrictions on Party B that shouldn’t even be there – a lot of the restrictions are actually Party C’s requirements, which shouldn’t even be getting in the way of the other two parties! Party B just wants to talk to Party A, and Party C shouldn’t be making them jump through hoops to do it!

Instead, I believe in the idea of “the invisible developer”, the idea that systems should be like a magic box: Party B enters their information, the magic box does all the hard work and passes the message to Party B. For example, if a telephone number field on the form requires numbers only and Party B enters a number with spaces, surely the system can just remove the spaces for them and not bother them with the effort of using the delete key? If the system is really clever, it’ll clean up the input from Party B too by making names formatted correctly with lower case and capital letters (you wouldn’t believe the amount of people out there who apparently have lost their caps lock key and can’t turn it off). The developer should be doing all the hard work behind the scenes, not the person using the system!

In the ideal world, there would be no error messages or forced requirements on Party B, but that’s probably never going to happen until someone invents a computer that connects directly into the brain Matrix-style. However, I maintain that the attitude of Party C should be to stop being the IT Git in the Middle and start being invisible. Don’t require things from Party B that you can fix behind the scenes with your magic box, and maybe Party B might just get their message to Party A a little easier with the minimum of fuss!

  1. If you genuinely don’t know why “QWERTY” keyboards aren’t in alphabetical order, it’s because they are arranged so that the most commonly-used letters are in the middle and the lesser used letters are on the outside. It’s surprising how many times we use the letter “g” in comparison to the letter “p”. ↩
  2. Mechanics can make sweeping statements about IT, so I’m allowed to make horrible facepalm-inducing generalisations about their mysterious craft too. ↩
  3. You’d think a term for “dedicated to evil” would be too strong in this context, but you haven’t met my parents. ↩
  4. Speaking from experience, I remember one particularly humorous enquiry from a Party B called “Papa Smurf”. If I remember correctly, the Party A luckily also saw the humour in it. ↩
  5. Psychologically this is due to a process called “chunking“, which is part of how humans learn and remember stuff. There you go, I can generalise about mechanics and psychology! ↩
  6. I’ve seen someone counteract this with an error message instructing Party B to enter a “1” into the field if they don’t have a fax number, which to my mind completely misses the point of UX and is a delightful example of Party C imposing requirements on Party B. ↩
  7. I’ve always been curious as to whether I’d ever see any complaints from Mr. 2010 Smith, who had his name changed to a number via deed poll for fun and cannot fill in the form because the name is restricted to letters and spaces only. As it turns out, a quick Google search reveals that you cannot change your name to a number, which is a damn shame in my opinion. ↩

Post by | July 19, 2014 at 11:35 am | Articles, Portfolio and Work | No comment

Tags: , ,