It's often said that engineers should not be designing user interfaces, and there's a certain wisdom to it. I've seen a lot of interfaces that were clearly designed by someone who has no real idea of what makes an interface useable, but nevertheless probably finds it entirely adequate because he knows exactly what everything does. I find myself compelled to ask: Just what is so hard about UI design?

Now, don't get me wrong. I have the utmost understanding for the fact that everyone is not good at everything, and that the more obscure details of interface design are rather arcane and hard to grasp. But I still wonder just why so many engineers are so bad at it, because really, it's not so difficult.

Stop me if this next part feels familiar to you: You've implemented some nice new functionality, and you'd like an interface for it, “just to test things”. So you make a dinky little interface that only you have to use, ever. But then the functionality grows, and you tack some more stuff onto the interface. And more, and more, and eventually you have a behemoth of an interface, but that's all right, isn't it? You're the only one who's going to use it.

Right up until the release deadline hits and the interface stays in there anyway. And in the meantime, someone else will have been using it anyway out of necessity. Or perhaps it's an open-source product and it's been on a public SVN all this time and everyone has been using it. And so, the Interface of the Beast remains in there, much to the chagrin of your customers.

If only engineers would design workable interfaces to begin with...

I won't reiterate what's been said on other blogs on the Internet, but designing an interface that is at least decent, if not amazing, is a piece of cake if you only remembering one thing: Stealing is good.

You're not the engineer in the world who has required a user interface for his program. And yours is not the only UI in the world. Look at other UIs, for other programs that are like yours, or just UIs in general, and steal everything they've done. It's all right. Really! Most modern UIs follow the same few design principles, and even if you don't understand them, you can come quite a ways just imitating what others have already done.

Here, though, is some short, practical advice that may help you in designing an interface that's not complete bollocks.

Group things according to function, divide and conquer

If two things are related functionally, they should be next to each other, and should be delinated from things that are not related. The bordered box frame (sometimes with a label on top) is a great tool here, as is the tabbed notebook frame. Use both to your advantage.

Related to the above is the importance of not cluttering your interface. If you feel your interface is growing too dense and cluttered, it's probably time to split it up into sections (this has a tendency to happen with preference dialogs, for instance). Again, the tabbed notebook widget is your friend here, but even something as simple as a line or a new box widget will help.

Line things up

I can't tell you how many times I've seen interfaces with text boxes that aren't lined up for shit. This isn't difficult, people! Lining things up makes it much easier to get an overview of what you're doing and is just plain nice.

Respect conventions and be coherent

This is where the “imitation” bit comes in again. Your host operating system probably has a lot of conventions for how things should be done (button placements or standard menus, for instance), and it's got them for a reason. Coherence is a good thing, and that means coherence across the entire platform, not just within your program.

Take a few minutes to look at what your operating system does, and do the same stuff. Menus, button labels and placement, toolbars, etc. are all things to pay attention to. Also, many UI toolkits offer functionality for standard dialogs like file open/save dialogs, message dialogs, font selection etc.—use them! Stick to the default system fonts and colors. Most importantly, don't violate the users' expectations, or you'll only confuse them.

Remember Fitts's Law

Fitts's Law is a usability law that basically states that the time it takes for a user to point and click on an element is proportional to the distance to the element and inversely proportional to the size of the element. What this means for you is that you need to make things that are oft-used big and close together to each other.

Another thing to remember here is that the edges of a computer monitor are “infinitely deep”, because you usually cannot move a pointer outside of the edge, so no matter how far you move your mouse to the right, say, you will stop at the right edge of the screen. The canonical example here is the “Close” button located at the top right of most windows. Try it now; move your mouse as far up and right as you can. Notice how you're still “on” the button? The lesson to be learned here is that the corners and edges of a screen are valuable real estate, and should be capitalized on.

Step it up

If an operation is divided into logical steps (such as an installation or other procedure), then they should probably be separate dialogs. All too often you see people trying to fit every step of a long procedure into the same dialog, and that just creates clutter and confusion. It's all right to have several dialogs.

Really, in the end, interface design is not as hard as it seems people think, at least if you are willing to settle for decent rather than excellent. A decent interface that doesn't get in the user's way and is reasonably useful is a simple task, barely requiring any thought. And always, please remember that any interface you make may end up being used more than you think. If not else, you still have to use it; don't make things more difficult for yourself than they have to be.