Iterative Design Processes in B2B UX

I posted this image last month and a lot of people asked for a breakdown — not the theory, but how each stage actually works in a real project. Here’s the reminder this visual was meant to give: Understand → Ideate → Test → Implement is not a straight line. It’s a loop. You return to previous stages every time new data proves you wrong. Example from my own work: I was designing a dashboard for a SaaS product. The UI looked polished and was already “ready for handoff,” until usability testing showed that 4 out of 6 users couldn’t correctly interpret the main metric. So we had to loop back: → Understand: clarify user mental model → Ideate: restructure hierarchy + labels → Test: validate again with a quick prototype → Implement: only then ship the updated version The design didn’t change visually — the clarity did. Task success rate went from 42% to 91%. That’s real UX. Not a clean slide with arrows — but constant informed rewinding. A few things people underestimate in real projects: • “Understand” is not only interviews — it’s business goals, constraints, and success criteria • “Ideate” is not Dribbble-style wireframes — it’s structured problem solving • “Test” is not just moderated sessions — analytics, heatmaps, and field feedback count too • “Implement” doesn’t end at handoff — onboarding, content, states, and accessibility are still design The process doesn’t fail. What fails is expecting it to work in one direction. What is your take on this? #uxdesign #productdesign #designprocess #userexperience #uxresearch #uidesign #uxworkflow #designthinking #uxstrategy #usabilitytesting #saasdesign #uxcasestudy

Systems design needs both short and long feedback loops. I work with teams that are often asked to grow or pivot a product to create more impact. Over the years, I’ve seen two main types of leaders trying to make progress in their products. The first type thinks very short term. They design page by page and try to keep the problem small. Sometimes this comes from not being able to sell a bigger vision, or from holding too tightly to release cycles. While this approach can create quick wins, it often comes at the cost of a bigger product vision. Great products can’t be built block by block, as great experiences are connected, and each part adds value to the whole (despite what some enterprise companies still think). I find this approach painful. And slow. The second type wants to solve the whole experience at once. They might copy a competitor or follow a logical sequence of steps. But most platforms don’t map one-to-one, so they end up backtracking to fix gaps. Iteration turns into rework, and learning is lost. Sometimes this works, and brute force is needed. You see this emerging with AI prototyping. Both approaches fall short. One misses how small decisions shape the system, and the other skips over details as it charges ahead. Modern software needs both views. And AI won’t fix these gaps… it will only make them worse if the right mindset isn’t there. That’s why I push for a third approach: progressive design. It tests assumptions at the screen level while shaping the bigger experience. Short, iterative cycles build the story. Adding signals from UX metrics and audiences makes it stronger. The beauty is that you can test incrementally with attitudinal metrics while also building a behavioral profile through actions. A recent customer used this approach with us using Helio on a complete homepage redesign and saw: +28% engagement on target KPIs +39% lift in positive impressions vs. baseline Curious what working styles have you seen work? #productdesign #uxmetrics #productdiscovery #uxresearch

While auditing content for an Entrepreneurship course at UNSW Arts, Design & Architecture I discovered a secret. The secret to enhanced user-centric innovation: We often get "stuck" with what we're taught, and this sometimes affects how we think. We all learn about Design Thinking as a standalone tool, but there's MUCH MORE to it. Integrating Design Thinking, Lean UX, and Agile methodologies creates a powerful framework for driving user-centric innovation. Here's how it works: → Design Thinking: for deep empathy and problem definition → Lean UX: for rapid prototyping and validation → Agile: for iterative development and delivery ... And what happens when each is missing? • Without Design Thinking = "Misunderstanding" • Without Lean UX = "Wasted Effort" • Without Agile = "Stagnation" Combining these methodologies offers a holistic approach. Concept Exploration + Iterative Experimentation = Needs-and-Pain-point Discovery The initial stages emphasize brainstorming and prioritizing insights, leading to hypothesis formation that guides subsequent experiments. Continuous experimentation allows for the revision of hypotheses based on real user feedback, creating a dynamic loop of learning and adaptation. Here's how to integrate them: 1/ Design Thinking: Start with empathy. Understand your users deeply before defining the problem. 2/ Lean UX: Prototype quickly. Validate your ideas with real users early and often. 3/ Agile: Iterate. Develop in short cycles and adapt based on feedback. As teams build and explore new ideas, they foster collaboration across disciplines, leveraging diverse perspectives to refine solutions. This integrated framework not only enhances the customer experience but also drives sustainable growth. This helps founders ensure they remain competitive and relevant in their respective industries. George Dr. Kelsey Burton Yenni 👀 LESSGO!

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