Dashboard Design Case Study – Product Sales Dashboard

A case study of the key steps to designing a product sales dashboard with real-world challenges

Get your PDF of the entire case study. Just enter your email to receive yours.

[email-download download_id=”1398” contact_form_id=”1397”]

How to deal with strong opinions and inflexible thinking

The cast of characters

Who the dashboard was designed for

Dashboard Design Case Study – Business Performance Dashboard

Dashboard Design Case Study - Business Performance Dashboard

A case study of the key steps to designing a business performance dashboard from an international thought leader

Get your PDF of the entire case study. Just enter your email to receive yours.

[email-download download_id=”1345” contact_form_id=”1344”]

How to deal with strong opinions and inflexible thinking

The cast of characters

Who the dashboard was designed for

How to Get Data Visualization Buy-In From Your Boss

How to get data visualization buy-in and other practical tips from NickSight

Getting the budget needed to ramp up data visualization operations is a challenge I see many companies, even the most progressive and deep-pocketed, face. In this post, we will walk through how to apply a marketing approach to selling your boss on investing in data visualization by highlighting the function’s value proposition as it relates to the business.

Let’s start by sharing a story from my experience in the field as a data dashboard consultant.

Years ago, I was hired by a director of analytics to help steer him and his team in the right direction when it came to data dashboard best practices. It was made clear from the beginning that the company wasn’t entirely keen on moving to a “new a way of thinking/doing things.” The company was wildly successful and had been maintaining profitability for the last 10 years. The executive team was very risk-averse and had the mindset of “if it’s not broken, it doesn’t need fixing.”

During the workshop sessions, the analytics director, let’s call him Steve, came to me and wanted a few minutes of my time outside of our workshop.

Steve was brought onboard three months prior and was considered “progressive” by his company’s definition. He explained to me that he wanted to sell his boss on a more effective and efficient way the analytics team can take the workshop knowledge and implement it into a software program that was currently only licensed out to a few of the team members. Added licenses were a significant financial jump and required an account upgrade, but to meet expected demand and to scale their analytics business function, the entire analytics team needed to have their own software license.

During their last directors’ meeting, Steve had presented a detailed cost-benefit analysis of adding licenses and upgrading the current account for entire analytics team. He had also looked at the company’s leading competitors and analyzed their output which clearly showed the competition was beating them by both volume and quality. He ended the presentation with simple math executives like to hear: if you invest in X now, you will receive Y business impact, which will result in higher quality deals, customers who stick around longer, and better annual revenue numbers.

Yet, the other directors remained on the fence about the purchase decision, causing Steve’s boss to still be unsure about the investment.

Does this sound familiar?

In my experience, leadership buy-in for data visualization has two components:

  1. A clear and well-articulated value proposition; and,
  2. Education on what data visualization is and what it can do not only in the short-term but in the big picture strategy of the business’ growth trajectory.

To learn what a value proposition is, take the lead from your marketing department.

Without getting too granular with marketing terminology, a value proposition essentially is a summary of why someone should buy a product or service that is different from similar products or services offered by other companies. You can think of it as the hook that makes people choose to purchase from company A over company B.

In this use case, the value proposition of data visualization is entirely unique to your company and its main objectives. Perhaps for your business, investing in data visualization will:

  • Contribute to the company’s competitive advantage
  • Retire manual processes and create more efficient and effective ones bringing products to market faster and with more accuracy
  • Enable smarter and more precise decisions to be made
  • Offer deeper and more detailed insights into product development

Once you list out what the core differentiators of data visualization are at your company, summarize them into a few short succinct sentences to form a value proposition statement. This statement should explain the relevancy, quantified value, and unique differentiators of data visualization.

If you find yourself struggling deciding what makes a data visualization program different from other potential company investments competing for budget dollars, think of how marketing teams list out a product’s value propositions in preparation to market a product to consumers.

For example, say you’re getting ready to market a pair of running shoes. The competition is high for this product, so you must clearly differentiate it from other running shoes for consumers to see value in purchasing them from your company versus another. Your company’s running shoes are:

  • 5 x lighter than the leading competitor
  • Locally manufactured and handcrafted by retired athletes
  • Eco-friendly, but durable — lasts an entire running season without loss of tread or grip
  • When the soles do wear down, our company will give you half off your next pair
  • Free shipping and guaranteed delivery in less than 24 hours
  • 30-day trial period — you hate ‘em, return ‘em at no cost to you
  • Bluetooth enabled — connect your shoes with the fitness app of your choice for a more accurate tracking of your activity. This feature adds no weight to the shoe.

When you look at this list, make sure none of the differentiators are offered by your competitors. If they are, they are not considered a differentiator and should be removed from the list.

Start your pitch with clear benefits and the importance of data visualization to the business.

Every data dashboard workshop I run begins with a short set of slides that clearly lay out the benefits of why data visualization is important and how it translates data to business value.

It’s wise to keep these benefits simple and clear. Don’t over complicate and always have supporting evidence to your projections.

In short, make the investment’s high-level data visualization benefits crystal clear to your boss and in layman terms, such as pitching something like, “If we make our data look this way, our customers will not only understand it better, but they will begin to change their purchasing behavior, which increases our net margins by X% over X amount of time. To make our data appear in an actionable way, my team and I need these tools. Your investment of $X now will bring you $X in one year, $X in two years, and $X in three years.”

The aim is to make the value proposition so enticing that it would be illogical not to invest. Value statements can come in many forms:

  1. It will allow us to improve sales, margins, etc.
  2. Our competitors are doing it, we’ll get left behind. We lost 7% market share last year and we need to get ahead.
  3. It will reduce our costs by X% year over year.
  4. We will free up Y number of staff to do higher value, higher impact projects.
  5. We can reduce our licenses in legacy technology and replace with a lower cost dashboard solution.

Ideally, there will be examples you can point to in your company. If not, running a low-risk, low-cost pilot, can be used to demonstrate the value.

The exercise here is about negotiation and making your case — don’t back down, and always bring data and evidence to the table while being respectful.

Use terms and benefits that are applicable to your boss and what matters most to him/her.

When constructing your pitch, go through line-by-line of it and conduct a litmus test of sorts that challenge each statement against the following:

  • How can data visualization help my boss look good?
  • How can data visualization help my boss get a promotion?
  • What will make my boss look like an innovative leader in front of the other executives?

Positioning the investment to your boss’ benefit will ultimately benefit you the most. Often times, however, a boss only hears what will help them and make the business more money. Pitching your value statement using these parameters will go much further than saying you or the analytics team needs some tool the executive is likely never going to see or use.

Eliminate any uncertainty. When getting buy-in, always think two or three steps ahead so you will be prepared for any follow-up questions.

Go through the exercise of what you expect your boss to ask immediately following your pitch to them based on your experience with them in the past. What do they usually hone in on? Have these potential objections solve for and in your back pocket.

Not only will you be more prepared, but your boss will see you’re looking at the big picture and not just your own needs.

How to Build a Dashboard That Resonates

How to Build a Data Dashboard That Resonates | NickSight Blog

Do you find yourself frustrated because your data dashboard is not resonating with key business stakeholders? Don’t fret — you’re not alone. Many dashboard architects feel this way day in and day out. In this post, you’ll be given tips to help close that gap between a highly functional data dashboard and one that makes it clear to your audience what action to take from it.

Break the cycle of ad hoc reactive requests from users mid-build by engaging with them as early as possible for a more cohesive and effective result

You’re juggling a lot — between mitigating for data quality issues and building reports to trying to understand why data dashboard users are either asking so many questions or not enough. It’s wearing and, at the very least, can make you feel like your data dashboard is missing the mark.

If you find yourself here more often than not, it’s time to take a different approach to your building process.

A leading reason where many processes are broken is that there is a disconnect between you — the data dashboard architect — and the end-user. Many times the end-user presents issues that could have been totally avoided if they were engaged with before the data dashboard was built.

Include any and all data dashboard users early in the journey of creating the dashboard. Doing so has proven to eliminate frustrating risks altogether, yet it’s overlooked by so many.

You can easily avoid these and many other unnecessary risks such as changing goals and objectives, which cause the data architect to have to restructure the entire build — if the end-user is engaged with early and often throughout the building process.

And while not all user input will be integrated into a final data dashboard, most of the value comes from the interaction between the architect and the end-user by simply fostering a human-to-human relationship.

The relationship you build with the end-user is a relationship to craft carefully. If done well, over time the end-user or users can shift from being a critic to an advocate and even a champion of your work.  

It’s no doubt a tough cycle to break and it certainly requires you to take a step back to objectively look at your build process from the beginning to the end, but once it’s done, you’ll see a favorable return not to mention less work for you in the long run.

[RELATED ARTICLE: Why Are My Data Visualizations Ineffective?]


Not engaging users early and often adds the following risks:

User needs are not met

This leads to the user asking handfuls of questions when they actually see the dashboard, which results in frustration for both you and the user and a lot of tangential back and forth. Overall, not a great experience for anyone involved.

Users feel disconnected

Look at this from a customer service or experience perceptive. Say, for example, you’re under contract with a home builder who is working to build you and your family a brand new home.What if the builders only involved you in the process when they were handing you over the keys or when it’s time to conduct an inspection? You walk into your new home with a set of expectations of what it should look like and none of those needs were met, resulting in unmet expectations. You’d be very upset and tell everyone in your life about their less than impressive work. The builders would need to then have to go back to the drawing board to meet the buyer’s needs.The same is true for dashboard building. Communication with users throughout the process is the secret sauce to having a well-built dashboard that functions and meets the needs of the end-user.

Trust is eroded and lost trust is hard to earn back

Like in any relationship, trust is the cornerstone of its longevity. For business relationships, the emphasis on trust is perhaps a bit more important due to the fact that the user is entrusting you, the dashboard architect, to help them meet their goals and grow their career. If this trust is lost, it’s nearly impossible to rebuild and to earn back. Having an open line of communication coupled with honest level-setting conversations can keep the trust between the two of you healthy. Do everything in your power to keep end-user trust protected throughout the process. Avoid any and all instances where that trust could be at risk.

Word gets back to your boss and any potential promotion gets placed on the backburner

Let’s go back to our home building example. The unsatisfied home buyers are so unhappy they go directly to the builder’s boss and the company’s upper management. The buyers call the builders out by name and list in detail what went awry. Any good standing and potential pay raise or promotion the builders were poised for is now at risk.Again, the same is true for you as the data architect. If the user feels so compelled by a dashboard that doesn’t meet their needs, your boss is likely to hear about it from the user directly, which should go without saying — reflects poorly on you. Not only would any potential promotion fall the wayside, but your work could potentially be viewed differently and respect for it would be tarnished.

Conversely, engaging users right early and often does several things:

Dashboards fail to resonate with users because their questions and needs are not being answered or met. Without talking to them often it can be difficult to know what those needs are.

Improve and iterate on your building process by mapping their questions to your charts and continuously refine the visuals to the company’s objectives. At the end of the day, an end-user will find it less cumbersome if you ask clarifying questions throughout the process than after the data dashboard is released.

Get your free step-by-step dashboard workflow and process map

Follow this process and ensure alignment and business value every time

This is the process used with the Global Fortune 100 on actual real-world analytics engagements. It ensures alignment with stakeholders, user and the business that produces actionable insight and bahavioral change.

Why Are My Data Visualizations Ineffective?

Ineffective data visualizations are a top frustration felt by many data analysts and their teams.

Before we overview a handful of data visualization techniques that you can begin to leverage when building effective dashboards, it’s important to take a step back and ask yourself who you want the dashboard to be effective for? In this post, we will provide insights in how to solve for this common frustration and provide tips to start using right away.

Before you begin building a data visual, get to know your audience first to increase effectiveness

Often times, data visualizations are ineffective because they are built for the wrong audience in mind. The perceived value of dashboards, too, gets lost due to poor communication with the end users.

Find out all you can about the audience you will be presenting the data visualization to. Meet with as many members of the audience as you can to learn their biggest pain points, their work goals, and ultimately, how the data visualization will help them make better decisions.

Don’t be afraid to learn about your audience, even if it’s just a few members of it, from a personal level. Consider setting up a lunch or a coffee meeting to just get to know each other. This will start to establish a trust between you and them and reveal helpful anecdotes that can be lost in the formality of the day-to-day. If you’re short on time or your audience is not on site, try as best you can by email or phone.

The more of a connection you can find with your audience, the better build you will have because you will know a bit more about how they tick and what they’re looking for from your visualization.

Common reasons why data visualizations are not effective

  1. Failure to understand what the business value could and should be for the available data;
  2. Not engaging dashboard users early in the process to learn what they want from the available data;
  3. Insufficient or ineffective communication between stakeholders, users, and the data architects;
  4. Poorly designed dashboards and charts without a path to behavior change


Without properly planning ahead of a build with these common adoption barriers, at least at some level, it will be hard for your visualizations to have long-term success.

While most dashboard architects do their best to consider these adoption barriers in their planning processes, it’s not uncommon to become sidetracked mid-process with other tasks and in-the-moment priorities that take the focus away from the prep work.

After all, as critical as this industry has become for businesses, the demand for trained professionals is much greater than the supply. Anyone working with data is stretched thin to do “all things data-related” even if it steers clear in the other direction of their core responsibilities.

All of the above points require interaction with people, and in an age where data is king, trying to convince people to engage in human stuff is a bit of a sales pitch that many folks either don’t want to do or, perhaps, know how to do it at all.

Let’s look at each one in a bit more detail.

Failure to understand what the business value could and should be for the available data

Any successful endeavor needs a clear and well-articulated goal — an objective to strive for. Don’t bother even starting to create visualizations without knowing what the desired outcome is. Again, it sounds like common sense but I’ve seen it far too many times where people dive right into the data without a concise vision.

Don’t fall into this trap, the work up front is worth the payoff. Building a dashboard against a proven failed strategy is like running in place — you put in all the energy and resources and get nowhere.

Not engaging dashboard users early in the process to learn what they want from the available data

Bridging business goals, data and users together is damn hard even when done by a pro. If we are missing the user element then we have data, we have a vision but we don’t have a means to actualize it effectively. Sure, you might get lucky from time to time by not engaging users, especially if it is a small user base, but not doing so is an open invitation to add risk and poor to no user adoption.

A user has needs and it’s part of your responsibility to know what they are and build a dashboard to meet those needs.

Insufficient or ineffective communication between stakeholders, users, and the data architects

Data quality is a behemoth breathing down the neck of the analyst. It is often a burden that is unshared and uncommunicated responsibility until it is forced into the light through user interaction. Time spent as an analyst is finding and formatting the data to analyze, limiting their bandwidth to perform a thorough analysis.

While not the only reason, getting an open channel of communication between all interested parties is a mechanism to address data quality issues early and devise strategies to mitigate or improve. There’s no logical reason to not communicate.

Poorly designed dashboards and charts without a route to behavior change

Solving the three previous factors will not be an easy feat if not successfully manifested into a user interface.

Business goals, data, and user needs are all brought together in the user interface, typically resulting in a complete dashboard.

When these three variables are not accounted for it’s due to:

  • The dashboard having no connection with what the business is seeking to solve
  • The dashboard has little or no intuitive actionable outcomes for the audience to walk away with
  • The dashboard was not built with data visualization best practices in mind

The value of data visualization is rooted in early and often communication

At the end of the day, improving the effectiveness of a data visualization has nothing to do with the skills needed to build the product. Rather, it’s a balance of good communication practices that are fine-tuned over time. And because communication is not necessarily a top priority for those in the data industry, it’s a shared frustration.

And while not exactly earth-shattering or breaking news, good communication skills for many people are a learned and practiced behavior through the application of the process. Simply put, it takes time and patience. Yet, the better you get at the human-side of this process, the better and more effective your visualizations will be.

Sign up to the newsletter to receive future articles, templates and solutions to making more effective visualizations.

How to Extend Your UX Skills to Analytics UX

I’m sure everyone has heard the excitement over analytics and how sexy data science is as a career path. Though there is rarely mantion of analytics UX. Analytics is often thought of as highly technical and difficult to get into. That’s not untrue but there are still very high value opportunities that don’t require a background in stats or database design, i.e. analytics UX. Enter the Dashboard Consultant. For the UI/UX Designer, becoming a Dashboard Consultant can follow a well-defined path, as it is a path I have traveled myself and I am going to share my learnings from that journey here and what I think is an optimal path having the experience to reflect upon.

What is a Dashboard Consultant?

A blend between UI/UX, business acumen and aspects of analytics such as data visualization and surface knowledge of data structures and databases are the basic ingredients. All of which can be learned in a matter of weeks to have a basic competence, though mastery will take years. The primary focus is mapping data to business value for the end users and stakeholders. Giving them access to actionable outcomes that either positively changes behavior and/or enables direct action to be taken to improve business outcomes. The closer those outcomes come to increasing profits the better. The role of the Dashboard Consultant is fundamentally to narrow the gap between data and profit through a user interface.

What Skills Do I Need for Analytics UX?

I’m assuming you already have UI/UX Design nailed and that covers a lot as it typically extends over to business acumen. However, a major word of caution here and a lesson I had to painfully learn. Analytics can be highly political and heated. Being overly evangelical about users and UX principles can and often do inflame already volatile situations. My approach is now pragmatic and firmly based in years of experience in application of UX to analytics. For more junior UXers I advise subtly over enthusiasm as you build up your business experience.

The skills you should already have and that will be used (not exhaustive):

  • UX research, interviews, personas
  • Journey mapping
  • Wire-framing and concept design
  • Consulting expertise

All that being said, the main new skills, with an hours estimate to get a basic competence if taught by a pro, that need to be added are:

  • Data visualization best practices – 16 hours
  • Chart selection process (big part of analytics UX) – 20 hours
  • Basic, very basic, knowledge of database structures – 16 hours
  • Facilitation expertise to run the occasional workshop – 16 hours theory with 8 hours of practical application
  • UI capability knowledge of the popular dashboarding tools like QlikView, Qlik Sense, Tableau, Power BI. This is not as hard as it may sound. – 4 hours per tool
  • Optional expertise in developing in one or more of the tools – highly variable

You will note that technical tools of dashboard development are left till last and this is intentional as there are many a person that can develop dashboards, there are very few that can design them well enough to have significant business value and impact. So, if you do have the aptitude to pick up some dashboard development expertise, then well and good. It is not vital. The value is in producing the design that wins. This will be in contrast to much of the prevailing advice out there and I only speak from my own experience as a dashboard consultant, which rarely involves me developing the dashboard. If development is needed I may do it myself, usually not worth my time, or I hand the work over to other contractors or, as is usually the case, the client has their own developers already.

What’s Next?

Be sure to check out the basics of dashboard UI design.

This has been a cursory view of what is needed and there is obviously a lot of detail behind the steps above. If people are interested, I’d be happy to write more on analytics UX and go into some more background of my own journey as well as resources and materials that would constitute the 80-hour investment for such a career upgrade. Interest can be expressed as likes, comments, resharing, tweets @nicksight, etc!

Enterprise Dashboard Layout: Keeping it Simple

There are many ways to approach dashboard layout and design, but I have found value in starting with a fixed layout that enables a basic narrative for rapidly identifying if action is needed and then providing the necessary journey to understand what action is needed. The layout can then be adjusted as necessary.

The Simple Approach to Dashboard Layout

Overall layout has four areas that can largely be standardized across platforms to start making consistent user experiences irrespective if created in Tableau, Qlikview, Qlik Sense, Power BI, etc:

  • Navigation
  • Filters
  • KPIs – should I act?
  • Charts – what action should I take?

Dashboard Layout Introduction-04

How to Tell a Basic Story Through the Dashboard Layout

Let’s take a look at the ideal flow of the generic enterprise dashboard template. Opening the dashboard should land us the on home/summary tab for a specific user/persona. The journey begins by selecting the navigation tabs. From there the user scans the KPIs to get a pulse of the state of the business. Should there be any call to action needed then one of these summary charts will make it easily identifiable, typically by color. More focused exploration can happen on the other tabs of the dashboard, accessible via the navigation tabs.

Dashboard Layout Introduction-05

Should a call to action be needed, but it is not clear exactly what, then the user is visually directed to one or more of the four detailed charts either by color association and/or comments.

Dashboard Layout Introduction-01


In this example we can see the projected revenue for the week is below target. This is indicated by the kpi being orange in color. Scanning to the main dashboard area for more orange lands us on the inventory chart and we can see the stock count is only 200 but we project to sell 5,000 units.

Dashboard Layout Introduction-02

Since we have tied an action to each chart then we know to call a specific number and find out what is happening with the inventory. Do we need to ship more units or is it simply a case of the inventory count being innacurate. Either way, an action is required.

Dashboard Layout Introduction-03

With this rather simple layout of a dashboard you can see how a basic narrative can lead to powerful change. However, it may look simple in the design, but making it simple requires a lot of ground work.

In the next article we will look at the process that can get you there. Be sure to visit the Insight Burger post to see how important design thinking and the UX process is to dashboard design.

Get your own Dashboard Wireframe Kit

Take the guesswork out of wireframing and bring everyone into alignment before you start work

The all new Dashboard Wireframe Kit

Get your own Dashboard Wireframe Kit and start winning at work. Make businness impact. Stand out from your peers. Accelerate your promotion cycle.

We’re taking preorders of the Dashboard Wireframe Kit. It will be delivered US customers by the 11th June. Add a week for international folks.

Since you are a data scientist, and you have lots of money, you might as well invest in yourself, get the kit.


The Insight Burger – A Primer on Behavioural Change with Data

A burger sits before you, and a decision. To eat or not to eat. Would access to data cause a behavioural change?
What if you could see the impact of eating the burger before you ate it. Your risk of heart attack goes up .3%. Your weight will go up .1lbs by next Tuesday. And your LDL cholesterol will enter a warning range.
Why might that data make you think twice. If it was personal to you and not some average of a bunch of people. The impact is compounded as you ate a pizza yesterday and a carbonara the day before. You receive the information in a timely manner, at the point of eating the burger, not 3 weeks afterwards. The information is relevant to what you are doing, i.e. it is health and diet information. And, finally, it is actionable. Will I eat it, yes or no. The information allows for a change in behaviour.
Maybe you will look at burgers differently now, but hopefully you will see how data can help you act differently and, hence induce a behavioural change.


In the next article we will explore how this becomes manifest in an enterprise-grade dashboard and why a dilligent design process leads to increased profits.

Would you like any of these images for your slides  for presentations at work? Subscribe to the site as I send out free content that helps you win over colleagues to the power of acting on data.

Dashboard Design Process

A business dashboard is a living thing that evolves with the needs to the users and the availability and quality of the data. If you agree with this then there is a process I utilize to ensure the dashboard never dies due to stagnation, irrelevance, inaccuracy or lack of value. The dashboard design process.
Why do this though, why not just get stuck in and build right away? Sure, that can work on occasion and you might get lucky. But in the enterprise, with multiple stakeholders, infrastructure and technology costs, employee costs and other factors, any ounce of risk can have significant impact down the road. Fixing user requirement issues during development is far more costly than during design. Not to mention regaining user trust. There is very good reason why the software industry adopted UI/UX years ago, applying these techniques to analytics is common sense.
  1. Know your users and stakeholders
  2. Understand your data
  3. Wireframe the end vision
  4. Build and apply best practices
  5. Drive adoption
  6. Rinse and repeat for the living dashboard

1 Know your users and stakeholders

For a dashboard to serve the needs of the business, leadership strategy and the end users, it may seem obvious, but we need to talk to anyone who has skin in the game. A good representation from each of the following groups is advisable:
  • Leadership and business owners of the dashboard
  • End users of the dashboard
  • Custodians of the data
  • Dashboard developers
There are many ways to skin this cat but getting answers to the following questions, tweaked by role, will help understand objectives, reduce risks and gain valuable information on potential roadblocks:
  • What is your role and what do you do day to day?
  • What are your objectives and goals?
  • How can this dashboard make your life easier?
  • How do you currently access this data?
  • What are your current challenges in doing so?
  • What KPIs do you currently use?
  • What KPIs would you like to see?

2 Understand your data

The deeper you can go on this the better but even knowledge of what tables and columns are available is important. Understanding data quality is recommended but can be tackled in later iterations of the process. What is vital, however, is having the ear of someone intimate with the data as a much of the details of the state of the data can be in that persons head.
Get the database schema, as well as the schemas of any other data sources. Run through what columns have sufficient data quality for a first iteration of the dashboard. Sufficient quality is obviously subjective but it should be enough to build user confidence in the numbers. What is not of sufficient quality needs a plan devised for when it can be improved and when it can be included in later iterations of the dashboard.


3 Wireframe the end vision

It’s workshop time and this kicks off the dashboard design. With some initial conversations and interviews under the belt a significant step is to get as many of the users and stakeholders into a room as possible with the aim of agreeing what is going to be solved while surfacing any obstacles and risks. The process revolves around personas for each of the user groups. This is were you leverage the work from step 1. It’s typical to have one to three primary personas. The key here is to surface what questions each persona wants answered and how/if the data is there to answer it.
The process is certainly a tricky one when mapping these questions to a series of charts where each chart should ideally satisfy several criteria:
  • What question is it answering
  • What is the resultant action (for an example see the post on the Burger)
  • Is the data sufficiently reliable for this phase
In the past I would draw out the dashboard and charts on the whiteboards but that was a long and risk-prone activity to do with a bunch of people in the room sitting idle. I now use a series of templates I developed to rapidly accelerate the whole process.
There are many design thinking frameworks that can be leveraged for running these sessions. I use my own customized version tailored to dashboard design but here are a few resources to have a look at:
The output of the workshop is a series of dashboard wireframes aligned to personas and a plan for next steps for finalizing the wireframes and moving on to creating high-fidelity concept designs that are more closely aligned to whatever technology the dashboards will be created in (QlikView, Tableau, Power BI, OBIEE, etc.). We are not boiling the ocean here, it is ok to have a basic dashboard for phase 1 so long has it has value and is reliable and the users understand it is part of a longer journey.


4 Build and apply best practices

With the high-fidelity designs signed off and approved the development can begin. There is plenty of variation, depending on the technology being used, but all of the modern tools allow a level of customization where data visualization best practices can be applied to some degree. Depending on how precise the high-fidelity wireframes were there may be a disconnect that has to be bridged to align the design with the technology. This is where spending extra time on step 3 with a dashboard developer of the technology of your choice is wise.


5 Drive adoption

I’ve been known to say that at this point we are 50% there because this is typically where a clear role has not been defined: who owns adoption? Who is responsible for making sure the users can find the dashboard, access it, understand it, use it and extract value from it? It is this vital stage that provides the detail to seed the next breath into the dashboard. It is the conduit for feedback and that enables a richer and more valuable subsequent iteration of the solution.
The important aspects of adoption can be surfaced in a platform that enables:
  • Discovery
  • Socialization
  • Gamification
 In practice the following features are desirable:
  • Dashboard hosting
  • Support for training materials
  • Search
  • Tagging
  • Discussion
  • Rating
  • Sharing
How this manifests can be the ubiquitous SharePoint but I prefer a platform born from the fires of analytics knowledge management: Cogo. However, the platform is just one part of the story. Handling change management, training and political/people ramifications are some of the hidden dangers ready to derail if not addressed.


6 Rinse and repeat for the living dashboard

As a rule a useful practice is to release a new version of the dashboard every three month for the first year of life. I’m not talking about the data refresh velocity here, that should always be fresh. It is the velocity at which we cycle through the above dashboard design steps again, i.e. get to step 5, get 3 months of user feedback and start with step 1 again applying all the learnings. After the first year I tend to default to a revisit every 6 months depending on workloads.

The Dashboard Design Kit

A revolutionary approach to dashboard design and data visualization forged in the fires of consulting, UX, data science and data visualization. With this kit you instantly add a set of processes to enable you to combine business goals and data to achieve realistic enterprise-grade dashboards. You win, your team wins and the business wins!

For more visit dashboarddesignkit.com.