Creating Scalable User Experiences for B2B Platforms

🔬 How To Run UX Research In B2B and Enterprise. Practical techniques of what you can do in strict environments, often without access to users. 🚫 Things you typically can’t do 1. Stakeholder interviews ← unavailable 2. Competitor analysis ← not public 3. Data analysis ← no data collected yet 4. Usability sessions ← no users yet 5. Recruit users for testing ← expensive 6. Interview potential users ← IP concerns 7. Concept testing, prototypes ← NDA 8. Usability testing ← IP concerns 9. Sentiment analysis ← no media presence 10. Surveys ← no users to send to 11. Get support logs ← no security clearance 12. Study help desk tickets ← no clearance 13. Use research tools ← no procurement yet ✅ Things you typically can do 1. Focus on requirements + task analysis 2. Study existing workflows, processes 3. Study job postings to map roles/tasks 4. Scrap frequent pain points, challenges 5. Use Google Trends for related search queries 6. Scrap insights to build a service blueprint 7. Find and study people with similar tasks 8. Shadow people performing similar tasks 9. Interview colleagues closest to business 10. Test with customer success, domain experts 11. Build an internal UX testing lab 12. Build trust and confidence first In B2B, people buying a product are not always the same people who will use it. As B2B designers, we have to design at least 2 different types of experiences: the customer’s UX (of the supplier) and employee’s UX (of end users of the product). In customer’s UX, we typically work within a highly specialized domain, along with legacy-ridden systems and strict compliance and security regulations. You might not speak with the stakeholder, but rather company representatives — who regulate the flow of data they share to manage confidentiality, IP and risk. In employee’s UX, it doesn’t look much brighter. We can rarely speak with users, and if we do, often there is only a handful of them. Due to security clearance limitations, we don’t get access to help desk tickers or support logs — and there are rarely any similar public products we could study. As H Locke rightfully noted, if we shed the light strongly enough from many sources, we might end up getting a glimpse of the truth. Scout everything to see what you can find. Find people who are the closest to your customers and to your users. Map the domain and workflows in service blueprints and . Most importantly: start small and build a strong relationship first. In B2B and Enterprise, most actors are incredibly protective and cautious, often carefully manoeuvring compliance regulations and layers of internal politics. No stones will be moved unless there is a strong mutual trust from both sides. It can be frustrating, but also remarkably impactful. B2B relationships are often long-term relationships for years to come, allowing you to make huge impact for people who can’t choose what they use and desperately need your help to do their work better. [continues in comments ↓] #ux #b2b

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

In enterprise software, you’re not designing for a person. You’re designing for an org chart. That’s one of the hardest truths for designers to internalize. Ignore any node in that system—user, buyer, or other stakeholders—and your product will struggle. In consumer apps, the path from value to purchase is often more direct: one person discovers, pays for, and uses the product. There’s usually no one else in the way. But in enterprise B2B? Totally different dynamic. Take cybersecurity, where I’ve spent years designing tools: - The Security Engineer uses the software. - The Chief Security Officer signs the contract. - And sometimes a CTO torpedoes the whole deal before it even gets started. I’ve had to design for all of them. Because if you neglect the buyer, you won’t sell. If you neglect the user, you won’t retain. And if you ignore the stakeholders, you risk getting shut down before you can even prove your value. Here’s what I’ve learned: - The user wants tools that make their day-to-day work easier. - The buyer wants measurable outcomes they can report up the chain. - The stakeholders just want the thing to fit into the existing system without causing headaches. The best enterprise tools are built for this full cast—not just the person clicking the buttons. If you’re a designer working in enterprise B2B, don’t let your empathy end with the end user. Map the real org chart. Learn what motivates each persona. And design your way through the complexity. That’s the real game. — How do you balance the needs of users, buyers, and stakeholders in your product work? I’d love to hear how others navigate this complexity.

Your B2B site isn't too complex. It's playing dress up as B2C. I keep seeing optimization "experts" preaches simplification. One click demos. Stripped down pages. Consumer style funnels. Heck, I've said it before. We're wrong. Your enterprise buyers evaluate million dollar decisions. They need comprehensive information. Deep technical specs. Detailed implementation guides. Stop insulting their intelligence with dumbed down experiences. Our technology stakeholder research at The Good | Digital Experience Optimization revealed the truth... CTOs juggle multiple priorities, legacy systems, and fragmented experiences. They want organized complexity, not oversimplification. B2B success demands depth. I've worked with enterprise B2B for 15+ years. Every CPO tells us the same thing: ↳ "Our site needs comprehensive information, not kindergarten explanations." Our most successful clients embrace their complexity. Then, they organize it brilliantly. They use clear navigation hierarchies, smart filtering, contextual help. Your buyers built 47-point evaluation criteria. They spent months on requirements. Give them what they need! If you must compare to B2C... Amazon doesn't apologize for having millions of products. They make finding the right one effortless. Your B2B site should work the same way. Respect your buyers' expertise. Organize your complexity. Watch conversions soar.

We just refreshed the website for a $150M+ HR tech company, where the product was built for employees, but bought by HR. This means: the people using the product weren't the ones buying it. 🤔 So how do you build a website that speaks to the buyer… when the product experience is built for the end user? This is where most companies slip up. Naturally, since the product is designed with users in mind, the website ends up with: - Messaging that addresses the user. - Consumer-style screenshots across pages - Features highlight ease-of-use, workflows etc So when a B2B buyer lands on a page that looks and feels like it’s built for consumers, it creates confusion. It raises the questions: Is this even built for businesses? or Is this something for end users? Here’s how we approached it: When someone from the buying side lands on your site, your goal isn’t to convince them that the product will work for them. It’s to show them it will work for their internal customers (users) That means using clear signals throughout the site: → Headlines that speak to business outcomes → CTAs that align with buyer intent → Value props that show real user impact → And don’t rely on glossy, consumer-style screenshots. Instead, show how the product scales so buyers see it as a solution that fits across the organization. Because that’s the real challenge: If your website speaks only to the end user, and not the actual buyer, you risk confusing or losing the buyer entirely.

"We've identified all these user needs and created a roadmap to address them, but it's just a long list of disconnected features. We keep shipping, but we're not moving metrics or able to pivot quickly when we learn new things about our users." While starting with user problems is a great first step, translating them directly into specific feature solutions often leads to rigid roadmaps and narrow implementation paths that limit your team's ability to adapt as you learn more. There's a more strategic approach: Capability-Driven Roadmaps What's the difference? ↳ A feature is a specific solution to a specific user problem ↳ A capability is the power to address a class of user problems in multiple ways For example: 🔦 Users need control over their experience → Instead of "add dark mode," think "build preference management capabilities" 📚 Users need relevant content discovery → Instead of "add homepage recommendations," think "develop personalization capabilities"  💸 Users need seamless payment options → Instead of "implement Apple Pay," think "expand payment processing capabilities" Capabilities create more business value: 1️⃣ Adds optionality to your roadmap Each capability you build opens multiple paths to value, allowing you to respond quickly to market changes. When your experiment fails (and some will), you can pivot to a new implementation without rebuilding foundations. 2️⃣ Ties directly to your business outcomes Great capabilities are outcome multipliers. A robust recommendation capability doesn't just power one feature — it enables personalization across your entire product, directly impacting engagement, conversion, and retention metrics. 3️⃣ Compounds in unexpected ways Capabilities combine in unexpected ways. The intersection of your identity, personalization, and communication capabilities might enable an entirely new product experience you hadn't initially envisioned. 4️⃣ Improves time to market A capability-focused approach doesn't mean slow platform projects with distant payoffs. These capabilities can be built incrementally, with each providing immediate business value while expanding future possibilities. Ensure each capability: ↳ Addresses persistent user needs, not just one-off requests ↳ Connects directly to current business priorities ↳ Delivers at least one immediate, measurable win ↳ Starts with user problems, not technology solutions The most successful product teams start with user problems, but they don't just build one-off features — they systematically develop capabilities that address fundamental user needs while creating sustainable competitive advantage and immediate business impact. #productmanagement #productstrategy #leadership -------- 👋 Hi, I'm Nathan Broslawsky. Follow me here and subscribe to my newsletter above for more insights on leadership, product, and technology. ♻️ If you found this useful and think others might as well, please repost for reach!

Brands used to broadcast. Now they respond. ✅ Think of a B2B SaaS platform where every interaction flexes to the person in front of it. A procurement officer logs in and the dashboard emphasizes compliance, audit trails, and control. A developer logs in and the experience surfaces APIs, sandbox access, and speed. A CFO sees ROI models, forecasts, and financial clarity. Same product. Same brand. Different resonance. This is the rise of responsive brand experience. Not a gimmick, but a strategy: making every layer of identity—UI, UX, content, and even tone of voice—adaptive, intelligent, contextual.❤️ The contrast is striking. Legacy enterprises still design for the average user. They ship one interface, one story, one pathway. Digital-first players design for each user, building systems that adjust like living organisms—changing not only logos, but dashboards, help content, and even microcopy to meet the user where they are. There’s philosophy behind it. Customers don’t just want “software that works.” They want “software that gets them.” Adaptive design—whether in visual identity, navigation, or communication—signals empathy. It says: we see you, we know what matters to you, and we’ll clear the clutter so you can move faster. But the danger is real. Adapt too much and you lose coherence. A CFO may welcome tailored insights but won’t trust a brand whose tone, design, or values feel inconsistent. Responsiveness must orbit around a strong, immutable core: trust, reliability, transparency. What shifts is the expression; what stays firm is the essence. So, the real question for technology brands is not can you adapt? It’s why and how much?💯 The opportunity is profound. Responsiveness is not decoration. Not novelty. It’s a signal of intelligence. The same principle behind great products—turning complexity into clarity—should govern the brand experience itself. When UI, UX, and content stop shouting and start listening, the brand doesn’t just “look” intelligent. It feels intelligent. That’s when technology stops being a tool and starts being a partner. #futureofmarketing #thoughtleadership #thethoughtleaderway

Can you really deliver cohesive and scalable user experiences across thousand of enterprise products without a #designsystem? At SAP, the answer is clear: No. As our #SAP product portfolio has grown over the years, so has the complexity of maintaining coherence across experiences. With so many teams, technologies, and touchpoints involved, the risk of fragmentation is real. That’s why the #SAPDesignSystem is a crucial part of how we design, develop and build products and solutions: providing shared design principles and guidelines, reusable UX components, design patterns, accessibility guidelines, and a unified design language that cuts across product, brand and every customer touch point. It empowers designers and developers to move faster, stay aligned, and ultimately deliver connected, familiar, and user-centered experiences (no matter the product). I see it as a foundational piece in realizing our vision: creating user experiences that people love to use. Check out the #SAPDesignSystem: https://lnkd.in/e6UpMZ6e What’s your take on the role of design systems in scaling #UX? Let’s discuss 👇 #SAPDesign #SAP #DesignSystem #UX #EnterpriseUX #UserExperience