Designing a build guide for mixed-ability users — and discovering where documentation fails through real usability testing.
UX Writing · Instructional Design · Usability Testing · Visual Communication · Iterative Design
Overview
Tensegrity structures — rigid parts held in balance by tension threads, never touching — are elegant in concept but surprisingly hard to build from written instructions. The challenge was to design a build guide clear enough for a complete beginner, robust enough to satisfy an experienced engineer, and honest enough to surface its own failures through real testing.
This project follows a full UX documentation cycle: design → test with real users → identify friction → iterate.
"The problem wasn't that users lacked skill. Both testers got stuck in the same places — which meant the problem was in the design, not the user."
Research
I deliberately selected testers with contrasting profiles to stress-test the instructions across a wide ability range.
High school sophomore · Low crafting confidence
Skims text, relies on photos. Default response to confusion: ask his sister, not re-read. Short frustration threshold — multiple steps lead to sighs and stepping away.
"I can do it myself." → five minutes later → "Emma, help me!"
Mechanical Engineer · 15+ years experience
Reads the full manual before starting. Trusts structural intuition. High bar for clarity — if the instruction isn't systematic, he flags it immediately.
"Specify the knot type — 'secure knot' means nothing to someone without rigging experience."
Ethan took ~60 minutes. Kevin took 33 minutes. Both got stuck in the same places — Steps 6–9 — which immediately pointed to the instruction design, not the users' abilities.
Key Findings
Mapping the friction points across both testers revealed a clear cluster in the threading and tensioning phase.
Bundle count error — Ethan made 5 W-2' bundles instead of 6. Checklist wasn't visually prominent enough to prompt verification.
EthanHands-free problem — Hot glue + holding the post upright = three hands needed. Both testers improvised; Ethan required his sister to intervene.
BothTwo-hands bottleneck — Threading while holding both K frames and measuring 10 cm simultaneously. No workaround provided. Both testers improvised independently.
BothMissing routing diagram — The most critical structural decision (cross-diagonal vs. same-side cable routing) was never stated. Kevin inferred from tensegrity principles; Ethan guessed.
BothNo adjustment method — "Lay flat → adjust → stand up → check" loop had no systematic guidance. Kevin did 3 iterations over 12 minutes. Ethan nearly quit.
BothVague knot instruction — "Tie a secure knot" is not actionable for a craft novice. Kevin used a double half-hitch from prior knowledge; Ethan had no equivalent fallback.
BothAnalysis
The most important structural decision in the entire build — which top corner connects to which bottom corner — was never explicitly shown. Photos of loose hanging thread give no routing information. An overhead schematic was entirely absent, and both testers had to guess or infer.
Several steps required three hands — a constraint obvious in testing but easy to miss when writing. The instruction assumed the builder had a free hand that was always occupied by the task. No staging tips, no prop suggestions.
"Secure knot," "adjust until level," "space symmetrically" — these phrases carry different meanings depending on what knowledge the reader brings. Expert users fill the gap with prior experience. Novice users are left without recourse.
Iteration
Due to time constraints, the revision focused on what could be addressed within the existing document structure — no reshoot of photos, no new diagrams. The one concrete addition was a troubleshooting table that consolidates the most common failure states identified during testing.
Reflection
The most valuable outcome of this project wasn't the final document — it was the gap between what I thought was clear and what actually worked under real conditions. I wrote every step from memory of having built it myself, which meant I assumed knowledge I'd already internalized: how to hold things, which direction cables run, what "secure" means physically.
Testing with two users at opposite ends of the skill spectrum made this gap impossible to ignore. The overlapping failure points — both testers struggling in Steps 6–9 — removed any possibility of attributing problems to individual skill differences. That's the kind of signal that only real testing produces.
If I were to do this again, I'd include a full overhead routing diagram before Step 7, specify knot type with a small inline illustration, and prototype the physical steps myself with a timer to surface every "three hands" moment before the instructions reach a user.
AI assisted with copy drafting · User testing conducted independently · All photos taken by me · Analysis & design decisions are my own