Unit 2: Problem Definition and Analysis

CSR102 — Design Thinking And Complex Problem Solving 10 min read

I. Orientation — From vague difficulty to design opportunity

Problem definition and analysis is the disciplined process of understanding a situation, identifying the people and systems affected, and expressing a solvable challenge before generating solutions. In design thinking, this work commonly occurs between empathizing with stakeholders and ideating possible responses. The governing principle is: solve the right problem before attempting to solve it well.

Human-centred focus: A problem is defined through the experiences, goals, and difficulties of people such as users, customers, employees, citizens, or service providers.
Systems awareness: Problems are influenced by relationships among technology, institutions, culture, economics, policies, environments, and behaviour.
Evidence before assumptions: Interviews, observations, records, measurements, and direct quotations are preferred to unsupported beliefs.
Iterative refinement: A problem definition may change when new evidence reveals an overlooked stakeholder, cause, constraint, or opportunity.
Solution neutrality: A strong problem definition describes a need or outcome, not a premature solution such as “build an app.”
Actionable boundaries: The problem must be sufficiently focused to investigate and address, while remaining broad enough to permit meaningful alternatives.

II. Stakeholder Needs and Contextual Factors — Understanding the situation

Stakeholder analysis identifies who is affected by a problem, what each party needs, and how the surrounding context shapes the problem’s causes and consequences.

A. Understanding stakeholder needs

Understanding stakeholder needs means distinguishing what people say they want from the underlying outcomes, frustrations, risks, and motivations that make those wants important.

Primary stakeholders: These directly experience the problem; for example, patients encounter appointment delays, while nurses manage the resulting workload.
Secondary stakeholders: These influence or support the system without being the main users; an insurer, hospital administrator, or software supplier may affect healthcare access.
Needs versus solutions: “I need a mobile application” may conceal the deeper need “I need reliable appointment information while travelling.”
Functional needs: These describe what must be accomplished, such as submitting a form in under five minutes or receiving an accurate status update.
Emotional and social needs: A user may need confidence, dignity, safety, or recognition; a public-service user may avoid a process that feels humiliating even when it is technically available.
Conflicting interests: Management may seek lower operating cost, whereas staff may need more time per customer; both positions belong in the analysis.
Evidence collection: Interviews reveal perceptions, observations show actual behaviour, and service records can reveal measurable patterns such as a 30% abandonment rate.

B. Contextual factors influencing problems

Contextual factors are the conditions surrounding a problem that can intensify, reduce, or change its meaning.

Physical context: Lighting, noise, distance, temperature, layout, and accessibility can alter behaviour; a self-service kiosk may work in a quiet lobby but fail in a crowded station.
Social context: Family roles, workplace hierarchies, peer expectations, and cultural norms influence who makes decisions and who feels able to speak.
Technological context: Device ownership, internet reliability, interoperability, cybersecurity, and digital literacy determine whether a proposed process is usable.
Economic context: Price, income, staffing, budgets, and opportunity costs affect feasibility; a free service may still be inaccessible if it requires unpaid travel.
Legal and ethical context: Privacy law, safety rules, consent, equality requirements, and professional duties limit acceptable actions.
Temporal context: Seasonal demand, emergencies, deadlines, and long-term trends matter; a transport problem during a festival may not represent ordinary weekday conditions.
Systemic relationships: A visible delay may result from upstream causes such as procurement rules, incompatible databases, or incentives that reward speed over quality.

III. Techniques for Problem Identification — Finding the real challenge

Problem identification uses structured inquiry to move from symptoms and complaints toward patterns, causes, and opportunities for improvement.

A. Techniques for problem identification

The purpose of these techniques is to gather evidence, test assumptions, and separate observable effects from underlying causes.

Observation and shadowing: Recording what people actually do can reveal workarounds; a worker who keeps a handwritten duplicate log may indicate that the official system is unreliable.
Semi-structured interviews: A consistent set of prompts supports comparison, while follow-up questions uncover meaning; “Tell me about the last time this happened” produces more evidence than “Is the process difficult?”
Surveys and questionnaires: These measure prevalence across a larger sample; a survey showing 68% of users abandon a form identifies scale, though not necessarily cause.
Journey mapping: A journey map records stages, actions, emotions, pain points, and channels from beginning to end, such as search, registration, payment, delivery, and support.
Affinity mapping: Similar observations are grouped into themes; repeated notes about confusing labels, missing instructions, and inconsistent terminology may form a “communication breakdown” cluster.
Five Whys: Repeatedly asking why helps explore causation. “Orders are late” may lead to “picking starts late,” then “stock information is inaccurate,” rather than stopping at the visible delay.
Fishbone analysis: Causes are organised under categories such as people, process, technology, materials, measurement, and environment, making multiple contributing factors visible.
Data and process analysis: Complaint logs, failure rates, queues, cycle time, and error counts help validate perceptions; a mean processing time of 18 minutes may conceal a critical 45-minute delay for a particular user group.
Triangulation: Confidence increases when different sources agree, such as interview reports of delays matching timestamp data and direct observation.

IV. Problem Statement Formulation — Expressing the challenge clearly

A problem statement is a concise, evidence-based description of who experiences a need, what the difficulty is, and why addressing it matters, without prescribing a specific solution.

A. Problem statement formulation

A well-formed statement converts analysis into a shared design focus that can guide research, ideation, and evaluation.

User or stakeholder: Name the relevant group specifically; “first-year commuter students” is more useful than “people.”
Need or difficulty: State the unmet need in human terms, such as needing to find affordable evening transport after laboratory sessions.
Context: Include the situation in which the need occurs, for example, “when campus buses have stopped running.”
Impact: Explain the consequence, such as missed work shifts, unsafe walking routes, or additional travel cost.
Evidence anchor: Connect the statement to findings; “seven of ten observed students used unofficial ride-sharing messages” is stronger than “students dislike transport.”
Neutral wording: Avoid embedding an answer. “How might we help…” invites alternatives, whereas “How might we create a bus-tracking app…” narrows the solution prematurely.

Useful template:

TEXT

  [Stakeholder] needs a way to [desired outcome] because [evidence-based difficulty and consequence] in [relevant context].

Quality test: The statement should be human-centred, specific, actionable, researchable, and broad enough to permit multiple solutions.

V. Scope Definition — Setting purposeful boundaries

Scope definition establishes what the investigation includes, excludes, and assumes so that the team can work within a manageable boundary without losing the problem’s essential context.

A. Scope definition

Scope is not merely a reduction in size; it is an explicit agreement about the system boundary, target users, time period, location, deliverables, and level of intervention.

In-scope elements: Specify the users, journey stages, service channels, geography, and period being studied; for example, online application support for domestic students during enrolment week.
Out-of-scope elements: Exclusions prevent uncontrolled expansion; international admissions, curriculum design, and campus housing may be excluded from an enrolment-support project.
Boundary justification: Each boundary should reflect evidence or resources; limiting research to one campus may allow observation of every service counter rather than superficial study of ten sites.
Process boundary: Define start and end points, such as from “searching for a service” to “receiving confirmation,” rather than vaguely referring to the entire customer experience.
Stakeholder boundary: Include decision-makers and affected groups even when they are not end users; excluding support staff can produce an impractical process.
Time boundary: State whether the issue concerns a normal week, a peak period, or changes over twelve months.
Assumptions: Record conditions treated as stable, such as an existing payment platform remaining available; assumptions must be revisited if evidence challenges them.
Scope creep control: New requests should be assessed against the original objective, available time, stakeholder value, and effect on the core problem.

VI. Constraint Analysis — Recognising limits and design conditions

Constraint analysis identifies restrictions that shape the range of acceptable solutions; constraints are not automatically negative because they can focus creativity and reveal essential requirements.

A. Constraint analysis

The analysis distinguishes fixed conditions from negotiable preferences and makes trade-offs visible before solution development.

Technical constraints: Existing hardware, software compatibility, bandwidth, data formats, maintenance capacity, or cybersecurity requirements may limit implementation.
Financial constraints: A budget ceiling, such as $20,000 for a pilot, affects materials, staffing, testing, and maintenance rather than only the initial build.
Time constraints: A solution needed before a six-week registration period requires a different development approach from a long-term infrastructure redesign.
Legal and regulatory constraints: Data protection, accessibility standards, safety codes, procurement rules, and licensing conditions define what can be collected or deployed.
Organisational constraints: Approval structures, staff skills, training time, policies, and resistance to change can determine whether adoption is possible.
Physical and environmental constraints: Space, climate, power supply, transport, and local infrastructure affect deployment; a solar device in a shaded location has a different energy constraint from one in direct sunlight.
Ethical constraints: A design must avoid coercion, discrimination, unnecessary surveillance, and exclusion of vulnerable groups.
Hard versus soft constraints: A legal prohibition is generally hard; a preference for using an existing brand identity may be soft and negotiable.
Trade-offs: Increasing speed may reduce accuracy, while increasing personalisation may increase cost or privacy risk; constraints should therefore be documented with their consequences.
Requirements traceability: Link each important constraint to evidence, an owner, and a verification method, such as “must support screen readers,” tested through accessibility evaluation.

VII. Objective Setting — Defining intended results

Objective setting translates the problem definition into measurable, realistic outcomes that guide decisions and provide criteria for judging whether an intervention helps.

A. Objective setting

An objective states the desired change, for whom, by how much, and within what time or context; it differs from an activity, which describes what the team will do.

Outcome orientation: “Reduce average form-completion time” is an outcome; “conduct three workshops” is an activity that may contribute to it.
Specificity: Identify the population and behaviour, such as “new users completing the online application without staff assistance.”
Measurability: Use indicators including completion rate, error count, waiting time, satisfaction score, cost per transaction, or accessibility success rate.
Baseline and target: A target requires a starting point. If current completion is 54%, an objective might seek 75% within one semester.
Time frame: State when improvement should occur, such as “within three months of implementation,” so evaluation is not indefinite.
Feasibility and ambition: Objectives should stretch performance without ignoring constraints; reducing processing time from 40 to 5 minutes may be unrealistic if legal verification alone requires 15 minutes.
Equity and unintended effects: Measure distribution as well as averages; a shorter overall wait may conceal longer waits for users with disabilities or limited internet access.
Leading and lagging indicators: Training completion is a leading indicator, while reduced service errors is a lagging outcome; both help monitor progress.

Objective format: