RESEARCH × PRODUCT DESIGN · HIGHER EDUCATION
Meet Norman.
Learning, with
something to
back it up.
An AI study assistant that uses course materials to answer questions, shows its sources, and keeps instructors involved.
Sandbox demo with precomputed answers from a real retrieval run. Built by a team at RIT.
A clearer source.
01 / THE CHALLENGE
A confident answer
isn’t always a useful answer.
Confident AI answers can miss
the context of the course.
NORMAN’S RESPONSE [1]
- Use course materials to answer
- Make sources easy to check
- Limit access to the right course
How might we help students move from
“What is the answer?” to
“I understand it, and I can check it.”
Stay close to the course
Start with the materials students are using in class.
Show where answers come from
Let students check the source, even when an answer sounds convincing.
Keep instructors involved
Give students a way to ask an instructor to review an answer.
02 / HOW THE DESIGN TOOK SHAPE
Turn research goals
into useful features.
These four steps explain the thinking behind Norman, based on the paper and the product.
- 01
Understand the problem
Students need to know whether an answer fits their course and where it comes from.
- 02
Set the course limits
Use each course’s materials and control who can access them.
- 03
Make the next step clear
Ask, check a source, save a note, or request a review.
- 04
Make it easier to use
Check that screens work on different devices and that actions are easy to find.
FOR STUDENTS
Move forward
in the course.
- Find the right course and start a question.
- Review the answer alongside its sources.
- Keep useful explanations in notes.
- Organize follow-up work in the agenda.
FOR INSTRUCTORS
See where
support is needed.
- Review student questions and flagged answers.
- Read session summaries and see where students need help.
- Use course materials to plan the next lesson.
- Review suggested dates before approving them.
| Need | Feature |
|---|---|
| Course-specific help | Course links and a visible course name |
| Sources students can check | Source excerpts students can open beside answers |
| Instructor review | A list of flagged questions and dates to approve |
| Keep learning after a chat | Saved notes, conversation history, and agenda |
03 / HOW IT WORKS
Course materials in.
Traceable answers out.
Understanding the pipeline shaped the interface.
- 01
Materials uploaded
- 02
Chunked and embedded
nomic-embed-text - 03
Stored in a per-course ChromaDB collection
Course isolation enforced - 04
Question asked inside a course
- 05
Dense retrievalBM25Run in parallel
- 06
Merged with reciprocal-rank fusion
Retrieval quality enforced - 07
Passages + question sent to
qwen3.5:27b - 08
Answer returned with sources attached
The paper describes a Flask system hosted at the university; this is the React and FastAPI build.
Technical stack of the later build
- Frontend
- React, TypeScript, Vite
- Backend
- FastAPI, SQLite
- Retrieval
- nomic-embed-text in per-course ChromaDB collections. Dense plus BM25, merged with reciprocal-rank fusion.
- Model
- qwen3.5:27b via RIT's Ollama-compatible API
- Access
- Course-level permissions tied to sign-in and verified enrollment
Where design meets the pipeline
One course at a time
The course ID is checked against enrollment and vector-store metadata before retrieval, so isolation lives in the pipeline, not the interface. I kept the course name on screen through every conversation so students can see what the answer is scoped to.
Evidence rides along
Retrieved excerpts return with the answer rather than on request. I put them inline beneath the response, so the supporting material stays visible beside the response.
04 / WHEN THE SYSTEM DOESN'T KNOW
The states most AI products hide.
No relevant source found
What happens: When retrieval returns no material, the model is instructed to acknowledge the gap and suggest contacting the instructor.
What the student sees: An explanation in the chat response, rather than a separate error screen. The wording is generated.
My design call: I designed the response to make the missing evidence clear and point students toward instructor support.
Weak or low-confidence retrieval
What happens: Retrieval ranks and filters passages. Its scores are not calibrated confidence, and filtering does not guarantee refusal.
What the student sees: The standard answer and source interface, without a dedicated low-confidence warning.
My design call: I kept source excerpts available for inspection without presenting retrieval scores as a confidence rating.
Question outside the course
What happens: The model is instructed to say when the course materials do not cover a topic and avoid teaching unsupported subject matter.
What the student sees: A conversational boundary and guidance on where to look or whom to ask. This is model-guided behavior, not a fixed refusal screen.
My design call: I designed the interaction to keep the course boundary visible and give students a next step.
Student flags an answer for instructor review
What happens: The question and answer are sent to the course instructor queue for review and resolution.
What the student sees: “Flagged for your instructor.” confirms submission, and the control changes to “Flagged.”
My design call: I placed the review action beside the answer and made its submitted state visible.
05 / THE EXPERIENCE
A study space.
Not just a chat box.
See how students and instructors use Norman.
From a course dashboard to a question, an answer, and saved notes.
Read the walkthrough description
Begin at the course dashboard. Open Chat and use a suggested question to start. Norman shows a response in the conversation. Save useful text to Notes, then return to the saved explanations.
Review course activity, plan a lesson, and add an event.
Read the walkthrough description
Instructors can find items needing attention, start a planning conversation, and review or add course dates.
DESIGN DECISION / 01
Start with a course,
not an empty prompt.
Courses, chat, and study tasks share one home. Suggested questions help students get started.
Why this matters: students know which course they are asking about.
DESIGN DECISION / 02
Save an answer.
Use it later.
Students can save explanations as notes, return to the original chat, and add follow-up tasks to their agenda.
Design choice: make saving quick and explain what will happen before notes are deleted.
DESIGN DECISION / 03
Help instructors see
where support is needed.
Instructors can review flagged questions, check course dates, and see recent activity. A separate chat helps with lesson planning.
Design choice: show what needs attention and make the next action clear.
06 / THE MEANINGFUL SHIFT
Get an answer.
Check it. Choose what’s next.
The design connects answers with supporting excerpts, saved notes, and instructor review. Opening the original source remains a proposed next step.
THE ANSWER-ONLY PATTERN
Ask → Read → Decide alone
Students must find supporting material and decide when to ask for help.
NORMAN’S APPROACH
Ask → Check → Act
Sources, notes, and review options are available in the same workspace.
MAKE SOURCES EASY TO CHECK
“What supports this?”
The later interface displays supporting excerpts. Linking them to the original lecture moment remains proposed and has not been retested.
Design purpose: help students judge an answer using its sources.
CONNECT ANSWERS TO STUDY
“How do I use this next?”
Save a useful explanation as a note, revisit its original conversation, or add it to the agenda. Learning can continue beyond the chat session.
Design purpose: make useful explanations easier to find later.
KEEP HUMAN SUPPORT AVAILABLE
“This needs a second look.”
Students can send an answer for review. Instructors see flagged questions on their overview page.
Design purpose: help instructors spot answers that need a closer look.
The design contribution: help students check answers, save useful work, and ask instructors for help.
07 / THE VISUAL LANGUAGE
Friendly to explore.
Easy to read.
Norman’s “Study Club” style uses hand-drawn details, clear borders, and familiar buttons to make the workspace feel welcoming.
TYPOGRAPHY
Balsamiq Sans
Balsamiq Sans gives headings and body text a friendly feel. IBM Plex Mono sets code and small labels apart.
IBM Plex Mono / 0123456789
COLOR WITH A JOB
Yellow highlights key actions. Light backgrounds and dark text make reading easier. Labels and borders add clarity.
Easy reading
Short lines, comfortable spacing, and artwork that stays out of the way.
Familiar buttons
Clear outlines, rounded corners, and buttons large enough to tap. Keyboard users can see which control is selected.
Quiet motion
Buttons respond when used. Text stays still. Motion is reduced when the reader requests it.
08 / EVALUATION
What students did with it.
I ran moderated think-aloud sessions with 16 students. Each did four tasks: catch up on a missed lecture, find something specific, ask a clarifying question, and check where an answer came from.
Sources built trust. They didn't let anyone verify.
What I saw: Seeing a sources label raised confidence. One student's answer to "would you trust it" went from "probably" to "definitely" the moment they noticed it. But the sources could not be opened, several students missed them, and one watched them disappear after leaving the chat. To actually check an answer, students went to Google or matched dates by hand in myCourses. Participants asked for clickable sources.
What it means for the design: A visible source is a trust signal. A clickable source is a verification tool. Norman needs the second, linked to the exact lecture moment.
The pre-filled prompt made people hesitate.
What I saw: "Ask Norman" pasted the selected summary into the text box. Students didn't know whether to keep it, edit it, or delete it. One sent it by accident with Enter. Multi-line context collapsed into a single visible line.
What it means for the design: Show selected context as an attached chip, separate from the question, so the text box belongs to the student.
Course-grounded, but not only course-grounded.
What I saw: Students were told Norman uses only lecture material. Several noticed it also gave general explanations and its own examples. Most welcomed this, but no one could tell which parts came from class.
What it means for the design: Label course-grounded content and general explanation differently inside an answer.
Students wanted control over the format.
What I saw: A request for a one-sentence answer was ignored until it was reworded. Requests for flashcards or a mind map got the format Norman preferred instead. Visual learners asked for diagrams and the lecture slides themselves.
What it means for the design: Honor explicit format requests, and surface lecture visuals where they exist.
Catching up on a missed class worked.
What I saw: This was the strongest task. Students praised the color-coded sections, key concepts up front, and assignments in their own block. Several said Norman would be the first place they went after missing class, and a lower-pressure option than emailing the professor.
What it means for the design: The session summary is the core of the product. Build outward from it.
"My answer was going to be probably, and now it's definitely yes."
"It's still sticking to what it would prefer, instead of what the user would prefer."
Smaller issues
- Calendar dates look clickable but aren't
- Cursor doesn't change on clickable elements
- One session summary failed to generate
- Sources disappear after leaving the chat
Still open
- Once sources are clickable, do students actually check them?
- Can students tell course-grounded content from general explanation?
- Can instructors review flagged answers within their workload?
EVIDENCE TO DECISION
What the findings call for next.
These responses address the initial evaluation findings. They are proposals, not demonstrated improvements.
| Observed finding | Design response | Implementation status | Retest status |
|---|---|---|---|
| Source labels raised trust, but sources could not be opened. | Link sources to the exact lecture moment. | Proposed; not implemented | Not retested |
| Pre-filled context confused students and was sent accidentally. | Separate context chips from the question field. | Proposed; not implemented | Not retested |
| Students could not distinguish class material from general explanation. | Label the origin of content within answers. | Proposed; not implemented | Not retested |
| Requested formats were not reliably followed. | Honor format requests and surface available lecture visuals. | Proposed; not implemented | Not retested |
THE RESEARCH BEHIND NORMAN
From a design question
to a published contribution.
Donovan, M., Shadangi, S., Ganskop, D., Beaton, C., & Mahajan, R. (2026). NORMAN: A Retrieval Artificial Intelligence Augmented Teaching Assistant for Higher Education. EDULEARN26 Proceedings.
Read the published abstract ↗DOI: 10.21125/edulearn.2026.0944
Sources and notes
- Norman paper: public abstract and publication metadata. The full manuscript was supplied for reference alongside the public abstract and publication metadata.
- Rinky Mahajan’s Norman project case study. Confirms research-collaborator and co-author attribution.
- Supplied Norman project: frontend design-system README and change log, React screens, API routes, and the revisions made during this project review. These explain the design choices and updates.
- Nielsen Norman Group: 5 Steps to Creating a UX-Design Portfolio. Informed the structure: context, contribution, decisions, artifacts, and outcomes with honest limitations.
Screens and videos use demo data. Videos combine screenshots; they are not continuous recordings or tests of live AI answers. The student and instructor goals are design summaries, not participant quotes. The current interface includes changes made after the version described in the paper.