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

I. Orientation — Innovation as an Iterative and Communicable Process

Design thinking treats innovation as a cycle in which teams understand users, frame problems, generate ideas, build prototypes, test assumptions, and revise solutions. A project is successful not merely when it produces an artifact, but when it creates demonstrable user value and communicates that value convincingly.

• Human-centred foundation: Decisions are anchored in observed user needs, behaviours, constraints, and contexts rather than designers’ assumptions.
• Iterative development: Prototypes are repeatedly built, tested, evaluated, and modified; early versions are learning tools rather than finished products.
• Desirability, feasibility, and viability:
  • Desirability asks whether users need and value the solution.
  • Feasibility asks whether available technology, skills, and resources can deliver it.
  • Viability asks whether the solution can be sustained financially and operationally.
• Evidence-based decisions: Interview findings, usability observations, performance measurements, and market data support design choices.
• Learning through failure: A failed prototype is useful when it exposes an incorrect assumption before large-scale investment.
• Clear communication: Presentations, demonstrations, diagrams, prototypes, and pitches translate design reasoning into forms stakeholders can understand.
• Ethical responsibility: Inclusive access, privacy, safety, sustainability, and unintended consequences must be considered throughout development.

II. Iterative Development and Re-Design — Improving the Solution Through Evidence

Iteration converts testing results into purposeful modifications, while re-design makes broader changes when the existing solution no longer satisfies user or project requirements.

A. Design Iteration and Product Re-Design

Design iteration is the repeated process of creating, testing, learning, and modifying a product until it meets defined success criteria.

• Iteration cycle: Each cycle should answer a specific question, such as whether users can locate an emergency button within five seconds.

Define assumption → Build prototype → Test with users
→ Record evidence → Identify insight → Modify design → Retest

• Prototype progression:
  • Low fidelity: Paper sketches or cardboard models test layout and concept.
  • Medium fidelity: Clickable screens or functional mock-ups test interactions.
  • High fidelity: Near-final products test performance, appearance, and integration.
• Incremental iteration: Small changes improve an existing concept—for example, enlarging a mobile application’s “Pay” button from 32 px to 48 px.
• Product re-design: Significant changes alter structure, workflow, technology, or form—for example, replacing a text-heavy interface with voice-guided navigation.
• Success criteria: Measures may include task-completion rate, error count, manufacturing cost, response time, durability, or user satisfaction.
• Iteration record: A design log should connect each version to evidence: “Version 3 moved the sensor because 6 of 8 users covered it while gripping the device.”

B. Principles of Design Iteration

Effective iteration follows disciplined principles so that repeated activity produces learning rather than uncontrolled change.

• Test assumptions early: The riskiest belief—such as “older adults can read the display”—should be tested before detailed engineering.
• Change one major variable when possible: Altering only button position allows the team to connect a performance change to that variable.
• Use explicit criteria: A target such as “90% of users complete registration without assistance” is clearer than “easy to use.”
• Prefer rapid, economical experiments: A paper interface can invalidate a workflow before software development begins.
• Maintain traceability: Requirements, feedback, modifications, and test results should be linked in a version history.
• Balance convergence and divergence:
  1. Divergence generates alternative forms, features, and mechanisms.
  2. Convergence selects an option using evidence and constraints.
• Avoid premature perfection: Visual polish can conceal a weak value proposition and make teams reluctant to discard flawed ideas.
• Stop deliberately: Iteration should pause when critical requirements are met and further improvement costs more than the value it creates.

C. User Feedback Analysis

User feedback analysis transforms comments and observed behaviour into reliable design priorities.

• Feedback sources: Interviews reveal explanations, observations reveal actual behaviour, analytics reveal patterns, and usability tests expose task-level difficulties.
• Behaviour versus opinion: “I like this menu” is subjective, whereas three wrong selections during checkout provide observable evidence.
• Coding process: Comments are grouped into themes such as accessibility, trust, navigation, speed, comfort, or price.
• Frequency and severity: A frequent cosmetic complaint may be less urgent than one rare safety failure.
• Prioritisation score: Teams may use a simple weighted model:

P = F × S × C

• (P) = priority score.
• (F) = frequency rating, such as 1–5.
• (S) = severity rating, such as 1–5.
• (C) = confidence in the evidence, expressed from 0 to 1.
  • Worked example: If a navigation error has (F=4), (S=5), and (C=0.8), then (P=16); it should normally outrank a colour preference scoring (2×1×0.8=1.6).
  • Bias control: Teams should use representative participants, neutral questions, consistent tasks, and disconfirming evidence rather than selecting only supportive comments.
  • Actionable insight: “Users are confused” becomes useful when reframed as “Users interpret the unlabeled icon as ‘delete,’ causing checkout abandonment.”

D. Design Refactoring and Re-Design

Design refactoring improves the internal structure or consistency of a solution without necessarily changing its core purpose.

• Interface refactoring: Standardising button colours, labels, spacing, and navigation reduces cognitive load while preserving functions.
• Technical refactoring: Modularising software, simplifying circuitry, or reducing part count improves maintainability and reliability.
• Content refactoring: Replacing technical instructions with short action-based steps improves comprehension.
• Re-design trigger: Fundamental re-design is appropriate when tests expose a wrong problem definition, inaccessible architecture, unsafe mechanism, or unsustainable cost.
• Paired distinction:
  1. Refactoring preserves the central concept but improves clarity, structure, or efficiency.
  2. Re-design changes major features, interactions, form, or value delivery.
• Constraint protection: Changes must still satisfy safety standards, dimensions, budget, compatibility, and environmental requirements.
• Regression testing: After improvement, previously successful functions must be retested; simplifying checkout must not break payment confirmation.

E. Strategic Pivoting and Continuous Improvement

Strategic pivoting changes a major project assumption, whereas continuous improvement incrementally strengthens a validated direction.

• Pivot triggers: Persistent low adoption, unaffordable production, regulatory barriers, weak willingness to pay, or discovery of a more urgent user need may justify redirection.
• Pivot forms: A team may change its user segment, problem focus, delivery channel, revenue model, enabling technology, or feature set.
• Evidence threshold: One negative interview is insufficient; a pivot should follow repeated patterns supported by tests or market evidence.
• Continuity principle: A pivot retains useful learning. A school attendance device might shift from facial recognition to QR identification while preserving the goal of rapid check-in.
• Continuous improvement: Small, recurring changes can follow the Plan–Do–Check–Act cycle: plan a modification, test it, compare results, and standardise or revise it.
• Metric control: Teams should track a small set of indicators, such as completion rate, defect rate, support requests, and unit cost.
• Pivot risk: Pivoting too frequently creates strategic drift; refusing to pivot creates escalation of commitment to a weak concept.

III. Product Presentation — Making Design Value Visible and Credible

A product presentation explains the problem, solution, evidence, operation, and impact in a structure adapted to the audience’s interests and decision criteria.

A. Product Presentation and Design Communication

Product communication makes both the proposed product and the reasoning behind it understandable.

• Audience analysis: Users prioritise usefulness, engineers feasibility, investors growth and viability, and assessors process and evidence.
• Narrative structure: A coherent sequence moves from user context to problem, insight, solution, testing evidence, impact, and next step.
• Visual communication: Journey maps show experiences, exploded diagrams show components, wireframes show interfaces, and charts show measured improvements.
• Prototype demonstration: The presenter should show a representative task rather than merely list features—for example, scan a label, receive an alert, and confirm completion.
• Evidence hierarchy: Tested performance and observed behaviour are stronger than unsupported adjectives such as “revolutionary” or “user-friendly.”
• Design rationale: Each important feature should connect to a need: “The textured dial supports users with low vision and limited dexterity.”
• Technical clarity: Architecture diagrams should label inputs, processing, outputs, power source, materials, and data flow without unnecessary jargon.

B. High-Impact Product Presentation

A high-impact presentation concentrates attention on a memorable value proposition and supports it with concise evidence.

• Opening hook: A short user story, striking observation, or quantified problem establishes relevance immediately.
• Single core message: The audience should be able to repeat what the product does, for whom, and why it is better.
• Slide discipline: One main idea per slide, readable typography, high contrast, consistent layouts, and meaningful visuals reduce distraction.
• Demonstration planning: The team should define the demo path, rehearse timing, prepare realistic sample data, and maintain a backup video or images.
• Credibility markers: Prototype test results, cost estimates, comparative performance, expert validation, and stated limitations establish trust.
• Delivery technique: Controlled pace, deliberate pauses, eye contact, clear transitions, and coordinated team roles improve comprehension.
• Closing action: The presentation should request a specific decision, such as pilot approval, technical partnership, funding, or further user access.

C. NABC Model

The NABC model structures an innovation proposal around Need, Approach, Benefits per costs, and Competition or alternatives.

• Need: Identify a specific, important user problem and support it with evidence—for example, “clinic staff lose time manually checking medicine temperatures.”
• Approach: Explain the product’s distinctive mechanism, workflow, or service model, such as a wireless sensor that logs temperature and sends threshold alerts.
• Benefits per costs: Compare measurable value with financial, behavioural, time, privacy, or implementation costs.
• Competition and alternatives: Compare the proposal with existing products, manual processes, non-consumption, and substitutes rather than claiming that no competition exists.
• Comparative statement: “Unlike handwritten checks, the sensor records readings continuously and alerts staff immediately, while requiring installation and periodic calibration.”
• Usefulness: NABC prevents feature-centred pitching by requiring the team to demonstrate an important need and relative advantage.

IV. Concise Advocacy — Communicating the Product Under Time Constraints

Short-form product communication compresses the project’s essential logic without sacrificing specificity or credibility.

A. Elevator Pitching and Product Communication

An elevator pitch is a brief spoken explanation designed to create enough interest for a longer discussion or demonstration.

• Core structure: State the target user, urgent problem, product category, key benefit, differentiator, evidence, and requested next step.
• Pitch template: “For [user] who faces [problem], [product] is a [category] that provides [benefit]. Unlike [alternative], it [difference]. Tests show [evidence]. We seek [action].”
• Concrete language: “Cuts inspection time from ten minutes to three” communicates more than “optimises operational efficiency.”
• Time control: A 30–60 second pitch normally contains one central benefit, not a complete technical specification.
• Adaptation: An engineering audience may need operating principles; an investor may need market size and scalability; a user may need convenience and trust.
• Delivery: Conversational tone, short sentences, an unrehearsed appearance, and a clear final request make the pitch persuasive without becoming exaggerated.

V. Project Integration — From Technical Evidence to Final Presentation

The final stage integrates user research, design development, engineering evidence, testing, and communication into a defensible account of the innovation.

A. Technical Design Case Study and Final Project Presentation

A technical case study documents how a product evolved and why the final design represents the strongest evidence-supported response to the problem.

• Case-study structure: Include context, stakeholders, research methods, problem statement, requirements, concepts, selection criteria, prototypes, test results, iterations, final architecture, and limitations.
• Concrete case: A smart medicine dispenser may combine a timed compartment mechanism, microcontroller, buzzer, status display, and caregiver notification.
• Requirement traceability: “Alert volume ≥70 dB at 1 m” links a user need to a measurable specification and verification test.
• Design evolution: The presentation should show rejected alternatives and explain decisions—for example, replacing a touchscreen with physical buttons after users repeatedly missed on-screen controls.
• Technical evidence: Present dimensions, materials, battery life, response time, tolerance, unit cost, test sample, and failure conditions where relevant.
• Final presentation flow: Move from need and insight to concept, operation, iteration evidence, final demonstration, impact, feasibility, limitations, and next steps.
• Team integration: Assign clear roles for opening, research, technical explanation, demonstration, business case, and closing while maintaining consistent terminology.
• Responsible claims: Separate demonstrated results from projections; a prototype tested by ten users supports preliminary usability findings, not universal effectiveness.
• Final deliverables: A coherent package may include the functioning prototype, process portfolio, technical drawings, test data, presentation slides, demonstration media, and concise pitch.