Signal: A draft UX framework for LLM-based systems

Semantic Interaction Guidelines for Natural AI Language

SIGNAL is a pattern framework for LLM UX, human-AI interaction, conversational AI, agent UX, semantic clarity, cognitive load, and, most importantly, user experience in LLM-based systems.

Warning

SIGNAL is under active development.

This framework was created after researching adjacent work in Human-AI Interaction, conversation design, cognitive accessibility, plain language, generative AI UX, AI governance, and LLM user research.

These fields contain strong ideas, guidelines, and empirical studies, but I could not find a focused, open, README-first pattern framework dedicated mostly to user experience in LLM-based systems, especially the communication layer: semantics, intent, grounding, navigation, agency, and cognitive load.

SIGNAL is not a claim of invention from zero.

It is a consolidation attempt: a practical pattern language for a space that appears fragmented across research papers, product guidelines, accessibility notes, governance frameworks, benchmark culture, prompt engineering, and chatbot design practices.

A signal is a gesture, token, or action used to transmit information, communicate a command, or serve as a warning.

When conversation is the interface, communication is the product experience.

Users do not want to write perfect prompts.

They communicate like people: short messages, vague references, metaphors, idioms, incomplete context, frustration, shortcuts, corrections, and indirect requests.

LLMs are optimized to generate plausible continuations of language. Product experiences require more than plausible continuation: they require visible intent, grounding, progress, agency, cost, and value.

That gap is where UX matters.

SIGNAL designs the communication layer between messy human language and useful AI behavior.

SIGNAL uses product-facing names, but each dimension is grounded in established concepts from Human-AI Interaction, linguistics, cognitive psychology, information retrieval, and agent research.

ISO 24495-1;W3C COGAIntentSpeech acts, indirect speech acts, intent recognition,query rewritingLLM UX intent taxonomy;MaFeRwGroundingretrieval-augmented generation, calibration, source attributionLewis et al. 2020;HELM;Microsoft HAXNavigationNielsen; Clark and Brennan 1991;Myers 1985AgencyAmershi et al. 2019;Microsoft HAX;NIST AI RMFLoadCognitive load, working memory, cognitive accessibility, progressive disclosureSweller 1988;Cowan 2001;W3C COGASIGNAL is not inventing these concepts from scratch. It organizes them into a practical framework for teams building AI experiences through language.

SIGNAL does not explain how an agent is implemented internally.

It explains how SIGNAL components can sit on top of an example agent loop and turn user/context information into proactive behavior, visible value, and precise communication about what the user expects.

The loop shown below is only an illustrative example, like using example.com

in documentation. It is not a SIGNAL recommendation, pattern, or required architecture.

The implementation can use RAG, tools, memory, workflows, agents, MCP, databases, or only prompting. The UX responsibilities stay the same.

This is not an internal architecture diagram. It is a reusable allocation model.

SIGNAL shows what an AI experience must preserve for the user, regardless of the actual implementation flow.

AI conversation UX is not only about producing an answer with cosmetic quality, concision, or explanation.

A good AI experience makes the AI context closer to what the user is trying to communicate and what the user actually needs.

It should divide understanding into reactive and proactive responsibilities.

Reactive understanding:

• the current turn;
• what the user is uncertain about;
• what context helps answer the user;
• what the AI needs from the user now.

Proactive understanding:

• what the system is doing actively and passively;
• what may become relevant from earlier context;
• what may cost, risk, or create consequences for the user;
• what AI can do for the user without being explicitly asked;
• what follow-up or action suggestion the AI can offer.

It should communicate:

• what changed;
• what value was delivered;
• what remains uncertain;
• what the user controls;
• what the AI can do next.

If the user says something that does not clearly connect to the last message, the system should not immediately ask "what do you mean?". It should first check whether the user is referring to something earlier in the conversation, something visible in the current environment, or something that just happened.

SIGNAL can be applied to any prompt engineering, agent, bot, assistant, workflow, or AI product by mapping its communication UX responsibilities to the product's actual behavior.

The following loop is only an example used to explain the concept:

flowchart LR
    U["User / Context"] --> A["Understand"]
    A --> B["Reason"]
    B --> C["Act"]
    C --> D["Validate"]
    D --> E["Respond"]
    E --> U

In this example, SIGNAL defines what each stage must preserve.

This makes SIGNAL reusable across architectures without requiring this specific loop.

It does not matter whether the system is only a prompt, a RAG assistant, a tool-using agent, an MCP workflow, a database-backed bot, or a multi-agent system.

The implementation may change. The UX responsibilities remain the same:

Understand -> preserve meaning and intent.
Reason -> preserve evidence, uncertainty, and state.
Act -> preserve user control.
Validate -> preserve correctness, scope, and recovery.
Respond -> preserve clarity, value, and low effort.

Use it in five steps:

• Map the product's AI behavior to the loop.
• Assign SIGNAL responsibilities to each stage.
• Choose patterns for the stages that are failing.
• Define checks for prompts, tools, retrieval, memory, workflows, and responses.
• Convert failures into product changes: better wording, better retrieval, clearer state, safer approval, lower user effort, or a stronger action boundary.

The output of a SIGNAL review should be concrete: rewritten responses, clearer action boundaries, better tool behavior, improved retrieval overlap, evaluation checks, and visible value receipts.

Each SIGNAL pattern is a reusable answer to a recurring AI UX problem.

flowchart TD
    P["User communication problem"] --> D["SIGNAL dimension"]
    D --> C["Canonical concept"]
    C --> R["Reference-backed principle"]
    R --> X["Reusable UX pattern"]
    X --> E["Evaluation criterion"]

Example:

docs/RESEARCH_AND_BENCHMARKS.md

docs/PATTERNS.md

docs/WHY_SIGNAL.md

docs/FOR_TEAMS.md

templates/conversation_ux_review.md

SIGNAL is not:

• a model benchmark;
• a prompt engineering trick;
• an internal agent architecture;
• a replacement for product research;
• a leaderboard;
• a claim that one assistant is universally better than another.

SIGNAL is a communication UX layer for AI product experiences.

It helps teams ask:

Did the AI understand what the user meant, act within the right boundaries, reduce user effort, and make the delivered value visible?