## 1. Visibility of System Status 

> Designs should keep users informed about what is going on, through appropriate, timely feedback.

✅ App using loader indicator, response streaming and submit button is changed with “stop” button.

## 2. Match between System and the Real World

> The design should speak the users' language. Use words, phrases, and concepts familiar to the user, rather than internal jargon.

✅ Text inputs has placeholder “Ask anything”, which is phrase tareted for chat user, opposed to “enter prompt”.

## 3. User Control and Freedom

> Users often perform actions by mistake. They need a clearly marked "emergency exit" to leave the unwanted state.

✅ During the response user may abort the response streaming with a “stop” button. If Answer is already in UI, user may reload or downvote the response. 

## 4. Consistency and Standards

> Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

✅ Asking question pattern is similar to google with one input to start interaction with the app. Chat is created with user messages aligned right in separate section from the response from LLM, implementing visual chat representation pattern.

## 5. Error Prevention

> Good error messages are important, but the best designs prevent problems from occurring in the first place.

🤷🏻 Probabalistic systems may produce errors, that are hard to expect or prevent. No data regarding the error prevention in chatgpt.

## 6. Recognition Rather Than Recall

> Minimize the user's memory load by making elements, actions, and options visible. Avoid making users remember information.

✅ User should not remember how to access previous chat or where chat is. Previous chats are available in the side panel together with search.

## 7. Flexibility and Efficiency of Use

> Shortcuts — hidden from novice users — may speed up the interaction for the expert user.

✅ App contains shortcuts for advanced users, which can be found in the help dialog or by clicking “command + /”

## 8. Aesthetic and Minimalist Design

> Interfaces should not contain information which is irrelevant. Every extra unit of information in an interface competes with the relevant units of information.

✅ A lot of app configuration is hidden in the main view under the “…” icon at the top right. Model choise is implicitly predefined and you can expand available models with a separate dialog. 

## 9. Recognize, Diagnose, and Recover from Errors

> Error messages should be expressed in plain language (no error codes), precisely indicate the problem, and constructively suggest a solution.

✅ Human-readable error messages are used as response in case of error together with “reload” icon, allowing to recover from the error. 

## 10. Help and Documentation

> It's best if the design doesn't need any additional explanation. However, it may be necessary to provide documentation to help users understand how to complete their tasks.

✅ At the bottom there is a help button, opening help dialog with usr guide and shortcuts for power user.



_Nielsen Norman Group_

[www.nngroup.com/articles/ten-usability-heuristics/](http://www.nngroup.com/articles/ten-usability-heuristics/)

How Jakob's Ten Usability Heuristics applied in chatgpt.com 

If you’ve ever asked an LLM about your own API and got an outdated answer, you know the pain. In the AI era — with all the vibe code hype and agentic development trends — the context we provide to LLMs is becoming more and more important.

We all know about issues with LLM responses called _“hallucinations”_ and those famous productivity graphs showing “with AI” vs “without AI”.

One of the reasons an LLM can give an incorrect response is **stale information** about the APIs you’re using.

To solve this issue, we already have an **MCP server**: [context7](https://github.com/upstash/context7), which _pulls the latest information from the source_.

As of today, **Context7** includes over **49,566 libraries** with up-to-date documentation.

But what about the data the LLM itself was trained on?

AI agents that don’t have access to this MCP server are still crawling web pages like any other crawler — gathering data to train on or to answer queries. This is neither efficient nor accurate.

The answer to this problem is **`llm.txt`**.

It’s a **standardized way for your documentation website to communicate with LLMs**. It helps:

- Control how AI accesses your documentation — API owners can guide navigation through sub-pages or lay out all docs in one place.

- Limit AI crawler interactions with your main documentation web app.

- Allow AI agents to access **up-to-date documentation in a single request**.

- Standardize how we communicate with AI crawlers and agents.

I’ve found a GitHub repository containing links to existing `llm.txt` files and tools already using this standard:

👉 [https://github.com/thedaviddias/llms-txt-hub](https://github.com/thedaviddias/llms-txt-hub)



`llm.txt` could become the `robots.txt` for AI — defining how LLMs see your docs.

   This is an example of RSPack docs for llm([link](https://rspack.rs/llms.txt)):

```javascript
# Rspack

> Rspack is a high performance JavaScript bundler written in Rust. It offers strong compatibility with the webpack ecosystem, and lightning fast build speeds.

## Guide

- [Introduction](/guide/start/introduction.md)
...
## Config

- [Configure Rspack](/config/index.md)
...

## Plugin

- [Introduction](/plugins/index.md)
...

## API

- [Introduction](/api/index.md)
...

## Blog

- [Overview](/blog/index.md)
...

## Other

- [Builtin plugin](/contribute/architecture/builtin-plugin.md)
...
```



llm.txt — A Standard for AI Documentation Access

### **What is RAG?**

RAG stands for Retrieval Augmented Generation. This is the process when the Large Language Models (LMM) input is enriched with a contextual information from the external sources by a provided prompt.

### **What problem it solves?**

- Stale or outdated data. Retrieving relevant data from the external sources and data which is up to date.

- Invalid answers or hallucinations. Adds data which may be missing, new or proprietary.

### **What is the Process?**

The RAG process consists of three main stages: _Retrieval_

- orchestrator accepts the prompt in a free text form. _"Where are libraries in my district?"_

- creates a vector query from the prompt. Vector is also called vector embedding. Vector is a floating point number (1.345). Vector embedding is a series of vectors (e.g. **`[1.34, 4.78, -0.35]`**).

- vector query is used to retrieve information from vector database.

- vector database can match similar vector by a vector query and returns top matching documents or text passages _Augmented_

- The retrieved text passages are integrated into the original prompt, adding specific context. For example: _"Context: Libraries in users district are located in X street 1km away form his location. Question: Where are libraries in my district?"_ _Generation_

- LLM generates response based on prompt and context

### **Is Vector database mandatory?**

No, a vector database is not mandatory for the RAG process. However, it is highly recommended due to its efficiency, scalability, and high accuracy in matching semantically similar texts, significantly improving the quality and reliability of retrieval results.