User-Centered Design
8/Jun 2006
Following my last post about human-computer interaction, I am going to talk a little bit about User-Centered Design which is a methodology to achieve a good human-computer interaction.
So, what is User-Centered Design…
A design method
User-Centered Design (UCD) is a design methodology that is about designing interactive technologies to meet users’ needs. We can divide it in four stages:
Understand users’ needs
Establishing requirements
Prototyping
Evaluanting designs
Its key characteristics are:
Understand users and their needs
Focus on users early in the design and evaluation.
Identify, document and agree specific usability and users experience goals
Iteration
We would like to use this methodology because using it would help us to
more likely build something useful
manage users’ expectations
Encourage ownership of the solution
Easier integration
That’s it, the user is the key in the design of any interactive product, something many vendors or software developers don’t consider quite oftenly
Understanding Users’ Needs
It is vital to understand what users would want from or would want to do with a interactive product. Many failures in this regard leads to unused, difficult or awkward products and basically come from ignoring what users of that specific artifact need and want.
To achieve this, we need to use certain Data Gathering Techniques in order to retrieve as much information as possible. So we could use a range of research methods:
Observation: Using anthropology methods to observe people and draw conclusions.
Interviews: They are good as an initial approach to what users want, but sometimes they might be unfeasible (too many people, time-consuming, etc.)
Questionnaires: A serie of questions to elicit information from the users. They are good to retrieve quantitative and cualitative data.
Focus Groups: They are group interviews, and are good to understand the users’ need from a global point of view. (ie. to get consensus)
Analysis: Extract conclusions from the aforementioned methods.
Establishing requirements
This is to deal with the typical questions: What do users want?, What do users need?… etc. As anyone who has done some software engineering, there are different requirements:
Functional Requirements: What the system should do…
Non-Functional Requirements: Especifications about the system: memory usage, network, etc.
Data: What kind of data to store, etc.
There might as well be other requirements, such as physical (noisy environment, dusty, etc…), social (sharing of files, displays, etc…) or organizational (hierarchy, communications, etc.) that may be addressed as well.
Prototyping
It is also vital to do prototyping, that is create mockups of the system or simmulations to test them. It does not need to be a final prototype, it can be done with paper in its initial stages, and, once its being defined, get a more-closer-to-the-final-product prototype. That’s why there are different kinds of prototypes that can be done:
Lo-Fi prototype: Basically made with paper, post-it notes, etc. Provides a quick and dirty look.
Mi-Fi prototype: simulated functionality. They are based on screen printouts or screen simulations.
Hi-Fi prototype: Almost like the final product, resembling it.
Evaluating Designs
There needs to be an iterative process evaluating the prototypes,
from the early stages of the project throughout the final prototypes.
This would help get the right design from the very beginning and reduce
errors or prevent from getting a final product that is unusable. Also,
it would help to extend the functionality.
We can have two different types of evaluation:
Formative Evaluation: Done throughout the process.
Summative Evaluation: Done when the process is finished
In order to evaluate, there are a variety of ways to do it, depending if its from a user’s point of view or from a group of experts’ point of view. These are:
Quick & Dirty: Informally asking users for feedback.
Usability testing: Recording typical users’ tasks in controlled settings
Field Studies: Observation in natural settings (where the interaction is taking place)
Predictive evaluation: Asking experts to apply knowledge of typical users.
**Disclaimer**: These notes are not my own creation. They are mostly based on what I have been studying and summaries I have been using. My sources include John Halloran's lecture notes and the book **[Interaction Design](http://www.amazon.com/gp/product/0471492787/sr=8-1/qid=1149523365/ref=pd_bbs_1/104-5215005-7477542)** by Rogers et al.