Why buttons start wars
It is not entirely uncommon for me, or others in my line of work, to get into arguments with colleagues over buttons. I’m not talking about the kind of button you sew onto a shirt. What I’m talking about, are those little elements on a software application or a website that human beings spend their time clicking, pressing or otherwise physically interacting with in order to make the software do something. But before I go on, please allow me to explain how a simple interface feature such as a button can be such a contentious issue in the first place.
Upon casing an eye over some proposed changes to some software, I noticed a button. The purpose of the button was to initiate a refund process. Specifically, when the user of the software clicks on this button, the system will ask for some information it needs to process a refund. There is an ‘OK’ button at the bottom of the screen. When the user clicks OK, after entering the data, and system processes the refund in the whirring and blinking way that systems do. I raised the question with the developer why they’d called the button ‘Unapply Payment’. The developer looked at me with that kind of look that I would expect to get had I dared to suggest that beer is best served hot. It was explained to me that ‘Unapply’ is the obvious name for the button because the system is performing a reversal of a function it has already done previously.
‘So what you are saying, is that the system will unapply the payment?’ I asked attempting to clarify the explanation. ‘Exactly!’ said the developer with a satisfied grin. ‘It is no different than the ‘Undo’ button you use in Word’ he said referring to the Microsoft Office application. ’And since the ‘Undo’ button exists in Word, it is commonly understood by most users.’ The developer could tell by my single-raised eyebrow that I was far from agreeing with him. I’ve heard this very type of reasoning before. It is an argument that is quite common in software design. But there couldn’t be a more flawed argument.
The first flaw should be obvious. The word “Unapply’ does not exist in the English language. But the developer had assumed that users will automatically know what its meaning is. This is a risky assumption. If you think of how messages can be misinterpreted even at the best of times, making up words is not the most wonderful of ideas. How will the user know the intention of ‘Unapply’ doesn’t mean ‘cancel’? Cancelling a payment implies a different result entirely and is not the same as refunding as the function is described to work. Cancelling a payment, in finance terms, is voiding a payment. And this button will not void the payment.
So, what about claim that the button would do the same thing as the ‘Undo’ button commonly seen in other software products? Well, I suppose it’s a start in the sense that at least it’s a real English word. But is it the right choice for this button? Let’s consider the context of the ‘undo’ command the computing environment. In computing-land, the ‘Undo’ command is described by almost all definition sources as ‘a feature of a computer program that allows a user to cancel or reverse the last command’. MS Word’s Undo button is consistent with this meaning. When you ‘undo’ in Word, the change you last made is erased. This is its common meaning and this is how it is always implemented. Unless of course someone decides to implement it in a different way, and end up confusing everyone else, including me.
Le’s apply this logic a little wider and apply the logic elsewhere across the software. Let’s say that anything you that you do in software, should be called ‘Undo’ when you want to effectively wind back the instance of it happening. After all, buttons, tabs and other interface elements should always be consistent on every screen. And you can get away with a lot, provided it is consistent and documented. So to ensure consistency across the software application, will we now change all relevant buttons. ‘Void Invoice’ will now be ‘Undo Invoice’. ‘Close’ will now be ‘Undo Open’. When we want to delete something will we now call it ‘Undo Save’. Uhhhhh. Okay, so we now have a new set of problems.
It should come as no surprise that the most obvious name such a button is ‘Refund Payment’ because that is the name of the activity the user will perform. The word ‘refund’ is a commonly-used English word that most people between the ages to 7 to 107 will understand to mean the reversal of a payment that has been received from someone, for some item or service that has been provided. ‘Refund’ is not a technical word. It is real-world word. If I ask you to refund me the $10.00 I gave you earlier, you know what I am asking. It would sound very bizarre to say “Fred, would you please unapply the payment?” or “Mary, I need you to undo the payment”. The word ‘Refund’ is not misleading or confusing. And it completely and accurately describes what user will have the ability to do when they click this button. The user doesn’t have to try and put themselves into the shoes of the programmer and ascertain think of what the button might really do. So if agree now that it make no sense at all for me to tell you to ‘unapply the payment’ when I’m really asking if you’ll refund me the 10 bucks I gave you earlier, then why on earth would we find it reasonable for a computer to communicate in these terms in the user interface of a website or some software?!
I don’t blame the programmer. I do not denounce his opinions or views because I think that he is stupid. He isn’t stupid. Not stupid at all. But programmers are trained to think in machine terms. They build things in machine code that process instructions in machine language. This is not a fault. It’s a necessary skill to have. But it just seems that the longer you think this way, you can tend to forget, or perhaps appreciate a little less, that this machine will communicate with a real human being who isn’t a machine and isn’t interested in becoming one or thinking like one. Of course this is not the case woth all programmers and many do think with with their communications hats firmly attached to their heads when developing the user interdace. They should too. The interface is the only thing separating the person from the program code and should always be designed so the user understands it. It should never be the case that the user should have to think like the machine.
A terrible user interface on top of brilliantly-coded software is in every way a bad software product. People using poorly-designed software hate them with a passion. They are often extremely frustrated and less productive. Let’s be frank. We’ve all used some dreadful shockers. For those of us in IT we’ve all had to support some dreadful shockers. And we’ve all had to deal with bucket loads of unhappy when faced with people who couldn’t understand what the system was telling them. This miserable situation can easily be avoided if a small amount of attention is paid to how the system will communicate with the user and how humans interact with the system. But in the development of software applications, particularly when the application won’t be used outside of the company, focus on making the product work from a user-experience point of view is the very first thing to be sacrificed. Many Project Managers don’t put up much of a fight because they see it more as a ‘nice to have’. Personally, I see it as a core requirement. I would rather drop one or two non-essential features in favour of making certain that what ever we deliver has a high-quality user interface that people can use without the user ending up with crying in a corner. One that includes buttons that are labelled correctly, screens are laid out in the correct order, spelling and grammar is correct and consistent and that everything on the user interface makes sense.
On those rare occasions where software/web/ digital designers are allowed to take a moment and study how humans interact with computers, we end up with products that completely reinvent the computer experience. As much as we like to make Apple the latest corporate punching bag, products such as the iPhone and the iPad immediately spring to mind given that they have single-handedly done more for promoting user-friendliness in computers and devices than almost anything else that came before it. Windows 3.0 also did it many moons ago. We could all learn a bit from why these products are so successful. Many point to the limitless and hungry Apple marketing machine. I don’t buy that, at least not in itself. A good marketing budget always helps a lot, but I just can’t believe that any marketing machine will ever be that successful if the product it’s selling causes frowns, bleeding knuckles, a sore foot or a broken window.