Iterative Prototype Development

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.

I caught up with a friend who works at a mid-size Swedish tech company. Over the last 4 months, their shipping velocity has almost doubled – not because they hired more engineers, adopted some new agile framework, or worked late nights. It came down to a single change in how they build products: they started using Lovable to prototype features instead of writing traditional spec docs. Before Lovable, it usually went like this: PMs drafted long PRDs, trying to anticipate every detail. Multiple stakeholders reviewed these documents, leaving comments and raising concerns. The document grew with each iteration. Alignment meetings were frequent but often resulting in ambiguity. Engineers often began implementation while details were still debated. Inevitably, confusion emerged about trade-offs, timelines got pushed, and features shipped incomplete or scaled back. Now, PMs build interactive prototypes directly in Lovable. These aren’t wireframes or rough mockups – they’re fully clickable, end-to-end experiences that feel like the real product. Engineers don’t have to guess what the flow should be. Designers don’t have to explain interactions. Everyone sees the same thing, from day one. The end result is fewer meetings, fewer misunderstandings, fewer rewrites. What used to take weeks of coordination now happens in a single day. This is what has provided the most value for enterprises using Lovable so far. Over time, the increase of clarity and velocity saves the companies millions of $ in wasted effort.

This is how Anthropic decides what to build next—and it's brilliant. Instead of endless spec documents and roadmap debates, the Claude Code team has cracked the code on feature prioritization: prototype first, decide later. Here's their process (shared by Catherine Wu, Product Lead at Anthropic): Step 1: Idea → Prototype Got a feature idea? Skip the spec. Build a working prototype using Claude Code instead. Step 2: Internal Launch Ship that prototype to all Anthropic engineers immediately. No polish required—just functionality. Step 3: Watch & Listen Track usage religiously. Collect feedback actively. Let real behavior, not opinions, guide decisions. Step 4: Data-Driven Prioritization - High usage + positive feedback → roadmap priority - Low engagement or complaints → back to iteration This "prototype-first product shaping" flips traditional product development on its head. Instead of guessing what users want, they're measuring what users actually use. The beauty? They're dogfooding their own tool to build their own tool. The feedback loop is immediate, honest, and impossible to ignore. The takeaway: Your best product decisions come from real user behavior, not theoretical frameworks. Sometimes the fastest way to validate an idea isn't a survey or interview—it's a working prototype.

𝗙𝗼𝗰𝘂𝘀. 𝗕𝘂𝗶𝗹𝗱. 𝗥𝗲𝗽𝗲𝗮𝘁. That’s not just a tagline. It’s the rhythm that has shaped every product I’ve ever created. From building custom FDM 3D printers with 1-meter build volumes… To deploying digital cinema software for studios across India… To developing CPR innovations that may one day save lives… I’ve come to realize: Most people overestimate ideation and underestimate execution.  • Ideas are easy.  • Building is hard.  • Building again—after feedback, after failure, after fatigue—is what defines product people. Here’s how I’ve applied this mantra: 🔹 𝗙𝗼𝗰𝘂𝘀: Deep dive into the problem. Cut the noise. Understand the user. 𝗙𝗢𝗖𝗨𝗦 — 𝗧𝗵𝗲 𝗣𝗼𝘄𝗲𝗿 𝗼𝗳 𝗦𝗲𝗹𝗲𝗰𝘁𝗶𝘃𝗲 𝗔𝘁𝘁𝗲𝗻𝘁𝗶𝗼𝗻 𝗖𝘂𝘁 𝘁𝗵𝗲 𝗰𝗹𝘂𝘁𝘁𝗲𝗿: Remove tasks that don’t align with your core goal this week/month. 𝗧𝗶𝗺𝗲-𝗯𝗼𝘅 𝘆𝗼𝘂𝗿 𝗱𝗮𝘆: 2–3 deep work sessions > 10 scattered hours. 𝗧𝗿𝗮𝗶𝗻 𝘆𝗼𝘂𝗿 𝗺𝗶𝗻𝗱: Mindfulness, journaling, and even a short walk can reset your focus. 𝗦𝗮𝘆 𝗡𝗢 𝗼𝗳𝘁𝗲𝗻: Every yes is a cost. Guard your attention. 🔹 𝗕𝘂𝗶𝗹𝗱: Don’t wait for perfect. Get a working version. Test it. Break it. Rebuild. 𝗕𝗨𝗜𝗟𝗗 — 𝗗𝗼𝗻’𝘁 𝗝𝘂𝘀𝘁 𝗧𝗵𝗶𝗻𝗸, 𝗗𝗼 𝗦𝘁𝗮𝗿𝘁 𝗺𝗲𝘀𝘀𝘆: Don’t wait for the perfect version. V1 is always ugly, but it works. 𝗕𝘂𝗶𝗹𝗱 𝗶𝗻 𝗯𝗹𝗼𝗰𝗸𝘀: Work in weekly deliverables or prototypes you can test. 𝗧𝗲𝘀𝘁 𝘄𝗶𝘁𝗵 𝗿𝗲𝗮𝗹𝗶𝘁𝘆: Launch small, fail fast, learn faster. 𝗨𝘀𝗲 𝘁𝗼𝗼𝗹𝘀 𝘀𝗺𝗮𝗿𝘁𝗹𝘆: Automate where possible. Don’t waste energy reinventing the wheel. 🔹 𝗥𝗲𝗽𝗲𝗮𝘁: What worked yesterday won’t work tomorrow. Evolve fast, or become obsolete. 𝗥𝗘𝗣𝗘𝗔𝗧 — 𝗕𝘂𝗶𝗹𝗱 𝗠𝗼𝗺𝗲𝗻𝘁𝘂𝗺, 𝗡𝗼𝘁 𝗝𝘂𝘀𝘁 𝗠𝗼𝗺𝗲𝗻𝘁𝘀 𝗪𝗲𝗲𝗸𝗹𝘆 𝗿𝗲𝘃𝗶𝗲𝘄𝘀: Ask, “What did I build this week?” Not just what you did. 𝗜𝘁𝗲𝗿𝗮𝘁𝗲, 𝗱𝗼𝗻’𝘁 𝗽𝗶𝘃𝗼𝘁 𝗿𝗮𝗻𝗱𝗼𝗺𝗹𝘆: Improve with intention. Don’t abandon too early. 𝗕𝗿𝗶𝗰𝗸 𝗯𝘆 𝗯𝗿𝗶𝗰𝗸: Small improvements compound into big outcomes. 𝗥𝗲𝘀𝗽𝗲𝗰𝘁 𝗯𝗼𝗿𝗲𝗱𝗼𝗺: Repetition creates mastery. It’s okay if it’s not always thrilling. If you’re working on a new product, startup, or even a creative project—just remember: 🚫 Don’t chase motivation. ✅ Build systems. ✅ Track progress. ✅ Stick to your loop. Focus. Build. Repeat. That’s how breakthroughs are born. #PingnaganPranavam #ProductDevelopment #StartupJourney #MakersMindset #ExecutionOverIdeas #FocusBuildRepeat #PPWrites #builtbypp

Built 8 interactive UI prototypes with Claude Code in about a week to experiment with different ideas for small HTML apps as problem solving tools. Each one is just a single HTML file. No build tools, no frameworks, no npm install. The lineup: 1. Cable Configurator (39KB) — A* pathfinding algorithm for routing cables through a visual editor. You draw obstacles, set start/end points, and it finds the optimal cable path. Real pathfinding, not fake lines. 2. 3D Configurator (30KB) — general-purpose product configurator with parameter controls and live preview. 3. Side Table Designer (17KB) — furniture design tool where you tweak dimensions, materials, and proportions interactively. 4. Draw-Refine — multi-file system where you sketch rough ideas and an AI refines them into cleaner versions. 5. Inline-Draw-Chat — chat interface that lets you draw diagrams mid-conversation. 6. Thinkboard — collaborative thinking tool, basically a freeform canvas for organizing ideas spatially. 7. Tldraw-Chat — chat interface integrated with the tldraw drawing library. 8. Side Table Grid (7.5KB) — grid-based variant of the furniture designer. The pattern across all of them: single HTML file, vanilla JS, canvas-based rendering, no dependencies. The cable configurator implements real A* pathfinding in 39KB of self-contained code. The furniture designer does real-time 3D-ish projection in 17KB. I think there's something underappreciated about single-file prototypes (Simon WIllison was one of the first I saw point this out in his amazing blog). No build step means you can iterate in seconds. No dependencies means it works everywhere forever. The constraint of one file forces you to keep things simple — and simple often means better UX. The cable configurator is probably the most technically interesting one for me. Implementing A* in a visual editor where users can paint obstacles in real-time was a fun evening project. → Single-file prototypes: no build, no deps, no excuses. Cheers! B)

We killed Figma from our design workflow. We haven't built a single mockup in months. Here's the journey that got us there and what replaced it 👇 It started innocently. Like everyone, we began with vibe coding to test quick ideas. Generate a prototype, throw it away, start fresh. Tested several tools like Replit or Lovable. Figma was still the source of truth. AI was just a toy on the side to illustrate the user paths and replace the prototyping, not the mocks. Then something shifted. We switched to Claude Code and started to build a more sustainable AI prototyping engine, plugged with our design system. Suddenly prototypes started looking... indistinguishable from the real product. Edge cases covered. Flows detailed. Components aligned. And that's when Figma became the bottleneck. 👉 If your AI-generated prototype already respects your design system, handles edge states, and runs in a browser — what exactly is Figma adding? The answer, for us, was: friction. Today our setup is simple. ➡️ For major new features that reshape the product architecture, we use our dedicated AI prototype engine built with Claude Code, hosted on Vercel. ➡️ For iterative improvements, we code prototypes directly on a branch of the codebase. Figma still hosts our atomic design system — components, tokens, molecules. But zero mockups are made there anymore. The results are hard to argue with. Where we used to spend hours testing a single design variant in Figma, we now explore five deeper variants with full edge-case coverage — and land on a more mature design before a single line of production code is written. Fewer iterations downstream. Faster shipping. Notion recently shared a similar path — their design team built a shared "prototype playground". That's the crux. Static mockups hide reality. Loading states, screen sizes, AI model behavior, interaction quirks — you only discover these in code. And now code is fast enough to be your first draft, not your last mile. I was afraid to quit Figma. Figma Make and their other initiatives are good. But the most effective path we've found is using the Figma MCP to export your design system and history into an AI-powered prototype engine, and gradually emancipate yourself from Figma altogether. I'm still in my learning curve on this reshaping of tools & collaboration patterns in the AI era. What was your path internally?

Starting with a Minimum Viable Product (MVP) is not just a phase; it's a strategic misstep most make unknowingly. If you're launching straight from MVP to full-scale production without iterative learning, you're doing it wrong. Here's why. MVPs are more than a launchpad. They are a goldmine of insights, a chance to deeply understand user needs and refine your solution. Skipping the iterative development process means missing out on critical feedback that can pivot your product from good to exceptional. The journey from MVP to production isn't linear; it's cyclical. Each iteration is an opportunity to learn, adapt, and enhance. Ignoring this cycle can lead to a product that, while functional, may not fully meet user expectations or exploit the market potential. Moreover, the MVP to production journey is about risk mitigation. Each iteration allows you to address issues on a smaller scale, saving time, resources, and, most importantly, your reputation. So, if your strategy skips these iterative learning cycles, it's time to rethink. Embrace the iterative journey from MVP to production. Leverage each phase as a stepping stone towards creating a product that not only meets but exceeds market expectations. Ready to transform your development strategy? Start by re-evaluating your approach to MVPs and embrace the power of iterative learning. Your future self (and product) will thank you.

Design iteration can get messy. It's usually controlled during production because engineering teams follow structured, logic-based processes that are hard to change quickly. However, these controls need to be more flexible to unlock the full value of design. Alessandro Trezzi has a great question on my last design iteration post. “How do you see iteration working within agile sprints?” Paraphrasing, he observes that once a feature ships, it’s often seen as "done" unless market pressure demands changes. Iteration usually happens only during development, while later improvements end up in a backlog that’s often ignored as new priorities take over. 🚀 Here’s how we approach this scenario: Design doesn’t follow a single track because it involves overlapping cycles. To manage this, we use three different mindsets. UX metrics are common across all tracks, which help us align discussions, communicate clearly with stakeholders, and connect the work to its design impact. Concept Track ↳ Create and improve ideas by gathering user feedback to ensure they’re ready before building. Production Track ↳ Turn improved ideas into prototypes and fully developed designs for real-world use. Analytics Track ↳ Track how live designs perform to decide if they should stay, be updated, or be replaced. 🤔  What does this mean? 1. Flexibility over strict processes ↳ Different tracks (concept, production, analytics) have their own timelines, which can vary weekly. Keeping them aligned requires flexibility because not every problem can be solved in a week, a month, or even a year. Example: If a feature idea takes months to develop but analytics need to be tracked weekly, the team should focus on gradual improvements without forcing rushed solutions. 2. Use UX metrics to bridge mindsets ↳  UX metrics connect ideas across all three mindsets (concept, production, analytics). These metrics can reveal opportunities to link cause and effect in the work. Example: Track "time on task" to see how initial design concepts evolve into prototypes, eventually impacting usability when live. 3. Involve the whole team in feedback ↳  Include everyone in feedback sessions so the origins of ideas are clear and everyone knows which assumptions will be tested during production. Example: During a review meeting, designers, engineers, and advocates discuss which prototype features are based on user feedback and what will be measured in live testing. 4. Align analytics to original assumptions ↳  Analytics should stay focused on the initial assumptions. Broad or vague data doesn’t build confidence in the results. Example: Instead of reporting general user activity, measure specific metrics, like whether a new navigation menu reduced task completion times as intended. We can explore ideas as needed in the conceptual track, using research to evaluate new directions. For most companies, design teams usually focus on improving and building upon an existing product. What's your approach?

As a product designer, I sometimes get hung up on my designs before they're done. I can sometimes prevent myself from ever finishing a project because I get stuck in a infinite loop: For example, I will catch myself in this loop of continuous improvement that looks like this: 1. Concept Sketch 2. Begin Concept CAD 3. Halfway through Concept CAD, think of better idea for system layout, go back to 1, rinse and repeat. It can be paralyzing. I sometimes let 'perfect' be the enemy of 'done' and in so doing, never move on to next steps. When this happens, I haven't even gotten to my first prototype, and I'm already moving on to rev 2 in my mind. I've finally figured out how to overcome this challenge. I give myself an artificially imposed deadline, for some date that should be impossible to hit. Instead of giving myself a week to model up a device, I'll give myself 1 day. It's incredible how much clarity of vision I can get when I have a (self-imposed) deadline. Then once I've completed this quick build, I quickly print/order the parts to get 'real' parts in my hands. This is truly the best way to eliminate assumptions. Build and test. Then iterate. My goal is to build many prototype iterations as possible to remove any assumptions. I'm not trying to build real production CAD at the start. I call this the Hack-n-Smash method for product design. My fake deadlines mean that I can build an entire system top-to-bottom in a very short time. I don't let creeping elegance prevent me from getting to milestone builds. I also don't fall in love with a particular modeling method until I'm sure of what I'm building for production. As your designs change, components change, and overall modeling strategy changes, quickly scrap it and start over. Each time you build an assembly it will get better, more robust, and more stable. Sticking with an early model will quickly build 'cruft' or modeling artifacts that hinder forward progress. Also, every time I rebuild a full-system model, I can get preliminary manufacturing feedback on moldability. I can't ever get that if I'm searching for perfection in each build #prototyping #fastbuildlabs

I’m seeing a bit of confusion lately: AI makes coding cheap, so just skip validation and go straight to shipping… Right? Recipe for a disaster. AI helps us move faster, but skipping discovery is exactly how you can ship a ton of stuff no one gives a shit about, with a massive bill from your AI provider. In the video below, I try to demystify what PM can actually look like, with AI, to make sure we build the right things. I’m using a real example for something we’re working on in the JPD team. 1. Wonder (problem discovery) - Watch feedback: we looked for the biggest unmet needs popping up from users. We now use AI to make it 10x easier (and are creating a Feedback app for you). - Dig into the why: we talked to lighthouse customers to understand the why behind the noise. Old school, human-to-human deep conversation. - Prove the demand: we spun up a quick in-app waitlist (you can now vibe code that) and exposed it to JPD users via a Pendo guide. 5,000 signups in 2 weeks = demand validated. 2. Explore (solution discovery) - Hero shots: we built high-level Figmas (we can now vibe-create those), showed them to people on that waitlist and iterated until we got: "Can I have this yesterday, please?" - Live data prototypes: we are prototyping and iterating on the experience to get a real feel for it. We use vibe coding on Rovo Dev for that. See my previous post for what I've managed to learn from that. - With the AI tech evolving so fast we're also prototyping a lot to even just explore what is now possible! 3. Make & Impact - Once we have enough confidence, we build the pieces we validated, while we keep exploring the others. In this we use Rovo Dev too, but with a very different approach to create durable code in our target architecture. If we don’t get validation we can stop at any time before it turns costly, no harm done. - Then, we validate if it actually solved the problems we set out to fix (with a mix of user interviews, analytics, etc.).