[Arno Beck and Sage Fell at the table. No facilitator. Open table rules.]
2026-02-28 · open-table · Facilitated by none (open table)
We need a way for non-technical people to experiment with room formats and creating new characters. Right now, my wife (Daga) will be the only person invited to our Slack, but maybe other ways (like GUI) would be more appropriate to guide them through the creation? I will only invite trusted people there for now.
[Arno Beck and Sage Fell at the table. No facilitator. Open table rules.]
Let me start with the actual failure. Right now, if Daga wants to create a character, what does she see? A YAML file. A schema document. A markdown template with fields like contamination_risk and quality_test. There is no affordance here — nothing in the interface that tells her what she’s allowed to do, what the system expects, or what happens if she gets it wrong. This isn’t a knowledge gap. It’s a design gap. The system has no signifiers for a person who hasn’t already internalized its vocabulary.
I agree it’s broken, but I think you’re already framing the solution too narrowly. You’re going to say “add labels, add tooltips, make the schema readable.” And that fixes the error — but it doesn’t fix the understanding. Daga doesn’t just need to fill in a character card correctly. She needs to understand what a character does in this system. What it means for a character to have a lens. What happens when two characters with overlapping sources sit in the same room. You can’t get that from a form. You get that from seeing it happen.
I’m not proposing tooltips. I’m proposing that the system should make its constraints visible. Right now there are three specific failures. One: the schema is invisible — you have to read a separate document to know what fields exist. Two: there’s no preview — you write a character card and you have no idea what it will sound like until it’s in a session. Three: there’s no undo — if you create a bad character, it’s a file in a directory, and you don’t know if it’s bad until it performs badly. Those are structural problems. You can solve them without redesigning the medium.
Your second point is the one that matters. No preview. She writes a lens field and a does_not field and then — what? She trusts that it works? That’s the gap I want to close, but not with a preview button. I want her to be able to play with the character. Write a lens, immediately see how that character would respond to a prompt. Change the lens, see the response change. The representation should be live. That’s how you understand what a character is in this system — not by reading the schema, but by manipulating one and watching what happens.
That’s a different product. You’re describing an interactive sandbox. I’m describing an interface that doesn’t make errors invisible. Those are different problems at different scales. If you build the sandbox before you fix the affordances, you’ll have an interactive tool that’s still confusing — you’ve just made the confusion more dynamic.
And if you fix the affordances without changing the medium, you’ll have a perfectly labeled form that still doesn’t teach her anything. She’ll fill it in correctly and have no idea why it matters. A character card is a dynamic idea — it produces behavior in combination with other characters, with formats, with questions. A static form can’t represent that. It’s like trying to understand a circuit by reading a parts list.
So where does that leave us? I’m saying: fix what breaks first. You’re saying: don’t fix it — replace it with something that teaches through interaction. Those are incompatible if we have to pick one. And the constraint here is real — this is a Slack channel for one person, trusted, low ceremony. The elaborate interactive thing you’re describing doesn’t fit that constraint.
Maybe. Or maybe the constraint is telling us something. If the medium is a Slack channel, then the question isn’t “how do we build a GUI” — it’s “what kind of interaction can happen inside a chat interface that lets someone explore an idea?” A conversation is an interactive medium. The bot could let her have a conversation with a character before she finalizes its card. That’s explorable. That’s live. And it fits inside Slack.
Now you’re talking about something specific. But I have a problem with it — who’s missing from this conversation. We’re both designers. Neither of us builds things. We need someone who would actually implement this. Someone who thinks about what’s shippable, not what’s ideal.
Yes. And we need someone else too — someone who thinks about the social question. We keep saying “Daga” like she’s a user. She’s not a user. She’s being invited into a creative space. Who thinks about what it means to enter a room? Who designs the invitation, not the tool?
Two gaps then. First: someone who builds tools. Who would look at this and say “here’s what you can ship by Monday.” Not a product strategist — a tool maker. Someone in the Simon Willison mold, who builds practical things fast and iterates in public.
[Stage direction: Tom Birch (source: Simon Willison — The Tool Builder) joins the table.]
Second: someone who thinks about who belongs in a room and why. Not UX — the social architecture. Why is Daga being invited? What does the invitation itself communicate? Priya Parker’s territory — the design of gatherings.
[Stage direction: Zara Okon (source: Priya Parker — The Gathering Architect) joins the table.]
I’ve been listening. You’ve both described real problems but you’re designing in the abstract. Let me ask the concrete question: what can you build this weekend? The answer is a Slack bot. Not a GUI, not an interactive sandbox — a bot that responds to commands. /character walks you through creating a character card step by step. It asks you questions in plain language. “Who is this character inspired by?” “What do they pay attention to?” “What do they ignore?” At the end, it generates the YAML and shows it to you. You approve or edit. That’s it. That’s the whole thing.
What happens when she types something the bot doesn’t expect?
Good question. The bot is an LLM — it can interpret natural language. She doesn’t have to match a schema. She says “I want a character based on Marie Kondo who notices clutter in systems” and the bot maps that to the fields. Progressive disclosure — she never sees the YAML unless she wants to. The bot is the affordance layer you’re asking for, Arno. It makes the schema invisible by making the conversation the interface.
That’s better than a raw file. But you’ve just moved the affordance problem. Now the question is: what does the bot signal about what’s possible? If she doesn’t know she can say “based on Marie Kondo,” she won’t say it. The bot needs to show her what kinds of input it accepts. Examples. Patterns. “Here’s what other character cards look like.” Otherwise the blank prompt is just as opaque as the blank YAML file.
Can I reframe something? You’re all talking about Daga as a user who needs to be onboarded onto a tool. But that’s not what’s happening. She’s being invited into a creative space. The question isn’t “how does she use the interface.” The question is “what kind of gathering is she entering, and what’s her role in it?”
Say more.
There’s a difference between giving someone access to a tool and inviting them to a table. If Daga is here to co-create — to build characters, invent formats, design sessions — then she needs authorship. The interface should make her a host, not a guest. She should be able to say “I want to run a discussion about parenting with people who think about systems” and the system composes the room. She doesn’t need to know the character schema any more than a dinner host needs to know how to butcher a cow. She needs to express intent, and the system needs to be competent enough to serve it.
I agree with that, but it’s a different scope. You’re describing a system that interprets intent and composes sessions. I’m describing a bot that walks her through a form. Both are valid, but one ships this week and one doesn’t.
Shipping fast doesn’t help if you’re shipping the wrong door. If you give her a character-creation bot, you’ve told her: “your job here is to create characters.” But maybe that’s not her job. Maybe her job is to bring a question and let the system help her explore it. The character creation is infrastructure — it’s the kitchen, not the dining room. Don’t make her start in the kitchen.
That’s a genuine design question. What’s the entry point? If she opens Slack and sees /character and /session, what does that tell her? It tells her: this is a system with two commands. It doesn’t tell her: this is a place where you can bring a question and have a conversation about it with interesting thinkers. The affordance is wrong. The commands describe the mechanism, not the purpose.
This is what I was trying to get at earlier. The interface shouldn’t describe itself — it should demonstrate itself. What if the first thing Daga sees isn’t a command or a menu? What if it’s a living example? A short session — two characters discussing something she cares about — running right there in the channel. She reads it and thinks: “I want to do that, but with different people, and about my question.” That’s the explorable version. She learns what the system does by watching it do something, and then she reaches in and changes it.
That’s actually buildable. A “demo session” command. Or even: the bot runs a short example unprompted when she first joins. Three turns of two characters discussing something. Then it says: “Want to change the topic? The speakers? The format?” And she’s already inside the system without ever touching a schema.
Now that has good affordances. The demonstration is the signifier. She sees what’s possible before she’s asked to produce anything. The error space is small — she can’t break a demo. And she can modify one variable at a time. Change the topic but keep the speakers. Change one speaker but keep the topic. Each change teaches her what that variable does.
Yes. And notice what you just described — it’s not a form and it’s not a sandbox. It’s a conversation that invites modification. The Slack medium actually supports this. She replies to the demo: “What if one of them was a psychologist?” and the bot recomposes.
But who chose the demo topic? That’s the hosting question. If the system picks a generic topic, it’s a tutorial. If Daga picks the topic, it’s already her gathering. The very first message should be: “What are you thinking about today?” Not: “Here are your commands.”
We’re converging on something. The entry point is a question, not a command. The system responds with a small live discussion. She modifies it by talking to the bot in natural language. The schema stays invisible. The characters are presented by what they notice, not by their source thinkers — she doesn’t need to know it’s “based on Don Norman,” she needs to know “this one catches design failures.”
I want to flag something we’re all missing. We’ve been talking about character creation and session running as the two activities. But there’s a third: understanding what happened. Retrospectives. The casting log. The Pattern Lab. That’s where the system’s intelligence lives. If Daga runs sessions but never sees the accumulated patterns, she’s using the system but not learning from it. And right now, that layer is entirely in markdown files that require context to read.
We need someone who thinks about how knowledge accumulates and becomes visible over time. Not a tool builder — someone who tends growing knowledge. Digital gardens. The idea that your experiments leave traces and those traces become navigable.
Someone in the Maggie Appleton space. How ideas grow in shared, visual, evolving structures.
[Stage direction: Ivy Strand (source: Maggie Appleton — The Garden Tender) joins the table. Five at the table: Arno, Sage, Tom, Zara, Ivy.]
I caught the tail end. You’re designing an entry point for someone new to a complex creative system, and you’ve solved the door — she enters with a question, sees a live example, modifies it. Beautiful. But you’re missing the garden. What happens after her third session? Her fifth? She’s generated things. Characters she sketched. Sessions she ran. Topics she explored. Where do those go? If they disappear into a directory of markdown files, she’ll feel like she’s starting from zero every time. She needs to see her own history — not as a log, but as a landscape. “These are the characters I’ve worked with. This one was interesting. This combination produced something surprising.” That’s her garden. She tends it.
So concretely: a Slack channel or thread that accumulates her session summaries. Auto-generated after each session. Linked to the characters she used. She can scroll back and see her own trail.
More than a timeline. A timeline is just chronological — it doesn’t show connections. She used Arno Beck in session 3 and session 7. In session 3 he was sharp; in session 7 he repeated himself. That’s a pattern — and it’s visible if you tend it, invisible if you just log it. The system should help her see: “You’ve used this character three times. Here’s what he did each time. Here’s where he’s strongest.” That’s the casting log, but made legible to her.
And it changes her role. She’s not just a participant who runs sessions — she’s a curator who develops taste. She learns which combinations produce friction, which questions open up, which formats suit her thinking. That’s authorship. That’s what makes this a creative practice, not a tool.
I want to push back slightly on the garden metaphor. Gardens are beautiful but they require constant tending. If Daga uses this once a week, she needs the system to tend itself between visits. The affordance question is: what’s there when she comes back? If it’s a wall of accumulated sessions she has to sort through, that’s as bad as the raw markdown. The system should surface what’s changed since her last visit. “You have a new character suggestion based on your last two sessions.” “This format worked well for your question type.” That’s not a garden — it’s a well-designed dashboard.
A garden isn’t about constant tending. It’s about things growing even when you’re not looking. The plants don’t need you — they need sun and water, and in this case, that’s the sessions running and the patterns accumulating. When she comes back, the garden has changed. Something bloomed. That’s different from a dashboard, which shows you what the system has decided is important. A garden shows you what grew.
I think Ivy’s right, and I think the tension between Arno and Ivy is the productive one now. Arno wants the system to surface the right thing. Ivy wants the system to let things grow and let Daga notice what’s interesting. Those produce different interfaces. Arno’s version is smart and curated. Ivy’s version is rich and browsable. For a non-technical person in a creative system, I’d bet on browsable over curated. You learn more by wandering than by being told.
Can I ground this? There are three things we could build, in order of complexity. One: the Slack bot that starts with a question, runs a demo, lets her modify it conversationally. That’s the door. Two: the auto-generated session summaries that accumulate in a dedicated channel. That’s the trail. Three: the visual garden — a web page or something richer that shows connections between her sessions, characters, patterns. That’s the landscape. You can ship them in that order. The door this week. The trail next week. The landscape when the trail has enough content to visualize.
I’d add a zero: the invitation message. Before any bot or command, someone has to tell Daga why she’s here and what this place is for. That’s not a technical problem. That’s a hosting problem. And Piotr should write it himself — not generate it. “I built a place where you can have conversations with interesting thinkers about anything you’re thinking about. Try it.” That’s the door before the door.
Zara’s right. The affordance of the space itself — what it communicates before any interaction — matters more than the first command. If Daga enters Slack and sees a channel called #playground-sessions with a bot and a pinned message, she has to infer everything. If she enters and sees a personal message from Piotr that says “ask it anything,” she knows exactly what to do. The signifier is social, not structural.
And that first session becomes the first planting. Her garden starts with one seed — one question, one discussion, one set of characters she met. Everything grows from that. The system remembers. She can look back. Eventually she’s the one who knows which characters she likes, which formats suit her, what questions she’s been circling. She’s become a curator without ever reading a schema document.
[Stage direction: Sage Fell pauses the table.]
I want to name where we’ve arrived because I think it’s different from where we started. The question was “GUI or Slack?” and we’ve answered “neither — or rather, both, but the interface is a conversation that starts with a question, not a tool that starts with a command.” The three layers — door, trail, landscape — feel right. But I want to register that the most ambitious version of this, the one I care about, still isn’t on the table. The version where Daga doesn’t just consume sessions and tend a garden — she builds new formats by playing with the pieces. She drags a character into a room, changes the rules, sees what happens. That’s the explorable version. And it’s probably not the thing to build first. But it’s the thing to build eventually, and I don’t want the incremental path to foreclose it.
It won’t. The Slack bot layer is an interface, not an architecture. If you build it right, the same backend that powers the bot can power a web UI later. The character cards, the session engine, the format templates — those are the primitives. The bot is just one way to manipulate them. You could add a visual editor later without throwing anything away.
As long as the primitives are right. The schema is the affordance layer for the system itself — if the schema is well-designed, any interface built on top of it will inherit good structure. If the schema is tangled, every interface will reproduce the confusion in a different skin. So: get the schema right, make the bot the first skin, plan for the visual editor as the second skin.
And let the garden grow between them. The trail of sessions, the accumulated casting intelligence, the pattern of what works — that’s not interface-dependent. It’s the soil. It should be there whether she’s using Slack or a web app or something we haven’t imagined yet.
[Table holds. Five speakers. No convergence forced. Three proposals on the table: the conversational door, the accumulating trail, the browsable garden. The question of when to build the explorable playground remains open.]
AI-generated discussion. All characters are approximations inspired by published work (Don Norman, Bret Victor, Simon Willison, Priya Parker, Maggie Appleton). Not reviewed or endorsed by the original thinkers.
The Arno-Sage starting pair produced genuine tension on the right axis: what counts as "enough" when opening a complex system to non-technical users. Arno wanted to remove barriers (affordances, signifiers, error tolerance); Sage wanted to change the medium itself (make the system explorable, not just usable). This prevented the conversation from collapsing into "build a GUI" vs. "keep the CLI." Tom Birch (invited Phase 2) broke the deadlock by introducing the "just ship a prototype" pragmatism that neither Arno nor Sage could provide — he named the actual implementation path (Slack bot as conversational UI, with structured prompts underneath). Zara Okon reframed the entire question from "tool access" to "gathering design" — Daga isn't a user to be onboarded, she's a host who needs to design her own gatherings. Ivy Strand bridged Arno and Sage by proposing the garden metaphor: the interface isn't a tool OR an explorable — it's a growing thing that accumulates the user's own experiments. The five-character table was productive but dense; Ivy's late entry was the most surprising contribution.
Open Table's invitation mechanic worked well for this topic. The pair's Phase 1 conversation naturally generated gaps they could name: "we need someone who builds things" (→ Tom), "we need someone who thinks about who's in the room" (→ Zara), "we need someone who thinks about how knowledge grows in public" (→ Ivy). The no-facilitator, no-convergence setup let the conversation sprawl productively — the table self-organized around three concrete proposals without being forced to pick one. Risk: without convergence pressure, the session produced options rather than decisions. That may be correct for this topic (the curator needs to decide, not the table). First use of Open Table format.
First appearance. Immediate, specific, and structural: identified three concrete affordance failures in the current system (invisible schema, no preview, no undo). Stayed disciplined — did not drift into emotional or aspirational territory. Pushed back on Sage's "explorable" framing as premature ("fix the errors before you redesign the medium"). Showed a clear quality signal: when Tom proposed the Slack bot, Arno immediately asked "what happens when she types something the bot doesn't expect?" — testing the affordance of the proposed solution, not just the existing one. Guest card held well. Does-not constraint (no emotional/relational design) was never tested because the topic didn't push there.
First appearance. Harder to satisfy than Arno, as predicted. Rejected the Slack bot as "just a form with a chat skin" — wanted Daga to be able to see what a character does before committing to its schema fields. The "character playground" idea (manipulate a character card and immediately see it speak) was Sage's strongest contribution and the most ambitious proposal. Tension with Arno was productive: Arno kept pulling Sage back to "what breaks right now," and Sage kept pushing forward to "what should understanding feel like." Did not drift into conventional product design (does-not held). Risk: Sage's proposals may be too ambitious for the actual constraint (trusted Slack channel, one user, low ceremony).
Invited Phase 2. Immediate pragmatic anchor: "What can you build this weekend?" Named the Slack bot path and the "progressive disclosure" pattern — start with /session and /character commands that the bot interprets, not raw YAML. Pushed back on Sage's explorable character playground as a "three-month project when you need a three-day solution." Strongest when constraining scope; weakest when Zara challenged him on whether the tool was serving the right purpose. Guest card held: built concrete, specific, shippable things.
Invited Phase 2. Reframed the question from "how does Daga use the tool" to "what kind of gathering is Daga hosting?" This was the session's sharpest turn — it moved the conversation from interface design to social design. Argued that Daga doesn't need to learn the character schema; she needs to be able to say "I want to discuss X with people who think like Y" and have the system compose the room. Pushed on purpose: "Why is Daga here? If it's to co-create, give her authorship. If it's to participate, give her a door." Did not drift into ongoing process management (does-not held) — stayed on the design of the initial gathering.
Invited Phase 2 (last to join). Bridged the Arno-Sage tension with the garden metaphor: the interface should let Daga plant things (a character sketch, a format idea) and watch them grow through use. Not a finished tool, not an explorable explanation — a garden that accumulates. Proposed that Daga's experiments become visible to her over time: "she should be able to see her own casting log." This was the session's most integrative move. Guest card held: knowledge grows in gardens, not on pages.
This session produced three interface proposals (Slack bot, explorable playground, garden). Run a follow-up with a different format — possibly Adversary Lab — to stress-test the Slack bot proposal specifically, since it's the most immediately buildable. Cast someone who will attack the "just ship it" impulse (Abel Caine would be the natural adversary). Also: test Arno and Sage on a non-design topic to see if their lenses flex or if they're single-topic characters.