DocuWare Design

A range of resources for designers, developers

Voice & Tone

Voice

Just as you have only one voice to speak with, also DocuWare has only one voice that should never change. The voice is the personality of our product.

Our users perceive DocuWare as a professional and informative product, while our voice remains at an approachable eye level with our users.

DocuWare is perceived as professional, informative and approachable

Professional and informative

Writing in a professional voice means being clear, concise, and seeking to convey information and ideas quickly. Give every word in your text a specific purpose, and don’t use superlatives like “best,” “least,” or “most.” Nevertheless, be informative and write descriptively if needed so that also complex topics are well received by our users.

Approachable

Use everyday business language and talk to our users on eye level. We stay responsive to them by writing positively and addressing them personally, but never in an insensitive way.

Tone

If the voice is our product’s personality, then the tone is how we express that.

According to our voice also, our tone is rather serious and respectful. We speak matter-of-factly but still want to encourage our users when, e.g., they fulfilled a task successfully by using a more excited tone. Our approach is a conversational way of writing.

Voice is our personality, tone is our mood

The following chart expresses the DocuWare tone of voice.

On the point

Avoid language that’s overly opinionated, funny, or trendy. Don’t try to be funny by using jokes, and slang. We provide a professional and serious product and should also speak like this.

Matter-of-factly but positive

We are excited about our product and should also share this enthusiasm but in moderation. Describe only the important information, without superlatives, and avoid exclamation and quotation marks.

Conversational

Keep the tone encouraging and address the user directly. We are speaking to our users in a conversational tone. Our voice is professional, but when using a conversational tone, sometimes saying “can’t” sounds more natural instead of “cannot” or the other way around.

Polite and friendly

Treat our users respectfully and politely. Irreverent writing could be misleading.

How to apply

The following example highlights how Voice and Tone can differ the impression within the same situation.

Use case: Error message

The user is facing an error message. During a system error, all changes were discarded.
In this situation, users’ stress levels might increase.
We want to lower that. 😉

Version 1

We take the user’s situation seriously and want to inform matter-of-factly what happened and how the problem can be solved.

  • Voice: Professional, informative, and approachable

  • Tone: Serious, matter-of-factly, conversational, polite, and friendly

We write in a rather dry style to keep the text serious and matter-of-fact. We address the user personally and thus remain conversational.
We are polite and friendly by using “please”. This is essential because the error is caused by the system and not the user, so we want to lower the stress level.

Version 2

At first glance, it’s not always clear how much the tone variation can make a text sound different. Therefore let’s mix 2 of our tone settings up to highlight a bad example.

  • Voice: Professional, informative, and approachable

  • Tone: Funny, enthusiastic, conversational, polite, and friendly

Using the word “Nope” makes the text sound very hip and edgy. Also, it is not clear what exactly the error was.
Summarized, our voice settings totally got lost by changing the 2 tones from serious to funny and from matter-of-factly to enthusiastic.

Writing Principles

Language

American English

Write in American English

American English has fewer regional accents and dialects to consider. Therefore it’s more internationally used than British English.

Product names

Stick to the product names

Using different terms for the same function confuses our users in their actions. If you are unsure how to write a term properly, you’ll find crucial DocuWare Terms in the Microsoft Teams team “Localization”. Please reach out to UX, to get access to the team.

Simple language

Write plain and simple

Users benefit from having text at a lower reading level when reading on a screen. In addition, our users are a broad group with different educational levels. To ensure that a text is well-readable and accessible, keep your text plain and use simple words.

If you are unsure if your text is well-readable, check your words in “List of human words” bellow, and/or with the Hemingway Editor.

Avoid technical jargon

When writing about a topic you are familiar with, keep in mind the specific persona you want to address. Technical jargon might not be understandable for all of our users. Try to write out the information instead of using jargon.

Write only information that has value to the user

The microcopy should be valuable and useful for the user. Avoid using decorative text chunks or proper sentences to fill the gaps in the User Interface.

BUT: Write out what is happening even if this makes the text longer.

Seriousness​

Write in a serious way

Don’t try to be humorous or write in too casual or irreverent ways. Writing like this could mislead our users and don’t fit a business product like DocuWare.

Positivity​

Write positive

Avoid negative words like:

  • Can’t
  • Don’t
Use the opposite adjective

Try to use the opposite adjective to create a positive statement or homonym words to refer to positive or negative states.

Don’t accuse the user

In case of the undesired system state caused by the user’s action, do not accuse her of doing something wrong or avoiding required actions.

Directness​

Write to our users in the second person (“you or “your”)

Use this style when DocuWare:

  • Speaks to the user directly
  • Asks to provide specific user information
Don't combine the first and second person in the same sentence

Numerals​

Write numerals to express numbers

Users scan rather than read. Writing out numbers in proper words can slow them down in their action.

Write integer if no decimal places are required

Users can easily feel overwhelmed when faced with a large number of, e.g., documents they have stored. Using an abbreviation instead of displaying the concrete number reduces the cognitive load of our users and lowers their stress levels. In addition, less space in the UI is required by using an abbreviation.

Structure
1 – Numeral
2 – Space
3 – Integer
4 – + (optional if the number is greater than the integer can express)

Terms and Phrases

DocuWare

Avoid writing “DocuWare” when describing a system behavior

If you are unsure of how to write a term properly, you’ll find crucial DocuWare Terms in the Microsoft Teams team “Localization”. Please reach out to UX to get access.

Sorry and please

Use “Sorry” and “Please” only for errors caused by the system

Think about how often you ask someone to perform an action on your website. If you start adding “please” and “thank you” every time you want a user to perform an action, it will quickly become confusing. Be concise and use as few words as possible to convey what the user needs to do.

Grammar

Capitalization by APA Style

Use Title Case capitalization for summarizing content:

  • This is in general first heading on a screen
  • Capitalize all words with more letters than 3

Use Sentence Case capitalization for everything else.

Here you can find all regulations: APA Style.

Front-loaded information

Start with the highest information value

That’s how users can identify the objective with an initial glance at the beginning.

Structure
1 – Objective:
2 – User action

Active voice

Write in an active voice

This makes a clear and short sentence structure.

Short text blocks

Focus on a small number of key concepts

Divide long sentences into several sentences according to their key concepts

Use bullets and numbered lists for enumerations

Punctuation

Avoid exclamation and question marks

Avoid these characters. The text you’re writing should always be in a matter-of-factually way. Using those characters might bring to much enthusiasm to the text.

  • Use exclamation marks only to highlight content that should not be over-read by users.
  • Use only 1 exclamation/question mark per component.

Concepts

Error

Be precise

Write out the reason that causes the problem.

Don't blame the user

Write in the passive form when the user is the subject and might feel blamed for the error.

Write conversational

Don’t write only keywords but write out full sentences.

Write “please”, if the error was caused by the system

Success

Don't write "successfully" for normal system behavior
Write “successfully” for complex and important actions performed by the user

Empty state

Empty states are our chance to communicate directly with our users. Never leave a blank space and use this chance to introduce/encourage the user to the feature.
BUT: Fill this space with informative and useful information. Keep in mind that all text you’re writing must bring value to our users.

Types

Empty states come in 3 types:

  1. Regular
  2. Positive
  3. Negative
Use cases

All settings are cleared up.

Ex: User cleared all settings within a configuration.

  • Regular

All actions are completed.

Ex: User completed all assigned tasks.

  • Regular
  • Positive

No content to display.

Ex: File Cabinet is empty.

  • Regular

First use.

Ex: User opens a function for the first time, and no settings are made so far.

  • Regular
  • Positive

Onboarding.

Ex: User opens a function for the first time, and needs to be onboarded.

  • Regular
  • Positive

Error – No results to display.

Ex: User performs a search and the query is empty, or there aren’t any data to show.

  • Negative

Error – Something goes wrong

Ex: A website can’t be displayed.

  • Negative

Regular

Use positive and active wording

Don’t state what there is not but what there could be.

Describe the function

Write informative and give the user the necessary information for successful use.

Don’t use exclamation marks, and keep the text matter-of-factly

The text should be written in a matter-of-fact way. Without exclamation marks or overstatements.

Write instructions on how to proceed

Give users the information they need to use the function.

Positive

Show a little excitement

Sprinkle some cheer in positive empty states by writing “Well done!”. Make them aware that they’ve just completed their activities and encourage them to go on like this. 
BUT: Don’t write overstatements and get too casual here. We still want to keep a professional and informative voice.

Use exclamation marks carefully

Write only one exclamation mark per component.

Negative

Don’t accuse the user of doing something wrong

Even if the user caused the error. Write positive and don’t shame them.

Inform users about the concrete error and give instructions on how to proceed

Give users the information they need to solve the error.

Don’t use exclamation marks, and keep the text matter-of-factly

In this situation, too enthusiastic writing and using exclamation marks may raise the user’s stress level.

Gendered Language

What is Genderless language?

Whether there is a need to write for an internal or external audience, it’s essential to write for and about other people in a compassionate, inclusive, and respectful way. Therefore, the DocuWare copy should be from a person-first perspective.

Use the plural to avoid gendered language

Many languages lack gender-inclusive options. If gender-neutral language isn’t possible, then choose the most understandable expression.

Yes

They/Them/Theirs

No
  • He/him/his

  • She/her/hers

DocuWare is not a gender-specific product and can be used by a variety of users. Therefore, we must avoid gender-specific pronouns and instead use the “you” or plural form to address our users.

No

“{0}” cannot be matched to any existing user.

Yes

“{0}” cannot be matched to existing users.

Localization

Principles and techniques for effective Localization

Localization is adapting the DocuWare product voice, messages, features, imagery, and communication to achieve a linguistic, cultural, and geographic fit and adapt to a specific country and market.

The purpose is to make user experiences for everyone as comfortable as possible across different cultural and regional contexts. As DocuWare products are multilanguage and multicultural, it is essential to consider localization and go beyond translation to create more inclusive experiences.

Localization VS Translation

Localization is often confused with translation, but it goes way beyond. In fact, localization deals with much more than a word-by-word translation of text and content. 

Translation strives for a linguistic equivalent, while localization broadly considers adaptation for a market or cultural context. Localization requires Designers and UX Writers to convert text from one language to another but also to adapt to all the different factors that define a particular group of people: time zones, national holidays, gender roles, product beliefs, and cultural references.

Elements to localize

To give the product and content the look and feel of having been created specifically for each target market and country DocuWare aim at, the Development team should consider localization of the following elements:

Visuals

Changing the visual elements of the product (videos, images, etc.) according to each market’s tastes and cultural traditions.

User Interface

Adaptation of the User Interface controls, guides, components, and all other elements to fit the translated text.

Data

Update charts, statistics, and surveys with local market data.

Units

Conversion to local units of measurement and currencies.

Formats

Adaptation of date formats, phone numbers, and addresses.

Compliance

Gathering information and taking action on legal and local regulations.

This list is not complete and depends on the product, feature, country, etc.

Cross-cultural Design

DocuWare service is international in scope, and the product is available in multiple language versions. Therefore, planning how to serve global users from the very beginning, long before localization begins, is vital. For this, Designers should follow the Internationalization of User Experience, also called cross-cultural UX Design. 

Internationalization/Cross-cultural Design is about designing a product in such a way that localization is easier and can be accomplished without the need for rework or product redesign.

Cross-cultural Design involves:

Usability

  •  A cross-cultural design means letting the users choose which language they want to use instead of imposing a language based on their geographic location.

Personalisation

  • Means allowing users to change their preferences (e.g., change the language, or format (date/number) settings according to the regional requirements).

Adaptation

  • Allowing the local symbols to be displayed instead of international or region-specific ones, not leaving the untranslated text in images, etc.

Localization stages

It can be helpful to think of the cross-cultural UX design process as comprising four steps.

1. Traditional design

UI design

  • UX writing
  • Input controls
  • Navigation
  • Layout
  • White space
  • Visual hierarchy
  • Buttons
  • Content

Usability

  • Learnability
  • Efficiency
  • Memorability
  • Errors
  • Subjective satisfaction

2. Cross-cultural Design

  • Flexible design for varying language length and font size
  • Double-length pre- or pseudo-localization
  • Right-to-left language support
  • Support for local currencies, units, dates, time, and address formats
  • Choice of display language
  • Localization-informed UX writing

3. Localization of Nontextual UI elements

  • Layout
  • Visual hierarchy
  • Information architecture
  • Images
  • Color palette
  • Animation and video
  • Seals and badges
  • Call-to-action buttons
  • Use of white space
  • Sizes

4. Content localization

  • Headings
  • Body text
  • Error messages
  • Onboarding screens
  • Instructions
  • Features descriptions
  • User-generated content
  • Customer/User support emails and responses
  • Social media and other marketing collateral
  • Email marketing campaigns
  • Documentation

Guidelines

Translations size

Designers should always be aware of the possibility of long translations. Designing all user interface components to be extensible can ensure that even longer translations (such as Spanish or German) can be displayed without issues.

Responsiveness

Containers should be responsive. Expansion of the length of text strings is typical when translating them into other languages, so the use of bounding boxes and containers with fixed dimensions should be minimized. This includes buttons. A hyperlink can be considered if a call-to-action requires a long text string.

Expansion factor

Text length often changes when user interface text is translated into another language. For example, English is a very compact language, which in most cases, leads to an increase in the volume of the translated text. Designers and writers should consider extensibility factors when working with user interfaces and controls.

Language Approximate expansion factor
English
1.0
German
1.8
French
1.5
Spanish
1.8
Italian
1.7
Japanese
0.8
Chinese
0.8
Korean
0.7

Words order

The User Interface must be adapted to the possible change in word order, as the latter can alter dramatically in translation. If the layout and functionality of an interface depend on a particular word order, it can break when localized.

Tips

  • Assume the word order of every sentence in your interface will change when translated.

  • Avoid using UI components to build sentences.

  • Avoid splitting one sentence into several strings, known as concatenated strings. If you use concatenated strings, translators won’t be able to change the word order, and their translations won’t make sense.

  • Avoid using variables in your strings, as they will translate differently.

Hardcoding text strings

The development team must avoid hardcoded text strings in the user interface. Instead, all text elements should be made easy to extract for translation, including Alt-text, Titles, Toolbar labels, and Menus.

Fonts

Choosing the right typography can affect how product text appears in different languages. Product fonts must support a wide range of weights and different scripts in order to display similarly on other operating systems, platforms, browsers, etc.

Line breaks

Line breaks can appear incorrectly in languages that do not use spaces between words, such as many CJK (Chinese, Japanese, and Korean) languages. Therefore, designers should use tools that calculate line breaks for CJK languages or automatically create them, which improves text readability.

Bidirectionality

Languages such as Arabic, Hebrew, and Farsi are read from right to left (RTL). While designing for left-to-right languages, Designers and Writers should ensure that the layout design and microcopy are optimized and can be mirrored for RTL languages.

Data, Date, and Number formats

Different regions have varying conventions for data and date formats, including addresses, phone numbers, names, calendars, measurements, currencies, payment methods, and more. It can be a good idea to check the international standard for automatic formatting of numbers, currency, and more, for example, CLDR (Unicode Common Locale Data Repository).

Culturally differences

The UI must not be culturally specific. Referring to specific holidays or cultural practices should be avoided unless it is inevitable that they’re known worldwide. Instead, designers should use visuals, content, and interface formats that are useful and meaningful to users worldwide.

Although icons and emojis are widely used for applications and websites, not all visual elements are interpreted in the same way across cultures. An icon or emoji might have a positive impact on one culture but could be offensive in another. When possible, universally known icons should be used. Usage of country-specific icons and their placement should be mindful.

To ensure that the content used in the product is understandable for the audience, Designers may consult a localization specialist if available, or someone who can serve as a subject matter expert for the target culture or market, such as a local user, an in-market support team, or a translator.

Seasons

Referring to seasons must be avoided. For example, “spring” in the northern hemisphere is “fall” or “autumn” in the southern hemisphere. Instead, it is advised to use the month, quarter, or temperature (if relevant).

Yes
  • New system version is released in October of each year.
  • In November and December, the cloud system experiences higher traffic volume.
  • During warmer months, data centers face a higher risk of cooling failures.
No
  • New system version is released in the fall of each year.
  • In winter, cloud system experiences higher traffic volume.
  • During summer months, data centers face a higher risk of cooling failures.

Non-DocuWare terms

Capitalization of non-DocuWare terms should be avoided. This may cause translation errors because translators expect not to translate capitalized terms.

Labels

Place labels above fields as it accommodates the lengthy character strings that often result from translation better than using left-aligned labels does. Left-aligned labels require more horizontal space, risk breaking layouts, and reduce the available space in which the user can input data.

Examples

Yes

Session expires soon

No

Your session will expire soon

German translation cannot be displayed fully because of the formal use of “You”

Yes

Creation day

No

Created

“Created” will most probably translated in past tense. Be more specific and use a terms that describe the action behind it.

Yes

Deletion rules for emails

No

Deleting Emails

“Deleting Emails” can be translated in a continuous way.

Tips

  • Keep labels short and extend them up to 1.8 longer to ensure that they fit in the page/dialog (German/Spanish can be much longer than English).

  • Do not write “You” in titles because of the use of the formal You in other languages – the title can get very long.

  • Avoid writing labels in an -ing, or -ed form, because it can be translated in ambiguous ways.

Positioning

Fixed positions should be avoided to ensure that content flows naturally. As for responsive containers, any elements in the user interface with fixed or hard-coded positioning risk breaking the layout. Instead, designers should ensure that elements adapt to the surrounding content. It is advised to view the product’s user interface in different languages to understand better how its layout might change.

Icons

Icons and symbology should be adapted and localized to be relevant to the target market. Whenever it is possible, the icon should be combined with a text label to clarify the meaning of the icon. Combining the two can help the user learn what the icon signifies and avoid misinterpretation.

Yes
  • Use a generic icon representing your concept for global relevance.
No
  • Avoid using icons that only have local relevance for global products, like a dollar sign to represent payment or money in countries beyond the US and Canada.

Color

Color choice can directly influence an individual’s product perception. While some colors are interpreted across many cultures with relative consistency, others convey various symbolic meanings across cultures. In addition, colors can hold discrete connotations in different regions. Therefore, Designers and Writers should consider those differences whenever using, describing, or mentioning colors.

Information density

Preferences for information density and design styles vary across regions and cultures. Density and style preferences can be explored with help from a localization specialist or expert in the culture. Within the same product, designs may be changed to better serve audiences with different backgrounds or needs.

Power Users

Remember to support power users. Keyboard shortcuts and access keys must be localized as well.

Translation freedom

Designers and Writers should plan and socialize upfront the strategy about how much freedom the translators can have in adapting product content and controls and how exactly transcreation (a process to rewrite messages to fit the target culture) should be used.

Testing

Standard research and testing, such as functional testing done by Designers and Testers together with native speakers, should help to reveal technical and functional errors in localized content. In addition, designers and Writers should always aim to cover design and copy/microcopy concepts with user tests.

Chat Icon Close Icon