[ディネシュ・クマール]

ISSUE #01 — 2026

Built by me

IAS Academy LMS

A learning platform where exam-prep students hand in written answers, mentors correct them and the academy keeps it all running. Designed and built with Claude Code.


[01. What I designed]

I was the product owner and UX designer: a written spec, a token-based design system and three role experiences (Student, Mentor, Admin), light and dark.

[02. What I built]

Built in 20 small steps with Claude Code, each with its own tests: 747 backend, 308 component and 166 end-to-end tests pass.

[03. Where AI helped]

Claude Code was my pair-builder. I set the spec, the rules and the checks; it wrote the code step by step.

Stack:Next.jsTypeScriptTailwindshadcn/uiDjango RESTClaude Code CLI· 2026
The productFig. 00 — product screens
Student dashboard with four stat cards, a marks-over-time chart, a status donut, upcoming tests and recent activityMentor review queue with Pending, In review and Completed tabs and Start review buttonsAdmin dashboard with count cards, a needs attention list and a mentor workload chart

Act 1

Hand in your answers. Get them back corrected.

Preparing for the IAS exams means writing a lot of long-form answers and waiting for expert feedback. At this academy that loop ran on files and messages. The goal was one trustworthy place for the whole loop, where students’ private papers and marks stay private.

  1. Student

    Often on a phone. Wants to know what is due, whether the upload worked and how they are doing over time.

  2. Mentor

    Long review sessions on a laptop. Wants the oldest waiting papers first and a fast path from queue to returned marks.

  3. Admin

    Runs the academy. Wants accounts, tests and tasks under control and a clear view of what needs attention.

Fig. 01
IAS Academy sign-in page: a blue panel with a sample marked answer scored 72 out of 100 and the line Hand in your answers, get them back corrected, beside a plain username and password form
Sign-in: the promise on the left, a plain form on the right

Act 2

One status flow as the spine

Every paper moves one way: Uploaded, In review, Corrected. That single flow drives the dashboards, the queue, the badges and the notifications. Each status pairs an icon, a label and a colour, so colour is never the only signal.

Decision 01

Students see where they stand

Four stat cards lead into a marks-over-time chart and a status donut. Upcoming tests carry an Upload button and a live countdown. Every chart has a 'View as table' twin.

  • Pending uploads
  • Submitted
  • Corrected
  • Average marks
Fig. 02
Student dashboard with four stat cards, a marks-over-time line chart, a submission status donut, upcoming tests with Upload buttons and recent activity with status badges
Student dashboard
Decision 02

Upload says why it is disabled

One large drop zone with the rules up front. When the button is off it gives the reason, such as the deadline has passed, instead of simply greying out. A student can replace a paper only while it is still Uploaded.

Fig. 03
Upcoming test page with an upload area, the allowed file types and size, the deadline and the maximum marks
Upcoming test with the upload rules
Decision 03

Mentors get a queue, oldest first

Pending, In review and Completed tabs with counts, sortable columns and a per-test filter. The queue shows only what is needed to pick the next paper, never marks or file names. Starting a review locks the student's upload.

  • Oldest first
  • Start review
  • Locked once started
Fig. 04
Mentor review queue with Pending, In review and Completed tabs, a table of two uploaded papers with Download and Start review buttons
Review queue
Decision 04

Marks, feedback and the corrected sheet in one place

A three-step timeline (Uploaded, In review, Corrected) with timestamps, then the returned marks and feedback. The student sees the result as soon as it is returned.

Fig. 05
Submission detail with a timeline of uploaded, in review and corrected steps, followed by the returned marks and written feedback
Mentor submission detail, corrected
Decision 05

Admin sees what needs attention, as sentences

The dashboard turns problems into plain sentences with a next action, such as 'Students have no mentor, so their uploads have nowhere to go' with an Assign mentors link.

  • No mentor
  • Awaiting publishing
  • Waiting over 3 days
  • Overdue tasks
Fig. 06
Admin dashboard with four count cards, a Needs attention list with action links, a mentor workload bar chart and a submission status donut
Admin dashboard

Act 3

Dark mode and phones

Light is the default. Dark is a full-parity option built from the same tokens, not a separate stylesheet: never pure black, indigo lightened, chart colours re-tuned in the same order. Students will often be on phones, so every page was checked at 360 px in both themes.

Fig. 07
Student dashboard in dark mode with the same cards, chart and donut on dark surfaces
Student dashboard in dark mode
Fig. 08
Student dashboard on a phone with the stat cards stacked in one column
Student dashboard on a phone
Fig. 09
Phone screen with the navigation slid over from the left
Slide-over navigation
Fig. 10
Review queue on a phone with tabs and filter stacked above a scrolling table
Review queue on a phone

0

axe violations

On every page, in both themes.

100

Lighthouse accessibility

Sign-in page, mobile. Measured on a local production build.

Act 4

What is done, and what is not

All 20 build steps and the admin dashboard are built and tested. Nothing is live yet, and no real students have used it: the build was driven by a written spec, not by user research. Usability sessions, the privacy choices (retention, deletion, consent for minors) and a card layout for wide tables on small screens are the next steps.

Role
Product owner and UX designer
Built with
Claude Code, in 20 steps (10 to 22 Oct 2026)
Roles
Student, Mentor, Admin
Status
Built and tested locally, not deployed

Define tokens and states before screens, and let one simple status flow drive the whole product.