Planning basics: frame a problem with AI
Use illustrated notes to separate a user’s difficulty from a proposed feature.
About 15 min readingAs of Oct 2026
By the end of this guide
- Separate facts from hypotheses.
- Write a user-centred problem.
- Compare options against evidence.
Who this is for
- People learning to structure this work with AI
- People who want to check a draft against evidence
What you need
- All cases, records and numbers here are fictional teaching material, not recorded model replies or research findings.
- Paper and a pen are enough. To try a prompt, use an assistant you already have and only the fictional material.
This lesson’s terms, in plain language
Read the short meanings here. Open a term for a fuller explanation and example.
- hypothesis
- An unverified idea that can be investigated through observation or a test.
- user story
- A short description of who needs to do what and why.
Key ideas
Start with a stuck moment
Figure: Three notes pass through a magnifier into one venue-finding problem brief. · AI Ping “Add AI recommendations” sounds like a plan, but whose difficulty would it solve? Use three fictional notes: A says a new reading-group member asked where the next meeting was; B says the venue is at the bottom of the announcement; C says the organiser wants automatic replies.
The cards in the drawing represent these notes. The magnifier asks where each claim came from. The final sheet should describe a difficulty, such as finding the venue, while keeping automatic replies as one possible solution. Moving the venue higher might also help.
Write the person, task and obstacle before requesting ideas. Do not expand one incident into “everyone struggles every week.” The exercise is about accurate framing, not proof of demand.
Keep facts, interpretations and questions apart
A hypothesis is an idea you have not yet established. “The venue is at the bottom” is a supplied fact. “New members stop reading early” is an interpretation. “Where did you stop reading?” is a question that could investigate it.
Use separate columns and attach note IDs to facts. “Could not find the venue” is not “the venue was missing”: those statements suggest different fixes. Leave device, attendance history and delivery method unknown if the notes do not say.
Ask a colleague to trace the columns back to the source. A filled-in document is not necessarily a better document; an honest unknown can prevent an expensive wrong turn.
Write a user story around the outcome
Figure: Read the user story as person → task → destination. · AI Ping A user story describes a person, a need and a goal. For this fictional case: “As a first-time attendee, I want to find the next venue so I can arrive at the right place.” Treat the proposed motivation as unverified.
Read the second drawing as person → task → destination. A chatbot is not required in that chain. An outcome-focused story leaves room for a clearer announcement as well as a conversational interface.
Add an observable acceptance criterion: the announcement shows the next date and venue. “Users are satisfied” needs a separate method of investigation. Do not attach an impressive time or satisfaction target without explaining how it would be measured.
Ask AI for a comparison, not a verdict
Give the assistant a bounded job: separate supported problems from unknowns using notes A–C. No recorded model answer is supplied here. For any generated sentence, identify its supporting note or label it an inference.
Compare moving venue information with answering questions automatically. Both may serve the same outcome, but the second proposal also needs a rule for choosing current information. That is a design responsibility, not a claim about any product’s price.
Ask who updates changed venues and who notices a wrong answer. A recommendation that ignores those responsibilities is incomplete. If missing information prevents a choice, record the missing evidence and the next action.
Example prompt Practice notes: A a new attendee asked for the venue again; B the venue is at the bottom; C the organiser wants automatic replies. Separate facts, hypotheses and questions. Attach A/B/C to facts. Leave unsupported causes unknown.
Try it: a one-page problem brief
Create a brief with five areas: problem, evidence, hypothesis, options and next question. Use the fictional notes throughout. Attach note IDs to evidence and mark untested explanations as hypotheses. Keep both announcement improvements and automatic replies in the comparison.
Ask a reader to trace each claim back to the notes. Explain why you prefer one option and what remains unknown. A single question cannot establish demand across the membership.
Highlight your strongest claim and your most uncertain claim. The first needs evidence; the second needs a next observation. A role-played customer response may help you revise your questions, but it cannot validate real demand.
Common mistakes
- Do not present fictional cases or AI guesses as customer evidence.
- Do not invent deadlines, results or commitments.
- Explain your decision before polishing its presentation.
Practice
Rewrite “All members ignore announcements.”
See a suggested answer
“The attendee in note A asked for the venue again.” Whether they read the announcement or others had the same difficulty remains unknown.
Suggest an option to test without automatic replies.
See a suggested answer
Move the date and venue to the top. If discoverability is the issue, this lets you investigate a simpler option before building a feature.
An AI role-play says it loves the idea. Is demand validated?
See a suggested answer
No. Role-play can help revise a question or mock-up, but it is not observed user behaviour. Investigate how actual participants find the venue.
References
- Learning about users and their needs — GOV.UK
- Writing user stories — GOV.UK
