Plan discovery around journeys and decision owners

Learning objective

Plan discovery around stakeholders, user journeys, current process, pain points, and decision owners.

Core idea

For an architect, discovery turns a sponsor’s intended outcome into questions that the right people can answer. Your first deliverable is a discovery plan: which journeys to observe, whose account to challenge, what records to request, and who can settle each consequential decision. A meeting with the budget owner cannot establish how frontline work actually happens.

NIST AI RMF 1.0 provides useful anchors: MAP 1.1 covers intended purpose and deployment context, MAP 1.2 covers interdisciplinary participation, and GOVERN 2.1 covers clear responsibilities and communication. The plan described here is a practical way to apply those outcomes, rather than a prescribed NIST template. It prepares the requirements work in 6.1.2–6.1.4.

How it works

Start with the journey and its end

Select a journey with a visible trigger and an accepted business outcome. “Customer service” is too broad; “a shopper requests a return and receives a valid disposition” lets you identify participants, systems, waiting periods, and exceptions. Include what happens after a generated answer: the customer may still need a warehouse decision or a payment adjustment.

Ask the sponsor what hurts, how that pain is measured, and why resolving it matters. Record the stated baseline and where it came from. A complaint that work is slow can mean long active handling, overnight queueing, or repeated transfers. Those causes imply different investigations. Do not turn the sponsor’s preferred explanation into an observed fact.

Anthropic’s ticket-routing guide begins by examining the existing support approach: service-level rules, existing automation, prioritization, and ambiguous cases. Use those questions in discovery. Understand which decisions the process already makes before proposing where Claude should participate. Anthropic’s “Building effective agents” recommends starting with the simplest solution and increasing complexity only when needed; discovery establishes what that solution must accomplish.

Assign questions to people with knowledge and authority

Create a stakeholder register whose rows connect each role to its knowledge, a discovery activity, and decision authority. Interviewing someone does not make them the approver. A team lead may explain workarounds while a system owner alone can authorize an integration.

For a return journey, a useful register includes these responsibilities:

One person can hold several roles in a small team, but keep the decisions separate. Add affected groups who do not control funding; otherwise a well-funded design can transfer work or harm onto people absent from discovery. Record disagreements in the register with a named escalation owner.

Compare accounts with observed work

Schedule both interviews and workflow observation. Interviews give breadth and explain intent; observation exposes the unofficial spreadsheet, manual check, or cross-team handoff that a verbal description omits. Ask an operator to demonstrate an ordinary case, a troublesome case, and a case completed outside the normal path.

Produce a current-process record with trigger, actor, system, decision, wait, and outcome for each step. Associate each pain point with its location and supporting observation. Preserve differences between sites or shifts instead of averaging them into a fictional universal process. A day-shift demonstration does not establish overnight escalation coverage.

Request a permitted sample of real cases early, with the data owner controlling access and handling. Use the sample to check whether observed journeys reflect the workload. Do not copy sensitive records into an unrestricted discovery document. Record sample provenance and coverage even when the underlying material must remain in a controlled system.

Time-box investigation around consequential unknowns

Give each activity an output and an owner. An interview should settle named questions or identify who can; an observation should produce a checked process record. Reserve a reconciliation session for conflicting accounts. Discovery that only accumulates notes leaves design dependent on the architect’s memory.

Prioritize unknowns that can invalidate scope: an unavailable source, a forbidden action, or an unstaffed handoff. Stop an investigation when its decision has enough support, and keep unresolved conditions explicit. Detailed behavior belongs in 6.1.2; operating limits and access readiness belong in 6.1.3.

Key distinctions and trade-offs

A stakeholder versus a decision owner: A stakeholder contributes knowledge or experiences an effect. A decision owner has authority to accept a requirement or resolve a conflict. You need both participation and authority.

The intended process versus the observed process: Policy explains what should happen. Case observation explains what happens under actual conditions. Differences are findings to resolve, not permission to automate a workaround.

A broader discovery sample costs staff time and delays design. A narrow sample can conceal the condition that makes deployment impossible. Spend investigation time on variation that changes permissions, outcomes, or ownership rather than repeating identical demonstrations.

Architecture / decision scenario

A retailer funds a ten-day discovery for returns across twelve stores. The sponsor proposes spending all ten days with headquarters and building a demo from policy documents. Store managers report that returns take eighteen minutes, while headquarters expects six; the figures measure different steps.

Choose two contrasting stores, including an evening shift, and follow customer journeys from request through accepted disposition. Interview headquarters about policy, observe operators’ checks and waiting, request representative case records, and involve the returns-platform owner and security lead. The process record reveals a nine-minute wait for a supervisor that a faster draft cannot remove.

The sponsor owns outcome priority, the operations director owns staffing and workflow acceptance, and the platform owner owns access approval. The architect uses the final discovery session to reconcile the timing definitions and assign the unresolved supervisor decision. A polished demo is the tempting alternative, but it cannot explain the conflicting baseline or establish who can change the bottleneck within ten days.

Common exam traps

• Treating the sponsor as the only source of requirements.
• Observing one clean journey and assuming every site works that way.
• Recording pain points without locating their causes in the process.
• Confusing consultation with authority to approve a decision.
• Selecting an agent pattern before identifying the work it must improve.

What to remember

Plan around complete user journeys, compare stakeholder accounts with observed cases, and assign authority separately from participation. Finish with a checked current-process record and owned unknowns that requirements discovery can resolve.

Knowledge check

References

• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• Anthropic, Ticket routing
• Anthropic, Building effective agents