Buyers, admins and users are different people
In a consumer app, the person who finds it, pays for it and uses it is usually the same person. In B2B SaaS, that is rarely true. At least three groups matter, and each wants something different.
| Who | What they care about | Where they meet your product |
|---|---|---|
| Buyer | Cost, risk, return, whether it fits the company. | Marketing site, pricing page, demo, security page. |
| Admin | Setup, control, users, billing, security. | Settings, user management, integrations, audit logs. |
| End user | Doing their daily job quickly. | The core product screens. |
Sometimes one person plays all three, as in a very small company. In larger ones, they are different people with different goals, and they may disagree. The buyer may choose a tool that the end users find slow. The end users may love a tool that the admin cannot secure.
The design question is: who is this screen for? Many B2B products try to serve everyone on every page, and serve nobody well. Name the user for each screen, and design for them.
Roles and permissions
Almost every B2B product needs roles: owner, admin, member, viewer, maybe more. Roles change what people can see and do, and that touches almost every screen.
Design problems that come up:
- What does a user see when they lack access? A button that does nothing is bad. Better options: hide what they can never use, and show what they can see but not change, with a short note on who can change it.
- How does an admin understand who can do what? A simple table of roles and permissions, in plain words, goes a long way.
- How are roles assigned? Let admins change roles in one place, and show the effect before they confirm.
- How are errors worded? "You do not have permission" is accurate and unhelpful. "Only workspace admins can invite people. Ask Maria or Sam." is useful.
- What about custom roles? Large customers will ask for them. Start with a few fixed roles. Add custom roles when real customers need them.
Plan for roles early. Adding them to a product designed for single users usually means redrawing many screens.
Dense data and tables
Consumer apps lean on cards, large images and simple lists. B2B products live in tables, filters, reports and forms. People use them for hours, and they want to see a lot at once.
That changes the rules:
- Density is a feature. A table with big padding and three rows per screen feels friendly and works badly. Offer comfortable and compact density, and let people choose.
- Speed matters more than delight. Keyboard shortcuts, bulk actions, saved filters and fast search save real time over a workday.
- Clarity beats decoration. Numbers should align, units should be clear, and columns should be sortable.
- Consistency matters. Users learn one table and expect all tables to work the same way.
- Handle large volumes. Think about thousands of rows, long names and missing values.
A more careful look at tables is a topic of its own, but the main point is: do not copy the look of a consumer app into a work tool.
Onboarding a whole team
Onboarding in B2B is not one person's first session. It is a group of people joining in stages.
- The first user signs up, often an admin or a champion, and sets up the workspace.
- They connect data, integrations or other tools.
- They invite teammates.
- Each teammate joins and needs their own first-run, shaped by their role.
- Over time, the admin configures settings, billing and security.
Designing for this means more than one welcome flow. The invited user should land in a workspace that already has something in it, not an empty room. The first user needs a good way to invite people, with clear role choices and a way to skip. The product should also handle partial adoption, where only half the team has joined.
It also helps to think about what happens when no one is the champion. If the person who bought the tool never finishes setup, who notices?
Sales-led vs self-serve
B2B products reach customers in two broad ways, and the design differs.
- Self-serve. People sign up, try the product and pay with a card. The product has to explain itself, the pricing has to be clear, and the first result has to come fast. There is no salesperson to rescue a confused user.
- Sales-led. A salesperson runs a demo, answers questions and closes a contract. The marketing site focuses on getting a conversation. The product can assume a guided setup. But the demo and the real product must match, or trust drops.
- Mixed. Many products let small teams self-serve and offer sales for larger ones. This needs a clear path for each, and a way to move from one to the other without starting over.
Know which one you are, because it decides where to spend design effort. A self-serve product needs very strong onboarding. A sales-led one may need strong demo materials and admin tools first.
Integrations and settings
In B2B, your product is part of a bigger set of tools. Customers expect it to connect to the systems they already use. This creates screens that consumer apps rarely have:
- Integration setup. Connect, authorize, choose what to sync, see the status, fix errors. Each step needs clear language, and each failure needs a clear message.
- Settings. Many B2B products have too many settings, thrown into one long page. Group them by task, use plain names, and put the rare ones out of the way.
- Billing and plan management. Admins need to see what they pay for, change seats and download invoices without contacting support.
- Security and compliance. Single sign-on, audit logs, data export and similar items matter to larger buyers. They may never be used often, but their absence can lose a deal.
- Notifications. Teams get overwhelmed fast. Give control over what is sent and to whom.
These pages are not glamorous, and often get little design attention. But for the admin and the buyer, they are the product. A buyer who finds a messy settings page may doubt the rest.
What we check first
When we review a B2B product, we look at a few things before anything else: whether each screen has a clear user, whether the roles make sense, how the tables behave with real data, what a new teammate sees on day one, and how the admin pages feel. Those usually tell us where the product loses people.
You can read about the products we focus on on our SaaS design agency page. A UX audit is a quick way to look at a live B2B product, and for a new one we plan roles, onboarding and settings early in an MVP design sprint. If you want a first opinion, send us a page for a free design review.
