DocuWare Design

A range of resources for designers, developers



  • Capitalize every first letter
  • Use a maximum of 3 words (if possible)
    (1) Verb – (2) Object
  • When referring to a button:
    Refer only to the label of the button without mentioning the component “button”
  • Write title matching buttons
  • Don’t use punctuation
  • Name the specific action the button will trigger


Buttons for a saving dialog

Button label pairs

  • Choose button labels that widely differ from another, if there are 2 or more buttons displayed on a screen

Suggestions for label pairs

Save changes dialog

Leave | Stay
Verlassen | Bleiben

Discard | Save Changes
Verwerfen | Änderungen speichern

Reset | Keep Changes
Zurücksetzen | Änderungen behalten

Delete | Keep Changes
Löschen | Änderungen behalten

Confirm actions within a wizard – amount of following steps is predicted.

Back | Next
Zurück | Weiter

Previous | Next
Vorherig | Weiter

Confirm actions within a wizard – process can be paused and continued later.

Back | Continue
Zurück | Fortsetzen

Previous | Continue
Vorherig | Fortsetzen

Last/final actions within a wizard

Done – (Intermediate)

Finish – (For very end of flow)

Button that comes with a checkbox with content like: “I have read and agree”

Submit – (User agrees on something and sends the agreement)

Confirm – (User only agrees on something without actual sending)




Icon Buttons

Toggle Buttons

Split Buttons




  • Keep it short
  • Write for a single line
  • Write unique and descriptive for each label
  • Use sentence capitalization
  • The label should be understandable even when stand-alone
  • Don’t use punctuation


  • For a longer description, prefer to start with a verb
  • For a shorter description, consider writing a noun
  • Name the specific action the checkbox will trigger
  • Write the positive state
  • The description must be understandable even when stand-alone


How to communicate with Dialogs in mind?

Dialogs inform users about a task and can contain critical information, require decisions, or involve multiple tasks.

A dialog is a type of modal window that appears in front of app content to provide critical information or ask for a decision. Dialogs disable all app functionality when they appear, and remain on screen until confirmed, dismissed, or a required action has been taken.

Dialogs are purposefully interruptive, so they should be used sparingly.


This section is available for DocuWare internal use only. You can see the content if you are logged into any company services. If the content is unavailable, log in to your DocuWare account in that browser and refresh the page.



  • Use sentence case capitalization according to APA Style
  • Don’t use punctuation
  • The placeholder text in input fields should not contain critical information (instructions or requirements) not displayed elsewhere.
  • Avoid appending the word “here”
  • Write the placeholder text as an example or call-to-action:

If necessary, add “Example” at the beginning


Text Input

Text Area

Number Input

Masked Input

Slot Input

Date Input

Time Input


What are Loader components?

Loaders are progress indicators informing users about the system’s or separate elements’ status of ongoing processes, such as loading, fetching, and submitting.

In addition, Loaders show the completion status of ongoing tasks and indicate whether a user can continue or leave the current context or flow.


A good Loader:

  1. Makes a user’s perception of time feel faster.
  2. Gives the sense that the application is making progress.

Loading Patterns

The two main Loading Patterns used in the Design System are Indeterminate Loaders and Determinate. The determining factor is time.

  • Determinate Loaders communicate a sense of duration. They have a starting point and an endpoint. They give users more information on how much time they can expect to wait.
  • IndeterminateLoaders have an uncertain duration. A common example is a looping animation or a spinner. They are less informative but are inevitable.



Loaders are communicative UI elements. They look and animate in ways that reflect the status of ongoing processes in the product and User Interface. They should never be decorative or used as placeholders.

Loaders use animation to capture users’ attention and inform them of an activity’s progress.

Loaders should be applied to all steps of the system processes (such as loading, saving, submitting, fetching, etc.) in a consistent, context-related way.

Loaders notify users that their request is performed. Although they do not provide details, they reassure users that their action is being processed

Loaders can help people decide whether to do something else while waiting for the task to complete, restart the task at a different time, or abandon the job.


Based on the duration of an operation, there are the following types of Loaders:

Loading Spinner

Used for indeterminate, unquantifiable tasks when the operation time is unknown (ex., loading or synchronizing complex data).

Progress Bar

Mainly used for determinate tasks with a well-defined duration.

Skeleton loaders

Used for indeterminate tasks with unknown operation time.

As a general rule of thumb, the following guidelines should be considered:

Duration Loader Type
0–2 seconds
No indication is needed (generally instantaneous to the user).
2–5 seconds
Loading Spinner should be used.
5-10 seconds
Progress Bar should be used

Note: A textual indication of the time remaining is generally recommended in these scenarios.
10+ seconds
Progress Bar alongside Cancel Button should be used. Users should be able to cancel the process.

Note: A textual indication of the remaining time is strongly recommended in these scenarios)


  • Loaders should be used to step a user through a journey so that they can keep track of their and the system's progress.
  • Only one Loader type should represent each kind of activity in User Interface. For example, if an update action displays a Loading Spinner on one screen, that same action shouldn't use a Progress Bar elsewhere in the product.
  • In case of displaying progress for a sequence of processes, the system should indicate overall progress rather than the progress of each contained activity.
  • Helper text should be used alongside Loaders if the process is complex or has a long waiting time. In this case, the system can show the process explanation or the list of exchanging sub-processes that are taking place.
  • Loaders are transient. They appear only while an operation is ongoing and disappear after it completes.
  • When possible, determinate Loaders, like Progress Bars, should be used to help users estimate how long a task will take.
  • If possible, the system should provide accurate progress reports for specific run times when displaying Loaders.
  • Loaders should keep moving until the task is done or the system reveals the status so people know something is continuing to happen. If a process stalls for some reason, the system should provide feedback that helps users understand the problem and the required next steps.
  • When it's feasible, the system should let users interrupt a process without causing adverse side effects by including a Cancel option. If interrupting the operation might cause negative side effects, the system may provide a Pause option in addition to a Cancel. User Interface should always communicate when halting a process has a negative consequence.
  • Content and user interface must support automatic updates. If necessary, the system can automatically update various controls and content areas. Those updates should not happen simultaneously and block the entire interface. If people expect periodic automatic refreshes, these actions should be as non-interruptive as possible.


The User Interface may also explain why the user is waiting by providing an optional Description. For example:

  • Please wait while we calculate your results.
  • Please wait while we set things up for you.
  • We are gathering your data.
  • 21 out of 30 documents checked.


The Loader components do not have keyboard accessibility since they are intentionally not interactable or navigable. However, Development Team should consider incorporating other accessibility features to help users to go through the flow.

Loading in progress

The primary accessibility consideration for the Loader components is to convey their meaning to assistive technologies so users are aware of status changes. This can be achieved by exposing the title value “loading” of the Loader SVG image/icon to screen readers so users hear “loading” when a Loader component appears on the screen.

Loading has completed

When the Loader components disappear, the system should convey another message – for example, “loading is finished.” There are several possible ways to communicate the message:

  • If new content takes focus when the loading is completed (for instance, after a full page load), users will understand the system is now available. Annotating what component takes focus will ensure this is properly implemented.

  • Where a change of focus is not appropriate when the Loader components disappear, the information can be surfaced through a non-displayed status message that can be conveyed to users through assistive technology. Developers need to obtain information programmatically (annotate) to assistive technology.

Loading Spinner

Overview of Loading Spinner component

Loading Spinner is a component that helps to notify users or give visual feedback about system performance. The component displays progress by animating the indicator along an invisible circular track in a clockwise direction.

Loading Spinners is used to communicate:

  • that action is being processed,
  • data is being retrieved,
  • content is loading,
  • the system performs lengthy operations,
  • synchronizing complex data,
  • performing slow computations,
  • other system processes.

Spinner as a progress indicator is Indeterminate and doesn’t provide an estimation of the time the system needs to complete the operation. Therefore, this component should be used for unquantifiable tasks and can be applied directly to a surface of content areas or other components.


Loading Spinner expresses an unspecified wait time.

A Spinner spins permanently while a task is performed.


  • A descriptive Label for the action is optional but recommended for automatic or system-triggered actions.
  • The Label should describe the state of the action being performed. For example, if the status is active and action is performed, the Label should speak in the progressive form: “Saving…”, “Storing…”.
  • Once the action status changes to finished, the Label should change. For example, when saving is finished, it would read “Saved.”
  • If the loading status changes to an error, then the Label should change to tell the user that an error or failure has occurred.


Due to the nature of the Loading Spinner, it should only be used for operations that require a short wait time of up to 5-10 (five to ten) seconds and generally do not interrupt the user’s flow or block the user from progressing through the User Interface.

A loading spinner should be used only if the wait time is anticipated to be longer than 2 (two) seconds. A spinner that only flickers quickly into view can confuse the user.

A 100 ms delay should occur before showing a spinner to mitigate unnecessary spinners showing up at the same time when load times are minimal.

The Spinner should be displayed in the same area and contextual level where the processing takes place and maintain the exact alignment. For example, if only the Loader indicates that data is being retrieved for a specific content area, the Spinner must be displayed in that same area.

Optionally, a descriptive visual Label can be provided with the Loading Spinner to indicate the system action and give people clarity in case the process is supposed to take a while. For example:

  • Uploading data…
  • Storing document…
  • Saving changes…

In most cases, this may be unnecessary, as the animation of the control indicates that the system is performing the action. If a spinner appears when people initiate a process, a label is usually unnecessary. Designers should decide about the Label for automatically initiated processes or if it needs to be clarified what the system is doing at the moment. 

A spinner must be centered horizontally and vertically within the container. Without first applying a light or dark mask, Spinners should not be placed directly over text, components, or other visual elements on a page.

The system should not change a Loading Spinner to a Progress Bar in the middle of the process. Spinners and Progress Bars have different shapes and sizes, so transitioning between them can disrupt the interface and confuse people. Designers should carefully pick the type of Loader based on the actual system behavior.

Loading Spinners are perceived to be slower than actual and make loading appear slower. They should be limited in use and applied only if they can improve user experience but not harm it. If possible alternative approaches should be used. Designers may provide additional content or valuable information to people while the system is performing an action.


Size Value Usage
16 px
Used with Inputs, Labels, or inside other smaller UI elements.
24 px
Used within larger visual elements, like Overlays.
32 px
Indicates larger components are loading, like a Data Grid.
Extra large
64 px
Indicates a large content area of the UI is loading.


The Loading Spinner’s color contrast and background must comply with AA Level contrast ratios

Loading Spinner must be placed in a container to ensure accessibility, regardless of background type.

If the Loading Spinner is on its own, a visual version should be appropriate for light/dark backgrounds.

Multiple simultaneous Loading Spinner can be very confusing for assistive technologies. Designers should consider using only one Spinner at a time and giving that one Spinner the most accurate possible Description.

The Loading Spinner must be given a Description to explain the loading event. When creating Loading Spinner, Designers must provide developers with loading text value for the Description for loading and loading finished text value for the Description for loading finishing.

  • Descriptions should not be too detailed and must use generic words or phrases such as “The page content is loading” and “The page content loading was finished.”
  • If there are multiple Spinners on the screen, they all must have identical descriptions. The Description is read to screen readers only once.
  • If the Spinner also has a visual Label, it can be hidden from assistive technologies to avoid the Description being read twice.

For screen readers, the information on what action is taking place / what the system’s state is should be provided.


The Implementation Guidelines are available for internal use only. To access the live demo and code snippets, you need to be logged in to any DocuWare account on this browser:

  1. Log in to the DocuWare account
  2. Update the page

Progress Bar

Skeleton Loaders



How to use Tooltip components?

Tooltip (also known as Popover) components are transient, short user-triggered guiding messages (floating labels or views) that provide additional information about on-screen content.

Tooltips are used when space is tight or User Interface elements require further clarification. Tooltips can be triggered by hovering over, focusing on, or tapping a control or interactive area and remain visible as long as the trigger is active.

Use cases

  • User onboarding

  • Guidance

  • Textual explanation of visual elements

  • Showing concatenated text


Tooltips are made of:
  1. Container

  2. Label (Title (for UI elements) or Description (for action components) text

Tooltip can contain:
  • Keyboard shortcuts

  • Additional textual information


  • Tooltips are secondary in nature, not primary guiding text. Included information should be contextual, helpful, and nonessential while providing extra ability to communicate and give clarity to a user.
  • Mission-critical information should always appear on the screen, not tucked away behind a tooltip.
  • Tooltips are usually initiated in one of three ways: through a mouse-hover gesture, through a keyboard-hover gesture, or through the touch.
  • Tooltips are always paired nearby the element with which they are associated.
  • If technically achievable Tooltips should allow users to copy text from them in order to clarify the meaning or make a translation. In this case, hovering on the tooltip can make it available for highlighting text.
  • Tooltips should be provided for unlabeled icons. Most icons have some level of ambiguity, which is why it is recommended to use text labels for all icons. If labels can not be provided - the least designers can do is supply users with descriptive tooltips.
  • Tooltips should be used consistently for all unlabeled components without a contextual piece of copy, label, or description text. Tooltips should be used in case of doubts.
  • Tooltips should only include short, descriptive text. They disappear so they should never contain critical information that a user would absolutely need to proceed, or information without which a user may cause errors.
  • Essential information (what users need to fulfill their actions) should be always kept on the screen, not in the tooltip.
  • Tooltips should never stop a user (or be a gate) from completing a task or performing an action.


  • Use sentence case capitalization
  • Simple tooltips consist of 1-2 lines (it is recommended to not use no more than 5 words max.).
  • Tooltips must add value. Avoid repetition of visible labels and already available pieces of text.


  1. The Label – contains Critical information.
  2. The Placeholder – display an example of what the user should enter in the field.
  3. The Tooltip (infobox) – provides guiding information.





Date Pickers

Overview of Date Picker

A Date Picker is an input field that allows users to select dates through textual input or interaction with a calendar overlay.



Date Pickers streamline date selection.

Time Pickers

Color Pickers

Number Pickers




  • Keep it short
  • Write for a single line
  • Write unique and descriptive for each label
  • Use sentence capitalization
  • The label should be understandable even when stand-alone
  • Don’t use punctuation


  • For a longer description, prefer to start with a verb
  • For a shorter description, consider writing a noun
  • Name the specific action the checkbox will trigger
  • The description must be understandable even when stand-alone




  • Use sentence case capitalization according to APA Style
  • Write a single line: If possible don’t use more than 3 words
  • Prefer to use nouns. Don’t write verbs in toggles with label and description
  • Write unique and descriptive
  • Don’t write sentence fragments. The label should be understandable even when stand-alone
  • Don’t use punctuation


  • Use positive and active wording
    • Start with a verb
    • Write the effect of the toggle in an “On” position
    • Don’t write negations
  • Write a maximum of two lines
  • Don’t write sentence fragments
    • The description should be understandable even when stand-alone
  • Don’t write questions

When referring to a toggle

  • Write out the word “toggle” and the function that it triggers

Chat Icon Close Icon