Session Prep — Lime UX Team
Format: 60-min remote call
Audience: Lime UX team
Goal: Be genuinely useful. Share how we work, show real examples that connect to their world, leave them with something they can use Monday.
Leave-behind: Lime UX Starter Kit — portable markdown files they can use with any AI tool
Deck: Build from this brief — this is the source of truth, deck is the presentation layer
Part 1: Who we are (5 min) — Mike
Keep this human. We're not presenting a framework. We're sharing how we work.
The intro: "Hi — we're Mike and Alex, we run Goose Group. We're a small consultancy that builds AI software, but really we're product thinkers focused on innovation. We work with teams that have real expertise and help them figure out how to use these tools to do their actual jobs better."
What we do, plainly: We build custom software for companies. Most of the work is figuring out what to build — that's the hard part. The tools are good now, but the hard part was always the hard part: understanding what people actually need, making good decisions about what to prioritize, and building things that are genuinely useful.
Why we're here: Karlie shared a brief with us about where your team is with AI. It was honestly one of the best briefs we've seen — you've already done real thinking about this. We're not here to sell you anything. We want to share how we use these tools day-to-day, show you some real examples, and hopefully give you something useful to take away.
Empathize with the pain: Most of us are in this weird middle ground with AI right now. You use it. It's sometimes helpful. But it's also kind of... generic? You paste something in, you get something back, you fix it, you paste it somewhere else. It works but it doesn't feel like it's actually changing how you work. And there's this background anxiety — is this thing going to replace me? Am I falling behind?
We've been through that. What changed for us wasn't a better model or a better tool. It was getting specific about what we actually know and care about, and giving the AI that context. Once you do that, the output stops being generic and starts being useful.
Part 2: How we actually work — Demos (10 min)
Demo 1: Alex mapping a business as a system (5 min) — Alex shares screen
Alex shows his real workflow: using playbooks to synthesize customer discovery into something navigable. Not a slide deck — a living map of how the business actually works.
What to show:
The workflow Alex actually does: 1. Ingest meeting notes, call transcripts, docs 2. Synthesize into Jobs-to-be-Done — what are people actually trying to accomplish? 3. Generate mermaid charts — state machines that show how the business moves: what triggers what, what depends on what, where humans are in the loop 4. USE the charts to inspect: where are the blind spots? What edge cases are we missing? What breaks? 5. Propose changes. Iterate. Update the JTBDs.
These mermaid charts are the state machine of the business. They map how things actually work — not the org chart, not the feature list, but the real flows: rider requests a bike → system assigns → rider rides → rider parks → ops team maintains → bike available again. With every branch, every exception, every human-in-the-loop moment.
Connect to their world — this is what Lime can build:
Karlie just got access to the Lime GitHub repos. Step 1: Use Claude Code to inspect the backend. How does the system actually work? What are the states? How do they transition? Where are the APIs? Step 2: Map that to the physical world. A service blueprint: bike maintenance workflows, ops team processes, rider experience flows. The HITL workflows — where humans and system meet. Step 3: One person can build this in a few days. Mermaid charts that describe the real system. Linked to Figma screens. Navigable by humans AND agents. The process of building it forces you to: → gather documentation that's scattered everywhere → figure out how things actually work → write down the processes nobody documented → find the gaps and the weird rules And what you produce is incredibly useful: → rich context for any AI tool your team uses → training manuals that stay current → helps developers understand second-order impacts from the physical world (and vice versa) → shared resource the whole UX team navigates with
This is the thing we'd encourage your team to build. It sits alongside a taste doc as the other half of the picture — taste says "how we think about UX," the system map says "how Lime actually works." Together they give AI (and new team members) everything they need.
Demo 2: The weather story (5 min) — Mike
Walk through a real thing that happened last week on a project.
Setup: We're building a scheduling system for a field maintenance company — 350 field visits a year across four states. Their operations director, Nick, asks a simple question: "What weather API are we using?"
What happened:
The agent found the API in three seconds. Open-Meteo. But that's not what Nick actually wanted to know. So I pushed: why is this the right choice for Keith, who schedules 350 visits and has to reschedule 57 customers when a snow system moves through Ohio? The agent searched four separate places: - A map of goals we'd documented (weather = #1 disruptor) - Three different call transcripts from months ago - The actual codebase - The original feature request on GitHub It came back with Keith's own words: "On condition services, any rain delays the job. But on track cleaning, we can work in the rain." And from another call — track repairs need 50°F sustained for 24 hours because the adhesive won't cure. None of this was in one place.
The "are you sure?" moment:
Before I sent the follow-up email, I had a gut check: are the features I'm describing actually built? I told the agent to verify every claim against the code. Result: 4 out of 10 things I would have described as features were not built yet. The agent caught it. Then I said "cut a ticket" — it created a GitHub issue with the four work items, cited customer quotes, linked everything. I didn't write any of that. Six nudges from me. Twenty minutes total. My contributions: the initial question, pushing deeper, pointing to the transcripts, saying "double check," asking for a shorter email, and "cut a ticket."
Connect to their world: This is a UX problem you deal with all the time. "Did we actually build the thing I spec'd?" "Are these annotations still accurate?" "What did the user say in research that led to this decision?" You have the same scattered context — Figma, Jira, Slack, research repos, design system docs. The pain is the same shape.
And the weird domain rules — Keith's adhesive cure temperatures, track cleaning in rain — you have those too. Rider behavior in Berlin is different from Austin. E-bikes have different constraints than scooters. Winter changes flows. These rules live in people's heads until someone writes them down.
The pattern: every problem is the same pipeline
Here's the thing — both demos are the same shape. And your work is the same shape too. Every useful AI workflow is a pipeline that compresses a lot of information into something specific and useful. The human decides what matters at each stage.
┌─────────────────────────────────────────────┐
│ RAW CONTEXT │
│ All the tokens. Scattered, unstructured. │
│ │
│ transcripts, research, Figma files, Jira, │
│ Slack threads, design system, past work, │
│ meeting notes, user data... │
└──────────────────┬──────────────────────────┘
│
YOU DECIDE:
what matters here?
│
▼
┌─────────────────────────────────────────────┐
│ STRUCTURED UNDERSTANDING │
│ Compressed. What your team actually knows. │
│ │
│ taste doc, personas, principles, │
│ domain context, past decisions, │
│ the weird rules... │
└──────────────────┬──────────────────────────┘
│
YOU DECIDE:
what's the right output?
│
▼
┌─────────────────────────────────────────────┐
│ USEFUL OUTPUT │
│ Rendered at whatever fidelity you need. │
│ │
│ design critique, onboarding doc, email, │
│ ticket, spec, presentation, leave-behind...│
└─────────────────────────────────────────────┘ The weather story through this lens:
RAW: 3 transcripts + JTBD map + codebase + GitHub issues
↓ (Mike: "why this API for Keith?")
STRUCTURED: Keith's constraints, weather rules by job type
↓ (Mike: "make it scannable")
OUTPUT: customer email → then: "are you sure?" → verified
email → then: "cut a ticket" → GitHub issue Alex's system mapping through this lens:
RAW: meeting notes + transcripts + client docs + codebase
↓ (Alex: synthesize into JTBDs)
STRUCTURED: mermaid charts — state machines of the business
↓ (Alex: "where are the blind spots?")
OUTPUT: proposed changes, edge cases found, updated JTBDs What Lime can build through this lens:
RAW: GitHub repos + scattered docs + tribal knowledge
+ rider data + ops processes + design system
↓ (you: inspect, map, document)
STRUCTURED: service blueprint + system map + taste doc
mermaid charts linked to Figma screens
↓ (you + agents: navigate, build, check)
OUTPUT: design critiques, training manuals, onboarding,
edge case detection, second-order impact analysis Even this session is the same pipeline. Karlie's brief is raw context. This prep doc is structured understanding. The deck is one rendering. The talk is another. The starter kit is a third. Same information, different fidelity.
The AI compresses tokens. You decide what matters. That's the whole thing.
Part 3: Making this real for your team (15 min) — Interactive
Your brief described a three-layer approach and it's good. It maps directly to the pipeline. Let's make it concrete.
Layer 1: Write down what your team knows (~5 min)
The single most useful thing you can do is write a document — plain markdown, nothing fancy — that captures how your team thinks about UX. Not generic principles. The specific stuff.
What does your team believe about good UX at Lime? What do you refuse to do, even when someone asks? What are the weird rules only your team knows? What does "good" actually look like for your work?
This is design system thinking, just for AI. Your design system says "this is what a button looks like." This doc says "this is what good UX judgment looks like at Lime."
We found this important enough that we built a tool for it — Smaak. But honestly, a well-written markdown file does 80% of the work. The tool just makes it easier to maintain and share across tools.
Interactive: "What's one thing your team refuses to do? One constraint that's specific to Lime UX?" Get 2-3 live answers. Write them down.
Layer 2: Give AI the context it needs (~4 min)
Every time a designer copy-pastes into ChatGPT, they're rebuilding context from scratch. That's the thing that makes AI feel generic — it doesn't know anything about your riders, your markets, your design system, your past decisions.
The fix is boring: write it down. Structure it. Make it available.
Your UX principles — as a doc AI can read Your personas — with the real research behind them Your design system — as a reference, not just for humans Past decisions — WHY things were done, not just what The real-world stuff — rider behavior, ops constraints, market-specific rules
Start with one doc that already exists and structure it. Don't try to do everything.
Layer 3: Try one workflow (~6 min)
Pick one thing your team does repeatedly that's high-effort and kind of tedious. Some options from your brief:
Design critique — but with YOUR principles, not generic heuristics. Input: a screen. Output: feedback that cites your actual rules and catches your actual edge cases. Project onboarding — new designer joins a project, gets full context in minutes instead of days of asking around and reading old Slack threads. Edge case identification — AI that actually knows your riders and your markets, flagging things that generic AI would miss entirely.
Interactive: "Which of these would save your team the most time? Or is there something else that's more painful?" Let them choose. Sketch what it needs: inputs, outputs, where human judgment stays essential.
Part 4: How to think about this (10 min) — Mike
This section flexes based on Q&A energy — if conversation is flowing, weave these points into the discussion instead of presenting them.
Close with the practical thinking, not the philosophy.
Start small. Don't try to build a system. Build one useful thing. We started with markdown notes and worked up from there. Mike went from obsidian notes → canvas thinking → full applications, each one building on the last. You don't need to build an app. Start with a doc.
Good enough is good enough. A design critique that catches 90% of issues is genuinely useful. You review the other 10%. That's how it's supposed to work — the AI handles the breadth, you handle the judgment.
Small improvements compound. 1.01^100 = 2.7x. You don't need one big transformation. You need a hundred small frictions removed. "Where's that file?" "What were the requirements?" "Did we do something like this before?" Each one is tiny. Together they change how work feels.
The hard work doesn't go away — it shifts. AI handles the repetitive stuff: annotations, documentation, first-draft critique. Your team handles what AI genuinely can't: deciding what's worth building, knowing when something is good enough, understanding what a rider actually needs, making calls that require empathy and taste. That work becomes more of your day, not less.
This is already happening at Lime. People who know these tools are already building things for themselves because they need them and can't wait for corporate to deliver. The question isn't whether this happens — it's whether the UX team leads it or follows it. Your CTO is pushing in this direction. This team can be out front.
Part 5: Q&A + Discussion (20 min)
This is the most important part. Let it breathe.
Opening question: "What's the one thing your team spends time on that you wish you didn't have to? The thing that keeps you from the work that actually matters?"
Let the conversation go where it goes. If Part 4 mindset points fit naturally, weave them in here instead. This should feel like a conversation, not a presentation with Q&A tacked on.
Before wrapping: share the starter kit link. "We put together some templates you can start with Monday. Just markdown files — use them with whatever tools you already have."
If there's natural interest in working together: "This is something we do — we work with product and UX teams to build exactly this kind of thing. Happy to talk about it if it's useful." Keep it light. The product partner page has the details.
Reminders
TONE:
→ Peers sharing, not experts presenting
→ Empathize with the pain — they're in the messy middle
→ "We've been through this" not "here's what you should do"
→ Earnest with edge. Genuine belief, not performance.
DO:
→ Show real work — be generous and open
→ Reference their brief — they did real thinking, honor it
→ Let examples speak for themselves
→ Mention Smaak naturally: "we found this useful enough to build"
→ Leave them with something practical
DON'T:
→ Provocative hooks ("your AI has no taste" etc.)
→ Jargon: encoding judgment, taste infrastructure, context gap
→ Sales pitch energy — this is about them
→ Avoid words: unlock, synergy, scalable solutions,
leverage, deep domain knowledge, best practices
→ Over-explaining — trust them to get it