Designing AI experiences for latency, trust, and messy input

A football video arrives with the phone tilted against a bag. The player moves near the edge of the frame, and someone walks behind them. A dictated note has a false start, a person’s name, and a sentence that moves from Hindi to English halfway through.

These are normal inputs for products such as AIM Football, which analyses smartphone video, and MemoFlow, which handles Hindi and Hinglish speech locally. ^{[1] [2]} The clean sample we use in a demo is useful for proving that the model works. It tells us much less about whether someone can rely on the finished product.

I’ve learned to treat latency, trust, and messy input as one design problem. A difficult input can take longer to process. An unexplained wait makes the result feel less dependable. If that result arrives with more confidence than it deserves, one imperfect input can damage trust in the whole experience.

Waiting needs an honest state

When someone taps upload or stops a recording, they first need to know that the product received it. A spinner can show activity, but it can’t answer whether the work is safely saved, still queued, being processed, or stuck.

I prefer a small set of states that correspond to something real in the system. “Video received” should mean the upload is safe. “Analysing” should mean work has started. If a retry is happening, the status should survive a closed screen and still make sense when the person returns.

Precise progress can be worse than a broad state when the product can’t predict the remaining time. A progress bar that races to ninety percent and stays there teaches people that its numbers are decorative. For longer work, I’d rather show what has happened, whether the person can leave, and how they will know when the result is ready.

Short interactions need a different response. During dictation, uncertainty begins almost immediately if no text or recording feedback appears. The timing has to match the task, an idea that also appears in Microsoft’s human-AI interaction guidelines. ^[3]

Trust comes from useful evidence

Confidence is tempting to reduce to a percentage. Most people can’t do much with “73% confident,” especially when they don’t know which part of the result is uncertain or what would improve it.

The explanation should fit the decision. If a football movement can’t be assessed because the player left the frame, say that and show where the problem happened. If a transcript is unsure about a name, make the word easy to inspect and correct. That is more useful than presenting a score with no next action.

The result also needs a clear boundary. An observation, such as what the system detected in a recording, is different from a suggestion about what to practise next. Showing that difference helps a player or coach decide how much weight to give each part.

Google’s PAIR guidance describes trust as something to calibrate, including the risk of people trusting a system too little or too much. It recommends explanations that help someone understand capabilities and limits, with more detail where a decision carries higher stakes. ^[4]I find that framing more useful than trying to make every AI output sound certain.

Messy input is part of the product

It’s easy to call a dim video or a noisy recording “bad input.” The person may have followed every instruction they noticed. If the same problem keeps appearing, the capture experience probably needs to do more.

Some checks are useful before expensive processing begins. Is the recording long enough? Can the player be seen? Did the microphone capture anything? A specific prompt while the person can still fix the problem saves more time than a generic failure after a long wait.

Other problems only become clear during analysis. A person may move out of view for part of a drill. Speech may contain an unfamiliar name, an acronym, or a language switch the model handles unevenly. The product should preserve the useful parts and ask for correction where it needs help. Making someone begin again should be the last recovery option.

This changes how I think about validation. Strict validation can make the model’s job easier while making the product frustrating. Loose validation can accept anything and waste someone’s time before failing. The better boundary depends on whether the system can produce a useful partial result and explain what is missing.

Correction should be cheaper than repetition

When an AI result is wrong, people need a path forward. Microsoft’s guidelines call for efficient correction, and PAIR’s guidance asks whether users can continue after a failure. ^{[3] [5]} That path should be designed with the main flow, since probabilistic systems will eventually need it.

In a transcript, correction may be editing one word while keeping the audio and the rest of the text. In video analysis, the useful response may be retrying a failed stage, asking for a short replacement clip, or letting a coach disregard one uncertain observation. The right option depends on what can be recovered safely.

A friendly error message won’t compensate for losing the original work. If the upload completed, the product should avoid asking for it again because a later step failed. If a person edits the output, their edit should remain visible and shouldn’t be silently replaced by another model run.

The interface depends on the system underneath

A useful waiting state needs more than animation. The product must have a lasting record of the job and know which stage completed. A retry needs an identity so it doesn’t create two conflicting results. Cancellation needs to reach work that may be running somewhere else.

The same is true for explanations. If we want to say that a player left the frame, the processing pipeline must retain enough evidence to support that message. If we want a person to correct one uncertain word, the system needs word-level information and a way to preserve the correction.

These are product requirements that shape architecture and model evaluation. Adding them near the end usually produces vague statuses and generic error messages because the system never kept the information the interface now needs.

Measure the route to a usable result

Average model latency is useful for capacity planning, but it can hide the experience we need to improve. I want to measure the time to the first trustworthy confirmation, the time until a result can be used, and how often people have to correct, retry, or abandon the task.

I’d also review those outcomes across the inputs the product actually receives. For speech, that includes accents, background sound, names, and language switching. For video, it includes different phones, lighting, framing, and movement near the edge of the camera. Privacy limits still apply to how examples are collected and reviewed.

A strong AI experience gives someone three clear answers: did you receive my input, what is happening now, and what can I do if the result is wrong? When those answers stay clear on messy inputs and slow days, the model has a chance to become a dependable product.