Objectives

The objective of dashboards is to summarize the primary information of the service. In general, there are three primary use cases that a dashboard can address:

  • Monitor: Users monitor the overall system health and track trends to prevent issues and optimize the system.

  • Investigate: Users filter and drill down to the root cause of the occurring issues, make decisions after investigating, and take action. This often involves navigating across services.

  • Be informed: The dashboard provides guidance aimed at new users about how to use the service. It also informs all users about service updates relevant to their tasks.

When creating a service dashboard, focus on your users. The guidelines and structures we provide are oriented to build a more consistent experience throughout a user interface, but ultimately the experience delivered should be based on concrete data, such as conversion analytics, user research, and direct user feedback.

Areas and content types

A
B
C
C
B
D
D
D
C
E
E
F
A
B
B
C
C
D

The content of your dashboard page should be distributed following a hierarchical order of importance so that it conveys the key information of your service in a simple format. For an example of a dashboard, see our demo service dashboard.

In a typical dashboard, there are three main areas that you can use to divide the content:

Service overview

Use the top area of the page to provide the most significant and high-level insights that users need to be aware of at first glance. Include actions that are used to control the content of the page.

The following are examples of content types for the service overview area:

A.
Page level actions

Actions that affect data displayed on the page or that allow users to create the main resource type for a service which will be displayed on the dashboard. For example: Filter by region, or launch an instance.

B.
Service status

You can provide status information on a service level, such as displaying service health information. Or you can provide it on a particular set of resources, such as the scores of the most important resources.

Service data

Use the middle area of the page to display data that provides context to the top page insights. Users can monitor the service status and investigate to perform issue resolution.

The following are examples of content types for service data area:

A.
Charts

By using charts, users can compare data series throughout a period of time, against other data series, or to quickly parse a specific value of high importance.

For information about creating charts, see the data visualization guidelines and our data visualization components.

B.
Lists

Lists are a collection of data in a tabular format that users can explore in depth. This format is effective for quickly identifying categories, comparing values in a large dataset, or accessing detail pages.

Service support

Use the bottom of the page to group information about updates and communications important for your users, which help them in optimizing the service. To support your users in being successful in understanding and setting up the service, use the help panel.

The following are examples of content types for service support area:

E.
Related resources

Group the information regarding service updates or service technical details that you want to communicate to your users. Provide links to external documentation so that users can find more information. For example, a new feature that empowers users with more control over their resources, or technical information about regional support.

F.
Help panel

You can provide a summary of information that helps new users to understand and set up the service. For example, links to technical documentation that explain how to use the service, or step-by-step configuration instructions to set up and run the service for first-time users.

Content principles

The objective of the content on a dashboard page is to provide information that can be consumed quickly, with minimum interactions or cognitive processing. Users should glance at the dashboard and immediately see answers to questions.

When you structure the content for your dashboard page, think about your user's objectives. Answering these common questions can help you do this:

  • Highlight: What data is most likely to change regularly, or change in a way that is significant to users?

  • Focus: What data is important to communicate to users, and what are the best ways to make it prominent?

  • Usage across devices: Will your users view the dashboard on different devices? If so, how does this affect the complexity of the data represented and the user interaction with it?

  • Frequency: How often would your users refer to the dashboard?

  • Context: What information is needed to make a metric understandable?

Use research methods and metrics to define what type of content is relevant for your users.

Relevance

Dashboards have a primary goal to communicate critical information. There are two categories of business intelligence dashboards that are generally used for this: operational and analytical.

  • Operational dashboards: aim to impart critical information quickly to users as they are engaged in time-sensitive tasks. They present data deviations, show current resources and their status. They help users to be quick, proactive, and efficient in managing day-to-day business occurrences.

  • Analytical dashboards: provide the user with at-a-glance information used for analysis and decision making, often including features like drilling-down and ad-hoc querying. They help users to investigate trends, predict outcomes, and discover insights in the past and in the future, by using historical data.

We recommend to refer to the above categories to orient the content towards an operational or analytical approach. However, due to the variety of users interacting with a dashboard page, you can consider a mixed approach when defining the content for your dashboard, by providing both operational and analytical information across the page.

Density

  • A dashboard page should never be overwhelming. Users expect it to provide key information to monitor, manage, and optimize, but they also use ad-hoc solutions to get the supplementary information they need, for example by using 3rd party tools.

  • Cognitive best practices consider seven (plus or minus two) as the number of images a brain can comprehend in one time. Consider seven as the limit number for data representation in your dashboard, as well as of items within a list or a graph.

  • Clutter and visual noise can distract your users in achieving their goal. Consider providing filter mechanisms, or break your dashboard into two or more separate dashboards.

  • If you opt to provide multiple dashboards your objective should be to group the right type of data within a dashboard page based on your users needs, and to establish parent-child relationship between the dashboards which align with your service architecture. For example, provide a parent dashboard for an overview of key insights related to your service, and a child dashboard to represent key insights relative to a specific set of resources.

Readability

The content of the dashboard page should be easy to understand, follow a logical order, and convey the right information for your users.

  • A user should be able to find the most relevant information on the dashboard within a few seconds. The most important and frequently needed metrics should be easy and quick to parse. Other tasks, such as ad-hoc investigation, can take longer.

  • To define the format for the data you’re going to display, begin with your user’s needs, and then choose the appropriate data representation type according to its purpose. For guidelines, see data visualization.

  • Avoid displaying long lists of data such as logs. Also, reduce the level of interactivity of the components, such as complex filtering on a table or a graph. Keep in mind that the user goal is to have a quick overview of the service status, so provide access to detail pages or cross-service navigation where the user can explore further.

Layout

Structure

Our design system provides a 12 columns grid that you can use to structure the content of your dashboard. To learn more about the grid system, follow the guidelines for grid.

  • Columns

    Allows you to create a layout with a maximum of 12 columns, and specify the relative column spans for different viewport sizes.

  • Areas

    Allows you to group components within an area of the page and specify the stacking behavior for different viewport sizes.

Component sizes

When creating the structure and positioning of the component throughout the page, use the following sizes to define how to best represent the data of living in your dashboard page.

  • XL size

    Components that span across the page are useful to display content that needs to catch users attention, or to represent data visualizations that require a complex interaction.

    • For example, an overview on the key metrics of your service, like running instances, volumes, security groups and load balancers.

    • For example, a chart where the users needs to be aware of events taking place in small time intervals, and perform filtering to narrow down the represented data.

  • L, M size

    Useful to display content that needs to convey multiple information, where users can pause their attention to perform mental actions, such as comparison of data.

    • For example, a chart representing trend of resources usage over a period of time.

    • For example, a table listing current alarms that need user intervention.

  • S size

    Useful to represent simple content that can be scanned quickly. Often related to one data type only, that conveys additional, but not critical, data to users.

    • For example, a chart to represent billing data.

    • For example, a key-value pair for the service health status.

Key UX concepts

Empty states

Empty states occur at two levels: page and component.

  • Empty page

    • Always display empty components, a dashboard page should never be a blank page. Include actions to trigger the population of the data at page level and/or at component level, depending on your service architecture.

    • Some services might require users to complete a tasks before the dashboard gets populated. Include a main action at page level to trigger a flow that allows users to create the first set of data which are then represented in the dashboard.

    • A dashboard can include a customization mechanism to allow users to toggle the visibility of the components. Consider setting a default set of components for your users, and allow them to build on top of that.

    • Some services might need up to 24h time to retrieve data that populates a dashboard view. Inform users about any time estimation, for example by using a flash message to communicate time expectations before the dashboard gets populated.

  • Empty components

    A component empty state occurs when users haven't created a resource or have deleted all resources. Include actions to trigger the population of data in the component. For example, a button that allows for cross service navigation to set up alarms.

Latency

  • We recommend to optimize your dashboard so that the page does not take more than two seconds to load. Research shows that this is the maximum time before users focus gets shifted away, resulting into an increase of page drop.

  • Optimize your dashboard page to allow for fast loading of the content. Consider loading content within a component asynchronously if the estimated loading time takes up to ten seconds. One second is about the limit for the user's flow of thought to stay uninterrupted, 10 seconds is about the limit for keeping the user's attention focused on the task (source Nielsen Norman Group ). Follow the guidelines for the loading state specific to the component you will be using.

Where dashboards fit in services

  • The dashboard page may be used as the default landing page of a service for returning users. Make sure to reflect it in your service side navigation, by placing the dashboard as first link listed in it.

  • Some services might have a hub structure, we recommend to add the dashboard page as first link within the console section in the service side navigation.

Actions

You can include actions in your dashboard page, both at page level and components level.

  • At page level you can provide an action to trigger the main function of your service, for example a create flow to launch an instance. You can also provide actions to filter the data represented in the dashboard page, for example filter by regions, services, or accounts.

  • At component level you can provide actions connected with the items displayed, for example, an action to request a limit increase. Provide actions that allow for cross console navigation, for example "view in Cloudwatch".

Responsiveness

When structuring the dashboard page consider cross-device experience. Users accessing the page on a smartphone primarily want to monitor the service status, and have access to meaningful and actionable information.

  • Optimize the content loading time to stay under three seconds.

  • Use areas to define the stacking behavior of the components in smaller viewports.

  • Avoid data intensive charts to not compromise touch interactivity, provide instead access to a detail view of the data presented.

Writing guidelines

Page title

Use the following format: {Service name} dashboard

Breadcrumb

Use the following breadcrumb structure: {Service name} > Dashboard

Help panel

Follow the guidelines for help panel.

Accessibility guidelines

General accessibility guidelines

  • Follow the guidelines on alternative text and Accessible Rich Internet Applications (ARIA) regions for each component.

  • Make sure to define ARIA labels aligned with the language context of your application.

  • Don't add unnecessary markup for roles and landmarks. Follow the guidelines for each component.

  • Provide keyboard functionality to all available content in a logical and predictable order. The flow of information should make sense.

  • Make sure you define ARIA labels for the selection inputs that are aligned with the language context of your application.

Related patterns and components

Data visualization is a graphic representation of information and quantitative data intended to quickly and clearly convey meaning.
Presents data in a two-dimensional table format, arranged in columns and rows in a rectangular form.
The help system pattern allows users to easily and quickly access help within the interface and current workflow.