Design Research Methods: Contextual Inquiry and Synthesis

Last Updated May 28, 2026

Design research methods give design thinking its evidentiary foundation. Without disciplined inquiry, design teams risk mistaking assumptions for needs, internal preferences for stakeholder realities, and polished concepts for meaningful solutions. Contextual inquiry and synthesis are especially important because they connect design work to the actual settings in which people act, decide, improvise, struggle, collaborate, and make sense of systems. They help teams study not only what people say, but what they do, what the environment asks of them, what constraints shape their behavior, and what hidden forms of work make systems function.

Design Research Methods: Contextual Inquiry and Synthesis examines how design teams move from situated field research to credible interpretation. Contextual inquiry helps teams observe people in real contexts rather than abstracting them into generic “users.” Synthesis helps teams convert field notes, interviews, observations, artifacts, workflows, tensions, and contradictions into design knowledge. Together, they form one of the most important bridges between empathy and stakeholder research, problem framing, insight generation, ideation, prototyping, and testing and validation.

This article treats design research as a rigorous interpretive practice rather than a preliminary activity. Contextual inquiry is not simply “watching users.” Synthesis is not simply grouping sticky notes. Both require method, documentation, reflexivity, ethics, sampling judgment, bias control, and careful translation between lived experience and design action. When practiced well, they help teams understand how problems are embedded in environments, relationships, workflows, policies, institutions, technologies, and forms of power.

Contextual inquiry and synthesis matter because many design failures begin with poor evidence. Teams may conduct interviews outside the context of use, rely too heavily on stated preference, recruit only accessible participants, reduce complex experience to personas, or summarize research without interpreting it. Contextual research slows this rush toward solution. It asks the team to enter the setting, study the work, observe the relationships, follow the handoffs, notice the artifacts, and understand the situated intelligence that people use to navigate real conditions.

What Design Research Methods Mean

Design research methods are systematic ways of learning from people, settings, artifacts, practices, systems, and relationships so that design decisions are grounded in evidence rather than assumption. They include interviews, contextual inquiry, observation, diary studies, participatory workshops, usability testing, journey mapping, service blueprinting, survey research, ethnographic fieldwork, co-design, prototype testing, and mixed-methods evaluation. These methods differ in purpose, evidence type, and depth, but they share a central responsibility: to make design more accountable to reality.

In design thinking, research methods are not isolated technical procedures. They are part of a larger process of inquiry, framing, interpretation, and intervention. A design team does not simply collect data and then “move on” to creativity. It uses research to understand what kind of problem it is facing, what stakeholders actually experience, where systems break down, what constraints matter, what tensions remain unresolved, and what forms of evidence should guide the next design move.

Design research therefore differs from casual feedback gathering. A casual feedback process may ask people what they want. A design research process asks what people are trying to accomplish, what conditions shape their action, what hidden work they perform, what they avoid, what they trust, what they fear, what they misunderstand, what they improvise, and what institutional arrangements make the experience easier or harder. It treats stakeholder experience as evidence that must be interpreted carefully.

Contextual inquiry and synthesis are especially important because they sit close to the core of human-centered design. Contextual inquiry helps the team observe action in its natural environment. Synthesis helps the team make sense of that evidence without prematurely flattening it into obvious conclusions. Together, they protect design from two common failures: abstraction without evidence and data collection without interpretation.

Design research is strongest when methods are chosen because they fit the question, not because they are fashionable. A poorly chosen method can make the wrong evidence look authoritative. A well-chosen method helps the team see what the problem actually requires.

Back to top ↑

What Contextual Inquiry Is

Contextual inquiry is a design research method that studies people while they are engaged in real activity within the setting where that activity normally occurs. Instead of asking participants to describe a workflow from memory in a conference room, the researcher observes the workflow in context, asks questions while the activity unfolds, studies the artifacts involved, and learns how people actually navigate tasks, interruptions, tools, constraints, decisions, and exceptions.

The method is especially powerful because much human action is tacit. People often cannot fully explain their routines in the abstract because those routines are triggered by environments, tools, sequences, social cues, exceptions, and embodied habits. A nurse may not remember every workaround used to reconcile a medication order until the situation occurs. A customer-service worker may not describe an unofficial spreadsheet unless the researcher sees it being used. A student may not name a bureaucratic barrier until the researcher watches them attempt to complete a form. Contextual inquiry makes these tacit practices visible.

In design thinking, contextual inquiry has three major functions. First, it grounds the team in lived reality before problem framing becomes too abstract. Second, it reveals misalignments between official process and actual practice. Third, it produces richly situated evidence for synthesis, insight generation, ideation, and prototyping. It helps designers understand the problem as it is enacted, not merely as it is described.

Contextual inquiry is often guided by several assumptions:

• People’s work and experience are shaped by setting, tools, relationships, rules, and interruptions.
• People often perform invisible labor that official systems fail to recognize.
• Observed behavior and participant explanation are both necessary; neither is sufficient alone.
• Breakdowns, workarounds, pauses, hesitations, and exceptions often reveal important design opportunities.
• Research should preserve context rather than strip experience into isolated preferences too quickly.

Unlike a purely observational study, contextual inquiry usually includes conversation. The researcher watches and asks. Why did you do that? What are you checking? What happens if this fails? Who do you call next? How did you learn that workaround? What would happen if this tool disappeared? These questions help connect visible behavior to meaning, judgment, and constraint.

The researcher’s role is therefore neither detached observer nor ordinary interviewer. It is closer to a learner entering the participant’s world with humility, structure, and careful attention. The participant is treated as the expert in the work or experience being studied. The researcher’s task is to understand that expertise well enough to translate it responsibly into design knowledge.

Back to top ↑

Why Context Matters in Design Research

Context matters because behavior changes when it is removed from the conditions that shape it. People may describe a process as simple when they are not actively facing the documents, deadlines, interruptions, terminology, emotional stakes, environmental constraints, or social pressures that make it difficult. They may report that they understand a system when the system is not presently asking them to make a decision. They may say they would use a tool differently than they actually do under time pressure, uncertainty, fear, or fatigue.

Design research loses depth when context disappears. A form looks easier in a usability lab than it does in a crowded kitchen with poor internet, limited English, missing paperwork, and a child asking for help. A healthcare portal looks clearer in a demonstration than it does to a patient waiting anxiously for results. A staff workflow looks rational in a process diagram but chaotic when the researcher watches interruptions, exceptions, shift changes, informal escalation, and system failures accumulate in real time.

Contextual inquiry helps reveal several kinds of evidence that abstract methods often miss:

• Environmental constraints: lighting, noise, device access, physical space, time pressure, privacy, mobility, and safety.
• Artifact dependence: forms, checklists, spreadsheets, post-it notes, paper records, screenshots, templates, and unofficial tools.
• Workflow sequence: what happens first, what happens next, where handoffs occur, and where the process breaks.
• Social coordination: who asks whom, who approves, who repairs errors, who knows the workaround, and who carries responsibility.
• Emotional burden: anxiety, embarrassment, frustration, distrust, uncertainty, fear of consequences, or resignation.
• Invisible labor: translation, checking, repeated calling, remembering, explaining, compensating, improvising, and repairing.
• System mismatch: gaps between official policy, digital interface, actual workflow, and lived use.

Context matters not because every detail is equally important, but because the important details are often unknown before the fieldwork begins. The researcher does not know in advance which environmental cue, informal practice, artifact, handoff, or exception will reveal the structure of the problem. Contextual inquiry preserves the opportunity to notice what a predesigned survey or abstract interview might never ask about.

This is also why contextual inquiry is central to design thinking’s broader movement from assumption to evidence. It forces the team to encounter the problem outside the organization’s preferred abstraction. It shows the difference between how a system is imagined, how it is documented, how it is managed, and how it is lived.

Back to top ↑

Core Principles of Contextual Fieldwork

Good contextual inquiry depends on fieldwork discipline. The researcher must observe carefully, ask questions without taking control, document what happens, preserve sequence, notice artifacts, and avoid interpreting too quickly. The goal is not to confirm a design team’s existing theory. The goal is to learn how the setting actually works.

One common principle is apprenticeship. The researcher approaches the participant as someone who can teach the work. Even when the researcher has domain knowledge, the participant understands the lived practice in a way outsiders usually do not. This apprenticeship stance changes the tone of research. It reduces the tendency to interrogate participants as test subjects and encourages a more respectful inquiry into expertise, judgment, adaptation, and constraint.

Another principle is partnership. Contextual inquiry is not passive surveillance. The participant can explain, correct, clarify, and interpret. The researcher should be willing to ask, “What did I just misunderstand?” or “Is this typical?” or “What would happen if this case were different?” This helps prevent observation from becoming projection.

A third principle is focus. Contextual inquiry should be open enough to notice unexpected patterns, but focused enough to answer the design research question. A team studying patient discharge should not merely observe everything in a hospital. It should understand discharge-related tasks, communication, handoffs, documents, roles, risks, and patient understanding. Good focus gives fieldwork direction without closing discovery.

These principles help contextual inquiry remain both open and disciplined. The researcher enters the setting ready to be surprised, but not without method.

Back to top ↑

Planning a Contextual Inquiry Study

A contextual inquiry study begins before the first field visit. Teams need to define research questions, identify stakeholder groups, determine sampling strategy, clarify ethical boundaries, plan observation protocols, decide how notes and recordings will be handled, and prepare for synthesis. Poor planning can undermine the quality of fieldwork before it begins.

The first planning task is to clarify the design research question. A vague question such as “How do users feel about the service?” is usually too broad. A stronger question might ask: “How do first-time applicants understand documentation requirements while completing the eligibility process?” or “How do frontline staff handle exception cases when the official workflow does not fit the situation?” These questions identify a setting, an activity, a stakeholder group, and a design-relevant uncertainty.

The second task is sampling. Contextual inquiry does not usually aim for statistical representativeness in the same way as a large survey. It aims for meaningful variation: different roles, levels of experience, access conditions, workflows, locations, edge cases, and burden levels. A team studying a public service may need to include first-time users, repeat users, non-completers, frontline workers, caregivers, administrators, community intermediaries, and people who avoided the service entirely. The most important participants may not be the easiest to recruit.

The third task is ethics and consent. Contextual inquiry may involve sensitive settings: homes, clinics, schools, workplaces, public offices, community organizations, or digital environments where private information appears. Participants should understand what is being studied, how data will be used, what will be recorded, who will see it, and whether participation affects their access to services or employment conditions. When power asymmetry is high, consent must be handled with special care.

Good planning does not remove uncertainty. It makes uncertainty researchable. It gives the team enough structure to learn responsibly from real settings.

Back to top ↑

Observation, Interviewing, and Artifact Study

Contextual inquiry works because it combines several evidence types. Observation shows what happens. Interviewing reveals how participants interpret what happens. Artifact study shows how tools, documents, templates, devices, forms, records, checklists, and informal objects mediate activity. None of these evidence types is sufficient alone. Together, they create a richer account of practice.

Observation allows the researcher to see sequences, interruptions, pauses, repeated actions, workarounds, environmental constraints, and moments of confusion. But observation alone can mislead. A participant may appear hesitant because the interface is confusing, because the task is emotionally significant, because they are worried about making an error, because they are being observed, or because they know the system sometimes punishes mistakes. Interviewing in context helps clarify meaning.

Interviewing during or immediately after activity allows the researcher to ask about decisions while the situation is still present. Why did you choose that option? What are you checking here? What would happen if you submitted this without calling? Who taught you this step? Is this part of the official process? Have you ever seen this fail? These questions reveal the logic behind observed action.

Artifact study is equally important. People rarely work or navigate systems through memory alone. They use forms, screenshots, saved emails, paper folders, browser bookmarks, spreadsheets, handwritten notes, templates, calendars, text messages, internal dashboards, sticky notes, and unofficial databases. These artifacts reveal the real infrastructure of action. Sometimes the most important design evidence is not what the participant says but the tool they created because the official system did not support them.

The strongest contextual inquiry preserves the relationship among these evidence types. It does not isolate a quote from the task, a behavior from the setting, or an artifact from the system that made it necessary.

Back to top ↑

Workflows, Handoffs, and Hidden Labor

One of the most important contributions of contextual inquiry is its ability to reveal hidden labor. Many systems appear efficient because invisible work is being performed by users, frontline staff, caregivers, community intermediaries, or informal support networks. A process may look simple on paper because the complexity has been shifted elsewhere. Contextual inquiry helps locate that shifted burden.

Hidden labor often appears as workaround. A staff member keeps a personal spreadsheet because the official system lacks exception tracking. A caregiver translates forms because the service is not language-accessible. A user calls repeatedly because the portal provides no trustworthy status. A teacher maintains a manual checklist because the student information system does not support the real advising workflow. A community organization explains eligibility rules because the public agency’s instructions are unclear. These workarounds are not side details. They are evidence of system failure and system repair.

Handoffs are especially revealing. Many breakdowns occur not within a single task but between roles, systems, departments, agencies, devices, or moments in time. The person who submits a form does not know who owns the next step. The frontline worker cannot see what the back office has done. The patient receives instructions from multiple clinicians that do not align. The student moves from admissions to financial aid to advising without a single coherent path. Contextual inquiry helps trace these handoffs as lived experiences rather than as process-chart abstractions.

Hidden labor can be grouped into several recurring forms:

• Navigation labor: figuring out where to go, who to contact, what applies, and what step comes next.
• Translation labor: converting institutional language into understandable terms.
• Verification labor: checking whether information was received, correct, complete, or acted upon.
• Coordination labor: connecting people, offices, systems, documents, or responsibilities that the formal process leaves fragmented.
• Emotional labor: managing anxiety, embarrassment, distrust, frustration, or fear while navigating the system.
• Repair labor: fixing errors, compensating for missing data, re-entering information, or creating unofficial workarounds.
• Advocacy labor: pushing the system to recognize a case, exception, need, or right that is not handled smoothly.

When design teams recognize hidden labor, they can ask more serious questions. Who is making the current system work? Who is paying the cost of complexity? Which burdens are being treated as user behavior rather than system design? Which informal workarounds should be supported, redesigned, or eliminated? These questions often lead to deeper problem framing than conventional feedback sessions can produce.

Back to top ↑

What Research Synthesis Means

Research synthesis is the process of transforming field evidence into structured understanding. It does not mean summarizing every observation. It means identifying patterns, tensions, contradictions, relationships, and implications that can guide design decisions. Synthesis is where contextual inquiry becomes usable design knowledge.

This stage is intellectually demanding because field research produces messy evidence. Participants may contradict one another. Observed behavior may differ from stated belief. A workaround may be helpful in one context and harmful in another. A service breakdown may be caused by policy in one case, technology in another, and staffing in a third. Synthesis must preserve enough complexity to remain truthful while producing enough structure to support action.

Weak synthesis tends to produce generic themes: “communication,” “confusion,” “trust,” “training,” “access,” “support.” These themes may be real, but they are too broad to guide design. Strong synthesis asks what kind of communication is failing, where confusion appears, why trust is damaged, which support is missing, what access requires, and how different stakeholders experience the same system differently. It moves from label to explanation.

Research synthesis usually involves several stages:

1. Evidence preparation: clean notes, transcripts, observations, artifacts, screenshots, and field records.
2. Evidence segmentation: break material into meaningful units such as quotes, incidents, decisions, behaviors, and breakdowns.
3. Coding: assign interpretive or descriptive labels to units of evidence.
4. Pattern detection: identify repeated themes, contradictions, dependencies, and exceptions.
5. Mapping: organize findings through journey maps, service blueprints, system maps, or evidence matrices.
6. Insight drafting: convert patterns into explanatory claims grounded in evidence.
7. Opportunity translation: convert insights into design questions, prototype hypotheses, or research next steps.
8. Validation: test interpretations against counter-evidence, stakeholder review, additional research, or prototype feedback.

Synthesis is not the place where evidence becomes simple. It is the place where evidence becomes intelligible enough to support responsible design action.

Back to top ↑

Affinity Mapping, Coding, and Thematic Analysis

Affinity mapping, coding, and thematic analysis are common methods for synthesizing contextual research. They help teams organize evidence without losing its connection to lived experience. Each method has a different emphasis, but all are concerned with the movement from raw material to meaningful pattern.

Affinity mapping is widely used in design workshops. Researchers place observations, quotes, behaviors, or field notes onto cards and group them according to emerging relationships. The method is useful because it externalizes interpretation. Teams can see how evidence clusters, where disagreement exists, and which categories are too broad or too thin.

Coding is more formal. It involves assigning labels to units of evidence, often in multiple passes. Descriptive coding may label what is happening: “status checking,” “manual workaround,” “handoff confusion,” “privacy concern.” Interpretive coding may label what the evidence suggests: “low confidence,” “institutional opacity,” “burden shift,” “trust repair.” A mature synthesis process often uses both.

Thematic analysis moves from coded evidence into broader patterns. A theme is not just a topic. It is an interpretive pattern that says something meaningful about the research question. “Communication” is a topic. “Users interpret procedural silence as abandonment because the system provides no status, owner, or expected timeline” is closer to an insight-bearing theme.

Strong synthesis keeps evidence traceable. A design team should be able to connect an insight back to observations, participant groups, artifacts, field settings, and contradictory cases. Without traceability, synthesis becomes storytelling detached from evidence.

Back to top ↑

Journey Maps, Service Blueprints, and System Maps

Contextual inquiry often produces evidence that is difficult to understand through themes alone. Experience unfolds through time, across touchpoints, through handoffs, and within systems. Journey maps, service blueprints, and system maps help represent this structure.

Journey maps show experience across stages. They often include actions, touchpoints, emotions, pain points, information needs, and moments of decision. A journey map is useful when the design challenge involves sequence: applying, waiting, receiving, returning, escalating, learning, recovering, or transitioning. It helps the team see where friction accumulates and where the experience shifts emotionally or cognitively.

Service blueprints connect visible stakeholder experience to the operational and organizational layers behind it. They distinguish frontstage interaction from backstage work, support processes, systems, roles, handoffs, and dependencies. This is especially valuable when contextual inquiry reveals that a user problem is actually produced by internal workflow, unclear responsibility, system fragmentation, or policy constraints.

System maps represent relationships among actors, flows, incentives, information, resources, authority, and feedback loops. They are useful when the problem cannot be understood as a linear journey alone. A public service, healthcare pathway, educational advising system, or community support network may require mapping across institutions and roles.

These artifacts should not be treated as polished deliverables alone. They are thinking tools. Their value lies in helping the team understand relationships that would otherwise remain scattered across notes, transcripts, and individual memories.

Back to top ↑

From Synthesis to Insight and Design Direction

Synthesis becomes valuable when it changes what the team understands and what it chooses to do next. The movement from synthesis to insight requires interpretation. The movement from insight to design direction requires translation. A coded theme or journey map is not yet a design direction. It must be converted into an explanatory claim and then into a question, hypothesis, or concept that can guide action.

For example, contextual inquiry may show that applicants repeatedly call a public agency after submitting documents. The descriptive theme may be “status checking.” A deeper insight might be: Applicants interpret procedural silence as evidence that the institution has lost, ignored, or rejected their case, so they call repeatedly to regain confidence and accountability. A design opportunity might then become: How might we make case ownership, status, and next steps visible enough that applicants do not have to call repeatedly to restore trust?

This translation process is where design research directly shapes ideation and prototyping. If the team stops at “users need better communication,” the next step may be a generic notification system. If the team understands that the real issue is procedural silence, missing ownership, and low trust, it can explore more meaningful interventions: status visibility, named ownership, expected timelines, exception handling, confirmation systems, human support triggers, or policy simplification.

Strong insight translation usually includes:

• Evidence summary: what observations, quotes, artifacts, and cases support the pattern?
• Interpretive claim: what does the pattern reveal?
• Stakeholder grounding: whose experience is being explained?
• System connection: what workflow, rule, tool, incentive, or relationship produces the pattern?
• Design implication: what kind of intervention space opens from the insight?
• Testable hypothesis: what could be prototyped or studied next?

The strongest design research does not merely produce findings. It produces better questions for design action.

Back to top ↑

Research Quality, Validity, and Evidence Strength

Contextual inquiry and synthesis require standards of quality. Because design research often uses qualitative evidence, some teams mistakenly treat quality as informal or subjective. That is a mistake. Qualitative design research can be rigorous, but its rigor depends on transparency, traceability, triangulation, reflexivity, sampling logic, and careful claims about what the evidence can and cannot support.

Evidence strength in contextual inquiry is not determined only by sample size. It depends on the richness of observation, relevance of context, variation across participants, convergence across methods, presence of contradictory cases, quality of documentation, and fit between evidence and decision. A small number of contextual sessions may reveal a powerful workflow breakdown. But the team should not confuse that discovery with proof of prevalence across a whole population.

Different evidence types support different claims:

Good synthesis distinguishes between finding, hypothesis, implication, and decision. A finding describes what the research shows. A hypothesis proposes an explanation that can be tested. An implication suggests what the design team should consider. A decision commits resources, attention, or authority. Design research becomes risky when these categories collapse into one another.

Validity in design research is also strengthened through triangulation. If interviews, observations, artifacts, service data, and prototype tests point toward the same interpretation, confidence increases. If they conflict, the conflict is not a problem to hide. It is a research finding. Contradiction may reveal stakeholder variation, system complexity, or an interpretation that needs revision.

Back to top ↑

Bias, Reflexivity, and Interpretive Discipline

Contextual inquiry and synthesis are vulnerable to bias because researchers do not enter the field as neutral recording devices. They bring assumptions, categories, organizational pressures, design preferences, prior theories, and expectations about what matters. These assumptions shape what they notice, what they ask, what they record, and how they interpret evidence.

Reflexivity is the practice of making those assumptions visible. It does not mean that researchers can eliminate all bias. It means they document their position, examine their interpretations, look for counter-evidence, and remain aware of how their presence and institutional role shape the research encounter.

Several interpretive risks are common in design research:

• Confirmation bias: seeing evidence that supports the expected design direction while overlooking evidence that complicates it.
• Solution fixation: interpreting research through the lens of a preferred feature, product, technology, or policy change.
• Availability bias: overvaluing vivid stories because they are memorable.
• Authority bias: weighting the views of managers, experts, or confident participants more heavily than less powerful stakeholders.
• Convenience bias: recruiting participants who are easy to reach and mistaking them for the affected population.
• Institutional translation: softening stakeholder critique into language that protects the organization from uncomfortable conclusions.
• Over-synthesis: smoothing away contradiction in order to create a clean deliverable.

Interpretive discipline requires practices that slow these distortions. Teams should separate observation from interpretation in field notes. They should document contradictory cases. They should trace insights back to evidence. They should invite multiple researchers to review the same material. They should ask what interpretation would be most uncomfortable for the institution. They should test synthesized findings with participants when appropriate. They should treat uncertainty as part of the research output rather than a weakness to conceal.

Good synthesis does not pretend to be free of interpretation. It makes interpretation accountable.

Back to top ↑

Power, Consent, and the Ethics of Field Research

Contextual inquiry can be ethically sensitive because it brings researchers into people’s real environments, workflows, homes, workplaces, service encounters, digital systems, or institutional settings. It may reveal private information, vulnerable moments, informal workarounds, fear, mistakes, conflict, or critique of powerful institutions. The richness of contextual inquiry is precisely what makes ethical responsibility so important.

Consent must be meaningful. Participants should understand what the researcher will observe, what will be recorded, how information will be used, who will see it, and what will happen if they decline. In workplaces, schools, healthcare, public services, and other high-power settings, researchers must be especially careful that participation does not feel required. A frontline worker may not feel free to refuse if leadership invited the research team. A patient may not know whether declining affects care. A student may not understand whether participation affects support. Ethical research design must account for these asymmetries.

Privacy is also critical. Contextual inquiry may expose documents, screens, conversations, client records, patient information, financial details, internal workflows, or personal circumstances. Teams should minimize collection, avoid unnecessary recording, anonymize field notes, secure data, and prevent vivid examples from identifying participants. The most compelling story is not always ethical to publish or present.

Ethics also involves reciprocity. Participants should not be treated merely as sources of insight. Where appropriate, they should receive compensation, feedback, summaries of findings, or opportunities to validate interpretation. Communities and frontline groups should not be asked to repeatedly educate institutions without seeing meaningful change.

Ethical contextual inquiry is not less rigorous than extractive research. It is more rigorous because it protects the conditions under which truthful, situated knowledge can emerge.

Back to top ↑

AI-Assisted Design Research and Its Limits

AI-assisted tools can support design research synthesis by helping organize notes, cluster observations, summarize transcripts, generate preliminary codes, identify recurring language, compare themes, and prepare research artifacts. Used carefully, these tools can reduce administrative burden and help teams explore large volumes of qualitative material. They can also support multilingual research workflows, search across field notes, and generate candidate synthesis structures for human review.

However, AI-assisted synthesis carries serious limitations. AI systems can produce plausible summaries that erase nuance, flatten contradiction, misclassify sensitive evidence, overemphasize common language, or reproduce dominant assumptions. They may convert stakeholder experience into generic themes and miss the contextual details that make a finding meaningful. They can also create privacy risks if sensitive transcripts or field notes are processed without adequate safeguards.

AI should therefore be treated as an assistant to human interpretation, not as a substitute for research judgment. Human researchers must decide what evidence means, what context matters, which participants are missing, which contradictions are important, and what ethical boundaries apply. AI can help sort and search material, but it cannot determine the legitimacy of an interpretation or the responsibility of a design decision.

AI-assisted design research is strongest when it helps researchers ask better questions, organize evidence more transparently, and test interpretations more carefully. It is weakest when it lets teams appear rigorous while distancing themselves from the difficult human work of interpretation.

Back to top ↑

Mathematical Lens: Modeling Coverage, Saturation, and Synthesis Confidence

Contextual inquiry and synthesis are qualitative practices, but formal models can help clarify how teams reason about research coverage, evidence strength, and confidence. One useful abstraction is to treat synthesis confidence for a theme \(i\) as a function of evidence support, stakeholder coverage, method triangulation, and interpretive risk:

where \(C_i\) represents synthesis confidence, \(E_i\) evidence support, \(S_i\) stakeholder coverage, \(M_i\) method triangulation, and \(R_i\) interpretive risk. The weights \(w_e\), \(w_s\), \(w_m\), and \(w_r\) reflect the research team’s priorities. This model does not turn qualitative analysis into arithmetic. It makes visible the criteria that teams often apply implicitly when deciding whether a theme is strong enough to guide design.

Research coverage can also be modeled at the participant-group level. If a study identifies \(n\) relevant stakeholder groups and includes meaningful evidence from \(k\) of them, a simple coverage ratio can be written as:

This ratio is not a measure of truth, but it helps identify an important risk. A team may have rich evidence from one group and almost no evidence from another. If the missing group is highly affected, the study may be less adequate than the volume of field notes suggests.

Theme saturation is often discussed in qualitative research, but it should be used carefully. A simplified way to think about saturation is to examine how many new themes emerge as additional sessions are added. If \(T_t\) is the cumulative number of themes after \(t\) sessions, the marginal theme discovery rate is:

When \(\Delta T_t\) approaches zero across additional sessions, the team may be approaching saturation for the current sampling frame. But this does not mean the research is universally complete. Saturation depends on who was sampled, which settings were observed, what questions were asked, and which forms of experience were excluded.

Triangulation can also be approximated. If a theme is supported by \(m\) distinct methods out of \(M\) possible methods used in the study, method triangulation can be represented as:

A theme supported by interviews, observation, artifacts, and service data generally deserves different confidence than a theme supported only by one participant quote. But triangulation should not be used mechanically. Sometimes a single observation reveals a severe access barrier, safety risk, or ethical problem that deserves attention even before it appears frequently.

These models are useful because they help design teams discuss research quality more explicitly. They should not replace judgment. They should help teams ask better questions: whose experience is missing, what evidence supports this theme, what methods converge, what contradictions remain, and what should be studied next?

Back to top ↑

R Workflow: Contextual Inquiry Coding and Theme Reliability

The R workflow below demonstrates how a design research team can organize synthetic contextual inquiry evidence, evaluate theme strength, compare coding across researchers, and identify which themes need additional validation. It is not a replacement for qualitative judgment. It is a reproducible structure for documenting synthesis decisions.

# Install packages if needed.
# install.packages(c("tidyverse", "irr", "scales"))

library(tidyverse)
library(irr)
library(scales)

# -------------------------------------------------------------------
# Synthetic contextual inquiry evidence.
# Each row represents one coded evidence unit from fieldwork.
# -------------------------------------------------------------------

evidence_units <- tibble(
  unit_id = 1:24,
  participant_group = c(
    "First-time applicants", "First-time applicants", "Caregivers",
    "Frontline staff", "Frontline staff", "Administrators",
    "Community partners", "Excluded users", "Excluded users",
    "First-time applicants", "Caregivers", "Frontline staff",
    "Administrators", "Community partners", "First-time applicants",
    "Excluded users", "Caregivers", "Frontline staff",
    "Community partners", "Administrators", "First-time applicants",
    "Excluded users", "Caregivers", "Frontline staff"
  ),
  method = c(
    "contextual_observation", "interview", "artifact_review",
    "contextual_observation", "artifact_review", "interview",
    "workshop", "interview", "contextual_observation",
    "artifact_review", "interview", "contextual_observation",
    "process_walkthrough", "workshop", "interview",
    "contextual_observation", "artifact_review", "interview",
    "workshop", "process_walkthrough", "contextual_observation",
    "interview", "artifact_review", "contextual_observation"
  ),
  primary_theme = c(
    "status_uncertainty", "documentation_confusion", "translation_labor",
    "manual_workaround", "manual_workaround", "policy_complexity",
    "trust_gap", "access_barrier", "access_barrier",
    "documentation_confusion", "translation_labor", "handoff_breakdown",
    "policy_complexity", "trust_gap", "status_uncertainty",
    "access_barrier", "translation_labor", "handoff_breakdown",
    "trust_gap", "policy_complexity", "status_uncertainty",
    "access_barrier", "translation_labor", "manual_workaround"
  ),
  evidence_strength = c(
    8.2, 7.5, 8.0, 8.6, 8.3, 7.2,
    7.8, 8.4, 8.7, 7.6, 8.1, 8.5,
    7.3, 8.0, 8.1, 8.8, 8.0, 8.2,
    7.9, 7.4, 8.3, 8.5, 8.2, 8.4
  ),
  interpretive_risk = c(
    3.5, 4.0, 3.8, 3.4, 3.6, 4.2,
    4.1, 4.4, 4.5, 4.0, 3.9, 3.7,
    4.3, 4.0, 3.6, 4.6, 3.8, 3.9,
    4.1, 4.2, 3.5, 4.7, 3.9, 3.6
  )
)

# -------------------------------------------------------------------
# Theme-level evidence summary.
# -------------------------------------------------------------------

theme_summary <- evidence_units %>%
  group_by(primary_theme) %>%
  summarize(
    evidence_units = n(),
    stakeholder_groups = n_distinct(participant_group),
    methods = n_distinct(method),
    mean_evidence_strength = mean(evidence_strength),
    mean_interpretive_risk = mean(interpretive_risk),
    synthesis_confidence =
      0.35 * mean_evidence_strength +
      0.25 * rescale(stakeholder_groups, to = c(1, 10)) +
      0.25 * rescale(methods, to = c(1, 10)) -
      0.15 * mean_interpretive_risk,
    .groups = "drop"
  ) %>%
  arrange(desc(synthesis_confidence))

print(theme_summary)

# -------------------------------------------------------------------
# Synthetic coding comparison between two researchers.
# -------------------------------------------------------------------

coder_comparison <- tibble(
  unit_id = 1:24,
  coder_a = evidence_units$primary_theme,
  coder_b = c(
    "status_uncertainty", "documentation_confusion", "translation_labor",
    "manual_workaround", "manual_workaround", "policy_complexity",
    "trust_gap", "access_barrier", "status_uncertainty",
    "documentation_confusion", "translation_labor", "handoff_breakdown",
    "policy_complexity", "trust_gap", "status_uncertainty",
    "access_barrier", "translation_labor", "handoff_breakdown",
    "trust_gap", "policy_complexity", "status_uncertainty",
    "access_barrier", "documentation_confusion", "manual_workaround"
  )
)

kappa_result <- kappa2(coder_comparison %>% select(coder_a, coder_b))
print(kappa_result)

# -------------------------------------------------------------------
# Identify themes requiring additional validation.
# -------------------------------------------------------------------

validation_priority <- theme_summary %>%
  mutate(
    validation_priority =
      0.35 * mean_interpretive_risk +
      0.25 * (10 - mean_evidence_strength) +
      0.20 * (6 - stakeholder_groups) +
      0.20 * (5 - methods)
  ) %>%
  arrange(desc(validation_priority))

print(validation_priority)

# -------------------------------------------------------------------
# Visualize theme confidence.
# -------------------------------------------------------------------

ggplot(theme_summary, aes(x = reorder(primary_theme, synthesis_confidence), y = synthesis_confidence)) +
  geom_col() +
  coord_flip() +
  labs(
    title = "Contextual Inquiry Theme Synthesis Confidence",
    x = "Theme",
    y = "Synthesis confidence"
  ) +
  theme_minimal(base_size = 12)

# -------------------------------------------------------------------
# Export results.
# -------------------------------------------------------------------

write_csv(evidence_units, "contextual_inquiry_evidence_units.csv")
write_csv(theme_summary, "contextual_inquiry_theme_summary.csv")
write_csv(validation_priority, "contextual_inquiry_validation_priority.csv")
write_csv(coder_comparison, "contextual_inquiry_coder_comparison.csv")

This workflow demonstrates several useful research practices. It keeps evidence units traceable, summarizes theme strength across stakeholder groups and methods, calculates an inter-coder agreement measure, and identifies themes that may require additional validation. The purpose is not to reduce contextual inquiry to metrics, but to document synthesis more transparently.

The most important output may not be the highest-confidence theme. It may be the validation-priority list. Themes with high interpretive risk, limited stakeholder coverage, or low method triangulation should be treated carefully before they shape major design decisions.

Back to top ↑

Python Workflow: Research Synthesis, Theme Networks, and Evidence Strength

The Python workflow below builds a synthetic evidence matrix, calculates theme confidence, creates a theme co-occurrence network, and models uncertainty in synthesis confidence through Monte Carlo simulation. This type of workflow is useful when teams want a reproducible bridge between qualitative coding and transparent research documentation.

# Install packages if needed:
# pip install pandas numpy matplotlib networkx scipy

import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import networkx as nx

# ---------------------------------------------------------------------
# Synthetic contextual inquiry evidence units.
# ---------------------------------------------------------------------

evidence = pd.DataFrame({
    "unit_id": range(1, 25),
    "participant_group": [
        "First-time applicants", "First-time applicants", "Caregivers",
        "Frontline staff", "Frontline staff", "Administrators",
        "Community partners", "Excluded users", "Excluded users",
        "First-time applicants", "Caregivers", "Frontline staff",
        "Administrators", "Community partners", "First-time applicants",
        "Excluded users", "Caregivers", "Frontline staff",
        "Community partners", "Administrators", "First-time applicants",
        "Excluded users", "Caregivers", "Frontline staff"
    ],
    "method": [
        "contextual_observation", "interview", "artifact_review",
        "contextual_observation", "artifact_review", "interview",
        "workshop", "interview", "contextual_observation",
        "artifact_review", "interview", "contextual_observation",
        "process_walkthrough", "workshop", "interview",
        "contextual_observation", "artifact_review", "interview",
        "workshop", "process_walkthrough", "contextual_observation",
        "interview", "artifact_review", "contextual_observation"
    ],
    "primary_theme": [
        "status_uncertainty", "documentation_confusion", "translation_labor",
        "manual_workaround", "manual_workaround", "policy_complexity",
        "trust_gap", "access_barrier", "access_barrier",
        "documentation_confusion", "translation_labor", "handoff_breakdown",
        "policy_complexity", "trust_gap", "status_uncertainty",
        "access_barrier", "translation_labor", "handoff_breakdown",
        "trust_gap", "policy_complexity", "status_uncertainty",
        "access_barrier", "translation_labor", "manual_workaround"
    ],
    "secondary_theme": [
        "trust_gap", "access_barrier", "documentation_confusion",
        "handoff_breakdown", "policy_complexity", "documentation_confusion",
        "access_barrier", "trust_gap", "status_uncertainty",
        "policy_complexity", "access_barrier", "manual_workaround",
        "handoff_breakdown", "status_uncertainty", "trust_gap",
        "documentation_confusion", "policy_complexity", "manual_workaround",
        "access_barrier", "documentation_confusion", "status_uncertainty",
        "trust_gap", "translation_labor", "handoff_breakdown"
    ],
    "evidence_strength": [
        8.2, 7.5, 8.0, 8.6, 8.3, 7.2,
        7.8, 8.4, 8.7, 7.6, 8.1, 8.5,
        7.3, 8.0, 8.1, 8.8, 8.0, 8.2,
        7.9, 7.4, 8.3, 8.5, 8.2, 8.4
    ],
    "interpretive_risk": [
        3.5, 4.0, 3.8, 3.4, 3.6, 4.2,
        4.1, 4.4, 4.5, 4.0, 3.9, 3.7,
        4.3, 4.0, 3.6, 4.6, 3.8, 3.9,
        4.1, 4.2, 3.5, 4.7, 3.9, 3.6
    ]
})

# ---------------------------------------------------------------------
# Theme-level synthesis confidence.
# ---------------------------------------------------------------------

def minmax_scale(series, low=1, high=10):
    if series.max() == series.min():
        return pd.Series(np.repeat((low + high) / 2, len(series)), index=series.index)
    return low + (series - series.min()) * (high - low) / (series.max() - series.min())

theme_summary = (
    evidence
    .groupby("primary_theme")
    .agg(
        evidence_units=("unit_id", "count"),
        stakeholder_groups=("participant_group", "nunique"),
        methods=("method", "nunique"),
        mean_evidence_strength=("evidence_strength", "mean"),
        mean_interpretive_risk=("interpretive_risk", "mean")
    )
    .reset_index()
)

theme_summary["stakeholder_coverage_score"] = minmax_scale(theme_summary["stakeholder_groups"])
theme_summary["method_triangulation_score"] = minmax_scale(theme_summary["methods"])

theme_summary["synthesis_confidence"] = (
    0.35 * theme_summary["mean_evidence_strength"] +
    0.25 * theme_summary["stakeholder_coverage_score"] +
    0.25 * theme_summary["method_triangulation_score"] -
    0.15 * theme_summary["mean_interpretive_risk"]
)

theme_summary = theme_summary.sort_values("synthesis_confidence", ascending=False)

print("Theme summary:")
print(theme_summary)

# ---------------------------------------------------------------------
# Theme co-occurrence network.
# ---------------------------------------------------------------------

G = nx.Graph()

for _, row in evidence.iterrows():
    primary = row["primary_theme"]
    secondary = row["secondary_theme"]

    if primary == secondary:
        continue

    if G.has_edge(primary, secondary):
        G[primary][secondary]["weight"] += 1
    else:
        G.add_edge(primary, secondary, weight=1)

centrality = nx.degree_centrality(G)
centrality_df = (
    pd.DataFrame({
        "theme": list(centrality.keys()),
        "degree_centrality": list(centrality.values())
    })
    .sort_values("degree_centrality", ascending=False)
)

print("\nTheme network centrality:")
print(centrality_df)

# ---------------------------------------------------------------------
# Monte Carlo uncertainty analysis for synthesis confidence.
# ---------------------------------------------------------------------

np.random.seed(42)
n_simulations = 10000
simulation_records = []

for simulation_id in range(n_simulations):
    simulated = evidence.copy()
    simulated["evidence_strength"] = np.random.normal(
        loc=evidence["evidence_strength"],
        scale=0.5
    ).clip(1, 10)

    simulated["interpretive_risk"] = np.random.normal(
        loc=evidence["interpretive_risk"],
        scale=0.5
    ).clip(1, 10)

    sim_summary = (
        simulated
        .groupby("primary_theme")
        .agg(
            evidence_units=("unit_id", "count"),
            stakeholder_groups=("participant_group", "nunique"),
            methods=("method", "nunique"),
            mean_evidence_strength=("evidence_strength", "mean"),
            mean_interpretive_risk=("interpretive_risk", "mean")
        )
        .reset_index()
    )

    sim_summary["stakeholder_coverage_score"] = minmax_scale(sim_summary["stakeholder_groups"])
    sim_summary["method_triangulation_score"] = minmax_scale(sim_summary["methods"])

    sim_summary["synthesis_confidence"] = (
        0.35 * sim_summary["mean_evidence_strength"] +
        0.25 * sim_summary["stakeholder_coverage_score"] +
        0.25 * sim_summary["method_triangulation_score"] -
        0.15 * sim_summary["mean_interpretive_risk"]
    )

    sim_summary = sim_summary.sort_values("synthesis_confidence", ascending=False)
    sim_summary["rank"] = range(1, len(sim_summary) + 1)
    sim_summary["simulation_id"] = simulation_id

    simulation_records.append(sim_summary)

simulation_df = pd.concat(simulation_records, ignore_index=True)

rank_stability = (
    simulation_df
    .groupby("primary_theme")
    .agg(
        mean_synthesis_confidence=("synthesis_confidence", "mean"),
        sd_synthesis_confidence=("synthesis_confidence", "std"),
        median_rank=("rank", "median"),
        mean_rank=("rank", "mean"),
        best_rank=("rank", "min"),
        worst_rank=("rank", "max")
    )
    .reset_index()
    .sort_values(["median_rank", "mean_rank"])
)

print("\nRank stability:")
print(rank_stability)

# ---------------------------------------------------------------------
# Validation-priority diagnostic.
# ---------------------------------------------------------------------

theme_summary["validation_priority"] = (
    0.35 * theme_summary["mean_interpretive_risk"] +
    0.25 * (10 - theme_summary["mean_evidence_strength"]) +
    0.20 * (6 - theme_summary["stakeholder_groups"]) +
    0.20 * (5 - theme_summary["methods"])
)

validation_priority = theme_summary.sort_values("validation_priority", ascending=False)

print("\nValidation priority:")
print(validation_priority[[
    "primary_theme",
    "validation_priority",
    "mean_interpretive_risk",
    "stakeholder_groups",
    "methods"
]])

# ---------------------------------------------------------------------
# Visualize synthesis confidence.
# ---------------------------------------------------------------------

plt.figure(figsize=(10, 6))
plt.bar(theme_summary["primary_theme"], theme_summary["synthesis_confidence"])
plt.xticks(rotation=25, ha="right")
plt.ylabel("Synthesis confidence")
plt.title("Contextual Inquiry Theme Synthesis Confidence")
plt.tight_layout()
plt.show()

# ---------------------------------------------------------------------
# Export outputs.
# ---------------------------------------------------------------------

evidence.to_csv("contextual_inquiry_evidence_units.csv", index=False)
theme_summary.to_csv("contextual_inquiry_theme_summary.csv", index=False)
centrality_df.to_csv("contextual_inquiry_theme_network_centrality.csv", index=False)
rank_stability.to_csv("contextual_inquiry_theme_rank_stability.csv", index=False)
validation_priority.to_csv("contextual_inquiry_validation_priority.csv", index=False)
simulation_df.to_csv("contextual_inquiry_simulation_records.csv", index=False)

This workflow is useful because it keeps synthesis auditable. A team can see which themes are supported across methods and stakeholder groups, which themes are central in the co-occurrence network, which themes remain stable under uncertainty, and which themes require further validation.

The workflow should not be used to automate interpretation. Its purpose is to help design researchers document how they moved from field evidence to synthesis confidence. The actual meaning of each theme still requires careful reading, stakeholder context, and design judgment.

Back to top ↑

GitHub Repository

The companion repository provides a reproducible technical workspace for exploring the modeling, simulation, documentation, and implementation ideas associated with this article. The article folder is organized for multi-language design research and includes folders for Python, R, Julia, C++, Fortran, C, Rust, Go, SQL, notebooks, documentation, raw data, processed data, and outputs.

The repository structure is designed to support reproducible design research rather than isolated code examples. The language-specific folders allow the same research-synthesis logic to be explored across statistical, scientific, systems, and database workflows. The documentation and data folders help preserve assumptions, provenance, intermediate outputs, coding decisions, validation notes, and research artifacts so that synthesis remains traceable.

Back to top ↑

Conclusion

Design research methods matter because design thinking depends on the quality of what the team learns before it attempts to change anything. Contextual inquiry helps teams study people within the real settings where problems unfold. Synthesis helps teams interpret that evidence without collapsing it into superficial themes or premature solutions. Together, they make design more answerable to lived experience, actual workflows, institutional constraints, hidden labor, and system conditions.

Seen clearly, contextual inquiry is not simply observation and synthesis is not simply organization. Contextual inquiry is a disciplined encounter with situated practice. Synthesis is the disciplined interpretation of that encounter into design knowledge. Both require methodological care, ethical responsibility, reflexivity, documentation, and humility. Both ask teams to resist the comfort of abstraction and the speed of premature certainty.

The field is weakened when research becomes performative: a few interviews, a few quotes, a polished persona, and a workshop wall of themes that do not change the design direction. It is strengthened when research methods are used to uncover how systems are actually lived, where burdens are hidden, whose knowledge has been excluded, which interpretations remain uncertain, and what design action the evidence can responsibly support.

A mature design process does not treat research as a decorative prelude to creativity. It treats research as the foundation of design judgment. Contextual inquiry and synthesis make that foundation stronger by connecting design to reality as it is practiced, experienced, repaired, resisted, and understood by the people who live within systems every day.

Back to top ↑

Related articles

• What Is Design Thinking?
• Human-Centered Problem Solving
• Empathy and Stakeholder Research in Design Thinking
• Problem Framing in Design Thinking
• Insight Generation in Design Thinking
• Ideation in Design Thinking
• Prototyping in Design Thinking
• Testing and Validation in Design Thinking
• Iteration and Experimentation in Design Thinking
• Design Thinking and Systems Thinking
• Design Thinking, Data Systems, and AI-Assisted Research

Further reading

• Beyer, H. and Holtzblatt, K. (1998) Contextual Design: Defining Customer-Centered Systems. San Francisco: Morgan Kaufmann. Available at: https://www.sciencedirect.com/book/9781558604117/contextual-design.
• Braun, V. and Clarke, V. (2006) ‘Using thematic analysis in psychology’, Qualitative Research in Psychology, 3(2), pp. 77–101. Available at: https://doi.org/10.1191/1478088706qp063oa.
• Brown, T. (2008) ‘Design thinking’, Harvard Business Review. Available at: https://hbr.org/2008/06/design-thinking.
• IDEO.org (2015) The Field Guide to Human-Centered Design. Available at: https://www.designkit.org/resources/1.html.
• ISO (2019) ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems. Available at: https://www.iso.org/standard/77520.html.
• Nielsen Norman Group (no date) ‘Contextual inquiry: inspire design by observing and interviewing users in their context’. Available at: https://www.nngroup.com/articles/contextual-inquiry/.
• Patton, M.Q. (2015) Qualitative Research & Evaluation Methods. 4th edn. Thousand Oaks: SAGE.
• Saldaña, J. (2021) The Coding Manual for Qualitative Researchers. 4th edn. London: SAGE. Available at: https://uk.sagepub.com/en-gb/eur/the-coding-manual-for-qualitative-researchers/book273583.
• Stanford d.school (no date) Design Thinking Bootleg. Available at: https://dschool.stanford.edu/tools/design-thinking-bootleg.
• Stickdorn, M., Hormess, M.E., Lawrence, A. and Schneider, J. (2018) This Is Service Design Doing. Sebastopol: O’Reilly Media. Available at: https://www.thisisservicedesigndoing.com/.
• Suchman, L.A. (1987) Plans and Situated Actions: The Problem of Human-Machine Communication. Cambridge: Cambridge University Press. Available at: https://doi.org/10.1017/CBO9780511625518.

Back to top ↑

References

• Beyer, H. and Holtzblatt, K. (1998) Contextual Design: Defining Customer-Centered Systems. San Francisco: Morgan Kaufmann. Available at: https://www.sciencedirect.com/book/9781558604117/contextual-design.
• Braun, V. and Clarke, V. (2006) ‘Using thematic analysis in psychology’, Qualitative Research in Psychology, 3(2), pp. 77–101. Available at: https://doi.org/10.1191/1478088706qp063oa.
• Brown, T. (2008) ‘Design thinking’, Harvard Business Review. Available at: https://hbr.org/2008/06/design-thinking.
• IDEO.org (2015) The Field Guide to Human-Centered Design. Available at: https://www.designkit.org/resources/1.html.
• ISO (2019) ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems. Available at: https://www.iso.org/standard/77520.html.
• Nielsen Norman Group (no date) ‘Contextual inquiry: inspire design by observing and interviewing users in their context’. Available at: https://www.nngroup.com/articles/contextual-inquiry/.
• Patton, M.Q. (2015) Qualitative Research & Evaluation Methods. 4th edn. Thousand Oaks: SAGE.
• Saldaña, J. (2021) The Coding Manual for Qualitative Researchers. 4th edn. London: SAGE. Available at: https://uk.sagepub.com/en-gb/eur/the-coding-manual-for-qualitative-researchers/book273583.
• Stanford d.school (no date) Design Thinking Bootleg. Available at: https://dschool.stanford.edu/tools/design-thinking-bootleg.
• Stickdorn, M., Hormess, M.E., Lawrence, A. and Schneider, J. (2018) This Is Service Design Doing. Sebastopol: O’Reilly Media. Available at: https://www.thisisservicedesigndoing.com/.
• Suchman, L.A. (1987) Plans and Situated Actions: The Problem of Human-Machine Communication. Cambridge: Cambridge University Press. Available at: https://doi.org/10.1017/CBO9780511625518.

Back to top ↑