2026-03-12 · open-table · Facilitated by none
How could we create an intuitive and natural interaction for creating a new character for the writing lab via Slack?
A shared desk in a co-working space, two laptops open, a Slack workspace visible on one screen, a YAML file on the other. Coffee. Whiteboards along the wall.
Let me start with the fundamental problem. A Slack message input is a single-line text field. It affords free-form text. It does not afford structured data entry. The character schema has — what, five or six distinct fields? Name, source, lens, does_not, working_label. Each one has a different kind of content. A text field gives you no signifier for any of them. You’re fighting the medium from the first keystroke.
Right, but you’re describing the problem as if the user has to fill out a form. They don’t. You pipe the message through an LLM. The user types something like: “I want to bring in someone inspired by Donella Meadows, she’d look at systems dynamics and feedback loops, she wouldn’t do reductive cause-and-effect thinking.” That’s a paragraph. From that paragraph, an LLM can extract name — well, the system generates the name — source: Donella Meadows, lens: systems dynamics and feedback loops, does_not: reductive cause-and-effect. Done. The user never sees the schema.
And what happens when the extraction is wrong? The user typed “feedback loops” meaning something specific and the LLM interpreted it as something generic. Where is the error correction affordance? The user sees a finished card and has to figure out which field to dispute. You’ve moved the cognitive load from input to review — you haven’t eliminated it.
That’s a real problem but it’s a solvable one. You show the preview. The user says “no, the lens is wrong, it should be more about leverage points than general feedback loops.” The bot updates the field. It’s a conversation, not a form. Slack is actually good at conversations.
Is it, though? A conversation implies turn-taking with shared context. But Slack’s threading model means the preview might appear in-channel or in a thread. If it’s in-channel, other people’s messages push it off screen. If it’s in a thread, the user has to navigate into the thread to see it. The mapping between “what I said” and “what the system understood” is physically separated in the interface. That’s a design failure — the feedback should be immediately adjacent to the input.
Okay, so you use an ephemeral message — only visible to the user, right there in the channel. Or a modal. Slack has Block Kit modals. You type /character, a modal pops up, you type your paragraph, it shows the extracted card in the same modal. One screen. No threading confusion.
Now you’re designing a modal form. Which is exactly what I said the problem was — except with an extra LLM step in the middle. A modal with a single text area and a preview pane is better than a modal with five labeled fields, I’ll grant you that. But the user still has to understand the mapping between what they wrote and what appeared in the preview. If the preview uses terminology the user didn’t use — “lens” instead of “perspective,” “does_not” instead of “wouldn’t do” — the system is speaking a different language than the user. That’s a gulf of evaluation.
The preview doesn’t have to use schema terminology. It can say: “Here’s what I understood — this character is inspired by Donella Meadows. They focus on: leverage points and feedback loops in systems. They avoid: reductive single-cause explanations. Does this look right?” Plain language. The schema field names are implementation details.
That’s better. But I still think we’re missing something. We’re arguing about the mechanics of input and review, but we haven’t asked: does the user even have a mental model of what a “character” is in this system? If they’ve never seen a character card, they don’t know what “lens” means, what “does_not” constrains, or why it matters. The affordance problem isn’t just the input field — it’s the concept. The system asks for something the user doesn’t have a model of.
That’s where I’d push back. The user who’s typing /character in a writing lab Slack channel already knows what they want. They have a thinker in mind. They know why they want that person in the room. The schema is our problem, not theirs. Our job is to extract what they already know and put it in a format the system can use. If they have to learn our schema to do that, we’ve failed.
We agree on that. But the extraction still has to be right. And the user has to be able to tell whether it’s right. That’s where I think we need someone who thinks about onboarding — when to ask for information versus when to infer it. We’re stuck on “form versus conversation” but there’s a third option: progressive disclosure. Show some fields, infer others, ask only when confidence is low.
Yes. And someone who’s thought about activation — what’s the moment where the user feels like they’ve accomplished something? Because saving a YAML file to disk isn’t it. Seeing their character show up in the roster and maybe even speak in a test exchange — that’s the moment. We need someone who thinks about time to value.
We need someone who understands onboarding and progressive profiling — when to ask for information versus when to infer it. Someone who’s thought about reducing upfront friction while still collecting what the system needs.
Agreed. And specifically someone who thinks about post-signup activation — what “done” looks like to the user. Not the schema being complete, but the user feeling like they created something real.
The pair has named two needs: (1) progressive profiling and onboarding mechanics, (2) activation and time-to-value. From the roster: Des Traynor is the primary source for Ronan Ash — direct match on both onboarding and activation. Ronan Ash joins the table.
Ronan Ash pulls up a chair, sets down a notebook with “TIME TO VALUE” circled on the open page.
I heard “progressive profiling” and “time to value” — those are the same problem. Let me reframe what you’re both circling. You’re arguing about the input mechanism — form versus conversation versus modal. But the user doesn’t care about the mechanism. The user cares about one thing: did I get a character that sounds like the thinker I had in mind? That’s your activation moment. Not “character saved.” Not “YAML committed.” The moment the user sees a card and thinks “yes, that’s them.” Everything before that moment is friction. Everything after it is retention.
So the preview isn’t just error correction — it is the product.
Exactly. Which means progressive profiling is the right model. Don’t ask for everything upfront. Ask: “Who’s the thinker?” That’s it. Extract what you can from public knowledge — the LLM already knows who Donella Meadows is. Show a draft card. Then ask: “What would you change?” Now the user is editing, not authoring. Editing is cognitively cheaper than creating from scratch. You’ve shifted the burden from recall to recognition.
I love this. The LLM does a first pass from just the thinker’s name. The user’s only job is to correct what’s wrong, not to generate what’s right. And the schema fields that the user never touches — working_label, the exact phrasing of does_not — those are the system’s job.
But there’s a risk. If the LLM generates a plausible-looking card from just a name, the user might accept defaults they shouldn’t. “Looks good” is not the same as “this is what I meant.” The card needs to be obviously provisional — visually marked as a draft, not a finished artifact. Otherwise you’ve created a new design failure: the user trusts the system’s guess and ends up with a character that doesn’t match their intent.
That’s a fair point. The draft state has to be unmistakable. But I’d go further — the question “does this look right?” isn’t good enough. It’s a closed question. It invites “yes” when the user hasn’t really evaluated. Better: “What’s missing or wrong?” That’s an open question. It assumes the draft is incomplete. It invites correction.
Okay, but we’re still in the review-a-static-card paradigm. The user reads the card, maybe corrects a field. But how do they know if the lens is right? “This character focuses on leverage points in complex systems” — is that right? The user can’t tell from the description. They’d need to see the character in action. That’s a different kind of preview entirely.
That’s a representation problem. The card is a static description of a dynamic entity — the character will speak, react, disagree. A text summary of what they “focus on” doesn’t convey how they’d behave in a session. We need someone who thinks about whether static representations of dynamic ideas are sufficient — or whether the preview itself needs to be interactive.
And honestly, we’re also missing the experience layer. We’ve been arguing about structure and mechanics, but nobody’s asked what the interaction feels like. When someone types /character and the bot responds — what does that first response feel like? Is it welcoming? Clinical? Overwhelming? That emotional register matters more than the schema.
Two more needs named: (1) interactive representations — can a static preview convey a dynamic character? (2) the emotional feel of the first interaction moment. From the roster: Bret Victor is the primary source for Sage Fell — direct match on interactive representation. Julie Zhuo is the primary source for Lian Hsu — direct match on experience and emotional register.
Lian Hsu and Sage Fell arrive together. Lian takes the seat nearest the Slack screen. Sage stands by the whiteboard.
I want to go back to the very beginning. Before the schema, before the preview, before progressive profiling. The user types /character and hits enter. What happens in the next three seconds? Because those three seconds determine everything. If the bot responds with “Please describe the thinker you’d like to create a character for” — that’s a form. It feels like a form. The user’s brain switches to task-completion mode. If the bot responds with “Who’s the thinker you want to bring into the room?” — that’s a conversation. The user’s brain stays in creative mode. Same information requested. Completely different experience.
The signifier is the language. “Please describe” versus “Who do you want to bring in” — one maps to bureaucracy, the other maps to invitation. The system’s first utterance is its most important affordance.
That’s easy to implement, too. The prompt engineering on the bot’s first response is a one-line change. But Lian, I want to push on something. You said “creative mode” — but is that what we want? The user is creating a structured artifact. At some point they need to engage with the structure. If the whole interaction feels like casual chat, they might not provide the specific, constrained information the schema needs. “Lens” is supposed to be a tight, opinionated focus. A casual conversation might produce something vague.
That’s the translation problem. The user thinks in terms of “this person is really about X” — that’s how people naturally describe thinkers. Your system needs to translate that into a focused lens statement. But the user doesn’t need to know they’re producing a lens statement. They need to feel like they’re telling you about someone they find interesting. The translation is the system’s job.
I want to challenge something everyone here has accepted. You’re all designing a flow where the user describes a thinker and sees a card. A card is a static representation. Name, source, lens, does_not — it’s a spec sheet. But the thing being specified is a character who will speak, argue, notice things, miss things. A spec sheet cannot convey that. It’s like describing a musical instrument by listing its dimensions. You need to hear it play.
So what — the bot generates a sample turn? “Here’s what this character might say about your current project”?
More than that. The preview should be interactive. Show the card and alongside it, a live sample: “Ask this character a question and see how they respond.” The user types a question, the character answers in voice. Now the user can feel whether the extraction worked. “Does this sound like the thinker I meant?” is a question humans can answer instantly, intuitively. “Is this lens statement accurately capturing the thinker’s epistemological focus?” is not.
That’s a genuinely different affordance. The card tells you what the system thinks the character is. The sample response tells you what the character does. One is specification, the other is demonstration. Norman would call it a knowledge-in-the-world versus knowledge-in-the-head distinction — you’re externalizing the character’s behavior so the user doesn’t have to simulate it mentally.
And from an activation standpoint, that’s your moment. The user asks a question, the character answers, and the user thinks “yes, that’s them.” That’s activation. Not “card saved.” Not “YAML committed.” The character spoke, and it sounded right. Time to value: the moment the character becomes real.
I hear the appeal, but let’s be practical. This is a Slack bot. Generating a sample character response means running an LLM inference with the character card as context, generating a turn in the character’s voice, and displaying it — all within the Slack interaction timeout. That’s buildable. It’s not trivial, but it’s buildable. The question is whether it’s v1 or v2.
If you ship without it, you’re shipping a form with an LLM in the middle. The user fills out a form, sees a card, and says “I guess that’s fine.” That’s not intuitive. That’s compliance. The interactive preview is what makes this different from a Google Form.
That’s fair. But I’d argue the LLM extraction plus preview is already meaningfully better than a form. The user types a paragraph, sees an inferred card, corrects what’s wrong. That’s a real improvement. The interactive voice sample is a v2 enhancement, not a v1 requirement.
I think Tom is right about sequencing but Sage is right about the end state. Ship the extraction-and-preview flow first. But design it so the voice sample can be added without restructuring the interaction. The preview pane should have a space for it. Even if v1 shows “Voice sample coming soon” — the affordance should be present, signaling that the card is not the final representation.
Can I propose something specific? Here’s the flow I’d design.
Step one: User types /character. Bot responds: “Who’s the thinker you want to bring into the room? Just tell me about them — who they are, what they’re known for, what perspective they’d add.”
Step two: User types a paragraph. Bot responds with a draft card in a clean format — not YAML, not schema labels. Something like: “Here’s who I think you mean — Inspired by: Donella Meadows. Their focus: Leverage points in complex systems — small interventions that shift large structures. They won’t touch: Linear cause-and-effect reasoning or simple root-cause analysis. Working name: Celia Vance. — What’s missing or wrong?”
Step three: User corrects. “The focus should be more about feedback loops, less about leverage points.” Bot updates and re-shows. Loop until the user says it’s good.
Step four — and this is Sage’s point — the bot generates a sample: “Here’s how Celia Vance might respond to the question ‘What’s wrong with five-year strategic plans?’” and shows a two-sentence character turn. User confirms or adjusts.
That flow has three activation checkpoints. The draft card — “does this look like the right thinker?” The correction loop — “is the focus right?” The voice sample — “does this sound like them?” Each one increases the user’s confidence that they got what they wanted. And importantly, each one is optional. If the user sees the draft card and says “perfect,” they can skip straight to save. Progressive profiling: ask for more only when the user signals the default isn’t right.
And technically, steps one through three are a weekend build. Slash command, LLM extraction, Block Kit preview, correction loop. Step four needs a character-voice prompt and another inference call — add a week. Ship steps one through three first, add four when you have it.
One thing we haven’t discussed: error states. What happens when the LLM doesn’t recognize the thinker? The user types “inspired by my former professor Dr. Aaronson.” The LLM has nothing to extract. At that point, the system has to fall back to asking specific questions — and the interaction shifts from recognition to recall. That transition needs to be smooth, not jarring. “I’m not sure I know this thinker — can you tell me more about their key ideas?” Not “Error: thinker not found.”
That’s the conversation model’s strength. A form breaks on unknown input. A conversation can ask follow-up questions. “I don’t recognize that name — what are they known for? What would they notice that others miss?” Now you’re gathering the lens and does_not through dialogue, not form fields. The user doesn’t even know they’re providing schema fields. They’re just answering questions about someone they admire.
And this is exactly where the interactive preview becomes essential, not optional. For a well-known thinker, the LLM’s first pass will be decent and the card might be enough. For an obscure thinker, the card will be generic — the only way to verify is to hear the character speak. “Here’s what I think your Professor Aaronson would say about organizational design” — and the user immediately knows if it’s right or wildly off. The voice sample is the error correction mechanism for cases where the card is insufficient.
Okay, I’ll concede that. For unknown thinkers, the voice sample isn’t a v2 nicety — it’s the only reliable verification. You’ve convinced me it should be in v1 for cases where the system’s confidence is low. High-confidence extraction: show card. Low-confidence extraction: show card plus voice sample. Use the system’s own uncertainty as a trigger.
That’s a good design principle. The system reveals more of its work when it’s less certain. Confidence determines the interaction depth. High confidence: minimal interaction. Low confidence: more questions, more preview, more verification. The user’s effort is proportional to the system’s uncertainty, not fixed.
And from the user’s perspective, they never see “confidence scores” or system internals. They just notice that sometimes the bot nails it in one step and sometimes it asks a few more questions. That feels natural. That feels like a conversation with someone who’s trying to understand what you mean.
That’s the whole design in one sentence. It should feel like a conversation with someone who’s trying to understand what you mean. Not a form. Not a wizard. Not a pipeline. A conversation.
Alright. I can build that. Slash command, LLM extraction, confidence-gated preview depth, correction loop, optional voice sample. The schema stays invisible. The conversation stays natural. The character card is the output, not the interface.
And the interaction should end with the character joining the roster and the user seeing confirmation — not in schema terms, but in human terms. “Celia Vance is ready. She’ll be available for your next session.” That’s the closing affordance. The character is a person now, not a YAML file.
One last thing. The conversation history of creating the character — the paragraph the user wrote, the corrections they made, the voice sample exchange — that should be preserved. Not as a log, but as context. When the character appears in a session later, the system knows not just the card but the intent behind it. The user said “more about feedback loops, less about leverage points” — that correction tells you something the card alone doesn’t.
That’s metadata. Store the creation conversation alongside the card. It’s cheap storage and rich context. Good idea.
The table settles. Five coffee cups, one whiteboard with Lian’s four-step flow sketched out, Sage’s “card + voice” distinction circled. No formal convergence — the Open Table leaves the tension between “ship v1 now” and “the voice sample is v1” unresolved, which is by design.
AI-generated approximations inspired by published work. No endorsement by original thinkers.
How could we create an intuitive interaction for users to define session formats via Slack?
Extending session 029's character-creation pattern to format creation exposed a harder problem: formats are behavioral recipes, not identity cards — you can't verify a format by reading its description, only by running it. The table split on whether users should compose formats from primitives (phase types, convergence rules, seat limits) or describe desired outcomes and let the system infer structure. Zara Okon's entry reframed the core question: a format is a gathering design, and the first question isn't "what fields does it have" but "what should happen in the room?" Petra Gale pushed back: without explicit process architecture, user-defined formats will collapse into unstructured conversation. The group landed on a two-layer approach — the user describes the gathering they want, the system generates a format card with explicit mechanics, and a dry-run simulation (two characters debating for 30 seconds) lets the user feel whether the format produces the kind of conversation they intended.
Arno and Tom as the starting pair produced the intended friction immediately. Arno treated the Slack medium as a design problem — what are the affordances? what does a text input field signify to the user? — while Tom treated it as a shipping problem: pipe the message through an LLM, extract fields, show a preview, done. The split was productive because both were partially right: the LLM-mediated approach solves Tom's problem (get something working) but not Arno's (make the interaction legible to the user's mental model). The invitations were well-timed: Ronan Ash arrived when the pair needed someone to define what "success" means for the user (activation, not completion). Lian Hsu entered when the conversation was arguing about structure vs. freedom but nobody was asking what the user feels in the first three seconds. Sage Fell arrived latest and pushed the hardest — his insistence that the preview be interactive (not a static card dump) was the session's most distinctive contribution, though it also created tension with Tom's "ship it today" instinct.
Open Table's invitation mechanic worked cleanly for this topic. The pair's blind spots were legible — Arno and Tom were arguing about form vs. function and both missed the user's emotional journey (Lian), the activation metric (Ronan), and the representation question (Sage). Each invitation added a genuinely new layer rather than reinforcing either side. The format's lack of facilitator worked here because the topic was concrete enough that the pair self-regulated — they kept returning to "okay but what would the user actually type?" as a grounding question.
First session appearance. Arno stayed tightly within the Norman lens — every contribution was about the mismatch between what Slack's interface signifies and what the character schema requires. Strongest moment: "A text input field affords free text. It does not afford structured data entry. You're fighting the medium." Did not drift into emotional or experiential territory (Lian's domain). The constraint held.
First session appearance. Tom was immediately concrete — within his second turn he'd sketched a working architecture (slash command → LLM extraction → preview → confirm). This practicality grounded the session but also created a ceiling: Tom's instinct to ship meant he sometimes dismissed valid design concerns as "we'll fix that in iteration." Strongest moment: pointing out that the schema is small enough that LLM extraction from a paragraph of natural language would get 80% of fields right on the first pass.
First session appearance. Ronan's contribution was surgical: he redefined the success metric from "character saved to file" to "user sees a card that matches the thinker they meant." This reframing broke a deadlock between Arno (the interface must be right) and Tom (the interface just needs to work). Progressive profiling was his other key move — don't ask for all fields upfront, let the system infer and the user correct.
First session appearance. Lian's entry reframed the entire conversation around the first three seconds of the interaction. Her point: the initial prompt after /character determines whether the user engages or bounces, and that prompt must feel like a conversation ("Tell me about the thinker you want to bring in"), not a form ("Please provide: name, source, lens, does_not"). This was the contribution that unified Arno's and Tom's positions — conversational prompt (Tom's natural language approach) that is cognitively clear (Arno's affordance requirement).
First session appearance. Sage pushed the conversation past everyone else's comfort zone by insisting the preview should be interactive — not just "here's your card" but "here's your card, and here's what this character would say about a sample topic." This was the most ambitious suggestion and also the most contentious — Tom argued it's over-engineering for v1, Arno said it adds cognitive load. Sage's counter: if the user can't feel the character, they can't evaluate whether the extraction worked. The table didn't resolve this tension, which is appropriate for an Open Table with convergence off.
This session was all guests — no full characters with established behavioral patterns. Next Open Table on a design topic should include at least one proven character (Nora Voss or Abel Caine) to test whether the invitation mechanic works differently when a full character is in the starting pair. Also: this session never hit the 6-seat limit — all five speakers coexisted. Test a session where someone has to leave to make room.