Brand style
guide development
in Amsterdam

Many public bodies in the Netherlands write for taalniveau B1. So do a growing number of companies. B1 is the plain language level that most adults can read without strain. A brand guideline for the Dutch market should name that target directly. It should not leave writers guessing at how plain is plain enough. A support letter, a product manual and a website footer are judged by the same expectation. Copy that misses it reads as careless, not formal.

Sentence length is the first lever. Short does not mean childish. It means one idea per sentence, with the subject near the front and the verb close behind it. A guideline can set a working range, say eight to fifteen words for most sentences. Allow longer ones only when a list or a condition needs the extra clause. Tell writers to split rather than trim. Cutting words from a long sentence often just makes it dense. Splitting it into two keeps the meaning intact.

Word choice matters as much as length. B1 copy favours the common, everyday Dutch word over the formal one, even when the formal word is technically correct. A guideline should give writers a short list of swaps, not a general instruction to write simply. General instructions get ignored under deadline. A swap list gives writers something concrete to check a draft against, rather than a mood to aim for.

Before and after examples do more work than any rule stated in the abstract. A guideline should carry a small set of real sentences pulled from the kind of copy the company actually produces: a product description, a support reply, a line from a contract summary. Each pair should show the original next to the rewrite. A short note should explain what changed. That way a writer learns why the rewrite works, and can apply the same fix to a fresh sentence later.

Examples should cover different kinds of text, not marketing lines alone. A support macro, a checkout error and a paragraph from a terms page each fail B1 in a different way. A set drawn only from headlines will not prepare a writer for the harder cases. Include at least one technical sentence rewritten without losing the fact it needs to convey. That is usually where a writer gives up and falls back on the original wording.

English loanwords deserve their own short section. Dutch business writing borrows freely from English for product and technology terms. A guideline has to decide, term by term, whether to keep the English word, translate it, or offer both on first use. Words with a Dutch equivalent that readers actually use should be translated. Words where the English term is the only one anyone recognises, common among software feature names, should stay in English rather than force an awkward coinage nobody outside the company would use.

Once a decision is made for a term, record it in one place. A short glossary of loanwords, with the agreed Dutch form or the decision to keep the English word, saves more editing time than any rule about tone. It also stops a term from drifting. A feature described one way on the website and another way in a help article reads as two different products to a reader who never saw the internal debate.

A final point on register. B1 in Dutch does not mean stripping out every technical term a reader might not know on sight. It means explaining the term the first time it appears, in the same sentence or the one after. A guideline that treats plain language as a ban on specific words, instead of a discipline of explanation, pushes writers toward vague copy that says less while reading no more clearly.

A brand guideline can stop at the logo and the colour palette. That leaves the words inside buttons, menus and error messages to whoever writes the code that day. Interface microcopy carries brand voice too. Often more of it, since a reader sees a button label far more times than any piece of marketing copy. Treat this text as its own category. Give it a short rulebook, not an afterthought for developers to fill in.

Button and link labels are a good place to start. They are short enough to standardise fully. Set a rule for verb tense: an instruction, not a description. A label should read Save changes, not Changes saved. Add a rule for capitalisation too. List words to avoid, such as vague labels like Submit or Click here that tell a reader nothing about the result of the action. Consistency matters more than cleverness in any single label.

Error messages deserve more space than one rule can give them. A bad error message costs a reader real time and trust. Ask for three things in every error: what happened, in plain terms; why it matters, if that is not obvious; and what to do next. Set a tone rule for this category. Tone that works in a marketing headline often reads as flippant when someone has just lost their form data.

Empty states are the screens a reader sees before any content exists. They are easy to skip during design. Easy to leave generic too, in the copy pass. Every empty state should answer one question: what should the reader do right now. A blank inbox, a search with no results, and a dashboard with no data yet each need a different answer. One generic line, such as Nothing here yet, fails all three.

Confirmation and warning dialogs are the highest-stakes microcopy in most products. They usually appear right before an action that is hard to undo. Name the action in the button itself. Not behind a generic Yes or OK. A reader under time pressure should never have to guess which button does what. Delete this file reads clearly. OK does not.

Length limits belong in the guideline as ranges tied to the interface element, not one number for all copy. A tooltip and a full error explanation have different jobs. And different space. A rule that treats them the same will either cramp the tooltip or leave the error too thin to help. Give a rough word count per element. Add a real example at that length too, so a writer can judge a draft against something concrete.

Finally, name who owns this text once the product ships. Interface copy drifts as developers patch small issues under deadline, swapping a word here or there without checking the rulebook. A short review step helps. Even a quick pass before each release. This keeps the microcopy aligned with the rest of the brand voice, instead of slowly drifting away from it.

A company with more than one product, or a product with more than one named feature, runs into a specific writing problem. How should those names behave inside an ordinary sentence. Left without a rule, one writer capitalises a feature name every time. Another treats it as a common noun. A third invents a shorthand nobody else uses. A short, checkable rule set settles this better than individual judgement.

First mention is the natural place to set the rule. Specify how a name appears the first time it shows up: full name, a short description if needed, and the short form to use afterward. After that, keep using the short form. Do not switch between the full name and a paraphrase for variety.

Plural and possessive forms of a proper name cause more damage than they seem to deserve. Adding an s to make a name plural, or attaching a possessive to describe something that belongs to it, often produces a form that reads as a typo. Sometimes it reads as a different product entirely. Give writers an approved way around each case. Rewrite the sentence so the name stays singular. Describe ownership with a phrase such as the settings menu of the product, rather than a form that bolts a letter s directly onto the name.

Generic descriptors are the safety valve for both problems. When a sentence would otherwise repeat a proper name three times in two lines, or would need an awkward plural, use a generic stand-in instead: the tool, the app, the dashboard, the feature. This only works if the generic term is unambiguous in context. Check first. If more than one named thing could match the generic word in that paragraph, go back to the proper name.

Capitalisation rules need to cover more than the obvious cases. Decide this early. State whether feature names are capitalised only as a full proper noun, or also when shortened to one word. Also decide whether category words near the name, such as plan or tier, are capitalised when they follow it. Without a clear answer, teams over-capitalise out of caution. Running text then starts to look like a list of headings, not a sentence.

Names that double as everyday words are the hardest case. A feature named after a common verb or object reads naturally until a reader cannot tell whether the word is doing its normal job or naming the feature. The fix is usually simple. Pair that name with its category noun on first mention, in every document. Ambiguity never builds up that way.

Finally, keep a short table of every current product and feature name, its approved short form, its plural handling, and one example sentence for each. New writers check this table before publishing. Update it the same day any product is renamed. An outdated table causes more confusion than no table at all.

A brand guideline that only shows a component in a static image gives a developer half of what is needed. The picture shows one state: a button or a card as it normally looks. It says nothing about hover, click, or an empty version with no content to fill it. Written documentation must close that gap. It should read as prose a developer can follow without asking a designer to explain the picture again.

Describe each interface state as its own short paragraph. Name each one clearly: default, hover, active, disabled, and error where that applies. For each state, note what changes, in words a developer can check against the code without measuring pixels: colour, weight, spacing, and timing for any transition. One sentence per state is often enough. It prevents most of the back and forth that happens after a component ships slightly wrong.

Naming conventions for components deserve a fixed vocabulary, agreed once and reused everywhere. Call it a card in one place and a tile in another, and trouble follows. A developer building a library of reusable parts ends up with two components doing the same job under different names. A short list of approved component names avoids this. Keep it beside the visual reference. No separate tool needed.

Spacing and sizing rules read better as plain rules than as a table of raw numbers alone, though the numbers still belong in the document. State that a card keeps a fixed amount of internal padding, whatever text it holds, and give the number alongside that rule. The reason matters too. It tells a developer what to build, and why, so a shortcut taken under deadline is less likely to break the rule unnoticed.

Accessibility notes belong inside the same component entry, not a separate document a developer might never open. Keep it short. A line on required contrast. A line on whether a state needs more than colour to read. A line on what a screen reader should announce. This keeps the requirement next to the visual reference, instead of sitting unread in a policy document.

Version notes matter once a component changes after launch. Record what changed and when, next to each component, in one line. Not a full changelog. A developer maintaining an older part of a product then knows whether the component in front of them matches the current rule, or predates a change not yet rolled out everywhere.

None of this replaces a proper design file or a component library in code. It sits between the two. Readable without design software open. Specific enough that two developers building the same component from the same entry produce the same result. That middle layer is often the piece missing from a guideline that otherwise looks complete.