By Mehdi HassanHow do you explain a complex product on a website?
You explain a complex product on a website by answering, in order, the four questions a new visitor asks: what is this like, how does it work, does it really work, and can I see it. We call that sequence analogy, mechanism, proof and visual. It's the method we use on every "complex products made clear" project, and it works for AI tools, developer platforms, fintech infrastructure and anything else a buyer can't picture on first read.
The order matters. An analogy without a mechanism sounds like a pitch. A mechanism without an analogy is hard to follow. Proof without either lands on someone who doesn't yet know what they're looking at. And a visual that arrives before the words just decorates.
This page is the hub for our series on explaining complex products. Each section links to a deeper guide, and the last section lists everything in reading order. If you're working on the copy side generally, our complete guide to SaaS website copywriting is the broader companion.
- Projects Designify has shipped
- 60+
- Industries, from AI and SaaS to fintech and healthcare
- 14+
- Fixed price for a Designify landing page
- $6,000
Why do buyers fail to understand complex products?
Buyers fail to understand complex products because the team that wrote the website already understands them. Founders and engineers describe the product the way they built it: architecture, features and category jargon. Visitors need it described the way they'll use it: the problem it removes and the result they get.
Three habits cause most of the confusion we see:
- Starting with the category. "An AI-native observability platform" means something to the five people who already use that category, and nothing to the rest.
- Listing features before the outcome. A grid of twelve capabilities forces the visitor to work out what they add up to.
- Claiming instead of showing. "Fast, secure and scalable" can describe any product, so it describes none.
There's also a market gap. When we researched how to explain a complex product, the results were mostly video production agencies pitching explainer videos. Video can help, but it's one visual format, not a method. The method has to start with the words, because a visitor who can't repeat what you do in a sentence won't book a demo, and neither will the colleague they forward the page to.
What is the analogy, mechanism, proof, visual method?
The analogy, mechanism, proof, visual method is a fixed sequence for explaining any product a visitor can't picture. Each layer answers the question the previous one raises, so the page reads like a conversation instead of a spec sheet.
Layer | Question it answers | Where it lives on the page | How it fails |
|---|---|---|---|
Analogy | What is this like? | Hero subhead or first line under the headline | Caps your value or points to the wrong reference |
Mechanism | How does it actually work? | A three-step how-it-works section | Becomes an architecture diagram nobody asked for |
Proof | Does it really work? | Right after the mechanism, and beside each claim | Logos and adjectives instead of real outputs |
Visual | Can I see it? | Supporting each of the three layers above | Arrives first and decorates instead of explaining |
You don't need four separate sections. On a strong homepage, the hero does the analogy and a hint of proof, the how-it-works section does the mechanism and its visual, and the sections below stack more proof. The point is that every layer is present and in the right order. Our deeper guide on website design for complex products shows how those layers translate into layout.
How do you choose the right analogy for a technical product?
Choose an analogy that your buyer already understands, respects and would use themselves. A good analogy borrows a mental model: "Stripe for payroll" tells a founder that payroll can be an API with good docs, in three words. A bad analogy borrows the wrong expectations, such as pricing, quality or a category the buyer dislikes.
Test every candidate against three questions:
- Does the buyer know the reference well? If they need the reference explained, it's not an analogy.
- Does it carry the right expectations? References bring a price point and a reputation with them.
- Does it point to the mechanism? The best analogies hint at how the product works, not just what market it's in.
Analogies work best as a bridge, not as the positioning itself. Use it in the subhead, then move to your own words. The "X for Y" shortcut is the most common format, and it has real costs as you grow. Our guide to analogies in tech copy covers when "it's like X for Y" helps and when it backfires.
How do you explain the mechanism without drowning buyers in detail?
Explain the mechanism in three steps written from the user's side: what they put in, what the product does, and what they get out. Three steps is enough to be specific and short enough to remember. If your product genuinely needs more, group the steps until it doesn't.
The mechanism is where most complex product websites either go silent or go too deep. Silence leaves the visitor with an analogy and no reason to believe it. Depth turns the section into an architecture diagram for the one engineer on the buying committee. Aim for the level a smart friend in a different industry would follow.
Write the input
Name the thing the user brings, in their words: "your support tickets", "your bank feeds", "your Figma file".
Write the transformation
Say what happens to it in one sentence, without naming internal components: "we group them by root cause and draft a fix".
Write the output
Describe what the user gets and where: "a ranked list in Slack every morning".
Add the one technical fact that builds trust
Usually how data is handled, what it integrates with, or what the user controls.
Our guide to diagrams, product visuals and micro-animations shows how to design this section so it explains rather than decorates. If your product has several modules, the mechanism needs to work at two levels: the suite and each module. Our guide to structuring a multi-product site covers that.
What proof makes a complex product believable?
The proof that makes a complex product believable is a real input next to its real output. A buyer who sees an actual support ticket turn into an actual drafted reply believes the mechanism. A buyer who sees "trusted by 500 teams" learns only that other people bought it.
Proof comes in levels, and complex products need the stronger ones:
Proof type | What it shows | Strength for complex products |
|---|---|---|
Logos | Other companies use it | Weak alone: says nothing about how it works |
Testimonials | Someone liked it | Medium if specific about the result |
Input-output examples | The mechanism working on real data | Strong: the visitor sees it, not hears about it |
Interactive demo or sandbox | The visitor tries it themselves | Strongest when the product can be shown safely |
Named limits | What it doesn't do | Builds trust by showing you know the edges |
AI products have a particular proof problem: commentators keep naming "magic promise, no proof" as the pattern on AI sites. Our guide to explaining AI products covers how LLM, agent and ML startups move from "powered by AI" to concrete input-output proof. For examples of companies doing this in public, see our roundup of AI company websites that explain the product in one screen.
Which visuals explain a technical product best?
The visuals that explain a technical product best show the mechanism moving: a before and after, a three-step flow, or an input turning into an output. Abstract illustrations, glowing gradients and stock photos of people at laptops explain nothing, however polished they look.
- Flow diagrams for products that move data between systems.
- Before and after for products that clean, summarize or fix something.
- Layered diagrams for infrastructure that sits between other tools.
- Annotated product UI for products where the interface is the value.
- Short code-built animations for showing a transformation step by step without a heavy video.
We build most of these as lightweight code rather than video, because code animations stay crisp, load quickly and can be edited when the product changes. Video still has a place for walkthroughs and launch pages. Our guide to explainer videos for SaaS covers script structure, length and lighter alternatives that load faster.
How do you write for technical and business buyers on the same page?
Write for technical and business buyers on the same page by layering it: the business story runs down the page in plain language, and the technical depth sits one click away, in expandable sections, tabs or linked docs. Both readers get the full answer they need, and neither has to wade through the other's.
The business buyer reads the analogy, the outcome and the proof. The technical evaluator reads the mechanism, the integration details, security and the docs. A page that serves only one of them either confuses the CFO or loses the CTO. Our guide to selling to technical and non-technical buyers covers the layered pattern in detail, and our messaging framework template helps you write each layer from one source of truth.
What does a complex product homepage look like, section by section?
A complex product homepage follows the same four layers from top to bottom, with each section doing one job. Here's the order we start from, then adapt to the product and buyer.
Section | Layer | Its one job |
|---|---|---|
Hero headline | Outcome | Say the result the buyer gets, in their words |
Hero subhead | Analogy | Place the product in something familiar |
Hero visual | Proof | Show a real output, not an abstract shape |
How it works | Mechanism | Input, transformation, output in three steps |
Use cases | Proof | Show the mechanism on two or three real jobs |
Technical depth | Mechanism | Integrations, security and docs, one click deep |
Customer evidence | Proof | Specific results and named limits |
FAQ and CTA | All | Answer the blocking questions, then ask |
Feature pages follow the same pattern at a smaller scale. Our guide to SaaS feature pages covers writing product pages that sell outcomes, not features. And if the rest of your site is fine and only the homepage confuses people, a homepage-only redesign is often the right-sized fix.
A hypothetical walkthrough: rewriting a data infrastructure homepage
A hypothetical example, for illustration only: a seed-stage startup sells a tool that syncs product usage data into a CRM. The original hero reads "The reverse ETL platform for modern data teams".
Analogy: "Like a data pipeline, but pointed at your sales team." Mechanism: connect your warehouse, pick the fields, and see them in your CRM records. Proof: a screenshot of a CRM record showing a real usage field, with the sync time beside it. Visual: a three-step animated flow from warehouse table to CRM card.
The new headline names the outcome: "Show sales which accounts are actually using the product." The category term moves to the subhead, where data engineers still find it.
How do you test whether your product explanation works?
Test whether your product explanation works by showing the first screen to someone outside your company for a few seconds and asking them to repeat back what the product does. If they can't say who it's for and what it does in one sentence, the explanation isn't working yet, however good the design looks.
Run a first-screen test
Show five people the hero for a few seconds, hide it, and ask what the product does and who it's for.
Ask for the explain-back
Have them describe it as if telling a colleague. Note the words they use; those are often better than yours.
Read sales call notes
List the questions prospects ask in the first five minutes. Each one is a gap the website left open.
Check the forwarded version
Imagine the page forwarded to a CFO with no context. Does the top third still make sense?
Teams that don't have time to do this themselves often hire a specialist writer. Our guide to hiring a SaaS website copywriter covers what to expect and what to ask.
What should you read next in the complex products series?
Read the series in the order of the method: analogy, mechanism, proof and visual, then the two guides on audience and format. Each one stands alone, but together they cover the whole page.
Guide | What it covers |
|---|---|
When "X for Y" helps and when it caps your value | |
Designing a how-it-works section built as code | |
Replacing AI buzzwords with input-output proof | |
The layered page pattern for buying committees | |
Scripts, length, placement and lighter alternatives | |
How the method translates into layout |
