Data Dashboards


Data makes the world go round. The ways in which it is viewed is even more important; how do you determine what is most important to each user? How do you design an interface that is digestible and not too cluttered? How do you offer reasons for why the data looks the way it does? It's a complex task to chew on and leads to different outcomes each time.

Click each image to expand

For a telecommunications client

This was from a hefty project creating a tool to monitor, expand, and optimize a telecommunications company's cellular network. These two dashboards are built around observing their own and their competitors' presence, performance, and growth in geographic areas.

Map-centric views

For the same client, this is a more geospatial view of data; letting the map take center stage, and viewing more data and performing actions in the panels on either side.

For a fast food client

This client came looking for a new tool for restaurant owners to perform common actions and view data about their performance. This is a page built around a single restaurant to view key metrics, errors, and graphs illustrating sales data. After is a similar page, with a group of graphs filterable by location.

What Makes a Good Dashboard?

Dashboards seem to have become an "easy" thing for a designer to put together to show off their design skills. Building one that is actually useful is a more intricate task. There are several concepts that dictate these being successful and not an overload of information behind a sheen of shiny gradients and big numbers.


The layout is not an overwhelming grid of charts and tables. Content is thoughtfully grouped and arranged. A user can find what they need quickly. Color is not overused - and used in utilitarian ways to signify success or warnings.

Real Data

When designing, use as much real data as possible. This will help you decide how much space a numeric value needs, if a set of data is more effective as a pie or a line graph, or what scale that graph should use.


Raw data is often not useful; explore how to explain the data, compare it to previous data, or tell the viewer why the data is like it is.


Use data that is thoroughly collected, fresh, and unbiased


The widgets that make up a dashboard are aligned around a single purpose. This helps the user stay focused and create a story around their role or task at hand. Consider personalization for each user type.


Shy away from unconventional ways of showing data or less-discoverable interactions. If a set of data is traditionally shown in a line, and a line has tested to work best, don't invent a snazzy new graph style. You can put a nice gradient on that line, but anything extra can stay in your Dribbble portfolio.


Ok, so what did my process actually look like creating these? Let's use the telecom one from above as a case study.

The Backstory

This dashboards project was a spike off of a bigger project for the same client, a massive geospatial analysis tool to view data about their network on a map, organize it, graph it, distill it down to answer business questions and make decisions, etc.

Some initial work was needed to be done to figure out the purpose of a dashboard among this larger tool. There was also talk of another tool just for reports. What tasks should a user do in each tool? What questions would each tool answer best? What types of users do we expect to do each kind of task?

Finding Purpose

We decided to build the dashboards tool using a pre-defined use case as a pilot: observing our own network against our competitors' and tracking how their offerings & footprints change. I identified two users to bring along with me during the whole process. They helped me learn what actual questions they need answers to on a regular basis, what data they look at to answer them, how they share their findings, and the frequency at which they need updates. I met with them often to show progress and test ideas.

Building Blocks

Once I had the guiding questions as my north star, I could start determining which data to present to answer those questions in the most effective way, and which format to use. This dashboard would be a combination of a map and smaller "widgets" to present graphs and tables. Some examples of the conclusions I started making:

  • Show total count of competitors in a given zip code boundary via color coding and tooltip content on hover
  • Show average download speed in a given census block boundary via color coding and bar graph modal on click
  • Show competitors offering fiber internet by county via a table ranked by counties with highest presence

More Sorting, Wireframing, Designing

From there, knowing what content would be on a map and what would be in widgets, I could start sketching out layouts and filling out a "bento box" that used the space in an effective and digestible way. I showed lo-fi prototypes to my users frequently to ensure it was in line with what they expected.

Design Systems

The same design system we devised for the greater analysis tool was used for the dashboards. A lot of the components could be shared too - things like graphs, tables, and map styles that engineers had already built could be reused for speed & consistency.

Now What?