Unit 1: Foundations of Problem Solving and Design Thinking

I. Orientation: The foundation of effective problem solving

Problem solving is the deliberate process of understanding a situation, identifying a meaningful gap between the present and desired states, generating possible responses, and selecting or testing actions. Design thinking applies this process to human needs, especially where the problem is unclear, changing, or shaped by competing interests.

• Governing principle: A strong solution addresses the right problem, not merely the most visible symptom.
• Core assumption: Problems are often shaped by human behavior, institutional conditions, technology, resources, and context.
• Iterative convention: Understanding and solution-building develop together; later evidence may require revisiting an earlier assumption.
• Evidence standard: Claims should be connected to observations, user experiences, measurable outcomes, or clearly stated constraints.
• Balanced aim: Effective work combines desirability for people, feasibility with available capabilities, and viability within economic or organizational limits.
• Systems awareness: A local improvement can produce wider effects, such as reducing waiting time for one group while increasing workload elsewhere.

II. Design Thinking as a Structured Approach to Problem Solving

A. Introduction to Design Thinking as a structured approach to problem solving

Design thinking is a human-centered, iterative approach for investigating needs and developing, testing, and improving responses under uncertainty. It is commonly represented through empathize, define, ideate, prototype, and test, although real projects do not always follow these stages in a fixed sequence.

• Empathize: Gather insight into people’s experiences through observation, interviews, diaries, or participation. Watching a commuter navigate a ticket machine may reveal confusion that a questionnaire misses.
• Define: Convert scattered observations into a focused problem statement. “Passengers need a faster ticket” is weaker than “First-time passengers need clear guidance at the payment stage because uncertainty causes queues.”
• Ideate: Produce multiple possible responses before selecting one. Ideas may include clearer labels, an instructional screen, staff assistance, or contactless payment.
• Prototype: Build a representation that makes an idea discussable and testable. A paper interface can reveal navigation problems before software is developed.
• Test: Place the prototype in front of relevant users, observe behavior, and collect reactions. A repeated error at the same screen is evidence for redesign, not simply evidence of user failure.
• Iteration: Move backward or forward when findings demand it. Testing may show that the interface is not the central issue; the payment policy itself may need reframing.

Design thinking is structured because it provides activities and decision points, but it is not a rigid recipe. Its value lies in making assumptions visible and learning early, when changes are less costly.

• Divergent thinking: Expand the field of possibilities by asking “What might we try?” and postponing premature judgment.
• Convergent thinking: Narrow possibilities by applying criteria such as user value, safety, cost, technical feasibility, and environmental impact.
• Low-cost learning: A cardboard model or role-play can test a service sequence without investing in a complete system.
• Collaborative practice: Designers, users, engineers, managers, and domain specialists contribute different forms of knowledge.
• Success measure: A promising solution produces improved outcomes, not merely an attractive prototype or enthusiastic discussion.

III. Understanding Different Types of Problems

A. Understanding different types of problems

Recognizing the type of problem determines what kind of evidence, reasoning, and decision process is appropriate. Problems differ in clarity, predictability, human agreement, and the degree to which a solution can be verified.

• Well-defined problems: The goal, information, and allowable operations are relatively clear. Calculating the shortest route between two specified locations is more structured than improving public transport satisfaction.
• Ill-defined problems: The starting conditions, desired outcome, or evaluation criteria are uncertain. “Make the hospital experience less stressful” requires investigation before solution design.
• Tame problems: A tame problem has a stable definition and can often be solved through established methods, such as correcting a repeated software calculation error.
• Wicked problems: Wicked problems involve interacting causes, contested values, and no final solution that is universally accepted. Homelessness, climate adaptation, and urban congestion combine policy, economics, behavior, and infrastructure.
• Simple problems: Cause and effect are relatively direct; a broken switch may be repaired by replacing a known component.
• Complicated problems: Several technical elements interact, but expert analysis can usually determine relationships, as in designing a bridge.
• Complex problems: Outcomes emerge from many changing interactions. Introducing a new school attendance policy may alter student behavior, family routines, teacher workload, and reporting practices.
• Technical problems: The main challenge is often applying specialized knowledge, such as improving database response time.
• Adaptive problems: The people affected must change behaviors, relationships, or beliefs. Reducing workplace conflict cannot be achieved only by installing new software.

A problem may change category as understanding improves. A complaint about “slow service” could be a technical capacity issue, a poorly sequenced process, or a trust problem caused by unclear communication.

• Problem indicators: Repeated symptoms, conflicting stakeholder descriptions, and solutions that work briefly suggest deeper complexity.
• Boundary choice: Defining what is inside or outside the investigation influences the eventual answer; excluding staff workload may distort a study of customer waiting time.
• Stakeholder plurality: Different groups may define success differently. A manager may prioritize cost, while users prioritize dignity and reliability.
• Appropriate response: Structured problems benefit from analysis and optimization; complex problems require experimentation, dialogue, and continuous adaptation.

IV. Problem Framing

A. Problem framing

Problem framing is the deliberate construction of a useful interpretation of a situation: who is affected, what matters, under what conditions, and why the issue deserves attention. The frame guides what evidence is collected and which solutions become visible.

• Purpose: Turn a vague concern into an actionable design challenge without closing down possibilities too early.
• Situation statement: Describe observable conditions before proposing a remedy. “Residents miss collection days when schedules change” is more useful than “Residents need a mobile app.”
• User and context: Identify who experiences the issue, where, when, and during which activity. A parent may struggle with school registration specifically on a phone with limited data.
• Need versus solution: Express the need independently of a particular product. “People need confidence that their application is complete” allows a checklist, confirmation message, or staff review.
• Cause and symptom: Separate visible effects from contributing conditions. A long queue may result from slow service, repeated form correction, poor signage, or uneven staffing.
• How-might-we question: Convert the frame into an open but bounded prompt, such as “How might we help first-time applicants complete registration accurately without staff intervention?”
• Constraints: Record non-negotiable limits, including budget, law, accessibility, safety, time, infrastructure, or organizational capacity.
• Assumptions: State what is believed but not yet verified. “Users prefer digital communication” should be tested rather than treated as fact.

One framing cycle may use a simple chain:

Observed situation → affected people → underlying need → design opportunity

“Students abandon an online form” may become “Students need reassurance and clear progress information during a high-stakes application,” opening alternatives beyond merely shortening the form.

• Scope: A manageable frame identifies a specific interaction while recognizing connected system factors.
• Reframing: New evidence may shift the question from “How do we speed up checkout?” to “How do we help customers make confident purchase decisions earlier?”
• Evaluation: A good frame is specific enough to guide action, broad enough to permit alternatives, and meaningful to the people affected.

B. Human-centered thinking

Human-centered thinking places people’s goals, capabilities, experiences, values, and constraints at the center of problem understanding and solution evaluation. It does not mean satisfying every preference; it means designing with real human conditions rather than abstract assumptions.

• Empathy: Seek to understand experience without assuming that the designer’s perspective is universal. An accessibility audit may reveal that a visually small icon creates a major barrier for low-vision users.
• User perspective: Examine what people say, do, think, and feel. A user may report liking a service but repeatedly avoid it because the actual process is time-consuming.
• Contextual inquiry: Study behavior in the setting where it occurs. Observing medication preparation at home can reveal interruptions and storage conditions absent from a clinic interview.
• Participation: Treat affected people as contributors to knowledge and design, not merely as subjects who approve a finished product.
• Inclusion: Consider differences in age, language, culture, disability, income, digital access, literacy, and confidence. A digital-only service can exclude people without reliable internet access.
• Dignity and agency: Solutions should avoid unnecessary exposure, stigma, dependence, or loss of control. A discreet appointment system may be more humane than publicly identifying users who require assistance.
• Accessibility: Design for varied sensory, physical, cognitive, and technological abilities. Captions, keyboard navigation, readable contrast, and plain language are functional requirements, not decorative additions.
• Ethical care: Obtain informed participation, protect personal information, avoid harm, and distinguish genuine research from persuasion or surveillance.

Human-centered thinking combines qualitative and quantitative evidence.

• Qualitative evidence: Interviews, observations, journey maps, and open comments explain meanings, frustrations, workarounds, and motivations.
• Quantitative evidence: Completion rates, error counts, waiting times, usage frequency, and satisfaction scores show scale or change.
• Triangulation: Compare sources rather than relying on one statement. If users report ease but completion data show a high abandonment rate, investigate the difference.
• Persona use: A persona summarizes evidence about a meaningful user pattern; it should not become a fictional stereotype detached from research.
• Journey mapping: Plot stages, actions, emotions, pain points, and opportunities across an experience, such as search, application, payment, confirmation, and follow-up.

The human-centered approach is strengthened by testing with users throughout development.

• Early feedback: Ask users to interpret a paper sketch before building a polished interface.
• Behavioral evidence: Observe whether users complete a task, where they hesitate, and what assistance they seek.
• Needs over preferences: A user’s request for “more features” may conceal a need for control, speed, safety, or reassurance.
• Limitations: Users may not accurately predict future behavior, research samples may exclude marginalized groups, and empathy alone cannot resolve legal, technical, or environmental constraints.
• Responsible balance: A solution should improve human experience while remaining feasible, sustainable, safe, and fair within the wider system.