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:
| Surface | Who | Artifact |
|---|---|---|
| Operator Console (desktop) | Operator / admin | operator-dashboard.html |
| Teacher Workspace (desktop) | Teacher | teacher-dashboard.html |
| Teacher app (mobile) | Teacher | teacher-mobile.html |
| Student app (mobile) | Student | student-mobile.html |
Short, means "words" — legible across every language the center teaches, and doesn't privilege English, Mandarin, Japanese, Korean or French over one another.
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.
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.
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.
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.
| Capability | Operator | Teacher | Student |
|---|---|---|---|
| Manage student accounts | ✅ | — | — |
| Manage teacher accounts | ✅ | — | — |
| Manage courses & study material | ✅ | Upload to own classes | View / 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 competitions | Apply / view status |
| Give reward to winner | ✅ | — | Receive |
| Give teacher bonus | ✅ | Receive | — |
| Post Hall of Fame / Memories | ✅ | Propose | View |
| Apply for leave | — | ✅ | — |
| Request/appeal teaching schedule | — | ✅ | — |
| Counseling | Respond | Request (to operator) | Request (1:1) |
| Play games / earn XP | — | — | ✅ |
| Teacher forum | — | ✅ | — |
This matches the roles you specified; §6 proposes a few additions.
Sidebar grouped into People (Students, Teachers), Academics (Courses & Material, Classes & Scheduling, Attendance), Finance (Payments & Payroll), Engagement (Competitions, Hall of Fame & Memories), plus an Overview.
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.
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.
Five tabs: Home, Learn, Games, Compete, Me.
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.
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.
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.
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.
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)
You said I could propose things outside what you described. In rough priority order:
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.