Capstone Dashboard Build and Defense

Capstone Dashboard Build and Defense

What This Lesson Asks You to Do

This capstone is your opportunity to demonstrate every skill you have built in this course. You will independently design, build, document, and defend a complete, multi-source dashboard in either Power BI or Tableau. The dashboard must answer a defined set of business questions drawn from a real, instructor-approved open-government dataset you have not worked with before. No instructor assistance is available during the build session—only published documentation and your own notes.

This lesson mirrors conditions you will face on the job and on certification exams, including the Microsoft PL-300, CompTIA Data+, and the Google Data Analytics Professional Certificate.

---

Phase 1: Plan Before You Build

Professional dashboard work always begins with a question, not a chart. Before you open Power BI Desktop or Tableau Public, read the business questions your instructor has assigned and write down, in plain language, what data fields will answer each one. Identify which tables or files you need and how they relate to each other.

Sketch your data model on paper first. Note every relationship: one-to-many, many-to-one, or many-to-many. A many-to-many relationship without a bridge table is a common source of incorrect aggregations. Resolve it before you start building.

Decide which tool you are using and commit. Switching mid-session costs time you cannot recover.

---

Phase 2: Build a Sound Data Model

Import your approved dataset and apply all needed transformation steps in Power Query (Power BI) or Tableau Prep / the data source pane (Tableau). Document every step as you go—your technical specification depends on accurate, ordered notes.

Key transformation practices:

• Remove duplicate rows and handle nulls deliberately: replace, exclude, or flag them based on business logic, not convenience.
• Set correct data types on every column before writing any measure or calculated field. A date stored as text will break time-intelligence functions.
• Rename columns to human-readable labels. Your future self and your panel evaluators will thank you.
• In Power BI, prefer a star schema: one fact table surrounded by dimension tables. Avoid bidirectional relationships unless the use case demands them and you can explain why.

---

Phase 3: Write Accurate Measures and Calculated Fields

Every number on your dashboard must be traceable to a formula. In Power BI, write DAX measures rather than calculated columns for aggregations—measures calculate in filter context, which is what most visuals need. In Tableau, use calculated fields with clearly named formulas.

Comment your formulas. A comment line above a measure explaining its business purpose takes ten seconds to write and saves minutes of confusion during your defense.

Test each measure against a known value before you move on. Cross-check a total against the raw data source. If the numbers disagree, find out why before adding more visuals.

---

Phase 4: Design Visuals That Answer the Questions

Choose chart types based on the question type:

• Comparison over time → line chart or bar chart
• Part-to-whole → bar chart or pie chart (limit pie to fewer than five segments)
• Distribution → histogram or box plot
• Relationship between two measures → scatter plot

Avoid decorative visuals that carry no information. Every visual element on the page should answer or support a business question.

Accessibility compliance is not optional. Use sufficient color contrast (WCAG 2.1 AA minimum). Do not rely on color alone to encode data—add labels, patterns, or shapes. Add alt-text descriptions to every visual in Power BI's Format pane, or provide a tooltip in Tableau. A dashboard that cannot be used by a screen reader or a color-blind colleague is incomplete.

---

Phase 5: Configure Refresh and Permissions

In your technical specification, state how often the data should refresh and why. For an open-government dataset updated monthly, a daily refresh is unnecessary; match the schedule to the source update frequency.

Document your Row-Level Security (RLS) plan in Power BI or your permission structure in Tableau. Even if your dataset does not contain sensitive personal data, naming the roles and rules you would apply shows employers you understand governance. In real deployments, exposing salary, address, or health data to unauthorized viewers is a compliance failure, not just a design error.

---

Phase 6: The Five-Minute Panel Defense

You will present your live dashboard to a two-person panel and answer three questions drawn at random. Questions may cover design choices, DAX or calculated-field logic, or refresh configuration.

Presentation tips:

• Open with the business question, not the data. Tell the panel what problem you solved.
• Walk through one visual at a time, explaining what it shows and why you chose that chart type.
• When you answer a technical question, say the formula or logic out loud; do not just point at the screen.
• If you do not know an answer, say so clearly and describe how you would find it. Guessing under pressure and being wrong is worse than an honest gap.

---

Technical Specification Document

Complete the two-page template covering: data sources (name, URL, date accessed), transformation steps in order, a data model diagram, all measures or calculated fields with full formulas, refresh schedule with rationale, and RLS or permissions plan. The specification is graded independently from the dashboard and counts toward your overall rubric score.

---

Passing Standard

The rubric has five criteria: data model correctness, measure/formula accuracy, visual appropriateness, accessibility compliance, and defense question responses. You need 80% or above overall, with no single criterion below 60%. A criterion below 60% requires targeted remediation and resubmission of that component.