CSR102Semester 1 • 3 CreditsSpecialization Subjects

Design Thinking And Complex Problem Solving

This course develops students' understanding and application of Design Thinking, human-centered problem solving, analytical reasoning, creative problem solving, workflow design, iterative refinement, solution communication, reflection, and feedback integration for addressing real-world challenges.

6 Units • Notes • Model Answers • MCQs
Select Course Unit (6 Units)
Active: Unit 1
Unit 1:Foundations of Problem Solving, Problem Framing & Design Thinking Mindset
18 min read•High-Yield Unit Guide

Foundations of Problem Solving, Problem Framing & Design Thinking Mindset

Unit 1 Exam Focus & Core Takeaways

Review the core definitions, standard architectures, and syntax patterns below. Pay special attention to sections highlighted with bullet points for your mid-term and end-term subjective questions.

Unit 1: Foundations of Problem Solving, Problem Framing & Design Thinking Mindset

1. Introduction: The Need for Human-Centered Problem Solving

In traditional engineering paradigms, problem solving has historically centered on technical optimization: taking a predefined problem statement, applying linear analytical procedures, and calculating a mathematically or mechanically sound solution. However, contemporary socio-technical challenges—such as sustainable urban mobility, climate adaptation, inclusive healthcare delivery, and enterprise digital transformation—are rarely straightforward or static.

Design Thinking emerged as an agile, non-linear, human-centered innovation methodology. Rather than jumping prematurely into technical solutioneering, Design Thinking reframes engineering by anchoring the entire problem-solving lifecycle in deep human empathy, collaborative ideation, rapid tangible prototyping, and continuous iterative testing.


2. Core Philosophy and Mindsets of Design Thinking

Design Thinking is not merely a sequence of steps; it is a cognitive mindset characterized by five fundamental attitudes:

[Empathy for Users] ──> [Bias Toward Action] ──> [Embracing Ambiguity] ──> [Radical Collaboration] ──> [Iterative Refinement]
  1. Human-Centered Empathy: Prioritizing the lived experiences, emotional pain points, unmet needs, and behavioral context of real human stakeholders.
  2. Bias Toward Action: Favoring tangible experimentation and experiential doing over endless theoretical debate; "thinking by building."
  3. Embracing Ambiguity and Failure: Treating failures as cheap, informative learning signals; cultivating psychological safety to iterate without fear.
  4. Radical Collaboration: Convening cross-disciplinary teams combining engineers, social scientists, designers, domain operators, and end-users.
  5. Mindfulness of Process: Consciously shifting between generative (divergent) exploration and analytical (convergent) decision-making.

3. The Five Stages of the Stanford d.school Design Thinking Framework

The d.school (Hasso Plattner Institute of Design at Stanford) articulates a five-stage non-linear model:

StageCore ObjectiveKey Activities & ArtifactsOutput / Deliverable
1. EmpathizeUnderstand users through observation, engagement, and immersive interactionIn-depth semi-structured interviews, direct field observation, "shadowing", Empathy MapsRich qualitative empathy observations, persona profiles, user journey touchpoints
2. DefineSynthesize empathy data into an actionable, user-centric problem framingPoint of View (POV) formulation, affinity clustering, "How Might We" (HMW) question generationClear, actionable POV Statement and generative HMW question set
3. IdeateGenerate a broad volume and variety of creative solutions without premature judgmentBrainstorming, Brainwriting, SCAMPER, Crazy Eights, Worst Possible IdeaLarge pool of diverse, novel solution concepts clustered by feasibility and impact
4. PrototypeTransform abstract conceptual ideas into inexpensive, tangible artifactsPaper mockups, cardboard physical models, wireframe sketches, role-playing storyboardsLow-fidelity tangible prototypes designed to test specific assumptions
5. TestSolicit genuine user feedback on prototypes in real operational contextsUser walk-throughs, usability testing, observation of behavioral friction, feedback gridsValidated hypotheses, discovered blind spots, and refined problem reframing insights
CODE
┌─────────────┐     ┌───────────┐     ┌──────────┐     ┌───────────┐     ┌──────────┐
│ 1. EMPATHIZE│ ──> │ 2. DEFINE │ ──> │ 3. IDEATE│ ──> │4.PROTOTYPE│ ──> │ 5. TEST  │
└─────────────┘     └───────────┘     └──────────┘     └───────────┘     └──────────┘
       ▲                  ▲                 ▲                │                 │
       │                  └─────────────────┴────────────────┴─────────────────┘
       └────────────────────────────────── Iterative Feedback Loops ───────────┘

[!NOTE]
The five stages are non-linear and iterative. Feedback gathered during testing frequently loops back to redefine the user's core problem, inspire entirely new ideation sessions, or reveal that initial empathy assumptions were flawed.


4. Cognitive Modalities: Divergent vs. Convergent Thinking

Effective problem-solving requires alternating systematically between two opposing cognitive modes:

Cognitive ModePrimary GoalMental PostureRules of Engagement
Divergent ThinkingCreate choices and broaden possibilitiesExpansive, playful, unconstrained, associativeDefer judgment; encourage wild ideas; go for sheer volume; build on others' ideas
Convergent ThinkingMake choices and select optimal solutionsAnalytical, evaluative, critical, decisiveApply explicit constraints; assess feasibility, viability, and desirability; prioritize systematically

The Double Diamond Model (UK Design Council)

The Double Diamond visualizes the problem-solving lifecycle through two successive expansion-contraction diamonds:

CODE
  PROBLEM SPACE (Discover & Define)              SOLUTION SPACE (Develop & Deliver)
        Diverge         Converge                      Diverge         Converge
           /\              \/                            /\              \/
          /  \            /  \                          /  \            /  \
         /    \          /    \                        /    \          /    \
        /      \        /      \                      /      \        /      \
       /        \      /        \                    /        \      /        \
  [General Issue]  [Discover]  [Define Problem]  [Develop Ideas]  [Deliver Solution]
  1. Diamond 1: Finding the Right Problem to Solve
    • Discover (Diverge): Broad qualitative exploration into the problem space without preconceived notions.
    • Define (Converge): Synthesizing findings to identify the root challenge and frame the core problem statement.
  2. Diamond 2: Finding the Right Way to Solve It
    • Develop (Diverge): Generating diverse solution architectures, prototypes, and operational models.
    • Deliver (Converge): Testing, piloting, refining, and scaling the finalized, validated solution.

5. Comprehensive Taxonomy of Problems

Not all problems are structurally equivalent. Categorizing problems accurately dictates whether linear mathematical algorithms, expert heuristics, or agile design thinking methodologies should be applied.

1. Well-Defined vs. Ill-Defined Problems

  • Well-Defined Problems: Possess clear initial states, unambiguous goal conditions, and deterministic transition rules. Objective evaluation exists to verify whether a solution is mathematically correct (e.g., solving quadratic equations, traversing a shortest-path graph, playing chess).
  • Ill-Defined Problems: Suffer from ambiguous initial states, shifting or unspecified success criteria, and incomplete operational information (e.g., designing an engaging educational curriculum, reducing smartphone addiction among teenagers).

2. Tame vs. Wicked Problems (Rittel & Webber, 1973)

Horst Rittel and Melvin Webber formulated the concept of Wicked Problems to distinguish social and systemic planning challenges from standard scientific engineering challenges:

DimensionTame ProblemsWicked Problems
FormulationDefinitive formulation can be stated mathematicallyNo definitive formulation; formulation changes as solutions are explored
Stopping RuleClear criteria indicating when the problem is solved (O(n)O(n) check)No inherent stopping rule; search terminates when resources (time, money) run out
Solution QualityEvaluated objectively as True or False (Right or Wrong)Evaluated subjectively on a spectrum of Better, Worse, or "Good Enough"
TestingSolutions can be tested without immediate irreversible real-world costEvery implemented solution is a "one-shot operation" with irreversible consequences
UniquenessReusable templates; standard classes of solutions existEssentially unique; past solutions cannot be blindly transplanted
Root CauseIdentifiable single or primary root causeEvery symptom of a wicked problem is itself a symptom of another higher-level problem
ExamplesCalculating structural load of a steel beam, compiling C codeEliminating urban homelessness, reforming national healthcare systems

3. The Cynefin Framework (Dave Snowden)

The Cynefin framework helps leaders and engineers make sense of problem complexity and adopt appropriate management practices:

CODE
           COMPLEX                       COMPLICATED
     (Domain of Emergence)            (Domain of Experts)
     Probe ─> Sense ─> Respond        Sense ─> Analyze ─> Respond
     [Emergent Practice]              [Good Practice]
     -------------------------------------------------
     Act ─> Sense ─> Respond          Sense ─> Categorize ─> Respond
     [Novel Practice]                 [Best Practice]
            CHAOTIC                          CLEAR
       (Domain of Crisis)             (Domain of Simplicity)
  1. Clear / Simple (Ordered): Cause-and-effect relationships are self-evident to everyone. Standard Operating Procedures (SOPs) apply. Action: Sense →\rightarrow Categorize →\rightarrow Respond (Best Practice).
  2. Complicated (Ordered): Cause-and-effect relationships exist but require specialized technical expertise and analytical investigation. Action: Sense →\rightarrow Analyze →\rightarrow Respond (Good Practice).
  3. Complex (Unordered): Cause-and-effect can only be deduced in retrospect; unpredictable emergent behavior dominates. Design thinking excels here. Action: Probe →\rightarrow Sense →\rightarrow Respond (Emergent Practice).
  4. Chaotic (Unordered): Immediate crisis; no discernible cause-and-effect relationship exists. Action must be taken instantly to establish stability. Action: Act →\rightarrow Sense →\rightarrow Respond (Novel Practice).

4. Technical vs. Adaptive Challenges (Heifetz & Linsky)

  • Technical Challenges: The problem is clearly understood, and adequate solutions exist within current institutional knowledge, organizational structures, or technical algorithms. Experts can solve them.
  • Adaptive Challenges: Require stakeholders themselves to change their values, priorities, habits, or behavioral paradigms. Solutions require social learning and cultural transformation rather than top-down technical fixes.

6. Problem Framing and Cognitive Reframing

The Danger of Premature Problem Definition

Albert Einstein famously noted: "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions."

In engineering, jumping immediately to solutioneering without critical examination often results in technically flawless implementations of the wrong thing.

The Classic "Slow Elevator" Paradox

Consider an office high-rise where tenants complain: "The elevator is too slow!"

  • Narrow Technical Frame: The elevator is too slow →\rightarrow Upgrade motor horsepower, reprogram acceleration curves, install faster pulleys. (Cost: $250,000, 3 months disruption).
  • Reframed Human Experience Frame: The wait is frustrating and boring →\rightarrow Install full-length mirrors next to the elevator doors, place interactive display screens, provide ambient music. (Cost: $2,500).
  • Outcome: Complaints drop to zero. The technical speed was never the root human problem; the perceived boredom of waiting was the true issue.

Problem Reframing Tools

  1. The 5 Whys Technique (Taiichi Ohno, Toyota Production System): Asking "Why?" iteratively at least five times to peel away surface-level operational symptoms and expose underlying systemic root causes.
  2. Ishikawa (Fishbone) Diagram: Systematically categorizing potential contributing factors into major buckets (People, Process, Equipment, Environment, Materials, Management).
  3. Point of View (POV) Framework:
    POV=[Specific User Description] needs [Deep Human Need] because [Surprising Emotional / Behavioral Insight]\mathbf{POV} = [\text{Specific User Description}] \textbf{ needs } [\text{Deep Human Need}] \textbf{ because } [\text{Surprising Emotional / Behavioral Insight}]
  4. "How Might We" (HMW) Questions: Translating the POV problem statement into open-ended springboards for ideation (e.g., "How might we make waiting for the elevator feel like a refreshing social pause?").

7. Cognitive Biases Impairing Engineering Problem Solving

Engineers are susceptible to subconscious psychological biases that distort problem framing:

Cognitive BiasUnderlying MechanismReal-World Engineering Failure Mode
Functional FixednessTendency to perceive an object or tool only in terms of its customary, traditional functionFailing to repurpose existing sensors or software libraries for novel diagnostic tasks
Anchoring BiasOver-relying on the first piece of information encountered when making subsequent judgmentsFixating on an initial client specification or initial cost estimate despite contradictory field data
Confirmation BiasSearching only for data that validates pre-existing hypotheses while ignoring contradicting signalsOverlooking critical test telemetry anomalies because the system performed well in laboratory runs
Sunk Cost FallacyContinuing to invest resources into a failing architecture merely because heavy investments have already been committedClinging to an unworkable monolithic codebase instead of refactoring to modular microservices
Einstellung EffectA predisposition to apply a familiar, previously successful problem-solving strategy even when simpler or better approaches existForcing a heavy relational SQL database onto a dynamic schema problem where a key-value store would excel

8. Common Practitioner Pitfalls and Best Practices

Anti-Pattern / PitfallUnderlying CauseCorrect Architectural Solution
Solution Bias (Premature Solutioning)Human urgency to reach closure leads engineers to fixate on the first plausible ideaEnforce a strict separation between Define (Problem Space) and Ideate (Solution Space).
Relying on Stated vs. Latent NeedsTaking users' literal requests at face value without uncovering unspoken, emotional realitiesConduct ethnographic observation and ask probing "Why" questions to uncover latent needs.
Building Overly Polished First PrototypesInvesting weeks building high-fidelity mockups causes attachment, making it painful to accept critiqueBuild "ugly", low-fidelity cardboard/paper prototypes in minutes to test core assumptions cheaply.
Treating Design Thinking as LinearMarching mechanically from step 1 to step 5 without circling back when testing yields surprisesEmbrace dynamic backtracking; use test results to redefine problem statements proactively.
Echo-Chamber BrainstormingAssembling homogenous engineering teams leads to groupthink and blind spotsIntentionally assemble diverse, multi-disciplinary teams with cross-functional perspectives.

9. Quick Revision & Exam Summary

The 5 d.school Stages

  1. Empathize (Understand human experience)
  2. Define (Formulate POV & HMW)
  3. Ideate (Divergent concept generation)
  4. Prototype (Low-fidelity tangible artifacts)
  5. Test (Feedback collection and refinement)

Rittel's Wicked Problem Markers

  • No definitive formulation.
  • No stopping rule.
  • Solutions are "better/worse", not "true/false".
  • One-shot operation with irreversible consequences.

Cynefin Quadrants & Responses

  • Clear: Sense →\rightarrow Categorize →\rightarrow Respond (Best Practice)
  • Complicated: Sense →\rightarrow Analyze →\rightarrow Respond (Good Practice)
  • Complex: Probe →\rightarrow Sense →\rightarrow Respond (Emergent Practice)
  • Chaotic: Act →\rightarrow Sense →\rightarrow Respond (Novel Practice)