“Make it easier to use” leaves choices open
Someone finds the search results awkward. You might add highlighting, filters, sorting, or a new layout, but those changes solve different problems. Implementing immediately turns a guess into code, tests, and rework.
Establish who is searching, what they need to find, and where they get stuck. Define what would count as an improvement before comparing solutions.
Restate the goal and assign the questions
Briefly describe the user, goal, and success condition so the requester can correct your understanding. Inspect the code and documentation for facts such as available response fields or existing components. Those are investigation tasks you can do yourself.
Restate my intent before continuing
— Matt Pocock
Ask for decisions in manageable rounds
Suppose the default sort depends on whether the old sorting behavior must remain available. Resolve that prerequisite first. Offer a recommended option with its reason, and explain when an alternative fits. Keep each round focused on choices that can currently be made.
Skip this round for a small, clear change. Ask people for tradeoffs that affect behavior or scope, after investigating the facts available to you.
Prototype questions about experience
Density and interaction flow are difficult to judge from a verbal description alone. Build inexpensive alternatives and ask someone to perform the same task in each.
Record what the person chose, why, and what remains undecided. An agent's preference does not establish agreement. A prototype supplies learning material; it still needs work before it becomes a deliverable.
Exercise: sort the search-page questions
Classify each question below and identify who should answer it. Explain why a question about splitting the interface across pages might require an actual prototype before anyone can make a useful choice.
| Question type | Our example | Who answers? |
|---|---|---|
| Fact | Does the response include tags? | The agent inspects the interface and code |
| Tradeoff | Default to relevance or date? | The user decides, with a reasoned recommendation |
| Experience | Do filters crowd the results? | A person tries prototypes and chooses |
Turn a vague search request into agreed behavior
- Task: give a next action for each question without claiming approval in advance.
- Deliverable: one goal, one unresolved tradeoff, and one prototype comparison task.
- Acceptance: describe what happens after selecting a filter and list remaining questions.
Suggested approach
Inspect the tag field; recommend relevance sorting with a reason; compare a sidebar with collapsible filters. After confirmation, record how selected filters appear, clear, and update results.
What counts as done?
Another collaborator can distinguish confirmed behavior, factual evidence, and open questions. Human choices have recorded reasons. If an unresolved issue could change the central behavior, keep it visibly unresolved.
Take confirmed results into specs and tickets so the next session can continue the work.
Quick reference
Investigate facts
Read the code and references first.
Ask for tradeoffs
Recommend with reasons and let the person decide.
Try the experience
Record prototype choices before updating the spec.
Sources
Independent, unofficial, noncommercial study notes. This site has no affiliation with or endorsement from Matt Pocock. Referenced works belong to their authors; MIT reuse carries separate copyright and license notices.