|
Commonality in Human-Centered Development*
1) Assess human needs. Observe key activities that the product is intended to support; use contextual inquiry (e.g., InContext Enterprises). Don't advise; observe and learn!
2) Study the market / environment. What else exists that might address a similar need? Who uses it? What are the constraints?
3) Use (1) and (2) to compile the list of performer needs, and validate the list by observations, data, and surveys.
4) Create mock-ups and samples of the product with rapid prototyping tools; use paper, drawings, etc. Get reactions from real potential performers. Iterate steps 1 - 4.
5) When you have reached the ultimate mock-up, write a manual for the product that is less than a page in lenth (big type, double spaced). If you cannot do this, then start over!
6) NOW start the design process using the manual, the physical prototypes, the mock-ups. Challenge the engineering arm of development to make a product that lives up to the manual and fits inside the prototypes.
7) Continually test and revise. All members of the design team observe, but do not talk, aid, challenge, or touch. Interpret performer difficulties as a challenge to developers, not an indictment of developers or stupidity of performers.
Questions:
A. How can a diversity model influence this process?
B. How is this process different from PCD?
*according to Don Norman
|