[Reference] Dashboard Definition

This page displays take away information related to building user interface dashboards for products. I used a few online resources to source responses and get some amazing feedback for a project I was working on at the time. I use this information as a reference point for research in the design industry.

What purpose does a dashboard within a product serve?


I work on a tech team where we develop a great content management product used on desktop and mobile platforms. I consistently run into questions pertaining to the Dashboard section of the product which I feel very strongly about.

Some of the questions are:

  • Why do we need a dashboard?

  • What purpose does it serve?

  • Does anyone even use it?

I'd love to get feedback from designers and developers in the community who have thoughts about this subject. Go >

Key Takeaways:

A dashboard's purpose is to summarize all the important information under an umbrella. → Giving the user a "quick glance" at their data before they dive deeper into the various sections under that umbrella.

Dashboard's should only contain important information. For example:
→ System warnings/alerts/etc.
→ Links to common actions (create/browse/manage/etc.)
→ Summarized numbers for the day/week/month/etc.

→ If you have a larger system with a bunch of parts which are always moving (ie. hosting, analytics, project management, etc), dashboards are invaluable. If your users don't use the dashboard you should rethink the information architecture of the page for a more optimized consumption experience.

Are they trying to make a decision? If so, about what?
Are they trying to determine if action is needed?
For example, monitoring that tells them a service is running properly?

Was the person doing before they looked at this component, and why did they come to look at it?
Now that they've seen it, what will they do next?
What will they do differently because of what they've seen?

I would start by asking whether people are actively navigating to this screen in order to do something, or whether this is a default landing screen.

→ People don't open software apps for no reason. They are trying to do something. If you can connect the elements on your screen with things people are actively trying to do in the moment they load that screen, that's a strong justification for your design choice.

What is the best data to include on a wallboard / dashboard?


Tool to be used to monitor all aspects of the startup, from project to server ops. Server ops, SCRUM, weather, there are lots datasets to put on a wallboard. Does your company have an awesome one - if so why? Looking to include data from third-party tools like Pivotal Tracker, Get Satisfaction, Chartbeat, etc

Key Takeaways:

Actionable data. Depends on your business of course, but visualizing non-actionable data pollutes mindspace rather than clarifying it. I have seen quite a few dashboards lately that have very impressive data sets/viz employing excellent design to convey a lot of information quickly efficiently...but how much of it is truly useful?  The hardest part in designing a dashboard is keeping it simple.

I constantly fight with myself (and with folks smarter than me) over wanting to add features to dashboards I work on...for reasons like: because I can add the feature, or, because I think it will impress someone if I accomplish some technical feat in the process.  

However, unless that awesome new 'feature' represents actionable data, it's noise. That's why Jonathan's advice is sound - if it's not actionable data, it pollutes rather than clarifies.

The second most important piece to include on any dashboard?

What does a good product dashboard look like?


I want to learn more about the kinds of metrics other product managers use to plan and monitor a specific (online) product throughout its lifecycle. How broad or narrow should a product dashboard be? What do stakeholders tend to be interested in; just financial metrics or product performance stats too? Would really appreciate the thoughts from other product managers on this, based on their experiences.

Key Takeaways:

The best way to think about relevant metrics is to first understand the company's goals for the next 3 to 6 months. If the company's goals are not defined it might be a good idea to develop a set of clear goals by collaborating with the stakeholders first.

Once you define those goals your metrics should match those specific goals.

Start off with a larger set of metrics and then narrow it down to top 10 metrics. YoY analysis is always good. We used to track several SEO metrics and also product metrics.

Relevant SEO metrics:

  • Page Views

  • Unique Visitors

  • Organic Traffic

  • Time spent on landing pages

  • Time spent on other specific pages (of course there are many more)

Relevant Product metrics:

  • New Signups

  • Customer Blogs Posts

  • Customer Renews

Conversion Metrics:

  • << this is very specific to your business >>

  • Orders

  • Comments

Whatever you do, always use an automated tool to build such a dashboard. It shouldn't take you more than a couple hours to analyze this dashboard.