Unit 6: Solution Communication and Reflection

CSR102 — Design Thinking And Complex Problem Solving 9 min read

I. Orientation

Design thinking is an iterative, human-centred approach to solving complex problems by understanding needs, defining opportunities, generating ideas, developing prototypes, and testing solutions. In Unit 6, the governing principle is that a solution creates value only when it is understood, trusted, adopted, evaluated, and improved by the people affected by it.

Human-centredness: Communication begins with stakeholder needs, experiences, language, and priorities rather than with the solution alone.
Clarity: A solution should be explainable in terms of the problem, evidence, proposed response, expected value, and limitations.
Audience awareness: Different stakeholders require different levels of technical detail, evidence, emphasis, and decision-making information.
Transparency: Assumptions, uncertainties, risks, trade-offs, and unresolved issues should be made visible.
Iteration: Presentations, reports, reflection, and feedback are stages in an ongoing learning cycle, not final administrative tasks.
Evidence-based judgment: Claims should be connected to research findings, prototype results, user observations, measurements, or clearly stated assumptions.
Action orientation: Communication should make clear what decision, resource, behaviour, or next step is required.

II. Principles of effective communication of solutions to diverse stakeholders — Building shared understanding

Effective communication translates design insight into a form that different audiences can understand, evaluate, and use. It connects the solution to stakeholder concerns without distorting the evidence or hiding complexity.

A. Principles of effective communication of solutions to diverse stakeholders

This subsection explains how to communicate one solution responsibly across audiences with different roles, knowledge, and interests.

Know the stakeholder: A user may ask, “Will this make my task easier?” while a finance manager asks, “What will it cost?” and an engineer asks, “Can it operate reliably?”
- Audience mapping: Record each stakeholder’s influence, interest, prior knowledge, concerns, and preferred communication format.
Lead with relevance: State the problem and consequence before describing features; for example, “Appointment reminders reduced missed visits in testing” is more meaningful than listing notification functions.
Use plain language: Replace unexplained terminology such as “iterative validation” with “repeatedly testing the idea with users and improving it.”
Balance emotion and evidence: A user story can establish urgency, while a usability result or frequency count supports the scale of the problem.
Make the logic visible: Show the chain from need to insight, design decision, prototype evidence, expected outcome, and implementation requirement.
Respect competing interests: Present benefits, costs, risks, accessibility implications, and possible disadvantages rather than communicating only persuasive advantages.
Choose suitable media: Use diagrams for systems, demonstrations for interactions, dashboards for trends, and concise decision briefs for executives.
Check understanding: Invite stakeholders to restate the proposed change, identify concerns, or comment on whether the solution addresses the real problem.

III. Development of presentation — Structuring a persuasive and evidence-based account

The development of presentation is the deliberate construction of a spoken, visual, or interactive explanation that guides an audience from problem recognition to an informed decision.

A. Development of presentation

This subsection shows how to build a presentation whose structure supports understanding and action.

Define the objective: Decide whether the presentation seeks approval, funding, implementation support, user adoption, or critique; the objective determines the closing request.
Construct a narrative: A useful sequence is:
1. Context: Who experiences the problem and under what conditions?
2. Evidence: What research, observation, or data confirms it?
3. Insight: What underlying need or cause was identified?
4. Solution: What was designed and how does it respond?
5. Validation: What happened when users encountered the prototype?
6. Decision: What action is required next?
Show, do not only tell: A 60-second prototype demonstration can communicate an interaction more effectively than several paragraphs of description.
Design readable visuals: Use one main idea per slide, strong contrast, meaningful labels, and charts with units and time periods clearly identified.
Control cognitive load: Introduce unfamiliar concepts gradually; avoid reading dense text while simultaneously explaining a complex diagram.
Prepare for diversity: Provide captions, accessible colour choices, readable type, alternative descriptions, and translated or simplified materials where required.
Rehearse transitions: Practice timing, likely questions, technical failures, and explanations of assumptions.
End with an explicit request: For example, request a two-week pilot, access to a user group, a budget decision, or permission to revise the service workflow.

IV. Reporting — Creating an accountable record of problem solving

Reporting is the systematic recording of the problem-solving process, evidence, decisions, outcomes, and recommendations so that others can evaluate and continue the work.

A. Reporting

This subsection identifies the content and standards of a useful design report.

Executive summary: State the problem, principal finding, recommended solution, expected value, and required decision in a short opening section.
Problem definition: Specify the affected users, context, constraints, and evidence; “long queues” is weaker than “45% of observed users waited more than 20 minutes during the 12–2 p.m. period.”
Method record: Identify interviews, observations, surveys, co-design sessions, prototypes, testing conditions, sample characteristics, and dates.
Evidence presentation: Distinguish observed results from interpretation; a prototype completion rate is evidence, while “users preferred it” requires a stated measure or quotation.
Decision trail: Explain why one concept was selected and another rejected, including criteria such as desirability, feasibility, viability, accessibility, and sustainability.
Limitations: State small samples, short testing periods, untested technical assumptions, missing stakeholder groups, or possible response bias.
Recommendations: Separate immediate actions from longer-term options and identify the responsible role, resources, and success measure.
Traceability: Use headings, version dates, figure numbers, data sources, and an appendix for instruments or detailed findings so claims can be checked.
Confidentiality and ethics: Remove identifying information where necessary and report consent, privacy protections, and any material risks to participants.

V. Reflection — Turning experience into professional learning

Reflection is a disciplined examination of actions, assumptions, evidence, and outcomes in order to improve future problem solving. It is more than describing what happened; it explains why it happened and what should change.

A. Reflection

This subsection presents reflection as an analytical cycle rather than a personal opinion statement.

Describe: Record the event accurately, such as “three of five participants misunderstood the icon during the first test.”
Interpret: Examine causes, including unclear labelling, insufficient explanation, cultural assumptions, or a mismatch between the prototype and real context.
Evaluate: Compare the result with the intended outcome; if the goal was 80% task completion and testing produced 40%, the gap requires analysis.
Identify assumptions: Ask which beliefs shaped the design, such as assuming all users have smartphones, stable internet, or equal physical ability.
Recognise positionality: Consider how the team’s professional background, authority, language, or cultural perspective influenced questions and interpretations.
Connect action to consequence: Link choices to results; delaying accessibility testing may have allowed a colour-dependent interface to progress unnecessarily.
Convert insight into action: Record a specific change, such as “include screen-reader testing before the next prototype review.”
Avoid blame and hindsight bias: Focus on conditions, evidence, and learning rather than judging people solely by outcomes that were not predictable at the time.

VI. Feedback integration — Converting responses into design decisions

Feedback integration is the structured process of collecting stakeholder responses, interpreting them against evidence and project goals, and deciding what to accept, adapt, investigate, or decline.

A. Feedback integration

This subsection explains how feedback becomes useful when it is organised and connected to action.

Collect feedback systematically: Use interview prompts, observation forms, rating scales, comment fields, or a post-demonstration discussion rather than relying only on memory.
Separate types of feedback: Distinguish:
- Preference: “I like the blue screen.”
- Problem report: “I could not find the submit button.”
- Requirement: “The service must work without mobile data.”
- Suggestion: “Add a reminder message.”
Cluster recurring themes: Group comments under usability, accessibility, desirability, feasibility, cost, safety, and policy rather than treating every comment as equally independent.
Prioritise with criteria: A simple matrix can compare impact and effort; a high-impact, low-effort change may be implemented before a low-impact visual preference.
Triangulate evidence: Give greater confidence to a recurring observation supported by interview comments and task data than to one isolated opinion.
Document the response: Maintain a feedback log with the issue, source, evidence, decision, rationale, owner, and status.
Use paired decisions:
1. Integrate: Change the design when feedback reveals a verified barrier, such as repeated failure to locate a control.
2. Investigate or decline: Seek more evidence when feedback conflicts, exceeds scope, or would create a greater risk elsewhere.
Close the loop: Tell contributors what changed and why; this demonstrates respect and encourages continued participation.
Retest changes: A revision is not successful merely because it reflects feedback; it must be evaluated against the original problem and relevant success measures.

VII. Continuous learning practices for professional problem solving — Sustaining improvement

Continuous learning practices for professional problem solving maintain the capacity to learn from new evidence, changing contexts, failures, and collaboration after a project’s initial solution has been delivered.

A. Continuous learning practices for professional problem solving

This subsection explains how individuals and teams turn repeated experience into improved professional capability.

Use iterative cycles: Apply a cycle such as plan, act, observe, reflect, and revise; each cycle should produce a recorded learning point or design change.
Maintain a learning log: Capture the date, situation, assumption tested, evidence, lesson, and next action; this prevents valuable insight from disappearing after a workshop.
Conduct retrospectives: After a milestone, discuss what supported progress, what created friction, what evidence was missing, and what the team will change.
Build communities of practice: Share methods, cases, tools, and failures with colleagues from different disciplines; cross-functional discussion exposes blind spots.
Seek deliberate feedback: Ask focused questions such as “Which assumption is least supported?” rather than requesting general approval.
Develop evidence literacy: Learn to interpret sample limitations, comparison conditions, qualitative themes, measurement error, and the difference between correlation and causation.
Update professional skills: Practise facilitation, visualisation, interviewing, accessibility design, prototyping, data analysis, and ethical decision making as project needs evolve.
Use small experiments: Test a risky assumption with a low-cost pilot before committing major resources; define the expected result and stopping condition in advance.
Monitor outcomes after implementation: Track measures such as adoption rate, task time, error frequency, satisfaction, equity of access, cost, and unintended effects.
Share failure constructively: A failed prototype can reveal a false assumption; documenting it prevents repetition and makes organisational learning possible.
Protect ethical standards: Continuous improvement must not sacrifice privacy, safety, consent, inclusion, or dignity for speed or performance gains.
Transfer learning: Apply a lesson beyond the original project, such as using a successful accessible testing protocol in future digital and physical service designs.