Prototype Development Guidelines

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’ve made games for 12+ years. My biggest mistakes? All ideas started with bad prototyping. Here are 5 hard-learned: 1. Prototypes don’t lie. ↳ Your prototype is brutally honest. 2. Don’t wait for perfection. ↳ Learn fast, move on - ugly is fine. 3. No one claps for your design docs. ↳ Let real people play, not your mom. 4. Prototypes boost morale. ↳ Long dev kills vibe, quick fun fuels it 5. Prototyping ≠ polishing. ↳ It’s a sketch, not a sculpture. 💡TIP: Build the smallest playable version of your core loop. → No art. → No polish. → No menus. → Just see if it’s fun. If it isn’t, nothing else matters. 🧱 Example: Want to make a horror roguelike? Just prototype: ↓ One room ↓ One enemy ↓ Basic tension mechanic If the loop isn’t scary now, it won’t be scarier with shaders. Prototype checklist: ✅ Core mechanic is in ✅ It feels something (tension, joy, etc.) ✅ Testers “get” what the game is about ✅ It breaks (but teaches you something) If YES: you’re on track. Prototyping isn't just for mechanics. Try these: → Visual style (Can I sell this mood?) → Control feel (Does jumping feel good?) → Onboarding (Can players figure this out?) All count. PROTOTYPING PITFALLS TO AVOID: ❌ Falling in love with your first idea ❌ Building full art assets too early ❌ Showing only to friends & family ❌ Refusing to cut features 🔥 Final tip: A prototype should answer this: "Should I keep building this?" If the answer is no, that’s not failure. That’s a massive win that saved you months (or years).

We’ve built for GoPro, Walmart, and 100s of hardware startups. Here are 8 mistakes I see $1.5M-funded founders repeat in pre-production: 1. If it can’t be quoted, it can’t be built. I’ve seen so many smooth prototypes that look great but aren’t designed for manufacturability. Then factories either ghost or quote 4x. Why? Undercuts and part geometry made tooling impossible. If your design isn’t quoting cleanly, it’s not a product yet. 2. BOM isn’t a budget - it’s a liability list. One team’s $38 BOM ballooned to $62 after sourcing revealed single-vendor parts and fragile components. Your BOM should protect your margin, not drain it. 3. Never tool before your tolerances are tested. A wearable team tooled early - then found a 12% failure rate in production. Tooling before DFM is just a bet you can’t afford to lose. 4. What works at 50 units fails at 5,000. We’ve seen battery doors crack, enclosures warp, and boards overheat - because the product was only tested at lab scale. CAD hides stress. Volume exposes it. 5. Design firms often don’t speak “factory.” A sleek prototype arrived with no draft angles, wall thickness issues, and unusable files. If they’ve never shipped 10,000 units, don’t trust them to design yours. 6. Getting one quote isn’t success - it’s a trap. One startup was quoted 35% above target and had no backup. We redesigned 3 parts and unlocked 5 new factories. No quote = no leverage = no plan B. 7. BOM rejection is where the bleeding starts. One team sent their BOM after raising $2.1M. 6 of 18 parts failed compliance or sourcing. If your BOM hasn’t been factory-reviewed, your roadmap is fiction. 8. Prototypes don’t prove scalability. DFM does. One team built a slick demo using CNC-machined parts. The clip-on enclosure fit perfectly. Everyone loved it. But when we prepped it for mass production, we found: - No draft angles for molding - Undercuts that required complex, expensive tooling - Assembly steps that added labor cost at scale It was never designed to be built at volume. What worked in a demo couldn’t be molded, tooled, or quoted. Prototypes can prove function. But only DFM proves you’re ready to scale. If you’re in pre-production with real capital at stake, DFM is your insurance policy. DM or comment “DFM” for the checklist, that’s saved founders six figures in mistakes (minimum).

No designer wants to waste weeks building the wrong thing. That’s why I lean on a battle-tested prototype progression that saves time, catches problems early, and gets stakeholder buy-in faster. Because smart prototyping isn’t about polish. It’s about asking the right questions at the right level of fidelity. And those last-minute pivots because “the client doesn’t get it”? Most of them are avoidable—with the right prototype at the right time. There are four main stages between napkin sketches and pixel-perfect handoff: 1️⃣ Paper Sketches 2️⃣ Low-Fi Wireframes 3️⃣ Mid-Fi Interactive Prototypes 4️⃣ High-Fi Prototypes The real magic comes from matching fidelity to purpose. → Want to test a new flow? Mid-fi is enough. → Need clean handoff? Go hi-fi. → Exploring 10 ideas? Stick to paper. Every level answers a different question. Skipping steps = solving the wrong problem too late. Smart prototyping lets you fail fast, learn early, and ship experiences that actually work. What’s your prototyping process for UX design projects? #uxdesign #prototyping #uxstrategy ——— 👋 Hi, I’m Dane—I love sharing design tips + strategies. ❤️ Found this helpful? Dropping a like shows support. 🔄 Share to help others (& for easy access later). ➕ Follow for more like this in your feed every day.

What's the right number of prototype iterations in MedTech? Hint: the answer is not 1. That's like expecting a hole-in-one on a long distance golf shot. Just ain't gonna happen. Instead, focus your prototype iterations on answering specific questions: ➡️ Prototype 1: Does it work on the bench? Simplified proof-of-concept prototype that addresses key questions related to technical performance. ➡️Prototype 2: Does it work (pre)clinically? Early prototype aimed at collecting data, preclinically (for significant risk devices) or clinically (for non-significant risk devices). ➡️Prototype 3: Will people use it correctly? Usability prototypes (or mockups) aimed at evaluating user interfaces, usability, and possible misuse through human factors studies. ➡️Prototype 4: Does it achieve target COGS? Alpha prototype integrating industrial design and engineering, while designing for production materials and processes. ➡️ Prototype 5: Does it meet the requirements? Beta prototype addressing shortcomings of Alpha, and used for engineering verification testing (before V&V). So, minimum.. 5 prototype iterations. Often many more. Stage these prototype iterations so that each one gains the benefit of the prior. If you isolate these risk factors, your prototypes can be much simpler, faster and more cost effective to design, produce, and test. Prototyping is a mindset -- it's about learning, quickly and effectively. > Identify the right questions to answer > Build simple prototypes focused on the key questions > Run the tests, learn, and iterate. #medtech #medicaldevices #prototyping

Prototypes aren't for testing your product. They're for testing your assumptions. Most teams get this backward, and it costs them weeks of wasted effort and a product nobody wants. A prototype isn't a tiny product; it's a medium for learning. It's a tool designed to ask a specific question and test a core assumption with the right audience. An unintentionally designed prototype is a flawed input, and even with advanced teams and tools, flawed inputs only amplify flaws. The true power of a prototype isn't in its polish, but in the intentional "message" it sends. To unlock this power and truly accelerate collective learning across your organization, you must design with intent: ✺ Low-Fidelity Prototypes: These are for asking foundational, "Does this even solve the right problem?" questions. They signal that everything is up for debate. The intentional message is: "Let's explore the idea, not the pixels." ✺ Medium-Fidelity Prototypes: Use these to test core user flows and information architecture. The intentional message is: "Is this journey intuitive?" By keeping them a little rough, you prevent stakeholders from getting fixated on visual design. ✺ High-Fidelity Prototypes: Reserve these for the final stages to test things like micro-interactions, brand consistency, or subtle emotional responses. The intentional message is: "We're almost there. What are we missing?" This is how you turn prototyping from a simple task into a strategic lever for change and Team Learning. It ensures your team isn't just building things, but is learning together and making better decisions about what to build and why. It's how you break down silos and create a "Holding Environment" for generative dialogue. What's a time you intentionally used a low-fidelity prototype to prevent a high-stakes meeting from spiraling? Let’s discuss in the comments below. #ProductDesign #SystemsThinking #StrategicDesign #UXStrategy #DesignLeadership #ComplexSystems #TeamLearning #Prototyping #OrganizationalDesign #Innovation

You’ve been sitting on that app idea for months. Maybe years. But when it’s finally time to build, you freeze. What tool do I use? What if I mess it up? Where do I even start? You’re staring at a blank screen. But what if you didn’t need to “build an app”? What if you just needed a prototype that works, and tells you if your idea even has legs? That’s what we did last Friday inside Mighty AI Lab. Here’s the 4-step process we used to go from idea to live prototype in 60 minutes: 1. Start with the Problem–Solution–User Triangle Before building anything, clarify three things: 1. The problem you’re solving (e.g. “Salespeople procrastinate on high-value tasks”) 2. The user you’re solving it for (e.g. “B2B sales reps who work remotely and feel isolated”) 3. The outcome that defines success (e.g. “Help them start difficult tasks in under 2 minutes”) Without this triangle, your app will drift. With it, every feature decision becomes obvious. 2. Use the IDEA Template A simple framework for structuring the app concept: - Intent: What is the core transformation this app enables? → “Reduce friction and resistance so users take action faster.” - Data: What info does the app work with or generate? → “User check-ins, emotional states, task history, time of day.” - Experience: How should it feel to use this? → “Supportive, low-pressure, playful. Like having a coach, not a critic.” - Actions: What tasks should the user be able to perform? → “Log resistance, get tailored nudges, track progress over time.” This turns vague ideas into a real architecture, without writing a single line of code. 3. Build in Claude Artifacts Instead of using 5 tools to cobble something together, we use Claude’s Artifact mode to: - Generate a UI (forms, logic, layout) through natural language prompts - Link intent to interaction—e.g., “When user selects ‘resisting outreach’, show mindset nudge.” - Iterate live while thinking out loud, which unlocks creativity and flow. You’re not coding. You’re designing with language. 4. Test. Adjust. Ship. Don’t wait for “done.” Start with usable. - Share the prototype with 2–3 target users - Ask: “Would this actually help you do the thing you’re avoiding?” - Based on real feedback, make small tweaks that move the needle - Only then consider porting it to something like Lovable or Retool This step saves founders weeks of wasted effort and gives clarity faster than any brainstorm ever could. Here's a real example: Holly came to the session with an idea: A tool that helps salespeople overcome procrastination. In less than an hour, she had a working prototype. Complete with resistance check-ins, mindset coaching, and game-like progress tracking. Not just imagined. Built. We build real prototypes live, every week, inside Mighty AI Lab. Interested? Join here: https://lnkd.in/gjah4Yen