By Mehdi HassanHow do you design a how it works section for a technical product?
You design a how it works section for a technical product by explaining the mechanism in three steps written from the user's point of view, then giving each step a visual that shows something changing. The section answers the question every visitor has after reading the hero: "Fine, but how does it actually do that?"
It's the mechanism layer in our method for explaining complex products, which runs analogy, mechanism, proof, visual. The hub guide on how to explain a complex product on your website covers the full sequence. Here we focus on the section itself: which visual pattern to choose, how to write the steps and how to build the visuals so they help instead of slowing the page down.
Which product explainer visuals work best?
The product explainer visuals that work best show the product's effect, not its architecture. Choose the pattern that matches what your product actually does to the user's data, work or day.
Visual pattern | Best for | What it shows | Watch out for |
|---|---|---|---|
Numbered flow | Products that move data or work between steps | A path from input to output | Too many steps, arrows everywhere |
Before and after | Products that clean, fix or summarize | The same thing, improved | Fake or idealized before states |
Layered diagram | Infrastructure between other tools | Where the product sits in the stack | Turning into an architecture slide |
Input to output pair | AI and generation products | A real input next to its real result | Cherry-picked examples |
Annotated UI | Products where the interface is the value | Real screens with callouts | Screens too small to read |
Interactive toggle | Products with modes or options | The visitor switching between cases | Hiding the main story behind a click |
Most pages need one primary pattern, not several. If your product is an AI tool, the input-output pair usually leads, as we explain in our guide to explaining AI products. If it's a data pipeline, the numbered flow does.
How many steps should a how it works section have?
A how it works section should usually have three steps: input, transformation and output. Three is enough to be specific and few enough to remember. Four can work when there's a genuine setup step, such as connecting an integration. Beyond that, the section becomes a tutorial.
If your product truly has more steps, group them. "Connect, configure, map fields, test, deploy" becomes "Connect your data, choose what to sync, see it in your CRM". The detail can live in docs or a linked product tour. Our guide to interactive demos and product tours covers when a deeper walkthrough is worth adding.
Why build how-it-works visuals as code instead of video?
Build how-it-works visuals as code because code animations are sharp at any size, load fast, stay accessible and can be edited when the product changes. A video of the same diagram is a heavy file that blurs on large screens, can't be read by search engines or assistive technology, and needs re-exporting for every copy change.
Pros
- Small file size compared with video, so the page stays fast
- Text stays real text: readable, translatable and indexable
- Crisp on every screen size and resolution
- Easy to update when a feature or label changes
- Can react to scroll position and respect reduced-motion settings
Cons
- Needs a designer and developer who can work together
- Complex sequences take longer to build than to film
- Not suited to showing long, real product sessions
- Can tempt teams to add motion that doesn't explain anything
We build most of these in SVG and CSS, or with a light animation library in Next.js, and keep video for real product walkthroughs. Our comparison of GIF, video, Lottie or code for animated product demos covers the trade-offs format by format.
How should explainer animation behave on a marketing page?
Explainer animation should play once, in step with the reading, and make sense when it's paused. Its job is to show the change between steps, not to keep the eye busy. Motion that loops forever or plays before the visitor reaches the section adds noise.
- Trigger on view. Start each step's animation when it scrolls into view, not on page load.
- Keep it short. Each step's motion should finish quickly enough that the visitor never waits for it.
- Respect reduced motion. Honor the prefers-reduced-motion setting by showing the final state without movement.
- Design the end frame first. If the static end state doesn't explain the step, the animation won't either.
- Animate only what changes. Move the data, the status or the result. Leave the rest still.
Our guide to motion design for marketing websites goes deeper on when animation helps and when it hurts conversion.
How do you write the copy for each step?
Write each step as a short title with a verb the user performs, plus one sentence on the result. The title says what happens; the sentence says why it matters. Avoid internal component names unless your buyer uses them too.
Start with the user's verb
Connect, upload, ask, approve. The user should be the subject of every step title.
Name the visible result
Follow each title with what the user sees: a list, a draft, an alert, a dashboard.
Add one trust detail
Under the step where it matters, add the line technical buyers look for: data stays in your region, nothing is sent without approval.
Read it without the visuals
Cover the diagrams and read the three steps aloud. If they explain the product, the visuals will strengthen them. If not, rewrite before designing.
For example, suppose a security tool designs its how-it-works section
Hypothetical example: a startup scans code repositories for leaked secrets. The first draft reads "Agentless scanning engine with real-time detection and remediation workflows" over a stack diagram.
The rewrite has three steps. "Connect your GitHub org" shows a repository list appearing. "We scan every commit" shows a line of code with a highlighted API key. "Fix it from Slack" shows an alert card with a one-click revoke button. Each visual is an SVG animation that plays once as it scrolls into view. Under step one sits a trust line: read-only access, nothing stored. This example is illustrative.
Where does the how it works section go on the page?
The how it works section usually goes right after the hero, or right after a short block of problem framing. The hero makes a promise; this section explains how the promise is kept, so it should arrive while the visitor is still asking that question.
On a SaaS homepage, a common order is hero, how it works, use cases, proof, technical depth, FAQ and CTA. Our section-by-section SaaS homepage guide covers the full order, and our guide to hero section design covers the screen that sets this section up. Questions the steps raise but don't answer, such as setup time or data handling, belong in an FAQ further down.
