UX
10 min read

Designing for experts: what I learned from a technical B2B website

When I started working on the MPB Communications redesign, I made an assumption I had to unlearn pretty quickly. I assumed that because the company's audience was highly technical, the website needed to lead with technical depth. Dense product specs, detailed datasheets, everything upfront.

That assumption was wrong, and the analytics confirmed it. High bounce rates on product pages, users dropping off after one click, almost no inquiries coming through. The information was there. People just weren't reading it.

The problem wasn't the product. MPB makes optical fiber lasers and photonics solutions used by researchers, telecom engineers, and space agencies. The product was genuinely impressive. The website just wasn't communicating it in a way that worked for the people arriving at it.

The audience was not one person

The first thing I had to get clear on was who was actually landing on the site. And the answer was: not one type of person.

There were engineers who already knew exactly what they needed and were looking for a specific spec sheet. There were procurement contacts and decision-makers who needed to understand what the company did before they could approve a conversation with the sales team. And there were first-time visitors who had found the site through search and weren't sure yet if MPB was even relevant to their problem.

The existing site was written entirely for the first group. Dense, technical, no entry point for anyone who wasn't already familiar with the product category. That works fine if every visitor is a returning engineer. It fails completely for everyone else.

A website for a technical company still needs to answer a very simple question for a first-time visitor: what do you do, and is it relevant to me? If it can't do that in the first scroll, you've already lost part of your audience.

Layering content instead of flattening it

The solution wasn't to remove technical detail. That detail matters to the buyers who need it. The goal was to layer it so different visitors could find what was relevant to them without being overwhelmed by what wasn't.

In practice, this meant restructuring every product page around a simple principle: start with the clearest possible summary, then let users go deeper on their own terms. A decision-maker gets enough context to understand the product's value in the first section. An engineer can scroll further and find the full spec breakdown. Neither one is blocked by content written for the other.

I used a modular card layout for product families specifically because it lets users self-select. Instead of landing on a wall of technical information and having to read through all of it to find what's relevant, visitors can scan and move toward what applies to them. The cognitive load drops significantly.

Navigation organized around the user, not the product

The original navigation reflected how MPB organized their products internally. That makes sense from an operational perspective, but it doesn't match how a buyer thinks when they arrive on the site.

Someone looking for a solution for a space application doesn't arrive thinking "I need a fiber laser." They arrive thinking "I need something for this specific application." If the navigation doesn't meet them at that level, they have to translate their problem into internal product language before they can even start exploring. That's friction, and friction is a reason to leave.

I restructured the navigation into three clear pillars based on product area (Telecom, Fiber Lasers and Amplifiers, Space Photonics) and added a separate Applications section for users who arrive with a use case rather than a product name in mind. Both paths are valid and both lead somewhere useful.

What this taught me: Navigation is not just a list of pages. It's a signal to the visitor about how the company understands their audience. If the structure makes sense to internal teams but not to buyers, it needs to change.

Credibility through restraint, not flair

One of the more interesting design decisions on this project was the visual direction. MPB's audience is researchers, engineers, and technical procurement teams. These are people who are skeptical by default, who read datasheets for fun, and who trust a company based on the quality and clarity of their communication, not the visual style of their website.

A bold, expressive visual design would have worked against that. Clean typography, strong product photography in real application contexts, and structured layouts communicate credibility to a technical audience far more effectively than anything trend-driven. The visual decisions were made to build trust, not to stand out.

This is something I think about on every project now. Visual design is always serving a purpose. On this one, the purpose was to make an expert feel confident that they were looking at a serious company worth their time.

What actually moved the needle

After launch, the results were clear. Total users up 248%, new users up 252%, and over 1,500 lead generation events in the months following. Mobile traffic grew by 158%, which directly validated the decision to wireframe mobile-first even for a site where the majority of users were on desktop.

But the number that meant the most to me was the lead generation one. Because that was the whole point. The product existed before the redesign. The audience existed. The gap was the website not doing its job as a communication tool.

  • Layered content lets multiple audiences find what they need without the experience breaking down for any of them.
  • Navigation structure communicates how well a company understands its buyers.
  • For technical audiences, credibility is the primary design goal. Visual restraint is a feature, not a limitation.
  • Starting with the audit before touching design prevented me from fixing things that weren't broken.
The takeaway: The users who land on a technical B2B website already know they have a problem to solve. The designer's job is to make it as easy as possible for them to confirm that this company is the right solution and take the next step. Everything else is noise.

I'd do one thing differently if I ran this project again. I would have pushed for user testing with actual buyers earlier, not just stakeholder reviews. The stakeholders knew the products deeply, which meant they sometimes had blind spots about what a first-time visitor needed. That kind of outside perspective is worth getting early.

But overall, this project changed how I approach technical clients. The complexity of the product is not the problem to solve. The gap between how the company communicates and how the buyer thinks, that's where the design work actually lives.

← See All Articles