tags:

views:

630

answers:

12
+9  Q: 

Designing a GUI

How would you, as a developer with little (or no) artistic inclination, design a GUI for an application? In particular, I'm thinking about desktop apps but anything that relates to Web apps is welcome as well. I find it extremely hard to design something that both I and potential users find pleasing. I can look up color schemes on the net, but how would I know where to place buttons/textboxes/etc.?

Update: To clarify, I don't mean what controls and such to use. Rather, are there any guidelines/hints to when I should buttons, combos, textboxes and so on? How long should they be and where would I place them on the form?

+3  A: 

Have you read http://msdn.microsoft.com/en-us/library/aa511258.aspx ?

Or read the wikipedia article: http://en.wikipedia.org/wiki/Human_interface_guidelines it contains links to some HIG

AlbertEin
+1  A: 

If you're designing for the desktop, you can find guidelines for the operating system interface, which can help.

Mark Cidade
Good answer, lots of people forgetting about this important fact.
Kev
+1  A: 

Joel Spolsky has a pretty good high level design tips:

http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html

Above that, the biggest thing is just trying something out, making mockups. Maybe initial ones on paper, but at some point just try to put together a GUI without hooking up the code behind. See what you think, try some changes, ask other people for their opinions, and just experiment. Best design technique is to get feedback from people, preferably from the target audience if possible.

Davy8
+1  A: 

It's not clear if you're talking about how to create a good dialog window or how to create a coherent look and feel for a huge application.

A pretty good reference for how do design an effective and clear UI is User Interface Design for Programmers by ... wait for it ... Joel Spolsky.

eaolson
I was going for the former, actually.
Yuval
+13  A: 

The first thing you need to do is get out of your developer-point-of-view. We tend to think in terms of forms, controls, buttons, lists, grids etc. And this tends to push us to solutions that are not always optimal for the user.

Users don't want to use our software. (except when you're programming games) They just want to get stuff done. So when desinging UI and user interactions it makes sense to start from there. Write down what a user wants to do with your software. Think about how a user would go about doing these things and what your application could do to make things easier.

Try to work with different tools than you use for programming. These make you think in UI widgets again. Start with a pencil and a piece of paper to sketch things, also try to think about the behaviour as well as the layout etc. If you've got a clear picture of what you want to build you can start thinking about how you're going to build it. That's when the widgets, buttons and pages come in.

Mendelt
Excellent response. A+++ would read again. I would also suggest that you show hand-drawn mock-ups to you users for early comments. Hand-drawn is vital - no functional or computer drawings - they make the UI look much closer to done than you want to convey.
Rob Allen
Also don't forget about design guidelines advocated/mandated by the OS vendors. These ensure that your application will behave in ways that users are already familiar and proficient in. For example the placing and order of say Ok, Cancel and Apply buttons on a dialogue.
Kev
Thanks for the suggestions. It's hard to give a complete answer. I'll make this wiki editable in the hope people can improve it. So feel free to edit.
Mendelt
+1  A: 

Heh. Read this: http://www.codinghorror.com/blog/archives/000734.html

BoltBait
LOL, that's what I was afraid of... For my personal and/or volunteer projects right now, the wife plays the art critic...
Yuval
+2  A: 

This may be helpful: best-practices-principles-for-gui-design

slashmais
A: 

Just think about who your users are from the perspective of your application. Is there one kind? More? Then for each kind of user, think about the big overarching things they want to accomplish. Present them those general choices, and then go from there into more appropriate interfaces for each task.

Finally, if you have a big set of steps, a wizard is nice because it lets you validate each step one at a time. This is obvious on a native app, but very handy on the web.

Kevin Conner
+2  A: 

On top of everything else that has been said in this page, I'd add that the less you notice a GUI, the better it is.

I mean, when the user interface isn't perceived by the user, it's because the user is getting his/her job done. Users notice the GUI when (a) it's beautiful (think Apple) or (b) it's crappy (think whatever GUI you have used that has got you frustrated).

schonarth
A: 

I have never seen GUI design as a fundamentally artistic activity. While it is true that a well designed user interface can be enhanced with artistic elements, but designing the underlying user interface is really an engineering effort. Certainly in larger projects a GUI specialist is a natural specialization, just like having build specialist, etc. But I think that it is the rare software engineer that cannot create an effective GUI - when they are given the time and resources to do so.

Most of us have learned most of what we know about building systems by recognizing goodness in existing system and then rolling up are sleeves and innovating, and by sticking to it until it works. The GUI is no exception.

Chris Noe
+4  A: 

The applications I developed get clicked thousands of times per hour, so everything comes down to efficiency. I like to think of it as a sort of currency with which you can generate lots of useful axioms:

If it saves a click, +1.

If it costs a click, -1.

If the user wastes time figuring out how it works, -1. (Most custom UI elements)

If it is fundamentally intuitive, +1. (Coverflow)

If it saves first-time users a click, +1. (Wizards)

If it costs long-term users a click, -1. (Wizards)

(Thus why you have to make sure your keyboard shortcuts and tab orders make sense.)

Etc.

Etc.

Everything gets subjectively weighted and tallied and you compromise where you have to. Ultimately, it might be a naive philosophy, but its served me fairly well. Extrapolate as you see fit.

bouvard
A: 

There are a few UI patterns presented on the UI patterns site that you may find useful

Generally if you are designing form for windows follow the various microsoft guidelines.

One principal I keep in mind is use existing patterns of behaviour (double click to execute/activate an item etc.) as people already know these.

tdyen