7 Insights for Navigating B2B Design
Key dynamics I wish I had known sooner in my enterprise design career.
Hello! I'm Pat, your guide to the business of creative technology and innovation. New here? Join our supportive community to fuel your creative journey!
Shifting from B2C to B2B software design isn't just a change of audience — it's a whole new playing field.
Today I’ll expand on my reply to Linear CEO Karri Saarinen’s post on this topic and highlight 7 key insights that helped me navigate the shift in my career.
In the last 7 years, I designed 3 separate 9 & 10-figure cybersecurity startups.
After spending the early years of my career focused on consumer-facing products, I was surprised to discover the differences in B2B.
B2B design differs from B2C but gets little attention from the design community.
It’s sad, but it makes sense.
B2B software isn’t a sexy topic ripe for social media shares.
The brands aren’t names your family will recognize.
And the aesthetics won’t excite designers like flashy new consumer tech.
That said, B2B software is incredibly high leverage when well-executed.
This makes good B2B software as good as gold and the companies that create it very valuable. It also makes the jobs they offer quite lucrative.
The B2B SaaS work environment differs from what many designers expect, but I think it’s worth their attention. It’s an area ripe for design disruption with the right mindset and culture shifts. Let’s be real, the design quality bar in this space is low. But this makes the impact of good design that much more significant and far-reaching.
Now let’s dig into a few key insights that helped me navigate this landscape.
Key Insights
1. Frontstage vs. Backstage Customer Service
B2B organizations look different than B2C ones.
In particular, they have large departments dedicated to customer service beyond basic support staff. These teams go by many names, but the ones I’ve encountered the most are ‘professional services’, ‘solutions architecture’, ‘account management’, and ‘customer success.’ The people in these roles are in constant contact with users and it’s their full-time job to understand their needs, represent them, and help them succeed.
This opens a lot of options for how to solve customer problems. It’s like layering a service business on top of a software business.
Frontstage vs. Backstage is a Service Design metaphor that helps make sense of the many actions that serve a customer across all the touchpoints in an enterprise.
In this context:
Frontstage = Things that happen in direct view of the customer
These could be interactions between the customer and the software or the customer and an employee.
Backstage = Things that happen behind the scenes to support frontstage actions
This includes everything the team does to deliver the software and anything a team member does on behalf of the customer without their presence.
In this context, shipping new software to the customer isn’t always the best way to solve their problem. Sometimes a frontstage employee can handle it manually. Other times creating an internal tool to help frontstage colleagues serve the customer will make a bigger impact. Ultimately, you can create systems and software to facilitate any frontstage process, whether it’s led by the customer or by an employee on their behalf.
Frontstage and backstage need to work together to deliver a great user experience but it can be tricky because there’s a lot to coordinate. I like to capture these collaborative workflows in Service Blueprints, which you can think of as a user journey with an added dimension that maps your organization and services onto the user’s journey to visualize how you deliver on their needs from end to end.
2. The User vs. The Buyer
In consumer software, the person who buys the product tends to be the one who uses it.
This isn’t the case in enterprise software.
In this context, the person who makes the purchase decision (the buyer) is often different from the person who uses the software daily for their work (the user).
An example from my cybersecurity career:
Security engineers used our software.
Chief Security Officers bought our software.
In practice, that meant that I designed mostly for the security engineer (the user) but needed to deliver enough value to the Chief Security Officer (the buyer) for them to decide to sign the contract. That’s no small feat when contracts range in the hundreds of thousands or millions of dollars per year.
Be careful not to neglect either one of these personas. Designers gravitate toward the user, but if you neglect the buyer then your product will struggle to sell. On the flip side, salespeople gravitate toward the buyer, but if you neglect the user then your software will struggle to retain and upsell when it comes time to renew the contract.
There are also sometimes third parties (neither the user nor the buyer) who can torpedo the sales process. For instance, a CTO who refuses to integrate your service in their tech stack no matter how good your solution is.
3. Long-term Relationships with Clients
Enterprise software often involves long-term client relationships.
Contracts tend to be measured in years, not months.
These extended relationships are a blessing for design because they open the door for more consistent and transparent feedback. The best ones evolve into a kind of mutually beneficial partnership that makes each business stronger.
These clients see the value in your software and want to help you improve your product so they can do their business better.
Rather than having to rely on macro-level consumer data to inform design decisions, you can talk directly with customers who are invested in helping you succeed.
Leaning into the collaborative process of designing and building with your customers rather than just for them can unlock great results.
It’s pretty much the definition of “win-win.”
4. Different "Voices of the Customer"
As a junior designer, I was taught that design should be the “voice of the customer.”
However, at my B2B startups, there were even stronger customer advocates already inside the company. These are the frontstage departments I mentioned earlier.
While it felt unnatural at first, I learned to loosen my grip on the idea that I needed to be the primary “voice of the customer” to make a difference with design.
Instead, I shifted my focus to interpreting the constant flow of feedback coming to my colleagues and synthesizing it into smarter design choices for the product.
Establishing the customer feedback loop from frontstage teams to design opens the product design flywheel. B2B companies have the gift of continuous feedback. Don’t waste it just because you’re hung up on the idea that only design can represent the customer’s needs.
5. Qualitative data > Quantitative data
Quantitative data can be harder to come by in a B2B context because the number of users tends to be much smaller than B2C. You’re likely working with tens or hundreds of customers rather than thousands or millions.
In my career at enterprise startups, I never had the user scale to get quantitative results fast enough to routinely inform my choices.
This meant some methodologies (like A/B testing, for instance) weren’t useful.
Instead, this environment prioritized a combination of qualitative research and craft to make design decisions.
As I mentioned earlier, B2B environments are rich with qualitative feedback coming directly from customers.
This makes them a surprisingly good place for designers to flex their skills, which tend to be grounded in qualitative methods.
6. Compliance Requirements
Enterprise software has stricter requirements for security, compliance, and accessibility.
Highly regulated industries like finance, healthcare, or the government stand out as obvious examples.
No matter how you slice it, compliance requirements introduce more complexity to any design project. However, if you plan accordingly you can make strategic design decisions to minimize the impact and handle compliance gracefully.
Compliance requirements can manifest in a bunch of ways:
Content requirements like legal copy
Technical requirements like data privacy protections
Design requirements like accessibility standards
And so on…
These can be real challenges for crafting a thoughtful and aesthetic interface.
However, if you accept these as inevitable and create your UI with flexibility and resilience in mind they don’t have to destroy your design hopes and dreams.
You might not get the full version of your ideal design, but you don’t have to ship a scary Frankenstein either. I promise.
7. High Stakes Changes
The stakes of making changes in B2B software can be very high.
Mistakes can cost millions of dollars.
Screwing up another business’ operations can cause them real financial harm. Meanwhile, losing a single, valuable enterprise customer can be a big hit to your company’s bottom line.
For example, when I was designing the firewall configuration experience at Signal Sciences / Fastly, shipping a poor experience could result in an error that would take down our systems, our customers’ systems, and the other businesses that depended on them. Trust me, you don’t wanna be on the receiving end of that phone call.
So in B2B, teams need to respect the high-stakes nature of the changes they ship. They must ensure the software is robust and performs well under a wide range of conditions. While designers may not push the code to production or be on-call to resolve an outage, we owe it to our teammates to “measure twice, cut once” and be deliberate in our approach to prototyping and rollout.
Final Thoughts
B2B design is rich with challenges but even richer with opportunities.
By understanding the unique landscape of B2B — from company dynamics to customer interaction — we can create designs that aren't just functional, but foundational to business success.
So, as we wrap this up, think of it this way: your design can change how businesses work for the better. With your skills and my guidance, you can help make software that shapes industries and improves the lives of those who work in them.
Here's to making work life better for everyone with great design.
Until next time,
Pat
Conversation Starter
Have you ever transitioned from B2C to B2B software? What was the most surprising challenge you faced?
Community Poll
If you got a little value from this post, consider subscribing or sharing. Follow me on LinkedIn and X/Twitter for daily posts.