Session 16 — User Testing + Chart.js Graphs

M4 — User Testing May 2026 @resist @shift

What I Did

Ran external user testing with two participants: age 21 and age 58. Both used the Reaction Time Test and Bilateral Coordination Test. Fixed the red dot collection bug. Added Chart.js graph visualization with toggle pills. This session produced the clearest evidence that the "track over time" value proposition works — both users asked about seeing their history.

User Testing Findings

Both testers validated the core concept — they understood what they were measuring and found it meaningful. Both asked "where do I see my results over time?" before reaching the history page. That question was the most important finding of the session: the tracking value proposition is compelling without being explained.

The age 58 tester provided the most useful feedback: the practice phase needed more explicit instruction, and the camera indicator (whether the camera was detected) wasn't prominent enough.

AI Interactions

Red dot bug fix: A bug prevented users from collecting the first dot (ID=0). Classic JavaScript falsy value problem: if (dot.id) evaluates to false when id === 0.

@shift — ID=0 Falsy Value Bug

The bug: dots with ID 0 couldn't be collected because if (activeDot.id) evaluated to false when ID was zero. JavaScript's falsy value behavior: 0, null, undefined, and empty string all evaluate to false. The fix: if (activeDot.id !== null) — explicit null check instead of truthy evaluation. This is the kind of bug that takes 30 seconds to fix once you know what it is, and hours to find if you don't know JavaScript's type coercion rules.

Chart.js implementation: User testing confirmed both testers wanted graphs of their performance over time. Added Chart.js 4.5.0 with zoom plugin.

@resist — Blue+Red not Green+Red

AI suggested green for the left hand and red for the right hand — a standard data visualization convention. I chose blue for left and red for right. When the two lines overlap or cross (indicating changing symmetry), blue+red produce a readable overlap. Green+red produce muddy brown at the intersection, which is exactly where the most interesting data lives — when the hands switch dominance or fatigue sets in asymmetrically. Color choices in data visualization should be made based on what happens at the overlap, not just what each line looks like independently.

What I Learned

User testing validated what research suggested: people want to track their performance, and they find it meaningful to do so. But the testing also revealed what I hadn't anticipated: the 58-year-old tester had much more trouble with the camera permission flow than the 21-year-old. That's an accessibility issue for M5.

The JavaScript falsy value bug is a reminder that code that "works in testing" can fail on real data. ID=0 never appeared in my own testing because I'd added dots in a different order.

Quarter Question Connection

User testing confirmed the quarter question is answerable for real people, not just in theory. A 58-year-old participant found the bilateral coordination test meaningful and wanted to track their performance over time. That's the quarter question answered in a person.

What's Next

Session 17: M4 complete. Compile Records of Resistance. Deploy to Vercel. Build the Fine Motor Precision Test. Shelve Rhythm Sync to M5.

← Session 15 Session 17 →