HCI Design Documentation and Development Reporting — Topics & Learning Outcomes

Module Topics

Introduction to HCI Development Reporting

• Purpose of an HCI Development Report — An HCI development report provides a structured, professional account of the entire design process, communicating decisions, rationale, and outcomes to stakeholders.
• Audience and Tone — A professional HCI report is written for a technically informed audience and must maintain a formal, objective tone throughout.
• Report as a Design Artefact — The development report itself is considered a design artefact, representing the intellectual and practical work of the project team.

Requirements Documentation

• Documenting User Research — The report must describe the methods used to gather user needs, including observations, interviews, surveys, or contextual inquiry, along with key findings.
• Stating Functional and Non-Functional Requirements — Requirements must be clearly categorized as functional or non-functional and written in precise, testable language.
• Rationale for Design Constraints — Any constraints placed on the design — such as platform, accessibility standards, or scope limitations — must be explicitly stated and justified.
• Linking Requirements to Design Goals — The report should show how gathered requirements were translated into concrete design goals that guided the project.

Design Process Documentation

• Documenting Concept Generation — The report should describe early ideation activities, such as sketching, brainstorming, or design workshops, and explain how initial concepts were generated and evaluated.
• Describing Low-Fidelity Prototypes — Low-fidelity prototypes such as paper sketches or wireframes must be documented with annotated images and an explanation of what each prototype was intended to test.
• Documenting Design Rationale — Design rationale explains why specific design choices were made, grounding decisions in HCI principles, guidelines, or user research evidence.
• Describing High-Fidelity Prototypes — High-fidelity prototypes represent near-final interface designs and should be documented with annotated screenshots and a clear account of how they differ from earlier iterations.
• Capturing Design Evolution — The report should present the design process as an iterative journey, showing how early decisions were refined in response to evaluation findings and emerging insights.

Evaluation Documentation

• Documenting Evaluation Methodology — The report must specify the evaluation method used, such as usability testing, heuristic evaluation, or cognitive walkthrough, along with the rationale for selecting that method.
• Presenting Evaluation Findings — Findings from evaluation activities must be presented clearly, distinguishing between observed problems, participant feedback, and analyst interpretations.
• Linking Evaluation Findings to Design Iterations — The report must explicitly connect evaluation findings to subsequent design changes, demonstrating that evaluation informed and improved the design.
• Reflecting on Evaluation Limitations — A professional report acknowledges the limitations of its evaluation activities, such as small sample sizes, time constraints, or method choices that may affect the validity of findings.

Final Implementation Documentation

• Describing the Final Interface — The final implementation section presents the delivered interface design, using annotated screenshots or walkthroughs to describe its key features and interactions.
• Documenting Implementation Decisions — Any design decisions made specifically during the implementation phase must be documented, including choices about interaction patterns, visual design, or technical constraints.
• Documenting Deviations from the Prototype — Where the final implementation differs from the approved prototype, the report must explain the reasons for any deviations and assess their impact on usability.
• Tracing Design Decisions to Outcomes — The implementation section should close by demonstrating how the final design addresses the requirements and design goals established at the start of the project.

Group Collaboration and Contribution Documentation

• Documenting Team Roles and Responsibilities — The report should identify the roles taken by each team member and describe how responsibilities were allocated across the project phases.
• Describing Collaborative Design Processes — The report should describe how the team made collective design decisions, including any structured processes such as design critiques, team reviews, or voting methods.
• Documenting Project Management Activities — Brief documentation of project management activities such as scheduling, task tracking, and version control demonstrates professional practice.
• Reflecting on Group Process — The report should include a reflective component in which the team honestly evaluates the effectiveness of their collaborative process.

Report Structure, Referencing, and Presentation

• Standard Report Structure — An HCI development report follows a conventional academic and professional structure that includes front matter, a body organized by project phase, and supporting appendices.
• Writing Cohesive Narratives Across Sections — Each section of the report must connect logically to adjacent sections, ensuring the overall document reads as a coherent account of an integrated design process.
• Academic Referencing — All sources cited in the report, including HCI guidelines, design principles, and research methods, must be referenced using the required academic referencing style.
• Use of Visual Evidence — Figures, screenshots, diagrams, and tables must be used strategically to support written arguments and are subject to the same presentation standards as text.
• Presentation and Formatting Standards — Professional formatting — including consistent fonts, heading hierarchies, appropriate line spacing, and accurate word counts — reflects the quality of the team's work.

Student Learning Outcomes

By the end of this module, students will be able to:

Course Outcomes (reference)