Can software developers build usable GUI’s?
By: Vincent Hartsteen, 17 April 2009
Most developers would answer this question the same way that Bob the Builder would when asked if he can fix it. “Yes I can” would be the reply. And I’m sure that Bob can. Why? Because Bob does his building based on a blueprint that tells him exactly what to build and what to use for building it.
In construction the architect is responsible for producing the blueprint. The architect talks to the customer in order to get a list of requirements for the building. For instance is the building used as an office-space or is it used as a family-home. Should it be a single or multi story building and how many rooms should it have. And of course the amount of money the customer is willing to spend. Geared with the list of requirements the architect uses his design skills and his technical knowledge to make a first sketch of the building. The architect discusses this sketch with his team of electrical, mechanical and structural engineers to find out if it feasible from a technical point-of-view. For instance is the construction mechanically strong enough, are the selected materials useable, etcetera. This should all result in a blueprint for a building that meets the customer’s requirements, is usable with respect to the needs of the customer and is aesthetically pleasing. Finally the constructionworkers take the blueprint and start building the construction.
In software development some similar process takes place. In short the information analist and the customer discuss about the requirements for the system. What functionality should the system offer, what is the expected load etcetera. The information analist works in close cooperation with the software architect. The software architect is responsible for making the technical decisions (which frameworks to use, what platform, how many nodes, etc.) such that the non-functional requirements (scalability, extensibility, manageability, etc.) can be met. The UML-artifacts created by the information analist and the software architect (e.g. use-case model, software architecture document, use-case realizations, etc.) are input for the developers.
One major difference between the blueprint for the construction workers and the UML-artifacts for the developers is that the blueprint has usability embedded. The architect has knowledge about how to make a construction usable to its users. When there is a requirement that a house must have 2 bathrooms the architect knows that to make them usable he could place one on the groundfloor and the other on the first floor. He could have fulfilled the requirement by putting both bathrooms on the attic but that would not have made them very useable. Very often a developers gets a requirement which basically comes down to: “the application must have a web-interface or a GUI and it should be user-friendly”. That’s it. So now it is up to the developers to figure out what “user-friendly” is.
Most developers have a technical mindset and find it hard to step into the role of the end-user. It is the end-user that decides if the application is user-friendly. He does so when the application supports the end-user to do his job without problems. So in order to design a user-friendly interface it must be clear what the application is used for and how it is used. Very often user-friendlyness is misconceived as “protect the end-user from making mistakes”. If end-users use the application every now and then to do some work it can be valid to pop-up a confirmation dialog. Expert users that use the application on a regular basis get annoyed by such dialogs.
There are currently lots of tools/frameworks that allow developers to build goodlooking user-interfaces: JavaFX, Flex, SAF, JSF, Wicket, and the list goes on. But goodlooking is not the same as user-friendly. With the tooling mentioned before we could build a very nice 3D, animated, gradient color dialog box that is very annoying (remember the Office paperclip?). So basically we have the tools to create cool and goodlooking user-interfaces but most of us lack the knowledge of how to build usable ones.
My point is that there should be a role in the softwaredevelopment team, just like a information analist or a software architect, that is responsible for designing the interaction with the end-user. Just like the architect in construction. I haven’t come across a person with such a role in the many projects I’ve worked on over the past years. Until that time it is up to us developers to design user-interfaces and for that we need to broaden our horizon and try to place ourselves on the end-user seat.
A few years ago I read “About Face. The Essentials of User Interface Design” (first edition) written by Alan Cooper which got me interested on this subject (3rd edition is the most recent version). The book describes the problems that occur when developers start designing user-interfaces and give advice on how to improve on that, all illustrated with entertaining examples. If you get into the situation where you as a developer are responsible for the design of the user-interface this book might help you do a better job.
Vincent Hartsteen
N.B.: Currently I’m reading “The Inmates are running the Asylum”, also by Alan Cooper. This book describes the role of “interaction designers”. I’ll write my findings when I’ve finished the book.
19 April 2009 om 11:09 am
I understand your point, but I don’t completely agree. Three things:
1 On my current project (ebanking project), we have a project team of about 20 people. About 10-12 of them are developers. We have 3 information analysts, 2 interaction designers and a visual designer. What I see with the graphics guys (interaction design + visual design) is that they are very Facebook/Hyves/Twitter oriented. They introduce things that may look good on a social networking site, but are useless when building a secure banking site. They don’t understand (I think) the difference between playing around on the net and doing serious financial business. It’s often the developers (with knowledge about backend systems and things like Interpay) who need to tell them that they are wrong.
2 Another thing is that developers are usually very capable of abstracting and modelling things into consistent structures. Consistency is also a good practice when designing UI’s, because you want the user to directly understand what a UI component is doing. For example, you want to make it very clear to the user that some actions trigger the commit of a transaction. They can do everything they want when “playing”, but when it comes to the final “submit/commit/save”, they must be sure they’ve entered correct data.
3 Developers are hard core internet users who usually understand the do’s and don’ts of web development. They understand the concepts of links/forms/back buttons/HTML elements/AJAX/state/security/performance, etc. and can thus oversee the whole picture when an interaction designer introduces some fancy thing.
Sure, I’m aware that developers are usually lazy and thus do everything to prevent fancy stuff to enter the realm of requirements, but I don’t agree with any statement that developers don’t have a valid vision on UI design.
Just my two cents…
22 April 2009 om 10:40 am
Jan-Kees,
Of course I’m talking in general. For sure there are software developers that can step into the mind of the end-user and are therefore able to build useable interfaces. But I think the majority is not quite aware what to focus on.
Interaction designers should have, just like the developers on your team, knowledge of the business domain they are working in. In addition to that they must understand how end-users interact/observe the system in order to design a highly useable interface. They shouldn’t just copy what’s currently hot. So when they don’t know the domain and are just copying the hypes then they are probably as bad or even worse then when sofware developers design interfaces.
In my opinion your other points are the exact reason why developers are not the best interface designers. From a developers point of view we see a lot of technology related issues like transactions, commits, HTML elements, AJAX, forms etc. etc. This is the implementation model of the application. Developers should be good at this kind of modelling.
End-users however have a different view on an application. End-users do not know (and should not know/care/bother) about the internals of the application. They have a so-called mental-model. This mental-model makes them comfortable enough to work with the application.
You can compare this with how you think what happens when you use your cell-phone to call someone that happens to be on vacation in Italy. Your mental model just tells you that you push a number, the telephony switch receives those digits and makes a connection to the other phone. This is comfortable enough to use it. You don’t have to know that there is HLR and a VLR involved and that the person you’re calling has a temporary directory number assigned on the Italian switch. All this is handled by the network and the developers that wrote the software for the switch took care of that. The gap between the mental-model and the implementation model is bridged by those developers. All you, as the end-user of the system, need to know are is the phone number of the person you’re calling which makes the system easy to use.
The same goes for UI design. We, developers, know the implementation model. The interaction designers should focus on the mental-model of the end-user and create a UI that matches that mental-model. It is the end-user that uses the system and the system must support the task the end-user is executing. There can be quite a mismatch between the mental-model and the implementation model. It is our job to close that gap with all creativity and technology we have to our disposal.
And as long as there are no (good) interaction designers available we should be aware of the end-users mental-model and that there might be a big mismatch with the implementation model.
Grt,
Vincent Hartsteen