Collaborative Prototyping Techniques

Something that's been effective for my design teams is "pair prompting" - get a designer and a PM together, share screens, and take turns prompting the same Figma Make. The back and forth helps both understand each other's thinking, plus you get a pretty good prototype for next steps. It feels a bit like a more focused, higher fidelity version of a design sprint. And it avoids the trap of a PM showing up with a "finished" prototype and passing it off to design. This has had several benefits:  • The designer can help guide the conversation to ensure user-centered best practices, appropriate patterns, and design system coherence.  • The product owner can contribute directly to the design while helping articulate goals, problem statements, and outcomes.  • Both experience high levels of collaboration, making it easier to be aligned on the final output. This can be done with or without a PRD. In fact, we've done it where the goal was to use the session to help write the PRD. I had one pair take the prompt history itself, feed it to an LLM, and draft a PRD. In the end, you have a decent prototype that you could use for concept testing, or even as a true MVP, though usually there is a list of things to tweak. We estimated this saves between 30-50% of time, compared to a designer reviewing a PRD with a product owner, going off to create initial mockups, have some back and forth, and then settle on a first version. Highly recommend giving it a try. 

Some of you disagreed with my last post. Fair. Let's talk. Let me explain the topic a bit more and give you a deep dive into how I see the new process. The old way: Think → Research → Wireframe → Design → Spec → Hand off → Build → Test → Iterate Weeks. Sometimes months. Before anyone touches real code. The new way: 👉 Step 1: Start with a problem, not a doc. I don't need a full PRD. I need one thing. Example: "𝘗𝘦𝘰𝘱𝘭𝘦 𝘴𝘵𝘳𝘶𝘨𝘨𝘭𝘦 𝘵𝘰 𝘨𝘦𝘵 𝘩𝘰𝘯𝘦𝘴𝘵 𝘧𝘦𝘦𝘥𝘣𝘢𝘤𝘬 𝘰𝘯 𝘵𝘩𝘦𝘪𝘳 𝘱𝘰𝘳𝘵𝘧𝘰𝘭𝘪𝘰." That's it. That's the brief. 👉 Step 2: Build the ugliest working version. I open Lovable or Cursor and prompt my way to a prototype. Not a mockup. Not a Figma file. A real, clickable, functional thing. 30 minutes. Maybe an hour. 👉 Step 3: Use it. Don't refine it. Don't show it to anyone yet. Use it yourself like a real user would. Click every button. Try to break it. Feel where it's awkward. 👉 Step 4: Now design. This is where design skill actually matters. You're not guessing what the experience should feel like. You already know because you felt it. Now you fix what's broken, remove what's unnecessary, and polish what works. Maybe pivot or try other solutions. 👉 Step 5: Show it, don't spec it. Instead of a 20-page spec, I send a link. "Here, try this. What's confusing?" Real feedback on a real thing beats hypothetical feedback on a hypothetical thing every single time. 👉 Step 6: Iterate in minutes, not weeks. Here's where this workflow really pulls ahead. Someone says, "This flow is confusing." You don't update a Figma file, write a ticket, and wait for the next sprint. You open Cursor, fix it, and send a new link. Same conversation. Same day. The feedback loop goes from weeks to hours. Sometimes minutes. And each round gets sharper because you're iterating on something real. 3-4 rounds of this, and you have something more validated than most products get after months of traditional process. 👉 Step 7: Document what you built, not what you plan to build. Documentation becomes a record, not a prediction. It's accurate because the thing already exists. You can do it at the end or during the process. Why this works: You make decisions with information instead of assumptions. You eliminate 80% of the back-and-forth. You design from experience, not imagination. And you iterate at the speed of conversation, not the speed of sprints. Why it feels wrong at first: Because we were trained to think before we build. And thinking first felt responsible. But we did that because we couldn't build. Now we can. And I don't think it's about ignoring thinking. (𝘔𝘢𝘯𝘺 𝘰𝘧 𝘺𝘰𝘶 𝘢𝘤𝘤𝘶𝘴𝘦𝘥 𝘮𝘦 𝘰𝘧 𝘵𝘩𝘢𝘵) I believe it's about doing it at every step. Refining it based on real feedback. Insights you can get internally and from user testing. If you're still reading this, let me know what you think about it all. ✌️

Prototyping is how ideas turn into evidence. It surface hidden assumptions, generate better stakeholder conversations, test specific hypotheses, reveal unforeseen interactions, and give you a concrete artifact to evaluate before code or tooling locks you in. Use low fidelity sketches and storyboards when you need speed and divergent thinking. They help teams externalize ideas, reason about user goals, and map flows before pixels appear. They are deliberately rough to avoid premature polish. Move to click through wireframes in Figma when the question is structure and navigation. Validate information architecture, menu depth, labeling, and path efficiency while changes are still cheap. When the feel of interaction matters, use interactive digital prototypes to evaluate micro interactions, timing, and visual polish. Treat them as validation instruments, not trophies. Plan change criteria up front so attachment to a pretty artifact does not silence real feedback. Some questions require real performance and materials. Coded prototypes and functional hardware mockups tell you about latency, reliability, durability, ergonomics, and safety. In medical devices and other regulated domains, high fidelity functional and contextual testing is expected for Human Factors validation. Not every question lives on screens. Experience prototyping and bodystorming put bodies in space to surface constraints that lab tasks miss. Acting out a shared autonomous ride with props reveals comfort, cue timing, and social norms. Wearing a telehealth mockup for a week exposes stigma, routine friction, and alert patterns that actually fit domestic life. Before building intelligence, simulate it. Wizard of Oz studies let a hidden human drive system responses while participants believe the system is autonomous. You learn vocabulary, trust dynamics, acceptable latency, and recovery strategies without heavy engineering. AI of Oz replaces the human with a large language model so you can study conversational realism early. Manage risks like model bias, hallucinations, and outages with guardrails and logging so findings remain trustworthy. Strategic prototypes also matter. Provotypes and research through design artifacts challenge assumptions, surface values, and force early conversations about privacy, power, and trade offs that slides tend to dodge.

Real-Time UI: https://lnkd.in/dNbmGcX8 "A prototype is worth 1000 meetings." But what if the meeting _is_ the prototype? That’s the spirit of an idea I’m calling “Real-time UI” (the name of which I gave next-to-no thought, so forgive me). The tools and technologies now exist to generate UI in realtime, making it possible to convert a conversation into a working digital thing. In this video, I introduce the concept to TJ Pitre and Ian Frost , and we talk about the possibilities and ramifications of generating UI in realtime, as well as speaking to the infinite creative potential of using AI & design systems together, as we are covering in our course: https://lnkd.in/eG5h8uaP https://lnkd.in/dubfHuCn As I see it, real-time UI can help accomplish a number of things: ◉ Visualize UI components in real-time – surfacing design system components immediately as they’re referenced in conversation (design systems are a shared language!) ◉ Visualize product design in real-time. Make abstract ideas real as soon as the words exit your mouth, and use the working prototype as a wet ball of clay the team can sculpt together over the course of a conversation. ◉ Wield your design system’s infrastructure to make realistic things. The spirit is to have the conversation and infrastructure tuned to your specific team’s context. Create prototypes that are built using your organization’s best practices rather than whatever AI decides to randomly generate. ◉ Minimize the friction involved in making prototypes ◉ A visual accompaniment to a conversation can help teams unlock new ideas, expose weak spots, explore opportunities, and iterate collaboratively ◉ Open the door to a more participatory design process. Diversity is critical to success, and it’s so important to make sure that digital products represent the best thinking from different disciplines & perspectives at a company. Historically, the design process was prohibitive to people who weren’t skilled in the mechanical aspects of creating designs & code. This is no longer the case. Of course professional designers or developers are still necessary (now more than ever!) to produce great results, but there’s now an opportunity to create more democratic, collaborative, participatory design workflows. If you're interested in exploring the future of using design systems and AI together, we'd love it if you joined our community by preordering our AI & Design Systems course! #ai #designsystems #ux #uxdesign #frontend #prototyping #design #process #workflow #collaboration

How do multiple people collaborate on the same prototype when using tools like Lovable? It seems we building a World of solo workers. AI-native prototyping is changing the rhythm of product creation. I usually prompt ideas between meetings as soon as I have an inspiration :). Instead of long design cycles, we now have: idea → prompt → prototype → iterate → deploy. But when more than one person is shaping the prototype, things get interesting. Some patterns I want to experiment with: A) Separate thinking from building Have one shared doc where the team writes prompts, constraints, and hypotheses before touching Lovable. It reduces prompt chaos. B) Assign a “prototype driver” Too many people prompting the tool at the same time creates noise. One person drives. Others critique. C) Prompt as version control Save the prompts that generated meaningful changes. Treat them like commit messages. D) Snapshot often When the prototype reaches a meaningful state, duplicate it. AI iteration can easily destroy something that was working. E) Define roles early Example: One person focuses on UX flows One on data / logic One on prompting the system behavior Without roles, everyone edits everything. We’re still figuring this out. AI tools made prototyping dramatically faster, but they also changed how teams collaborate. Curious to hear from others experimenting with Lovable, Replit, v0, or Cursor: How are you collaborating on AI-generated prototypes with your team? What works? What breaks? #ArtificialIntelligence #ProductDesign #ProductManagement #AI #leadership