Application header

What problem does this solve?

Every application in the Atlassian suite has a customised version of a branded header. This consistent experience shows the integrated nature of the products, and users don't have to relearn this common area for each of the applications.

When and how to use this pattern

The application header follows the same structure for all pages (from left to right):

Application header example
Application switcher:
to move seamlessly amongst all integrated Atlassian applications.
Logo and application name:
to easily identify which application the user is in.
Top level navigation items:
adjusted to the particular needs of each application, and can be buttons or dropdown buttons. Note: buttons, dropdown buttons and other controls have unique styling for the application header area that is not to be used anywhere else on the page.
Optional: "Create" button:
can take on three forms (with unique designs for use in application header only):
  1. Simple button: creates a particular entity in the application, without any further choices.
  2. Simple button, followed by modal dialog: opens a modal dialog that displays further choices for new entity.
  3. Split button: shows the most common 'Create' option immediately, but reveals more options if users click on the dropdown part of the control.
Optional: Feedback button:
users can leave feedback about any page they are on.
Optional: Search field:
conducts a search across the whole application.
a dropdown button that offers links to all help options available in this application.
Optional: Notifications:
offers a quick-access inline dialog to display the latest notification connected to the users' accounts.
if users have admin access within the application, more options are revealed to change the configuration of various parts of the application.
User profile:
offers link to the users' profiles but can also contain access to other settings and tools.

When designing the controls to move through the information architecture, be mindful of a few items:

  • Structure and sequence: Order the top level menu items by frequency of access from left to right, starting with the most frequently accessed. Within the dropdown menus, order the items by the most used to least used
  • Menu content: Menus can display titles to indicate a group of related items, a separator to indicate group divisions (where it makes logical sense), 16px icons (but always with accompanying label), checkbox and radio button variations. Use sentence case for menu items. Use words that clearly communicate the intended outcome of a menu item

The page header gives a title and context to the content within a page. It may contain additional navigation, metadata and actions relating to the page content.

Page header example
The title of the page (e.g. 'Dashboard') or the name of the object in a collection (e.g. the 'DEV-210: New actions bar' branch in a repository). This is the only required element.
The full path to the content is show as breadcrumbs. The middle steps of a breadcrumb may be truncated if the path is long.
Any additional information about the content (e.g. date created, author) that is not part of the content itself.
Use this for actions that apply to the object or entire content on a page. Actions that are specific to one section of the page should be placed in that section and not in the page header.

Horizontal navigation

Horizontal navigation switches between different sections on a page.

Horizontal navigation example
Selected item:
The section currently in view.
Nav items switch between different sections on a page or different areas of a single page app. If you have more than 10 navigation items, consider using the vertical navigation pattern instead.

Vertical navigation

Horizontal and vertical navigation is used for navigating content pages, while tabs are used for switching views of the same content. Vertical navigation is optimised for using the left hand side of pages to navigate through a set of screens.

Interactive example and usage

General usage


  • Use vertical navigation for moving between related sets of pages
  • Use at left hand side of pages and modal dialogs
  • Use for navigation where you need groupings
  • Use when you need a scalable navigation
  • Use dividers and group headings for structure


  • Never nest vertical navs inside each other
  • Icons are not recommended in this navigation
  • Don't use dropdowns in the navigation
  • Use grouped headings as links


What problem does this solve?

Pagination helps users move between a finite number of items that are distributed across several pages. Pagination allows you to display a smaller set of results to avoid overwhelming the user, have a clear indication of location within results, know the total number of results, and move to a specific subset of results quickly.

When and how to use this pattern

Pagination can be used whenever there are too many results to show at once, mostly in listings in tables, search results, and directories. What constitutes 'too many' can be influenced by factors like:

  • System load times
  • Amount of data in each entry (the more data you show
  • Screen space
  • … and more

Make sure that the first batch of results users see holds enough items to cater for the most common use cases (unless this is not possible due to an assumed strict order, e.g. 'alphabetical'). Unless there is a strong use case for it, users will not paginate far.

In general, users navigate through their data by clicking on the corresponding page number. As users move through the pages, the URL should change accordingly so that URLs can be shared, and expert users can adjust the page number manually.

There are a few scenarios where it becomes necessary to move users to other pages, due to actions they committed elsewhere:

  • If users search or filter, move them back to the first page
  • If users sort a column in a table, keep the user on the current page, i.e. if they were on page 3 when they sorted, they should be on page 3 on the resorted table

Interactive example

The page footer is a base component and it appears at the end of every page. By default it contains the product name, the product version and a 'report a bug' link.

The contents of the footer can be adjusted if related information is available, e.g. system status. However, the footer should not contain product navigation or help text. If you are unsure about whether a particular link or piece of information should be added to the footer, err on the side of leaving it out.

Interactive example

Single-line footer

Two-line footer – reserved for when a separation between footer items is needed



  • Color any footer icons in medium gray to match the text


  • Wrap footer items onto a second line to save space
  • Create a footer with more than two lines
  • Place content below the footer avatar