What a SaaS site has to do
A SaaS website has one job: let a technical buyer decide whether this thing solves their problem, without talking to anyone.
Key Takeaways
SaaS website design goes wrong in a specific way: it describes the product instead of showing it. The visitor is usually the person who will have to operate the thing, they are comparing three tabs, and they are trying to answer one question — does this solve my problem — using only what you have put on the page.
Show the product, not an illustration of it
The default SaaS hero is a gradient, a headline about empowerment, and an isometric drawing of shapes that resemble no software anyone has used. Replace it with the actual interface doing the actual job, with real labels and plausible data. If the product is hard to photograph in one screen, show the narrow slice that matters most.
An interactive sandbox beats a video, and a video beats a static image, but all three beat an abstraction. The point is to let someone recognise their own work in it.
Publish the price
A pricing page where every tier says “Contact sales” tells a buyer that the price depends on what you think they can afford. Some enterprise deals genuinely are bespoke, and one custom tier at the top is normal. All of them being custom is a signal, and technical buyers read it correctly.
Say what the unit is, too. Per seat, per workspace, per run, per thousand events — a number without its unit is not a price. Whatever meters it, say what happens on overage before someone hits it.
Let people read the docs before they sign up
Documentation behind a login is a strange choice for a product whose buyers are the people who will read the documentation. The docs are where a technical evaluator decides whether the integration is a two-hour job or a quarter, and that decision happens before the trial, not during it. Public docs also give search engines something substantial to index, which is why they often out-rank the marketing pages.
A row of customer logos with no context persuades almost nobody, and if any of them are a lapsed pilot rather than a paying customer it is a claim you would not want examined. One named customer with a sentence about what they actually do with the product is worth the whole row.
Decide what the trial actually costs the visitor
Card-required trials filter for intent and shrink the top of the funnel. Card-free trials do the opposite. Neither is correct in general — but the page should be honest about which one it is, before the signup form. Discovering a card requirement on step three of onboarding is the kind of small dishonesty people remember.
The same goes for the demo request. If the “free trial” button opens a calendar booking, the button is lying, and the visitor who wanted to try the product has learned something about how the rest of the relationship will go.
Say what it does not do
Every product has a boundary, and naming it is the fastest trust signal available on a SaaS site. A short line about who this is not for, or which adjacent job it deliberately leaves alone, disqualifies the wrong visitors before they consume a sales call and persuades the right ones that the rest of the page is honest too.
What to cut
- Abstract 3D hero illustrations. They occupy the most valuable space on the site and communicate nothing about the product.
- Testimonials with no name or company. An anonymous quote reads as written in-house, because it usually was.
- Feature lists without outcomes. “Advanced analytics” is not a feature; the question it answers is.
- Chat widgets that open unprompted. They interrupt exactly the reading you wanted the visitor to do.
Planning a SaaS site rebuild? Start with the pricing page and the docs, then design the marketing around what they already prove. See our web design services, or the same treatment written for ecommerce stores.