Dashboards
Prerequisite Knowledge
This lecture builds on the following concepts from earlier lectures. If any feel unfamiliar, review the linked notes before proceeding.
Previously Covered in This Subject
- Sheets, dashboards, and stories — covered in Lecture 6 (6.9.3) and Lecture 3 (3.7)
- Chart selection and the chart cheat sheet — covered in Lecture 2 (2.2)
- Clutter, white space, and color with purpose — covered in Lecture 2 (2.3, 2.4)
- Storytelling and knowing your audience — covered in Lecture 3 (3.2)
- Parameters, sets, and filtering for interactivity — covered in Lecture 7 (7.2, 7.4, 7.8)
- Data types (quantitative and qualitative) — covered in Lecture 4 (4.2)
9.1 What Is a Dashboard
9.1.1 The Core Definition
The previous module ended with hands-on work in Tableau. That work covered maps with Tableau's own geocoding, the three action types (filter, highlight, and go to URL), and unique charts such as world maps, bubble charts, and waterfall charts. Everything built so far was at the level of the individual sheet. Dashboards are the next step up: you take those sheets and combine them onto one screen. Before touching the tool, it pays to be clear about what a dashboard actually is, why it matters, and what separates a good one from a bad one.
Hook: Suppose you manage a delivery team of forty people. In the three seconds between opening your laptop and taking the first sip of coffee, how would you know whether today is on track? You would need the answer without opening five different files. That instant answer is exactly the problem a dashboard exists to solve.
There is no single definition of a dashboard. The closest working description is that a dashboard is like a control panel. You bring all the key KPIs of a business — or whatever you want to measure — together at one spot, and decisions get easier to make.
Working definition. A dashboard is a visual display that brings the key information of a business or process to one place so it can be read at one glance. Four ideas build the definition:
- One place, one glance. The most important information sits together, readable at a glance, instead of scattered across files and pages.
- Tracking together. KPIs, metrics, and key data points are tracked side by side so relationships become visible.
- Aggregation from multiple sources. Data is brought in from different places, combined, and merged — a dashboard can weave several sources into one view.
- Monitoring and action. It shows historical trends and the actionable data that tells you what to do next.
The end result is a single source of truth. Everyone argues less about whose number is right, and decision-making gets faster.
When the class was asked to define a dashboard, one student gave a strong first attempt:
Q: A dashboard is like displaying visual data in one place where there are multiple charts and graphs, and we use them to drill down into things. It is quite different from a report because here we have the option to drill down more.
A: That is a very good point, and the report-versus-dashboard difference is coming up soon. There is no one right or wrong definition of a dashboard — think of it as a control panel where you bring all the key KPIs of your business, or what you want to measure, to one place. That always helps to take better decisions. Rather than flipping through multiple reports on different pages and trying to interpret data manually, a dashboard puts the key KPIs in one place so decision-making is easier.
A key piece of intuition: there is no limit to what a dashboard can look like, as long as you follow the basic principles and guidelines. There is no "right route" dashboard. The KPIs, parameters, and metrics vary because those are the things you agree on with your stakeholders. A company focused on research and development will have different dashboards from a sales-driven company. A research firm cares about R&D milestones and publication timelines; a sales company cares about orders, pipeline, and territory coverage. Same medium, completely different content — and that is by design.
Real-world: in IT service companies, delivery managers and account managers watch team use, productivity, and planned-versus-actual progress. If a project should have reached 40% by May and it is lagging, the dashboard shows that gap at a glance. Nothing needs to be asked, compiled, or argued over — the gap simply sits on the screen.
9.1.2 The Car Dashboard Analogy
The best everyday example of a dashboard is the one in a car. On a single panel you see the fuel level, the speed, the RPM, the coolant, the headlight status, and the battery status. All of these are different measurements with different purposes, and they sit together so the driver can absorb them in one glance.
Worked example — the car dashboard. Walk through what a driver actually sees, and what each gauge is for:
- Fuel level — how much driving time remains before a refill is needed.
- Speed — how fast the car is moving right now, compared with the legal limit.
- RPM (revolutions per minute) — how hard the engine is working, so the driver can shift gears at the right moment.
- Coolant temperature — whether the engine is overheating, a sign of possible damage.
- Headlight status — whether the lights are on so the driver is visible at night.
- Battery warning light — whether the electrical system is charging properly.
Each gauge answers one question, and none is "fancier" than another. The magic is not in any single gauge — it is that the right gauges were chosen and placed together on one panel. Glance once: fuel is low, speed is fine, engine is cool. The picture forms in a second.
Sense-check: the dashboard works because every gauge was chosen for the decisions a driver makes. A dashboard nobody chose gauges for is just a collection of dials.
Your work dashboard works the same way. It is not that the gauges are fancy; it is that the right gauges were chosen and placed together. In a work context, the gauges are the KPIs and metrics that the stakeholders agreed to track. There is no limit to how a dashboard should look — as long as the basic principles hold, one dashboard can look completely different from another, because the audience and the decisions differ.
Where the analogy breaks: a car dashboard is fixed hardware built once by an engineer for every driver. A business dashboard is custom-built per team, changes over time as the business changes, and its gauges can be chosen wrongly — which is why the design decisions in this lecture matter. The car analogy gives the why; the rest of this class gives the how.
This is also why dashboards matter for a data-visualization course. Individual sheets and individual reports are important, but the real strength of data visualization shows up when a good dashboard narrates the story — what we should focus on and how we are doing.
9.1.3 Dashboards in the Room — Industry Examples
Students already work with dashboards in several forms, and the examples they shared are worth studying:
Q: As a scrum master and a business analyst, I have to check team performance, so I created dashboards in Jira — how many tickets are coming in, how many are getting resolved, and we also created one for SLA breaches. In Power BI, I once created a balance scorecard for one of my teams.
A: SLA-based dashboards are among the most fundamental dashboards in the service industry. Any IT service company's support team must report the count of tickets, the age of tickets, how many are P1 and P2, how many are closed, and how many are open. That is where the power of dashboards shows: instead of showing multiple reports on multiple pages, a dashboard gives you exactly where we are — is our ticket trend growing or coming down?
Worked example — the IT service ticket dashboard. An SLA (service-level agreement) is a promise about response and resolution times, such as "critical issues are acknowledged within one hour." The support dashboard that tracks it shows:
- Ticket counts — how many tickets arrived today and this week.
- Age of tickets — how long each open ticket has been waiting; old tickets are a risk.
- Priority split — how many are P1 (critical), P2 (high), P3 (moderate), P4 (low).
- Open versus closed — whether the team is clearing tickets faster than new ones arrive.
- The trend — a line showing whether the backlog is growing or shrinking week over week.
Sense-check: one glance answers the team's daily question — are we winning or losing? If open tickets climb every week while closure stays flat, the trend line says "act now" before anyone asks.
Real-world: IT service companies typically track plan versus actuals, finances (is the project under-spending or overrunning?), bench strength, and resource utilization. Sales teams track region-wise numbers, target versus actuals, and sometimes how competitors or peers are doing. Some teams treat their dashboards as day-and-night companions — people literally paste them on their desks. Today most of these are real time and available on web portals, so printouts are no longer needed.
Caution — fundamentals still apply at dashboard level. Building the dashboard is the easy part; the earlier-class rules decide whether it works:
- Pieces must not contradict each other. A date range in one chart and a different range in the neighbour chart produces two stories on one screen.
- Clutter is the enemy, white space is a friend. Do not try to fill every nook and corner; empty space is what lets the eye rest.
- Choose the chart that fits the data. A time series belongs on a line graph, not a pie chart.
- Keep one consistent color theme. If red means something in one graph, it must mean the same in the next; use fewer colors rather than more, and elevate whatever you want to focus on.
9.1.4 What a Dashboard Does for an Organization
Think of dashboards as the magnifying glasses of the organization: you can zoom into a subdivision, a team, or a department and see what they are actually doing. In that sense, a dashboard translates the organization's strategy into objective measures and metrics. Look at a company's dashboards and KPIs, and you can read what the company's goals and strategy are. If the company is research-driven, its dashboards and KPIs will be shaped accordingly.
This pays off in three verbs. Dashboards let business stakeholders monitor (track what is happening), analyze (understand what the numbers mean), and manage (take action). The chain works like a doctor checking a patient: first the vital signs (monitor), then the diagnosis (analyze), then the prescription (manage).
Worked example — the sales review chain. A concrete walkthrough shows the monitor-analyze-manage chain in action:
- Monitor: sales are going down — the dashboard shows the trend as a falling line on a time axis.
- Analyze: zoom into sales per region to find which region performed poorly. The bar chart of regional sales highlights one weak region.
- Manage: ask why that region failed — is the right team placed there? The answer drives an action: change the team, change the target, or change the plan.
Sense-check: every step used the same data, and each step answered the question the previous step raised. Without the dashboard, step two would start from a guess.
The line of business can be anything. Finance people track finance numbers; sales people track sales; an IT program or delivery manager monitors, analyzes, and manages projects. The mechanics are the same: monitor, analyze, manage.
That is why you should design dashboards with the key SMEs and stakeholders rather than alone. Business people usually know exactly what they want to see — "I want to see this, and along with that, this." Domain experts and business owners have a clear idea, so take their input and the dashboard will serve its purpose.
Recap. A dashboard is a control panel: the right KPIs, chosen with stakeholders, placed on one screen so the organization can monitor, analyze, and manage in one glance. It is the single source of truth that replaces scattered reports — and the first step toward it is agreeing on what to show, not opening the tool.
Real-world: dashboards improve decisions and optimize processes and plans. In a world where productivity climbs and decisions move faster, one day of lost productivity is costly — we cannot afford to have information that we do not know. Looking at KPIs is how teams stay on top of that. Stock market apps, delivery-tracking portals, and cloud platform consoles all run on the same idea: key numbers on one screen, decisions in seconds.
9.2 Report versus Dashboard
The terms "report" and "dashboard" get used interchangeably all the time, yet the two serve different purposes. The class was asked to name differences, and the earlier definition discussion already supplied one good answer: dashboards let you drill down. The full comparison is worth laying out.
Hook: Why does your phone's battery percentage update every second, while your electricity bill arrives once a month as a printed statement? Both describe the same world, but at completely different speeds and levels of detail. That difference is the whole story of reports versus dashboards.
9.2.1 Many Pages versus One View
In the old days, reports were long, multi-page documents. Take payroll: a payroll report could run to hundreds of pages of employee data.
Worked example — the payroll report. A company with 2,000 employees runs its payroll report at month end. The output is a document of hundreds of pages, one row per employee, with the same fields repeated page after page: employee name, employee ID, department, gross pay, deductions, net pay, and bank details. The finance team that uses it does not read it from page one — they search it. One parameter sits on page one, another on page ten; cross-checking means flipping back and forth.
Sense-check: the report is complete — every employee is on it — but nobody can absorb it at a glance. Completeness came at the cost of overview.
Reports usually rely mostly on one set of data — they will show, for example, all the finance numbers or the financial statements. You flip through them page by page: next, next, next — one parameter on page one, something else on page ten.
A dashboard, by contrast, is a single consolidated view of multiple KPIs. It is purpose-built to place multiple metrics together so you can see the summary in one place. That is the one main difference. The advantage is immediate: you can glance through everything on one screen instead of reading many pages.
9.2.2 Scheduled Data versus Real-Time Data
Reports run at a predefined time and schedule. They are often a mix of real-time and batch data — "report as of 31 March" or a month-end report are classic examples.
Worked example — the month-end report. Finance closes the books on 31 March and runs a scheduled report of everything up to that date. The batch job processes a massive volume of transactions overnight, and the finished report is ready the next morning. Its data is a frozen snapshot — accurate as of 31 March, no matter when somebody actually reads it. The same report rerun on 15 April would still say "as of 31 March" unless the batch runs again.
Sense-check: the snapshot nature is a feature for audits — everyone reads exactly the same numbers — and a limitation for live decision-making.
So it would be unfair to say reports are always offline; but they may not always be real time. Dashboards are different: their data is more real time, coming from various data sources in real time. There are exceptions — a dashboard can also show data as of some date — but the default expectation is freshness.
Performance also differs. Reports can process a massive amount of data and take time to run; a year-end report can simply be left to its batch processing. Dashboards, however, cannot keep loading and refreshing. When we design a dashboard, we take care of the loading time and the performance up front, and we typically show data that is pre-processed or real time. A dashboard that spins for ten seconds after every click has failed — the whole point is the glance.
9.2.3 Detail versus Overview
Reports are detailed. Because the information is split across many pages, understanding takes time: you look at one parameter, jump to page ten, cross-check, and go somewhere else. When you do that, you are one level down — you are already doing the deep digging yourself.
Dashboards provide the overview. In one glance you can see the trend and spot contradictions: "my sales are growing, why is my profit going down?" The dashboard tells you where to look. Then you zoom into the details for the deeper analysis. Dashboard first, detail report second — that is the natural reading order.
The two tools differ on four practical dimensions:
| Dimension | Report | Dashboard |
|---|---|---|
| Format | Long, multi-page document | Single consolidated view, one screen |
| Data freshness | Scheduled batches, snapshots ("as of 31 March") | Real time or near real time by default |
| Level of detail | High — row-level data, every record | Summary level — KPIs, trends, aggregates |
| Typical use | Root cause analysis, audits, record keeping | Monitoring, quick decisions, spotting what to investigate |
This is not a judgment that one is better. Reports deal with massive amounts of data and can be complex; dashboards are more concise. Their purposes and aims are different, and we need both.
9.2.4 Both Are Equally Important
Q: A dashboard feels different from a report because here we have the option to drill down more.
A: That is a very good point, and it is exactly why both exist. The purpose and aim of each are different, even though we keep using the two terms interchangeably — which is the only reason this comparison matters. Reports and dashboards are equally important. When you need to zoom in and do root cause analysis, you will have to go into the detailed report. It is not that from tomorrow you should refuse to work on reports and only build dashboards. The dashboard gives you the overview; the report gives you the detail underneath.
Pitfalls — where teams trip up:
- Believing the dashboard replaces the report. It does not — the detailed report is where root cause analysis happens. Kill the report and you lose the evidence trail.
- Demanding real-time everything. Some numbers are monthly by nature (tax filings, month-end books). Forcing a real-time dashboard onto them adds cost without value.
- Loading report-style detail onto a dashboard. Rows and rows of records defeat the one-glance purpose; the dashboard should stay summary level and link out to detail.
- Using the words "report" and "dashboard" as if they were synonyms in a design conversation. The word chosen sets the audience's expectation about freshness and detail — being precise avoids building the wrong thing.
Real-world: teams routinely disagree over numbers — one department holds an Excel report, another works in Power BI, another has an MS Access or SQL report. When the organization is big, that fragmentation adds confusion. Dashboards, by placing everyone on the same data, remove that class of argument entirely.
Recap. Reports give the complete, detailed, scheduled truth; dashboards give the fresh, summarized overview. The dashboard tells you where to look; the report lets you look properly. Both remain equally important — the skill is choosing the right one for the question.
9.3 The Dashboard Data Layers and DIY
9.3.1 Three Data Layers
Hook: How long should it take for a business user to get a new report? If the answer is "three months," the reporting stack has a dependency problem. This section is about how the data flows from its sources to the screen — and about a newer model that removes the queue entirely.
Every reporting or dashboarding stack — whatever the tool — works through roughly three layers:
The three data layers. Every dashboard you will ever build sits on top of the same stack:
- Underlying tables and data sources. This is where the various data sources come in — transaction databases, spreadsheets, operational systems. The raw material lives here, in whatever shape each source keeps it.
- A prepared layer. Tables and fields get joined — into data lakes, cubes, or a prepared set where the data is cleaned and set for consumption. This is the workbench: joins happen, names are standardized, missing values get handled, and the messy source data becomes something a tool can consume.
- Consolidated views and dashboards on top. The final outcome the user sees — the polished dashboard, the published view, the KPI panel.
Picture the layers as a stack: sources at the bottom, the prepared layer in the middle, dashboards at the top. Reports do not read the sources directly; they read the prepared middle layer. That is why the same dashboard keeps working when the underlying system changes — the middle layer absorbs the change.
Increasingly there is a fourth style. Instead of handing out finished views only, teams give end users the datasets and ready-made views, and let the users build what they want themselves. That idea is called DIY, and it is covered next.
9.3.2 DIY — Do-It-Yourself Dashboards
DIY means giving end users the option to create their own reports and dashboards. The motivation is dependency: in the old model, business always depended on IT to create reports, and a request could take months because IT is busy. With DIY, a data-literate business user opens the tool, drags and drops fields, and joins tables themselves — no IT ticket needed. Real-world: Microsoft has a DIY platform that lets end users and data-savvy business users build their own reports, and Power Apps extends the same self-service idea. More people are getting data literate every year, so DIY is becoming very common.
Worked example — the five-person team. A team of five support engineers wants to see their own workloads every morning. The IT team builds one shared dashboard for the whole group, but each engineer needs a personal view. The team gives the engineers a view with ten to twenty fields — assignee, status, priority, open date, and so on. Each engineer drags the fields they care about onto their own small report: "my open tickets," "my P1s." No IT ticket, no wait — each person sees exactly the two or three numbers that tell them what to act on.
Sense-check: the same fields serve five different layouts, and nobody had to file a request. That is the whole DIY promise: the user decides, the tool does the work.
A typical arrangement: the team builds five good, polished dashboards. On top of that, business says, "these dashboards are good, but I want to look into the data myself." The team then gives them a data lake or a view with ten to twenty fields. Users drag and drop whatever they want. DIY is not a replacement for the built dashboards — those are still required. It is the layer for users who want their own drilling and analysis at a raw, deep table level.
9.3.3 Student Questions — What Counts as DIY
Q: Earlier you talked about DIY dashboards. In Jira we create some filters and based on those filters we create dashboards ourselves. Is that the same functionality you were talking about?
A: DIY is exactly the same idea — we let the end user decide what they want to see. Suppose you have a team of five. You can give each member the option to drag and drop, and they see for themselves: "I have two tickets open, I have to act on that." So instead of waiting for a published report, every morning your team can check what is against their name. You create a feature where they are not dependent on a report being published. That is a DIY. We give them ten, fifteen, twenty fields and they drag and drop whatever they want.
Q: Jira as a product gives all its users the flexibility to create dashboards as per their requirement. So is that product actually giving DIY to its customers?
A: Exactly. In the same way, when ad hoc reports or dashboards are required — say the overall monthly performance of a team — users create them by themselves. That is exactly what DIY is. Usually the niche or sophisticated dashboards that need skill are built once by the team. On top of those, if business wants to look into the data on their own, we give them a view where they can drag and drop. One note: DIY is more for people who are closer to the data. Executives and delivery heads still like to see a proper dashboard with trend analysis and performance — they are not DIY users.
Q: In Excel, there is a field called Analyze Data — we just write down a prompt and it creates some charts and graphs based on it. Can we call that DIY?
A: Yes, exactly. These days people do not want a dependency on another team to create things. Whatever tools let the end user directly see something qualifies as DIY — and almost every tool is getting smarter and allowing this feature. Excel's Analyze Data is exactly a DIY.
One doubt comes up often, and it is worth settling explicitly:
Q: If users can build their own dashboards with DIY, do we still need the dashboards the team builds? Is DIY a replacement for them?
A: No — DIY is not a replacement. The polished dashboards are still required; DIY serves the users who want to drill into the raw data themselves. Think of it as two shelves: one shelf holds the team-built dashboards that everyone needs, and the other holds the self-service data for the people who want their own digging. They coexist.
The two coexist, and the important skill is deciding when a request is a "build me a dashboard" request and when it is a "give me the data" request. Getting that call wrong wastes either the team's build time or the user's patience.
Pitfalls — where DIY goes wrong:
- Expecting executives to be DIY users. They want the polished, ready-to-read dashboard with trend analysis — handing them twenty fields and a blank canvas is not a gift.
- Giving users raw, unprepared data. DIY works when the prepared layer is clean. Letting users drag from dirty sources breeds the exact "whose number is right" arguments dashboards are supposed to kill.
- Forgetting governance. If ten people build ten private versions of "revenue," the single source of truth quietly fragments again.
- Treating DIY as free labour. The data lake or view still needs building, cleaning, and documenting — the team's work moves, it does not vanish.
Recap. Every dashboard sits on three layers — underlying sources, a prepared layer, and consolidated views. DIY adds a fourth style: hand the prepared data to the user and let them drag and drop. DIY removes the IT dependency and suits people close to the data — but it never replaces the team-built dashboard.
9.4 Benefits of Dashboards
The benefits were discussed throughout the earlier examples; here they are in one structured list, because understanding the theoretical side makes the hands-on work better later.
Hook: Picture a manager's desk on a Monday morning: a sales printout, a finance sheet, an operations update — three different documents, possibly three different numbers for the same thing. How much of the morning burns on stitching them together? Every benefit in this section is a version of that question with a better answer.
9.4.1 Better Decision-Making and Enhanced Communication
A dashboard translates a complex dataset into simple trends, patterns, or outliers at a glance. Nobody has to walk through multiple reports: give stakeholders the stats, analysis, and visuals, and anything unusual flashes on its own. Decision-making gets faster and improved, because the dashboard is also a communication tool.
Communication improves because the information is shared in a standard way. The same dashboard, the same data source, and the same interpretation go to every team. When team A has its own report and team B has a different one, disputes start; with one dashboard, everyone looks at the same number and talks the same language. Real-world: without this, one department has an Excel report, another a Power BI report, another an MS Access or SQL report. The confusion grows with the size of the organization.
The decision-making story has a structure worth keeping: the dashboard turns raw data into findings (a trend), then into priorities (this region is weak), then into actions (fix the team there). Each step is visible to everyone, so the reasoning behind a decision is not locked in one person's head.
9.4.2 Efficiency, Productivity, Streamlined Monitoring
Efficiency rises because nobody has to collect and compile data manually from various sources anymore. Executives used to sit with multiple reports spread in front of them — one for sales, another for something else — and stitch the picture together by hand. Invest once in a dashboard, and that manual work disappears. Dashboards can evolve, but you do not rebuild individual reports every cycle.
Visualize the old scene and the new one side by side. Old: a desk covered with printed reports, a highlighter, and a notepad for "reconciling" numbers that should match. New: one screen where the numbers already match, because they come from one source. The scene change is the efficiency gain.
Productivity follows: all the data sits in one central location, and every user refers to the same data source. Streamlined monitoring is the third win.
Worked example — the defect dispute. The testing team reports 42 defects; the development team says the real count is 27, because their tracking sheet counts differently. Each team argues from its own source, and the disagreement eats a meeting. The delivery manager puts both teams on one shared defect dashboard built from the single, agreed data source. Now both teams see the same 42 — or the same 27 — and the conversation moves from "your number is wrong" to "what do we do about these defects?"
Sense-check: the dashboard did not fix the defects; it removed the argument about counting them. Process streamlined, trust restored, energy redirected.
9.4.3 Storytelling and Fewer Errors
Dashboards help you tell the story with data: here is the starting point, then we did this, then that happened, and here is where we are now. That narrative structure makes data understandable. One important clarification: storytelling has no hard dependency on dashboards. Domain experts, product SMEs, and business analysts tell wonderful stories with a few PPT slides; storytelling is a much broader concept. It is also a career-long soft skill — there are courses and LinkedIn Learning resources on storytelling, and it helps in any role.
Errors and discrepancies drop because the work stops being manual.
Worked example — quarter-end midnights. Every quarter, finance and accounting teams sit through midnight hours making numbers add up. The same Excel ritual repeats: a VLOOKUP breaks when a column is inserted, a copy-paste misses a row, one step of the monthly process gets forgotten — and the whole workbook has to be redone. Each error is small; the rework and the lost trust are not.
Sense-check: once a dashboard is built, the fields selected, and the data in place, the chances of going wrong fall sharply. Wrong keyed-in data is a data-quality issue, not a reporting issue; but manual, scattered reporting is bound to have errors.
9.4.4 Transparency, Stakeholder Management, and Flexibility
Transparency increases because everyone refers to the same dashboard, the same data point, and the same version — fewer discrepancies, more trust between teams. Stakeholder management improves because you stop sending multiple reports that can go wrong or miss a correction. A dashboard makes you and your stakeholders speak the same language: instead of arguing about which data is right, you focus on addressing the problem of the project. Your red project will not become green the moment you share a dashboard — but the conversation becomes much more focused.
Flexibility and customization are the last big benefit. In the Crystal Reports era, adding or removing one field meant a round of testing to make sure nothing broke. Modern dashboards are the opposite: drag a field out, drop another in, remove one and add more. You can create personalized views, deliver to mobile and tablet, and give specific users filters that match their needs. That is what makes dashboards so easy to explore and customize compared with the fixed reports of the past.
Pitfalls — benefits, not magic:
- Sharing a dashboard does not fix a bad situation. A red project stays red — the win is that everyone now argues about the fix, not about the number.
- Mistaking the dashboard for the data pipeline. If the underlying data is wrong, the dashboard simply displays the error more prettily. Data quality is a separate, upstream problem.
- Expecting benefits without a shared source. The gains above all assume one agreed data source; keep a second unofficial workbook alive and the old disputes return.
- Over-automating small processes. A dashboard saves little if the manual ritual it replaces was already quick and reliable.
Recap. Dashboards pay off in six ways: faster decisions, standard communication, efficiency, productivity, fewer manual errors, and transparency — plus the flexibility modern tools give you to change fields in seconds. The benefits compound only when everyone reads the same source.
9.5 The Four Types of Dashboards
Dashboards come in broad categories, and different books present three or four. Here we treat four: strategic, operational, analytical, and tactical. The type is defined by the audience and the timeframe it serves, so knowing the four types is really knowing who the dashboard is for.
Hook: Before a single chart is drawn, the first design decision is: who reads this, and how often does the world change for them? A CEO and a factory floor supervisor need completely different dashboards — and both are right. The four types below are the standard answers to that question.
9.5.1 Strategic Dashboards
A strategic dashboard focuses on long-term goals. The audience is executives and senior management, and the horizon is multi-year — the industry, the company, or the group seen at the level of quarters and years. The KPIs are chosen to track progress against long-term objectives, and they are usually compared against industry benchmarks.
Worked example — the executive pair. Two executives, two strategic views:
- The CIO in the automobile industry looks at his dashboard and asks, "what is the industry standard?" If the industry is at five and we are at six, he learns something about the company's standing. The dashboard is about overall business health — not today's incident, but where the company sits on the industry curve.
- The CFO's dashboard shows the stock price of the company, the sales that are happening, and how market share compares with competitors. The picture is: are we ahead, level, or behind — on the measures the market cares about?
Sense-check: both examples compare the company against outside references (industry norm, competitors) over long periods. A number without that comparison would be meaningless on a strategic dashboard.
Strategic dashboards deal in quarterly and yearly numbers: how sales are growing, how the customer base is growing, and which way the industry is going. They also carry the projection for future business. Picture one: a title row of headline KPIs, a set of trend lines on a monthly-to-yearly time axis, a benchmark line or shaded band showing the industry norm, and minimal interaction — executives read, they do not hunt. In short: long-term goals, high-level performance metrics, and a big-picture view of the business.
9.5.2 Operational Dashboards
Operational dashboards focus on day-to-day operations. The audience is middle-level management and team leads, whose job is to make sure the unit, factory, or output does not stop. These dashboards are more real time — they show what is happening today or tomorrow, not the quarterly trend.
Worked example — the manufacturing plant. The dashboard shows what the plant is doing: the plant utilization (what share of capacity is being used), the inventory level, and the efficiency of the lines. The key is the relationships between the numbers. If inventory is coming down, that means the engineers will be sitting idle soon — a signal to act before the idle day arrives. The dashboard is watched continuously; when utilization dips below a threshold, someone responds the same hour.
Sense-check: the same inventory number that a strategic dashboard would summarize quarterly is here a live, hourly signal. Timeframe changes everything.
The operational dashboard is how you make sure the day-to-day activities stay on track: productivity, efficiency, and real-time performance at the floor level. It answers "is anything about to stop?" — like the warning lights in a car, it is built for immediate attention.
9.5.3 Analytical Dashboards
Analytical dashboards are for in-depth analysis. When something needs focus — when you already know there is an area worth investigating — the analytical dashboard is where you zoom in and dig. The audience is analysts, data scientists, SMEs, or techno-functional experts: people who know the domain and can produce findings and corrective actions. These dashboards involve a lot of filtering, exploring data across many tables and dimensions, and statistical models aimed at uncovering hidden insights.
Worked example — website traffic. "Why was my traffic low in some months, high in others? Which area caused it?" The analyst opens the analytical dashboard, filters by month, and drills into the traffic sources — search, direct, referral, campaign, social. The pattern emerges: one campaign's attribution broke in the low months. That finding supports a clear action plan: fix the tracking, reallocate the budget.
Sense-check: the analytical dashboard did not answer with a single KPI; it supported a chain of questions — filter, drill, compare — until a cause surfaced.
Worked example — UAT defect analysis. During UAT (user acceptance testing), one module or integration shows the maximum defects while everything else is smooth. The delivery manager asks why that particular module is so red. The analytical dashboard produces a module-wise breakdown — defects per module, severity, status — and the analysis may reveal that the requirements were not clear or the team did not understand what was to be done. The finding changes the plan: rework the requirements before the next cycle.
Sense-check: the dashboard zoomed into one area, surfaced the trend and pattern, and pointed to a root cause — the analytical dashboard's whole purpose.
That is the analytical dashboard: zoom into one area, find the trends and patterns, and address them.
9.5.4 Tactical Dashboards
Tactical dashboards are short term. They are specific to a particular project or department, with a start and an end, and the aim is to track progress against a deadline.
Worked example — the three-month project. "I have to finish this within the next three months." The project manager builds a tactical dashboard tracking the initiative: milestones, tasks behind schedule, budget spent to date, and remaining effort. Every weekly review compares actual progress against the plan, and the dashboard shows whether the end date is still reachable.
Sense-check: the dashboard exists for one finite goal, then retires. It is born with the project and dies with it — the opposite of a strategic dashboard that runs for years.
Tactical dashboards are typically built and used by team members or project managers, and they suit quarterly targets and critical projects just as well.
Q: The fourth type was introduced as tactical, but later in the discussion it was also described as technical. Which name is the right one?
A: The intended name is tactical — the dashboards aimed at short-term goals with a clear start and end date, such as a three-month project or a quarterly target. The word "technical" slipped in during the discussion, but the standard label for this short-term category is tactical, and that is the one to remember.
9.5.5 Comparing the Four Types
| Type | Focus | Timeframe | Typical audience |
|---|---|---|---|
| Strategic | Long-term goals, business health, industry benchmarks | Multi-year, quarterly, yearly | Executives, senior management |
| Operational | Day-to-day operations, productivity, efficiency | Real time | Middle-level managers, floor managers, team leads |
| Analytical | In-depth analysis, root-cause findings, hidden insights | On demand, when an issue needs focus | Analysts, data scientists, SMEs, techno-functional experts |
| Tactical | Short-term initiatives with a deadline | Weeks to months, quarterly | Team members, project managers |
A strategic dashboard is not going to talk about what happened today; it talks about quarterly and yearly numbers and projections. An operational dashboard exists to keep today on track. An analytical dashboard appears when a specific area demands investigation. A tactical dashboard exists to land a specific project or target by a specific date.
When to pick which: choose by the question. "How is the company doing against its long-term plan?" — strategic. "Is the floor running right now?" — operational. "Why is this one area failing?" — analytical. "Will we finish this project on time?" — tactical.
Pitfalls — mixing up the types:
- Putting real-time floor data in front of executives. Strategic readers want quarterly trends and benchmarks, not today's breakdowns — the wrong type for the audience is the wrong dashboard.
- Treating an analytical dashboard as an operational one. The analytical dashboard expects exploration and filtering; forcing an operator to run analyses under time pressure invites missed alarms.
- Forgetting the tactical dashboard is temporary. It tracks a project or quarter and then retires; teams that keep maintaining it forever waste effort.
- Calling the fourth type "technical." The standard term — and the examinable one — is tactical.
Recap. Four dashboard types, split by audience and timeframe: strategic (executives, long term, benchmarks), operational (managers, real time, keep today on track), analytical (analysts, on demand, find causes), and tactical (teams, short term, land the deadline). Know the audience first — the type follows.
9.6 Characteristics of a Good Dashboard
These are the things to keep in mind whenever you build a dashboard in the future — for this course or in general.
Hook: Two teams build the same dashboard for the same data. One is used every morning; the other is opened once and never again. The difference is rarely the tool — it is a handful of design characteristics that this section names one by one.
9.6.1 Focused and Clear Purpose
A dashboard displays exactly the information needed to take the decision or meet the objective. It is not built to please somebody or make somebody feel happy. If it is a project performance review, it must talk about the key KPIs required for that review. The purpose and target should be defined before you start, with agreement and alignment: what will this dashboard be for, and which KPIs are good to have? Then present only what is relevant to the audience.
Here is a calming thought to hold onto: building a dashboard technically is not rocket science. With the background you have, dashboarding is nothing more than drag and drop and placing fields. The real work is deciding what to present and how much to present. That is where you involve your SMEs and BAs, who can think from the stakeholder's point of view. Agree with the stakeholder on what to show before you touch the tool. Business people usually know exactly what they want to see — "I want to see this, and along with that, this" — so ask first, drag second.
9.6.2 One Screen, One Glance
Fit the dashboard on a single screen whenever possible, and avoid scroll bars. Different tools let you choose the length and width, but do not split half the information into one sheet and the rest into another. Aim to give the information in one glance, and prefer smaller, clearer widgets. If a user has to scroll or click through pages to assemble the picture, the dashboard has failed its basic purpose.
Picture the target layout: everything visible without scrolling — a title row, the headline KPIs up top, the main trend chart in the center, supporting views around it, and every widget small enough to read at a glance. The moment a viewer must scroll to find the KPI they need, the simultaneity that makes a dashboard powerful is gone.
9.6.3 Clean, Simple, and Visually Appealing
Keep the data clean and easy to understand, and make the dashboard visually appealing — these skills come with practice, not from one class. Chart selection matters. Recall the chart cheat sheet from an earlier class: for a time series, use one of the two or three time-series graphs; for shares or distributions, there are specific choices too. The guiding principles exist, but you should still discuss with stakeholders what actually helps them understand the data.
The fundamentals from earlier classes all apply at dashboard level. Do not clutter. Keep a consistent color theme — if red represents something in one graph, it must not mean something else in the graph next to it. Use fewer colors, and elevate whatever you want the audience to focus on. White space is your friend. Do not fill every nook and corner.
9.6.4 Actionable Insights
The data you present should push the audience toward action. If weak areas are emerging in an IT project review, the dashboard should highlight them: "the highest defects are in this module, so we have to focus here." You give the insight — top module with high defects, most complex module. The audience decides what to do with it. Do not paste random charts and numbers and hope; make sure the dashboard leads somewhere. A good test: after thirty seconds on the dashboard, the reader should know at least one thing they did not know before — and what to do about it.
9.6.5 Real-Time and Up-to-Date
Connect the dashboard directly to its data sources. The more real time, the better — there is no point showing outdated data to stakeholders. Freshness itself helps decision-making, because the conversation is always about now. Teams no longer ask "is this last night's number?" — the data on screen is the data of the moment, and the review conversation starts from the present.
9.6.6 Customization, Interactivity, and Accessibility
Build in customization: filters, drill-down, and the ability for the user to zoom in. In an earlier class, the action-by-highlight demo did exactly this — clicking one bar on one sheet automatically filtered the data in the sheet next to it. That kind of interactivity engages the user.
Worked example — action-by-highlight. On a dashboard with two sheets side by side — a bar chart of regional sales on the left, a line chart of monthly profit on the right — the designer sets an action: highlight or filter. The viewer clicks the bar for the South region on the left sheet. Instantly, the right sheet re-filters itself to show only the South region's monthly profit. No extra page, no new query — one click made the data answer a follow-up question.
Sense-check: the interaction turned a static picture into a conversation. The user explored instead of just reading, which is exactly what interactivity is for.
Accessibility is the next characteristic: dashboards are available on almost every portal — web pages, published on a server, on mobile. Wherever it lives, it should be easy to understand: give tooltips where possible and make legends clear so the team knows what is being presented. Think from the end user's point of view — that is the best mantra. In IT we use heavy jargon, and business users are typically not IT-savvy; decide your legends, data points, and tooltips based on who the audience is.
9.6.7 Mobile-Friendly and Storytelling
Today almost every portal offers both desktop and mobile-friendly versions of the dashboard. Mobile matters more than ever — people want to see data on the fly, and nobody logs in and sits in front of a laptop all day. Finally, do not just present data — present a story. Start with "we were here last year, we started with this, then this happened," build the narrative, and conclude with actionable insights that people can decide on.
Pitfalls — what makes a good dashboard fail in practice:
- The cluttering habit. The IT reflex of filling every free space with visuals — if a corner is empty, something "should" be there. Empty space is where the eye rests; filling it buries the message.
- Building alone. Design with SMEs and business stakeholders, not in isolation — the business people know what they want to see.
- Deciding layout before purpose. Starting with the charts and working backward to the question almost always produces a dashboard nobody acts on.
- Jargon for a non-IT audience. Legends, data points, and tooltips written for developers confuse the business user the dashboard was built for.
9.6.8 Student Questions — The Balanced Scorecard
Q: Last year I created a balance scorecard as a dashboard for the leadership — it gave visibility into what was happening for the whole year, on a yearly and monthly basis.
A: That was a strategic dashboard. The yearly and monthly views, built for leadership, fit exactly the strategic profile — long-term goals and high-level performance metrics for senior stakeholders.
Q: If you had to build that balance scorecard all over again with what you know now, would you do something different?
A: The cluttering concept — that is typically what all of us do with an IT mindset. Wherever we see a free space, we think somebody will read it — but it never happens. In our good old days, in the excitement to show more data, we probably tried to put so much information into the dashboard that it became more of a torture for the end user than help. That is absolutely fine — with time we all get smarter. Just leverage these lessons the next time you build.
Recap. A good dashboard has one focused purpose, fits one screen, stays clean and consistent, pushes toward action, stays fresh, invites interaction, and works everywhere — mobile included. Exam note: the upcoming experiential learning exercise will ask you to prepare and present a dashboard on sample data, and to explain your assumptions and your approach. Practicing the characteristics above — one screen, one glance, clean and focused — is exactly the preparation it needs.
9.7 Two Kinds of Dashboard Data
Dashboards typically display two types of data: quantitative and qualitative.
Hook: Numbers are not the only thing worth watching. The daily performance of a team sometimes shows up better in a sentence than in a bar chart — and a dashboard that ignores that is throwing away useful information.
9.7.1 Quantitative Data
Quantitative data is the most common, and it is what most dashboards use. It covers KPIs, numbers, graphs, percentages, and targets — everything measurable. Sales KPIs and finance KPIs all qualify.
Quantitative data — data that comes in numbers and can be measured. The common thread across almost all dashboards is that they primarily display quantitative measures of what is currently going on: totals (revenue this month), averages (average order value), percentages (progress toward a target), and ratios (utilization rate).
Typical quantitative measures by function:
- Sales: bookings, billings, pipeline, number of orders, order amounts.
- Marketing: market share, campaign success, customer demographics.
- Finance: revenues, expenses, profits.
- Operations and manufacturing: units produced, manufacturing time, defects, inventory levels.
- IT and web: network downtime, visitors, page hits, resolved support cases.
Within quantitative data there are also time-based metrics: quarter to date, month to month, or today. These measures anchor the dashboard in a time frame and are still quantitative. A single measure also becomes far more useful with a comparison — the same quarter last year, the budgeted amount, the forecast, or a competitor's number.
9.7.2 Qualitative Data
Some dashboards are qualitative — driven by things that cannot be measured in numbers. These usually take the form of tables, text, or lists.
Worked example — the newsletter. A team newsletter dashboard carries no KPIs and no analytical numbers. It is built from text and lists: commentary on what the team achieved this month, the highlight of the month, the highlight of the week, and a "top five team members of the month" list. The reader gets the story of the team in a minute — something a bar chart of tickets could not tell.
Sense-check: the value is real even though nothing is measured. The dashboard's job was to inform and celebrate, and lists and commentary did that better than numbers would have.
Other common qualitative items are lists of people or tasks — top customers, issues that need to be investigated, tasks that need to be completed, people who need to be contacted — and schedules with due dates and responsible owners, which are common when the dashboard supports project or process management.
Such dashboards are real and valid, though qualitative data-driven dashboards are less used than quantitative ones. Not every dashboard will qualify as quantitative, and there is no need to force numbers where they do not belong.
| Dimension | Quantitative dashboard | Qualitative dashboard |
|---|---|---|
| Content | KPIs, numbers, graphs, percentages, targets | Tables, text, lists, commentary |
| Examples | Sales KPIs, finance KPIs, time-based metrics | Newsletter highlights, top-five lists, schedules |
| Typical use | Measuring and tracking performance | Informing, narrating, managing people and tasks |
Pitfalls — kinds of data:
- Forcing numbers onto qualitative content. Turning "monthly highlights" into a made-up score destroys meaning and invites arguments about the scoring.
- Treating qualitative dashboards as less worthy. A newsletter-style dashboard is a valid, useful product — dismissing it because it has no KPI misses its purpose.
- Labelling anything non-numeric as qualitative, without checking. Data is qualitative when it cannot be sensibly measured — not merely when it happens to be text.
Recap. Dashboards display two kinds of data: quantitative (KPIs, numbers, percentages, targets — the majority of dashboards) and qualitative (tables, text, lists — commentary, highlights, top-five lists). Choose the kind that fits what the dashboard must communicate, and never force numbers where they do not belong.
9.8 Common Dashboard Mistakes
These mistakes apply far beyond dashboards — the same rules make any single slide, team update, or short presentation better. Unknowingly, the discipline seeps into your day-to-day work.
Hook: Nobody sets out to build a confusing dashboard. Yet most dashboards fail — not because the data is wrong, but because of a handful of design mistakes that this section names. Learn them here, so the failure happens on somebody else's screen, not yours.
9.8.1 Three D Categories: Design, Display, Data
Mistakes fall into three categories, all starting with D: design, display, and data.
The three D categories of dashboard mistakes:
- Design issues — a meaningless variety of chart types (put a pie here, a histogram there), unattractive visuals. The layout and the design concept should be deliberate, thought through from the user's point of view.
- Display issues — wrong color selections, wrong formatting, controls placed where they confuse.
- Data issues — incorrect data, poor data, too much abbreviation.
The three categories help you debug a failing dashboard: ask separately "is the design concept wrong, is the display wrong, or is the data wrong?" — the fix is different in each case. A color fix will not repair bad data, and a data fix will not repair a confused layout.
9.8.2 Information Overload
Information overload is the classic mistake. Think twice before placing anything on a chart, a slide, or a dashboard. Lesser is better. The underlying challenge is real: how do you fit so much information into the small space you have? And how do you show it all on one screen without losing the narrative? That is where your creativity, your domain knowledge, and your knowledge of the data come in. Every extra element you place has to earn its position: if removing it changes nothing, remove it.
9.8.3 Wrong Charts, Missing Context, Unnecessary Animation
Data-to-visualization pairing is often wrong: in a hurry, we pick the wrong chart and lose the whole purpose. Charts exist for a purpose — they are not interchangeable decorations. Research which chart fits which kind of data categorization; with practice, a time series automatically suggests a line graph. Do not just pick any chart.
Missing context and animation — two quiet killers:
- Missing context. Support graphs with commentary. Put valid labels and tooltips on everything so the user never has to guess whether a number is defects or something else. What are we presenting? Make it explicit. A number without context — "7,822" — answers nothing; "7,822 units year to date, 82% of target" answers everything.
- Animation as a myth to retire. People used to think the more animation, the happier the end user. That is not always true. Animation is not wrong in itself, but it should be used with careful intention — overdo it, and it becomes distraction; people forget what they were actually looking at.
9.8.4 Ignoring the End User
Several failures share one root cause: not thinking from the end user's point of view.
Six failures with one root cause — the end user was not considered:
- Layouts not validated. Check how the dashboard looks on mobile and on tablet before publishing. It is a simple step and usually ignored — then the layout moves and breaks when people open it in another mode.
- Overconfidence about understanding. You know the project and the technology well, but the audience may not be at the same level. Do a dry run with a colleague: "this is what I am presenting — what is your view?" Do not assume that whatever you present will be understood. Do not count on being there to explain it either.
- Accessibility ignored. Be careful with color contrast and think about audiences with limitations. Not every dashboard needs this, but understand the audience first and decide.
- Static data. The world changes fast; people see everything at the click of a button on Google. Even data as of last night may fail to excite. Make the data almost real time and keep the user engaged — the days of "this will be published once a week" are gone.
- No interactivity. Some dashboards are just placed in front of users with the assumption that people will understand. People like to take control themselves — give them filters and drill-down options so they can touch and feel the data.
- Over-building. Keep it simple. Let the user ask for something if they want it, rather than giving everything first and removing later. Adding one thing on request is fine; removing a pile of things nobody asked for is waste.
9.8.5 Lessons from Bad Dashboards
Sample dashboards that fail teach the mistakes faster than any list:
Worked example — autopsies of bad dashboards. Five failing samples, and what each one teaches:
- Too many tabs. A dashboard should not have too many tabs; the user should not have to hunt for the right one. Each tab hides the data behind a click — and the one-glance promise dies with the first tab.
- Unnecessary elements. Elements added just for the sake of having something, with no label and no purpose, leave the user unable to tell which graph to look at. It may look complicated — and be completely useless.
- Meaningless variety and clutter. A heat map with red and green, a gauge, bars — all on one screen. You do not know what to look at first. The eye has no path; the message has no voice.
- Troublesome colors. Color choices that are hard on the eyes make the dashboard painful to use. If red and green sit together as the only cues, a viewer with color blindness loses the message entirely.
- Unnecessary 3D. The same data could have been presented in a far simpler way; 3D adds nothing.
Sense-check: picture each screen — nothing says "start here," nothing says "this number is the one that matters." The common failure is not the tool; it is that every element arrived without a decision about its purpose.
These dashboards turn the audience off rather than add value. First understand what your data is; then present it simply.
Recap. Most dashboard failures come down to three D categories — design, display, data — and one root cause: ignoring the end user. Think twice before placing anything, give every element a context and a label, retire the animation myth, and let the lessons of bad dashboards do the teaching.
9.9 Best Practices
9.9.1 Know Your Purpose and Audience
Hook: You have seen the types, the characteristics, and the mistakes. The final layer is the craft: the handful of practices that turn a correct dashboard into one that is actually easy to read. Every one of them starts before a single chart is dragged onto the canvas.
Everything comes back to the same starting point: know your purpose and know your audience. A dashboard with a clear purpose and a defined audience writes itself; one without them collects random charts. Start with the decision it must support, then choose the KPIs, and only then choose the charts.
The build order that never fails. Work backwards from the decision:
- Define the decision — what will the reader decide or act on after looking at this dashboard?
- Choose the KPIs — the few measures that genuinely inform that decision.
- Choose the charts — the display that fits each KPI and the audience that will read it.
A dashboard built in this order has a reason for every element; a dashboard built "chart-first" has decorations.
9.9.2 Controlling Eye Flow
An average audience starts at the top left corner of the screen and flips through from there. That reading order is a tool: the more bold and more colorful an item is, the earlier the eye lands on it. You can absolutely control and decide how your users flip through the dashboard.
The eye-flow lever. Most readers scan a screen like a page: top left first, then across, then down — the classic Z-pattern. Bold and colorful items capture the eye earlier, so emphasis is a steering wheel, not decoration. Give your most relevant items enough attention — steer the eye with color and emphasis rather than leaving the path to chance.
Map the planned path on your own layout: the reader's eye enters top left, meets the headline KPI there, slides along the main trend chart, lands on the supporting views, and exits on the action you want taken. If any element pulls the eye away from that path, it is either misplaced or unnecessary.
Make sure titles are well aligned and in line with the overall color theme and content. Give your most relevant items enough attention — steer the eye with color and emphasis rather than leaving the path to chance.
9.9.3 Limit Views, Add Interactivity
Limit the number of views and controls. There is no need to put so many things on the dashboard that the important ones drown. Wherever possible, add interactivity to encourage exploration, and highlight whatever you want attention given to. The best dashboards are the ones that guide the eye, invite the user to touch the data, and never force the user to ask what to look at first.
Pitfalls — practices that silently fail:
- Starting with charts. "I have a nice bar chart, let me find a purpose for it" produces random collections, not dashboards.
- Trusting the audience's patience. With no deliberate eye flow, the reader scans randomly, lands on the least important number first, and leaves confused.
- Piling on views and controls. Every extra control is another place to get lost; the important numbers drown in the interface itself.
- Treating interactivity as optional decoration. Filters and drill-down are how users take control — without them the dashboard is a poster, not a tool.
Recap. Best practice in three lines: know your purpose and audience before building; control the eye flow because readers start top left and follow emphasis; and limit views while adding interactivity. Guided, touchable, and uncluttered — that is what a best-practice dashboard feels like.
Exam Guidance Summary
- Experiential learning format: once the dashboarding classes finish, you will receive sample data and will have to prepare and present a dashboard built in Tableau. You will present the dashboard along with your assumptions and your approach. That presentation is the assessment, so practice narrating the design decisions: which charts, which colors, which KPIs, and why.
- The two theory classes overlap. The characteristics of a well-defined dashboard and its design are repeated in the next class. Content from both classes counts together — do not treat them as separate topics.
- Remember the fundamentals from the earlier classes. They apply directly to dashboard work: chart selection (a time series belongs on a line graph), a consistent color theme (red must mean the same thing everywhere), and clutter versus white space. They also cover elevating what you want to focus on.
- Know the four dashboard types and their audiences — strategic, operational, analytical, and tactical. Choosing the right type for the audience is a core design decision you will need for any dashboard you build.
- Study expectation: the class continues with DIY concepts and a bit of hands-on dashboarding in the next session; the class after that is pure hands-on. Come prepared with the tool open and the theory fresh.
A quick self-test before the assessment: can you state the four dashboard types with their audiences, name the three data layers, list the characteristics of a good dashboard, and explain the report-versus-dashboard difference in one sentence each? If yes, the theory side is ready — the remaining work is practice on the tool.
Key Industry Applications
- IT services (SLA dashboards): support teams track ticket counts, age of tickets, P1 and P2 priorities, open and closed tickets, and whether the trend is growing or falling. Real-world: Jira is a common home for these dashboards, used by scrum masters and business analysts to track team performance and SLA breaches.
- Project and finance tracking: plan versus actuals, under-spending or overrunning, bench strength, and resource use are standard dashboards in IT service companies.
- Sales dashboards: region-wise numbers, target versus actuals, and competitor and peer comparison.
- Manufacturing operations: plant utilization, inventory level, and efficiency, watched in real time by floor and middle management — with falling inventory read as a warning of idle engineers.
- Executive strategy: CIOs and CFOs watch industry benchmarks, stock price, sales, and market share versus competitors on strategic dashboards.
- Analytics and QA: website traffic analysis and UAT defect analysis (module-wise breakdowns) run on analytical dashboards.
- Self-service BI (DIY): Microsoft's DIY platform and Power Apps let business users build their own reports. Excel's Analyze Data creates charts and graphs from a typed prompt, and Jira gives its users dashboard-building features out of the box.
- Dashboards everywhere: the car dashboard (fuel, speed, RPM, coolant, headlights, battery) is the everyday example; stock market apps and web portals put real-time dashboards in everyone's pocket.
- Legacy contrast: Crystal Reports showed how painful report customization used to be — changing one field meant testing; modern dashboards make changes as simple as drag and drop.
- Storytelling: dashboards support data storytelling, a skill also practiced on PPTs and taught on platforms like LinkedIn Learning.
- Data fragmentation problem: Excel, Power BI, MS Access, and SQL reports living in different departments create the confusion that shared dashboards remove.
A useful pattern to notice across all of these: the same four types keep reappearing in different industries. SLA and project tracking are operational-to-tactical; executive dashboards are strategic; traffic and defect analysis are analytical. When you enter any industry, the fastest way to understand its information needs is to ask which dashboards exist — the type tells you the audience, and the audience tells you the design.
DVI Lecture 9 notes · Dashboards
Sections Breakdown
The control-panel definition of a dashboard, the car dashboard analogy, industry examples, and the monitor-analyze-manage chain.
How reports (multi-page, scheduled, detailed) differ from dashboards (one view, real time, summary) and why both are equally important.
The three data layers every dashboard sits on, plus DIY dashboards that let end users drag and drop from prepared views.
Better decisions, communication, efficiency, productivity, monitoring, storytelling, fewer errors, transparency, and flexibility.
Strategic, operational, analytical, and tactical dashboards — split by audience and timeframe, with a comparison table.
Focused purpose, one screen and one glance, clean design, actionable insights, freshness, interactivity, and accessibility.
Quantitative data (KPIs, numbers, percentages) and qualitative data (tables, text, lists, commentary).
The three D categories — design, display, data — plus information overload, wrong charts, missing context, and ignoring the end user.
Know your purpose and audience, control the eye flow, limit views, and add interactivity.
The experiential learning assessment: present a Tableau dashboard on sample data with your assumptions and approach.
Dashboards across IT services, sales, manufacturing, executive strategy, analytics, and self-service BI.
Exam Revision Notes
Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.
What Is a Dashboard
Must-know: A dashboard is a control panel that puts the agreed KPIs in one place for one-glance monitoring; there is no single definition, and KPIs depend on the stakeholders.
⚠️ Top pitfall: Treating dashboards as just "sheets combined on a screen" — the real work is choosing the right gauges (KPIs) with stakeholders and keeping pieces consistent (date ranges, colors, chart types).
Self-check: What are the three verbs that describe what dashboards let stakeholders do?
Connects to: Section 9.2 (Report versus Dashboard), Section 9.6 (Characteristics of a Good Dashboard)
Report versus Dashboard
Must-know: Reports = many pages, scheduled batch data, high detail, for root cause analysis. Dashboards = one screen, real-time data, summary KPIs, for overview and quick decisions. Both are equally important.
⚠️ Top pitfall: Treating "report" and "dashboard" as interchangeable, or believing dashboards replace detailed reports — root cause analysis still happens in the detail report.
Self-check: Which one runs on a predefined schedule with snapshot data, and which one defaults to real-time data?
Connects to: Section 9.1 (What Is a Dashboard), Section 9.6 (Characteristics of a Good Dashboard)
The Dashboard Data Layers and DIY
Must-know: Three data layers: underlying tables/sources, prepared layer (joins, cleaned data), consolidated views/dashboards. DIY = end users drag and drop from prepared views to build their own reports; it removes IT dependency and suits people close to the data, but is not a replacement for team-built dashboards.
⚠️ Top pitfall: Believing DIY replaces team-built dashboards, or expecting executives to be DIY users — polished dashboards with trend analysis remain the executive-facing layer.
Self-check: What are the three layers every reporting stack works through, from bottom to top?
Connects to: Section 9.2 (Report versus Dashboard), Section 9.4 (Benefits of Dashboards)
Benefits of Dashboards
Must-know: Key benefits: faster decision-making, standard communication, efficiency (no manual compiling), productivity, streamlined monitoring, storytelling, fewer errors, transparency, better stakeholder management, and flexibility/customization.
⚠️ Top pitfall: Believing the dashboard itself fixes problems — a red project stays red; the win is that everyone now argues about the fix, not about which number is right.
Self-check: Name three benefits of dashboards and the single shared ingredient they all depend on.
Connects to: Section 9.1 (What Is a Dashboard), Section 9.2 (Report versus Dashboard)
The Four Types of Dashboards
Must-know: Four types: strategic (executives, long-term, benchmarks), operational (middle management, real-time, day-to-day), analytical (analysts/SMEs, on-demand, root causes), tactical (teams, short-term with a start/end date, deadlines). The fourth type is tactical — not technical.
⚠️ Top pitfall: Mixing the type with the audience: giving executives real-time floor data, or calling the short-term category "technical" instead of "tactical".
Self-check: A dashboard tracks a three-month project against its deadline — which type is it, and why not strategic?
Connects to: Section 9.6 (Characteristics of a Good Dashboard), Section 9.1 (What Is a Dashboard)
Characteristics of a Good Dashboard
Must-know: Characteristics: focused purpose agreed with stakeholders, one screen/one glance, clean and visually appealing with consistent colors, actionable insights, real-time data, customization and interactivity, accessibility, mobile-friendly, storytelling.
⚠️ Top pitfall: The cluttering habit — filling every free space with visuals, which tortures the end user instead of helping them.
Self-check: The experiential learning exercise will ask you to prepare and present a dashboard on sample data — what will you need to explain in the presentation?
Connects to: Section 9.5 (The Four Types of Dashboards), Section 9.8 (Common Dashboard Mistakes), Section 9.9 (Best Practices)
Two Kinds of Dashboard Data
Must-know: Two kinds of dashboard data: quantitative (measurable KPIs, numbers, percentages, targets; the common thread of most dashboards) and qualitative (non-numeric tables, text, lists — newsletters, highlights, top-five lists).
⚠️ Top pitfall: Forcing numbers onto qualitative content like monthly highlights, which destroys meaning instead of informing.
Self-check: Give one example each of quantitative and qualitative dashboard content.
Connects to: Section 9.1 (What Is a Dashboard), Section 9.5 (The Four Types of Dashboards)
Common Dashboard Mistakes
Must-know: Three D categories: design (chart variety, layout), display (colors, formatting, controls), data (incorrect data, abbreviations). Key failures: information overload, wrong charts, missing context/labels, over-animation, ignoring the end user (layouts, dry runs, accessibility, static data, interactivity, over-building).
⚠️ Top pitfall: Filling every free space and skipping the dry run — the audience will not understand by magic, and static data fails to excite.
Self-check: What are the three D categories of dashboard mistakes, and what single root cause do several of them share?
Connects to: Section 9.6 (Characteristics of a Good Dashboard), Section 9.9 (Best Practices)
Best Practices
Must-know: Best practices: know the purpose and audience first; build in the order decision → KPIs → charts; control eye flow (top left start, bold/colorful emphasis); limit views and controls; add interactivity to invite exploration.
⚠️ Top pitfall: Starting with charts instead of the decision, and piling on views so the important numbers drown.
Self-check: Where does an average audience start reading a screen, and what does that imply about where the most important item belongs?
Connects to: Section 9.6 (Characteristics of a Good Dashboard), Section 9.8 (Common Dashboard Mistakes), Section 9.5 (The Four Types of Dashboards)
Exam Guidance Summary
Must-know: The assessment is a presented Tableau dashboard on sample data with assumptions and approach; both theory classes count together; fundamentals from earlier classes apply.
⚠️ Top pitfall: Treating the two theory classes as separate topics — their content counts together.
Self-check: What will you present in the experiential learning assessment, besides the dashboard itself?
Connects to: Section 9.5 (The Four Types of Dashboards), Section 9.6 (Characteristics of a Good Dashboard)
Key Industry Applications
Must-know: Where dashboards are used: IT services SLA tracking, project/finance tracking, sales, manufacturing operations, executive strategy, analytics/QA, self-service BI, and consumer apps.
Self-check: Which dashboard type does UAT defect analysis belong to, and why?
Connects to: Section 9.5 (The Four Types of Dashboards), Section 9.3 (The Dashboard Data Layers and DIY)
Was this lecture useful?
BitsNotes AI Assistant
Subject Notes AssistantConfigure AI Chat
Choose how to access the chatbotSigned in as
Powered by BitsNotes — 20 messages per day. No API key needed. Want unlimited access? Use "Bring Your Own Key" mode.
Sign in to use AI Chat
Get 20 free AI messages per day to ask questions about your lecture notes. Sign in with Google or GitHub — it takes 5 seconds.
Sign In to BitsNotesSwitch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.