Skip to main content
Article thumbnail
Location of Repository

Facilitating the comprehension of human-computer interaction design intent within a software team

By Carl Myhill


A large proportion of today’s software development is unsuccessful. One reason for this is thought to be lack of attention to the user. Maintaining a user-centred focus during software production is regarded as a major problem. Introducing an HCI designer role into the software team (they usually function as external advisors) is thought to be a means of addressing this problem. Issues surrounding the introduction of an HCI designer role into software teams were explored by a qualitative investigation. Participant-observation studies were carried out on two year-long software projects, with the researcher performing the role of HCI designer within the software teams. Aspects of comprehension within the team were found to be fundamental to successful collaboration. Prototypes were found to be an effective means of facilitating team members' comprehension of HCI design intent, and of maintaining conceptual integrity. However, this use of prototypes was flawed because they introduced the potential for ambiguity and they were inaccessible. Focusing on the collaboration of the HCI designer and programmers, requirements for a prototype-centred explanation tool were specified to exploit the potential of prototyping to facilitate comprehension, by addressing the flaws discovered. Such a tool, called ‘ProtoTour’, was designed and implemented, based on the requirements specified. An experiment was conducted with 22 commercial programmers to ascertain whether a ProtoTour representation of an existing, commercially developed prototype, facilitated comprehension more effectively and was more accessible than a conventional prototype. Results of the experiment found that programmers using ProtoTour gained a significantly better understanding of HCI design intent, than programmers using a conventional prototype. Those using ProtoTour also asked the HCI designer significantly fewer questions about the HCI design intent. Results suggest that prototype-centred explanation tools have the potential to improve programmers’ comprehension of HCI design intent. Introducing an HCI designer into a software team was found to be an effective way of improving the user-centred focus of software during production. A prototype-centred explanation tool appears to have potential as a means of helping programmers comprehend HCI design intent

Topics: Waterfall lifecycle
Publisher: College of Aeronautics; Human Factors Technology Group
Year: 1998
OAI identifier:
Provided by: Cranfield CERES

Suggested articles


  1. (1992). All citations made in the main body of the thesis appear in this references section and are formatted in accordance with the guidelines of the Human Factors Society (Human Factors Society,
  2. (1994). A Case Study of Applying Rapid Prototyping Techniques in the Requirements Engineering Environment. doi
  3. (1986). What are the new paradigms?
  4. (1987). Methods for Designing Software to Fit Human Needs and Capabilities.
  5. (1996). Problems for User Involvement:A Human and Organisational Perspective. doi
  6. (1995). Enough About Process: What We Need Are Heroes. doi
  7. (Eds.) Readings in Human-Computer Interaction: A Multi-disciplinary Approach
  8. (1987). Case Study A - The Design of a Voice Messaging System. In
  9. (1972). Chief programmer team management of production programming. doi
  10. (1998). Satisficing in engineering design: causes, consequences and implications for design support. doi
  11. (1991). Beyond the Interface: Encountering Artifacts in Use. In
  12. (1986). An Innocent Anthropologist – Notes from a Mud Hut. doi
  13. (1991). The Contributions of Applied Cognitive Psychology to the Study of Human-Computer Interaction. doi
  14. (1981). A controlled experiment quantitatively comparing software development approaches. doi
  15. (1979). The characteristics of large systems.
  16. (1988). Implications of Current Design Practice for the use of HCI Techniques.
  17. (1990). A Framework for Assessing the Applicability of HCI Techniques in Human-Computer Interaction.
  18. (1993). Integrating Theoreticians’ and Practitioners’ Perspectives with Design Rationale. doi
  19. (1988). Taking Panes: Issues in the Design of Windowing Systems. doi
  20. (1993). Ethnographic Field Methods and Their Relation to Design. In
  21. (1993). Cooperative Design: Techniques and Experiences From the Scandinavian Scene. doi
  22. (1991). Specmaster Demonstrator Task Analysis. Unpublished SFK internal report.
  23. (1992). Object-Action Analysis. Unpublished SFK internal report.
  24. (1992). User Interface Rationale. Unpublished SFK internal report.
  25. (1992). Specmaster Seed User Interface Plan. Unpublished SFK internal report.
  26. (1981). Software Engineering Economics. doi
  27. (1988). A Spiral Model of Software Development and Enhancement. doi
  28. (1988). Software Comprehension. In doi
  29. (1983). The computer’s debt to science. doi
  30. (1975). The Mythical Man-Month (reproduced in 1995 edition cited)
  31. (1986). No silver bullet - essence and accidents of software engineering. doi
  32. (1980). Studying Programmer Behaviour Experimentally: The Problems of Proper Methodology. doi
  33. (1994). STUDIO - STructured User-interface Design for Interaction Optimisation. doi
  34. (1994). Reflections on Qualitative Data Analysis. In doi
  35. (1994). Developments in Qualitative Data Analysis: An Introduction. In doi
  36. (1994). Transfering HCI Modelling and Design Techniques to Practitioners: A Framework and Empirical Work.
  37. (1996). Analyzing the Usability of Design Rationale Notation.
  38. (1984). In The Field – An Introduction to Field Research. doi
  39. (1992). Will it sell? Hard to tell,
  40. (1994). Occasioned practices in the work of software engineers.
  41. (1993). Reusing User Interface Designs: Experiences with a Prototype Tool and High-Level Representations.
  42. (1991). Communicating Human Factors Expertise Through Design Rationales and Scenarios.
  43. (1980). Presentation and representation in design problem solving. doi
  44. (1990). Human-Computer Interaction Scenarios as a Design Representation. In doi
  45. (1991). Information Architecture and the Design Process. In
  46. (1996). A Process-Oriented Approach to Design Rationale. doi
  47. (1994). The Perils of Prototyping. Visual Basic Programmers Journal (October,
  48. (1991). A Graphic Designer’s Perspective. In
  49. (1996). The Prescribed Form for the Presentation of Theses.
  50. (1981). Substantiating Programmer Variability. doi
  51. (1986). By the way, did anyone study any real programmers?
  52. (1988). Five Paradigms in the Psychology of Programming. doi
  53. (1986). Software Psychology: The need for an Interdisciplinary Program. doi
  54. (1991). Towards a Human Factors Strategy for Information Technology Systems.
  55. (1989). Towards A Conception For An Engineering Discipline Of Human Factors. doi
  56. (1991). An Observational Study of User Interface Design Practice. doi
  57. (1991). Human Factors Contributions to the Design Process. In B. Shackel and S.J. Richardson (Eds.) Human Factors for Informatics Usability (pp.73-96).
  58. (1992). HCI, Where’s the Practice?
  59. (1988). Computer-Based Instruction. doi
  60. (1988). Work-oriented design of computer artifacts. doi
  61. (1993). Scandinavian Design: On Participation
  62. (1988). Online Aiding for Human-Computer Interaction. doi
  63. (1963). A Conceptual Framework for the Aumentation of Man’s Intellect.
  64. (1982). Integrated, Evolutionary, Office Automation Systems.
  65. (1990). Creativity and Design. In
  66. (1995). Notes on design practice: stories and prototypes as catalysts for communication.
  67. (1996). Design as Storytelling. doi
  68. (1979). When do diagrams make good computer languages? doi
  69. (1992). Supporting indirect collaborative design with intergrated knowledgebased design environments. doi
  70. (1991). Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Predictive Software Maintenace.
  71. (1994). Productivity: Is there a silver bullet?.
  72. (1997). Protocol Analysis: Theoretical Background. In

To submit an update or takedown request for this paper, please submit an Update/Correction/Removal Request.