Sort voice-captured ideas into projects and experiments

Speak the observation that caused the idea: “Three customers asked how to find yesterday’s report.” Then state your interpretation separately: “Maybe the history screen is difficult to navigate.” The first statement can be checked; the second is a hypothesis. Keeping them separate makes later decisions easier.

Use GPT Realtime Assistant’s sessions and projects to organize the material if that matches your workflow. Do not create a project for every possible improvement. A project should represent work you intend to coordinate, not every thought you might someday revisit.

Use four labels. An observation records something that happened. An idea proposes a possibility. A decision records a choice already made by the responsible person. A task describes an accepted next action. An experiment sits between idea and decision: it tests the assumption that matters most.

A suggested prompt is: “Classify these notes as observations, ideas, decisions or possible tasks. Keep my uncertainty words. For each possible task, ask whether I am accepting it before including it in the final action list.” This prevents the assistant from treating brainstorming as authorization.

For the report example, an idea card could say: “Make recent reports easier to find; evidence is three support requests; assumption is that navigation caused the problem.” An experiment could say: “Watch two volunteers try to find a report; note where they hesitate.” Neither version requires committing to a redesign.

An unhelpful output would announce “Redesign report history by Friday,” because neither the solution nor the deadline was agreed. If this happens, ask for the exact statement that justified the commitment. The expected recovery is a question or hypothesis, not an invented project plan.

Two ideas belong together when they help the same user achieve the same outcome. “Find an old report” and “filter report history” may support one project. “Change the app icon” probably does not, even if both concern the same app. Prefer a concrete outcome over broad buckets such as improvements.

Before attaching an idea to a project, ask what decision it could change. If you cannot answer, put it in an uncommitted list. This keeps the active workspace readable. Review only the ideas relevant to current goals, rather than repeatedly summarizing the entire collection.

For each experiment record the question, smallest test, expected signal and result. “Ask whether users like the design” is weak; “Can a participant find the last report without help?” produces an observable result. Label the example as a proposed test until someone has actually performed it.

If voice transcription loses an important term, correct the card before sorting it. When a thought remains ambiguous, retain a short direct quotation and revisit it later. Organization should preserve the original meaning, not make every uncertain thought look ready for execution.