Case study

Ezra Dashboard

2025 — Present

FITA Academy — mentors & students

Ezra is the product I designed and built to fix a very human problem: at FITA Academy, mentoring students meant fragile attendance sheets, easy to lose or “reinterpret,” and no single place for mentors and learners to share the same truth. I channelled that into a dashboard for mentors—fed by a bot I named Ezra—plus a student view for hours and daily attendance, automations for batch-end reminders, Gmail-backed payment handoffs, and a path to subscription. What started as a tool for my own batches is now in discussion for an org-wide buy, with paid pilots from other mentors along the way.

Tools & languages
Figma · TypeScript · React · Vercel · WhatsApp · Automations · Gmail
Role
UX Design & Development
SSituation

At FITA, attendance sheets went missing, numbers got disputed, and students forgot to mark leave. As a mentor myself, I was living in the gap—no single honest record, no fair way to track what I was owed. Spreadsheets and group chats couldn't scale.

TTask

Build one system: a bot-fed mentor dashboard, a student progress view, and automations that run themselves. Attendance everyone trusts, earnings always visible, and a Gmail handoff on completion—zero extra admin.

AAction
01Mapped three real roles—coordinators, mentors, students—and traced the pain from assignment → class → mark → pay.
02Mentor dashboard: roster, batch timeline, total earned vs expected, attendance (manual + batch-end lock).
03Built Ezra bot: mentors add students in chat (name, phone, course, slot)—syncs to dashboard instantly, no double entry.
04Post-batch scheduler nudge: attendance confirmed while the session is still fresh in memory.
05Gmail integration: completion auto-sends payment email with the project link attached.
06Student view: hours to complete + daily attendance—same data as the mentor, visible on one screen.
RResult
One system everyone reads from—no more ‘which version is correct?’
₹50k in paid pilots from 5 mentors over 5 months—traction before any pitch.
Less WhatsApp chaos: faster attendance close, fewer payment reconciliations.
Academy-wide buy in discussion; subscription modal in build.

2.1 · UX process

Step 01

Field research in my own batches

I treated every mis-filed mark and every “can you resend the sheet?” as a signal. Student self-marking, coordinator handoffs, and my own end-of-day reconciliation became the first journey map before any pixel was sacred.

Contextual inquiryPain clusteringRole mapping (coordinator / mentor / student)

Outcome

A shared list of failure modes: missing data, no reminder cadence, and no student-visible mirror—enough to justify a product, not a prettier spreadsheet.

Step 02

Ezra as the data front door, dashboard as the brain

I didn’t want mentors to be data entry clerks. The bot is the human-shaped input; the dashboard is the structure. That split kept the interaction kind for tired hands at 9 p.m.

Conversational form designState sync (bot → DB → UI)Error recovery for half-entered students

Outcome

New students could appear in the roster without a second form, and the UI stayed the source of truth for money and status.

Step 03

Automation, honesty, and the path to a license

Reminders had to feel helpful, not nagging. Student views had to be explainable in one screen. The Gmail handoff had to be the last mile, not a new inbox problem. As peers paid to use the stack, subscription UX became as important as the dashboard grid.

Notification timingProgressive disclosure for payoutsPricing / subscription copy

Outcome

A story that works for a solo mentor and scales to “the academy buys it”—now under active development and negotiation.

Customer journey

01

Assignment

Goal

Coordinators place a new student with the right mentor and context

Pain

Handoffs live in DMs; mentor starts from scratch each time

Fix

Structured handoff the dashboard can read (course, slot, contact)

→ Fewer “who is this person?” moments on day one of class

02

Class + self-mark

Goal

Students mark attendance; mentors trust the day’s record

Pain

Sheets disappear; some students don’t mark; leave isn’t updated

Fix

Student view + explicit leave; batch-end truth pass with reminder

→ One version of the day, visible to both sides

03

Batch close

Goal

Mentor locks the session without a Sunday salvage mission

Pain

Reminders are social (“please update”) not systematic

Fix

Scheduler nudges when the batch window ends; manual override in-line

→ Attendance catches up to reality before pay conversations

04

Earnings + completion

Goal

Mentor sees money owed and completion state clearly

Pain

Payouts tracked in head; completion triggers ad hoc Gmail

Fix

Totals in dashboard; Gmail workflow with project link for payment ask

→ Less manual chasing; cleaner handoff at the end of the program

05

Scale

Goal

Other mentors and the academy can adopt the same pattern

Pain

One-off tool doesn’t survive procurement or support

Fix

Subscription / pricing; fit for org-wide buy under discussion

→ Path from side project to institutional product

User personas

Mentor · two parallel batches

Karthik

“I’ll fix the sheet on Sunday” — and Sunday never matches Friday’s truth.

Goals

Close each week knowing who was actually in the room, without cross-checking three chats.
See what he’s owed and what’s still open before following up for payment.
Onboard a new co-ordinator-assigned student without a 20-field form.

Pains

Sheets get “adjusted” and nobody agrees which version is official.
Students who skip self-marking create awkward money conversations at month-end.

Mentor · evenings only

Ananya

She’s great in class, allergic to admin at midnight.

Goals

A reminder that respects real batch times, not a generic daily digest.
Fast manual mark when the automatic story is wrong.
A calm view of who’s close to completion so she can line up the final project push.

Pains

Guilt and rework when she discovers missing marks a week late.
Fear of looking unfair when she corrects a student’s own mistake.

Student · self-paced attendance

Rahul

He shows up, but the sheet doesn’t always say so.

Goals

See the same attendance story his mentor will use for completion.
Know how many hours are left in the program without opening a spreadsheet.

Pains

Anxiety that one missed self-mark will derail his certificate or last payment step.
Confusion when the group chat says one thing and the “official” list says another.

Student · also working full-time

Divya

Leave and make-up days need to be visible, not buried in a DM thread.

Goals

Record leave and see it reflected in her progress view.
Finish with a handoff that already includes the project link and payment step—no mystery email chain.

Pains

Bilingual back-and-forth in WhatsApp that never gets copied to a master record.
Not knowing if she’s “done” until someone manually confirms.

SWOT

Strengths

  • Solves a lived, daily pain the designer actually runs in production class hours.
  • Mentor bot + dashboard split keeps input human and data structured.
  • Paid pilots from peers before the org deal: proof of pull, not only slideware.

Weaknesses

  • Single-academy context; some flows assume FITA’s rhythm until generalized.
  • Gmail and scheduler dependencies need careful error handling in v2.

Opportunities

  • Institutional license at FITA with coordinators on the same rails.
  • Clear subscription tiers as more mentors want Ezra for their own batches.

Threats

  • Policy changes in how attendance or payouts must be stored or audited.
  • Scope creep if every mentor asks for a different report before core stability ships.

Information architecture

FITA / Ezra
People
Coordinators · mentors
Students
Mentor core
Roster · batches
Pay & completion
Ezra
Intake in chat
→ Dashboard sync
Student
Hours · daily marks
Leave
Ops + growth
Gmail + scheduler
Subscription (roadmap)

FITA & Ezra

Project coordinators · Mentor dashboard (web) · Student progress view · Ezra bot (WhatsApp / chat) · Gmail + scheduler automations

Mentor dashboard

Roster by batch · Attendance (manual + batch-end) · Earnings: earned vs expected · New student (mirrors bot intake) · Completion → payment handoff trigger

Student view

Hours to complete · Daily attendance & leave · Completion status (aligned with mentor data)

Ezra bot

Capture student: name, phone, course, timing · Confirm updates · Pushes to shared roster (no re-type)

Automation layer

Post–batch end reminders · Gmail: payment + project link on completion · Future: subscription / billing entitlements

User flows

Coordinator → mentor → Ezra

01Coordinator assigns a new student to a mentor (course, batch, contact context).
02Mentor opens Ezra and confirms or adds the student: name, phone, course, session timing.
03Ezra writes to the same store the dashboard uses; roster updates without a second form.
04Mentor sees the new row in the right batch, ready for attendance and earnings rollups.

Batch day → mark → nudge

01Students are expected to self-mark; student view shows hours left and the day’s status.
02If reality differs, mentor can adjust manually; leave can be set when someone was absent on purpose.
03When the batch window ends, the scheduler pings the mentor to confirm the session’s attendance while memory is fresh.
04Earnings and completion flags stay in sync for payout conversations.

Completion → money + handoff

01Dashboard shows a student as complete against the program rules; mentor gets expected payout clarity.
02Gmail path triggers with the payment request and the project link attached—no re-written thread each time.
03Student and mentor share a paper trail; subscription / academy-wide licensing sits alongside for the next growth step.

Mobile · mentor flows

Two touchpoints the product runs on every week

Short vertical clips: lock attendance when the session is still fresh, and add a new student in Ezra so the same row appears in the web dashboard with no second data entry pass.

Same phone canvas mentors already use after class: quick taps, no context switch to a laptop until they want the full batch and money view in one place.

EZ-M-1 · Marking attendance
EZ-M-1.mp4

End-of-class path to record who was in the room — before the day turns into a spreadsheet rescue.

EZ-M-2 · Adding a new student
EZ-M-2.mp4

Capture name, course, and slot in flow; the roster updates for earnings and follow-up the same night.

Web · live overview

EZ-M · dashboard for the mentor

The web surface is where batches, money, and alerts meet — one pass before you talk to a student or send a payment follow-up.

Screen recording from the live product: day switches, headcount, earned vs potential, and which slot is asking for attention.

EZ-M · screen recording

Batch cards, headcount, earned vs potential, and where to drill in — one calm read before any money conversation.

Web · student view

Student dashboard

Each student gets their own link — a unique URL for their account only, so they can’t open another person’s page or read anyone else’s attendance and hours by guessing paths.

The student surface mirrors the truth the mentor sees: days completed, time left, and clear status for their batch — with no shared roster in the open.

EZ-2 · student dashboard

Walkthrough: personal progress on the student link — the same data contract as the mentor view, without exposing other students.

Upcoming: subscription checkout with Razorpay

A subscription layer is in the roadmap so mentors (and the academy) can pay for Ezra on a clear plan — Razorpay for checkout, renewals, and less manual back-and-forth for access. Same product story: from pilot users to an org-wide seat model without a new spreadsheet for every invoice.

Go-to-market plans & revenue to date

Planned GTM + traction

  • ·Live demos with mentors between batches—dashboard on a real afternoon, not a static deck.
  • ·Time-to-close attendance as the before/after story in coordinator channels.
  • ·Short screen recordings for approvers who need a two-minute yes from leadership.
  • ·Founder-mentor positioning: the roadmap is tied to the same class hours as users.

Earnings & next step

₹50k+ from 5 paid pilots; academy-wide deal in active discussion

Rolling access fees from other mentors over several months proved willingness to pay before any enterprise pitch. The next jump is a packaged subscription (with Razorpay) and a cleaner seat model for the academy buy—so revenue scales without billing work scaling with it.

UI design system

Multi-accent operational dashboard on near-black. Each data category owns a colour — green for healthy batches, amber for earnings, red for issues, blue for navigation tabs — so a mentor can scan batch status at a glance without reading every label.

Colour palette

#0d0d14

Deep dark

Page and card backgrounds — near-black with blue undertone

#06B6D4

Teal / cyan

Primary UI accent, user avatar chip, app icon

#4ADE80

Batch green

Active batch, graduated students, healthy/present states

#F59E0B

Earnings amber

Money / revenue metric icons — earned & potential

#EF4444

Warning red

Attention-needed batch, absent, issue states

#3B82F6

Active blue

Weekdays active tab, primary interactive button

Typography

Metric values / headings

Inter Bold

₹47,300, batch time slots — large tabular weight for quick reads

Roster / data rows

Inter Regular

Student names, status labels, 13–14px in dashboard rows

Badge labels

Inter Medium

LIVE SYNC ACTIVE, batch ID chips — operational, screams live data

Components

Metric summary card (Active / Graduated / Earned / Potential)Batch time cardLive sync badgeWeekdays / Weekends tab switcherStudent count chipStatus icon (green / red)Floating action button (+)View Details row

Design principles

  • Colour = category, not decoration — green / amber / red / blue each own exactly one data type
  • One dashboard, one view — batch status visible without drilling into sub-pages
  • Operational calm — density is high but colour hierarchy prevents scan overwhelm

UX strength (1–10)

Where the product is winning after real mentor + student use.

Trust in attendance8/10
Mentor time saved8/10
Student clarity (hours / day)7/10
Automation fit (nudges, Gmail)7/10
Readiness for org / subscription6/10

Learnings

Build it for yourself first—if it doesn’t survive your own last batch, it won’t ship to peers.

Attendance is a trust product: same numbers for student and mentor, or every feature rebuilds distrust.

Two surfaces are enough—cash + calendar for mentors, hours + marks for students.

Back to home