Designing an LLM UX for users who cannot see the screen

July 18, 2026 8 min read

When we started building Artume OS, we thought we were building a screen reader replacement. Two years in, we realized we were building something completely different: a UX where there is no visual fallback at all.

That constraint forced us to design for clarity in a way that benefits everyone, not just blind users. Here are the four biggest lessons.

Lesson 1: Latency is the entire UX

A sighted user can scroll a loading spinner. A blind user waiting for a response hears silence. 200ms feels instant; 1.5 seconds feels broken; 3 seconds feels like the computer crashed.

We redesigned every interaction to hit a 400ms p95 target. That meant: streaming TTS word-by-word, partial responses acknowledged with earcons, and explicit "I'm thinking" prompts only when we genuinely need > 800ms.

The same principle applies to voice interfaces in general. If you build an LLM app with voice, your latency budget is half what it would be for a typed interface.

Lesson 2: Confidence must be spoken

A sighted UI shows uncertainty with greyed-out text or warning icons. A voice interface has to verbalize it.

If the LLM is 60% sure about a file lookup result, we say "I think I found it, but I'm not certain — should I open it?" If the LLM is 95% sure, we just say "I found it" and open it.

This kind of confidence communication is increasingly important in any LLM UX — we are all going to be talking to agents more, and "I'm not sure" is information the user needs.

Lesson 3: Confirmations are not optional

When a sighted user clicks "delete" on a file, they see the file disappear. They have visual confirmation. A blind user asking "delete that file" hears nothing after the action — did it work? Did it delete the wrong file?

Every destructive action needs explicit verbal confirmation. We made this a hard rule: the assistant always says "I deleted the invoice PDF from Tuesday. Anything else?" after every action that changes state.

This same principle shows up in any high-trust application: financial tools, healthcare, infrastructure. Make state changes loud.

Lesson 4: Memory is the killer feature

A sighted user can scroll back through their screen to remember what they did 5 minutes ago. A blind user in a conversation has no easy way to recall.

We invested heavily in conversational memory: the system tracks what the user has done, what they have said, and what files they have touched. When the user asks "what was that PDF from earlier?", the system retrieves it.

This is going to be the next big UX battleground for AI products generally. Once users trust that an agent remembers their context, they will not go back to stateless interfaces.

Takeaway

Designing for the most constrained users forced us to make every interaction deliberate, every state change audible, and every response quick. Every LLM product would benefit from the same constraints — even if their users have 20/20 vision.

#accessibility#ux#llm#product-design

LLM Engineering

Why every production LLM app needs a two-stage intent router

A monolithic LLM that handles everything — classification, planning, tool use — is slow, expensive, and hard to debug. A two-stage architecture with a small classifier upstream fixes all three.

Infrastructure

We replaced Pinecone with Qdrant + SQLite. Here is the playbook.

For most production AI applications, self-hosting your vector store is 10x cheaper and faster than a managed service. Here is how we did it for AetherFS.