01 / CONTEXT
Describe the decision first.
“We need an application” is a starting point, but it does not explain the decision the application should improve. A more useful description identifies the person, the situation, and the difficulty. For example, a coordinator may spend time comparing inconsistent requests before deciding which need attention.
That description suggests questions about categories, missing information, and review responsibilities. It does not yet establish that a new product is necessary. An improved document, a change to an existing tool, or a small prototype may each deserve consideration.
02 / RELATIONSHIPS
Choose a proportionate way to learn.
A sketch can test whether the sequence makes sense. A clickable prototype can support a conversation about navigation. A limited technical experiment can examine an uncertain connection. Each method answers a different question and leaves other questions open.
For a simple demonstration, use invented information and label simulated behavior. A prototype that appears to submit a request may not have a receiving service. Successful interaction with the demonstration is therefore different from evidence that a production system is ready to operate.
03 / REVIEW
Record what the observation supports.
Before reviewing a concept, write down what would influence the decision. This might be whether the task can be explained, whether a required field is available, or whether a proposed step creates additional work. A useful observation should relate to that question.
Afterward, note the conditions, limitations, and remaining uncertainty. Decide whether the next step is a revision, a deeper investigation, an implementation discussion, or no further work. Keeping the conclusion proportionate to the evidence is more useful than presenting every experiment as a success.