How Do You Design a Website for a Product Nobody Understands Yet?
How Do You Design a Website for a Product Nobody Understands Yet?
Explain before you persuade. When a visitor has no mental model for what you sell, every clever line lands as noise. The page has to do one job first, which is to make someone able to describe your product to a colleague. Everything else waits until that has happened.
This is the hardest brief in marketing site work, and it is more common than it sounds. New categories, technical infrastructure, anything that replaces a process rather than a product: all of them arrive with the same problem, which is that the visitor cannot place you.
We end up in these projects often, and the failure mode is remarkably consistent. The team is so close to the product that they have lost access to what a stranger does not know.
Why Is Your Product Hard to Explain?
Usually one of three reasons, and they need different fixes. Either there is no familiar category to compare you to, or the value is real but invisible, or the product does several things and the team refuses to lead with one. Naming which of the three you have is the whole first step.
The no-category problem is the cleanest. The visitor has nothing to anchor to, so you have to lend them an anchor, even an imperfect one. Being placed in roughly the right neighbourhood beats being unplaceable.
The multi-thing problem is the most political, because solving it means choosing. A product that does five things gets described as a platform, and platform is the least informative word in software. Nobody has ever understood a company better after hearing it.
What Should the First Screen Actually Say?
What it is, who it is for, and what changes. In that order, in plain words, without a metaphor. If a visitor can read one sentence and correctly say what kind of thing you are, the hardest part of the page is done and everything after it gets easier.
The instinct to lead with transformation is what kills most of these pages. A headline promising to reinvent how teams work says nothing about what arrives when you buy. It reads as confidence, and confidence without content is exactly what a confused visitor does not need.
Write the boring version first. Then, only if it earns its place, make it better. In our experience the boring version survives more often than anyone expects, because it is the only version that answers the question the visitor actually arrived with.
Does Clever Copy Ever Help Here?
Rarely, and the research is unusually blunt about it. John Morkes and Jakob Nielsen ran a study at SunSoft's usability labs in Menlo Park in summer 1997 with 51 experienced web users, comparing five versions of the same site content.
The results held up in every direction. A scannable version measured 47 percent better usability than the promotional control. A concise version came in 58 percent better. An objective version, stripped of promotional language, was 27 percent better. Combining all three produced a version 124 percent better than the promotional original.
The study is old, which people use to dismiss it, and that is a mistake. It tested whether marketing language helps people understand and use a site, and found it actively hurt. Nothing since has reversed that, and the pressure to write marketese has only grown.
How Do People Actually Read the Page?
They mostly do not read it. Nielsen's write-up on how users read on the web, published on 30 September 1997, reported that 79 percent of test users always scanned any new page they came across, and only 16 percent read word by word.
That changes what a page for an unfamiliar product has to do. You are not writing an explanation to be read in order. You are placing a small number of statements where a scanning eye will land on them, each of which has to make sense on its own.
Practically, that means the headline, the subheading, the section headings, and the image captions carry the explanation. If someone read only those and nothing else, they should still come away with a correct idea of what you sell. Our piece on designing for skimming covers the layout side.
How Do You Show Something Abstract?
Show the thing itself, badly, rather than a beautiful abstraction. A real screenshot with real data beats an illustrated diagram of glowing nodes every time, because the screenshot answers what the product is and the illustration answers nothing.
When there is genuinely no interface to show, show the artefact. What does the customer end up with: a report, an alert, a decision, a saved hour? Photograph or render that. Infrastructure products often have a moment where something visibly happens, and that moment is your hero image.
Interactive demos work well here too, if they are short and cannot be failed. A guided three-step walkthrough that ends in a recognisable outcome teaches more than a page of copy. We wrote about that format in our piece on interactive product demos on websites.
Should You Explain the Problem or the Product?
The problem, but only for one screen. Opening with the problem gives the visitor a place to stand, and it lets them self-identify before they have to understand anything technical. It is the fastest way to make an unfamiliar product feel relevant.
The failure is staying there. Pages for hard-to-explain products often spend three sections describing a pain the reader already has, which is flattering to write and useless to read. They know their problem. They came to see whether you are a plausible answer to it.
Our rule of thumb is one problem statement, then straight into what the product does about it. If the problem section is longer than the explanation section, the page is stalling.
How Much Detail Belongs on the Homepage?
Enough to be credible, not enough to be complete. A technical buyer evaluating something unfamiliar is looking for evidence that you have thought it through, and that evidence is specifics: a real constraint, a real number, a real integration name.
Vagueness reads as evasion to exactly the audience you need. Saying you work with existing systems tells a buyer nothing. Naming the three systems you connect to tells them whether to keep reading, and losing the people it loses is a feature.
Then put the rest one click away. A homepage that explains and a second page that proves is a better structure than one page attempting both, and it gives your sales team something to send. Our notes on how it works sections cover that middle layer.
How Do You Test Whether It Landed?
Ask a stranger to describe your product back to you after fifteen seconds on the page. Not whether they liked it, not whether the design felt premium. Just what they think it is and who it is for. The gap between their answer and the truth is your actual brief.
Do it with five people outside your industry and the pattern shows up immediately. Everyone will misunderstand the same thing, and that thing is almost always a word your team uses internally without noticing it is jargon.
It is also worth asking an AI assistant to summarise your homepage, because that is now a real reader. If the summary is wrong, buyers using those tools to shortlist vendors are getting the same wrong answer, and you will never see it happen.
What Would We Do First?
Write one sentence that says what it is, who it is for, and what changes, then read it to someone who does not work with you. If they can repeat it, build the page around it. If they cannot, nothing else on the page will rescue it.
Then cut every word that is doing persuasion while the visitor is still doing comprehension. That order is the whole discipline. Explain, then prove, then persuade, and resist doing them simultaneously because it feels more efficient.
If you are staring at a homepage that your team understands and nobody else does, we are happy to look at it with fresh eyes. That is a normal piece of work for us at phoenix.studio, and the first draft of the plain version usually takes an hour.
Want a site that performs like this?
Tell us about your project. We will come back with a clear next step, no pressure.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Have a project like this?
Tell us where you want to go. We'll tell you how we'd get you there.