#16 Nobody prepared you for B2B UX

If you spend any time in UX communities — newsletters, talks, LinkedIn, conferences — you’ll notice that almost everything is about B2C. Viral apps, consumer products, redesign concepts for Gmail or Spotify. It makes sense: these products are visible, relatable, easy to discuss.

B2B UX is almost invisible by comparison.

And yet, a huge portion of UX jobs sit in enterprise companies. Platforms for sales teams, financial dashboards for CFOs, process management tools for operations departments. If you’re a junior designer, nobody is really preparing you for this world. And if you’re already in it and feeling lost, you’re probably not finding much out there either.

I gave a talk on this at UX Day 2024. The reaction in the room wasn’t surprise — it was more of a “finally someone is talking about this.” So here’s a longer version, for anyone who needs it.

B2B products are used by companies to run their business. That sounds obvious, but the implications run deep.

Your users aren’t scrolling for fun. They’re at work, trying to complete tasks, often under time pressure, often switching between your product and five other tools in their day. A small company might have a CEO using your platform to manage client relationships and find new business leads — doing everything themselves, not particularly tech-savvy. A large company might have a Head of Marketing using your tool to run acquisition campaigns and report to the board: highly specialised, working inside complex internal processes.

The interfaces that serve these users tend to fall into two categories (but can live in the same product):

• analysis interfaces (dashboards, data visualisation, anything that helps someone make a decision based on data)

• process management interfaces (tools that help coordinate, monitor, and move work forward).

A word that defines this space more than any other: collaboration. B2B interfaces rarely serve one person in isolation. Data gets shared via email, reports get exported for management, results get pulled into other systems. Designing for B2B means designing for handoffs.

A common challenge in this space is what I’d call the legacy problem. A lot of enterprise software has been around for a long time. The UI is dated, the UX has accumulated problems over years of patchwork development, and the technology underneath makes change difficult.

The consequences of this are predictable: high cognitive load (pages packed with content that make it hard to complete tasks), too many steps to do anything (long user journeys that could be cut in half), and users who are resistant to change. That last one catches a lot of designers off guard: when you redesign something that’s been working a certain way for years, even an improvement can feel threatening. Users know where everything is; they’ve built habits around the inefficiencies.

There are also two patterns worth knowing by name.

• Feature overload: the interface fills up with functionality, not all of it valuable, not all of it well organised.

• The “ad personam” feature: something gets added because one client asked for it, without a real product vision driving the decision.

Both are things you’ll encounter, and both are easier to push back on when you understand why they happen.

In B2B, not understanding the domain is a real liability. I experienced this directly: early in a project, I felt stuck because I didn’t understand the business context well enough to make design decisions. What helped was going back to basics — researching keywords, using AI to ask questions about our user base and the broader sector, focusing on understanding before moving to solutions. Once I understood the context, I knew which direction the design should go.

Interviews help (with users and stakeholders). Co-design sessions help. Desk research helps, and AI has made this faster. A stakeholder map helps you understand who you need to listen to and in what order. None of this is glamorous, but it’s what separates a designer who’s guessing from one who’s making informed decisions.

One of the mistakes I see most often in B2B design is treating the interface as if it exists in isolation. It doesn’t. It sits inside a workflow, which sits inside a department, which sits inside a company. Understanding how the service or system works — not just the screens — changes the decisions you make before you even open Figma.

Service design thinking is useful here, even if you’re not a service designer. A service blueprint forces you to think about what happens before and after someone uses your product, who else is involved, and where the friction really lives. Archetypes (not generic personas, but behaviour-based user types) help you make decisions about hierarchy and functionality that actually reflect how different people use the product. These tools help you make better decisions earlier, which is where the real leverage is.

This one sounds administrative, but it does real work. When you’re designing in B2B, there’s constant pressure to add features — from clients, from sales, from internal stakeholders with good intentions. Without clear product goals that everyone has agreed on, you end up with feature overload and ad personam additions that nobody planned for.

Keeping those goals visible — in alignment workshops, in design reviews, in conversations during delivery — gives you something concrete to refer back to when someone asks for a feature that doesn’t serve the product’s direction.

This is the one that surprises people, so let me be direct about what I mean.

In B2B design, trying to invent new patterns is usually a mistake. I’ve seen junior designers do this: either creating something they made up, or using well-known patterns in the wrong context. The result is an interface that users have to learn from scratch, which adds friction in an environment that already has too much of it.

Known UX patterns — sidebar navigation, breadcrumbs, tabs, filter panels, data tables, progressive disclosure — exist because they work. Users who spend their day in enterprise software have mental models built around these conventions. Working with those models, rather than against them, is not a creative limitation. It’s a design decision.

Progressive disclosure is worth calling out specifically: the idea of moving from overview to detail, surfacing complexity only when the user is ready for it, is one of the most useful tools you have in a space where information density is high and cognitive load is already a problem.

B2B interfaces are often behind a login wall, which makes benchmarking harder. But inspiration doesn’t have to come from B2B products. Some of the most useful references I’ve found come from B2C: health apps, finance apps, tools in completely different sectors that have solved data density or navigation problems in ways worth borrowing.

Mobbin is where I spend most of my research time; it gives you real flows from real products, filterable by pattern. But beyond that, I’d suggest downloading apps you use outside of work and paying attention to the moments where something works well. That pattern will come back to you when you need it!

Whether you’re deciding whether to pursue B2B roles, or you’re already in one and feeling like nobody prepared you for this — the gap tends to be the same. Not enough domain knowledge, not enough understanding of the system the interface lives inside, and too much time in Figma before that foundation is in place.

The good news: the gaps are fixable. And most of your competitors aren’t fixing them.

📚 Mentorship Mastery If you’re thinking about becoming a mentor yourself, or want to understand what good mentorship looks like from the inside, I recommend checking out the Mentorship Mastery course on Uxcel — it’s a great resource for anyone who wants to approach mentoring the right way.

💬 Work with me 1:1 I still have a few open spots for mentorship on MentorCruise. If you’re looking for a one-off portfolio and CV review instead, you can book one under “Sessions”.