Stay where you are on the page, as much as possible, always. Do the task where the task is. Every extra screen, every link to elsewhere for looking something up is a moment where someone gets lost and stops doing what he came to do.
October 2026
It’s best if the system doesn’t need any additional explanation.
Jakob Nielsen, tenth usability heuristic
If there is one rule I have applied to almost every interface I worked on, it is this one: stay on the page. Do not spread over two or three screens what fits on one. Do not send someone to a help page, an FAQ or a manual to find out how to do the thing in front of them. Put what they need where they need it.
It sounds obvious. It is broken constantly, and almost always for reasons that have to do with how the organisation is built rather than with what the user is doing.
Where help used to live
I started in technical writing, in the years when help was a separate thing. You wrote a manual, then online help, and both lived outside the program. Press F1, and a second window opened over the work, with a table of contents and an index. The user had to leave the task to learn how to do the task, and then find their way back.
The best thinking in that field went the other way. In 1990 John Carroll published The Nurnberg Funnel, the book that gave technical writing the word minimalism: short, task-oriented pieces, as few words as the task needs, and errors treated as moments to teach rather than things to prevent at all cost. The logical end of that idea is that the explanation stops being a separate document at all. It becomes a label, a line under a field, a sentence next to a button. The help moves into the screen.
Usability said the same from the other side. Jakob Nielsen’s tenth heuristic starts by saying it is best if the system needs no extra explanation. His sixth asks that the information needed to use a design be visible or easy to retrieve when it is needed, so that nobody has to remember something from one part of the interface to use it in another.
The back office is where it matters most
Public websites get the attention. The maintenance screens behind them get very little, and that is where people who run those kinds of websites spend whole working days. In 2014 I designed the interface of the back office of a content management system built for the Flemish government. Much of that work was building prototypes, testing them, and taking steps out of the screen flow.
A back office tends to mirror the database. There is a screen for each table, so an editor who wants to publish one page with an image visits four of them: one for the text, one to upload the image, one to attach it, one to publish. Nothing in that sequence is wrong. All of it is in the wrong place. Bring the upload, the attaching and the publishing onto the page being edited, and the same task takes one screen and a fraction of the attention.
The same goes for explanation. A field called Slug needs one line under it saying what a slug is and what happens if you change it. Without that line, the editor goes to look it up, or guesses, and the guess ends up in the address of a page.
When a second screen is right
Staying on the page is a default, not a law. A second screen earns its place when the step is a different task, when it cannot be undone and needs a moment of attention, or when the first screen would become too long to read. What it should not be is a way of sparing the designer a decision about what belongs together.
Here is the test I use.
Before you add a screen, a link or a help page
- Ask whether it can happen here. If the step uses the same object the person is already looking at, it belongs on this page.
- Put the explanation next to the thing it explains. One line under a field beats a paragraph on a help page nobody opens.
- Explain consequences before the action. What happens when you press the button should be readable before you press it, not afterwards on another page.
- Keep a second screen for a second task. Or for a step that cannot be undone and deserves a pause of its own.
- Bring the answer back from the FAQ. Every question asked about a page is a line that page is missing.
- Count the screens for one real task. Do the most common job from start to finish and count. If the number surprises you, it will surprise the user too.
Read the originals
- John M. Carroll, The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill (MIT Press, 1990). The book behind minimalism in technical writing.
- Jakob Nielsen, 10 Usability Heuristics for User Interface Design (1994, revised since). Six and ten, side by side, are this note in two lines.
- Wikipedia, Minimalism (technical communication). A short way into Carroll’s ideas, and into the IBM guidelines that came before them.
- Sarah Richards, FAQs: why we don’t have them (Government Digital Service, 2013). What happens to help when it is moved off the page.