Twig Science: Live Class Monitoring Report
In compliance with this project's NDA, proprietary screens and internal documentation cannot be shared. This case study focuses on the design process, key decisions, and outcomes; with visuals sourced from the product's publicly available help documentation.
ROLE
Senior UX Designer
TEAM
Product Manager
Engineering
Junior UX Designer
TIMELINE
3 months
Jan - Mar, 2022
TOOLS
Adobe XD
Miro
01. OVERVIEW
This case study explores how I designed a real-time monitoring system to close a critical competitive gap, solving the "cluttered dashboard" problem through progressive disclosure and question-first architecture.
About Twig Science
Twig Science is a K-8 phenomena-based science curriculum platform serving 1M+ students (now part of Imagine Learning). The platform competed directly with other assessment space, where live class monitoring had become table-stakes for winning RFP evaluations and renewals.
My Role
I was the Senior UX Designer, working with a junior designer. I owned research (competitive analysis of Edulastic, Nearpod, Formative), IA (question-first structure, 3-tab system), interaction design, and stakeholder alignment. I collaborated daily with engineering on technical constraints and presented designs to stakeholders and teachers for validation before handoff. The junior designer supported component execution under my direction.
02. PROBLEM
Business Problem
Competitive analysis revealed live monitoring as a must-have feature in the K-8 assessment market. Competitors had established real-time visibility as table-stakes, and we were losing RFP evaluations and renewal deals specifically because this capability was missing from Twig Science. Sales needed feature parity to compete.
User Problem
Teachers had no visibility into how students were approaching assignments during class time. Existing post-class reports showed final scores and correct/incorrect answers, but teachers couldn't:
Can't identify struggling students before they give up
Can't detect copy-pasting behavior
Can't see which questions trip up the whole class
Can't intervene when help is most needed
"By the time I grade assignments after class, it's too late to help the students who were struggling."
- From a teacher
03. Discovery & Research
Working within constraints
Without direct 1-on-1 teacher access, I embedded research into every available touchpoint:
Client Call Observations
Asked targeted questions to the teachers during scheduled check-ins
Validated pain points with 3-5 teachers across calls
Gathered context on classroom monitoring workflows
Stakeholder Workshops
Aligned on feature requirements with PM and client leads
Prioritized must-have vs. nice-to-have features
Established technical feasibility parameters with engineering
Competitive Analysis
Audited Edulastic, Nearpod & Formative's live monitoring feature
Identified UX gaps and differentiation opportunities
Mapped feature requirements for sales parity
Key Insights
All competitors showed what students answered. None showed how students were working with the same visual clarity.
Twig Science's Differentiation:
Question-first table layout → Pattern recognition ("Q7 is hard for 15 students")
Live screen thumbnails → Visual confirmation of activity (not just text responses)
Per-student time tracking → Individual struggling students visible, not just class averages
Copy-paste detection as visible label → Scannable during class, not post-analysis only
Strategic Positioning:
We weren't just achieving feature parity - we were rethinking the mental model from "monitor individual students" to "diagnose class-wide learning patterns."
04. Defining the Design Challenge
How might we...
Visualize 10-15 students answering different questions simultaneously without overwhelming the teacher?
Show "how students think" (not just "what they got wrong") in a scannable format?
Integrate seamlessly into existing teacher workflows so adoption feels natural, not disruptive?
05. DESIGN PROCESS
The Core IA Decision
I explored two fundamentally different mental models:
Model A: Student-First
Structure:
Rows = Students
Columns = Metadata (score, time)
Interaction:
Click student → see all their answers
Why it didn't work:
Doesn't surface which questions are causing widespread issues
Model B: Question-First (Chosen)
Structure:
Rows = Students
Columns = Questions
Each cell = mini-preview of activity
Interaction:
Click question → see all responses
Why it won:
Teachers think "which concept is hard?" not "which student is struggling?"
Validated with teachers: Presented both approaches in stakeholder meetings. Teachers confirmed question-first aligns with how they intervene (re-teach a concept, not micromanage individuals).
Solving the "Clutter" Problem: 3-Tab System
Instead of cramming everything into one view, I separated into three focused modes:
Design Rationale:
Teachers choose their view based on what they need right now and not forced to process all data at once.
State-Aware Architecture
Rather than building a separate "live monitoring tool," I designed a reporting system that adapts to assignment state:
NOT STARTED → IN PROGRESS → IN GRADING → DONE
In Progress state: Answers Preview tab shows live thumbnails
All other states: Same UI, but static final responses (not "live"; except Not Started)
Why this matters:
Teachers don't learn multiple tools. Live monitoring feels integrated into the assessment workflow they already know.
What was Intentionally Left Out
Not every metric belongs in every view. Each report serves a clear need - prevents cognitive overload.
Time-on-Question:
Teachers told us they didn't need it here (already in separate Assignment Report). Prevented feature duplication.
Copy-Paste Detection:
Designed but deprioritized for V1 launch (technical complexity vs. timeline).
Inline Grading:
Separated grading into its own workflow (GRADE ASSIGNMENT button redirects).
Monitoring ≠ evaluating; kept these tasks distinct.
Collaboration with Engineering
I embedded technical feasibility checks into the design process (not after handoff).
Handoff:
Wrote detailed user stories with acceptance criteria in Jira, participated in sprint planning
Result:
Zero major design changes during development. 100% fidelity shipped.
06. SOLUTION
A State-Aware, Tab-Based Reporting System
Top Bar (consistent across all other reports):
Report Title
Class and assessment dropdowns
Assignment metadata (start/due dates)
After mapping the assignment lifecycle, I identified two high-frequency teacher actions and promoted them to the top bar: VIEW ASSIGNMENT (check setup/metadata) and GRADE ASSIGNMENT (score responses).
Assignment Status Indicator:
Not Started / In Progress / In Grading / Done
PRESENT button (share view on projector)
All screenshots sourced from publicly available Twig Science help documentation. Original design files under NDA.
Tab 1: Summary (Default View)
Color-coded status icons: ✓ Green (correct), ✗ Red (incorrect), ◐ Yellow (partial), ○ Gray (not started), ⬤ Gray Solid (attempted)
Scannable in 5 seconds: Teacher can identify struggling students at a glance
Question-first structure: Each column = one question. Spot class-wide patterns instantly
Tab 2: Details
Numeric scores toggle: Switch between absolute (1/1, 0.5/1) and percentage (100%, 50%)
Hyphen for ungraded responses: Open-ended questions show "-" until manually scored
Quick math: See class performance at a glance
Tab 3: Answers Preview (Live Monitoring Core)
Live thumbnails (In Progress state only): See what students are doing in real-time
Question-specific capture: Thumbnail shows only the question section, not full browser
All attempted questions visible: Not just current question. See student's progression through assignment
Static thumbnails (other states): Final responses after assignment ends
Question-First Modal
Question-focused view: Shows all student responses to Q3 (not one student's responses to all questions)
Student dropdown: Toggle between students without closing modal
Full response displayed: MCQ: selected option + all choices. Essay: typed text. Question stem included.
Reinforces diagnostic thinking: "Why is Q7 hard for everyone?" vs. "What did Student One answer?"
Design Decisions Explained
Why question-first modal (not student-first)?
Teachers intervene by re-teaching concepts, not tutoring individuals. Question-first aligns with instructional practice.
Why separate grading workflow?
Monitoring (observe students working) ≠ Grading (score responses). Separating these prevents conflating observation with evaluation.
Why no time-on-question in this view?
Already exists in separate Assignment Report. Prevents feature duplication and keeps each report focused.
07. Impact & Outcomes
What Shipped
Business Impact
Competitive Positioning:
Live Class Monitoring became a sales talking point in competitive deals. Feature closed the gap that was blocking new sales and renewals.
Teacher Feedback (Post-Launch Demo):
"Finally see what students are actually doing, not just what they got wrong."
Note on Metrics:
Detailed usage analytics (adoption rate, time saved per teacher, frequency of use) were tracked internally by Twig Science but not shared with the design team due to client NDA. Post-launch impact was validated through qualitative teacher feedback, sales confirmation, and zero performance issues.
08. REFLECTION
What Worked
Progressive Disclosure Over Data Density
The 3-tab system solved the "overwhelming" problem. Teachers choose their view based on immediate need, not forced to process everything at once.
Systems Thinking
Not cramming every metric into every report. Live Class Monitoring focuses on real-time progress. Time-on-question lives in Assignment Report. Each serves one clear need.
What I'd Change
Validate IA Earlier with Teachers:
I chose question-first structure based on stakeholder input and my hypothesis about teacher mental models. While it validated in demos, I could have de-risked this earlier with a quick card-sorting exercise via client calls: "Here are 10 students and 5 questions, show me how you'd organize this to monitor a class."
Why it matters:
Would have validated the biggest design decision with direct teacher input, not just assumptions, even within access constraints.
