Understanding users,
work and context

Users, goals and the surrounding activity

A usable interface must support work that matters to somebody. Knowing how vision, memory and movement operate helps explain an interaction, but it does not tell us whose goal the interface should serve. Before choosing a control or sketching a screen, we need to understand the people, activities and conditions that give the interaction its purpose.

Consider a student who searches a library catalogue. The visible action is entering a book title. The immediate task is locating an item. The larger goal may be preparing for an examination, checking a quotation or finding an accessible edition. These goals can lead to different definitions of success. Returning an exact title is insufficient if the student cannot obtain a usable copy before the deadline.

An activity includes more than the computer. People use paper, phones, conversations, spatial arrangements and learned routines. A catalogue screenshot, a shelf label and a librarian’s advice may all participate in one task. The boundary of our inquiry should follow the meaningful activity rather than stop at the edge of a screen.

Klemmer illustrates this distinction with transport: taking a bus is part of a larger activity such as getting to work or visiting somebody. Looking only at the vehicle can hide the uncertainty involved in finding a stop, planning a connection or reaching the final destination. An initial design brief is a useful starting point, but field evidence can reveal that the important difficulty occurs elsewhere. [R1]

This chapter follows a continuous library case through research planning, data collection, interpretation, task modeling and requirements. Use the case to practice each step of the research and design process.

Research questions and definitions of success

A research question specifies what we need to learn. “Build a better catalogue” names an ambition, not a question. “What do students do when the catalogue says an item is available but they cannot find it?” directs attention toward a particular breakdown, its context and possible recovery paths. It leaves room for evidence to change the eventual solution.

A feature request and a need are not interchangeable. A request for a mobile application may express a need to retain information while moving through the building. A different solution—a stable item summary, a printable location slip or better shelf signage—might meet that need. Record what the participant requested, but investigate the reason before treating the request as a requirement.

Define the task’s success boundary as well. Is success identifying a title, locating a physical copy, borrowing it, or obtaining appropriate reading material? These boundaries change both the task model and any later evaluation. A successful search followed by an unsuccessful shelf visit is not a successful borrowing episode.

Constraints belong in the inquiry: opening hours, accessibility, available equipment, network access, organizational responsibilities and time pressure can all matter. Distinguish a constraint observed in the current system from one that must remain in the future design. A requirement to visit a particular desk may be an existing procedure rather than an unavoidable user need.

A research-question clinic

Before recruiting anyone, write down what a useful answer would let you decide. “Do students like the catalogue?” leaves the situation and decision unclear. “What do students do when a listed copy cannot be found, and what information do they need to recover?” identifies an episode, an uncertainty and a possible design consequence. It still allows a result that does not require new software.

A question about how work unfolds is different from a question about how often a problem occurs or whether one interface causes better performance. Observations and interviews can investigate mechanisms and generate hypotheses. Estimating prevalence or comparing causal effects requires a suitable design and sampling strategy. Lecture 6 develops experiments, measurement and statistical analysis; this lecture concentrates on understanding work.

Participants, stakeholders and sampling

Target users perform the activity the design intends to support. Other stakeholders affect it or experience its consequences. In the library, students, librarians, shelving staff, accessibility staff and system administrators can provide different knowledge. Interviewing a manager does not substitute for understanding a student’s experience; interviewing only students may conceal the process that keeps catalogue status current.

Recruitment should follow the research question. For missing-book recovery, variation in catalogue familiarity, visit frequency, access needs and the urgency of obtaining an item may be informative. A convenience sample of technically confident friends can be easy to recruit while excluding the people who struggle most. State whom the study reached and whom it did not.

Qualitative recruitment often deliberately seeks informative variation rather than a statistically representative sample. That choice supports understanding different mechanisms and circumstances; it does not justify estimating how common a problem is across a population. There is no universal participant count that guarantees sufficient understanding for every inquiry. Scope, diversity, depth, emerging contradictions and the claims we intend to make all affect the decision.

A domain expert can describe rules, exceptional cases and tacit skills. A novice can expose assumptions hidden by expertise. A lead user who develops a workaround may reveal an unmet need, while an extreme user can make a constraint unusually visible. Klemmer contrasts very heavy and very infrequent email use: either extreme can be informative. Neither automatically represents everyone between them. [R1]

Keep a recruitment matrix with relevant characteristics and reasons for including them. Avoid collecting demographic information merely because a persona template has a blank field. A characteristic should matter to the research question or the interpretation. Similar demographics do not establish equivalent experience, access or goals.

Recruit for informative differences

Turn an inclusion criterion into a reason. “Has attempted to find a physical library item recently” makes concrete recall possible. Variation in familiarity helps you examine learned workarounds. Access needs may expose barriers hidden by a convenience sample. Recruit staff whose actual responsibilities touch the episode, rather than assuming that the most senior person knows every detail.

A recruitment matrix is a planning device, not proof of representativeness. Track the perspectives you have reached and the gaps that remain. If recruitment comes through one enthusiastic librarian, consider whom that route may exclude. Record refusals or access limitations at an appropriate aggregate level; do not turn lack of participation into a judgment about individuals.

Revisit the matrix during analysis. A surprising episode may justify seeking someone who performs the same task under different conditions. Explain the reason for that follow-up and the limits of the resulting claims. Do not prescribe a universal sample size simply because a class exercise needs a manageable number of sessions.

Ethical practice is part of the method

People should understand what participation involves, what will be recorded, who can access the material and how it will be used. Explain that declining or stopping is possible, and describe any practical limits on removing data after aggregation or publication. Consent to an interview is not automatically consent to video recording, public quotation or the publication of a screen image.

Power relationships can affect participation. A student approached by an instructor or an employee recruited through a supervisor may feel pressure to agree or to give a favorable account. Recruitment and communication should reduce that pressure. Compensation recognizes time and effort; its appropriateness depends on the setting and should not be treated as a universal amount copied from another study.

Plan data handling before collecting data. Record only what the question requires; separate contact information from research records where possible; limit access and define retention. Replacing a name with a code is pseudonymization, not necessarily anonymization. A rare role, location or quoted incident may still identify someone. Screen captures can include information about people who never joined the study.

For the library exercise, observation notes can describe actions without recording a person’s name, account details or complete borrowing history. If a screenshot is needed, arrange a way to exclude unrelated personal information. Do not rely on the promise that sensitive material will be noticed and removed later.

Ethical preparation also includes the burden and setting of research. Avoid disrupting essential work or asking participants to record an entry during an unsafe activity. Institutional review and applicable local requirements must be followed for the actual study. These principles guide a research plan; they do not replace the relevant review process.

Reflexivity means examining how our role, expectations and decisions influence the inquiry. A designer who already wants a mobile app may attend selectively to phone use. Write down that expectation, seek contrary cases and preserve the distinction between what was recorded and what was inferred. Transparency is more useful than claiming to be completely unbiased.

Prepare a participant-facing opening

Explain the activity in everyday terms: “We want to learn how people locate books and seek help. We are studying the service, not testing your ability. You can skip a question or stop.” Explain recording separately, along with access, use and applicable withdrawal arrangements. Check understanding rather than treating a signature as the whole conversation.

During a visit, a participant may open a screen containing unrelated account information, or a bystander may enter the scene. Stop or redirect recording when necessary and follow the agreed procedure. If you change the method, document why. A usable research procedure should let people protect their privacy without having to interrupt an apparently authoritative researcher.

Observation and contextual inquiry

Observe activities, artifacts and relationships. Note the sequence of actions, the conditions that trigger a change, information consulted, people approached and workarounds. A sticky note can be an external memory aid, an unofficial procedure or a coordination device. Its presence is a reason to inquire, not proof of a design failure.

A short field visit is not automatically an ethnography. Ethnographic work involves sustained engagement with practices and their social or cultural meaning. A focused observational visit can still be valuable if its purpose and limits are clear. Do not describe all qualitative work as informal watching or all interpretation as arbitrary opinion.

Contextual inquiry combines attention to real work with questions about it. The participant is knowledgeable about the activity; the researcher learns by examining concrete episodes and artifacts together. In Beyer and Holtzblatt’s account, context, partnership, interpretation and focus guide this inquiry. Shared interpretation helps check an explanation, while focus keeps the inquiry relevant without requiring every observation to confirm an initial assumption. [R6]

Ask “What are you checking here?” or “What made you choose this route?” at an appropriate pause. Avoid making the participant reconstruct an idealized procedure detached from what just happened. Also avoid constant questioning that prevents the work from unfolding. Record when a question or request may have changed the activity.

A think-aloud request asks a participant to verbalize while acting. It can reveal information useful to understanding an interaction, but it is not invisible instrumentation. It adds work and can interfere with conversation, concentration or a naturally fast sequence. Choose it for a reason and distinguish spontaneous remarks from prompted explanations.

In Klemmer’s examples, working alongside people exposes informal learning and everyday adaptations that manuals omit. The general lesson is to examine how expertise and cooperation are enacted in practice. A formal job description is one source; it is not a complete description of the work. [R1]

Prepare a focused field visit

Define an episode boundary before you arrive. For the library question, begin when the person identifies an item to obtain and follow the activity through its outcome, including a decision to stop. A boundary limited to catalogue use would exclude the shelf visit that makes the question meaningful. Note what you cannot observe, such as staff work behind a service desk.

Prepare a short observation guide: triggers, actions, artifacts, handoffs, interruptions, workarounds and outcomes. Use it to direct attention without forcing every episode into a fixed script. Decide how you will record notes, request clarification and handle consent. Pilot the note-taking arrangement; a researcher who spends the visit operating recording equipment may miss the activity.

Position yourself so that you can see relevant actions without obstructing them. In a two-person research team, one person can lead the conversation while the other records; participants should know both roles. A single researcher may use brief jottings and expand them promptly afterward. Preserve the difference between contemporaneous notes and later reconstruction.

Attend to coordination, not only the focal person

Follow information across artifacts. A code moves from a screen to a note; the note is compared with a shelf label; a staff member asks for an edition that the note omits. This trajectory may explain a difficulty more clearly than counting clicks. Also notice useful adaptations: a hand-drawn map, an informal queue, or a colleague who knows an exceptional procedure.

Consider another setting: a shared printer. A person alternates between a laptop, a release terminal and a paper notice taped to the device. Watching only the laptop might suggest a software problem. Following the whole episode may reveal a release-code instruction on the notice or a queue at the terminal.

Decide when to ask and when to wait

When an unfamiliar action occurs, note a question and ask at a natural pause. “You checked the label and then moved to the next shelf; what were you looking for?” anchors the prompt to an event without naming its cause. If the activity is delicate or time-critical, defer the question. Record that the explanation was retrospective and may reflect reconstruction.

Do not rescue the participant automatically when studying existing work. Providing directions changes the episode you can observe. At the same time, research is not a reason to prolong distress or obstruct essential work. Agree on intervention boundaries and record interventions. A breakdown after a researcher’s instruction cannot be interpreted as if the instruction never happened.

Distinguish observation from a usability test

In naturalistic observation, the person’s own activity supplies the task and outcome. In a usability test, the researcher commonly provides a goal involving a particular design. Both may use recording and questions, but the evidence answers different questions. “Show me your current way of finding a required edition” investigates practice; “Use this new prototype to request help” evaluates a proposal.

A worked observation record

The following episode follows a student trying to obtain a specified edition. Separate visible action, participant report and researcher interpretation before drawing a conclusion.

“The student cannot remember information” is not an observation in this record. The phone note may be an efficient strategy. “The catalogue is inaccurate” is also not established: the item might be in use, awaiting shelving, mislocated or associated with a misunderstood location. Those explanations generate follow-up questions.

A preliminary interpretation is that item identity and location must survive a transition between catalogue, shelves and staff assistance. Evidence E1, E4 and E6 makes that interpretation plausible, but additional episodes may show different strategies. A participant who saves the complete record might recover without repeating the search.

Preserve enough context for another analyst to understand each record: task, relevant artifact, participant role, time or sequence, and whether the statement was prompted. Keep interpretations in a separate field so they can change without rewriting the evidence.

Build a record another researcher can inspect

Expand shorthand soon after the visit while retaining the original jottings. Attach record identifiers to relevant artifacts and recording timestamps where available. Mark a direct quotation only when it was captured accurately; otherwise use a labeled paraphrase. Do not silently convert remembered wording into a verbatim quotation.

Finish with an outcome and a coverage note. If you left before staff completed the investigation, write “outcome not observed.” If the recording failed, state which interval is missing. Missing data can change what you may conclude. A neatly completed timeline must not hide uncertainty about order, duration or completion.

Debrief before explanations become fixed

Write a brief summary of the episode, two plausible interpretations and a question that would distinguish them. For the return to the catalogue, perhaps the note omitted the title, or perhaps the person wanted updated availability. The visible return alone does not decide between those accounts. A follow-up question and inspection of the carried information can help.

In a team, compare what each researcher noticed before combining notes. A disagreement may concern viewpoint, timing or interpretation. Preserve the original records and document the resolution. Avoid allowing the most confident account to overwrite an inconvenient observation. The purpose of the debrief is to expose assumptions and decide what to investigate next.

Choose a method for the question

Methods produce different kinds of evidence. An interview can explore a person’s explanation, intention and remembered experience. Observation can reveal actions, artifacts and coordination that are difficult to describe. Logs can record selected system events, but an event name does not explain the user’s motive. A diary extends collection across time while depending on participation and self-report.

Combining methods is useful when they address complementary uncertainties. A log may show repeated searches, an observation may show movement between catalogue and shelves, and an interview may explain why a particular edition matters. Agreement can support an interpretation. Disagreement should be investigated rather than averaged away: perhaps the sources describe different tasks or periods.

Distinguish formative inquiry from an evaluation of a proposed interface. Watching everyday borrowing seeks to understand work. Asking someone to complete a specified task in a prototype examines that design. They can inform one another, but their instructions, researcher role and interpretation differ. Detailed usability testing and experimentation are developed later in the course.

Interviews and useful questions

A structured interview uses a prepared set of questions and a relatively stable procedure. A semi-structured interview combines prepared topics with follow-up questions. An unstructured interview allows more flexibility in direction; it still requires preparation, listening and a clear purpose. These are choices about organization, not a ranking from scientific to unscientific.

Start with a concrete recent episode: “Tell me about the last time you searched for a book you needed.” Ask what prompted the task, what happened, what information was used, where the process changed and how it ended. Follow the participant’s vocabulary before introducing technical labels such as “error recovery” or “information architecture.”

Closed questions are useful for factual clarification, such as whether a person visited that day. Open questions help uncover an episode and its meaning. The problem is not the grammatical form alone; it is whether the question produces evidence relevant to the inquiry. Klemmer’s feature-importance example shows why broad approval of a feature is weak evidence for its actual value. [R1]

Allow a pause after an answer. Immediately proposing an interpretation can prevent a participant from elaborating. Neutral probes include “Can you give an example?”, “What happened next?” and “What made that matter?” A question such as “Was it frustrating because the search was badly designed?” supplies both the emotion and the cause.

Pilot the guide before the main sessions. Check comprehension, order, timing, recording and whether the questions produce concrete accounts. A technically correct question can still be incomprehensible to the intended participants. Russis’s interview guidance emphasizes preparation, participant comfort and follow-up opportunities; these are part of obtaining usable evidence. [R2]

An expert’s account of how a procedure should work is valuable but may differ from everyday practice. Preserve both accounts and investigate the difference. Do not assume that either an official statement or a single remembered episode is the complete truth.

Construct an interview guide, not a questionnaire to race through

Organize the guide around a small number of uncertainties: the goal, a recent episode, information used, changes of plan and outcome. Prepare an opening question and optional probes for each. Mark factual checks separately. During the interview, follow relevant unexpected material and return to uncovered topics later. Completing every prepared question is less valuable than understanding an important episode.

Begin with an accessible account of recent work. A neutral opening builds shared context before sensitive or demanding questions. Ask one question at a time. “What happened, why did you do that, and how did you feel?” bundles different demands and makes the answer difficult to interpret. Reflect the participant’s words carefully; do not improve their language into your preferred technical explanation.

Probe for evidence without cross-examining

Ask for a concrete instance when a participant says “always” or “never.” “Can you walk me through the most recent example?” usually produces more useful detail than challenging the generalization. Ask about successful episodes too. Comparing a routine success with a breakdown may expose the condition that changes the task.

Use artifacts as prompts when appropriate: a participant can explain a note, message or screen they used. Obtain permission before viewing it and avoid unrelated private material. The artifact anchors the account but does not remove recall limitations. Ask what was happening at the time rather than assuming that the current screen is identical to its earlier state.

When an account seems inconsistent with observation, describe both neutrally. “Earlier I saw you return to the catalogue; now you describe usually going straight to staff. What was different that time?” The difference may reflect an exception, a misunderstanding, social expectations or incomplete observation. Treat it as a question to investigate rather than proof that the participant is unreliable.

Practice listening and closing

Allow silence and avoid completing the person’s sentence. A short reflection—“So the edition mattered because of the assigned pages?”—can check understanding, but keep the interpretation revisable. Watch for acquiescence: an immediate “yes” to a long explanation supplied by the interviewer is weaker evidence than the participant’s own account.

Close by checking important interpretations, asking what you missed and explaining the agreed next steps. Afterward, note which questions led to concrete evidence and which produced vague agreement. Record deviations from the guide and any factors that may have shaped the conversation. Pilot revisions should improve what you can learn, not simply make the session shorter.

Diaries, experience sampling and research burden

Some events occur too rarely or across too much time for a short visit. A diary asks participants to record relevant experiences over a period. Entries may be tied to an event, such as an unsuccessful shelf search, or a schedule, such as the end of a visit. Experience sampling prompts a response at selected moments; schedules may be fixed, random or triggered by a condition, depending on the question.

A diary can capture context closer to an event than an interview held weeks later. It still involves selection, recall and interpretation. People may omit inconvenient, embarrassing or unremarkable episodes. A missing entry is not evidence that nothing happened. If difficult episodes are precisely those least likely to be recorded, the omissions matter to the findings.

Keep the recording procedure proportionate. A lengthy form after every search may become a larger task than the search itself. Practice entries can reveal misunderstood categories. Reminders may support participation, but repeated prompting also imposes a cost. Research instruments are interfaces: their design affects who participates and what data they produce.

Klemmer’s additional needfinding methods provide useful alternatives when direct observation is impractical. Choose the recording medium for the context: text, photographs or audio have different burdens and privacy implications. Do not assume that a convenient medium for the researcher is convenient for the participant. [R1]

Design the diary interaction

A diary instruction must say what counts as an entry, when to record it and what to do if immediate recording is impractical. For occasional printing difficulties, a short event entry could record the goal, setting, trigger, action and outcome, with optional later explanation. A daily entry may catch routine successes but require remembering an entire day. Choose the schedule for the question rather than habit.

Missing entries do not mean that no events occurred. Participants may forget, be busy or find the instrument difficult. Ask about omissions in a follow-up, record the limitations and avoid filling gaps with assumptions. A prompt that arrives during the activity may change that activity. Pilot the research instrument as an interaction in its own right.

Research example: capturing interrupted mobile tasks

Karlson and colleagues’ CHI 2010 study connects interruptions to an actual inquiry method. Participants captured phone screenshots when a task was disrupted, then added contextual explanations through a web form. A later interview discussed the captured experiences. The screenshot acted as a memory cue while keeping immediate phone input short. [R4]

The diary phase involved 24 people: 12 iPhone and 12 Pocket PC users recruited within a large software corporation. They participated over two weeks. There were 467 submitted screenshots; 81 were excluded, leaving 386 for further analysis. These are records contributed by people, not 386 independent participants. Further analyses used smaller subsets according to their questions.

The methodological tradeoff is instructive: lightweight capture can preserve a moment, while delayed annotation can lose context. The recruitment and historical devices limit generalization. We use this study to examine a research design, not to infer present-day smartphone behavior from its counts. See the study’s method description on pages 4–5 of the paper.

A second methodological example is Chetty and colleagues’ Kermit household network study. It combined interviews, diaries, speed tests and limited usage records in a ten-household field trial. Each source answered a different question: technical performance, lived experience and household responsibility are related but not identical. The study is useful further reading on combining evidence and on the limitations of recruitment and instrumentation. [R5]

Organizing and interpreting findings

Analysis is the work of making an accountable interpretation. Begin by organizing notes, recordings and artifacts so that statements remain connected to episodes. A short note should be specific enough to stand alone but retain its source. “Navigation bad” is an opinion; “After returning from the shelf, participant repeated the title search” identifies an event that can be examined.

Affinity analysis groups notes according to meaningful relationships and develops labels that express what the groups have in common. Start with the evidence and allow groupings to change. A note that does not fit is not necessarily irrelevant; it may reveal a different task, a contradiction or a missing category.

Affinity analysis of research notes is not the same as participant card sorting. Card sorting asks people to organize items, often to investigate categorization for an information architecture. The activities may both involve cards, but their data, participants and questions differ. A designer sorting observations has not thereby measured users’ preferred navigation categories.

Codes can identify actions, conditions, goals or recurring concerns. Document how labels were used and keep examples. An affinity cluster is not automatically a mature theme explaining a pattern. Thematic interpretation requires reasoning about relationships and meaning, and may require revisiting the original record. Counts of mentions do not establish prevalence when participants had different opportunities to mention an issue.

Seek contrary cases. If some students avoid repeated searches by saving a record, ask what enables that route. Does it work only on personal phones? Does the saved view contain current availability? Competing explanations sharpen the analysis. Team discussion can reveal assumptions, but agreement between analysts alone does not prove that an interpretation is correct.

Work through one interpretation

Take E1, E4 and E6 as separate notes. A first code might describe the action: “copies location,” “repeats search” and “requests item identity.” A provisional grouping is “carrying item information across contexts.” The finding is not simply that three notes belong together; it is the argued interpretation that continuity of information may matter during recovery.

Now seek a contrary case: someone saves the complete record and still cannot proceed. This could weaken a claim about missing information and redirect attention to terminology, status or staff procedure. Preserve the exception and specify the conditions under which the interpretation seems useful. Distinguish grouping notes from estimating how common the difficulty is.

Digital tools for research analysis

Paper notes remain useful for collaborative interpretation, but task analysis can also use digital models, coded recordings and computational assistance. These tools support different stages of inquiry. An affinity board groups related evidence; card sorting investigates how people group or label items; an HTA describes goals, their decomposition and the plans governing their performance. Moving all three onto a screen does not make them the same method.

Choose a tool for the analytical job

A dedicated HTA editor reduces the effort of maintaining a hierarchy and its numbering. A video-coding tool helps locate evidence for a task. A qualitative repository helps organize and retrieve observations and quotations. AI can propose candidate structures or questions. The researcher must still decide whether the model fits the work and whether its claims are supported.

These examples illustrate capabilities rather than a requirement to buy or adopt a particular product. Only the ErgoSphere workflow in the task-modeling topic was tried hands-on for this chapter; the other descriptions were checked against their official documentation. Features and access conditions can change. A generic diagram editor is also sufficient when it lets the analyst maintain explicit plans and evidence links alongside the tree.

Code recorded actions and check their context

For a recorded study, define an event-coding scheme before counting actions: what marks the start and end of searching, a return to the catalogue, or a request for help? BORIS or a similar tool can associate those codes with timestamps. Review ambiguous episodes and, when appropriate, have another analyst code a subset to examine consistency. Agreement about an event code does not itself establish the user’s goal; combine the sequence with context and participant explanation.

System logs can reveal repeated searches and transitions, while process or task mining can suggest recurring sequences. Such sequences reflect what was captured. A catalogue log will miss a shelf visit, a phone note or a conversation unless additional data capture them. Frequent paths are not necessarily desirable paths, and temporal order alone does not establish causation or hierarchical goal structure. Use computational patterns to direct inquiry, then construct and check the HTA.

Before using real recordings with any service, check the agreed data handling and the service’s processing arrangements. Use fictional records for classroom demonstrations. A vendor statement about local processing is not a substitute for checking the actual workflow. Keep access to raw recordings controlled while making the analytical reasoning traceable to authorized reviewers.

Scenarios, personas and participation

A scenario tells a concrete episode: a person, goal, context, actions and outcome. It is easy to follow because it selects one path through time. That strength is also a limit: one story cannot display every branch, exception or parallel activity. Dix and colleagues use scenarios to communicate behavior and to examine other models; a task hierarchy complements rather than replaces a narrative. [R7]

Our scenario is a student seeking a specified edition, moving from catalogue to shelf, then asking staff for help. An essential use case can abstract away the particular buttons: identify the needed item, establish acceptable alternatives, locate an obtainable copy and arrange access. Separate the user’s intention from the system’s responsibility before committing to a screen sequence.

A persona summarizes relevant patterns in research; a name and photograph can make it memorable but do not make it evidence. Explain which needs, behaviors and constraints support the representation. Avoid adding a fictional family biography or age-based stereotype that contributes nothing to a decision. Several people can share a need for continuity across locations while differing greatly in age and occupation.

An AI-generated persona can be used as an explicitly labeled hypothesis or a prompt for considering a missing perspective. It is not an interviewed participant, and generated quotes are not research evidence. Use it to formulate questions that can be checked, not to manufacture support for a preferred feature.

Participation can go beyond answering questions. People may help interpret materials, propose changes, evaluate alternatives or influence priorities. An expert consultant supplies valuable knowledge, but consultation does not automatically distribute decision-making power. State which decisions participants can affect and make disagreements visible rather than claiming universal agreement.

Cultural probes offer a further approach to eliciting personally meaningful material and stimulating design reflection. They should not be treated as interchangeable with a standardized diary or a representative survey. They offer a different kind of design input; distinguish their exploratory purpose from the explicit observations and reports used in the library case. [R7]

Workflows across people and artifacts

An individual task tree does not fully represent work distributed across roles. A missing-item inquiry can involve a student, a service desk, shelving staff and a catalogue record. Information may wait, change ownership or be returned for clarification. A workflow makes these handoffs and conditions visible.

In the travel example, a request passes through funds checking and approval before travel and expense processing. A missing or rejected condition changes the route. Translating it into a website without understanding the roles could merely accelerate submission while leaving the actual delay in approval unchanged.

For each handoff, ask who sends what, who receives it, how completion is recognized and what happens when information is incomplete. A status such as “submitted” may mean success to the sender but only the start of work for the recipient. Status terminology should reflect the shared process rather than only one screen’s event.

Task analysis: goals, actions and plans

Task analysis describes what people do to accomplish goals and how the work is organized. It can include physical, cognitive and communication activity. Walking to a shelf, deciding between editions and asking a librarian are different demands within one borrowing episode. A model limited to clicks would miss much of that work.

A goal states the intended result. A task identifies work toward that result. Subtasks decompose it into useful parts. A plan specifies ordering, conditions, choices or repetition. A hierarchy shows decomposition; its branches do not automatically prescribe a left-to-right execution order. This distinction is central to hierarchical task analysis. [R3]

Choose the level of detail for the question. “Use the library” is too broad to explain loss of item information. Modeling every finger movement is unnecessary for that question. Stop decomposition when the model supports the intended analysis, and revisit the boundary when an important exception cannot be represented.

1. Goal 0: Borrow a book from the library.
   1. Go to the library.
   2. Find the required book.
   3. Retrieve the book from the shelf.
   4. Take the book to the counter.

The top-level plan allows 1–3–4 when the location is already known; if the book is not at the expected shelf, it uses 2–3–4. Under task 2, the model identifies 2.1 access catalogue, 2.2 access search screen, 2.3 enter search criteria, 2.4 identify the required book and 2.5 note its location. Plan 2 uses 2.1–2.4–2.5 when the available information identifies the book. If it does not, the search route is 2.2–2.3–2.4–2.5. The plan therefore distinguishes using already available information from performing an additional search.

The model deliberately abstracts some work. Taking a book to the counter is not a complete description of authorization, checkout or every access need. A task model can be useful without being exhaustive. Make its assumptions visible before extending it; an omitted branch is not evidence that the situation never happens.

Extending the model using evidence

A proposed extension adds task 5, “Resolve unavailable or missing item,” after an unsuccessful retrieval attempt. Possible subtasks include retaining item identity, checking alternative locations or copies, contacting staff and choosing to wait, substitute or stop. These are candidate activities to investigate; they are not all observed in the six-record teaching episode.

A plan can state: attempt retrieval; if the item is found, continue to checkout; otherwise preserve the selected record and enter the recovery task. Within recovery, the next action depends on constraints and staff procedure. This expresses a condition rather than pretending that every person follows one linear path.

Do not treat the current procedure as the only possible future procedure. MIT’s teaching example of a paper manual illustrates the danger: observing page turning does not imply that digital design should optimize page turning rather than support effective search. Conversely, its dental-billing example shows useful handwritten annotations being lost when a formal digital system omits them. Both the burdens and the valuable informal practices must be understood. [R8]

For the library, copying information into a phone is a current action. The underlying need may be continuity of item information. A design might support that need without requiring manual copying. Evaluate alternatives against the goal and context, not their resemblance to the existing sequence.

Building and checking a digital task model

The following model was entered into ErgoSphere using the library example. It is a simplified proposed model for discussion, with its own numbering; it is not a transcription of the historical “Borrow a book” diagram in the core task-analysis section. It combines observed activities with a proposed recovery structure. Task 4 marks the intended borrowing outcome, whose detailed procedure is outside the six records.

Several modeling decisions remain open. Does “recovered” mean physically locating the specified edition, and who confirms it? Can staff investigation finish later? Can the student stop at any point? Is retaining information a distinct task or a condition that should hold throughout recovery? The diagram makes these questions easier to discuss; it does not answer them.

The hands-on trial confirmed that child and sibling tasks could be added, numbers were assigned, plan text could be entered and a PNG could be downloaded. The exported image shows plan markers rather than their full text. Therefore the image alone is an incomplete record of this HTA: preserve the plans, evidence mapping and version information separately. This trial did not establish automatic plan validation, simulation, collaborative editing or reliable recovery of an editable project after closing the browser.

Use AI to propose, then inspect against evidence

An AI assistant can help turn a long transcript into candidate goal/action statements, suggest alternative decompositions, locate apparent contradictions or draft questions about a missing branch. These are analytical suggestions. A fluent sequence can silently introduce actions that nobody performed, mistake an interview report for observation, or turn a proposed feature into a description of current work.

A bounded prompt makes the distinction explicit. Supply the E1–E6 records from the worked observation record, then ask:

Using only E1–E6, propose a preliminary task hierarchy for the library episode. For each element, provide its task identifier, parent, description, supporting record identifiers, evidence type and uncertainty. Separate observed activity from participant reports and proposed design support. Draft plans only where order or conditions are supported; label other plan elements as hypotheses. List unresolved questions. Do not invent checkout steps, participant quotations, timing, reservation policy or a successful outcome.

Even this prompt is not a guarantee. Check every claimed link by returning to the underlying record; in a real study, use transcript lines or recording timestamps rather than a summary alone. A citation to E6 does not support everything said about staff: it supports the particular action recorded there. Retain the input scope, model/version where available, prompt, raw response and analyst corrections so the transformation can be reviewed.

A second check concerns omitted alternatives. A model may contain only the successful route because it is easier to describe. Walk through “found,” “not found,” “staff unavailable” and “request unresolved” cases. Distinguish a hypothetical stress test from an observed event. Ask a participant or knowledgeable practitioner to explain whether the proposed plans correspond to actual work; revise the model when they do not.

Preserve the task tree, explicit plans, evidence links and unresolved questions together. Their connection makes the model reviewable as your understanding changes.

Evidence to design requirements

A requirement should express a justified capability or constraint. Keep the reasoning chain visible: evidence, interpretation, need, proposed response and an observable check. The links are judgments that can be questioned; they are not automatic deductions from a quote.

Distinguish need from solution. “Support continuity of item identity” leaves several designs possible. “Add a blue floating button” is an implementation choice requiring further justification. Conversely, a requirement so broad that every design satisfies it—“make the system intuitive”—does not provide a useful basis for evaluation.

Acceptance criteria define what would count as satisfying the requirement. Specify task, conditions and observable outcome. If a performance threshold is needed, justify it through baseline evidence, stakeholder decisions or relevant constraints. Do not invent a target percentage and present it as an established standard.

Requirements can conflict. A persistent summary supports memory but consumes screen space. A detailed missing-item report may help staff while burdening a student. Prioritize using consequences, frequency where evidence supports it, severity, feasibility and dependencies. A frequent inconvenience is not automatically more important than a rarer failure with substantial consequences.

Track changes to the chain. If additional inquiry shows that item identity is already preserved but the student cannot find it, the problem may concern visibility rather than persistence. Updating a requirement after new evidence is a normal part of design, not a failure of the original inquiry.

From task models to interface design

An HTA helps you understand how activities contribute to a goal and under what conditions they occur. It does not prescribe the interface that should support them. One task may involve several screens, several tasks may share one screen, and some tasks may take place away from technology altogether. The design problem is to use the model and research evidence to reason about better support for the activity.

The progression is iterative: interpret the evidence and task model, identify opportunities, allocate responsibilities, explore interaction concepts, prototype, evaluate and revise. New findings can send you back to an earlier decision. A prototype may reveal a missing exception in the HTA, while further observation may show that a proposed feature addresses the wrong problem.

1. Interpret the current work before changing it

Start by reading the task model alongside the observation records. Where do people lose information, repeat effort, wait for someone else or recover from a breakdown? Which actions are necessary to the goal, and which arise from limitations of the current arrangement? Preserve useful strategies as well as identifying difficulties.

In our library case, E1, E4 and E6 suggest a possible difficulty in carrying item information from selection to shelf searching and staff assistance. They do not prove that memory is the problem or that the catalogue contains incorrect information. The phone note may be a successful adaptation. A useful design question is: “How could you help someone retain the selected item context while seeking assistance?” This question allows multiple answers.

Keep the descriptive model of current work separate from a proposed model of future work. If your design removes repeated title entry, the future task sequence should reflect that change. Do not preserve an unnecessary action merely because it appears in the original HTA, or quietly present your redesigned sequence as something you observed.

2. Decide what should change and who should do it

Consider changes at the level of the activity before choosing controls. Better shelf signage, a portable item summary, a clearer staff-help procedure or improved catalogue status could address different causes of the difficulty. Some opportunities concern service organization rather than interface layout. Investigate which cause matters before selecting a response.

Allocate responsibilities explicitly. The person selects an appropriate edition and decides whether to seek help. The interface can retain and display the selected record. Staff may investigate the physical location. A system should not silently substitute an edition merely because that is easy to automate. E3 makes the edition constraint relevant, while the available records establish neither permission nor policy for automatic reservation.

These rows connect evidence to decisions and questions. They are not instructions to create one button per task. Several decisions might be supported by the same persistent item summary, while the staff investigation may require a separate service workflow.

3. Explore alternative interaction concepts

Develop at least two plausible ways to support the goal before committing to a layout. Describe each as a short scenario: what the person is trying to accomplish, what information remains available, what they do next, and how the service responds. Then sketch enough of the interface to expose the differences.

These are schematic, non-interactive wireframes for comparing concepts. The wording and controls are provisional, and no electronic request service is assumed to exist. Both concepts could support the same HTA. Choosing between them requires evidence about visibility, task continuity, available devices and the real assistance workflow—not a preference for the more polished drawing.

4. Specify states and transitions, then prototype

A picture of the successful screen is insufficient. Define what information the interface holds, what actions are available, and what changes after each action. In this case, distinguish an item being selected, an unsuccessful shelf search, assistance being consulted, a request being submitted if that service exists, and an item being physically recovered. “Request submitted” must not imply “book found.”

For each transition, ask what triggers it, what must already be true, what information persists and what feedback confirms the result. Include cancellation, returning to the item, changing the selected edition and assistance being unavailable. If a person changes the item after starting a request, the interface must make clear which item the request concerns. These details develop the interaction concept rather than mechanically reproducing the hierarchy.

Choose prototype fidelity according to the uncertainty. Paper or linked wireframes can reveal whether a person notices assistance and understands the route. A working prototype may be needed to examine persistence across navigation or devices. Simulate staff responses only when the study makes that simulation clear; a prototype cannot establish that an unimplemented service will operate as promised.

5. Walk through the design and evaluate with people

First perform an analyst walkthrough using the HTA plans and explicit hypothetical exceptions. Follow the normal route, the missing-item route and the unresolved route. At each step, inspect whether the necessary information and actions are available, whether the next action is discoverable, and whether the result is understandable. This checks the design against the model; it does not establish usability with actual users.

Then evaluate with appropriate participants. Give a goal and situation without naming the control you want them to use: “You need this edition, but you could not find it at the listed shelf. Use the prototype to decide what to do next.” Observe whether they retain the correct item, find assistance, understand its status and recover from wrong turns. Asking “Click the help button” would conceal a discoverability problem.

Compare the alternatives against the same goals and conditions. For a formative comparison, inspect the reasons for confusion and successful recovery, not simply which design participants say they prefer. If you make quantitative comparative claims, plan sampling, measures and order effects appropriately. The schematic concepts above have not been evaluated and carry no performance claims.

6. Revise the design and the model

Suppose a participant retains the item successfully but interprets “available” as a guarantee that it is on the shelf. That finding would shift attention toward status meaning and uncertainty. Suppose staff explain that investigation is asynchronous. The future task model would need waiting, notification and unresolved-outcome handling. In either case, update the evidence ledger, the requirement and the relevant prototype states together.

Maintain traceability without treating it as proof: a design decision should point to the need it addresses, the supporting records and the remaining uncertainty. Several designs may meet the same need. Record why you chose one, what tradeoff you accepted and what evidence would cause you to reconsider.

Where tools and AI fit

HTA editors help maintain task structure; diagramming and prototyping tools help explore interaction flows and screens. AI-assisted wireframing can produce editable candidates from a brief. For example, Figma documents prompt-based generation of draft wireframes and designs. This is assistance with making alternatives, not verification that a design satisfies the research evidence. Figma First Draft documentation.

A useful generation brief includes the goal, relevant evidence, constraints, human and system responsibilities, required states and unresolved questions. For this case, request two alternatives that retain title, edition and location during recovery; explicitly prohibit invented reservation policies or claims that staff assistance is instantaneous. Inspect the output for unsupported features, missing branches and inaccessible interactions before using it in a study.

Model-based UI engineering offers a more formal account of successive transformations from task and domain models through abstract interaction structures to concrete interfaces and implementations. The W3C introduction is a historical conceptual reference, not evidence of a current turnkey converter for the HTA tool used here. W3C: Introduction to Model-Based User Interfaces.

The outcome of this process is a justified design proposal with explicit alternatives, a prototype and questions that can be evaluated. The HTA remains a revisable account of work that informs those decisions.

What the inquiry should leave behind

The useful outcome is a defensible account of people and work: who was studied, which goals and conditions mattered, what was recorded, how it was interpreted, and why a proposed change follows. A list of methods or a polished persona alone does not supply that account.

Research artifacts should support decisions while preserving uncertainty. Keep evidence distinguishable from reports and interpretation; keep task models distinguishable from implementation; keep requirements distinguishable from untested design ideas. The next lecture can then explore interaction structure and interface alternatives against an explicit understanding of the task.

For the library case, the central design question is no longer simply “How can search look better?” It is how people identify suitable material, carry information across contexts, recover when location fails and coordinate with others. That richer question is the practical contribution of user research.