Video summary

UX Forum - Collaborating on Claude to Prototype & Test with other designers

Main summary

Key takeaways

Technology

Summary of the Video

Goal of the prototype / research validation

The team aimed to improve DAP GA’d (details not expanded in subtitles) by validating multiple improvements using an agentic workspace concept. They modeled the workspace so that conversations act as containers for agentic actions, including:

  • Human-in-the-loop decision points
  • Disclosure (information shown “as you work”)

Research design

Testing needed to cover multiple personas, not just engineers. The team created three persona-specific scenarios:

  • Developers
  • Planners
  • Security engineers

The prototype also had to be:

  • Interactive enough for self-exploration
  • Run unmoderated

Deployment + iteration constraints

They planned to deploy prototypes to GitLab Pages so participants could access separate URLs per persona scenario. They wanted the prototypes to be iterable without engineering support, and evaluated tooling:

  • Figma wasn’t sufficient because it couldn’t handle the dynamic behavior and the many interaction states/scenarios/data required.

Built with Claude-driven code + GitLab workflow

A key collaboration challenge was that copying/pasting Claude-generated code between designers (via Slack) didn’t work reliably.

Solution:

  • Create a shared hosted project where code was stored outside of personal Claude chats.
  • Both designers could pull down the project, iterate with Claude, and push back.
  • This shared repo became the source of truth, enabling async collaboration by default (aligned with GitLab’s workflow).

Their Claude conversations included many iterations (some around version ~150), with extensive back-and-forth to prepare for user testing.

What the prototype looked like (interaction model)

The prototype included:

  • A home/landing page listing persona use cases, with each scenario opened via URL
  • Each scenario launched a Duo Workbench experience with persona-tailored tasks/data:
    • Security scenario → security-focused tasks/data
    • Planner scenario → PM/planning-focused tasks/data

They made it highly interactive, including:

  • Clicking into conversations
  • Expanding Duo into more complete pages

They also added small “fun” UI/animation moments (e.g., Duo “blinking,” “crying” on failure) to make the prototype feel more engaging.

Honest Review: What Worked vs. What Didn’t

What worked

  • Very fast iteration speed
    • Multiple prototype iterations per day
  • Lowered the bar for designers to reach testable code
    • Claude acted as a design reasoning partner, not just a code generator.
    • Example: ask Claude to review the prototype “as a PM” and iterate based on feedback.
  • GitLab async-friendly workflow
    • Either designer could pick up work at any time, even if the other was offline.

What didn’t

  • No shared context across conversations
    • If a conversation restarted (or one designer took over another’s work), they had to re-explain.
  • Manual code integration
    • Copy/paste between Claude outputs and the repo was described as very manual.
    • Claude could take ~10 minutes to load the prototype at one point.
  • Poor diff/comp comparison
    • They lacked meaningful “diffs” of changes—comparing files rather than tracking changes from Claude’s evolution.
  • Claude drifted toward generic UI
    • Claude-generated UI sometimes diverged from actual GitLab UI, raising concerns that they were redesigning GitLab rather than testing concepts.

Next Steps / Proposed Future Workflow Improvements

The team proposed moving toward workflows that reduce workarounds and increase maintainability.

  • Try Claude Code-style collaboration for similar prototypes.
  • Desired improvements:
    • Avoid web IDE + copy/paste loops (so it can “know your project files,” reducing re-explanations)
    • Allow two designers to work in branches and review each other’s changes via MR-like flows
    • If a designer goes on PTO, others can still iterate and redeploy to Pages
  • Future workflow target:
    • From manual Slack/private review → artifact-based reviews where the code change lives (e.g., in MRs)
    • Reduce the barrier from “prompt AI to write React” → “review the diff of what AI changed.”

Discussion Points Raised by Others (Summarized)

  • Confidence & Git knowledge
    • Confidence improved when relying on familiarity with Git, since handoffs are code/repo-based.
    • Caution: as prototypes grow complex, the team may spend more time debugging/maintaining the AI-generated prototype than validating the underlying concept (a “bug bounty hunters” risk—debugging the prototype rather than the idea).
  • Claude setup hygiene
    • Use a Claude.md file (or segmented guidance like design.md) to provide stable context and reduce repeated mistakes.
  • Design system + Figma workflows
    • Question raised: how could the GitLab design system help?
      • Mentioned these prototypes were done before Claude component-based prototyping guidance.
      • Suggestion: revisit with newer workflows using real components.
    • Figma to code and back was seen as beneficial for demonstrating specific design intent (e.g., multiple artboard variants), but tooling limits remain (e.g., React-only environment makes it hard to apply the design system).
    • Overall stance: stick mostly with Claude for research prototypes where components can be pulled in, and use Figma for other workflows where it’s especially helpful.

Main Speakers / Sources (As Stated)

  • Emily Bowman — Product designer on the AI team; main presenter
  • Alex — Collaborator mentioned; co-authored prototype iterations
  • Austin — Contributor during Q&A/comments; mentions Claude setup for GitLab Pages and recommendations
  • Paul — Called on for questions
  • Michael Fingman — Mentioned as having a presentation related to component-based Claude prototyping
  • Nick — Asked/commented about confidence/operation
  • (AI/Forum moderator implied) — “Emily, you’ve got the floor” / “Paul, you’ve got the next question” callouts without a specific host name

Original video