Projects / ReQUESTA
ActiveReQUESTA: from a research engine to a product faculty use
1 / 4The flowchart
- Product
- ReQUESTA, an AI app that creates comprehension questions from course material, with STEM problem-solving questions being added
- Role
- Design lead
- Team
- Nishad P, design lead of a team of three designers
- an engineering team of 9
- LEI's researchers, project managers and usability team
- Timeline
- November 2025 onward
- Status
- Live in beta
- in design QA and in testing with people, formal and informal
- Made for
- ASU's Learning Engineering Institute (LEI), funded by Active Learning at Scale, a $3.75M award from the Institute of Education Sciences (IES)
- built with ASU's Enterprise Technology
- My tools
- Figma (variables, branching, Code Connect)
- Figma Make
- Tailwind
- Asana
- The product runs on
- Python, Django, Next.js, S3 and agentic generation services, with TypeScript for deterministic scripts
ReQUESTA creates comprehension questions from course material, and STEM problem-solving questions are being added.
Faculty upload their course material and pick the kinds of questions they want, and a team of AI agents creates them: on what the text says, what it implies, and its main idea. Faculty then edit, regenerate and export the set for class.
It's becoming an evidence-based question engine that many surfaces plug into, and the web app is the first.
I lead the design of how people use it. Until November 2025, ReQUESTA was research: the agents and an MVP, which is still listed in ASU's Learning Design Suite, with no product around them.
Since the product work began, my team and I have taken the web app from a requirements document to a built version 1, now live in beta.
Impact
$3.75 millionIES award
Funded
Active Learning at Scale, a $3.75 million IES award.
more thantwice as wellas a single GPT-5 prompt
Questions that tell readers apart
In LEI's researchers' study of 572 learners, the agents' questions did more than twice as well as a single GPT-5 prompt at telling strong readers from weak ones (under review).
Research behind the engine, by LEI's researchers
40of the 50 issues
Fixed after testing
The usability team's test with 16 faculty found 50 issues, 24 of them high priority. My team designed fixes for 40 of the 50 issues, and the engineers built them.
doubledtheir build speed
Faster builds
The engineers say keeping design and code matched doubled their build speed.
From requirements to a full design
I decide, review and direct the design, and build proofs of concept for my team and the engineers to take forward.
The flowchart.
I turned the written requirements into a flowchart of the whole app, from projects and file checks to generation and export. It became the project's shared language: scope, edge cases and flow logic were argued against it.
The flowchart Wireframes.
From paper sketches, my team drew three versioned rounds of wireframes, with comments pinned to each screen, so the file stayed a living document, not a handoff.
1 / 2Paper sketches A workspace.
The first round gave every action its own page. The second was a workspace: question sets in a sidebar, the open set in the middle, its details at the side.
Secondary research, and comparing the two rounds, showed the app needed to be more open and inviting, with several areas of focus at once, so I chose the workspace.
It carried through to the built app.
1 / 3A paper sketch of the workspace A working front end.
In 3 to 4 days, my team built the app's front end as a website with Figma Make, Figma's AI prototyping tool. It ran in Figma's environment, filled with dummy data, so every interaction could be tested and testing could start early.
The Figma Make prototype The high‑fidelity design.
In parallel, my team designed the whole app in high fidelity, about 30 pages with tablet and phone versions, on our ASU design system. It's what version 1 was built from, and what the build is checked against. The detail matters more now that developers' AI tools pick up the high-fidelity designs and turn them into code.
1 / 5Creating a question set
What testing changed
LEI's usability team tested the Figma Make front end with faculty in moderated group sessions, and my team reviewed every issue they reported.
Most became fixes:
- "Knowledge" became Course Material
- edit and regenerate moved onto each question card
- faculty can type instructions as well as upload files
A few went deeper:
Bloom's taxonomy was cut. It had been in the designs since the first sketches, but professors weren't comfortable with this way of sorting questions by level of thinking, and some didn't know what it was.
The agents' work is visible. Instead of polishing a loading animation, we made the screen show each agent's role, its reasoning as it runs, and what it drew from the uploads, so faculty can trust what comes back.
The wording assumed a researcher, so we audited the microcopy.
Keeping design and code matched
I set up how design and code stay matched, and my team and the engineers put it in place. Today it works like this:
One design system.My team built an ASU version of Flowbite's Tailwind kit, following ASU's brand guidelines. Figma and the code share it, and Code Connect links each Figma component to its code.
Copy in one place.UX copy lives as Figma variables, so a label changes once, for design and code.
Ready for AI tools.Figma's API and MCP, the standard way AI assistants connect to tools, link the design file to the engineers' tools, and the front end tells coding assistants to use the design system first. Developers can turn a Figma node into UI with Copilot or Claude.
My team also explored Figma's branching: each feature is designed on its own branch and merged back after review. And they check the build against the designs, logging mismatches in Asana for the engineers: 29 reports so far.
How it got here
Over time, I experimented with every kind of automation between Figma and code.
- First I automated token sync.
- Then MCP and REST API endpoints came up, so I tried MCP and plugin-based sync in both directions.
- Then Figma added new tools to its MCP.
- Then I tried automated documentation in Storybook and ZeroHeight, but by then we were moving to a design.md-based system, so we scrapped them, along with the earlier scripts.
Overall, it's been a moving target, in a workspace that keeps evolving.
Onboarding
I wrote the onboarding content, with my own AI assistants: a welcome, a first-visit primer and a Help Center, with the Help Center as the source for the other two. It shows no screenshots, because the interface has changed three times since July while the ideas behind it haven't.
What's next
I'm leading an internal test of the whole workflow on the build in dev, from a plan I wrote: each task gives a goal, never a click path, and testers keep working while questions generate.
STEM questions, a version that plugs into AI chatbots through MCP, and a Canvas integration are in progress, and Campus Quest, a gamified campus project, is built on the same core.
Reflection
ReQUESTA is the most institutional, process-driven project I've worked on: a massive project run by defined teams, with stakeholders who each want different things. It's also a response to an ecosystem that keeps changing. Expectations keep moving for testing, for UI and UX, for development and engineering, and for the learning surface itself, since people might reach the system through MCP, an agent, a game or the LMS. How people reach the UI is changing, and so is how they reach the information behind it. As we explore the MCP approach and open the engine to those other surfaces, I watch the perceived usability of the web UI we designed take a downturn for stakeholders, and their expectations change with it. Working inside that, I keep weighing what to build at all, and for the UI especially, how long it will last, who will use it, and how users will split across surfaces.
There's a psychological tension I hold too: if a professor uses AI to write the questions, a student will wonder why they shouldn't use AI to answer them.
Faculty were also wary of uploading their material and of LLM use, so we proposed and built the system on ASU's own AI infrastructure, which ASU's Enterprise Technology team runs. As LLMs grow and change, I watch how much of the multi-agent system will need rebuilding and how much will stay relevant. The way we link Figma and code already shows it: it works for ReQUESTA, but I don't expect it to outlive it, because agents can now reach Figma and code the same way, and we've found better ways in design markdown files and in letting agents work in Figma directly. So I treat staying nimble as a feature, and the most valuable position to hold. That's what makes ReQUESTA interesting to me: it sits right where both the technology and the expectations are changing.