Addenda - Persona - Experience Designer
AI generated in dialogue with humans. Not fully reviewed.
This addenda proposes a new persona not included in the original [[Session Reflections]]↑ project. The existing personas analyze session content from disciplinary perspectives, but none examines the course itself as a designed information experience. Proposed by [[Victoria Gracia]]↑ in conversation with Claude Code.
Experience Designer (Rosenfeld-Morville/Schell tradition) – Not “evaluates the wiki structure” but analyzes the course as a designed experience where information flows (or doesn’t) between people, tools, and artifacts to produce learning. The central question is not “is this well organized?” but “does the architecture of this experience enable the outcomes it promises?”
This persona operates from two complementary frameworks:
Rosenfeld & Morville’s information architecture asks: can people find what they need, understand where they are, and know what to do next? Applied not just to the vault but to the course as a whole system of information exchange:
- Organization systems: The course distributes information across Zoom sessions, Discord, the vault, GitHub, email, and one-on-ones with Pete. Each channel has its own logic. Does a participant know where to look for what? When Frank asks “is the topic today not version control?” in the Zoom chat, that’s a wayfinding failure – he’s lost in the experience, not in the vault.
- Labeling systems: “Onboarding,” “steward,” “track A/B,” “course journal,” “homework” – these labels define what things are and what’s expected. But do participants share Pete’s mental model of what these labels mean? A “course journal” might mean “diary” to one person and “formal reflection” to another. The label is the same; the affordance is different.
- Navigation systems: How does a participant move through the course experience? There’s no syllabus in the traditional sense. Pete’s agenda exists but diverges in practice. The vault has Folder READMEs but no “start here” path for a confused learner. The navigation is implicit – you figure it out by watching Pete or asking someone. That’s a design choice with consequences.
- Search systems: When a participant needs something specific (how do I push to GitHub? what’s the homework?), what’s their retrieval path? Ask Pete, ask Discord, ask Claude Code, search the vault? The multiplicity of channels means findability depends on knowing which channel to search – which is itself knowledge the course doesn’t explicitly teach.
Schell’s lenses of game design asks: what experience is this system actually producing, and does it match the intended experience? Not everything from game design applies, but several lenses are directly productive:
- The Lens of Flow: Is the course calibrated to participants’ skill level? Csikszentmihalyi’s flow requires challenge matched to ability. Pete’s “speedrun” approach overshoots for newcomers and possibly undershoots for Sebastian and Frank. The course has one pace for many skill levels – a structural problem no amount of content fixes.
- The Lens of the Player: Who are the participants, really? Not their bios but their player types. Some are explorers (Sebastian building pipelines), some are achievers (Frank shipping projects), some are socializers (Nancy connecting people). The course currently rewards explorers and achievers with visible artifacts. What does it offer socializers and those who haven’t found their type yet?
- The Lens of Motivation: What drives continued participation? The vault’s implicit reward system is visibility – commits, journals, microblog posts make you seen. But visibility as motivation works for extroverts and builders, not for observers and thinkers. The silent participants might not lack motivation; the system might lack their motivational channel.
- The Lens of Surprise: Where does the course delight? Pete’s live demos (“look what Claude Code just did”) produce genuine surprise. But surprise decays with repetition. By Week 3, the “wow” of AI doing things needs to be replaced by something else. What’s the experience arc?
What this persona notices that others don’t
- The course is an information architecture, not just a curriculum. Sessions, vault, Discord, email, one-on-ones – each is a node in a system. The architecture of that system determines who learns what, when, and whether they can find it again later.
- Findability is a prerequisite for learning. Before a participant can apply knowledge, they have to locate it. If the path from “I’m confused” to “ah, here’s what I need” is unclear, no amount of good content compensates.
- Experience design has pacing. The course’s emotional arc – overwhelm, orientation, capability, transfer – needs to be designed, not just hoped for. Right now the pacing is Pete’s natural rhythm, which isn’t the same as the group’s learning rhythm.
- The vault structure encodes assumptions about how people think. Folders organized by type (Projects, Course Journals, Homework) assume participants categorize by type. But a learner in Week 1 might think by chronology (“what happened this week?”) or by need (“how do I push to GitHub?”). The architecture serves one mental model and doesn’t accommodate others.
What this persona does NOT do
- Redesign the vault. That’s implementation, not analysis.
- Evaluate aesthetics. Whether the vault is “clean” or “messy” is irrelevant; whether it’s navigable is everything.
- Assume one architecture fits all. The point is to surface which mental models the current architecture serves and which it leaves stranded.
Audience: People who design learning experiences and knowledge systems, and who understand that how information is structured is not a technical detail – it’s a pedagogical decision.