How to Diagnose Your B2B SaaS Website Before You Redesign It

At one point, the navigation on a marketing site I owned had become enormous.

It listed nearly every solution, industry, and feature we offered. Nothing was missing. That was part of the problem. Opening the menu gave people a wall of choices, and we had made it their job to sort through them.

The session recordings made the problem hard to miss. People opened the navigation, scanned it, and often left without going very deep. Even visitors who seemed to know what they wanted did not always find the right page.

So we tried a simpler version.

We looked at which pages people visited most, which were gaining search visibility, and which terms brought people into the site. We moved the few destinations that appeared most useful to the front. Everything else sat behind a “show all” option.

What I remember from the later recordings is that people seemed to reach the relevant industry, solution, or feature page faster. Our customer experience and support teams also found it easier to pull up information while talking with customers.

We had evidence of people getting stuck before we changed the menu. Simpler navigation was our hypothesis, not our starting assumption.

A redesign does not tell you what is wrong

I understand why marketing teams reach for a redesign. Sometimes it is the right call. The company has been acquired. A new leader changes the strategy. The brand no longer reflects the business. Or the underlying technology makes routine marketing work painful.

I have also seen teams reach for a redesign because traffic is down or the website is not producing enough pipeline. Those problems are real. Neither one tells you what to build.

A redesign changes many variables at once: messaging, page structure, navigation, design, technology, forms, and analytics. If the numbers improve, which change mattered? If they do not, the team has spent months rebuilding the site and still does not know why buyers are getting stuck.

The opposite mistake is to test whatever happens to be easy. I have done this too: a new button label, a different CTA, a small layout adjustment. Those tests have their place. They will not help much when the problem is structural.

Buyers may not understand the product. The navigation may reflect the company’s internal categories instead of the way customers think. Or visitors may reach a working demo form without enough confidence to submit it. A button test will not answer any of those questions.

Find the problem before choosing the size of the change.

What we borrowed from Making Websites Win

Karl Blanks and Ben Jesson’s Making Websites Win had a large influence on how we worked.

One of its central ideas is DiPS:

Diagnose → Problem → Solution

We followed that process pretty closely.

We drew from analytics reports, Google Search Console, SEO data, session recordings, and what our customer-facing teams were hearing. Analytics told us where people went, but not what happened between one page and the next. Search data showed how they found us. Recordings showed us the hesitation, backtracking, and dead ends that the reports could not.

Then we tried to name the problem and decide what might fix it.

For the navigation, the recordings suggested that people were not using the menu as we intended. Traffic and search data helped us decide which destinations deserved priority. We still did not know that a simpler menu would work. We had a reason to test one.

DiPS also kept us from confusing continuous improvement with tiny changes. The book has a good term for arbitrary optimization work: “meek tweaking.” A small test can look rigorous because it has an experiment attached. The quality of the experiment still depends on the idea behind it.

Sometimes the diagnosis calls for a small fix. It can also point to a new page, a different conversion path, a structural change, or even a redesign. The evidence should determine the scale.

Start with the action that matters most

In practice, diagnosis starts with knowing what the website is supposed to help someone do.

At the sales-led company where I learned this approach, that action was requesting a demo. It was our load-bearing event because it created the clearest connection between the website and the sales process.

From there, we could work backward. Which pages brought the right visitors into the site? Where did they go next? What did they need to understand before a demo felt worthwhile? Where did they leave? And did the landing page, form, scheduling experience, and sales handoff work together?

We experimented with page layouts, content, forms, and booking experiences. I cannot point to one test and say it changed everything. What helped was having a shared way to decide what deserved attention.

You do not need an elaborate experimentation program to begin. Build a few useful reports in GA4. Check page and query trends in Search Console. Use an SEO tool such as Ahrefs if you have one. Watch recordings. Ask sales and support what customers keep asking because the website does not answer it.

Choose one point in an important path where the evidence suggests people are struggling. Write down what you think is happening and what change may help. Make the change, then look again.

Before committing to a redesign, answer five questions:

• What is the load-bearing action?
• What evidence shows that buyers are getting stuck?
• What specific problem do you think is causing it?
• What change would address that problem?
• What would you expect to observe if you are right?

If those answers are still vague, you are not ready to choose a solution.

A redesign may still be the answer. By then, you should be able to say what you expect it to fix—and why rebuilding the whole site is necessary.