Unit 2: Problem Definition and Analysis - Subjective Questions

Stakeholder needs are the expectations, goals, concerns, motivations, and limitations of individuals or groups affected by a problem or its possible solution.

Understanding stakeholder needs is essential because:

• It ensures that the problem is viewed from multiple perspectives.
• It helps identify explicit needs as well as hidden or unmet needs.
• It prevents designers from making assumptions based only on their own experiences.
• It improves user acceptance and the practical usefulness of proposed solutions.
• It reveals conflicts between different stakeholder groups.
• It supports the development of solutions that are desirable, feasible, and viable.

Techniques such as interviews, observation, surveys, focus groups, and empathy mapping can be used to understand stakeholder needs.

Contextual factors are the surrounding conditions that affect how a problem occurs, is experienced, and can be solved. Important factors include:

• Social factors: Culture, relationships, social norms, and community expectations.
• Economic factors: Income, affordability, resource availability, and financial incentives.
• Technological factors: Existing infrastructure, digital access, technical skills, and system compatibility.
• Environmental factors: Location, climate, physical surroundings, and sustainability concerns.
• Political and legal factors: Regulations, policies, ethical requirements, and institutional authority.
• Organizational factors: Processes, hierarchy, communication patterns, and available expertise.
• Temporal factors: Changes over time, urgency, seasonality, and historical conditions.

Analyzing these factors prevents a problem from being treated in isolation and helps ensure that the final definition reflects real-world conditions.

Interviews and observation are qualitative techniques that help uncover both stated and unstated stakeholder needs.

Interviews:

• Involve asking stakeholders open-ended questions about their goals, difficulties, behaviors, and expectations.
• Follow-up questions can reveal the reasons behind a particular behavior or complaint.
• Interviews may be structured, semi-structured, or unstructured.
• Responses should be recorded, organized, and analyzed for recurring themes.

Observation:

• Involves studying stakeholders in their natural environment while they perform relevant tasks.
• It can reveal workarounds, inefficiencies, safety issues, and needs that people may forget to mention.
• The observer should avoid interfering with the activity and should document actions, context, and environmental conditions.

Using both methods provides a more reliable understanding because interview data reflects what people say, while observation reveals what they actually do.

Stakeholder needs can be classified according to how clearly they are expressed or recognized.

• Explicit needs: These are directly stated by stakeholders. For example, a student may say, "I need the examination timetable at least one month in advance."
• Implicit needs: These are not directly stated but are reasonably expected as part of a satisfactory solution. For example, a user may expect an online application system to protect personal information even if they do not mention security.
• Latent needs: These are unrecognized or unarticulated needs that stakeholders may not know they have until a solution reveals them. For example, users may not request automatic accessibility features but may greatly benefit from screen-reader compatibility.

Identifying all three types is important because focusing only on explicit needs can produce solutions that meet basic requests but fail to address deeper expectations or opportunities for innovation.

Empathy maps and stakeholder maps are visual tools used to organize information during problem analysis.

An empathy map commonly records what a stakeholder:

• Says
• Thinks
• Does
• Feels
• Experiences as a pain
• Hopes to gain as a benefit

It helps the team move beyond surface-level requirements and understand stakeholder emotions, motivations, and frustrations.

A stakeholder map represents the people, groups, institutions, and systems connected to the problem. Stakeholders can be categorized according to their level of interest, influence, impact, or involvement.

Together, these tools help teams:

• Identify primary, secondary, and indirect stakeholders.
• Recognize relationships and power differences.
• Discover conflicting expectations.
• Prioritize whom to engage during research.
• Build a more complete and human-centered problem definition.

Both techniques investigate the causes of a problem, but they differ in structure and application.

Five Whys:

• Begins with a clearly stated problem.
• Repeatedly asks why the problem occurred.
• Helps move from a visible symptom to an underlying cause.
• Is simple and effective for relatively focused problems.
• May become unreliable if the team assumes only one causal path.

Cause-and-effect analysis:

• Uses a structured diagram, often called a fishbone or Ishikawa diagram.
• Organizes possible causes into categories such as people, methods, machines, materials, measurement, and environment.
• Supports group brainstorming and consideration of multiple interacting causes.
• Is more suitable when a problem has several possible causes.

The Five Whys is generally linear, whereas cause-and-effect analysis is multidimensional. They can be combined by using a fishbone diagram to identify possible causes and the Five Whys to investigate important causes in greater depth.

A systematic problem-identification process may include the following steps:

1. Observe the situation: Study the environment, activities, and events associated with the issue.
2. Collect stakeholder perspectives: Use interviews, surveys, focus groups, and contextual inquiry.
3. Document symptoms: Record what is happening without immediately assuming the cause.
4. Analyze patterns: Group observations into themes and identify recurring behaviors or failures.
5. Investigate root causes: Apply techniques such as the Five Whys, cause-and-effect diagrams, or data analysis.
6. Identify affected stakeholders: Determine who experiences the problem, who contributes to it, and who influences it.
7. Test assumptions: Verify interpretations through additional evidence or stakeholder feedback.
8. Prioritize the problem: Consider its severity, frequency, impact, urgency, and solvability.
9. Formulate a problem statement: Express the validated challenge in a clear, user-centered form.

Validation is important because a perceived problem may be only a symptom, an isolated incident, or a result of incorrect assumptions.

A problem statement is a concise description of a meaningful challenge that identifies who is affected, what difficulty they experience, and why the difficulty matters. It guides further research and solution development.

An effective problem statement should be:

• User-centered: Focused on the people experiencing the issue.
• Clear: Written in language that stakeholders can understand.
• Specific: Describes a meaningful challenge without unnecessary generalization.
• Evidence-based: Supported by research and observations.
• Solution-neutral: Does not prescribe a particular product, technology, or method.
• Actionable: Broad enough to allow creative ideas but focused enough to guide design.
• Relevant: Connected to stakeholder goals and organizational priorities.
• Measurable where appropriate: Includes indicators that can later be used to evaluate improvement.

A useful structure is: "[Stakeholder] needs a way to [need] because [insight or underlying reason]."

These three statements serve different purposes.

• Symptom statement: Describes an observable effect without explaining the deeper issue. Example: "Customers are waiting too long in the service area."
• Problem statement: Explains the stakeholder-centered challenge and its significance. Example: "Customers need a predictable and efficient service process because uncertainty about waiting times causes frustration and abandoned purchases."
• Solution statement: Proposes a specific response to the problem. Example: "The organization should install a mobile queue-management application."

A symptom statement is useful as an initial observation, but it may not reveal the root cause. A problem statement should be developed through research and should remain open to multiple solutions. A solution statement should be created only after the problem has been properly understood and defined.

A suitable problem statement is:

First-year and commuting students need a more accessible and engaging way to discover and use library resources because they find the current services difficult to navigate, poorly communicated, and disconnected from their study routines.

This formulation is effective because:

• It identifies a specific stakeholder group.
• It describes a need rather than prescribing a solution.
• It includes likely underlying reasons for low usage.
• It leaves room for several solutions, such as improved communication, redesigned spaces, better search tools, or extended services.
• It can be validated through interviews, usage data, observation, and surveys.
• It connects the issue to user experience rather than merely stating that usage is low.

The statement should be revised if research shows that another group or another cause is more significant.

Scope definition establishes the boundaries of a problem-solving effort. It clarifies what is included, what is excluded, which stakeholders are considered, the time period involved, and the expected depth of analysis.

Importance of scope definition:

• Prevents the project from expanding without control.
• Focuses research and team effort on relevant issues.
• Helps estimate time, cost, skills, and resources.
• Clarifies responsibilities among team members.
• Makes objectives and success criteria easier to establish.
• Supports realistic decision-making.

Risks of an excessively broad scope:

• Lack of focus
• High resource requirements
• Difficulty identifying root causes
• Delays and unclear accountability

Risks of an excessively narrow scope:

• Ignoring important stakeholders or contextual factors
• Treating symptoms rather than systemic causes
• Producing solutions that fail when applied in the real environment
• Missing unintended consequences

A good scope is focused but flexible enough to include evidence that reveals important relationships.

A scope statement should provide a shared understanding of the project boundaries. Its major components include:

• Problem area: The challenge or opportunity being investigated.
• Purpose: Why the project is important and what value it is expected to create.
• Target stakeholders: The primary users and other affected groups.
• Geographical and organizational boundaries: The locations, departments, institutions, or communities included.
• Time boundary: The period covered by the research or the deadline for the project.
• Activities included: Research, analysis, ideation, prototyping, testing, or implementation planning.
• Activities excluded: Work deliberately outside the project boundary.
• Resources: Available budget, personnel, technology, data, and facilities.
• Deliverables: Expected outputs such as a validated problem statement, prototype, or recommendation.
• Assumptions and dependencies: Conditions that must be true or external factors on which the project relies.
• Success criteria: Indicators used to judge whether the project has achieved its intended outcome.

Constraint analysis is the systematic identification and evaluation of factors that limit the available choices or the implementation of a solution. Constraints do not always prevent innovation; they can also focus the design team and encourage creative alternatives.

• Technical constraints: Limitations related to technology, infrastructure, performance, compatibility, or reliability.
• Financial constraints: Limits on budget, operating cost, revenue, or affordability.
• Legal constraints: Requirements imposed by laws, regulations, contracts, standards, or intellectual property rules.
• Ethical constraints: Requirements concerning fairness, privacy, safety, inclusion, consent, and avoidance of harm.
• Time constraints: Deadlines, response times, seasonal periods, or limited project duration.
• Resource constraints: Limited people, skills, materials, equipment, data, or organizational capacity.

Each constraint should be documented, classified as fixed or negotiable, and assessed for its impact on objectives and possible solutions.

Constraints influence design thinking in both positive and negative ways.

Positive influence:

• Encourage teams to focus on the most important needs.
• Reduce the number of possible directions and make decisions easier.
• Stimulate resourceful and unconventional ideas.
• Promote prioritization and realistic planning.
• Reveal opportunities to redesign processes rather than simply add resources.

Negative influence:

• Excessive restrictions may eliminate promising ideas too early.
• Unrecognized constraints may cause implementation failure.
• Fixed assumptions may be mistaken for genuine constraints.
• Financial or technical limitations may result in solutions that exclude vulnerable stakeholders.

Teams should distinguish between must-have constraints, which cannot be violated, and preferences, which may be negotiable. They should also test whether a constraint is real, temporary, or created by an outdated process. Effective design balances creativity with feasibility and ethical responsibility.

These terms describe different levels of intended achievement.

• Goal: A broad statement of the desired direction or long-term purpose. Example: Improve access to healthcare.
• Objective: A specific result that contributes to the goal. It should be clear and measurable where possible. Example: Reduce average appointment-booking time by within six months.
• Output: A direct product or deliverable produced by project activities. Example: A redesigned appointment-booking interface.
• Outcome: The change in behavior, performance, or experience resulting from the output. Example: More patients successfully book appointments without assistance.
• Impact: The broader, long-term effect on individuals, organizations, or society. Example: Improved continuity of care and better population health.

The sequence can be represented as:

Clear distinctions help teams set realistic objectives and evaluate whether a solution creates meaningful value.

SMART objectives are designed to be clear and assessable. SMART commonly means:

• Specific: States exactly what is to be achieved and for whom.
• Measurable: Includes indicators or evidence that show progress.
• Achievable: Is realistic given available capabilities and constraints.
• Relevant: Supports stakeholder needs and the overall project purpose.
• Time-bound: Specifies a deadline or time period.

For example, an unclear objective is: "Improve the online registration process."

A SMART version is: "Increase the percentage of users who complete online registration without assistance from to within four months, while maintaining compliance with accessibility requirements."

SMART criteria reduce ambiguity, support prioritization, guide evaluation, and help stakeholders agree on what success means. However, objectives should not become so rigid that they prevent learning when new evidence emerges.

The problem identifies unreliable service, negative effects on commuters, and a need for greater predictability. Suitable objectives can be derived by converting these concerns into measurable improvements:

1. Reliability objective: Increase the percentage of services arriving within the accepted time window from the current baseline to at least within twelve months.
2. Information objective: Ensure that of commuters can access accurate delay information within five minutes of a disruption.
3. Experience objective: Reduce the average commuter-reported uncertainty score by within six months of implementing the intervention.
4. Punctuality objective: Reduce the proportion of commuters reporting lateness caused by transportation delays by within one year.
5. Equity objective: Provide equivalent disruption information through digital and non-digital channels for commuters with limited internet access.

These objectives are derived from the main needs of reliability, timely information, reduced uncertainty, punctual arrival, and inclusion. Baseline data must be collected before final targets are approved.

Stakeholder conflicts arise when different groups have incompatible goals, priorities, risks, or definitions of success. For example, customers may want low prices, employees may want more time per service interaction, and managers may prioritize cost reduction.

Conflicts can be identified by:

• Mapping stakeholder interests, influence, and power.
• Conducting interviews with different stakeholder groups.
• Comparing stated needs and success criteria.
• Examining disagreements over resources, risks, privacy, or access.
• Using journey maps or system maps to show how decisions affect groups differently.

They can be managed by:

• Making disagreements explicit rather than hiding them.
• Separating positions from underlying interests.
• Using evidence and shared objectives to support discussion.
• Prioritizing safety, rights, and ethical requirements.
• Co-creating criteria for evaluating alternatives.
• Negotiating trade-offs transparently.
• Testing proposed directions with affected stakeholders.

The goal is not always to satisfy every preference, but to create a fair, evidence-based balance while protecting essential stakeholder needs.

Qualitative and quantitative techniques provide different but complementary forms of evidence.

Qualitative techniques:

• Include interviews, observation, focus groups, diary studies, and open-ended responses.
• Explore experiences, emotions, motivations, meanings, and contextual details.
• Usually involve smaller samples but provide rich explanations.
• Help identify unexpected needs and formulate hypotheses.

Quantitative techniques:

• Include surveys with numerical responses, usage analytics, experiments, performance measures, and statistical records.
• Measure frequency, scale, trends, relationships, and differences between groups.
• Usually involve larger samples and support comparison or generalization.
• Help establish baselines and test the significance of patterns.

Qualitative evidence can explain why a problem occurs, while quantitative evidence can show how often, how many, or how large the problem is. Using both methods, known as mixed-method analysis, generally produces a stronger problem definition.

A problem tree is a visual analysis tool that organizes a complex issue into three levels:

• Roots: Direct, indirect, and systemic causes of the problem.
• Trunk: The central problem, expressed as an existing negative condition.
• Branches: Immediate and long-term effects resulting from the problem.

For example, if the central problem is "small businesses struggle to access digital payment systems," possible roots include high setup costs, limited digital literacy, unreliable connectivity, and lack of trust. Possible effects include lost sales, reduced customer convenience, and limited business growth.

The method helps teams:

• Distinguish causes from symptoms.
• Identify relationships among contributing factors.
• Avoid treating an effect as the central problem.
• Locate areas where intervention may be possible.
• Convert negative conditions into positive objectives for later planning.

The problem tree should be validated with evidence and stakeholder perspectives rather than treated as a final explanation based only on team assumptions.