Design Process Documentation

Design process documentation is the practice of creating a comprehensive, evidence-based record of every meaningful decision, experiment, and iteration that shaped a product's development. Far from being a bureaucratic formality, good documentation serves multiple vital purposes: it makes your reasoning transparent to stakeholders and evaluators, it creates an institutional memory that helps teams avoid repeating mistakes, and it demonstrates the rigour of a human-centred design approach. A polished final interface tells you what was built; thorough process documentation tells you why it was built that way, and what was learned along the journey. The sections below address each major documentation responsibility in depth, from the earliest sparks of ideation through to the fully-realised high-fidelity prototype and the narrative thread that ties all iterations together.

Documenting Concept Generation

Concept generation is the creative engine of the design process, and documenting it well means capturing not just the outputs — the sketches, diagrams, or written descriptions of ideas — but also the process by which those ideas were produced and evaluated. Readers of your documentation should be able to understand exactly how your team moved from a problem statement to a shortlist of candidate designs.

Begin by naming and describing the ideation method your team used. Common methods include:

• Brainstorming: A time-boxed session in which participants generate as many ideas as possible without immediate criticism, deferring judgement until a separate evaluation phase.
• Crazy Eights: Each team member rapidly sketches eight distinct interface concepts in eight minutes, forcing divergent thinking by limiting reflection time.
• How Might We (HMW) prompts: Problem statements are reframed as open questions (e.g., "How might we help a new user discover core features without a tutorial?") to stimulate solution-oriented thinking.
• SCAMPER: A structured checklist (Substitute, Combine, Adapt, Modify, Put to other uses, Eliminate, Reverse) applied to existing designs to generate variants.
• Analogical design: Drawing inspiration from solutions in unrelated domains (e.g., borrowing a "progressive disclosure" pattern from complex medical forms to simplify an onboarding wizard).

Naming the method alone is not sufficient. Explain why that method was appropriate for your project's stage, team size, and problem type. For example, Crazy Eights suits early divergent exploration within a team of two to six people, whereas a structured design studio with HMW prompts may be better suited to cross-functional groups that need to build shared understanding before sketching.

Next, describe the criteria used to assess initial concepts. Evaluation criteria should be defined before assessment begins so that selection is principled rather than swayed by whoever argued most persuasively in the room. Typical criteria include:

• Feasibility: Can the concept be implemented with the available technology, time, and budget?
• Desirability: Does the concept address real user needs identified in research (e.g., interviews, surveys, contextual inquiry)?
• Usability: Does the concept align with established HCI principles such as learnability, efficiency, or error prevention?
• Novelty or differentiation: Does it offer something meaningfully better than existing solutions?
• Scope alignment: Does it fit within the defined project boundaries?

A useful documentation technique is a concept evaluation matrix, which makes the scoring of each concept against each criterion visible and auditable:

Including a table like this in your report, alongside a brief narrative interpreting the scores, demonstrates that concept selection was a deliberate, criteria-driven process rather than a matter of preference or convenience.

Documentation of concept generation must also account for the human dynamics of the process. Describe how team members contributed: who sketched, who facilitated, who critiqued. In diverse teams, individuals often bring different domain knowledge, lived experience, or technical perspectives, and those differences frequently produce more innovative concepts than homogeneous groups. Explain how divergent ideas — concepts that pulled the design in different directions — were reconciled. Common reconciliation strategies include:

• Dot voting: Each team member places a fixed number of sticky dots or votes on their preferred concepts, producing a rapid democratic ranking.
• Affinity mapping: Individual ideas are grouped by theme so that clusters of related concepts can be considered together rather than as isolated proposals.
• Weighted decision matrix: Criteria are assigned importance weights, and each concept is scored against each criterion; the weighted totals determine priority.
• Synthesis: Elements from two or more competing concepts are merged into a hybrid that captures the strengths of each.

Finally, document which concepts were selected for further development and why others were discarded. The concepts that did not advance deserve as much explanation as those that did. A concept discarded because it was technically infeasible, too similar to a competitor's product, or incongruent with user research findings tells a clear story about the team's priorities and constraints. Avoid the temptation to document only winning ideas; the rejected concepts demonstrate critical thinking and honest evaluation.

Describing Low-Fidelity Prototypes

Low-fidelity (lo-fi) prototypes are deliberately rough, inexpensive representations of a design — typically paper sketches, wireframes, or cardboard mock-ups — created to test ideas quickly before significant resources are committed. Because they are cheap and fast to produce, lo-fi prototypes encourage experimentation: it is psychologically easier to discard a pencil sketch than a polished digital interface, and this freedom is genuinely productive.

The most important rule for documenting lo-fi prototypes is: include the artefacts themselves. A written description of a hand-drawn wireframe cannot substitute for an actual photograph or scan of that wireframe. Every lo-fi prototype should be represented visually in your report — either embedded in the main body if they are central to a narrative, or collected in an appendix if the volume would interrupt the flow of reading. The relationship between artefact and text should be bidirectional: the image should be numbered and captioned, and the surrounding text should explicitly reference that number (e.g., "Figure 3 shows the initial navigation sketch discussed in this section").

Annotations are what transform raw images into documentation. An annotated lo-fi prototype might call out:

• The purpose of each region of the layout (e.g., "This left-hand panel was intended to persist across all views as a global navigation aid")
• Design choices that were deliberately left vague at this stage (e.g., "The content of these cards was not specified; the sketch was testing layout density, not content strategy")
• Elements that were known placeholders (e.g., "This box represents a search bar whose exact interaction model had not yet been decided")
• Connections between screens, indicating how a user would navigate from one state to another

Beyond the artefact itself, documentation must explain the specific design question or hypothesis each prototype was created to explore. Lo-fi prototypes are most valuable when they are targeted — each one probing a specific uncertainty rather than attempting to represent the whole design. For example:

• Prototype A explored whether a bottom navigation bar or a side drawer would feel more natural to users completing multi-step tasks on a mobile device.
• Prototype B tested whether displaying item counts on navigation tabs helped or confused users when tasks were time-sensitive.
• Prototype C examined whether a wizard-style sequential form was preferable to a single long scrolling form for users completing a complex registration process.

Framing each prototype as an answer to a design question — essentially a hypothesis test — shows that your prototyping was purposeful and intellectually disciplined, not simply "making something to look at."

Also document any informal feedback gathered during the lo-fi phase. This feedback might come from a quick hallway test, a five-minute desk critique with a colleague outside the project, or a brief walkthrough with one or two representative users. Even if no formal usability study was conducted at this stage, informal responses are data. Record:

• Who provided the feedback (a team member, a potential user, a subject-matter expert) and in what context
• What the feedback was — specific observations, confusions, or positive reactions — not just a general impression
• How the feedback influenced subsequent design decisions

For instance: "When shown Prototype B, two colleagues who fit the primary user persona both attempted to click the tab count badges, expecting them to filter results. This unintended affordance prompted us to either make the badges interactive or remove them entirely, which we addressed in the next iteration." That kind of specific, actionable documentation demonstrates genuine responsiveness to evidence.

Documenting Design Rationale

Design rationale is the explicit explanation of why a design decision was made — the reasoning that connects a design choice to the values, evidence, or principles that justified it. It is arguably the most intellectually demanding aspect of process documentation, because it requires designers to step back from what they built and articulate the logic that drove each significant choice.

A foundational rule is: every significant design decision should be accompanied by a stated rationale. "Significant" does not mean every pixel; it means any decision that meaningfully affected the user's experience, the system's architecture, or the project's scope. Decisions about navigation structure, information hierarchy, input mechanisms, feedback modalities, error handling approaches, colour and typography systems, and interaction patterns all warrant rationale. Decisions about exact padding values or specific icon choices generally do not — unless they were the subject of deliberate experimentation or user feedback.

Rationale should be grounded in one or more of the following sources of authority:

• User research findings: Decisions justified by what was learned about users in interviews, observations, surveys, or usability tests carry the strongest empirical weight. For example: "We placed the 'Save' action in the top-right corner of the form because three of five interview participants looked there instinctively when asked where they expected to save their work."
• HCI principles and guidelines: Well-established frameworks — Nielsen's ten usability heuristics, Fitts's Law, the Gestalt principles of visual grouping, WCAG accessibility guidelines, or platform-specific design systems — provide principled, peer-reviewed justifications for many common decisions. For example: "Consistent with Nielsen's heuristic of visibility of system status, we added a progress indicator to the file upload component so users always know whether their upload is pending, in progress, or complete."
• Both in combination: The strongest rationale often combines empirical and principled justifications. For example: "Consistent with the principle of recognition over recall (Molich & Nielsen, 1990), and supported by our observation that users in contextual inquiry rarely used keyboard shortcuts, we prioritised visible action buttons over a command-line interaction model."

A common failure in design documentation is describing what was designed without explaining why. Compare these two approaches:

• Insufficient: "The navigation bar is pinned to the bottom of the screen on mobile."
• Sufficient: "The navigation bar is pinned to the bottom of the screen on mobile because research by Hoober (2013) found that 49% of users hold their phone one-handed and operate it primarily with their thumb, making bottom-anchored controls significantly more reachable than top-anchored alternatives. This finding was reinforced during our lo-fi feedback session, where two participants instinctively swiped upward from the bottom of the screen when asked to navigate between sections."

The second version gives an evaluator or stakeholder everything they need to understand, and if necessary challenge, the decision. That intellectual accountability is exactly what design rationale documentation is meant to provide.

Describing High-Fidelity Prototypes

High-fidelity (hi-fi) prototypes are detailed, interactive, or near-production-quality representations of the design — typically built using tools such as Figma, Adobe XD, Axure, InVision, or even coded front-end implementations in HTML/CSS/JavaScript. They are visually polished, use real or realistic content, and simulate core interactions closely enough that users can engage with them much as they would with a finished product.

Documenting a hi-fi prototype begins with visual representation. Every key interface screen should be shown as an annotated screenshot. "Key" screens are those that represent distinct states of the interface: the landing or home view, the primary task flow, any modal dialogs or overlay panels, error states, empty states, and any screen that was the subject of a significant design decision or usability finding. Screenshots should be high resolution, cropped to remove distracting browser chrome unless that context is relevant, and presented at a size large enough to read labels and controls.

Annotations on hi-fi screenshots serve a different purpose than those on lo-fi sketches. Where lo-fi annotations explain intent and uncertainty, hi-fi annotations explain specific choices: why a particular visual hierarchy was established, why a specific component (e.g., a toggle rather than a checkbox) was used for a given interaction, why content was arranged in the order it was, or how the design handles edge cases. Annotations should be numbered and cross-referenced in the report body so that a reader can move fluidly between the screenshot and its written explanation.

One of the most analytically valuable sections of hi-fi documentation is a clear account of what changed between the lo-fi and hi-fi versions, and why. This comparison makes the design process legible. Changes might be structural (an entirely different navigation pattern), visual (a shift from a dark theme to a light one based on accessibility feedback), content-related (replacement of placeholder text with real microcopy informed by user testing), or interaction-related (changing a hover-triggered tooltip to a persistent inline label after testing showed hover was unreliable on touch devices). Each change should be linked explicitly to the evidence or reasoning that motivated it — a usability test finding, a heuristic evaluation, stakeholder feedback, or a technical constraint discovered during development.

Documentation should also describe the tools and technologies used to create the hi-fi prototype, including:

• The primary design and prototyping tool (e.g., Figma for visual design and clickable prototyping)
• Any component libraries or design systems used or referenced (e.g., Google Material Design, Apple Human Interface Guidelines, a custom design system)
• Any plugins or extensions that extended the tool's capabilities (e.g., a Figma plugin for generating realistic data)
• If the prototype was coded rather than click-through: the languages and frameworks used (e.g., HTML5, CSS with a framework such as Bootstrap or Tailwind, JavaScript with React), the development environment, and any backend or API integrations that were simulated or partially implemented
• The fidelity level of the prototype — whether it was a static click-through, a partially interactive prototype with some live components, or a fully functional front-end connected to real data

Explaining the toolchain situates the prototype in a technical and methodological context, and helps readers understand what kinds of user testing the prototype was and was not capable of supporting.

Capturing Design Evolution

Design evolution documentation is the connective tissue of the entire process report: it shows how the design changed across iterations and, critically, why it changed. Without this narrative, a reader might encounter a polished hi-fi prototype and assume it emerged from a single inspired session — which would misrepresent both the design process and the value of the team's iterative work.

The most effective way to communicate evolution is through a structured narrative or visual timeline that traces the design's progression. A timeline can be presented as a written chronology ("In the first iteration, we explored... In the second iteration, informed by feedback from... we changed..."), as a visual artefact (a horizontal or vertical timeline with thumbnail images of the design at each stage and brief annotations), or as a comparative table:

A table like this makes the relationship between evidence and action explicit and scannable. Readers can trace any specific design feature back through its history of change.

The essential discipline in capturing design evolution is to explicitly link each design change to the evidence or feedback that motivated it. This linkage is what transforms a list of changes into a demonstration of rigorous, evidence-driven practice. The connection between cause (feedback, testing finding, heuristic violation) and effect (design change) should be stated directly, not left for the reader to infer. Phrases such as "in response to," "because our usability test revealed," "following the observation that," and "to address the heuristic violation identified by" are all useful signals that you are making this causal relationship explicit.

Finally — and this is both a documentation principle and a reflection of genuine intellectual honesty — avoid presenting the design as if it emerged fully formed. A common temptation, especially when preparing a polished final report, is to narrate the process as a clean, linear journey from brief to solution. Real design work is messier: ideas are pursued and abandoned, assumptions are overturned by testing, technical constraints force rethinks, and team disagreements are resolved through compromise. Documenting this messiness — judiciously, with reflection rather than apology — is not a weakness. It is evidence that the team engaged seriously with the problem, took user feedback seriously, and treated the design as a hypothesis to be tested rather than a vision to be defended. Iteration is not a sign of failure; it is the mechanism by which design quality is achieved.

Design process documentation is the written and visual record of how an interface came to be: the ideas you generated, the sketches and low-fidelity prototypes you tested, the reasoning behind each choice, the higher-fidelity versions you built, and the way all of this changed across iterations. In practice, a design document is not a scrapbook of pretty screens — it is an argument. It shows a reader what problem you were solving, what alternatives you considered, why you kept one and discarded others, and what evidence supported that call.

This matters in CEN3722 because your course project is judged largely through what you write about it. Graders, teammates, and future maintainers cannot watch you work, so your report must make the invisible parts visible: the discarded concepts, the trade-offs, the usability findings that forced a redesign. Clear documentation of design rationale is also what separates a defensible HCI decision from a personal preference.

The three videos below come from practicing designers and from the Nielsen Norman Group. As you watch, pay attention to the artifacts each one produces at every stage — diagrams, annotated prototypes, specification notes, explanation slides — and ask how you would capture that same artifact in a section of your own report. Also notice how each speaker explains a choice to someone who was not in the room; that framing is exactly what your rationale sections need.

femke.design · 14:02 · 122,467 views · 4y ago · captions — Watch on YouTube

About this video

A working product designer walks through her end-to-end process using the Double Diamond framework, moving through discovery, problem definition, ideation, and delivery. Based on its title and description, it is a project-style walkthrough that shows how a real design effort progresses rather than a purely theoretical lecture, and it acknowledges that the process varies from project to project. Expect to see the stages where concepts are generated and narrowed, and the artifacts that result from each phase.

Why this video

It gives you a concrete, named structure (Double Diamond) for organizing the narrative of your design process section, which directly supports documenting concept generation and capturing design evolution across iterations.

NNgroup · 3:52 · 6,105 views · 3y ago · captions — Watch on YouTube

About this video

This short Nielsen Norman Group video introduces three types of prototype specifications — element, functionality, and content — as a way to document the details of a prototype. It explains what each specification type captures and why written specs are needed alongside the prototype itself, since a visual artifact alone rarely communicates intended behavior. At under four minutes it is dense and directly practical.

Why this video

NNgroup is a widely cited authority in usability, and this is the most directly on-topic piece for describing low- and high-fidelity prototypes in writing — it gives you vocabulary and categories you can use as headings in your own prototype documentation.

femke.design · 13:46 · 35,189 views · 4y ago · captions — Watch on YouTube

About this video

This video addresses what to do with a large, messy sandbox of ideas: how to organize design explorations and present them to others for feedback. Judging from the title and description, it covers selecting and grouping explorations, structuring them for an audience, and framing them so reviewers can respond productively rather than being overwhelmed by raw variations. It is aimed at the moment between generating many concepts and committing to one.

Why this video

Presenting explorations for feedback is essentially the live version of writing design rationale, so this video models how to justify and compare alternatives — the core skill behind the concept generation and design rationale subtopics.

Together these videos trace the arc your module asks you to document. The Double Diamond walkthrough supplies an overall process narrative and the record of how a design evolved from problem to solution, which feeds the iteration history required by MO1. The exploration-organization video models how to select among alternatives and explain those choices to an audience, which is the habit behind MO3's requirement to justify decisions rather than merely report them. The NNgroup video on prototype specifications supplies precise, structured conventions for describing prototypes in writing, supporting both MO1's record of design decisions and MO2's emphasis on clear, professional technical reporting. Watch them with your own project document open and note which section each idea belongs in.

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.