Nutshell
Designing a privacy-first AI meeting assistant that turns conversations into searchable, actionable insights — without sending anything to the cloud.
Meeting conversations disappear. The tools for capturing them create new problems.
Every meeting produces information that feels important in the moment and is hard to find an hour later. Decisions get made without being recorded. Context is shared and forgotten. Action items drift into informal notes across different apps. Recordings exist but feel too long to actually replay.
The conventional solution — cloud-based AI transcription — introduced its own problem. Many conversations happen in sensitive contexts: medical discussions, legal strategy, financial planning, HR reviews. Sending those recordings to a third-party server creates risk that the participants never explicitly consented to.
What users were experiencing
Why existing tools fell short
Most meeting AI products had to choose between capability and privacy. Nutshell didn't.
Local-first AI was maturing at exactly the moment users were growing more skeptical of cloud-based transcription. The timing created a product opportunity: build an AI meeting assistant that could do everything cloud tools could do — transcription, summaries, searchable recall, action items — without ever sending the recording to a remote server.
The user problem wasn't just "I need transcription." It was "I need transcription I can actually trust with my conversations." Those are different design briefs.
Nutshell's job was to make on-device processing legible. Not just architecturally correct — visibly trustworthy. That distinction shaped every design decision in the product.
Most of the pain happens after the meeting — when context has already faded.
I mapped the full meeting lifecycle: the preparation, the live session, and the aftermath. The key finding was that users weren't struggling during the meeting. They were struggling 30 minutes afterward — when action items had blurred, decisions couldn't be sourced, and the recording felt too long to help.
I also identified a trust gap in how users understood "local AI." Without any baseline expectation for what on-device processing looked like, users had no mental model for how their data was being handled. "On-device" was an engineering claim, not a user experience.
User needs surfaced
Constraints I designed around
Five passes — from workflow map to finished interaction system.
Map the meeting lifecycle
Documented what actually happens before, during, and after a meeting — where information surfaces, where it disappears, and where the real friction lives. Found that post-meeting recall, not live note-taking, was the highest-pain moment.
Define the privacy constraints
Worked with engineering to understand the full data flow: audio in → on-device transcription → local LLM → structured output. Each step had a failure mode that needed a design response. No cloud calls. Offline by default. Local model latency treated as a UI state, not a bug.
Design the transcript experience
Focused on readability under pressure — a transcript users could scan during a live meeting without losing the thread. Speaker labels, timestamps, and visual separation were designed for quick orientation, not archival completeness.
Build the AI interaction model
Positioned the AI assistant beside the transcript — not above it, not in a separate tab. The design principle was "companion, not replacement." Users ask questions in natural language; the assistant grounds every answer in the active meeting. General-knowledge responses were excluded by design.
Layer consent and prompt patterns
Added a consent reminder that fires before every transcription session — not buried in settings. Built a slash-command system that lets users save reusable prompts for recurring meeting types. Both features were designed around ethical defaults: consent is visible, and prompt friction is low enough that good behavior is the path of least resistance.
Five decisions that shaped the product experience.
Three interconnected features. One focused meeting workspace.
The product isn't three separate features. It's a single workspace where transcription, AI questions, and reusable prompts reinforce each other. You're in the transcript reading what was said. You ask a question in the assistant beside it. You use a slash command you set up for your standup meeting type. These actions flow between each other without mode-switching.
The on-device architecture created design constraints that cascaded through the entire interface.
Local models have different latency profiles than cloud APIs. Processing speed varies by device. The UI needed to handle extended processing states without making the product feel broken. These weren't edge cases — they were the baseline operating conditions I designed around.
I worked with engineering to understand the full data flow: audio in → on-device transcription → local LLM processing → structured response out. Each step has a failure mode that needed a design response. No connection error (the system is fully local). A transcript that lags. A model that's still loading on startup. Designing around these realities made the product more honest about what it could and couldn't do.
System components I designed around
Interface states I designed for
What the design made possible.
Nutshell became a strong product design project because it connected AI interaction design, privacy-first strategy, and practical meeting workflows. The design work translated complex local AI capabilities into an interface that felt understandable, useful, and trustworthy.
Clearer meeting review
Transcript design that makes long conversations scannable during and after the meeting.
Faster context recovery
AI assistant grounded in the actual meeting — users get answers, not hallucinations.
Privacy made legible
"Thinking locally…" became a trust signal users could see, explain, and rely on.
Less prompt friction
Slash commands turned repeatable outputs into one-keystroke actions for regular meeting types.
Responsible by default
Consent reminders built into the recording workflow — not optional, not buried in settings.
What this project taught me about designing for local-first AI.
Designing for local-first AI is a different discipline than designing for cloud AI. The constraints are real, the latency profile is different, and the trust model requires explicit UI work that most cloud products can skip. Privacy becomes a product feature when the interface makes it visible and legible — not when the backend documentation says so.
The strongest moment in this product was the consent reminder. It's the one place where deliberately slowing the user down was the right design decision. That friction exists to protect the user's relationships with the people in the meeting. Getting that decision right required thinking about the product's ethics, not just its usability.