- Don Norman, “Cognitive Engineering”, in Donald A. Norman and Stephen W. Draper (editors), User Centered System Design: New Perspectives on Human-Computer Interaction, Lawrence Erlbaum Associates, 1986, pp. 31-61
- This article by the cognitive psychologist turned HCI guru Don Norman predated his well known book The Design of Everyday Things. What he calls “cognitive engineering” is closely related to what others call “cognitive ergonomics” – the application of research about cognition to design. See the slides from this session for the points I think are most salient and enduring in Norman’s article.
- Tim Brown, “Design Thinking”, Harvard Business Review, June 2008
- This is a good summary of the ideas behind “design thinking” as practiced and promoted by the influential palo-alto based design firm IDEO, of which Tim Brown is the CEO. Design thinking is also the predominant approach at Stanford’s d.school, whose web site contains a crash course in design thinking.
- The case study described in this article revolves around IDEO’s work with Shimano to develop the “coasting bike”. Unfortunately, the product did not sell well and was soon discontinued, so including that example makes this article seem less persuasive than it might be if the chosen example were a successful product.
- Andreas Holzinger, “Usability Engineering Methods for Software Developers”, Communications of the ACM 48(1):71-74, 2005
- Usability research is connected with evaluation, which would be a worthy topic of its own for this course in future years.
- User testing is another aspect of the relationship between cognitive psychology and HCI. While cognitive engineering/ergonomics focuses on bringing psychological principles into design, usability testing brings and augments methods of experimental psychology to the refinement and evaluation of designs.
- The proposals that the two teams came up with for redesigning Stanford’s daily class schedule were both interesting and included valuable ideas. I am planning to write up a proposal of my own that will include these ideas, and will share it with all of you when it is done. The Faculty Senate seems likely to take up the issue of the class schedule in 2013-’14. As an exercise, I feel this could be improved by asking design teams to go through an explicit process: discuss and list problems you want to address, then brainstorm solutions, then develop a single proposed design and do a pro-con chart showing how your design compares to the existing system. In a multiple teams approach, designs could then be compared on pro-con charts in relation to each other as well as the existing system, and the groups together could choose one or develop a synthesizing proposal that combines them. It would be interesting to give different instructions to the groups, e.g. one goes through a step-by-step process and another does not, to see how procedural structuring affects the proposal that each group develops.