The question-driven experience

You explain the situation. Software helps uncover the choices. #

You should not have to know every hidden requirement or write the perfect prompt before asking for help. People can describe what they are trying to do in ordinary language. Software should help notice the assumptions, ask useful questions and make the consequences understandable.

That is the question-driven experience we are building: help discovering the decisions, with people retaining control over the answers.

Start with a situation you can recognize #

Imagine a gathering where friends choose what to bring. Avery's household offers to bring dessert. Jordan's household wants to bring dessert too.

Should only one household bring dessert, or may several?

Neither answer is automatically right. One household may be enough for a small gathering. Several may suit a larger one. The question matters because the choice changes what happens next.

If you choose one household, the first accepted offer holds the place. Another household can choose something else or wait until it opens again. If you allow several, both households can bring dessert. Showing those consequences helps you choose the behavior you actually want.

The interactive example on this page lets you try both answers. It changes only the example here; it does not change a real gathering or contact anyone.

Try the cases that could change your mind #

A useful question goes beyond the easiest case. What if the first household cancels? Should the place become available again? What if this is a large family gathering and several desserts are welcome?

Those cases can reveal that an apparently simple rule needs another choice. The goal is to make overlooked decisions visible before an agent quietly fills them in.

An answer should also have a clear reach. A choice for this gathering should not silently become your preference for every future gathering. Permission for one exception should not quietly become an ongoing rule.

Make room for “That is not what I meant” #

Sometimes the offered answers miss your intention. You might want a waiting list, or a different arrangement nobody has asked about yet. You should be able to explain that in your own words.

A clarification needs to remain visible as an unresolved need until the behavior is understood and supported. Recording what you want is different from making it work. A confident interpretation should not hide that difference.

If a new answer conflicts with an earlier choice, the software should show both meanings and let you decide whether to keep the original or change it. Your explicit answer should not be quietly replaced by a prediction.

Confirm the choices that matter #

Useful questions should show the relevant details before you decide: what may happen, whose information is involved and who may receive it. Preparing a choice, committing to it and paying for it need distinct permission.

An agent can help explain an option, but its suggestion is not your approval. If important details change after you decide, the software should ask again rather than treat an earlier yes as permission for a different action.

Personal Programming Interfaces carry these choices into the wider vision. The ghost browser experience shows how focused agent help and private human decisions fit together. Privacy boundaries explains the information limits to understand before supplying private details.