Myths of UI Design

I recently presented a workshop on UI design in the software development world, and as part of the workshop we talked briefly about some common UI Design myths.

I thought it might be useful to iterate some of the myths again on my blog. (You can find the slides of my workshop presentation here). This is from my experience in designing and implementing user interface applications, as a software developer, not a user experience engineer or human-computer-interface expert.

Myth #1: Developers know what users want

One of my favourite comics from www.ok-cancel.com is this one:

Need I say more?

I can also heavily paraphrase Joel Spolsky (from his book "User Interface Design for Programmers") and say that we forget that:

• most users cannot read
• most users cannot use a mouse

I'm not trying to ridicule the end-user here. (I'm a end-user myself.) Joel explains the much better than me, so grab hold of his book. But what it boils down to is that we need to keep the interface as simple as possible. Users will typically not read long sentences, or even phrases, in a dialog or wizard, or wherever else you display them. A lot of users will also not even read the user manual (I never do...).

We developers are also inclined to think all users have super-duper mouse skills, honed on numerous Dota or Quake3 games, using great laser-mouses on clean desks. We forget that some computers are used in greasy factories or workshops, a lot of cheap inaccurate mouses are being sold daily and everyone does not have nifty 24" or bigger monitors.

Somehow the simplicity thing is very difficult to grasp...

Look at the numerous overly complex, distractingly busy websites out there. Look at all the feature-bloated, monstrous applications we have to struggle with. Because we as developers like to tune our operating systems and play with every setting we can find, does not mean our end-users wants all that choice and features. For them the software is just a tool to get their real work done, hopefully in as simple as possible way.

This does not mean we must make all our software so simple that it does not add value to the user. Some UIs needs to be complex to provide what the user needs, e.g. IDEs. However, these the user will get to know over time, and get to expect how it will behave.

I think the challenge is to find the simplest possible design that provides what the user expects.

Myth #2: UI Design is art, just do what you want

“Art is about freedom, Design is about constraints” is a quote that I read a while ago on a website, but I could not find the quote again. (If whoever wrote this somehow reads this post, please contact me and introduce yourself :-) ).

UI design and implementation is a very creative process for me, however, it is a process that must take a lot of constraints into consideration. One might naively think that you can let your creative side just take over and be totally free with your designs. Unfortunately you will most probably loose all your users along the way; scared away by the radically new ideas and metaphors that you so artfully brought into the software.

Life is at its core a balancing act; the same with UI design. You need to be creative, but you also need to be consistent with what the user expects.

Of course there are always some other less welcome constraints that typically influence a project. You know... lack of money, tyrannical management, looming deadlines, issues with the GUI framework that was chosen, and so forth. These all join together to kill of that spark of creativity... (or sometimes actually ignite it, like a wild animal trapped in a corner).

Myth #3: UI can be left for last

The sad truth in the software development arena is that UI design and implementation somehow gets left for the last minute in many projects out there.

The feeling I get from a lot of companies where I consult or do development is that the user interface part of a project is seen as being inferior to “Server development”. You get The System, where all the experienced developers are being used, and then there is that "little bit off to one side" where some junior code monkeys get dumped to spin out some quick check-boxes.

[Disclaimer: I do not see these guys as junior code monkeys; that is part of the feelings floating around that I observed.]

When I see this, I want to scream (in some cases I do scream): People, ARE YOU MAD! The user interface is the end-users' view of the system. It MUST be professional and conform to there (highly complex, yet simple) expectations, otherwise the whole system will be perceived as a failure. It does not matter if your database can handle 10000 transactions in a second for 100000 users connected simultaneously and compress the data such that each record takes up only 1 bit. If the user interface(s) of the system is lacking, your whole project will be a failure.

I put it very bluntly (you might say provocatively) at the UI workshop the other night: server-side coding is very easy. You design some domain objects and some business logic, and select the framework that ties everything together. There is known input and known logic to get some known output from that.

On the other hand, UI development is extremely difficult. You have two major unknowns:

1. the user (show me a predictable user)
2. the windowing system of the OS (Remember: the experienced guys has worked on the kernels, while the UI framework and windowing systems of the different OS's has been build by the new kids on the block...)

What does this mean? Put your good developers on GUI development as well.

OK, before you get too worked up, I have stated it in the extreme above. However, it seems that there is a mental block about this at a lot of companies. Not all companies, no. But a lot.

A lot of successful companies have banished this "server team" vs. "gui team" approach, and actually get their developers to work on all the layers that make up the systems.

I'm going to wrap up this post now, and hope for the same kind of debate I got at the workshop...