Verba — LMS & Gamified Learning Platform

Product & Design Specification — v1.0, 21 July 2026

Verba is a learning management and operations platform for a language tutoring center. It runs the business side (people, courses, money, competitions) for operators and teachers, and delivers a gamified mobile learning app for students. This document explains what was designed, why, and how the pieces connect.

It accompanies four interactive prototypes:

SurfaceWhoArtifact
Operator Console (desktop)Operator / adminoperator-dashboard.html
Teacher Workspace (desktop)Teacherteacher-dashboard.html
Teacher app (mobile)Teacherteacher-mobile.html
Student app (mobile)Studentstudent-mobile.html

1. Design Direction

Why "Verba"

Short, means "words" — legible across every language the center teaches, and doesn't privilege English, Mandarin, Japanese, Korean or French over one another.

Color

You asked for light blue that "isn't so light it fails to register." A pale pastel blue disappears against white; it also reads as low-confidence for a product that handles money and student records. The palette instead uses a mid-saturated cerulean (#2E7DE1) as the one accent, carried by a scale from a near-white blue-tinted background (#F3F7FC) up through a deep ink-navy (#0B2C5E) used for headings and emphasis.

Every neutral (borders, muted text, shadows) is blue-tinted rather than pure grey, so the whole UI reads as one family instead of "blue accent on generic grey admin template." Dark mode isn't an inverted afterthought — it's a second calibration of the same tokens, validated for contrast on its own navy surface.

Two Visual Registers, One System

The operator and teacher desktop tools are calm and data-dense — this is where someone reconciles payroll or checks who hasn't clocked in, and the UI gets out of the way. The student app is the same blue family but turned up: gradient cards, a gold XP color, a coral streak flame, circular progress rings.

Same design tokens, different amplitude — a teacher and a student on the same platform should feel like siblings, not strangers.

Reference Material Used

The Designo LMS dashboard (Figma Community) supplied the desktop information-architecture patterns (sidebar + card grid, calendar, status-pill tables) — reskinned entirely in Verba's palette rather than copied. The GlobalTalk language-platform file supplied the mobile game grammar (circular sprint timer, hearts-based listening drill, CEFR level chips) — again rebuilt, not reused, and extended with a new Picture Match game since the source file didn't cover the "image game" you asked for.

Layout and interaction choices also follow Figma's published UI principles: hierarchy, progressive disclosure, consistency, contrast, accessibility, proximity, alignment.

Type & Components

System font stack (Segoe UI / -apple-system) at a disciplined scale — this is a utility product used for hours at a time, not a marketing page, so legibility and consistency beat typographic personality. Tabular numbers wherever digits line up in a column (money, attendance %, XP). Status is never color-only: every pill carries a dot + label, every chart has a legend or direct label.


2. Who Does What

CapabilityOperatorTeacherStudent
Manage student accounts✅——
Manage teacher accounts✅——
Manage courses & study material✅Upload to own classesView / consume
Assign teacher ↔ class✅Appeal a slot—
Assign student ↔ class✅—Join assigned class
View own attendance—✅✅
View all attendance✅Own students only—
Clock in/out (face capture)—✅—
View/verify student payments✅—Pay & view own invoices
Run teacher payroll✅View own payslip—
Set bonus criteria & amounts✅View own breakdown—
Post a competition✅——
Assign competition PIC (teacher)✅——
Manage competition participants✅For own competitionsApply / view status
Give reward to winner✅—Receive
Give teacher bonus✅Receive—
Post Hall of Fame / Memories✅ProposeView
Apply for leave—✅—
Request/appeal teaching schedule—✅—
CounselingRespondRequest (to operator)Request (1:1)
Play games / earn XP——✅
Teacher forum—✅—

This matches the roles you specified; §6 proposes a few additions.


3. Screen-by-Screen Tour

3.1 Operator Console (desktop)

Sidebar grouped into People (Students, Teachers), Academics (Courses & Material, Classes & Scheduling, Attendance), Finance (Payments & Payroll), Engagement (Competitions, Hall of Fame & Memories), plus an Overview.

3.2 Teacher Workspace (desktop)

Mirrors the operator's information architecture at teacher scale: Dashboard, My Students (progress + last activity, not just a roster), Schedule (weekly grid with a "Request off" action per slot — this is the appeal/rejection mechanism you asked for), Attendance (own clock-in log), Leave (apply + history), Salary & Bonus (payslip plus a transparent breakdown of exactly which behaviors the bonus rewards — satisfaction score, punctuality, retention, competition results), Teacher Forum, Counseling (request time with the operator), My Competitions (PIC view: training checklist, documentation upload), and the shared Hall of Fame & Memories.

3.3 Teacher App (mobile)

Five tabs: Home, Schedule, Students, Forum, Me. The one thing this surface does that desktop can't: clock-in with face capture — a full-screen camera view with a face-alignment guide, a capture action, and a confirmation screen with timestamp and branch. Everything else is a lighter-weight mirror of the desktop tool for on-the-go use between classes.

3.4 Student App (mobile) — The Gamified Core

Five tabs: Home, Learn, Games, Compete, Me.


4. Core Flows

Enrollment → Class → Attendance

Operator creates the student record and enrolls them in a language/level → operator assigns a teacher to that class (or a class carries an "unassigned" flag until they do) → each session, both the student (implicitly, via the platform) and teacher (via face-capture clock-in) generate attendance records → those roll up into the attendance % operators and teachers both see against that student or class.

Money

Student payment → operator verifies (bank transfer proof, in the prototype) → invoice flips to Paid → feeds the revenue chart on the operator overview. Independently, at month end the operator runs a payroll pass per teacher: base salary + a bonus computed from the criteria in §3.2 → teacher sees the same breakdown on their own payslip, so the number is never a surprise.

Competition Lifecycle

Operator posts a competition and names a teacher as PIC → students apply from the Compete tab → PIC trains/tracks participants against a checklist and uploads documentation → operator marks results and issues rewards to student winners and a performance bonus to the PIC teacher → the win becomes a Hall of Fame entry, and event photos become a Hall of Memories post. This is the loop that ties competitions, bonuses, and the two "Hall of" features together instead of leaving them as separate features.

The Gamification Loop (Student)

Play a game → earn XP (levels up the profile), gems (a soft currency), and streak credit → XP and streak surface immediately on Home so progress is visible without hunting for it → streak creates a reason to open the app daily even on days without a scheduled class; XP/leaderboard creates a reason to play more than the minimum.

This mirrors why Duolingo's streak and XP mechanics work: the reward has to be immediate and the competition has to feel winnable, not just the top student always winning. The Hall of Fame leaderboard is a top-5 list, not "you're #340," because ranking systems only motivate when a student can see themselves moving up it.


5. Data Model (Indicative)

User (id, role: operator|teacher|student, name, email, phone, avatar)
Student (user_id, level_by_language[], enrolled_courses[], guardian_contact?)
Teacher (user_id, subjects[], base_salary, rating, bonus_criteria_scores)
Course (id, language, level, materials[])
Material (id, course_id, type: reading|listening|worksheet|flashcard|game_bank, url)
Class (id, course_id, teacher_id, schedule[], roster: student_id[])
AttendanceRecord (id, user_id, class_id?, date, check_in, check_out, method)
LeaveRequest (id, teacher_id, date_range, type, status)
ScheduleAppeal (id, teacher_id, class_id, date, reason, status)
Payment (id, student_id, course_id, amount, due_date, status)
PayrollRun (id, teacher_id, period, base, bonus_breakdown{}, net, status)
Competition (id, title, language, date, pic_teacher_id, status)
CompetitionEntry (id, competition_id, student_id, status, result)
GameSession (id, student_id, game_type, level, score, xp_earned, completed_at)
HallOfFameEntry (id, student_id, achievement, competition_id?, date)
MemoryPost (id, title, media, date, posted_by)
ForumThread (id, author_id, category, title, replies[])
CounselingRequest (id, requester_id, requester_role, topic, status, notes)

6. Beyond the Brief — Proposals

You said I could propose things outside what you described. In rough priority order:

  1. Placement / diagnostic test before enrollment. Right now level is assigned by the operator; a short adaptive placement test (itself gamified, reusing the Sprint/Listening engines) would make level assignment self-service and consistent, and gives the student their first XP before they've even "started."
  2. Streak-freeze / streak-repair. Duolingo's research (cited by multiple independent case studies) shows a purchasable or earnable streak freeze meaningfully improves 14-day retention because it removes the all-or-nothing anxiety of a missed day. Worth a gem-cost freeze in Verba's economy.
  3. Parent/guardian view. If a meaningful share of students are minors (common for language centers), a lightweight read-only view — attendance, payment status, upcoming competitions, Hall of Fame mentions — for a parent account would reduce "is my kid actually going to class" support requests without giving parents access to the student's social/gamified layer.
  4. Push/reminder notifications. Class-starting-soon, streak-about-to-break, competition-application-closing, payment-due. None of this is designed here (it's not a screen), but it's the mechanism that makes the streak and XP systems actually pull people back in daily rather than only working for people who already remembered to open the app.
  5. Referral program. A student who refers a friend earns gems/XP; a teacher who converts a trial student earns a small bonus line item next to the existing bonus criteria. Cheap to build on top of the existing bonus/XP ledgers since both already exist.
  6. Multi-branch support. The teacher clock-in confirmation already shows a branch name ("Verba Kemang Branch") as a placeholder — if Verba operates more than one physical location, branch becomes a first-class filter on the operator's attendance, scheduling and revenue views, not just a label.
  7. Trial-class conversion tracking. A funnel view (trial booked → attended → converted to paid enrollment) would give the operator a number that "revenue this month" alone doesn't show: whether the pipeline feeding the school is healthy.

7. What's Intentionally Not Designed Yet

Settings/roles administration, notification center UI, in-app messaging/chat threads, payment gateway integration screens, and the Reading game's actual play screen were scoped out of this first pass to keep the four prototypes focused — flagging them so they're a visible backlog rather than a silent gap.