Back
AI-first Product Design — Case Study
Sharpening the last mile of UPSC prep.
I designed and built Prayas AI's core experience as the sole designer — not as static mockups, but as near-production code in Claude Code, then handed to engineering to wire up the backend and ship.
Role
AI-first Product Designer
Scope
Sole designer · 4 modules · ~1 wk each
Output
Near-production React, handed to eng
Status
Live · in daily use
4
modules designed + built
~1wk
per module · brief → build
100%
handed off as code
10K+
Downloads on Playstore
Context
What Prayas AI is
Prayas AI is a practice app for serious UPSC aspirants — the ones who've finished covering the syllabus and now live or die by how sharply they revise and test themselves. It isn't where you learn the syllabus. It's where you practise, smartly.
Most tools stop at delivering content. Prayas starts where content ends — turning scattered material into focused, repeatable practice aspirants come back to daily.
The problem
Finishing the syllabus isn't the hard part
Once the syllabus is covered, the bottleneck moves — from knowing to practising the right things, often enough, without losing momentum. Three things got in the way.
01
Unfocused practice
No clear read on weak areas, so practice time scattered across everything — and sharpened nothing in particular.
02
Scattered material
High-value notes and PDFs piled up in Telegram and downloads, rarely reopened. Raw files aren't something you revise on a phone between two tasks.
03
Fading motivation
Solo, silent practice is the easiest thing to skip. Without stakes or feedback, consistency quietly erodes.
How I work — design → design engineering
Designer by role, builder by choice
My job is the UX designer's — research, design, and the handoff to engineering. But when Prayas adopted Claude Code, so did I: my handoff stopped being just Figma. Now I hand over a working React prototype I vibe-code myself — carrying the interaction and haptics a static file can't, so the design reaches the devs pixel-perfect.
Design
Design engineering
01 · Brief & Research
Projects starts with Brief decoding with AI understnding newancing with taking to doamin experts in team and connverting it into hi fi wireframes to get vaidation call with stakeholders
→
to Figma
02 · Figma
🎨
Figma design
Basedon wireframes which modified intofigma we put into claude code whre similar to figma a code deisgn systme buidled by me which allows me to get 90% accurate deisgn match to app which again traser to figma for modify and tiwsn
→
same tokens · design → build
03 · Claude Code
⌨️
System in code
after figma deisgn are ready and modifyed andgot approved y team i used to take some odules back to claude code wiusing figma mcp and create react prototype for thag deisgn which has interaction conenct flows which later files handover to dev for furhre .,, ths makes get deisgn s showcase better
Near-production code — not a mockup, in hours, not sprints.
Because the design system lives in code, the same tokens carry a screen from Figma to a running React build — interaction, animation, and haptic feel a static mockup can never show. I hand those coded files to engineering, who connect the backend and existing modules, fill the gaps, and take it live.
↳ The whole thing, sped up
How I work — design → design engineering
From a brief to a real app build — in hours, not sprints
I don't hand off static mockups. I run one loop that carries a brief into real, coded UI — crossing from design into engineering without leaving my hands — then hand the build to the dev team. drop GIFs into each step below
Design
Design engineering
01 · Brief
Start from the PM's PRD. Rough frames, fast — validated before any polish.
→
to Figma
02 · Figma
🎨
Figma design
Real screens on the design system — shared tokens, shared components.
→
same tokens · design → build
03 · Claude Code
⌨️
System in code
The same tokens, rebuilt in code — the design system, now executable.
→
generate
04 · Coded build
📲
Near-production React
Designs become a running React build — interaction, motion & haptics. Handed to eng to wire up.
Near-production code — not a mockup, in hours, not sprints.
Because the design system lives in code, the same tokens carry a screen from Figma to a running React build — interaction, animation, and haptic feel a static mockup can never show. I hand those coded files to engineering, who connect the backend and existing modules, fill the gaps, and take it live.
↳ The whole thing, sped up
Module 01 — Home & navigation
A launchpad, not a landing page
Challenge. Four powerful surfaces — practice, Vault, AI assistant, Duel. The risk: a home that shows everything and starts nothing.
Decision. Home as a launchpad. Permanent bottom nav for the four destinations; the home screen pushes one thing — get into practice today — to the top.
↳ Live coded build
Module 02 — AI Knowledge Vault
From Telegram dump to bite-size revision
Challenge. Aspirants hoard files in Telegram — gold buried in noise. Long PDFs don't get revised on a phone between tasks.
Decision. The Vault connects to a Telegram bot: files get processed by AI into bite-size, consumable units — short, scannable, built for repeat passes.
Text
—
Text
—
Text
—
↳ Live coded build
Module 03 — AI assistant
A study companion that's always awake
Challenge. Aspirants get stuck at odd hours with no one to ask. An unresolved doubt becomes a gap.
Decision. An AI assistant grounded in the UPSC context — a calm, on-demand companion, not a generic chatbot, with a UI tuned for study over small talk.
Text
—
Text
—
↳ Live coded build
Module 04 — UPSC Duel
Making practice worth showing up for
Challenge. Solo practice is easy to skip. Motivation needed stakes.
Decision. A 1v1, real-time question battle — same questions, a live opponent, a result. Practice becomes competitive, social, and fun to repeat.
Text
—
Text
—
Text
—
↳ Live coded build
Foundations
A design system built for one-week cycles
Shipping a module a week, solo, only works if I'm not redrawing the same button every Monday. So I built the foundation every module assembles from — tokens, components, patterns.
It keeps four very different features feeling like one product — and it didn't stay in Figma. I turned the same system into code, which is where the next section picks up.
Text
—
Text
—
Text
—
Craft
Design QA — closing the gap between design and build
Design isn't done at handoff. As engineering took each module live, I reviewed the running build against the design — caught where reality drifted from intent (spacing, states, edge cases) — and got it corrected. Craft survives in the details that are easiest to skip.
BEFORE
—
AFTER
—
Outcome
Where it stands — and what I'd carry forward
Prayas AI is live and in daily use. The core experience I designed and built in code — home, Vault, AI assistant, Duel — is what aspirants spend their time in, after engineering wired it up and shipped.
add metric
active aspirants
add metric
practice sessions / week
add metric
retention or engagement
↳ Don't invent numbers. Use whatever real signal you have — even rough or directional. If you have none yet, swap this row for qualitative feedback or remove it.
Reflection
Designing in code, on a one-week loop, changed what "done" means for me — I commit early and prove it in something real instead of polishing in the dark. Next, I'd push past a single interview and close the loop with usage data on which practice formats actually move an aspirant forward.
Thanks for reading.
your@email.com
portfolio link
