FT7 Game: Describe an Operation Problem in Four Clear Fields

Write a useful FT7 Game help question by separating your goal, starting state, exact input and visible response in a worked tutorial example.

“It is not working” may be a completely honest description of frustration, but it leaves the person helping to guess both the task and the failure. For FT7 Game information requests, a useful short description has four fields: goal, current state, input and visible response. We will build one from a hypothetical tutorial problem. The aim is not to write a technical report; it is to include the few details that distinguish this problem from a different one.

Our invented interface has a lesson list and a preview page. The learner wants to open the written explanation for lesson three. They select lesson three, press Continue, see a spinner briefly and return to the list without the explanation opening. These are teaching screens. The example gives enough detail to ask a question while leaving the underlying cause unknown. It does not assume that a spinner proves a request was accepted or that returning to the list proves a particular fault.

Begin with the destination

Field one is the goal: “Open the written explanation for lesson three.” This is more specific than “start,” which might mean opening the app, beginning a demonstration or joining an activity. A good goal names the intended next state. If the explanation was supposed to open as a separate page, that expectation belongs here. If the expectation comes from a tutorial, identify the relevant instruction so the person helping can compare the described flow.

Field two is the current state: “The lesson list is open; lesson three is selected.” The selection matters because pressing Continue before selecting anything would be a different starting condition. Use what is visible: the lesson's label, highlight or selected mark. Do not infer selection merely from having intended to tap it. A short description of the observed state can reveal an important mismatch between the action someone remembers and the state the screen actually shows.

Field three is the input: “I press Continue once.” Name the displayed control rather than saying “the green button,” which may not distinguish it from another control. Include the number of taps if relevant. Pressing twice would be a different input sequence, and a long press might differ from a tap. Avoid adding speculative steps that did not occur. The purpose of this field is to preserve the actual action between the starting state and the response.

Say what appeared, not what you guessed

Field four is the response: “A spinner appears briefly, then the lesson list returns; the written explanation is not shown.” This records the observation without diagnosing it. “The server rejected me” would be a claim about a cause that the visible sequence has not established. If an error message appears, quote its text accurately. If none appears, say that no message was visible during the recorded sequence rather than inventing a likely message from memory.

The complete FT7 Game question can now be short: “I want the written explanation for lesson three. On the lesson list, lesson three is selected. I press Continue once. A spinner appears, then I return to the list without an explanation. Which step or condition should I check?” Each sentence contributes a distinct field. The description still leaves room for the answer to identify a missed requirement instead of insisting in advance that the app must be broken.

Compare a second case: the goal is the same, but no lesson is selected and Continue is visibly inactive. There is no spinner and no page change after the tap. This case should not be merged with the first merely because neither opened the explanation. Its starting state and response differ. The likely next question concerns how selection is indicated, whereas the first case needs the flow after a selected item is continued. Precise descriptions separate these branches early.

If a helper asks for one extra detail, attach it to the relevant field. “Version 2.3” describes the environment; “lesson three loses its selected mark before the tap” revises the starting state; “the spinner lasts two seconds” refines the response. Do not rewrite earlier observations silently. A useful correction says what changed in the account. This lets the conversation develop without making the original and revised versions look like two unexplained reports from different situations.

Our FT7 Game example has become answerable without becoming lengthy. The destination is a written lesson, the starting state includes a selected item, the input is one named tap and the response is a return to the list after a spinner. Even if the cause remains unresolved, the problem is no longer vague. The four fields give the next explanation somewhere concrete to begin, and let the learner recognise whether that explanation actually addresses the sequence they observed.