# Writing style guide

*Category:* Getting started
*Section:* Guidelines
*Source:* https://uikit.developers.rio.cloud/#/start/guidelines/writing
*Captured:* 2026-04-27T14:57:06.810Z

UX writing doesn't receive as much attention as it should. In the past, digital experiences featured words written by different individuals - ranging from designers to engineers — at various times and in diverse styles, all without a centralized guide.

## Writing style guide

Consequently, the language sometimes proves to be confusing, lacking consistency from one screen to another, and occasionally feels robotic or overly enthusiastic when a more conversational tone is needed.

A good understanding of UX writing plays a pivotal role in creating better digital experiences. If the language within your product is intricate, uninspiring, or unfriendly, it’s likely that users will perceive your product in the same way — complex, uninspiring, and unfriendly.

Sources:

This guide is heavily inspired by the following guides:

- Microsoft Writing Style Guide
- Intuit content design
- Google’s content design
- Adobe Spectrum

## Here's what you will find in the RIO’s writing style guide

- Voice and tone
- Write like you speak Project friendliness with contractions Get to the point fast Be brief Addressing the user clearly Active and passive voice Focus your message
- Capitalization
- Title case vs. sentence case Sentence case rules When in doubt, don’t capitalize Use ALL CAPS only when you should
- Punctuation
- Skip periods and unnecessary punctuation Skip colons in headings Use exclamation points sparingly Remember the last comma
- UI elements
- Buttons Links Forms Input placeholder Form labels and placeholders Dialogs Error states Notifications
- Error messages
- Errors in general Avoid showing a message whenever possible Have the system automatically resolve errors Use plain language, and avoid jargon
- Commonly misspelled or misformatted words

- Write like you speak
- Project friendliness with contractions
- Get to the point fast
- Be brief
- Addressing the user clearly
- Active and passive voice
- Focus your message

- Title case vs. sentence case
- Sentence case rules
- When in doubt, don’t capitalize
- Use ALL CAPS only when you should

- Skip periods and unnecessary punctuation
- Skip colons in headings
- Use exclamation points sparingly
- Remember the last comma

- Buttons
- Links
- Forms
- Input placeholder
- Form labels and placeholders
- Dialogs
- Error states
- Notifications

- Errors in general
- Avoid showing a message whenever possible
- Have the system automatically resolve errors
- Use plain language, and avoid jargon

## Voice and tone

In the same way that products should maintain a consistent look and behavior, they should also maintain a consistent style of communication. Maintain a unified voice while adjusting the tone to suit the specific context of the situation.

In general, try to be

- Clear and understandable
- Friendly, honest, and responsible
- Concise and simple

## Write like you speak

Write like you speak

Read your text aloud. Does it sound like something a real person would say? Be friendly and conversational. No. Robot. Words.

Example

> You need an ID that looks like this: "someone@example.com"

> Invalid ID

> Turn on location service

> Enable location service

> Preparing video…

> Buffering…

> This command isn't supported on your phone

> This command is only supported on dual-core devices

## Project friendliness with contractions

Project friendliness with contractions

Use contractions: it’s, you’ll, you’re, we’re, let’s To sound more conversational and natural. Use commonly understood contractions to keep sentences from feeling out-of-touch, robotic, or overly formal.

However, sometimes "do not" can give more emphasis than "don't” when caution is needed.

- Avoid contracting nouns with is, does, has, or was. This might make it look like the noun is possessive.
- Be mindful of how many contractions you use in a sentence. Too many contractions can make things difficult to read.
- Avoid using contractions when dealing with legal concerns, payment processing, and account security. Casual isn’t always the best style when handling sensitive information.

Example

> To help you avoid traffic, remember anniversaries, and in general do more, RIO needs to know what you’re interested in, what’s on your calendar, and who you’re doing things with. The business is closed

> To help you avoid traffic, remember anniversaries, and in general do more, RIO needs to know what you are interested in, what is on your calendar, and who you are doing things with. The business's closed

## Get to the point fast

Get to the point fast

Lead with what’s most important. Front-load keywords for scanning. Make customer choices and next steps obvious.

Example

> Save time by creating a document template that includes the styles, formats, and page layouts you use most often. Then use the template whenever you create a new document.

> Templates provide a starting point for creating new documents. A template can include the styles, formats, and page layouts you use frequently. Consider creating a template if you often use the same page layout and style for documents.

## Be brief

Be brief

Give customers just enough information to make decisions confidently. Prune every excess word.

Example

> Create a chart that's just right for your data by using the Recommended Charts command on the Insert tab.

> The Recommended Charts command on the Insert tab recommends charts that are likely to represent your data well. Use the command when you want to visually present data, and you're not sure how to do it.

> Read the instructions that came with your device.

> Consult the documentation that came with your device for further instructions.

## Addressing users clearly

Addressing users clearly

When addressing the user directly, it's important to use the second person pronouns 'you' or 'your'' rather than 'my' or 'I.' This choice of words, utilizing 'you,' creates trust and mutual understanding, whereas 'my' can potentially cause confusion among our users. I is also helping the user to feel like the UI is talking to them and referring to their actions.

Don’t combine first and second person. Avoid mixing 'me' or 'my' with 'you' or 'your.'

An exception to this rule are found in agreements or acknowledgments. For example, “I agree to the terms of service.”

Example

> Profile and settings Lorem ipsum dolor sit amet consectetur adipisicing elit. Aliquam velit commodi sunt nostrum nisi? Voluptas eos dolorum error amet esse. Fugit consequatur obcaecati deleniti! Corrupti praesentium molestiae voluptate a rem.

> My profile & settings Lorem ipsum dolor sit amet consectetur adipisicing elit. Aliquam velit commodi sunt nostrum nisi? Voluptas eos dolorum error amet esse. Fugit consequatur obcaecati deleniti! Corrupti praesentium molestiae voluptate a rem.

> You seem to be offline Your data isn't available. Try checking your internet connection.

> Offline Data not available

## Active and passive voice

Active and passive voice

Use active voice in most cases and use passive voice sparingly.

- With active voice, sentences are simpler, shorter, clearer, and more conversational.
- With passive voice, you can soften and provide distance in select situations (e.g., notification of a disabled account).

Active voice means the subject of the sentence performs the action. With passive voice, the subject receives the action. For avoiding passive voice it often helps to rephrase a message and center it around the object or the actions that someone could undertake.

Using present tense and an active voice shortens and simplifies our sentences. Past and future tenses, along with passive voice, make our users read more words to convey the same message. Additionally, the active voice ensures we take responsibility for our actions.

One exception is when you want to specifically emphasize the action over the subject. In some cases, this is fine: Your account was flagged by our Abuse team.

Example

> John Doe resolved your comment Your payment has been declined Something went wrong

> Your comment was resolved by John Doe We declined your payment An error happened

> Quickly categorize your transactions The team conducted usability tests with customers We couldn’t save your changes. Try again in a moment. Changes saved 34 invoices sent

> Your transactions can quickly be categorized Usability tests were conducted with customers Your changes weren’t saved The system saved your changes You sent 34 invoices

> Message sent

> Message has been sent

## Focus your message

Focus your message

Create a hierarchy of information. Lead with the main point or the most important content, in sentences, paragraphs, sections, and pages.

Example

> To remove a photo from this album, drag it to the trash.

> Drag a photo to the trash to remove it from this album.

## Capitalization

## Title case vs. sentence case

Title case vs. sentence case

In most products and websites today, there are two ways to capitalize words:

- Title case: Capitalize every word. This Is Title Case.
- Sentence case: Capitalize the first word. This is sentence case.

Even though title case looks more formal, serious and provides symmetry especially on buttons or short headlines, it is also harder to implement. Many rules and exceptions behind it are sometimes not easy to understand or to grasp.

Sentence case on the other hand is much easier to read especially when the text gets long. It is also easier to define and easier to explain to designers and engineers. No rules for what to capitalize and what no. Sentence case also looks more friendly and casual. It feels more natural and approachable.

A more detailed comparison between the two cases can be found at: https://www.everyinteraction.com/articles/title-case-vs-sentence-case-in-ui/

## Sentence case rules

Sentence case rules

Use sentence case, even in headings and titles, labels and buttons.

Sentence case is friendly. It helps support the approachable RIO style and brand personality. It also makes translation a bit easier.

Sentence case tends to be easier to read and comprehend, especially when CTA labels are more than three words. Also, breadcrumb labels in sentence case are easier to scan.

Sentence case improves consistency. In an environment of many independent teams, it’s a lot easier to implement the sentence case.

Proper nouns, Products, and branded terms may also be capitalized.

Example

> Create new partner Company name of the partner Cancel Add partner

> Create New Partner Company Name of the Partner Cancel Add Partner

> Order date Transport type Total weight Total volume Dangerous goods Lorem ipsum 1 Kg

> Order Date Transport Type Total Weight Total Volume Dangerous Goods Lorem ipsum 1 Kg

## When in doubt, don’t capitalize

When in doubt, don’t capitalize

Default to sentence-style capitalization. Capitalize only the first word of a heading or phrase and any proper nouns or names. Never Use Title Capitalization (Like This).

Example

> Find a RIO partner New RIO customer Limited-time offer Join us online

> Find a RIO Partner New RIO Customer Limited-Time Offer Join Us Online

A proper noun is a specific name used for an individual person, place, organization, or sometimes thing, which is always capitalized in English. Proper nouns differ from common nouns, which are general names for a class of objects or concepts.

Examples of proper nouns include:

- People: "John Smith," "Marie Curie"
- Places: "New York," "Mount Everest," "The Nile River"
- Organizations: "Microsoft," "United Nations"
- Titles: "The Great Gatsby," "Time Magazine"

In contrast, examples of common nouns include:

- People: "man," "woman"
- Places: "city," "mountain," "river"
- Organizations: "company," "club"
- Titles: "book," "magazine"

## Use ALL CAPS only when you should

Use ALL CAPS only when you should

Avoid using ALL CAPITAL LETTERS. It’s like screaming, and it may present additional difficulty for reading longer texts. We occasionally display all capital letters in headings on marketing pages, badges (such as NEW, PLUS, or FREE), or navigation labels but of these uses are exceptions.

There are capitalization exceptions on some marketing pages. To attract new customers and encourage action, marketers might capitalize the word free or some catch phrases. Research proves that the capitals are effective for conversion, but the promotional tone of the capital letters is out of place in the in-product conversation.

## Punctuation

## Skip periods and unnecessary punctuation (" : ! ?")

Skip periods and unnecessary punctuation (" : ! ?")

Skip end punctuation on titles, headings, subheads, UI titles, and items in a list that are three or fewer words. Save the periods for paragraphs and body text. This helps readers scan text more easily.

- Labels
- Single sentence tooltip text
- Bulleted lists
- Dialog headlines and single sentence dialog body

- Multiple sentences
- Long or complex sentences, if it suits the context
- Any sentence followed by a link. Links themselves should not be full sentences.

Example

> Move a tile 1. Press and hold the tile.

> Move a tile. 1. Press and hold the tile.

## Skip colons in headings

Skip colons in headings

For headings on lists of items, do not use colons. For lists within body text, use a colon.

## Use exclamation points sparingly

Use exclamation points sparingly

Exclamation points can come across as shouting or overly friendly.

Example

> Congratulations! You created your first connection

> No contracts! Save a contract and it’ll appear here

Exclamation marks can be used to emphasize celebratory momentsAvoid using exclamation marks for empty states and common tasks. Save it for bigger accomplishments

## Remember the last comma

Remember the last comma

In a list of three or more items, include a comma before the conjunction. Don't use it followed by an ampersand. The comma that comes before the conjunction is known as the Oxford or serial comma.

Example

> Android, iOS, and Windows

> Android, iOS and Windows

## UI elements

## Buttons

Buttons

Button texts should always include verbs. Keep things clear and concise, and use sentence case. It’s OK to use an ampersand in button text.

Pair action verbs with nouns. Is the user saving details, downloading an invoice, or editing an order? Pairing tells the user exactly what will happen.

**In general, follow these guidelines**

- Use chevron icons (left and right) to indicate directions
- Use the plus and delete icons for creation and deletion respectively
- Explain what’s going to happen next
- Be concise

Example

> Back Remove component Add new vehicle

> Back Remove Add New Vehicle

**Explain what’s going to happen next**

Ambiguous button labels, such as yes/no, submit/cancel, or abort/continue provide minimal information to the user. This requires the user to read the dialog text in order to complete the task, making them prone to misinterpretation and adding extra effort for users.

Example

> Edit order? Are you sure you want to edit this existing order? Never mind Edit order

> Edit order? Are you sure you want to edit this existing order? Cancel Edit

Consider this: If you remove all the text around your buttons, could the user still accomplish the task? If not, change your button labels. Use words that motivate immediate action.

**Don’t cancel the cancellation**

When you have buttons for actions that could cause problems, like deleting something or stopping a service, it's important to make sure people understand what the buttons do.

For example, if one button says confirm and another says cancel, it might not be clear which one actually cancels the action. This can lead to people making mistakes.

To help users, always use clear words on buttons that tell them exactly what will happen when they click them.

If you use the same words on the buttons as you do in the title or header, it makes everything easier to understand and encourages users to take the right action. This way, you avoid confusing labels like confirm/cancel. Also, if you use a word like 'keep' on the second button, it makes it really easy for users to not accidentally cancel something.

Example

> Cancel your order? Keep order Cancel order

> Cancel your order? Cancel Confirm

Source: https://medium.com/sainsburys-customer-experience/a-quick-guide-to-writing-better-button-labels-69daecff3497

**Don’t truncate button text**

Avoid truncating button text, as it can confuse users about the buttons intention.

Strive for concise button text, and consider using labels if needed.

If your buttons have longer text that doesn't fit due to limited space, stack them to ensure clarity, especially in narrow containers with multiple buttons.

Example

> Save & continue Submit application

> Save and continue editing Submit application for review

> Update profile information Generate & download PDF

> Update profile information Generate report and download PDF

## Forms

Forms

**General form guidelines**

Please follow these rules when implementing and designing form in your service

- Mark optional or required fields. Add the "* Fields are required" legend.
- Group the label and the respective form element and separate them visually from other form elements
- Use placeholders to provide users a hint to avoid input mistakes
- In case explain what you want the data for

**When to validate**

- Validate on submit and re-validate on change
- Validate on blur
- Don’t validate on first input click and avoid showing errors immediately when the user starts typing
- If realtime validation is needed, use a debounce mechanism to delay validation until the user pauses typing for a short period (e.g., 300-500 milliseconds). This reduces the number of validations and prevents overwhelming the user.
- For input length validation, display a character counter instead of an error message
- Use default values or limit options, no validation is needed
- Disable the submit button, if possible, to avoid errors when using multiple required fields
- Never rely on a red input border alone in case of an error

By using techniques like debouncing, on-blur validation, and friendly error messages, you can provide a balanced and user-friendly validation experience.

Example

> Name Email address Password Phone number (optional) In case we need to call you for further details

> Name* Email address* Password* Phone number

In case there is only one or just a few optional fields, rather mark the optional fields than marking all other fields required.

> First name* Last name* Date of birth We want to give you a special treat on your birthday Country Comments * Fields are required

> First name* Last name* Date of birth Country Comments

When using the * character to mark required fields, please add the explanation for the user even though it is common to use.

## Input placeholder

Input placeholder

Placeholder text for form inputs generally should not contain a trailing "..." (ellipsis). The purpose of a placeholder is to provide a short hint to the user about what to enter in the field, and adding an ellipsis can create unnecessary visual clutter and may be confusing.

**Best practices for placeholder text**

- Clear and concise Keep placeholder text short and to the point. Long placeholder text gets cropped making it inaccessible. Use longer text as help text instead.
- Descriptive Ensure the placeholder text clearly describes the expected input
- Avoid ellipses Do not use trailing ellipses for placeholders in inputs, for inputs with autocomplete, selects, or dropdowns. Ellipsis are typically used to indicate truncation or continuation, which is not the purpose of placeholder text. It can create ambiguity and doesn't provide clear guidance on what to enter.

**Examples of good placeholder text**

- "Search by name"
- "Search for products"
- "Search in table"
- "Find a vehicle by name"
- "Add comment"
- "New message"
- "Enter keywords (e.g., documentation, examples)"

Example

> Password Your password must include 1 lowercase letter and 1 uppercase letter as well as a special character

> Password

## Form labels and placeholders

Form labels and placeholders

When designing forms, it is crucial to use labels and placeholders effectively to ensure a clear and user-friendly experience.

**Differentiating labels and placeholders**

- Avoid redundancy Using both a label and a placeholder with the same value is redundant and unhelpful. Each element serves a distinct purpose.
- Label usage Labels should clearly describe the input field's purpose. They are persistent and help users understand what information is required, even after they begin typing.
- Placeholder usage Placeholders should provide an example of the expected input format, not a call-to-action (CTA). For example, use "example@mail.com" for an email input field.
- Special cases for placeholders In most cases, search fields can use a placeholder with CTA text instead of a label. This approach simplifies the form and enhances usability. It can also be applied to other input fields where a label would be unnecessary and would complicate the design, such as message inputs, comment sections, and chat windows.
- Appropriate styling Form labels should not be styled as headlines. Headline styles are generally too prominent and can distract from the form's usability. Labels should be clear and readable, ensuring they complement the form design without overwhelming it. Headlines should be used for an entire form or a form section to provide clear grouping and structure. For more detailed grouping within a form, you may use the <fieldset> element with a <legend> to create a clearly defined section, which helps users understand the organization and purpose of different parts of the form. This approach enhances readability and navigability, making the form more user-friendly.

Form labels should not be styled as headlines. Headline styles are generally too prominent and can distract from the form's usability. Labels should be clear and readable, ensuring they complement the form design without overwhelming it.

Headlines should be used for an entire form or a form section to provide clear grouping and structure. For more detailed grouping within a form, you may use the <fieldset> element with a <legend> to create a clearly defined section, which helps users understand the organization and purpose of different parts of the form. This approach enhances readability and navigability, making the form more user-friendly.

Example

> Email* Form section using fieldset Lorem ipsum

> Name Email* Search features

## Dialogs

Dialogs

Avoid presenting users with unclear choices. “Cancel” doesn't make sense here because no clear action is proposed.

Example

> Not part of your order The selected item is not part of you order and cannot be assigned Ok

> Not part of your order The selected item is not part of you order and cannot be assigned Cancel Ok

## Error states

Error states

Always use the header and the description of a state when using components like ErrorState, NotFoundState, EmptyState, or any other state.

Leaving out the message and using the headline for the user action feels like shouting to the user.

Example

> You have no vehicle selected Please select a single vehicle from the list of your vehicles on the left hand side of your screen

> Please select exactly one vehicle

## Notifications

Notifications

This guide outlines the best practices for crafting notification messages. The aim is to ensure consistency, clarity, and brevity across all notification messages.

**General notification guideline**

Naming the subject first in notifications is a common and effective best practice. Here’s why this approach is beneficial:

1. Clarity It immediately informs the user about what the notification is regarding. This is particularly useful when multiple notifications are displayed at once or when users are multitasking.
2. Consistency Maintaining a consistent structure helps users quickly understand the nature of the notification. If the subject is always mentioned first, users will become accustomed to scanning for that information first.
3. Prioritization In notifications where users might need to take action or understand the context quickly, presenting the subject first allows them to prioritize their attention effectively.
4. Readability It can improve readability and user experience by clearly separating the notification's subject from its outcome or details.

**Considerations**

- Keep the message consistent in structure across different contexts
- Use a period at the end of the message only if part of a full sentence in a larger context but omit it in standalone notifications.
- Keep the message short and to the point
- The tone should be professional and neutral
- Use simple and straightforward language. Don’t use technical terms that may not be familiar to all users.
- Don’t use exclamation marks (e.g., "Address copied to clipboard!")

- Name copied to clipboard
- Tour published successfully
- Appointment created successfully
- Failed to create the appointment
- The file could not be uploaded
- Your changes could not be saved

Example

> Your request has been submitted Data load error Something went wrong while loading your data. Please refresh the page. Invalid input Please check your email address and try again Appointment not scheduled There’s a conflict with your calendar. Please choose a different time. New feature: Order tracking You can now easily track your orders directly from your account. Check it out today! Account review completed Your account details are up to date. No further action is required.

> Completed successfully The form has been submitted Error JSON parse error: Unexpected token < in JSON at position 0 Invalid Input was incorrect Error The appointment wasn’t scheduled because of a conflict with your calendar. Scheduling failed. We’ve added a new feature that lets you track your orders more easily. Try it out today and see how it can improve your experience! Account info: Your account details were recently reviewed, and everything seems to be in order. There’s nothing you need to do at this time.

**Usage guide for notifications**

A comprehensive guide to using default, info, success, warning, and error notifications effectively.

Neutral or low-priority updates that don’t fit into other categories.

- Best for: General feedback or updates, non-urgent information, or messages without special emphasis.
- Examples: "Your report is being generated" "This feature is in beta"

- "Your report is being generated"
- "This feature is in beta"

Provide actionable or helpful information to the user.

- Best for: Announcements, tips, or non-urgent details users should know.
- Examples: "A new version of the app is available" "This vehicle has no position data" "Pro tip: Use filters to narrow your search results."

- "A new version of the app is available"
- "This vehicle has no position data"
- "Pro tip: Use filters to narrow your search results."

Celebrate or confirm that an action was successfully completed.

- Best for: Positive feedback for completed tasks or goals.
- Examples: "Your profile has been updated successfully" "Your message has been sent" "Payment processed successfully"

- "Your profile has been updated successfully"
- "Your message has been sent"
- "Payment processed successfully"

Alert users about potential risks or actions they should take to avoid issues.

- Best for: Situations requiring user action to prevent problems or risks.
- Examples: "Your password will expire soon. Update it now." "Your account is approaching its storage limit" "Some items in your cart are no longer available"

- "Your password will expire soon. Update it now."
- "Your account is approaching its storage limit"
- "Some items in your cart are no longer available"

Notify users of problems or issues that require immediate attention.

- Best for: Failed actions, critical issues, or situations blocking progress.
- Examples: "Failed to save changes. Please try again." "Unable to process your payment" "Something went wrong. Contact support for assistance."

- "Failed to save changes. Please try again."
- "Unable to process your payment"
- "Something went wrong. Contact support for assistance."

**"Copy to clipboard" notification guidelines**

All success notifications for clipboard actions should follow this structure: "<Item> copied to clipboard"

- <Item>: The specific content that has been copied (e.g., Address, Coordinates, Link, Name)
- copied to clipboard: A fixed phrase that confirms the action and its result
- Omit the close button as this message should be shown with the default timeout and disappear automatically

- Address copied to clipboard
- Coordinates copied to clipboard
- Name copied to clipboard
- Text copied to clipboard

Example

> Coordinates copied to clipboard

> 48.11293, 11.53486 Copied to clipboard.

## Error messages

## Errors in general

Errors in general

Errors can cause frustration, confusion, a loss of data, or more work for the user. These moments make it harder for them to finish their task.

No matter the design component or the length of the message, the most thorough error messages consist of three clear communication elements

- What happened
- The underlying cause (if possible)
- How to fix it

What happened

The underlying cause

How to fix it

Example

Your request could not be savedWhat happenedThere was an error in connecting to the server, so this request was not added to the list of support requests.The underlying causePlease wait a few seconds and try saving the request again. If the problem continues, please let our support team know.How to fix it or to become unblocked

## Avoid showing a message whenever possible

Avoid showing a message whenever possible

The best error message is no error happening at all.

Find ways to avoid the error altogether, like by using in-line validation, visual cues, and disabled states to guide users.

Example

> Description (required) Submit

> Description (required) Description required Submit

Utilize the "disabled" feature of elements to show that users need to do something before they can move onDon't create unnecessary error messages as a workaround to unintuitive design

## Have the system automatically resolve errors

Have the system automatically resolve errors

Avoid using error messages as the first solution. Instead, design things so that the user interface doesn't need to show errors or ask users to fix problems whenever you can.

For instance, if a user types "101" into a field that should only allow numbers up to 100, like percentages, the system should automatically change the value to 100.

Example

> Input that auto-corrects %

> Input that allows invalid data Invalid input. Please enter a maximum of 100% %

## Use plain language, and avoid jargon

Use plain language, and avoid jargon

Your Users may not understand "server architecture" or "client-side queries". Know your audience, and write your error messages in plain, usable language so that your user will understand what went wrong and how it’s being resolved.

Technical terms are different than jargon. If you’re confident that your audience would be readily familiar with technical terms, and if such terms are relevant to the message, you can include them.

Example

> We had trouble processing your request because the server's pathway to the data was slow. We're working to fix it.

> Your request encountered a server-side bottleneck due to inefficient API endpoint routing

More information the error message topic can be found here: https://spectrum.adobe.com/page/writing-for-errors

## Commonly misspelled or misformatted words

## List of commonly misspelled words

List of commonly misspelled words

There are quite a few words that are commonly written incorrectly or inconsistently in software and UI texts. Here are some frequent ones

- Login vs. log in ✅ Correct: Log in (verb) / Login (noun, adjective) ❌ Incorrect: Login to your account (should be Log in to your account)
- Sign up vs. signup ✅ Correct: Sign up (verb) / Signup (noun, adjective) ❌ Incorrect: Create a sign up (should be Create a signup)
- Log out vs. logout ✅ Correct: Log out (verb) / Logout (noun, adjective) ❌ Incorrect: Please logout (should be Please log out)
- Cancel vs. abort ✅ Preferred: Cancel (stop an action before it completes, more user friendly) ✅ Correct but technical: Abort (To forcefully stop a process. Used in more technical contexts, like system failures - e.g., "Process aborted due to an error") ❌ Incorrect in general UI: Abort (too harsh for standard user actions)
- Email vs. e-mail ✅ Correct: Email (correct and widely used in software, more modern, should be capitalized at the start of a sentence) ✅ Correct within copy: email (standard when it's in the middle of a sentence, as it's a common noun, e.g., "Please enter your email address.") ❌ Incorrect: E-mail (technically correct but outdated)
- Email vs. e-mail in German context 🇩🇪 ✅ Correct in German UI: E-Mail (official and correct) ❌ Incorrect: Email (while gaining popularity, "Email" is still considered incorrect in formal German writing) ❌ Incorrect: email without capitalization in German ✅ Correct: E-Mail-Adresse (official and correct) ❌ Incorrect: Email-Adresse without capitalization in German
- Username vs. user name ✅ Correct: Username ❌ Incorrect: User name (though some older UIs still use this)
- Last name vs. surname 🟢 Preferred: Last name (even in en-GB UI) ✅ Formal: Surname (less common in UI, more in official documents) ❌ Incorrect: Lastname (should be two words: Last name)
- Last name vs. surname in German context 🇩🇪 🟢 German UI: Nachname ✅ Official forms: Familienname (but avoid in casual UI)
- Ok vs. okay ✅ Correct: OK (most common in UI) ❌ Incorrect: Okay (too informal for UI)
- Home page vs. homepage ✅ Correct: Home page (two words) ❌ Incorrect: Homepage (often used but technically incorrect)
- 2FA vs. two-factor authentication ✅ Correct: Two-factor authentication (2FA) ❌ Incorrect: 2FA authentication (redundant)
- Wi-fi vs. wifi vs. WiFi ✅ Correct: Wi-Fi ❌ Incorrect: WiFi (often seen but not the official spelling)

Login vs. log in

- ✅ Correct: Log in (verb) / Login (noun, adjective)
- ❌ Incorrect: Login to your account (should be Log in to your account)

✅ Correct:

❌ Incorrect:

Sign up vs. signup

- ✅ Correct: Sign up (verb) / Signup (noun, adjective)
- ❌ Incorrect: Create a sign up (should be Create a signup)

✅ Correct:

❌ Incorrect:

Log out vs. logout

- ✅ Correct: Log out (verb) / Logout (noun, adjective)
- ❌ Incorrect: Please logout (should be Please log out)

✅ Correct:

❌ Incorrect:

Cancel vs. abort

- ✅ Preferred: Cancel (stop an action before it completes, more user friendly)
- ✅ Correct but technical: Abort (To forcefully stop a process. Used in more technical contexts, like system failures - e.g., "Process aborted due to an error")
- ❌ Incorrect in general UI: Abort (too harsh for standard user actions)

✅ Preferred:

✅ Correct but technical:

❌ Incorrect in general UI:

Email vs. e-mail

- ✅ Correct: Email (correct and widely used in software, more modern, should be capitalized at the start of a sentence)
- ✅ Correct within copy: email (standard when it's in the middle of a sentence, as it's a common noun, e.g., "Please enter your email address.")
- ❌ Incorrect: E-mail (technically correct but outdated)

✅ Correct:

✅ Correct within copy:

❌ Incorrect:

Email vs. e-mail in German context 🇩🇪

- ✅ Correct in German UI: E-Mail (official and correct)
- ❌ Incorrect: Email (while gaining popularity, "Email" is still considered incorrect in formal German writing)
- ❌ Incorrect: email without capitalization in German

✅ Correct in German UI:

❌ Incorrect:

❌ Incorrect:

- ✅ Correct: E-Mail-Adresse (official and correct)
- ❌ Incorrect: Email-Adresse without capitalization in German

✅ Correct:

❌ Incorrect:

Username vs. user name

- ✅ Correct: Username
- ❌ Incorrect: User name (though some older UIs still use this)

✅ Correct:

❌ Incorrect:

- 🟢 Preferred: Last name (even in en-GB UI)
- ✅ Formal: Surname (less common in UI, more in official documents)
- ❌ Incorrect: Lastname (should be two words: Last name)

🟢 Preferred:

✅ Formal:

❌ Incorrect:

Last name vs. surname in German context 🇩🇪

- 🟢 German UI: Nachname
- ✅ Official forms: Familienname (but avoid in casual UI)

🟢 German UI:

✅ Official forms:

Ok vs. okay

- ✅ Correct: OK (most common in UI)
- ❌ Incorrect: Okay (too informal for UI)

✅ Correct:

❌ Incorrect:

Home page vs. homepage

- ✅ Correct: Home page (two words)
- ❌ Incorrect: Homepage (often used but technically incorrect)

✅ Correct:

❌ Incorrect:

2FA vs. two-factor authentication

- ✅ Correct: Two-factor authentication (2FA)
- ❌ Incorrect: 2FA authentication (redundant)

✅ Correct:

❌ Incorrect:

Wi-fi vs. wifi vs. WiFi

- ✅ Correct: Wi-Fi
- ❌ Incorrect: WiFi (often seen but not the official spelling)

✅ Correct:

❌ Incorrect: