This site has been deprecated. Please see the new Unity Editor Foundations for up to date information.

menu
About the 2017 HIG Checklist Best Practices Inspector Organization Hiding vs Disabling Controls Multi-level Help Selection Scope Resources

Checklist

This is a collection of guidelines to help ensure your functionality matches the look, feel and behavior of the Unity Editor. It is designed to help you catch common problems early, so you don’t have to waste time iterating late in the development process.

Interface

Icons

  • Author Asset Icons at 16x, 32x, 64x, and 128x to support hi-dpi screens and project view scaling.
  • Asset Icons should be the same for both Personal and Professional editor skins.
  • Author Component Icons at 16x, 32x to support hi-dpi screens.
  • To request icons please visit #unity-icons Make sure to allow for 2-3 weeks of lead time. All new components and assets need an icon before release.

Inspector

  • Always support multi-selection editing for all types of objects that can exist more than once in a project.
  • There should be no horizontal scrolling when the Inspector is at its minimum width of 275pt.
  • All controls (except Buttons) should be accessible by keyboard using tab/arrows.
  • Do not add a vertical scroll view inside the Inspector. This leads to ambiguity between the Inspector scroll view and nested scroll view for mouse wheel scroll events.
  • See Inspector Organization and Hiding vs. Disabling Controls.

Logs

  • Use Errors for situations where Unity can not recover/proceed gracefully.
  • Use Warnings for situations where Unity can recover/proceed, but users may be unaware of side effects.
  • Avoid using Info-style logs, which are reserved for user-generated debug information.
  • For Errors and Warnings, provide a likely workaround solution that the user can use to fix the issue.
  • Do not have logs that are printed every frame. Instead consider a Help Box for persistent errors in components.
  • Check the text for typos, voice, and capitalization.
  • Menu item text should be a verb or verb phrase, to indicate the action being taken when the button is clicked. See Verbs
    • .
  • Use ellipses ("...") if the action requires additional input after selecting the menu item (for example, if clicking the item opens a dialog box).
  • If clicking a menu item opens a new dialog box, the dialog box's title should match the name (without the ellipses) of the menu item that opened it.
  • Avoid introducing new global shortcuts, until Unity has a central shortcut management system. Check for conflicts.
  • Use Title Capitalization.
Main Menu

Window Toolbars

  • Use Toolbar styles for controls within the Toolbar. See API documentation on EditorStyles.
  • Exception: You can use normal Slider controls in the Toolbar.
  • Use 12px-sized font for all controls in Toolbars.
  • Avoid standalone control labels in Toolbars.
Toolbars Window

Tools

  • Tools in the main Window Toolbar (Pan, Translate, Rotate, Scale, etc…) should apply to all types of selectable GameObjects in the Scene View. Place other types of tools either in the Inspector or in a window.
    • Examples: Terrain Inspector, Palette Window
  • Tools should always immediately deactivate if the user switches to another tool.

Tooltips

  • Write Tooltips in complete sentences and terms, not shorthand or abbreviations.
  • Use full punctuation in all sentences.
  • Do not use system language or domain jargon. Assume that users are unfamiliar with the feature and domain.
  • Do not use Tooltips as a replacement for documentation. In-depth instruction on how to use a feature should be kept in documentation. Only use guiding information in a Tooltip.
  • All fields/controls should have a Tooltip.
  • Tooltips should be less than 3 lines.
  • Check the text for typos, voice, and capitalization.
  • Note: Tooltips do not work when the Unity Editor is in Play Mode.
Tooltip

Type and Fonts

  • Do not use a different typeface than the default one in the Editor.
  • There are five different font sizes you can use in the Editor:
  • Use the standard font size (12px) for most text.
  • Use the semi-small font size (11px) for search fields located inside toolbars.
  • Use the small font size (10px) sparingly for labels inside grids and similar small areas.
  • Use the big font size (14px) sparingly for list labels (Examples: Profiler)
  • Use the very big font size (19px) sparingly for window titles (Examples: Project Settings)

Wireframing Notes

  • Every platform uses the same font with a secondary option that varies per OS.
    • Windows: Inter, Verdana (secondary option)
    • macOS: Inter, Lucida Grande (secondary option)
    • Linux: Inter, Verdana (secondary option)
  • Inter Font sizes:
    • --unity-font-size: 12;
    • --unity-font-size-semi-small: 11;
    • --unity-font-size-small: 10;
    • --unity-font-size-big: 14;
    • --unity-font-size-very-big: 19;

    </ul>

    Undo and Redo

    • Use Title Capitalization.
    • Only use Undo/Redo for property changes made to GameObjects in the Scene and Assets.
    • The only reason to add view-specific changes to the undo stack is to ensure further undo actions can be visible to the user (for example, Selection changes).

    Verbs

    • Use verbs and verb phrases for buttons and menu items that perform actions.
    • Examples of commonly used and understood verbs:
      • Cancel Restores the objects/system being operated on back to its previous state.
      • Stop Leaves the objects/system in an incomplete state. Use when the operation can not be undone.
      • Skip Bypasses the current object, and continues the operation with the next object in the queue. Use for operations that act on multiple objects.
      • Skip All Bypasses all future objects and the current object. Use for operations that act on multiple objects.
      • OK A confirmation of some information provided to the user.
      • Create Creates a new object.
      • Delete Destroys an object.
      • Add Adds a new element to a list.
      • Remove Removes an element from a list.
      • Duplicate Duplicates the currently selected object/element.
      • Close Closes the current view.
    • Verbs and verb phrases should never be longer than three words.
    • Use Title Capitalization.

    Windows

    • Design for the smallest common resolution on the most used operating system (Windows): 1920x1080px
    • Dockable windows should remain functional through Editor restarts, as they get saved into the last-used layout.
    • All dockable windows should have a toolbar at the top of it with window functionality. See Toolbars.

    Controls

    Buttons

    • Button text should be a verb or verb phrase, to indicate the action being taken when the Button is clicked. See Verbs.
    • Use ellipses ("...") if the action requires additional input after clicking the Button (for example, if clicking the Button opens a dialog box).
    • If clicking a Button opens a dialog box, the dialog title should match the name (without the ellipses) of the Button that opened it.
    Buttons

    Delayed Fields

    • Only use Delayed Fields in cases that require the control to be confirmed (for example, by pressing Enter or by changing keyboard focus) to finalize the value.
    • Only use Delayed Fields if changing the property requires time to process, or if the change of the property is destructive. Otherwise, use non-delayed versions of these fields that immediately change the property value as the user is typing/manipulating it.

    Dialogs and Progress Bars

    • Dialog and Progress Bar Button text should be a verb or verb phrase, to indicate the action being taken when the button is clicked. See Verbs.
    • For custom Button actions, use a verb which describes the action being performed by the Button (for example, "Stop").
    • If a menu item invokes a dialog, the menu item text and dialog title should match.
    • Any operation that takes longer than 2 seconds should have a Progress Bar.
    Progress Bar
    • Use for choosing between multiple related actions.
    • Avoid having more than one level of sub-menus.
    • Use separating lines to group related actions.
    • Depict Dropdowns with a single downward-pointing arrow.
    • Interaction Model
    • Clicking the control spawns the menu beneath the control.
    • Clicking again on the control will close the menu and maintain the current menu item.
    • Clicking outside the bounds of the control will close the menu and maintain the current menu item.
    • Selecting an item will close the menu and make it the active item in the list.
    Dropdown

    Popups

    • Use Popups to switch between different modes/states.
    • Don't use for turning options on. If you need to let the user enable a setting, use a Toggle instead.
    • The Popup content should always show the currently selected mode/state.
    • Depict Popups with two arrows, pointing up and down.
    • Interaction Model
    • Clicking the control spawns a menu over the control.
    • Clicking outside the bounds of the control will close the menu and maintain the current menu item.
    • Selecting an item will close the menu and make it the active item in the list.
    Popup

    Foldouts

    • When using Foldouts for tree views (e.g. Hierarchy, Project View), clicking on the Foldout arrow should expand the Foldout, and clicking on the Foldout text should select the tree view element.
    • When using Foldouts for other cases (e.g. Inspector properties), clicking on either the foldout arrow or the foldout text should expand the Foldout.
    • Always indent elements exposed from expanding a Foldout.

    Help Boxes

    • As a general rule, if 80% of users could use the interface without a Help Box, you probably don't need one. Avoid using Help Boxes to describe edge cases.
    • No more than a few lines of text.
    • Don't use for documentation.
    • Follow the same rules as logs for choosing between box types (such as Error, Warning, Info).
    • Check the text for typos, voice, and capitalization.
    Error Help Box

    Int, Float and Double Fields

    • Avoid hidden or implicit behavior when a number field has not yet changed from its original value. If a change in value produces a change in behavior, consider placing the control behind an explicit decision that the user must make (such as a Toggle or a Popup), so that the user is clear about what should happen.
    • Disallow entry of any value that is invalid for the property.
    • If the value is bounded on both ends, use a Slider.
    • Interaction Model
    • Pressing Enter/Return confirms and finishes entry of the text.
    • Pressing Escape cancels the current entry, and reverts the field to the value it was before editing began.

    Labels

    • In Inspector-like windows, almost all input controls should have Labels.
    • Avoid using abbreviations unless they are commonly known to all users.
      • If unavoidable, clarify abbreviation meaning in the Tooltip.
    • Use headers to avoid redundancy. If you have multiple fields with the same prefix, consider making that prefix a header and indenting the controls under it. See Inspector Organization
    • Do not use any punctuation (such as colons, full stops or question marks) at the end of Labels.
    • Use Title Capitalization.
    • Check the text for typos, voice, and capitalization.
    • Only use Link Labels for opening external web pages.
    • Don’t use the words “Click”/”Click Here”. It is implied from the link styling.
    • When linking to or interacting with a web page, ensure that the link never gets broken.
    • Note: Link Labels are currently internal API only.

    Object Fields

    • Avoid hidden or implicit behavior when the Object Field is unset. If unsetting the Object Field changes its behavior, consider hiding the control behind an explicit decision that the user must make (such as a Toggle or Popup) to make sure the user knows what to expect.

    Sliders

    • Use Sliders when there’s a fixed range of values that the user can use (for examples, 1-10).
    • Slider inputs should be immediately responsive, and visualized in the Scene View if possible.

    Text Areas

    • Use Text Areas for multi-line text entry properties.
    • Interaction Model
    • Pressing Enter/Return inserts a new line.
    • Pressing Shift+Enter/Return confirms and finishes entry of the text.
    • Pressing Escape cancels current entry and reverts the field to the value it was before editing began.

    Text Fields

    • Use Text Fields for single line text entry properties.
    • Interaction Model
    • Pressing Enter/Return confirms and finishes entry of the text.
    • Pressing Escape cancels current entry and revert the field to the value it was before editing began.

    Tabview Toolbars

    • Use Tabview Toolbars to switch between views within the same interface.
    • Use variable-width tabs to fit the content of each tab.
    • Choose tab contents that are relatively uniform in length.
    • Ensure that the Tabview Toolbar fits within minimum inspector width (275pt).
    • When using a Tabview Toolbar in the inspector, use no more than 4 tabs.
    Toolbars View Tabs

    Toggles

    • Don't use the words "Enable"/"Use"/"Is" in Toggle labels. They are implied by the Toggle.
    • Never create a Toggle that disables functionality when the Toggle is enabled.
    • Only use Toggles for turning things on/off, never for switching between states of this/that.
      • Example: "Is Orthographic" should be a Popup with two states "Perspective"/"Orthographic" rather than a Toggle for turning "Orthographic" on.
    • Don’t use Toggles to start actions that make the user wait. Use a Button instead.
    • Don’t use Toggles for destructive actions such as deleting data or interrupting a process.
    • Use a Toggle Button in places where a checkbox is impractical, such as Toolbars.
    Toggle Toggle Button

    On This Page