UX Writing · Technical Communication

Tensegrity Structure
Instruction Set

Designing a build guide for mixed-ability users — and discovering where documentation fails through real usability testing.

Role
Sole Designer & Researcher
Context
TWC 150 · ASU
Methods
Usability Testing · Iterative Design
Year
2026
View Instruction Set PDF

The Challenge

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."

Two Very Different Users

I deliberately selected testers with contrasting profiles to stress-test the instructions across a wide ability range.

  • Ethan, 15

    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!"

  • Kevin, 40

    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.

Where the Instructions Broke Down

Mapping the friction points across both testers revealed a clear cluster in the threading and tensioning phase.

  • Step 1

    Bundle count error — Ethan made 5 W-2' bundles instead of 6. Checklist wasn't visually prominent enough to prompt verification.

    Ethan
  • Step 3

    Hands-free problem — Hot glue + holding the post upright = three hands needed. Both testers improvised; Ethan required his sister to intervene.

    Both
  • Step 6

    Two-hands bottleneck — Threading while holding both K frames and measuring 10 cm simultaneously. No workaround provided. Both testers improvised independently.

    Both
  • Steps 7–8

    Missing routing diagram — The most critical structural decision (cross-diagonal vs. same-side cable routing) was never stated. Kevin inferred from tensegrity principles; Brian guessed.

    Both
  • Step 8

    No adjustment method — "Lay flat → adjust → stand up → check" loop had no systematic guidance. Kevin did 3 iterations over 12 minutes. Brian nearly quit.

    Both
  • Steps 5 & 9

    Vague knot instruction — "Tie a secure knot" is not actionable for a craft novice. Kevin used a double half-hitch from prior knowledge; Brian had no equivalent fallback.

    Both

Three Core Design Failures

  • Missing spatial diagram for cable routing

    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.

  • Physical constraints were invisible to the designer

    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.

  • Vague action verbs didn't translate across skill levels

    "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.


What Changed in the Final Draft

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.

Identified Problems

  • No diagram showing which top corner connects to which bottom corner
  • "Tie a secure knot" with no type specified
  • No guidance for stabilizing parts during hot glue steps
  • Bundle checklist present but visually buried in text
  • "Adjust until it looks equal" — subjective and open-ended
  • Step 6 assumed a free hand that didn't exist

What Was Actually Fixed

  • Troubleshooting table added — covering the knot, cable routing, and adjustment loop failure states in one place

What I Learned

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