Retrieval-augmented answers for Islam Q&A — where being useful matters less than being traceable, and knowing when not to answer matters most of all.
Islam Q&A is one of the largest published archives of scholarly answers on the internet — categorised, referenced, and available in seventeen languages. People arrive with a question in their own words; the archive is organised by topic. That gap is where the search box fails them.
RAGeh closes it with retrieval-augmented generation: the user asks in natural language, the system retrieves from the enriched archive, and the answer is shaped to the question type with its references attached. Behind it sits an admin console where the corpus is ingested, cleaned, enriched, reviewed by humans, indexed into a vector store, configured, evaluated and monitored.
Two design surfaces, one problem: a system that speaks about sacred matters has to show its work. Every decision below follows from that. Direction, system and reviews are mine; screens are shared with Omar Hammad.
An answer without a source is worthless here In this domain a claim carries weight only by its chain back to a scholar and a text. A fluent paragraph with no citation isn't a lesser answer — it is the wrong object entirely. References had to be a structural part of the answer, not a footnote the interface could collapse.
Most real questions are under-specified Rulings turn on circumstance: who is asking, where, in what state, under which conditions. A system that answers a vague question confidently is more dangerous than one that answers nothing. So the interface needed a first-class state that most AI products treat as a failure — I need more from you before I answer.
One answer shape doesn't fit every question A definitional question, a ruling with conditions, and a question with genuine scholarly disagreement need different shapes on the page. Designing one generic response bubble would have flattened distinctions the archive is careful about.
Confidence has to be visible without being a number A percentage invites false precision on subject matter that doesn't take it. The design had to communicate strength of evidence and known limits in words and structure — and had to let the system decline territory it shouldn't enter.
Arabic first, sixteen other languages after The corpus is Arabic; the readership is global. Type, line length, numerals and the whole reading rhythm had to be right in RTL before anything was mirrored into LTR — the reverse order produces an Arabic interface that reads like a translation.
The console's users are reviewers, not ML engineers Ingestion, enrichment, chunking, embeddings, retrieval settings, evaluation runs — the pipeline is technical, but the people who validate the corpus are editors and scholars. The admin design had to make a RAG pipeline legible to someone who reasons about texts rather than vectors.
Requirements first, then the system fundamentals and the stories in parallel, screens assembled from tokens rather than drawn freehand, and Claude Code carrying the repetitive work underneath. What changed on RAGeh is what the stories had to pin down before a frame was worth drawing: not just what a screen shows, but what the system is allowed to say.
1. Take the requirements from the client How the archive is structured, how an answer is composed, what a reference means, and which questions the system must refuse or defer. The editorial rules came first because they constrain the interface far more than any feature list.
2. Build the fundamentals of the design system Tokens and core components designed Arabic-first: a type ramp tuned for naskh and Latin at matched optical weight, RTL mirroring as a rule rather than a fix, and a component set that covers the states this product actually has — asking back, answering partially, citing, declining.
3. Write the stories Each one naming its surface and its acceptance conditions, including the ones engineers can't infer: what the screen does when evidence is thin, when sources disagree, when the question is out of scope.
4. Build the screens in Figma The client app for mobile and desktop, and the console for the full pipeline — assembled from the token set so a change to the citation block or a field propagated instead of being repainted across every screen.
5. Use Claude Code to make the work faster and more accurate Drafting and normalising stories against the requirements, checking screens against the pipeline's actual inputs and outputs, scaffolding tokens and components, and catching the drift between a design and its story before it reached a build.
Three flows recorded from the prototype: the first run through to the question field, the conversation history with its per-question status, and a structured answer resolving with its references attached.






