Before You Redesign Your SaaS Website, Decide What Needs Explaining

Bytek’s before-and-after homepage recordings show how a product explanation can change without discarding everything the old site got right.

In a sales conversation, you can explain a vague promise, give a diagram context and answer the question the page leaves open. If you run a SaaS company and handle marketing yourself, you may do that without noticing how much you are adding. A buyer reading the website alone gets the page.

I’m Head of Marketing at Merge Rocks. AI helped me research and write this article.

The Bytek case page includes two homepage recordings. They make a useful comparison because the older version already contained much of the substance a redesign brief might ask someone to introduce.

The product was already there

In the recording labeled Before, Bytek promises “from Data to Marketing Performance through AI.” The page has platform navigation, named AI modules, customer logos and an offer combining software with expert support.

The recording labeled After foregrounds predictions. It connects the platform to marketing tasks, including paid-media optimization and customer engagement. Product illustrations accompany the explanation, and a later section describes specialists’ tuning and configuration role.

The difference I would put in a brief is the connection between the output, the task and the people involved.

A broad promise about marketing performance gives a buyer a direction. Naming an output gives them something more specific to investigate: what the software produces and which decision it helps them make.

That changes what an illustration needs to accomplish. A graphic that looks like software may establish the product category while leaving its use unclear. The buyer still needs to connect what they see with something they need to do.

Specialist involvement needs the same precision. A buyer assessing software needs to understand what they will handle themselves and what the provider will configure. Removing that explanation to make the offer appear more self-serve could create the wrong expectation.

“Make it more product-focused” leaves too much of this unresolved. A designer can reorganize the story. The founder still has to explain the product accurately enough for the designer to know which relationships to show.

And there is no reason to discard accurate module information or relevant customer logos because they belong to the older design.

The explanation has to work with and without you

Paolo Dello Vicario, Bytek’s CEO and co-founder, describes the site’s role in a video testimonial published by Merge Rocks:

“Right now the website is the pillar for every single presentation.”

He also describes wanting someone who starts with the product and expresses its value graphically.

A founder using the site during presentations has a direct way to assess that work. Can you point to the page while explaining the offer, or do you have to explain around it?

During a conversation, you can tell someone how an output relates to their situation. You can discuss whether the product fits their requirements. Those are legitimate reasons to talk.

But if you repeatedly have to explain what the product does before that discussion can begin, the page may be leaving basic work to you.

I would put that repeated explanation into the brief, then decide how much belongs on the website. A visitor needs enough context to understand the offer and choose a sensible next step. They do not need every answer a specialist might give after learning about their business.

The recordings show how Bytek presents the offer; Paolo tells us how he uses the site. They do not test the software, show what an unfamiliar buyer understood or establish a gain in sales or conversions.

The next step deserves the same attention as the product explanation. The newer recording shows “Get a Demo,” “Schedule a Meeting” and “Try the Platform.”

Those labels can prepare a buyer for different commitments. The recording does not follow them, so their destinations and access conditions remain open questions.

Before changing an invitation, follow it. Establish what the buyer will see, what they will be asked to provide and whether a conversation or configuration comes before access. Several invitations can coexist if the journey explains their relationship.

A functioning button is only part of that check. Its promise needs to match what happens next.

A founder brief built from the comparison

This is the brief I would propose from the public materials.

• Establish whether the page leaves a buyer answer missing or inaccurate before deciding that work is needed.
• Explain what prediction the platform provides, which marketing task it supports and where specialists configure or tune it. Give product illustrations a specific part of that explanation to carry.
• Retain accurate platform and module information, relevant logos and the context around human support.
• Verify what the demo, meeting and platform invitations request. Change their wording or destinations only after understanding the actual journey.
• Check the explanation and route against those requirements. Use suitable readers to assess comprehension separately.

These are criteria for the explanation and route, rather than acceptance criteria for an entire website release.

The brief leaves room for no change, further verification or a limited edit. A broader proposal should explain why its scope fits the problem.

On your own site, start with an offer you sell now. Locate its promise and the explanation behind it. Follow the next action. Write down where you have to supply information the page omits, alongside what it already explains accurately.

Your familiarity will fill some gaps before you notice them. A founder’s walkthrough can expose a mismatch with the offer; it cannot establish what an unfamiliar buyer understands. If that uncertainty affects the scope, it needs a suitable reader check.

You may also have a reason to commission work that has little to do with missing explanations. An agreed rebrand needs implementation. A changed offer may require new routes. A publishing limitation needs assessment against a real update you cannot handle adequately today.

None requires advance proof of additional revenue. Each needs a clear account of the requirement and why the proposed work addresses it. Finding no obvious website problem, meanwhile, does not prove that acquisition is the problem elsewhere.

For an explanation problem, I would buy work that gives a buyer enough context to judge the offer and understand the next step. The proposal should show what is missing, where the page will supply it and how the scope addresses the gap.

If that connection remains unknown, resolve it before buying the redesign.

Before You Redesign Your SaaS Website, Decide What Needs Explaining was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.