Web app · 0-to-1
Requesta is an LLM-powered question-generation web application for educators, running on ASU’s multi-provider CreateAI gateway. Faculty use it in the browser to turn source documents (chapter PDFs, syllabi, textbooks) into assessment question sets.
TEAM
8-person cross-functional team, 7 stakeholders
TIMELINE
Mar to Apr 2026
TOOLS
Figma · FigJam · Figma Make · Tailwind UDS
At a glance.
Faculty think in collections of questions, and my first version made them work in steps. The project started as a 40‑page engineering spec with no product behind it. I turned that spec into user flows, Figma prototypes, production UI and a component library, and kept 7 stakeholders and an 8‑person cross-functional team aligned along the way. I dropped the page-per-action flow once faculty kept asking where their questions lived, and designed a three-panel workspace with its own design system, Tailwind UDS.
3
versioned wireframe sets
with a written feedback protocol
15–20
components
kept of the ~50 audited
Figma Make prototype
Testable in days, for early feedback.
First job: make the spec legible for everyone.
The SRS explained the system’s operations and said nothing about the educator’s experience. I turned it into a FigJam flowchart, and that became the project’s shared language: every decision and edge case got argued against it.
View the full flowchart
Then pen and paper before Figma. Three versioned wireframe sets followed, reviewed across several teams and by directors. Three rounds produced feedback we could act on.
Figure 2. One notebook page: the generation screen drafted as a step list, with an error state and a retry drawn at the failing step.
The pivot: V1 felt like a checkout.
V1 was a drip-down, page-per-action flow. The SRS spoke in operations, so my first structure did too. Faculty kept asking where their questions lived, because their mental model is a collection, and the app was making them think in steps.
I discarded V1 and restructured the information architecture into a panel-centric workspace, inspired by NotebookLM: project navigation left, working area center, knowledge panel right, everything visible at once with one shared state.
PROJECT NAV
projects and sets
WORKING AREA
questions
KNOWLEDGE PANEL
source files
Figure 3. The three panels share one reactive state.
Figure 4. The final flow: six steps, with files kept apart at step 2.
The layout shift changed what Requesta was: from a question generator you visit once to a question management workspace you return to.
Figure 5. Drag the handle: the discarded V1 checkout flow against the V2.1 workspace that replaced it.
Three decisions inside the workspace.
They cover how files are uploaded, how generation shows its work, and how far editing can reach.
Two upload zones, the most argued pixels in the product.
QUESTION CREATION FILES
What the questions are made from, like the chapter being taught.
CONTEXT FILES
Supporting material that informs the questions, like the syllabus.
The review threads show how contested this was: three reviewers flagged the same confusion independently.
WHAT REVIEWERS SAID
WHAT CHANGED
Need to understand the difference between Question Creation and Context files.
Kept the two zones, and renamed everything in plain language.
“Context” for a regular user is not language they would know.
A banner on each zone now says exactly what it feeds.
It seems like context files shouldn’t live here.
Context Files moved behind an opt-in checkbox, closed by default.
I defended the two-zone structure, because the model treats the inputs differently, and conceded the language on every front.
Figure 6. The Figma comment thread on the two zones, with my reply.
Two more asks came out of the same reviews.
Figure 8. The granular export modal, built from the second reviewer ask.
The pipeline shows its work.
Generation is long enough that a spinner reads as a hang, and each failure has a different recovery. So the screen exposes the pipeline as an accordion with five stages: analyzing source documents, mapping Bloom’s taxonomy levels, generating question stems, generating answer options, and a final quality review. Errors surface at the failing stage, and users retry the right thing.
The accordion also matches the real architecture: Requesta runs as a multi-agent workflow, and each stage on screen is one of those agents at work.
Figure 9. Screen recording of the accordion. Each stage opens as the pipeline reaches it.
Editing, deliberately scoped.
Three operations per question, each scoped to what it can safely touch.
The design system was a parallel workstream from day one.
Tailwind UDS, a Tailwind-based system extending ASU’s in-house Unity Design System, was built alongside the screens, with tokens matched to the frontend stack from the start.
An automated audit cut ~50 candidate components to the 15–20 needed, merged by how they behave.
Variables synced via the Figma REST API, and components resolved by identity through Figma’s Code Connect. I stood up a React implementation with semantic tokens and themes, to check the structure held up in real code. A Figma Make prototype was testable in 3–4 days while hi-fi continued.
Figure 12. The Figma Make prototype, recorded. Testable in 3–4 days.
Where things landed.
We built the Make prototype in days so faculty could test it while hi-fi was still in progress. The walkthroughs surfaced no major changes, so the workspace direction held up in front of its users before engineering built it.
The multi-agent framework behind the product was later evaluated by the lab’s research team against a GPT-5 baseline, and that evaluation is their work.
The product UX itself wasn’t instrumented. If I were measuring:
Project takeaways.
Next case study
iSTART Early, rebuilding a reading platform for young learners
Read the case study →
Anchal Nagdev