Designing an AI product for the next step

I founded CourtAhead around a difficult product question: how can software help somebody understand a complicated, changing situation without pretending that uncertain information is settled or taking consequential decisions away from the person?

CourtAhead is in early development. This essay discusses the public product principles informing my work, not its unpublished architecture, workflow, roadmap, or available feature list.

The question is relevant far beyond legal technology. In any high-stakes product, the difficult part is rarely generating more information. It is deciding what the product should make clear, what it can responsibly infer, what the person still needs to decide, and how the experience should change when new information arrives.

Start with the decision, not the dashboard

Complex products often begin as dashboards. Dashboards are reassuring because they turn complexity into boxes: activity, dates, messages, tasks, and status. The screen can look organized before the team has decided what the product is actually responsible for.

I prefer to start with the moment somebody gets stuck. What decision are they trying to make? What changed? What information could affect the choice? What remains unknown? Which part can software prepare, and which part needs human judgment?

Those questions reveal whether a proposed feature reduces meaningful uncertainty or simply rearranges information. The useful interface is the result of answering them. It is not the starting point.

The state model is part of the product

One of the most important product decisions is defining what each status actually proves. “Done” is rarely precise enough.

A payment can be scheduled, sent, or settled. A job application can be prepared, submitted, or received. An AI output can be generated, checked, or approved. These states sound close to one another, but each represents different evidence and different expectations.

If an interface collapses them, it creates false confidence. If the underlying product model collapses them, the team may later be unable to correct the problem without reconstructing history.

I treat state language as a product contract. Every label should stay within what the system can establish. External events need external confirmation. Unconfirmed states should look and read differently from confirmed ones. A saved draft should never inherit the visual authority of a completed action.

Keep explanations close to their sources

AI can turn a large body of material into fluent prose. Fluency is useful, but it can hide the distance between a statement and the evidence supporting it.

My preference is to keep an explanation connected to its source. A person should be able to understand why the system surfaced a statement, inspect what supports it, and recognize when the source is incomplete or open to another interpretation.

A citation alone does not solve the problem. The surrounding experience has to preserve enough context for the person to judge whether the source actually supports the explanation. The model is only one participant in that chain; the product has to make the chain legible.

Make uncertainty operational

Uncertainty should not be a vague disclaimer added after an answer. It should change what the product does.

If a system finds a date but cannot determine what the date represents, the easiest interface is to place it on a timeline and let the screen look complete. The responsible interface keeps the ambiguity visible, explains why it matters, and asks for the smallest clarification that can resolve it.

I think about uncertain information in four parts:

1. What is observed?The exact source, event, or user statement available to the product.
2. What is inferred?The interpretation the system is proposing rather than treating as fact.
3. What is missing?The information that prevents a stronger conclusion or safe next action.
4. What can resolve it?A source, question, review, or external confirmation that would move the state forward.

This turns “not confirmed” into a useful product state. It gives the person a reason for the uncertainty and a path to reduce it.

Useful AI is more than a good answer

A polished response is easy to demonstrate. It is not enough to prove that an AI product works.

A summary compresses information. A useful product connects the person’s goal to choices, evidence, timing, tradeoffs, and the work that follows. A model can produce a convincing recap while missing the decision the user is actually trying to make. It can be factually accurate and still create the wrong impression through tone, ordering, or visual emphasis.

That is why I separate the quality of the model response from the quality of the product. The response matters, but so do retrieval, context, state, interaction design, authorization, and what happens after the answer appears.

Proactive does not mean autonomous

There is value in software that notices a change and begins useful preparation. It is a mistake to treat that ability as permission to act on a person’s behalf.

Preparation, recommendation, and execution are different levels of authority. The product can reduce the work required to make a decision, but the person should retain control over consequential choices and external actions.

This boundary is not friction to be optimized away. In a high-stakes workflow, deliberate confirmation can be a feature. The design challenge is placing control at the moment it matters without making the person approve every harmless background task.

Evaluate the system and the experience

Teams often evaluate an AI product by reading a good answer. That tests model output, not the complete experience.

I separate several questions:

• Did the system retrieve the right material?
• Did it preserve important qualifications and conflicting information?
• Did the explanation stay within what the sources support?
• Did the interface show the result with the right degree of confidence?
• Did the person understand the decision and what still needed checking?
• Did the product preserve an accurate state when the situation changed?

A technically accurate extraction can be useless if it appears too far from the decision it should inform. A careful recommendation can lose its value if the user cannot return later and understand what changed. The product leader has to evaluate the chain, not just the sentence.

Measure whether the person can move forward

Feature usage alone cannot tell me whether this kind of product works. Opening a document, generating an explanation, or completing a setup step may be necessary, but each is only a proxy.

The more useful questions are behavioral and comprehension-based. Can the person explain the situation more clearly? Can they identify the source behind an important statement? Do they understand which facts are established and which still need checking? Can they compare choices without losing the tradeoffs? Can they return after an interruption and understand what changed?

The goal is not a screen that looks certain. The goal is a person who knows enough to make the next decision with greater understanding and control.

The product leader owns the connections

Building a trustworthy AI product crosses research, interaction design, data modeling, evaluation, security, operations, and language. Each discipline can solve its own part correctly while the overall experience still fails.

The product leader’s job is to own the connections. Does the state model support the promise in the interface? Does the system preserve the evidence the explanation needs? Does the language match what the product can prove? Does preparation stop at the authorization boundary? Does evaluation measure the user’s outcome rather than the novelty of the model?

This is the work I find most valuable: turning a complicated domain into a clear product model, making that model visible through interaction, and giving the technology enough structure to behave responsibly.

Designing for the next step does not mean predicting everything that will happen. It means helping the person see the current situation, the available choices, the supporting information, and the unresolved questions—then preserving that understanding as the situation changes.

Continue reading

Learn about CourtAhead. For the broader AI operating principles behind this work, read AI that survives contact with production. For my approach to capable professional software, read Building tools for experts.