Designing UX for AI applications

Start from the user, not the model

Before designing any screen, write down who will use the feature and what job they are trying to finish. Study Buddy has at least two kinds of user in mind: a learner who wants explanations and practice, and perhaps a teacher who wants to check what the tool tells students. Their needs overlap but are not the same.

Ask whether AI is the right tool for each part of that job. A fixed list of chapter titles is better as a plain menu; explaining a concept in three different ways is where a model earns its place. Adding AI to a step that was already simple usually makes it slower and less predictable.

Then set expectations at first contact. A short line that says what the assistant can do, what it cannot do and where its answers come from prevents most disappointment later. Keep it specific to your product rather than a generic warning that everyone learns to ignore.

Personalisation can help when it is visible. If the learner tells Study Buddy their level and goal, show those settings somewhere they can see and change them, so a surprising answer can be traced back to a setting rather than feeling random.

Designing for the right amount of trust

Two opposite failures haunt AI products. Overtrust happens when people accept every answer, including the wrong ones, because the text sounds confident. Mistrust happens when people ignore a useful tool because it surprised them once. The goal is calibrated trust, where users rely on the system about as much as it deserves.

Explainability is the main lever. Show the sources behind an answer, such as the notes it was built from, and let the user open them in one click. When the system follows a rule, say so in plain words: for example, that Study Buddy gives hints instead of full solutions during a quiz.

Label generated content as generated. A small, consistent marker on AI answers, summaries and images tells people when to apply extra care, and it matters most where output could be mistaken for a teacher's or an expert's words.

Keep explanations simple. Most users are not AI specialists, so describe behaviour in terms of what they see, such as which notes were used, not in terms of embeddings or tokens.

Showing uncertainty honestly

Language models do not report their own reliability well. Asking a model to rate its confidence from 1 to 10 gives you a number that sounds precise but often has little to do with whether the answer is right. Showing that number to users creates false precision.

Use signals your code can actually measure. Retrieval that found no relevant note, a tool call that failed, two runs of the same question giving different answers, or a question outside the topics you support are all real reasons to show caution.

Turn those signals into clear states rather than vague hedges in every sentence. An empty state that says your notes do not cover this topic, with a button to add a note or ask for a general explanation, is far more useful than an answer padded with maybes.

• Found in your notes: show the answer with its sources
• Not in your notes: say so and offer next steps
• General knowledge: answer, but label it as not from the learner's material
• Something failed: explain briefly and offer a retry

Keeping the user in control

Generated output is a draft until the user accepts it. Let people edit an answer, regenerate it, ask for a simpler or shorter version and copy it out. Every one of these controls says that the human makes the final call.

Anything that changes data or reaches other people needs a confirmation step and, where possible, undo. If Study Buddy proposes five sessions for the study plan, show them first and add them only after the learner agrees, with an obvious way to remove a session added by mistake.

Give users control over their data as well. Make it clear which material the assistant can read, such as their notes or shared course files, let them switch sources on and off, and offer a way to delete stored history.

A little friction is sometimes a feature. Before a learner copies a generated essay outline into graded work, a short reminder that the text came from AI and should be checked and rewritten in their own words is a fair nudge, not an obstacle.

Feedback, loading and error states

Build feedback into the design from day one. A thumbs up or down next to each answer costs one click, and an optional short reason tells you much more. Store the question, answer and rating together so you can review the worst cases and turn them into test cases later in the course. While the app is new, read the low-rated entries every week; they show problems faster than any dashboard.

Waiting is part of the experience. Stream text as it arrives, show a clear message about what is happening, such as searching your notes, and keep the rest of the interface usable. A frozen screen with no explanation makes even a good answer feel broken.

Error messages should never blame the user or leak technical noise. Say what went wrong in plain words, what the person can do next, and keep their typed question so they do not have to start again.

Accessibility runs through all of this. Controls should work by keyboard, status messages should reach screen readers, and contrast and text size should stay readable for everyone who uses the app.