Love our Articles?

Sign up and we’ll send you new ones every month.

Written By:
Fanny Vassilatos
Ceara Crawshaw
abstract illustration of a data dashboard on a light purple background and a dotted paper style area containing a few pie charts with purple accents, abstract stacked bar chart, and 3-line line chart in green, pink and grey

Dashboards are the mother of all screens. In data-heavy industries, it’s easy for software to feel overwhelming. Dashboards play the crucial role of congregating key information in a streamlined place. Whether it’s for analytical, operational or strategic purposes, being able to interpret the right information at a glance is pivotal for teams and departments of all sizes. When designing a data dashboard for your own enterprise product, your team needs to be very intentional about what data points get showcased. Make no mistake, data dashboard UX is tricky, but hopefully we can help. In this article we’ll share the dashboard design UX best practices we’ve learned over the years.

🐦  Early sign up is open for the Dashboards Masterclass 👈  (plus 4 other new pattern masterclasses)

Why does dashboard design matter?

A product’s dashboard is like the control center — think of an airplane cockpit. It’s a page that allows you to take the pulse of recent activity, recognize patterns, and identify trends and changes over time. Dashboards should provide clarity through prioritized and actionable insights (#buzzwordalert).

Why are dashboards relevant to enterprise software?

In data-heavy platforms, a common pain point is navigating multiple data sources and disjointed systems. Dashboards can unite those systems together and provide a global overview. They are typically the homepage. Dashboards offer an at-a-glance snapshot and prevent users from having to check 10,000 screens just to “know what’s up”.

Things to consider for your dashboard UX design

Follow these prompts along with your team as you embark on tackling your dashboard UX design. These prompts should help you think about how you want to apply dashboard best practices to your specific scenario. 

Is the data clean enough?
The very first thing you get to do is a data architecture analysis. Sounds fancy? But really, just sit down with your brainiest peeps, look at your data structure, have a chat with your DBA. What data do you even have? Is the data maintainable? Is the metadata consistent and scalable? Start with prompts like these:

  • Is the data tracked over time? 
  • How much historical data do we have? (years, months etc)
  • Can we calculate if/when statements to create insights?

Map out user context
As much as it would be nice to design a dashboard for each persona, that wouldn’t be very efficient.  Find the overlaps and divergences.
If the divergences are small enough, creating multiple unique versions might not be necessary. But if they are large, you should consider catering to separate personas.
Aim to keep it global at first (default state) + allow for granularity with interactions (see below).

Determine dashboard goals
What are users expecting to do with that screen? What questions do they need the dashboard to answer?

  • What needs their attention?
  • What do they need to report on?
  • What deserves a spot on the dashboard?
  • What are the most global metrics that deserve higher visibility?
  • What needs to be visualized?
  • What personas/scenarios does this dashboard need to be catered to?

Figure out what key actions will be executed there —prioritize warnings and actionable items
In order to offer an experience that is informative at the overview level, you need to be very aware of what users are looking for. You can always allow them to drill down but be sure you surface the key stuff they can take action on, and any warnings they should quickly be made aware of.

Find out what is taking the most time for users to compile
Try to prioritize which charts will actually make it to the dashboard. For this, you need a good understanding of your typical user personas, what are they currently doing to obtain this information? Of these things, which ones do they do every day? Versus once a month or once a quarter?
To do this, try a workflow mapping exercise with your users, or you can learn a lot by reviewing their internal spreadsheets or reports.
This can help guide the selection process of what to actually show on the dashboard. When personas are very differentiated, this can warrant creating multiple versions of the dashboard.

Is the data relevant over time?
Is it pertinent to this particular data point to be measured in time?  Is there historical data that can surface trends over time? Are there better ways to represent it? (Ratio (pie-chart), totals, averages (lists), deltas (diffs), etc.)

Is the data captured in a way that you can represent with graphs?
Can you actually visualize it as a graph? Are there measurements you can place against each other to drive some contrast or a sense of proportion? Is it worth modifying the way you capture the data and have additional metadata to turn this into a visualizable chart?

Anatomy of dashboard UX

hand-drawn simplified dashboard screens. First one showing a filters area as a left sidebar, navigation as a top bar, and a content area made of sections. Second one showing the zoomed-in content area and separate sections made of modules. Third one showing a zoomed-in module made of data, line chart and key numbers

At the high-level, the page should consist of your navigation (duh), a filter area (top or side) and the content area made of sections. As much as possible, try to keep the scroll length limited to a single page.

Zooming into the content area, we should sense distinct sections. Group related stuff together. Consider the styling of your text headers to communicate a clear hierarchy.

Inside these sections are where your modules live — the meat of the dashboard. Modules are the grouped entity of a chart or graph or list accompanied by its title, key values, labels, legend and other accessories. They often live inside a “card” design but can also work well as floating elements.

Layout UI patterns for dashboards

Intuitive page layout

Dashboard UX design and UI are very closely related. On such a critical page, you need to optimize content placement for the way your users will scan the page. This key page acts as a homebase with strategic entry points into more granular flows. Users should be able to click a module or chart and enter a dedicated page for that data type. 

To optimize that behaviour, consider the typical eye-scanning patterns that are true for web pages. For left-to-right (LTR) language speakers, those would be the F and Z patterns. 

The F shape suggests that the eye will naturally get drawn to the top-left corner at first and then scan horizontally, before zig-zagging (that’s the Z) down the page, again starting from left to right for the following sections or rows. 

hand-drawn simplified dashboard screen in purple with directional lines in pink starting from #1 in the top left corner, going across to the top right of the page, then diagonally down to #2 middle-left, going towards the right but stopping mid-page, going diagonally down to #3 bottom-left and then a little further to the right

Eye-tracking research shows that users tend to scan webpages in “F” and “Z” shapes

Since the top left area gets more attention, that’s where you want to showcase the most global numbers, or the most relevant data.

You’ll want to structure your charts and graphs into related sections going top-down. Starting of course with the most important at the top, following with a global overview in the middle, and wrapping up with a more detailed breakdown at the bottom. 

Research around the F pattern proves that the further down users get on a page, the less they scan the full width of the row. So again, make sure to stick the important stuff on the left side.

Consistent card layout

Card layouts are very common for data dashboards and come in many shapes and sizes. A card layout doesn’t mean all your charts are visually enclosed in a distinct “div”. It just means that your charts and graphs are treated the same way, consistently placed along their title, labels, legend and other accessories.

Examples of styles of cards containing title, line chart and legeng: Floating with no background, Card with white background and rounded corners, Title accent with bold full-width coloured line underneath title

You’ll want to study the best way to layout your graphs inside their cards. Make sure you decide on a solution that can allow for different types of graphs, and that leaves room for recurring elements like key values, date pickers and legends.

Here, consistency is key. You’ll help your users a lot if they can quickly find the title on the top left of each module, or the legend always at the bottom center. That’ll help reduce visual noise when they scan the page.

Bar chart, line chart and pie chart, laid out in cards of various sizes all with title in the top left, date picker in the top right, and legend at the bottom

Chart UX patterns you can use

☝️Before you start

Make sure you and your team take the time to hash out the data details around your charts and graphs. There are a lot of considerations that go into the logic of what is rendered in a graph. Here are some examples:

  • Do you implement a dynamic y-axis that responds to the values shown?
  • Or does it make more sense to keep it static?
  • Do you opt to not show a chart at all if data doesn’t exist?
  • Or is there a more informative empty state you could design?
  • Is the data compared to a baseline or goal? How is that represented?

Now that you’ve nailed down the page structure that works best for your users and your data, let’s zoom in a little and explore ways to elevate the charts and graphs you present in your dashboard.

Think of it this way: how much extra love do your out-of-the-box graphs deserve? Of course a lot of the patterns mentioned below come for free with your typical chart library but do the work of determining which small tweaks need to be brought to elevate your data and better meet the user needs. 

Use of colour

Smart use of colour is a very elegant way to provide additional meaning to the data. How might we go beyond the basic language of red-yellow-green for bad-neutral-good?

Red colour square Negative, Yellow colour square Neutral, Green colour square Positive

Going beyond the typical “red is bad, green is good” stoplight formula 

Some of your charts might benefit from a secondary palette like different shades of, say, your brand colour to express levels of intensity. Higher values could indicate larger quantities or densities, and lower values smaller ones.

Rectangular scale of colour samples going from 10 - light purple to 100 - almost black, with Brand Colour being pointed to number 40

Using variations of the same colour to represent levels of intensity

Other classics if your page is already filled with stoplights are blues to indicate positive values, and oranges for negative trends.

sample of three shades of blue and a blue line chart trending up with caption Blues Positive trend. Sample of three shades of orange and an orange line chart trending down with caption Oranges Negative trend

Blues and oranges provide the same levels of vibrancy and contrast as greens and reds, without your UI feeling like a trading terminal

When exploring colours, it’s important to keep accessibility in mind. To ensure good visibility, make sure the colours you choose have high enough contrast against your background colour.

Lines, fills and textures

Again with accessibility in mind, it’s considered best practice not to rely on colour alone. Look for ways to add some hashes or texture in your fills and your legends.

Base colour and variations by adding a dot grid, vertical lines, horizontal lines, line grid, diagonal lines to the right, diagonal lines to the left, diagonal grid

We can build a lot of variety from a single base colour

The same holds true for lines. A line chart with a bunch of solid lines in different colours can quickly become hard to interpret. You can add in a variety of styles of dotted lines.

sample of various dotted line styles: dots, dashes, wider gaps, dashes & dots, variable dash length, solid

Increase accessibility with dotted and dashed lines


Deltas are used to showcase differences (aka: diffs). When relevant, make sure your charts bring forward consistent deltas to your users. They can be relative (% change since same day last month) or absolute (absolute difference compared to global average). Deltas should catch the eye and be quick and easy to make sense of. 

collage of various types of deltas: Icon first has a colour indicator red yellow green, an icon trending up flat or down and the percentage change; Textual has a small arrow icon trending up flat or down and a natural language label; Inline is displayed inside a table row with percentage change on top of small coloured dot red green yellow with pale label

Deltas are either positive, neutral (little to no change), or negative

A typical way to present deltas in the context of graphs is to allow users to select from a few options. 

line chart in a card layout with a delta dropdown in the top right corner where options are selectable: compare to last week, last month, last year, industry


When adapting your dashboard UX design for mobile, the first question to ask is whether all the information is relevant for your users’ “on-the-go” scenarios. Try to understand what they need to see when they’re not sitting at their desk. Chances are they don’t need it all and you’ll save yourself a whole lot of work.

Maybe only display that top section, the most important or global data, and fit it in a vertical layout instead?

stacked bar chart in a horizontal layout where hovering on a colour from one bar highlights the same colour in all bars

A stacked bar chart in its desktop horizontal version

mobile interface of a stacked bar chart where hovering on the legend items highlights the matching colour in each bar

The same stacked bar chart adapted to a vertical layout for mobile

mobile dark interface showing a blurred bar chart with white text on top: "this chart is better viewed on a larger screen, try rotating your device into landscape mode"

There’s also no harm in indicating that this page  or a particular chart is better experienced on a larger screen, or to encourage them to flip their mobile in landscape mode.

Data labels on charts

In general, labels are central to excellent UX design, dashboard design is no exception. When dealing with large timescales or datasets, negotiating space might become a bit tricky. Angled labels typically work well, but there’s always a limit. You should account for those edge cases early and pre-determine the logic to use once the threshold gets surpassed. 

There are different ways to navigate label length. Determine in advance how you want long labels to behave. How many characters can you display without it feeling too bloated? How do you want to manage ellipses to best serve your users? For example, deciding to crop the ending versus the middle of a label?  “September 19” truncated to 6 characters can become:  “Septem…”  or  “Sept… 19”; which one conveys the most information?

If space really becomes an issue, remember: not everything has to be visible at all times. The visual of the chart itself should communicate the majority of the insight. So don’t hesitate to hide some labels altogether and leverage tooltips in these denser views where more specific labels could appear only on hover.

line chart showing a lot of x-axis labels one per week and per month and per quarter very dense barely legible line chart with fewer x-axis labels shown by default only one label per quarter instead of per month

Here we’ve got one endpoint per week, but only display labels for Quarters to provide the high-level trends & projections

You can prevent some of these issues by limiting the length of the selectable filters or date range to ensure users can only select as much as the viewport can offer.

Finally, there’s always the option of coding a horizontal scroll. But for this, watch out for where the scrollbar will appear and account for the room it’ll take up!

Typography & hierarchy

When looking at trendy dribbbl-y dashboards, we often see big bold numbers in a stylish display font. When done well, these typographic accents can really help the functionality of your dashboard. They do a great job at catching the eye. If you’ve done your research and identified the right numbers to accentuate this way, it demonstrates confidence and decisiveness. 

dashboard interface with beige background colour and dark green accents where key numbers are shown in a very bold and larger font size

From the user’s perspective, it means you’ve done your job, you know what your users are looking for and you’ve made sure the system is effectively keeping track of these data points. All-around trust-builder. And karma points.

Interactive graphs and charts

Okay, now that our charts and graphs are neat and consistent inside their page structure, let’s look at interactions we can offer our users.

To avoid barraging the user with data, you can borrow some of the concepts of progressive disclosure. Offering gentle reveals and visual emphasis upon the user’s request really helps mitigate overwhelm and confusion. Here are a few interactive UX patterns that embrace those principles.

Tooltips & hover states

Hover states are the perfect way to hide that secondary layer of detail while avoiding visual noise. Since the goal of the dashboard is to provide an at-a-glance snapshot, the visual of bars or lines should be enough for users to sense the trends. But revealing additional detail upon hover is a great use of progressive disclosure. That way your users can leverage it when needed, and it doesn’t clutter the page by default.

Colourful stacked bar chart where hovering on legend items highlights the related colour in each bar

Toggling variables

Another interaction that could be relevant for some of your charts is the turning on and off of certain variables. Let’s say the default view of a line chart presents 7 different lines. It might be useful for the user to hide some of those endpoints so they can focus on comparing a smaller selection. 

This can be implemented by making your legend items into a checkbox list.

Part of a dashboard screen where deselecting items from a table view affects the number of lines visible in the data chart above

Filters within dashboards

🥅 We wrote a full piece on filtering targeted to enterprise software needs, have a look!

In short, you can offer your users a full-page filter sidebar (or horizontal bar for that matter) but this means the filter selection affects the whole page —i.e. every single chart at once. It’s always useful to have filters always accessible; consider a fixed header for users to easily initiate them as they navigate the page.

Another option is to have smaller filter options inside each module or section. That way, users can be specific in what they want to see. They could filter the top section by location, and then select a specific date range for the middle section.

Custom personalized dashboard pattern examples

Now, if you really want to go all out and you know from your users that the dashboard is where they spend most of their time, you might want to build some customization options.

This can take many shapes. You could allow them to move modules around, and reorganize the order of the sections by drag-and-dropping. (Fancy!) You can also let them hide and show some sections.

You might even want to consider integrating a custom “build your own dashboard” flow in the onboarding UX. That way, they get to explicitly pick the endpoints they want to see and they get to make it as minimal or as complex as they wish.

Jira example of adding gadgets to a new dashboard and rearranging the layout

Example of Jira’s Create Dashboard flow. You get to pick Gadgets and organize them inside a module layout

Whether or not you venture into these more advanced interactions, you always want to give your users some options. If ever the way you designed the dashboard doesn’t meet their needs, you should always allow the data to be exported as raw CSV’s so they can pull it out and manipulate it elsewhere. That’s just some basic data etiquette. Data needs to be free! If you love the data, let it go. 🕊

Wrapping up

This might seem like a lot of work to create excellent dashboard UX design, and that’s because it is. 

Remember why you’re doing this. You’re giving shape to the essence of the value your platform offers. Treat it like a spaceship cockpit, make every detail count. 🚀

Learn to love your data and have conversations about it with your crew. That way you’ll be able to make the right decisions and curate it appropriately.

Remember that your page layout should accurately reflect users’ priorities.

Elevate your data by leveraging colour and textures, providing added insight with deltas, considering mobile screens, and pre-determining the logic of rendering labels.

Take the time to handpick and build the right interactions so your users feel in control of what they’re looking at.

You got this! Now make us proud 🥲

How does this fit in with the development workflow?

If you’ve been struggling to implement complex features, (like filtering) that your users find intuitive to use, we have put together a course (Design SOS) that will help improve your implementation and overall usability.

🧠 Want more enterprise-focused UX guidance?

You’ll probably enjoy our pattern analysis on enterprise data tables.

“Digging deep into dashboard design is our favorite thing”

P&P crewdata ux nerds