views:

654

answers:

10

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?

+8  A: 

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.

Aaron Digulla
A: 

One "system" that I have used and am particularly happy about is Contextual Design. It incorporates all aspects that impact how to properly design an automated system, including a flow, sequence, cultural, physical and artifact model. A good book about this technique is by its originators, Beyer and Holzblatt.

Deckard
+4  A: 

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.

Wim Coenen
+1  A: 

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

Scott Whitlock
I'm aware of that book. However I hoped to see interesting ideas directly here.
Developer Art
+2  A: 

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.

Wim Coenen
That is certainly A solution. I'm not certain it works in all cases, or even many cases.
Robert Harvey
Keep in mind that most software out there is written to keep businesses running efficiently. Do we really need to re-invent the GUI for custom order management/inventory/billing/CRM/payroll systems a million times over? And end up with this? http://stuffthathappens.com/blog/2008/03/05/simplicity/
Wim Coenen
The design pattern sounds interesting enough to investigate. But I've seen enough things come and go to know there's no silver bullet.
Robert Harvey
I have seen the cartoon that you refer to before. While it is amusing, and effectively illustrates how we can wrap ourselves around the axle with user interfaces, the truth is that we couldn't write an accounting application user interface like an iPod interface, nor would we want to. Certainly, such accounting interfaces could be much better, which is why we keep trying.
Robert Harvey
+1  A: 

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.

Jeff O
My other advice on selling a house was to hide all cleaning things, like mops and brooms. Apparently this is supposed to give the impression of a self-cleaning house.
David Thornley
Just like not including documentation or help files with an application to show how easy it is to use.
Jeff O
A: 

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

HLGEM
+1  A: 

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.

Steve
+8  A: 

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.
Dean J
A very nice summary
Steve
+2  A: 

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...

Thomas Levesque
I thought I read all articles there already but that one I missed. Thanks!
Developer Art
The question is old and I've very sorry people decided to ignore it. Only proves that programmers mostly care about programming. Sad.
Developer Art