Recommended resources
The freely available resources this lesson will direct you to.
Hello, and welcome to the first lesson. This course follows an enterprise knowledge-assistant project from an initial client brief through design, implementation, evaluation, deployment, and a client presentation. We begin where a consulting team should begin: understanding the problem before committing to a solution.
By the end of this lesson, you should be able to read a brief and extract user roles, pain points, constraints, and assumptions without treating every client statement as a verified fact. That distinction will give the rest of the project a sound foundation.
A brief is a starting point, not a specification
A client might open with, “We need an AI chatbot for our staff.” That tells you what someone wants to build, but not yet who struggles, what they are trying to accomplish, or whether a chatbot would solve the problem. The first move is to restate the request as an outcome to investigate: Staff need a reliable way to find and use the right guidance while handling a case.
The UK Government Service Manual makes this distinction in its guidance on discovery. Although its setting is public services, the principle applies equally to an enterprise client brief.
How the discovery phase works - Service Manual
Read the UK Government Service Manual’s “How the discovery phase works” to see why a proposed solution should be interrogated before it becomes a project commitment.
Under “Define the problem,” read the problem framing. Begin with the paragraph about being given a pre-defined solution and stop after the paragraph about understanding the current cost of the problem. Notice how the contact-centre example separates a requested feature from the underlying need.
Consider this fictional client brief, which we will use throughout the lesson:
Harborline Services wants a GenAI chat assistant on Google Cloud by the end of the quarter. Support agents search a shared drive for current returns guidance and message policy specialists when two documents disagree. A support lead says agents sometimes copy outdated PDF text into customer replies; she estimates that finding guidance takes about 12 minutes per case, but no timings have been collected. Policy specialists publish approved updates weekly, while older files remain in shared folders. IT says some documents are restricted to specialist teams. The sponsor believes citations will make agents trust answers and expects chat to appear in the existing case-management screen. Security says sensitive case details must not go to an unapproved service, but the relevant policy and approved-service list have not been supplied. The service lead wants fewer escalations. Someone has suggested Spanish-language answers, though agents have not been asked about them.
There is useful information here, but it comes in different forms. “Support agents search a shared drive” describes a reported activity. “Sometimes copy outdated text” is a reported pain point. “Citations will make agents trust answers” is a prediction. “Build a GenAI chat assistant” is a proposed solution. Keeping those forms separate prevents a persuasive brief from becoming an unquestioned design.
Identify roles by what people do
A user role is a group of people distinguished by its goal or responsibility in the situation—not necessarily a job title or a future software permission. Ask who needs information, who creates or checks it, who supports the work, and who sets conditions on the project.
In Harborline’s brief, support agents are the likely primary users: they seek guidance while answering cases. Policy specialists publish updates and answer questions when documents conflict. A support lead reports difficulties and may help arrange research; the sponsor and service lead express desired outcomes. IT and security appear to set or clarify conditions. These roles matter, but they do not all have the same need. Nor can we assume that customers will use the proposed assistant: the brief describes an internal tool.
The Service Manual’s user-research guidance is useful here because it asks you to look beyond the most obvious user and distinguish evidence from second-hand opinion.
Learning about users and their needs - Service Manual
Read “Learning about users and their needs” from the UK Government Service Manual for a practical account of whom to research and how to describe a need without prescribing a feature.
Under “Researching users and their needs,” start at “When to research” and read the discovery guidance, ending after the advice about opinions from non-users. Then read from “Who to research with,” through “Writing user needs,” and into “Validating user needs”: the needs guidance. Focus on the difference between a user’s goal and someone else’s idea for meeting it.
For Harborline, a provisional agent need might be: “When answering a returns case, I need to find the currently approved guidance so that I can give the customer an accurate answer.” It is provisional because we have not heard an agent describe the need or observed the work. It also avoids embedding “chat,” “citations,” or a particular model in the need itself.
A pain point is friction or a poor outcome in that work. Record what happens and why it matters, rather than replacing it with a feature request. Searching multiple files and finding conflicting guidance may delay a reply; using outdated text may produce an incorrect one. The brief reports both, but it does not establish how often they occur, their root cause, or their cost. Those are questions to investigate, not gaps to fill with guesses.
Extract constraints without treating every preference as immovable
A constraint limits what a workable solution can do or how the team can deliver it. Common sources include policy, contracts, existing systems, access rules, time, and operational processes. A brief may state a constraint clearly while leaving its exact meaning—or even its authority—unconfirmed.
How the discovery phase works - Service Manual
Return to “How the discovery phase works” for its distinction between hard constraints and processes that might be changed.
In “Understanding constraints,” begin just after the opening sentence that introduces constraints and read the constraint discussion. Stop after the paragraph about testing whether an existing process can change. Pay particular attention to why a current way of working should not automatically be treated as permanent.
Harborline’s reported document restrictions are an access constraint to investigate: which documents are restricted, to whom, and where are those rules recorded? Security’s instruction about sensitive case details is a stated restriction; the team still needs the policy and approved-service list before deciding what data may go where.
“On Google Cloud” and “by the end of the quarter” are also stated project conditions, but their flexibility is unknown. The existing case-management screen may be a requirement, a strong preference, or merely the sponsor’s expectation. Record that uncertainty rather than silently calling all three “hard constraints.”
This is an important consulting habit: respect a stated constraint while verifying its scope and source. You should not ignore security’s warning because documentation is missing; equally, you should not invent a complete security policy from one sentence.
Make assumptions and unknowns visible
An assumption is a claim the team is relying on without sufficient evidence. A related open question is something the team knows it does not yet know. Both can affect scope, design, and whether the project delivers value.
The CSD matrix below offers a way to sort statements into certainties, suppositions, and doubts. Its dog-training example is unrelated to Harborline, but its structure is useful: it makes the team’s confidence visible instead of mixing all its notes together.
For example, the sponsor’s belief that citations will create trust belongs among suppositions until agents have been consulted. The suggested need for Spanish-language answers is also untested. “Which services are approved for sensitive case details?” is a doubt with an identifiable source of clarification. Even a “certainty” should carry its source: the brief says policy specialists publish weekly is safer than all guidance is reliably updated weekly. Publication and removal of obsolete copies are different matters.
To turn these notes into productive conversations, prepare questions about who performs the work, what triggers it, where information comes from, when delays occur, and what happens if something goes wrong.
Requirements Elicitation – What Questions to Ask
Watch “Requirements Elicitation – What Questions to Ask” from Bridging the Gap – Resources for Business Analysts for a way to prepare follow-up questions from an initial account.
Watch question categories for prompts about how, where, what, when, who, and why. Then watch probing the problem for ways to ask about underlying reasons and consequences without making the conversation feel like an interrogation. As you watch, consider what you would ask an agent who encounters two conflicting policy documents.
A useful follow-up is specific enough to test a claim but open enough to reveal surprises: “Can you show me the last case where two guidance documents disagreed, and what you did next?” For the timing claim, you might ask how “12 minutes” was estimated and whether case records or observation could establish a baseline.
Turn the brief into a traceable extraction
Your output at this stage is not a final requirements document. It is a compact record of what the brief says, how you have interpreted it, how confident you are, and what needs checking. Here is a sample drawn from Harborline:
| Extracted item | Category | Status and next check |
|---|---|---|
| Support agents look up returns guidance while handling cases. | User role and task | Reported in the brief; confirm with agents and observe the task. |
| Agents encounter conflicting or outdated documents. | Pain point | Reported by a lead; inspect examples and ask agents how often it occurs. |
| Some documents are restricted to specialist teams. | Constraint | Stated by IT; obtain the access rules and document classifications. |
| Sensitive case details must not reach an unapproved service. | Constraint | Stated by security; obtain the policy and approved-service list. |
| Finding guidance takes about 12 minutes per case. | Assumption about magnitude | Lead’s estimate; establish what is being timed and measure a baseline. |
| Citations will make agents trust answers. | Assumption about a solution | Sponsor’s belief; ask agents what evidence they need to rely on an answer. |
| Spanish-language answers are needed. | Possible user need | Suggested, not researched; establish which users and cases, if any, require them. |
Notice what is not in the table as a proven need: “build chat.” It remains a proposed approach. “Fewer escalations” is a desired business outcome, but the brief does not tell us whether escalations are unnecessary, how many occur, or whether reducing all of them would be safe. Preserve that outcome as a question for later measurement rather than converting it into a claim about today’s performance.
A consistent extraction format lets you review a brief efficiently:
- Name the role and its task. Use the brief’s words where possible; mark roles you infer.
- Describe the friction or consequence. Separate the reported incident from guesses about its frequency or cause.
- Record each constraint with its source and scope. Note what documentation or owner must confirm it.
- List assumptions and open questions. Give each a plausible way to check it, such as an interview, observation, document review, or baseline measurement.
If a statement fits more than one category, retain the distinction. “Old PDFs remain in shared folders” describes a reported condition; “therefore search always returns obsolete answers” is an assumption about its effect. That separation is more valuable than forcing every sentence into exactly one box.
Conclusion
A strong first reading of a client brief does four things: identifies who is involved, describes what makes their work difficult, records what limits the solution, and exposes what has not yet been established. Keep proposed features and desired outcomes visible, but do not mistake them for validated user needs or evidence of a problem’s scale.
In the next lesson, you will use this extraction to map how a target user retrieves knowledge today and how a proposed workflow might change that journey.