Publisher Document Setup Why?

[bt1138]

A small request:

Why is Document Setup under the File menu and not the Document menu? 

Every time I access it, I ask why why why is Document setup not under the Document menu? Please move it there - just look at the words -> Document -> Document. yes. put it there. Why is there a document menu if document setup is somewhere else?

Is it a file or a document? Is a document not a file? If it's not a file, what is a document? Don't hate me, you're the ones who do the things where the words you use don't add up and we can't find things.

It's the little design things that drive us crazy.

 

[Ali]

There is no Document menu in Designer - I would argue for its removal in Publisher so that everything is under File, as it is in Designer, for consistency.

However, document setup is quicker to access from the toolbar in both apps.

[Pyanepsion]

The Document menu is traditionally intended, where it exists, for editorial or contextual actions. It includes:
—options related to content, such as sections, pages, styles and navigation;
—commands that affect the logical or narrative structure of the document;
—and, in some cases, tools specific to page layout.

→ This menu operates on what the document contains, not on its ‘container’ (page size, resolution, etc.).

The File menu, by contrast, is traditionally used for:
—operations that apply to the document as a whole, such as opening, saving, exporting or printing;
—global settings for the file, such as page format, margins, units of measurement, colour profiles or resolution.

→ These elements concern the physical structure of the file, which is why they are grouped under File, as it relates to the digital container of the document.

As Ali rightly pointed out, there is also the Document Setup button, which is quite handy, as well as the Preferences button in both Affinity Publisher and Affinity Designer.
This does not apply to Affinity Photo, since we are not dealing with a document, but with a working canvas.

 

[bbrother]

With all due respect @Pyanepsion to this opinion, it is worth noting that dividing the functionality of the Document menu solely into "content operations" (e.g. pages, objects) while excluding "container settings" (page size, margins, bleeds, etc.) is an artificial limitation that finds no justification in either the logic of the interface or the user's expectations.

 

🔍 The user does not think in terms of container and content

• For the user, the document is one coherent whole.
• The mental model of how the interface works says: "I want to change something in the document", not: "does this function concern the content or the frame (container)".
• In this logic, both Add Page and Document Setup, Margins or Facing Pages are simply functions on the document.

 

🧂 Artificial consistency between apps hurts UX
It's understandable to strive for consistency between apps in a suite, but:

• Affinity Designer doesn't have a Document tab → Document Setup goes to File out of necessity.
• Affinity Publisher has Document — and that's where Document Setup logically and functionally fits in.

👉 Putting it under File just to “make it consistent with Designer” is like keeping milk in the spice drawer because that’s what they did in the neighboring kitchen. Sounds coherent. But no one will thank you when they want to make coffee.

 

🔧 Bottom line:

• Consistency can't mean duplicating mismatched solutions. A better form of consistency is consistent logic that works in each app in its own context.
• Document Setup should be where the user naturally expects it—in the Document menu, if it exists. Simple layout, more intuitive, less frustration.

 

[carl123]

3 hours ago, bbrother said:

Document Setup should be where the user naturally expects it—in the Document menu, if it exists.

If we have Document setup under two different top-level menus that would mean users would have to remember where to quickly find Document setup depending on which app they are using or which (Publisher) persona they are in. 

Therefore, from a UI design perspective and (more so) a user experience perspective, the Devs likely decided to keep Document setup under the File menu, in all the apps, so users don’t have to guess/remember where to find it based on the app/persona they are in.

In saying that, if Designer did have a Document menu, I would agree that Document setup could have been in that menu but from a UX perspective from someone that is constantly switching between apps I prefer to have it in a location that is consistent in all the apps.

So, in the case of the Affinity apps I think the Devs were right not to conform to the "norm", where we would have had the Document setup option in the Document menu in Publisher and in the File menu in Designer. That to me would not be a good user experience.

 

[fde101]

2 hours ago, Pyanepsion said:

This does not apply to Affinity Photo, since we are not dealing with a document, but with a working canvas.

This is not correct.  Photo is still document-based, but simply lacks the tools to create artboards or pages past the first.  Photo creates single-page documents on its own, but if Designer is used to create artboards or Publisher is used to create a multi-page document, those documents are ultimately native Photo documents that it can still work with if they are opened in Photo.

Consider that Photo has a "New Document" window, a "Document" menu, etc.

[Pyanepsion]

Thank you, @bbrother, for your response, which usefully clarifies the debate.

We probably all agree on one essential point: user experience must take precedence. But that must be grounded in coherent logic, not in a superficial convenience of terminology.

That a menu is labelled Document does not mean that everything related to the document must be placed there.

Let me offer a concrete analogy: if you give someone a packet of sweets, no one would think to eat the wrapper simply because it, too, bears the word “sweets”. The distinction between what is consumed and what contains it is obvious — and it is just as obvious here.

There is nothing artificial, then, in distinguishing:

• what relates to editorial content (pages, sections, styles), → which rightly belongs under Document;

• and what concerns the physical or digital properties of the file (page size, margins, resolution), → which naturally belongs under File.

This structuring is anything but arbitrary: it has long been adopted by most software, especially in word processing and publishing (Adobe, Scribus, Microsoft, Jutoh, Soft-Logic…), because it promotes a clear, intelligible and sustainable interface.

Affinity’s suite has nothing to gain by departing from these proven standards. And much to lose by clouding the interface in the name of a personal sense of consistency.

[Alfred]

25 minutes ago, Pyanepsion said:

 

Off topic, “Mi-Cho-Ko” doesn’t work well in English as a name for sweets!

[HCl]

.

[Pyanepsion]

17 minutes ago, Alfred said:

Off topic, “Mi-Cho-Ko” doesn’t work well in English as a name for sweets!

One must always instruct with the right tools.
75% soft caramel, 25% cocoa. 😊

[bbrother]

4 hours ago, Pyanepsion said:

That a menu is labelled Document does not mean that everything related to the document must be placed there.

 

🧠 User intuition comes first

Users don’t study interface documentation to decide where something should be. They follow names and context. If something relates to a document and there’s a “Document” menu — they’ll **click there**.

This isn’t about “terminology convenience” — it’s a cognitive shortcut that:

• reduces decision time,
• lowers mental friction,
• speeds up action.

As Steve Krug put it: “Don’t make me think.” The interface should be intuitive enough that users don’t stop to ask: “Do margins count as content or container?” They don’t think in those terms — they just want to change the document. That’s it.

 

🗂️ Local logic vs. unification

From the perspective of modern UX standards, the approach I’m proposing better aligns with human-centered design.

Interface design should adapt to the user’s intuition — not the other way around. What improves UX in one app may not make sense in another. Since Publisher has a “Document” menu and Designer does not, placing “Document Setup” under “Document” in Publisher is simply local logic done right.

This isn’t a breach of consistency or standard — it’s an intelligent, user-first adaptation.

 

♻️ Flexible consistency: the golden standard

Modern UX embraces flexible consistency — consistency that is context-aware and adaptive:

• Interfaces shouldn’t be blindly mirrored across apps,
• Instead, they should be designed to make sense to humans in their specific context.

Local logic takes priority when it:

• enhances intuitiveness,
• simplifies decision-making,
• shortens the path to completing a task.

That’s what real consistency looks like — not cloned menus, but a consistent principle: “Go where the context leads you.”

Because consistency only adds value when it supports intuition. When it suppresses it — it becomes an obstacle.

[carl123]

12 minutes ago, bbrother said:

Since Publisher has a “Document” menu and Designer does not, placing “Document Setup” under “Document” in Publisher is simply local logic done right.

Well, since Publisher has a "Document" menu should we also have the document save, document export & document print commands in that menu?

Isn't that what you are advocating when you say local logic done right?

 

[Pyanepsion]

@BBrother, we cannot follow you down that path.

The distinction is clear, necessary and universal — even on digital game distribution platforms.

Manufacturers who ignore it sooner or later adopt it… or vanish.

Is that what you want, @BBrother?

Here, have a banana split.
And don’t worry — I haven’t confused the wrapper (the peel) with the content. 😊

[Alfred]

8 minutes ago, Pyanepsion said:

Here, have a banana split.

Some of us would put on weight just from looking at that!

[bbrother]

2 hours ago, carl123 said:

Well, since Publisher has a "Document" menu should we also have the document save, document export & document print commands in that menu?

Isn't that what you are advocating when you say local logic done right?

 

🧠 User-first logic: clarity before taxonomy

Let’s drop the semantics and focus on human behavior.

When users see a “Document” menu and want to change their document’s layout, margins, or size — they’ll intuitively look there. Not under “File.” Not because they’ve read UI documentation, but because humans follow naming and context.

This isn’t just about interface tidiness — it’s about cognitive flow. As Steve Krug famously said: “Don’t make me think.”

Users aren’t pondering the structural taxonomy of content vs container. They just want to adjust the document — and go where the label takes them. That’s why placing “Document Setup” under “Document” (when such a menu exists) reduces mental load and shortens the decision path.

That’s not confusion. That’s good UX.

 

🗂️ False equivalence: Save ≠ Setup

You argue that if we follow the logic i propose, Save/Export/Print should also move under “Document.”

That’s a flawed comparison.

Those functions are almost universally anchored in the “File” menu — for decades now — and are part of long-standing mental models. They belong there because users expect them there.

“Document Setup,” on the other hand, is about changing a document’s core structure. And if a “Document” menu exists, that’s exactly where users will try first. Hiding it under “File” simply adds unnecessary friction.

Let’s not confuse long-term convention with forced categorization.

 

1 hour ago, Pyanepsion said:

Here, have a banana split.
And don’t worry — I haven’t confused the wrapper (the peel) with the content.

 

🍌 Bananas and interfaces

Thanks for the banana split. I’ll try not to slip.

No — I’m not confusing the peel with the fruit. I’m simply saying that users don’t dissect bananas before eating them. They don’t debate whether margins are content or container.

They follow what makes sense in front of them.

In UI terms: if there’s a “Document” menu, they expect document settings there. It’s not “confusing the wrapper” — it’s following intuition. And good design should meet that intuition, not resist it.

 

♻️ Flexible consistency beats rigid duplication (once again)

• Modern UX design celebrates context-aware consistency — not UI duplication at all costs. What works in one app might feel clunky in another.
• Affinity Publisher has a “Document” menu. Designer does not. Forcing identical menu structures despite that difference reduces clarity, not enhances it.
• Consistency is useful only when it supports human logic. When it overrides it — it becomes an obstacle.

 

🧩 Alternative: Rename “Document” to “Pages”

Now, here’s a compromise worth considering.

If the current “Document” menu mostly contains page-level actions — like Add Page, Go to Page, View Masters — then renaming it to “Pages” would make its purpose crystal-clear.

In this case, keeping “Document Setup” under “File” becomes more acceptable — because there’s no longer a competing “Document” label to mislead the user. It even aligns better with Affinity Designer, which doesn’t have a “Document” menu either.

This move would:

• Remove ambiguity from the UI
• Improve discoverability
• Maintain cross-app consistency without sacrificing clarity

It’s not about chasing purity — it’s about serving the user.

 

Just to clarify — I work closely with UX/UI designers on a regular basis. While my main focus is backend development (PHP is my home turf), I started out on the front end — HTML, CSS, JS, visual design — so I’ve always approached interface logic with a practical, user-centered mindset.

This isn’t theoretical for me. I’ve seen firsthand how even small changes in menu logic can either streamline the experience — or slow users down. So when I say that local logic matters, I mean it quite literally: it impacts people’s time, decisions, and overall flow.

[Pyanepsion]

@bbrother — thank you for your detailed replies. Let’s now take a moment to clarify a few essential points, for the benefit of everyone following this discussion.

1. Steve Krug, an American based in Chestnut Hill, does not advocate following labels at the expense of logic. Quite the opposite.

His well-known principle — “Don’t make me think” — means:
“Design so clearly that the user never has to wonder.”
It does not mean: “Place functions wherever the wording feels familiar.”

What Krug (as well as Norman, Tidwell, Cooper…) consistently defend is this:

Quote

User intuition is built through repeated exposure to clear, predictable structures.

A good interface does not maintain ambiguity — it resolves it.

 

2. The “Setup” menu acts on the container, not on the editorial structure.

Changing a document’s size, margins, resolution or units affects the file itself, not its content.
→ That is precisely why its logical place is under File, alongside other global settings.

Adding the label “of the document” is entirely appropriate, as it clarifies the scope of the command.
→ But it certainly does not justify a change of menu.

 

3. The “Document” menu is aptly named — but not everything containing the word “document” belongs in it.

This menu is dedicated to editorial actions: adding pages, managing styles, navigating through sections…
It is therefore perfectly legitimate and functionally sound.

But that does not mean every command mentioning the word document must be placed there.
→ “Document Setup” modifies the container, not the editorial structure — which is why it rightly belongs under File.

It is not the menu label that causes confusion, but an overly literal interpretation of it.

 

In summary:

Coherence, clarity and predictability remain the foundations of sound interface design — not lexical proximity.

And that is precisely why, @BBrother, so many professional tools — and so many users — do not follow your reasoning.
→ And have not done so for nearly half a century.

You are now defending the opposite of your own arguments, simply to avoid acknowledging the obvious.
And evidently, you did not grasp the reference to the packet of sweets, nor the one about the banana peel — though both were perfectly clear.
This is no longer a discussion — it’s a loop.
Perhaps it’s time to consult the sources — the real ones — rather than argue from impressions.

 

[bbrother]

Thank you for your summary, @Pyanepsion. Let me respond point by point — no metaphors, no packaging jokes — just UX, in its clean, practical form.

 

“Coherence, clarity and predictability remain the foundations of sound interface design — not lexical proximity.”

Sounds great. But in reality, it’s language and context that guide the user toward their goal. When they see “Document”, they’re not dissecting taxonomy like container vs content — they click it, because they want to change the document. That’s not lexical laziness — it’s a designed cognitive shortcut, supporting intuition and reducing decision time. In UX, language doesn’t conflict with logic — it drives it.

 

“And that is precisely why, @BBrother, so many professional tools — and so many users — do not follow your reasoning. → And have not done so for nearly half a century.”

UX is not a heritage museum. It evolves with users, technology and context. Quoting a fifty-year lineage of menu structures doesn’t validate anything — it simply proves that some tools are still clinging to habits born before human-centered design existed. Today’s UX doesn’t preserve what’s old — it improves what’s useful. Affinity Publisher has a “Document” menu. Therefore, users expect to find document settings inside it. That’s not confusion — it’s behavioral design.

 

“You are now defending the opposite of your own arguments, simply to avoid acknowledging the obvious.”

Absolutely not. I’ve been consistent from the start: functions should be placed where the user naturally expects to find them. If “Document Setup” adjusts aspects of a document — and a “Document” menu exists — that’s where it belongs. If the menu doesn’t exist, as in Designer, then “File” is a reasonable home. Simple. Contextual. Consistent — with human cognition, not legacy data hierarchies.

And speaking of consistency…

I even proposed a clear alternative: rename the “Document” menu to “Pages”, since most of its contents focus on page-related actions. That removes ambiguity. When users see “Pages”, they understand it’s about pagination — and “Document Setup” can reside under “File” without contradiction, just as it does in Designer. That’s true consistency: not duplication, but adaptation to context, serving clarity above replication.

 

“And evidently, you did not grasp the reference to the packet of sweets, nor the one about the banana peel — though both were perfectly clear.”

Bananas are tasty, sure — but they’re not an interface design model. And while metaphors can be helpful, they shouldn’t replace testing, behavioral observation or actual UX logic.

Yes, I used one too — the misplaced milk analogy. But mine wasn’t decorative or whimsical. It was a functional metaphor, grounded in how users actually behave when searching for something they expect in a logical place.

So let’s be clear: I don't argue with fruit metaphors. I argue with any design approach that makes the user stop, think, and wonder if they’re in the wrong menu — instead of simply acting.

Because good UX doesn’t entertain. It works.

 

“This is no longer a discussion — it’s a loop.”

No — it’s still a discussion. It turns into a loop only when arguments run dry and theoretical positioning replaces practical empathy. UX isn't closed by declarations — it’s guided by observation, adaptation and iteration.

 

UX isn’t about preserving system purity. It’s about designing for human cognitive maps. Your map leads to the file.

Mine — to the human.

And one more thing: The best UI is the one the user doesn’t notice.

If users have to stop, ask themselves where a setting might be, and question whether margins are “container or content” — they notice. And when they notice, the design has failed.

And let’s be honest — the structure you're defending leads exactly to that moment. It invites users to second-guess themselves, navigate across mismatched menus, and debate internal logic instead of simply working. It’s a cognitive detour disguised as interface clarity.

That’s not clarity. That’s friction, dressed as structure.

[Oufti]

1 hour ago, bbrother said:

If users have to stop, ask themselves where a setting might be, and question whether margins are “container or content” — they notice.

When I need to define margins or document size, I always look first in the File menu for the command above the Print command, and it's like that since 35 years in each Mac application I've used. Usually it's named Page Setup (Format d'impression), in Affinity Designer and Pblisher it's named Document Setup but it's on the same place and it does the same, even if with some more options than most apps — that's all. 

My User eXperience says that if I've always found what I'm looking for at one place (for example salt and pepper must be close to the cooking stove) I'll first look there, and I'd be very surprized if somewhere else it wasn't there! 

 

[bbrother]

Thanks for sharing your view @Oufti — and I get it. Habits built over 35 years can feel like second nature. But in UX, familiarity doesn’t always equal optimality.

Your metaphor — salt and pepper by the stove — perfectly illustrates habitual placement, not contextual logic. If we redesign a kitchen so the spices live in a dedicated drawer called “Flavour”, would it confuse people? Maybe — but if it’s clearer, faster and used consistently across the entire kitchen, it becomes the new standard.

That’s exactly what we’re discussing here. Affinity Publisher has a “Document” menu. That menu isn’t decorative — it's part of the interface hierarchy. When a user wants to set up a document — size, margins, bleed — it's only natural they look in “Document”, not “File”. Why? Because their goal isn’t about files. It’s about the thing they’re working on: the document.

The fact that legacy apps placed “Page Setup” in “File” doesn’t mean it’s the right choice today. UX has evolved. Modern interfaces prioritize cognitive flow over legacy conventions. The original poster was confused. That confusion isn’t invalidated by your personal routine — it confirms a mismatch between expectation and placement. And that’s a UX problem.

So while your experience is valid, it’s one lens. UX doesn’t design for memory muscle — it designs for task efficiency, semantic clarity and cognitive intuition.

If menus like “Document” exist, they should hold document-related actions. If we respect context, not habit, users stop asking why something isn’t where they expect — and simply do what they came to do.

That’s not novelty. That’s good UX.

[Old Bruce]

52 minutes ago, bbrother said:

Affinity Publisher has a “Document” menu. Therefore, users expect to find document settings inside it. That’s not confusion — it’s behavioral design.

Following that sort of logic up to reductio ad absurdum: Publisher has a Layer menu. I cannot use it to change the blend mode or opacity of a Layer. It has a Text menu, I cannot set the size of the text to a particular point size, also I cannot set the leading to a particular size let alone change the font family itself.

The reason is that there are limits as to what can be displayed in a Menu. 

I do agree that perhaps the Document menu should be changed to Pages so as to avoid this sort of discussion/confusion.

And finally I will admit that I understand UI but remain convinced that UX is a boondoggle.

[bbrother]

3 hours ago, Old Bruce said:

Following that sort of logic up to reductio ad absurdum: Publisher has a Layer menu. I cannot use it to change the blend mode or opacity of a Layer. It has a Text menu, I cannot set the size of the text to a particular point size, also I cannot set the leading to a particular size let alone change the font family itself.

The reason is that there are limits as to what can be displayed in a Menu. 

 

Let’s be precise — because your analogy doesn’t just miss the mark, it misrepresents the entire structure of the interface.

You're comparing the “Document” menu — a top-level, structural command hub — to contextual panels and toolbars designed for real-time property adjustments. That’s like confusing the building’s blueprint with the light switch. Font size, leading, blend modes — these belong in toolbars and panels because they’re dynamic, localized, and frequently changed. No one expects them in the main menu bar.

But “Document Setup” is not a contextual tweak — it’s a structural configuration. It opens a dialog that defines the document’s core properties: margins, bleed, units, page size. That’s exactly the kind of function that belongs in a top-level menu — and if a “Document” menu exists, that’s the most intuitive place for it.

Saying “menus can’t hold everything” is a distraction. No one’s asking them to. We’re talking about a single, high-level function — and placing it where the user naturally expects it.

Dismissing UX as a “boondoggle” doesn’t make you sound bold — it makes you sound out of touch. UX isn’t decoration. It’s the scaffolding that holds usable software together. It’s the reason people don’t throw the app out the window — and the reason they come back to it the next day. Ignore it if you want — just don’t expect users to stick around while you figure out why they’re leaving.

I’ll let the thread speak for itself. My position is clear. I’ll leave it here and let others take from it what they will.

[Oufti]

My point was not only about habits but more on the logic behind these.

In my opinion if salt and pepper deserve to be placed in evidence close to the stove, it's because that's where I mostly need it, especially when I'm in a hurry. (If I'm preparing cold dishes on a side counter, I can make a step or two to fetch them but when I'm stirring a preparation that is about to be overcooked, I don't want to.) 

The same is true for Document setup: most of the time, when I need to set page size or margins, resolution,… it's when I'm creating a new document or when I want to print, save as or export it: all operations grouped in the File menu. That's why I expect to find there the related commands. 
(And if the Document menu was renamed Pages, there wouldn't be anymore reason to expect to find the Document setup in this menu.) 

[Pyanepsion]

@bbrother,
When professionals describe their actual workflow, and you respond with theories that are clearly AI-generated (we could even name which one)… the masquerade becomes obvious.
End of discussion.

[bbrother]

56 minutes ago, Pyanepsion said:

When professionals describe their actual workflow, and you respond with theories that are clearly AI-generated (we could even name which one)… the masquerade becomes obvious.
End of discussion.

 

“End of discussion”? That’s not how discussions work. You don’t get to declare them over just because you’ve run out of arguments. This isn’t a courtroom, and you’re not the judge. If your only closing move is to dismiss a well-reasoned position with a vague “AI” accusation and a mic drop — that’s not confidence. That’s retreat dressed as authority.

Let me be crystal clear: No, my statements were not generated by AI. Every word, every analogy, every argument — that’s me. My experience, my reasoning, my voice. If it sounds structured and coherent, that’s not because a machine wrote it. It’s because I’ve spent years thinking critically, working with real users, and learning from real design teams. I don’t need AI to sound intelligent. And apparently, that’s enough to make some people uncomfortable.

So if you’re done, fine. But don’t pretend you’ve “exposed” anything because you haven't. You've simply run out of counterarguments..

The discussion doesn’t end because you say so. It ends when the arguments stop landing. And judging by your exit line, mine are still standing.

[Oufti]

8 hours ago, bbrother said:

I’ll let the thread speak for itself. My position is clear. I’ll leave it here and let others take from it what they will.

… 🙄