Much of my work has involved making complicated systems usable. With CourtAhead, I’m working on that problem for people representing themselves in California family court. The product question I keep returning to is simple: when someone opens the software, can they understand where they are and what needs their attention?

A folder of documents is useful. A timeline can be useful. Neither automatically explains what a person is looking at, which details are uncertain, or what they need to check before moving forward. Those connections are the work.

CourtAhead is still being built. These are the design principles guiding my work, rather than a list of capabilities available today.

Start with the moment someone gets stuck

Consider a simple design scenario: someone receives a document they do not understand. They can read the words, but they do not know how it connects to the papers they already have. They may also be unsure whether a date matters or whether something is missing.

Starting with a dashboard encourages a team to ask which information deserves a card. Starting with this moment leads to different questions. What is this document? What does the person already know? Which question can the product help them resolve first?

I want the first interaction to create a manageable starting point. A useful screen should help someone make progress even when they cannot yet explain the whole problem.

Keep the explanation close to the record

A summary is easier to read than a stack of papers, but it also creates distance from the original. If the summary leaves something out or misreads a detail, the reader needs a practical way to notice.

My design preference is to keep an explanation connected to the material behind it. A person should be able to move from a statement to the relevant passage, understand what it supports, and flag something that needs checking. A source link is most useful at the point where a question occurs.

This also affects how I think about AI. Fluent text can make incomplete information feel settled. The surrounding product needs to show which parts came from a record, which parts the person supplied, and which parts remain unresolved.

Make uncertainty useful

“Not confirmed” should help someone understand what is missing. A useful explanation names the open question, shows why it matters to the result, and gives the person somewhere to go next.

For example, a product may have a date without knowing what that date represents. Presenting it confidently on a timeline would make the screen look more complete while leaving the underlying question unanswered. I would rather show the gap and ask for clarification.

That choice takes discipline. Teams like complete screens. Users need an accurate picture of what the system knows.

Give progress a precise name

Words such as “done” can hide several different states. A draft might be saved, reviewed, or sent. Those are distinct events, and the interface should name the event it can actually establish.

This is a principle I carry across product work. A successful save tells us the software stored something. It says nothing about what happened outside the software. Status labels need to stay within that boundary.

Clear language helps people return after an interruption, too. They should be able to see what happened, what they were working on, and what is still open without reconstructing the last session from memory.

Measure the next step

The test I want to apply is practical: after using a screen, can a person explain their situation more clearly? Can they find the record behind a statement? Do they know what still needs checking? Can they leave and come back without losing their place?

Those questions give me a more useful design target than the number of features on the page. They keep the work focused on helping someone move forward with understanding and control.

Learn about CourtAhead, or read more about my approach to building tools for experts and AI in production.