Your UX Project Has a Blind Spot You Don't Know About. It's Called Missing Transcripts.

Notes Are Not the Same as the Memory of a Conversation

‍

Workshop notes are, by nature, subjective and incomplete. The person taking notes decides what seems important at the moment and filters out the rest—often without realizing it. The problem is that what feels "obvious" during the meeting can become surprisingly unclear just a few weeks later. You return to the notes and realize you no longer know why a particular decision was made in the first place.
‍

Audio or video transcripts solve this problem in a completely different way. Instead of preserving only the outcome, they preserve the reasoning behind it. They capture not just what was decided, but why—which alternatives were considered, which were rejected, and what ultimately led to the final decision.
‍

In practice, this means one simple rule: we use transcription tools such as Otter, Fireflies, Notion AI, or tl;dv from the very first workshop—not only when the project starts getting complicated. If a conversation hasn't been recorded, you can never truly reconstruct it later.
‍

In the Kello project, the decision to make the interactive calendar the central element of the entire application emerged during the Customer Journey workshop. It became one of the project's key architectural decisions. Without a complete transcript, that decision could easily have been diluted or even lost as new ideas and alternative concepts appeared throughout subsequent iterations.

‍

‍

‍

‍

AI Can't Read Minds—You Have to Give It the Full ContextBad

‍

Recording a meeting alone isn't enough. AI-generated summaries are only as good as the signals they receive during the conversation. AI has no way of knowing that a crucial design decision has just been made unless the participants make that explicit.

‍

‍

At ZIMA, our meetings typically follow a few simple rules:

• When something is a decision, we state it as such: "This is a design decision – we are doing X instead of Y."
  ‍
• We deliberately use verbal markers that both AI and people recognize easily, such as: "We've agreed that...", "We're dropping...", or "At this stage, our priority is..."
  ‍
• At the end of every workshop, we ask AI to summarize not the entire discussion, but only the decisions made and the remaining open questions. Before anyone leaves the meeting, we review that summary together with the client.
  ‍

That final step is perhaps the most important. It's the moment when someone says, "Wait, that's not how I understood it." It's far better for that misunderstanding to surface while everyone is still in the room than three weeks later in an email beginning with, "Unfortunately, we'd like to point out..."

‍

A good decision record is much more than "We decided X." It should include the decision itself, the reasoning behind it, the alternatives that were rejected, what influenced the final choice, and who made the decision—and when. Without that context, the conclusion alone has very little value.

‍
Documentation Should Be a Cheat Sheet for AI, Not a File That Nobody Opens

‍

‍

Well-structured documentation is documentation that enables an AI agent to implement a solution with as few follow-up questions as possible. That only happens when insights from research and workshops are stored where the AI—and the development team—will actually look for them, rather than buried inside a report that no one opens during implementation.
‍

A few practices we've adopted:

• Insights from user testing are added directly as comments to the relevant screens in Figma—not only to a research report that rarely gets revisited during development.
  ‍
• Customer Journey Maps can serve as implementation flow documentation for AI agents—but only if they're sufficiently detailed, including entry states, transition conditions, and system logic, rather than just a visually appealing diagram connecting point A to point B.
  ‍
• For key screens, we create a dedicated Implementation Notes section in Figma or Notion. This is where we document anything unusual, edge cases, or implementation details that require special attention from developers. Think of it as a warning label saying, "Careful—this is where the tricky part begins."

‍