User Interface Text

This chapters is mainly for the George Copywriting & Communications (CopyComm) team and focusses on the wording of the actual George interface.
There will be constant updates on this.

After some general rules, there will be guidelines for various George components (in alphabetical order).

10 General Rules

• I = George, You = User. We = the bank (but try to avoid the “We”). Never mix it up. (Exception: legal checkboxes where “I = User”: in this case use quotation marks)
• Use full sentences whenever you can but not for labels, buttons, menu item.
• Use active voice as it keeps the user in the driver’s seat.
• George speaks British English. In local languages, he has no dialect and is fit in grammar.
• If applicable in your local language, always address all genders.
• Don’t shout at users. Avoid CAPITALS or exclamation marks!
• When addressing the user by name, use the full name (first name & family name e.g. “Marie Weber”), don’t use titles.
• Avoid technical terms and standard phrases.
• Consistency, consistency, consistency (Web/App and within one channel)
• Keep it short, simple, and, most of all, friendly.

Bullet Points / Unordered Lists

• minimum of 2 points (if you have only 1 bullet point, it is not a list)
• no punctuation except if you list full sentences
• either full sentences or catchwords, no mix-up
• sentence case (i.e. first letter capitalised)

Buttons

Labels of a button (also known as Call to Action or CTA) should be as short and clear as possible, and should describe the action the button performs. Be precise and avoid misunderstanding under any circumstances.

• Use a maximum of 3 words.
• Avoid articles (only here, nowhere else! 😉).
• Don’t use punctuation at the end, especially no exclamation marks!
• Buttons are written in sentence case, i.e., only the first word and proper nouns are capitalised.
• Don’t use URLs (if the CTA links to one).
• Don’t use words like “click” or “press”.
• Don’t use CAPS (except first letter, of course).
• Check the consistency across George (e.g. don’t use “Confirm” for an action that is called “Sign” everywhere else in George.
• Avoid personal pronouns.
• If radio buttons answer a Yes/No question, use “Yes” and “No”, followed by a verb, e.g. “Yes, block card” and “No, cancel”.
• Don’t use counts, pluralisation, or placeholders.

Capitalisation

Title case

In title case, every word is capitalised except conjunctions, articles, and prepostions. In title case, both parts of compound nouns are capitalised, except the second word is a participle modifying the first word (e.g.: Take off, How-to …).
Title case is used for the main navigation, the side navigation, page titles, modal menus, headlines, titles, and stepper titles.

Sentence case
In sentence case, every word is written in lowercase, except proper nouns. Sentence case is used for all running text, labels, sub-headlines, and buttons.

Checkboxes

• Write full sentences.
• If in a legal checkbox the first person does not mean George but the customer, use quotation marks to avoid a mixup with I = George. If possible add the name as a placeholder to clarify: ” “I, Marie Weber, agree … ” “.
• List options in a logical order.

Confirmations

For confirmations, “OK” is used. The spelling has to be consistent, therefore variations like “O.K.”, “O.k.”, “o.k.”, “okay” etc. are not used.

Error Messages

Errors happen. Apologise for them but don’t be defensive. Be transparent, don’t lie and focus on actions that the user can do to fix the problem.

• Use full sentences in active voice only.
• Write it like you explain it to a friend.
• Start with a “I’m sorry.” But don’t repeat it. This should be the only text in the headline.
• Let an explanation of the error follow in the description.
• Be specific.
• Write in human, understandable language, avoid technical terms under any circumstances.
• No blame game
• Generic errror messages shall be avoided whenever possible. An explanation of the error / issue should be given in the description.

Empty State Messages

Empty State Messages are used if no data or information is available. The empty state message shall always explain the use of the respective feature. Generic messages shall not be used.

Instructional Texts

When writing instructions for users (often the first sentence at the top of a page), try to be as brief yet as helpful as possible. Explain the feature but don’t go into details as the functionality should be self-explanatory.

The tonality can vary: For something serious or even legally relevant (e.g. tax transfers or GDPR settings) you should use a sober and fact-bound tone, whereas “fun features” such as a wallpaper plugin or picture uploads can be explained in a witty and charming way.

• Use full sentences.
• Minimum of 2 lines, try to limit to a maximum of 4 lines.
• No use of bold but maybe a linebreak
• Don’t just repeat the headline or menu items.
• Don’t be redundant.
• Stop writing the obvious.

Menu Items

Menu items navigate the user. Nothing has to be clearer, simpler, shorter and more consistent than menu items. That can make them tricky.

• Reduce them to 1 or 2 words.
• Avoid verbs, use nouns.
• Do not use special English versions.
• Ensure consistency. Do not change existing menu items without checking side effects and consulting product owners and/or designers.
• Don’t use punctuation.

Modals, Dialog, Popups

In modals, George enters a kind of direct conversation with the user. Therefore, be as friendly, helpful and colloquial as possible. Guide the user step by step through the process and avoid technical and/or bankish terms.
Modals usually consist of a headline, explanatory text, (optional: entry fields, selectors or checkboxes), call to actions.

• Use full sentences.
• Explain what’s going on and what this is for.
• Be direct. And address the user personally: “You can …“. Use active voice only. No exceptions.
• If you ask questions, reduce the offered answers to 2 options, ideally “yes” or “no”.
• Don’t be redundant.

Placeholders

Avoid them. In 90 % of the cases, they are redundant. So even if there is a key for it, make it empty on purpose. Use them only if you can give important and valuable additional information on how to enter a field. Do not repeat the label.
With selectors (aka drop downs), write “Please select”

Proper Nouns & Categories:

• Proper nouns are written in title case.
• Proper nouns name specific one-of-a-kind items.
• Categories are treated as proper nouns and therefore the inital letters are capitalised.
• If two categories appear in one line, they are conencted by ”&” instead of “and”.

Titles

• Titles are written in title case, i.e., every word is capitalised, except minor words (articles, short prepositions, conjunctions).
• If the title consists of “Thank you” only, it is spelled in sentence case and ends with a full stop.
  Thank you.
• Full stops are not used in titles
  Exception: If the title is a full sentence, it is written in sentence case and ends with a full stop or question mark.

Success Messages

Success messages inform the user about an action or process having been completed. The tonality of the messages should be positive and informative. Avoid exuberant and redundant messages. A too gushy tonality contradicts the desired impression of easy and accessible banking.

Validation Messages

Validation messages inform the user that data, he entered is not accepted, i.e. wrong formats, wrong characters, too many / too few characters etc. The tonality of validation messages should be positive and solution-oriented. An apology can be added, but is not necessary.