Human Factors of Computer Interface Design

We just finished up the first big part of the User-Centered Design process, user research.

We moved from learning about planning and conducting user research to analyzing data into the form of personas and then using scenarios to derive specific design requirements. The course is designed so that you apply these concepts in upcoming assignments. So, the user research project that you will conduct is meant for you to implement these same steps. As you can begin to see, doing the work raises issues that are not as straightforward as they seem when we read about them.

We used the quotes in the slides below to provide integration and meaning to what we have done so far and what we are doing in this class:

Should you need a more linear, defined outline of the steps in the UCD process, please go through the slides I use for my undergraduate class:

The main points to remember so far are, that if you want to build GOOD, useful, and successful computer products:

1. You need to put the users first.
2. You need to understand very well actual users – talk to actual people. Avoid the trap of self-referential design where you design for yourself!
3. Creating ideas for what the product should do comes from a deep understanding of actual users, and happens only after you have a good understanding of actual users.
4. To understand actual users and their needs, you need to observe them, talk to them, ask them questions, and then synthesize all that information into personas.
5. Persona-based scenarios help you bridge the gap between research and design (envisioning what the product should be able to do).
6. The idea for the product emerges from the combination of user research and your own creativity. Your own creativity must remain grounded in the user research. Personas help you stay grounded.
7. How the product should work, and the programming behind it are not even issues at this time. At this time, we assume that the computer can work magic.

The idea of designing products first and programming later was revolutionary about 10 years ago. It was introduced in Alan Cooper’s book The Inmates Are Running the Asylum. These days, it is pretty much taken for granted.

I highly recommend looking at this book a bit closer. Here is an excerpt from the publisher’s summary:

Why are VCRs impossible to program? Why do car alarms make us all crazy at all the wrong times? Why do our computers reprimand us when they screw up? All of these computerized devices are wildly sophisticated and powerful, and they have proliferated our desks, our cars, our homes and our offices. So why are they still so dauntingly complicated to use?

The highly renowned Alan Cooper, “The Father of Visual Basic,” tackles this issue head-on with his new book, The Inmates are Running the Asylum, from Sams Publishing. Cooper believes that powerful and pleasurable software-based products can be created by the simple expedient of designing computer-based products first and then building them. Designing interactive software-based products is a specialty that is as demanding as the construction of these same products, Cooper says. Ironically, building computerized products isn’t difficult, they only seem so because our process for making them is out of date. To compound the problem, the costs of badly designed software are incalculable, robbing us of time, customer loyalty, competitive advantage and opportunity.

I would like to ask you:

Is this UCD (and GDD) process what you thought it would be? Does it differ from your experiences and expectations? How so, or why not?