What should a developer know about interface desig

问题:

Possible Duplicate:
Human factors design (meeting psychological needs in UI design)

What should a developer know about user interface design, usability and less technical aspects of human computer interaction?

What knowledge of usage scenarios, user behavior patterns and the psychology of user to computer interaction should we embrace to design effective software that helps users solve their problems in a natural and uncomplicated way without building barriers and creating obstacles?

There is much more to design of software than building the architecture, implementing the requirements and creating a nice-looking interface. A beautiful interface may not necessarily be useful and effective, and vice versa, an ugly software utility can become a favorite tool for many users. What at least basic knowledge should a decent developer or designer have to smooth the user experience?

Please focus on one issue per answer, describe a problem, bring examples, how the user experience is impaired and what are the ways to address the situation.

I will start:

PROBLEM: Interfaces with lots of controls and options immediately on one screen can be overwhelming to users. They will have to waste time looking through all of them trying to locate the one option they need. They'll also get distracted in the process, see one more feature, go there to learn about it and maybe read help to see if it can solve their problems, then another one and so on until they are completely lost.

EXAMPLE: As a good example I will cite the Microsoft Word (as well as other Office applications) of pre-2007 version. The sheer amount of menus and options has always scared me. I managed to remember where were the options I needed most often but that's it. Everything extra, I tend to google for things I need to learn where this particular feature is located in the forest of options.

SOLUTION: Hide out all extra options behind a few menus and submenus logically structured for the user to be able to locate them through the process of logical thinking. The 2007 redesign has obviously taken the problem into account by grouping the options into tabs. I found many new options I needed without googling but just by thinking where it could belong and looking there. Not that it has always worked, but the improvement can be felt.

Now, what are your ideas?

回答1:

Useful and effective interfaces are beautiful. Look at them as a UI designer, not as an art major. :-)

• Simplicity; as few choices as can accomplish the needs.
• Convention; follow patterns the users are already familiar with.
• Observation; watch the users, and smooth the places they have problems.
• Gentleness; write human-readable errors. Don't upset the users.
• Consistency; do things the same way everywhere in the application. Have one person write all of your text, or write a standard that text must meet.

回答2:

Learn to listen.

Users will tell what they want but not in the words that you're used to. Socialize, sit down, take your time and listen. Watch them work, ask questions. Bring up some ideas "How would you like...?" and listen to the replies. Don't assume that something would be better for them, ask them. Don't force them down a certain path because it's more simple to code.

回答3:

Interfaces with lots of controls and options immediately on one screen can be overwhelming to users.

GMail has this slogan "Search, don't sort". The same principle can be applied to user interfaces. As you mentioned, users are already doing this themselves by googling for features.

Now the next step is to build support for feature search right into the application. Hit a keyboard shortcut, type a few keywords, and click on the feature you want to use. The IDE Insight feature in the upcoming RAD Studio 2010 does exactly that.

回答4:

Problem: user interfaces often don't have a 1-to-1 correspondence to the domain model:

• There are communication problems because programmers talk about the hidden domain model while users talk about the GUI.
• There are maintenance problems because users are constrained by the task-based user interface. They regularly need to ask for "a new screen to do this" even if the domain model may already support it.

Solution: the naked objects architectural design pattern. To take this to the extreme you might even generate the GUI automatically from the domain model.

回答5:

I know the question is a bit old, but I'm surprised to see that no one mentioned Joel Spolsky's excellent article : User Interface Design For Programmers. It's definitely something every developer should read. There are no especially brilliant or original ideas in it, it's mostly common sense, but it did open my eyes on some not so obvious points...

回答6:

I suggest reading "The Design of Everyday Things" by Donald Norman.

回答7:

I use to think asthetics were useless until I tried to sell my house. Sturdy foundation, 3 brms, 2 baths, 2 car garage, fenced yard, blah, blah blah - until I got rid of the stink from my 3 dogs nobody would touch it.

The more visually pleasing the app/site is, the more chance it will get used. Now a user will give it a try and determine if it does anything they want. Finally, how usable is it? This is a point when you will probably get more feedback.

Just like the house: get rid of the clutter, clean everything, start with a general color pallette and let the user add the crazy colors if the want them.

回答8:

If you really want your eyes opened, take a course in Human Factors Engineering.

回答9:

I have worked at a pharmaceutical company for the past two years and I think that the design of the interface is nearly as important as the functionality. Watching users struggle with old complicated legacy code is the primary reason for re-designing it. Functionality is seldom the primary reason for redeveloping code or replacing it.

• Usability studies
• Watching people use your code
• Extreme programming (Delivering preview code intermittently throughout design process)

Are all essential to delivering code that not only meets the users needs but makes them happy and productive. At the end of the day, programs will only be used if they make you happy and productive.