Unit 6: Innovation Project, Re-Design and Product Presentation

INT335 — Design Thinking 11 min read

I. Orientation: Design as an Iterative Innovation Process

Design thinking is a human-centred problem-solving approach in which products and services are developed through repeated cycles of understanding users, defining needs, generating ideas, prototyping, testing, and improving. Innovation is therefore not a single creative event but a disciplined process of learning from evidence and translating insight into usable value.

  • Governing principle: A design solution should be desirable for users, feasible with available technology and resources, and viable within a sustainable delivery or business model.
  • Human-centred assumption: The person experiencing the problem is the primary source of evidence about needs, frustrations, behaviours, and context.
  • Iterative convention: A prototype is treated as a learning tool rather than a final product; failure identifies what must change.
  • Evidence-based decision-making: Re-design choices should refer to observations, interviews, usability results, measurements, or clearly recorded stakeholder feedback.
  • Communication requirement: A successful innovation must be explained through a clear problem, a credible solution, evidence of value, and a realistic implementation pathway.
  • Project outcome: The final presentation should demonstrate both the product and the reasoning that produced it.

II. Design Iteration and Product Re-Design

Design iteration is the repeated improvement of a concept through cycles of making, testing, evaluating, and modifying. Product re-design applies this process to an existing product whose performance, accessibility, cost, appearance, sustainability, or user experience can be improved.

A. Design Iteration and Product Re-Design

The purpose of iteration is to convert assumptions into tested knowledge and progressively increase the product’s value.

  • Iteration cycle: A practical loop is research -> define -> ideate -> prototype -> test -> learn -> revise.
  • Prototype function: A paper interface, foam model, CAD rendering, or clickable wireframe makes an assumption visible before expensive production.
  • Re-design trigger: Change is justified by evidence such as repeated user error, excessive production cost, poor durability, or unmet user needs.
  • Scope of change: Re-design may be incremental, such as changing a handle angle, or substantial, such as replacing a physical control panel with a mobile interface.
  • Success measure: Improvement should be compared with a baseline, for example reducing task time from 90 seconds to 60 seconds or lowering material waste by 20%.
  • Learning record: Each iteration should document the design decision, evidence considered, change made, and result observed.

B. Principles of Design Iteration

The principles of design iteration provide rules for producing meaningful improvement rather than uncontrolled variation.

  • Start with a testable assumption: Instead of “users will like this,” state “first-time users can complete checkout in under two minutes.”
  • Change one important variable: Altering navigation, colour, and wording simultaneously makes it difficult to identify which change caused the result.
  • Prototype at the right fidelity: Use a sketch for layout questions, an interactive prototype for navigation, and a functional model for performance or safety.
  • Prioritise high-risk assumptions: Test uncertain claims about user behaviour, technical feasibility, and cost before polishing low-risk visual details.
  • Use measurable criteria: Evaluate usability, reliability, safety, accessibility, environmental impact, and manufacturability using observable indicators.
  • Preserve traceability: A version label such as Prototype 2.1 should connect test findings to specific changes.

III. User Feedback and Design Improvement

User feedback is evidence gathered from people who use, encounter, purchase, maintain, or are affected by a product. It becomes useful when analysed systematically and converted into design requirements.

A. User Feedback Analysis

User feedback analysis identifies patterns behind comments, behaviours, and failures rather than treating every opinion as equally actionable.

  • Collect multiple forms of evidence: Combine interviews, observation, task completion rates, surveys, support requests, and usability testing.
  • Separate observation from interpretation: “Five of six users tapped the logo expecting a home button” is stronger evidence than “the interface feels confusing.”
  • Code recurring themes: Group statements under labels such as navigation, comfort, accessibility, trust, speed, or maintenance.
  • Distinguish severity: A safety failure or inability to complete a core task ranks above a preference for a different colour.
  • Identify user segments: A solution suitable for an experienced technician may be unsuitable for a child, older adult, or user with limited mobility.
  • Translate findings into requirements: “Users struggle to read the display outdoors” becomes “text must remain legible in direct light with sufficient contrast.”
  • Avoid popularity bias: The loudest comment is not necessarily the most representative; repeated behaviour and task failure often provide stronger evidence.

B. Design Refactoring and Re-Design

Design refactoring is the deliberate restructuring of a design to improve clarity, efficiency, maintainability, or usability without losing its essential purpose.

  • Remove unnecessary complexity: If a three-step setup produces the same outcome as a seven-step setup, eliminate redundant controls or instructions.
  • Improve structure: In a digital product, group related functions; in a physical product, separate controls, surfaces, and serviceable components logically.
  • Preserve core value: Re-designing a bicycle for lighter weight must not remove stability or safe braking.
  • Use modular thinking: Replaceable parts, reusable interface components, and standard fasteners reduce future redesign cost.
  • Check unintended effects: A smaller package may reduce shipping volume but increase grip difficulty or damage risk.
  • Validate the revised system: Refactoring is complete only when the revised design is tested against the original problem and relevant constraints.

IV. Strategic Change in Innovation Projects

Innovation projects operate under uncertainty. Teams must decide when to improve the current direction and when to change the target user, problem definition, technology, or delivery model.

A. Strategic Pivoting and Continuous Improvement

Strategic pivoting is a significant change in direction based on evidence, while continuous improvement consists of smaller, ongoing enhancements to an accepted direction.

  • Pivot condition: Pivot when evidence repeatedly disproves a central assumption, such as users valuing a different outcome from the one originally targeted.
  • Pivot dimensions: A team may change the customer segment, problem, product feature, revenue model, channel, or technical approach.
  • Preserve learning: A pivot should retain validated knowledge, such as a confirmed user need, rather than restarting without evidence.
  • Continuous improvement: Small changes such as clearer labels, faster loading, stronger packaging, or simplified maintenance accumulate over time.
  • Decision threshold: Use criteria such as adoption, task success, cost, retention, safety, and environmental impact to determine whether to persevere or pivot.
  • Example: If commuters ignore a smart bicycle theft app but campus security departments request it, the project may pivot from direct consumer use to an institutional service.
  • Governance: Record the reason for a pivot, expected benefit, new risks, resources required, and measures that will show whether the new direction works.

V. Product Presentation and Design Communication

Product presentation communicates what has been designed, why it matters, how it works, and what evidence supports it. Design communication must serve audiences with different technical knowledge, priorities, and decision-making authority.

A. Product Presentation and Design Communication

A strong presentation connects the user problem to the design response through an understandable visual and verbal narrative.

  • Narrative sequence: Present the problem, target user, insight, concept, prototype, evidence, refinement, feasibility, and next step.
  • Audience adaptation: Executives need value and risk, engineers need specifications and constraints, and users need relevance, clarity, and ease of use.
  • Visual evidence: Use annotated prototypes, user-journey diagrams, before-and-after comparisons, test charts, and labelled system diagrams.
  • Design rationale: Explain decisions concretely, such as “the emergency control was enlarged after four of five test users missed it.”
  • Technical accuracy: Identify materials, dimensions, components, software functions, manufacturing processes, or performance limits where relevant.
  • Information hierarchy: One slide or display should communicate one primary idea; supporting details should not overpower the main conclusion.
  • Integrity of claims: Distinguish tested results from forecasts, goals, and assumptions.

B. High-Impact Product Presentation

A high-impact presentation creates rapid understanding while demonstrating that the proposed product is useful, credible, and ready for the next stage.

  • Opening impact: Begin with a concrete user situation, statistic, image, or short demonstration that reveals the problem immediately.
  • Show the product: A working prototype, video, model, or interactive screen provides stronger evidence than a description alone.
  • Make value explicit: State the improvement in user terms, such as “cuts medication setup from five actions to two.”
  • Use disciplined visuals: Maintain readable typography, consistent labels, limited text, and high-quality images of the actual design.
  • Demonstrate evidence: Include sample size, test condition, baseline, result, and limitation rather than presenting unsupported percentages.
  • Handle objections: Address cost, safety, privacy, durability, accessibility, manufacturing, and adoption barriers directly.
  • Close with a decision: End by requesting a pilot, additional testing budget, manufacturing review, partnership, or approval for the next milestone.

VI. NABC Model

The NABC model is a concise framework for communicating innovation: Need, Approach, Benefits per costs, and Competition. It helps a team explain both user value and strategic credibility.

A. NABC Model

The model structures a proposal around the reason for change, the proposed response, its measurable value, and available alternatives.

  • Need: Define who experiences the problem, in what context, and with what consequence. A need is stronger than a general desire because it identifies a real gap.
  • Approach: Explain the product mechanism, key features, technology, and user interaction that address the need.
  • Benefits per costs: Compare measurable benefits with financial, environmental, technical, training, or adoption costs.
  • Competition: Include direct competitors, substitute behaviours, existing internal processes, and the option of doing nothing.
  • Evidence link: Every NABC element should connect to proof: interviews for need, prototype demonstrations for approach, testing for benefits, and market research for competition.
  • Compact structure:
TEXT
Need -> Approach -> Benefits / Costs -> Competition
  • Example: A reusable food container may meet the need for lower takeaway waste, use a collapsible sealed design, reduce single-use packaging at an acceptable unit cost, and compete with disposable containers and existing reusable products.

VII. Elevator Pitching and Product Communication

An elevator pitch is a brief, audience-focused explanation designed to create interest and secure a next conversation. It compresses the logic of a design project without eliminating its essential evidence.

A. Elevator Pitching and Product Communication

Effective product communication presents a specific user problem, distinctive solution, and credible outcome within a short time.

  • Opening problem: Name the target user and difficulty: “Small clinic patients often miss dosage instructions after leaving an appointment.”
  • Solution statement: Explain what the product does and how it changes the experience.
  • Distinctive value: Identify the feature or insight that makes the approach different from ordinary alternatives.
  • Evidence: Include one strong result, such as “in a ten-person usability test, task completion improved from 60% to 90%.”
  • Feasibility: Briefly mention the technology, materials, partnership, or implementation pathway that makes the proposal realistic.
  • Clear request: Ask for a specific next step, such as a pilot site, technical review, or investment decision.
  • Communication discipline: Avoid unexplained jargon, feature lists, exaggerated claims, and vague statements such as “revolutionary” or “everyone needs this.”

VIII. Technical Design Case Study and Final Project Presentation

A technical design case study demonstrates the complete movement from a defined problem to a tested and communicated solution. The final project presentation should make the design process auditable and the proposed next step actionable.

A. Technical Design Case Study

A case study analyses the constraints, decisions, experiments, and outcomes of a particular innovation project.

  • Context: Define the user, environment, task, and original limitation, such as a public water station used by children and wheelchair users.
  • Requirements: State functional, safety, accessibility, material, cost, environmental, and regulatory requirements.
  • Development path: Show how sketches, prototypes, tests, failures, and revisions led to the current design.
  • Technical evidence: Include dimensions, material selection, interface states, load tests, energy use, software architecture, or manufacturing details as appropriate.
  • Trade-offs: Explain a decision such as choosing aluminium for low mass despite higher material cost than steel.
  • Validation: Report test method, participants or sample size, conditions, results, and remaining limitations.
  • Transferable learning: Identify which design principle, research finding, or technical method can guide future projects.

B. Final Project Presentation

The final presentation is the formal synthesis of the project’s research, design reasoning, evidence, and proposed implementation.

  • Recommended sequence: Problem and users; research insight; design criteria; concept alternatives; selected approach; prototype demonstration; test evidence; re-design decisions; feasibility; next steps.
  • Team roles: Assign presentation, demonstration, technical explanation, and question-handling responsibilities so the delivery remains coordinated.
  • Demonstration control: Prepare a recorded backup, charged equipment, labelled prototype parts, and a recovery explanation if the live model fails.
  • Evidence boundaries: State what has been proven, what remains experimental, and what requires a larger trial or specialist approval.
  • Professional visuals: Use consistent terminology, readable diagrams, captions, sources for supplied data, and photographs that show the product clearly.
  • Final decision point: Conclude with the project’s present readiness level and the precise action required to move from prototype to pilot, production, or further research.
  • Evaluation focus: A successful presentation is judged not only by appearance but by clarity of need, quality of iteration, strength of evidence, technical plausibility, user value, and communication of next steps.