In a product's content style guide, why do many teams choose sentence case over title case for interface text?
answer
- one rule versus many
- which words count as minor
- reads like natural speech
- proper nouns stand out
- consistency beats the choice itself
basics
~20 sSentence case has one simple rule, so it does not drift between writers; it reads like natural speech and lets proper nouns stand out. Title case is a valid choice too - what matters most is applying one convention everywhere.
solid answer
~40 sIn sentence case only the first word and proper nouns are capitalised - 'Run payroll for this month'; in title case the major words are - 'Run Payroll for This Month'. Title case needs rules about which words are minor (articles, short prepositions, conjunctions), and different writers resolve them differently, so a product with many writers drifts. Sentence case has one rule anyone can apply. It also reads more like ordinary speech, which suits a conversational voice, and it keeps proper nouns and named features visibly distinct from ordinary words. Title case is not wrong - some platform guidelines prefer it for certain elements - but mixing the two across screens is. The style guide should pick one, list which elements it covers and keep a list of proper nouns.
go deeper
Know the difference between sentence case and title case, and apply the style guide's rule, including its proper-noun list, to every label you write.
Explain why sentence case drifts less than title case, why capitals should signal proper nouns rather than importance, and when title case is a defensible exception.
Show how you would audit a product for mixed capitalisation, write element-by-element rules and add a string check so engineers' strings follow them.
Weigh a single cross-platform capitalisation rule against following each platform's own conventions, and decide which exceptions the system will carry.
## The two conventions A **content style guide** is the reference that fixes how a product's interface text is written - capitalisation, punctuation, numbers, terminology and common message patterns. One of its first decisions is capitalisation. | Convention | Rule | Example in a payroll product | |---|---|---| | Sentence case | Capitalise the first word and proper nouns only | Run payroll for this month | | Title case | Capitalise major words; leave minor words lower case | Run Payroll for This Month | | All capitals | Capitalise every letter | RUN PAYROLL FOR THIS MONTH | Both sentence case and title case are used by serious products. The choice matters less than applying it consistently, but there are reasons sentence case has become a common default for interface text. ## Why sentence case is a common default - **One rule, no judgement.** Title case requires deciding which words are 'minor': articles, short prepositions, conjunctions. Is 'with' minor? Is 'into'? Is 'Is'? Writers answer differently, so title-case products drift. Sentence case leaves nothing to decide except proper nouns. - **It reads like speech.** Most interface text is short instructions and labels. Sentence case reads like a person talking, which suits a plain, conversational voice. - **Proper nouns stand out.** When only names are capitalised, a capital carries information. In a payroll product, 'Year-End Pack' can signal a named feature while 'year-end report' is an ordinary description. - **Easier reuse.** A string written in sentence case can move from a heading to a sentence without being rewritten. - **Scanning.** Long title-case labels create a row of capitals that is slightly harder to scan, especially in menus and tables with many items. ## When title case is reasonable Title case is not an error. Some platform guidelines prefer it for particular elements, such as menu items or window titles, and a product that wants to feel native on that platform may follow them. Some brands use title case for a small number of display headings. What the style guide must avoid is ambiguity: every element type should have one rule, and the rule should be written down. Consistency within a surface matters most. A user moving between a web dashboard and a mobile app notices a difference in convention far less than a user who meets 'Add Employee' and 'Add a benefit' side by side on one screen. If the product follows different platform conventions, the difference should fall along platform lines, never inside one screen. ## Writing the rule into the style guide A capitalisation section usually covers: 1. **The default** - for example, sentence case for all interface text: buttons, headings, labels, menu items, table headers, tooltips. 2. **Exceptions by element**, if any, with the reason - for example, a platform convention the product follows. 3. **A proper-noun list** - product names, named features, partner names - so writers do not have to guess which terms get capitals. 4. **Acronyms and abbreviations** - keep acronyms in capitals, spell them out on first use where users may not know them. 5. **All capitals** - reserved, if used at all, for very short labels such as a small status tag; never for sentences or long labels, where it is harder to read and reads as shouting. ## Common mistakes - **Mixing conventions** - 'Add Employee', 'Add a benefit' and 'ADD DEDUCTION' on neighbouring screens, which makes the product feel assembled from parts. - **Capitalising for importance** - writing 'Gross Pay' or 'Tax Code' with capitals to make ordinary terms look official; it makes proper nouns and ordinary words indistinguishable. - **Capitalising after a colon or in the middle of a sentence** for no reason. - **Forgetting system-generated text** - error strings and notifications written by engineers often escape the rule. ## Checking it Capitalisation is one of the easiest rules to check automatically. A string review can flag labels with several capitalised words that are not on the proper-noun list, and a quick audit of all button and heading strings shows how far the product has drifted. Fixing case across a product is cheap compared with most copy changes, which makes it a good first win when a team starts a style guide. It is also a quick test of whether the guide is being read at all.
- How should a sentence-case style guide treat named features such as a 'Year-End Pack'?Decide explicitly and keep a list. If the feature is a true proper noun - a branded name users will search for - capitalise it everywhere; if it is just a description, keep it lower case. The list stops writers guessing, and it keeps capitals meaningful: in sentence case, a capital should signal a name, not importance.
- A native app team wants title case because their platform's guidelines use it for menus; is that a problem?Not necessarily. Following a platform convention for specific elements is a defensible choice, as long as the style guide records it as an exception by element and platform, with the reason. What harms users is unexplained mixing within one surface, not a documented rule that differs by platform.
saying these in an interview costs you the question
- Title case is always wrong for interface text.
- Capitalising a term makes it clearer or more important.
- Mixing capitalisation styles across teams has no effect on users.
- All capitals is a good way to make long labels or messages stand out.
- Every payroll concept deserves capitals, such as 'Gross Pay', to look official.