After reading the title of this blog post, you could easily be forgiven for not having a clue what this piece of writing will be about. Not to worry, soon, this will all change.
A warning is due, however. Being called the AMIS Technology blog, this place is usually (over)filled with code, code and then some more code. Not this time. Stop reading here, if you are looking for code.
This short article will be about the most overlooked part of software development. And I am not even talking about testing or documentation. No, there is another aspect to software development that seems to be neglected on an even larger scale.
Decades ago, when applications shifted away from being merely a stack of papers with holes in them, end-users were given an opportunity to interact with these programs. In the early days, people might have been easily impressed, merely by the fact that they were able to deliver input to a program in a relatively flexible way.
This is not the early days, though. This is -almost- 2012. And in a world where people on an average day interact more with machines (of whatever kind) than with other people, users have become quite used to wonderfully created applications, catering exactly their needs in a way that is easy and pleasant to use.
Not so much so, with corporate applications. “It’s their job to work with it, they better get used to it, or they’ll know where they can find the door!” seems to be the paradigm…
If I haven’t already completely lost you, you probably have figured by now, that I’m talking about Human-Computer Interaction. A field of expertise -which I just so happened to have studied at the Free University Amsterdam- consisting of all things related to how us mere mortals work with machines. Key aspects of HCI are the fields of Cognitive Psychology and Graphical User Interface design. Basically, knowledge of the first, is applied when practicing the latter.
Warning: The following lines might be considered shocking by some audiences.
To the end-user, the graphical user interface is the application. End-users do not care about whether or not analytical functions were used, nor does he find it interesting to know the application was built in Java, .NET, Cobol or JavaScript.
Hard to swallow, maybe, but very much true. So, what do users care about? I already gave a few hints. The GUI is the only part of the application a user actually sees and hence cares about.
“But,”, the project manager said, “building that web service was rather expensive, and making sure we used the newest and latest version of jHolyGrail took much longer than we expected… Hmm, deadline is coming up and we haven’t got much of an interface. Ah, not to worry. Why don’t we just randomly slap some UI components in our WYSIWYG editor and call it a day?”
Hopefully, this is not common practice. But it happens. I’ve seen it happening.
The last project I’ve worked on was a nice example. On first impression, it looked so much better than the one before that, which I worked on while it had already been built a few years earlier. This new project also was already under development for quite some time, so again no chance to start from scratch.
As time progressed, we came up with the bright idea to do some usability testing. Rather unsurprised, the application scored poorly. Realizing that user acceptance would be of critical importance, we set out to improve usability. Functional designers went -in some cases literally- back to the drawing board. And I was called in to aid in making the application look less like a technical-backend kind of monster, and more like a human-understandable, easy to read, pleasant to look at website.
To make this application more useable, sometimes drastic measures were needed. In fact, functionality that had cost developers blood, sweat and tears to build, sometimes ended up in the trashcan. A bitter pill to swallow, but sometimes the best option nevertheless. By reducing functionality in some places, users now for the first time found other features that were actually much more useful to them in the first place. They always had been there, just hidden too much for them to find.
From a user’s point of view, the best application is not the one with the most technologically advanced, high-tech, bleeding edge features. No. The best application for a user, is the one that does what he wants, possibly more than he wants as long as it’s not getting in his way, and does so with the least possible effort required.
End-users have high expectations these days. As people spend more and more time interacting with all kinds of machines, little annoyances can make or break an application. If you can pick from four iPhone Apps that do the same, why would you keep using the one where you have to scroll down before you can press that button you need to press most often? You wouldn’t.
So, next time you have the opportunity to build an application from the ground up, don’t fall for the pitfall of starting bottom up with the model, but grab the opportunity to build the application top down, starting at the GUI. And should you want some help, contact details are on this page somewhere… 🙂
Hi Lucas, thanks for your nice words. Of course I have to agree, to make a good application, only a great UI without any functionality is not going to please much customers. Balance is everything, but in order to make a statement to bring some balance, sometimes one has to go ‘all out’ in emphasizing the other end of the scale…
When it comes to cheaply fixable pitfalls, one can think along the lines of low-contrast fonts, increasing (negative as well as positive!) feedback after user actions.
Pay attention to overly cluttered screens. Focus is key, breaking up a screen into two, three or as many as five or six different screens will hugely increase a user’s focus and hence ease his task-at-hand.
Lastly, I’ve heard rumors that rounded corners help to take the edge off the day 😉
Best regards,
Ton
Great piece, Ton. Reality check for us technology minded folks. And also from my experience only too true. You can make users happy with things that may seem almost meaningless or certainly not high priority from the point of view of a developer. It is sometimes hard to accept that the smallest change in the UI is much more helpful to end users than some complex architecture pattern you finally mastered. Of course without the ‘invisible’ layers, the UI would just be an empty shell, like a pretty but dumb blond developer or an iceberg with nothing hiding under water. So it is a matter of balance. But you are right to stress to us-not-so-much-in-tune-with-our-end-user-day-to-day-demands-developers that in the end, to the users, UI is everything.
Do you have examples of easy to fix UI pitfalls?
kind regards,
Lucas