Blank state

This shows a blank state where a package manager search returned no results

Blank states are shown when there is nothing to display in a window, for example, when a search returns no results or a broken network connection causes nothing to display.

1. Blank states give concise and relevant information about the cause of the blank state.
2. Consider all scenarios that could cause the blank state to occur, and provide actions or help boxes to resolve.
3. Blank states can contain simple action buttons, such as Retry Connection button when there is no network connection, or an error help box if a connection attempt fails. For more information see content best practices.

Don’t: Use blank states where the user needs to take multiple actions to continue.

Don’t: Use blank states for rare situations or edge cases. Check other feedback types to effectively communicate to the user when something goes wrong.

Idle state

Debugger window informing the user to select an Instruction to begin a see the details

Windows are in an idle state when there is nothing selected to populate it with content. For example Timeline needs the user to select a GameObject in the Hierarchy to display its properties.

1. Idle states inform the user about what needs to be selected, often with the phrase structure;
   “Select ___ to ____”.
2. Idle states are usually non-interactive and do not contain actions. They often only contain a message advising what needs to be selected.
3. Idle states are not first-time use cases. To help onboard the user new to a feature, use day zero states and custom onboarding flows instead.

Day zero state

Timeline and Collaborate windows informing the user about actions required to begin

Day zero states are used to welcome the user who is new to a feature or section of the Editor, to help them understand the context of the first steps needed to continue.

1. Day zero states are populated with starter content and actions to enable the user to take the first steps
2. Day zero states are used for brief, simple actions (eg. load an asset, open a setting, login)
3. Be mindful to avoid including too many action controls in a single empty state
4. If the user needs to be onboarded in multiple steps, with a variety of actions to start, use sequences of onboarding or launch flows in a full window. Day zero states are meant to be brief

Message

Empty state messages should use the plainest possible language that can clearly convey the message.

1. Always use --unity-font-size (Default) and sentence case for the message text
2. Make text easily scannable to highlight key information
3. Keep the message concise. Only include the information the user needs to understand and resolve the immediate event
4. Avoid obscure abbreviations and technical jargon. Use a console log or a help box message to communicate errors or technical information

Docs Style Guide

For more information on content guidelines visit Unity Documentation Style Guide ->

Displaying actions

Consider including an action or link to help the user decide what to do next.

1. Always use .minibutton base style for action buttons
2. Be mindful to avoid including too many action controls in a single empty state
3. Keep button labels concise when describing what action the user can take (eg, "Login" , "Remove" or "Create")

Buttons

For more information on buttons go to Components > Buttons ->

Displaying help boxes

In some cases, an empty state with a message and an action might need to be supported with a help box.

“No network connection” blank state on initial display, and after a connection attempt failed

Consider including help boxes if the state persists longer than usual, or the attempt to recover from the empty state has encountered an error.

Help Boxes

For more information on help boxes, visit Components > Help Boxes ->