4 - David Earle

Not only is the user not always correct, Hoekman goes as far as to suggest that the user is often unaware of how he/she would act, or what he/she wants. This chapter strays away from the user-centered focus of the previous two, to look at the realities and pitfalls of overly user-centric design. Hoekman highlights the time complexity of many projects which don't leave room for user-research. He also addresses problems with user reliability, and the fact that persona's can become a distraction -due to non-pertinent details- and can contribute to excluding non-represented users. After highlighting the difficulties of user-centered design, Hoekman considers the opposing philosophy of activity-centered design, which all but ignores the users. Having decided that "Where user-centered design is too broad, Activity-Centered Design is too narrow. Where UCD looks at too much of a person, ACD looks at too little" (Hoekman 47), Hoekman proposes a third solution: Situation-centered design. The idea behind this third approach is that "it isn't a type of person who uses an application, it's a person in a type of situation" (Hoekman 48), hence the situation can be seen as the unifying factor between activity, and user centered design. Taking a situational approach allows for a variety of research techniques -including situational immersion, and use case writing-, without having the designer waste time with useless user details, or get tunnel vision focusing only on the activity. At the end of the day, Hoekman seems to be promoting moderation, no matter the design philosophy that is used. Showing that all of these approaches have downsides, but that the situational approach is the most effective due to the fact that technology solves for situational problems, not activities or people.

In advocating a situation-centric approach, Hoekman suggests that the best way to improve a design is to understand the situation in which it is used. For our second project, we attempted to improve the interface of an exercise bike. To do so, we took pictures of the bike and its interface, and then proceeded to simplify its overwhelmingly cluttered panel. While I think we came up with a solid improved design, reading this chapter has made me realize that it was a mistake to simply take a few pictures and then leave the gym: the situation in which our design is used. While we used user feedback and testing to refine our design, these users were not regular gym users. Nor was any of our testing or prototyping situational. If I could do project 2 again, I would focus on studying the gym environment and the situation in which the interface occurs more closely. By shadowing users in the gym and doing more appropriate contextual inquiry within that environment, I feel that we could have gained a superior understanding of our problem space.