Iterative Design Feedback Processes

I used to think user research was easy. But then I switched to B2B. And oh boy... reality hit hard Back when I was working on a B2C product, I could run 10 user interviews in a day. Users would happily spend 45 minutes answering questions and testing new designs. I thought this was just regular product design. Turns out, I was riding a perfect wave of continuous discovery without even realizing it. Then I switched to B2B. And I admit it really felt scary at first. Users were just too busy to pick up my phone calls. It took 3 weeks to schedule 5 calls. Some users left a bad CSAT score with barely any comment. Damn. How can we build anything serious without ever talking to users? At that time, it really felt like an impossible task. And any way I tried to put it, there were just no efficient process to get those users on the phone. But then it hit me. What if the best discovery touch points weren’t designers or PMs at all? What if they were already happening… in sales calls, support chats, internal Slack threads? And we had this feedback scattered across tools, threads, and people. But no one was making sense of it. So we built a Feedback Management System. We plugged every feedback into a single source of truth directly in Notion: - Intercom conversations and Modjo calls with customers - Internal tickets from sales and support to discuss user pain points or feature requests - User feedback forms submitted on the platform All filtered and organized per team through Notion automations. Each designer spends 2 hours per week turning raw feedback into structured insights. Then each team reviews it together weekly, and it feeds product decisions and the roadmap. It’s simple. It’s scalable. And it changed everything. Product designers no longer design based on shaky assumptions or partial data. They're now the source of customer truth and alignment. In B2B, discovery doesn’t happen in a lab. It happens in the wild. You just need to know where to listen. #productdesign #uxdesign #userresearch

Earlier today, a young product designer told me that in his company, design reviews were largely focused on blame — instead of progress. I wish this surprised me. Reagrdless, I'm gonna say a whole lot here for the room as a whole — from #UX and #ProductDesign folks to the #ProductManagers and #VPs of whatever who take them to task: Design feedback should never be failure — it should always be FUEL. What I mean by that: if teams or their bosses treat critique like a courtroom — cross-examination, defense, judgment — innovation suffers and progress toward measurable results stops dead. Here’s the truth: If a team member flinches at feedback, that's not a design problem. It’s a culture problem. And in most cases, it's a culture where managers mistakenly think that by being "tough" on their teams they'll get better results. I am here to tell you that they could not possibly be more wrong. When feedback feels like a personal attack, people stop taking risks. They stop exploring alternatives. Hell, they stop tryign altogether because they're optimizing for safety — not quality. The result? Weaker, safer, less effective work that helps no one. Not the team, not the company and certainly not its users or customers. Leaders: YOU set the tone. Your team will only take feedback well — or speak up and tell you the truth you need to hear — if they know they’re SAFE doing so. Make it clear that critique is about progress, not performance. Encourage your team to share early. Praise exploration. Normalize unfinished work. Great products aren’t built in silence — they’re shaped through conversation. Designers: You can shift the tone. Normalize iteration by sharing early and often. Don’t let reviews be the first time stakeholders see the work. Start reframing feedback sessions — and don’t allow it to become an opinion fest by asking “what do you think?” No matter what you heaar, stick to these kinds of responses: “What’s not clear to you here?” “What were you expecting to happen instead?” “What assumptions did we make that didn't hold up in real-world use?” Everyone involved needs to lead with curiosity, not defense. When feedback is treated as exploration — NOT evaluation — everyone gets better. [ Photo: Adam Rutkowski ]

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. ✌️

💡Triple Diamond Design Process The "Triple Diamond" process is a process that builds upon the widely known Double Diamond design process. While the Double Diamond focuses on two main phases—problem definition and solution design—the Triple Diamond adds a third phase to add depth and breadth to the design methodology.  This variant of a triple diamond process, crafted by Ted Goas (https://lnkd.in/eJFCR8rF), adds a third diamond for iterative development. It emphasizes iterative cycles, prioritization of user needs, and continuous refinement of the solution throughout the product lifecycle. Quick overview of the 5 key phases of this process: 1️⃣ Discovery (What’s our problem?) This phase focuses on identifying the problem to solve. Goal: Understanding customer pain points & narrowing down insights into actionable focus areas. Activities: ✔ Customer empathy budding: Researching user needs. ✔ Market research: Analyzing market trends. ✔ Competitive analysis: Assessing competition. ✔ Insights prioritization: Organizing findings for strategic focus. ✔ Building product strategy: Setting goals for the product. 2️⃣ Definition (What’s our solution?) This phase focuses on solution ideation & validation. Goal: Generate multiple ideas, structure them and validate the most promising ideas Activities: ✔ Ideation: Brainstorming and generating ideas. ✔ Drafting experience workflow: Mapping out how users will interact with the solution. ✔ Wireframeing: Visualizing the solution. ✔ Initial prototyping: Creating early product models for testing. 3️⃣ Development (Let’s build our solution) This phase is about building, iterating, and refining the product. Goal: Breaking down features and iterating to reduce risks. Activities: ✔ Feature breakdown: Breaking the solution into smaller deliverable tasks. ✔ Iterative build cycle: Continuously building and improving the product. ✔ Collecting research insights: Using feedback to refine features. 4️⃣ Distribution (Initial customer feedback) Focuses on testing the product with users and preparing for the final release. Phases: ✔ Internal release: Early internal testing (alpha and beta testing) ✔ Early access program: Collecting feedback from early adopters. ✔ General (Public) release: Launching the product publicly. 5️⃣ Retro (What did we learn?) Post-release reflection phase to gather insights for future iterations. Using insights collected from feedback, metrics, and retrospective discussions to refine the product. 📕 A Comprehensive guide to product design process https://lnkd.in/eyh4YGy6 #design #designprocess #ux #uxdesign #productdesign #uidesign #ui

We do not implement every user feedback. Here’s why (+our 3-step process) Since we launched Scripe, we got a lot of user feedback But here's the thing... Trying to implement everything can turn your product into a mess. Here's what I've learned: → Users often want features that don't align with our core vision. While they might be helpful for some, they can clutter the product for others. → Balancing user suggestions and our own insights is key. Our team focuses on innovating rather than firefighting endless feature requests. → Each new feature adds complexity. This means increased costs for development and maintenance, often the resources are better spent on enhancing core functionalities. So, we developed a 3-step process: 1/ Prioritize Essentials → We ask: Does this feature serve most users? Is it aligned with our mission? 2/ Conduct In-Depth Research → Not every request is a "yes." We dig deep into the real needs behind feedback. 3/ Iterate with Insights → We release MVPs and refine them based on actual user behavior, not just feedback. This approach keeps us efficient and effective, focusing on solving one problem and adding REAL value. Have you already tried balancing user input and your vision? How did it go?

Obsess over the feedback loop. All the learning you need is in the feedback loop. Most people don’t fail because they lack talent. They fail because they lack a system for learning from failure. Every success story rests on a foundation of failures that were properly ↳ Analyzed ↳ Iterated On ↳ And Improved Most of us don’t hit these important marks. We move move past failure too quickly, avoiding the embarrassing discomfort of reflection. We take failures personally instead of treating them scientifically. We assume trying harder is the answer when we need to try harder to design a better approach. I focus on one core truth: Learning more from failure is how we ultimately win. Failure is a feedback loop, and if yours is broken, you won’t just fail, you’ll repeat your failures over and over. Here’s how to fix that. 👇🏼 1️⃣ Pause & Reflect ↳ Before you move forward, stop. ↳ What went wrong? ↳ What did you assume? ↳ What was unexpected? 2️⃣Capture Data ↳ Write everything down. Future-you needs this information. 3️⃣ Remove Your Ego ↳ This isn’t about you, it’s about the process. ↳ Failures are feedback, not character judgments. 4️⃣ Get External Input ↳ Find people ahead of you who will tell you the truth. ↳ No sugarcoating. ↳ No yes-people allowed. 5️⃣ Identify the Root Cause ↳ Surface-level problems aren’t the real issue. Dig deeper. ↳ What’s the pattern behind your failures? 6️⃣ Make One Small Change ↳ Not everything needs an overhaul. ↳ Start with one adjustment and test the impact. 7️⃣ Test & Observe ↳ Don’t make assumptions. Run your new approach. ↳ Measure the results, and see what actually works. 8️⃣ Iterate with Consistency ↳ One correction doesn’t fix everything. ↳ Keep adjusting, keep improving, keep refining. 9️⃣ Build a Culture of Learning ↳ Winners review their losses more than they celebrate their wins. Every failure contains data. Every mistake contains insight. Are you learning? If you’re not, you’re setting yourself up to fail the same way again. DO. FAIL. LEARN. GROW. WIN. REPEAT. FOREVER. What do your feedback loops like? Which of these ideas might be most helpful to your work? Drop a comment below to share your experience. 👇🏼 _____ 🔗 Subscribe to The Failure Blog via the link in my profile (💯🙏🏼) ➕ Follow me, John Brewton, for content that Helps (💯🙏🏼) ♻️ Repost to your networks, colleagues, and friends if you think this would help them (💯🙏🏼)