Mastering BLANK in Power BI [Part 3-2]: Solving "Ghost KPI Cards" & "Calculated Columns vs. Measures"


UX Best Practices for Data Dashboards

This guide focuses not just on numerical accuracy, but on the critical moment when "Interpretable UX" collapses.
 
Ghost KPI & Static Status: Why "Silent Numbers" Ruin Your Reports

After deploying a Power BI dashboard, have you ever received feedback like this?
  • "I selected a slicer, but the KPI card is completely empty."
  • "Sales are $0, so why does the status still show as 'Achieved'?"
Technically, the numbers within the data engine are correct. However, if a user looks at the screen and tilts their head in confusion, it’s not a data error—it’s a failure in "Interpretable UX" design.

Mastering BLANK in Power BI [Part 3-2], we will focus on two major culprits that erode report credibility: the Ghost KPI (Blank Card) phenomenon and the Static Status (Dead Column) problem. We will go beyond simple formulas to cover how to "respond kindly" to users with the COALESCE function and the practical reasons why you must use Measures instead of Calculated Columns. It’s time to breathe "living life" into your reports.

You can see previous 3-1 Part as below.

Anti Pattern vs. UX Best Practice vs. Business Value


 

1. Practical Example Data for Analysis

To help your understanding, let's assume a simple sales table with monthly Actuals and Targets.

Practical Example Data for Analysis

This data contains all the conditions that trigger UX issues:
  • Months with zero sales.
  • Stores that do not appear at all in certain months.
  • Cases where a Target exists but Sales do not.
  • Situations where calculation targets disappear depending on month/store slicer combinations.

 

2. BLANK Anti-Pattern 2: Ghost KPI Card

While using a Power BI dashboard, you change a filter and the KPI card suddenly goes empty or the status indicators act erratically. The user asks, "Is this broken, or is there just no data?" This is usually not a data error; it's a DAX design lacking a UX perspective.

2-1. The Basic KPI Starting Point

Most analysts start with this measure: Total Sales = SUM ( Sales[SalesAmount] ) Then, they place this measure onto a KPI card.

2-2. What Actually Happens on the Power BI Screen

When you place this measure in a KPI card visualization, users will see one of three types of screens depending on the filter conditions:

What Actually Happens on the Power BI Screen for total sales

1) Three Ways Power BI Responds

  • Case 1 (Normal): When a month with performance is selected, the number appears correctly.
  • Case 2 (Explicit Zero): When "Mar-26 + New York" is selected, the row exists but the value is 0, so "0" is displayed. The user understands there was no performance.
  • Case 3 (Silence): When "Mar-26 + Texas" is selected, that store has no data for that month. The SUM result becomes BLANK, and the KPI card becomes a void with no text.

2) Where the UX Problem Occurs

In Case 3, the KPI card displays a Blank with no characters. No error message appears, yet it’s not a 0—it’s a state of "nothingness."
  • Developer Mindset: "There is no data, so it's technically correct that it shows a Blank."
  • User Mindset: "Is it still loading? Is my computer slow? Or is there a system error?" Essentially, the dashboard becomes a UX that provides no clues.

2-3. Why BLANK is the Worst Choice for UX

As covered in Part 3-1, BLANK is a function that merely masks visibility without changing the underlying aggregation logic. Here, an additional UX problem is added: BLANK communicates absolutely nothing to the user. A KPI that cannot answer "Is this indicator functioning normally?" has failed its role.

2-4. Solution Strategy: Show "Intended Zero" Clearly with COALESCE

1) COALESCE is 'Consideration,' Not Just a Function

BLANK is a "no-response" that gives the user no information. You must turn this into a clear answer using the COALESCE function.

Total Sales (UX) 
    = COALESCE ( SUM ( Sales[SalesAmount] ), 0 )

By designing it this way, "0" is displayed even when data is entirely missing. This 0 is not just a number; it’s a clear message: "The system is working fine; the performance for this specific condition is simply $0."

What Actually Happens on the Power BI Screen for total sales -->Solutions using Coalesce

2) When Should You Use 0 Instead of BLANK?

  • KPI Cards: For metrics where status must be grasped instantly.
  • Trend Chart Start Points: To connect periods and prevent broken lines.
  • Month-over-Month Growth (%): To prevent calculation errors when a base value is missing.
  • When "None" itself is a meaningful state.

 

3. BLANK Anti-Pattern 3: Static Status Column

3-1. The Trap of Row-Level Judgment

In monthly performance management, it feels natural to add a 'Status' value at the row level.

The Trap of Row-Level Judgment

Especially when monthly Actuals and Targets are clear, creating a Status value via a Calculated Column seems fast, intuitive, and perfect.

Calculated Column seems fast, intuitive, and perfect

Status = IF ( 'Retail Sales'[SalesAmount] >= 'Retail Sales'[Target], "Achieved", "Failed" )

In the Data View, each row performs its role perfectly:
  • Specific stores/months are "Achieved."
  • Others are "Failed."
  • Zero-sales rows are naturally "Failed." This aligns with the goal of "recording performance against targets by period." The problem arises the moment this is placed on a dashboard for aggregation.

3-2. Problems in the Power BI Dashboard 

Suppose a user selects Q1 2026 and wants to see cumulative performance by store.

The visual includes:
StoreID, Total Sales (Measure), and Status (Calculated Column).

Aggregated Sales with Row-Level Status

Aggregated Sales with Row-Level Status

What happens when status is a column and click in Quarter 1 Slicer

The numbers are correct, but the store appears twice—once as "Achieved" and once as "Failed." The screen fails to answer the user's real question:

"Did this store meet its cumulative target for Q1?"
It is showing historical monthly fragments instead of a unified Q1 judgment.

3-3. Why is the Same Store Split into Two Rows?

Practitioners often wonder if it's their fault for looking at multiple months at once, but the user's request is valid. The problem is assigning a real-time question to a static Calculated Column.
  • Calculated Columns are row-based, static, and calculated at refresh.
  • Users want summarized, real-time results based on their current filters. The tool simply did not match the nature of the question.
Wait! Still confused about the difference between Calculated Columns and Measures?

To fully understand this phenomenon, you must first grasp the fundamental differences between the two pillars of DAX: 'Calculated Columns' and 'Measures.' Check out the link below for a 5-minute summary!

[Go to DAX Deep Dive 02: Calculated Column vs. Measure, Key Differences Every Power BI Pro Must Know] Update coming soon

The Limitations of Row-Level Judgment
A design that fixes row-level judgment results into a Column cannot capture a "summarized perspective." This is exactly why we must use Measures when creating complex business logic.

3-4. Restoring Meaning by Moving Status to a Measure


To solve this, let's move the logic from a Column to a Measure.

1) Moving the Logic to a Measure

Status =

VAR TotalSales = SUM(SalesAmount)
VAR TotalTarget = SUM(Target)
    RETURN IF(
        TotalSales >= TotalTarget,
        "Achieved",
        "Failed"
)

This measure follows one principle:

"Recalculate based on exactly what the user is seeing right now (Context)." Every judgment is made in real-time within the current filters.

2) Same Screen, Different Result: Data Integration

Correct Answer with Measure-Based Status

Correct Answer with Measure-Based Status
Correct answer with Measure-Based Status
The store is no longer split. Logical contradictions disappear. The Status is now a meaningful interpretation of the entire selected period.

3) How Measure-Centric Design Revives Interaction

  • Immediate Response: Selecting different months instantly updates the status (e.g., from "Failed" to "Achieved").
  • Consistent Logic: The measure always compares sales and targets based on any active context (Region, store group, etc.).
  • Restored Trust: Sales and Status are calculated on the same basis, ending doubts about inconsistent results.

4) Practical Tips: Enhancing Visual Intuition

Text + Conditional Formatting: Use Green for "Achieved" and Red/Gray for "Failed" for instant cognition.
Icon-Based Status: Use icons like "●" or "○" to turn values into readable sentence structures.
KPI/Card Visuals: Clearly communicate that the report reacts to the current context in real-time.

3-5. Changes Brought by Measure-Centric Design

  • Immediate Interaction: Status updates in real-time as you move the slicer.
  • Flexible Criteria: Re-evaluates based on any selected region or store group.
  • Memory Efficiency: Only calculates when viewed, keeping the model light.



 

Wrapping up


"Explainable Numbers" Trump Fancy Charts

Ultimately, a good dashboard answers the user's "Why is it like this?" before they even ask. "Do not show the user the BLANK that the engine understands; translate it into a living message through Measures."

Summary at a Glance
  • KPI Cards: Displaying "(Blank)" vs. Using COALESCE for an "Intended 0".
  • Status Logic: Using Calculated Columns for static status vs. Using Measures for real-time re-calculation.
  • Business Value: Accurate, context-aware analysis that boosts user trust.

Core Messages of This Guide:
  • BLANK is "silence" in terms of UX.
  • COALESCE is a design choice that explains the situation.
  • Status should be a re-interpretation, not a fixed value.
  • Think in Measures to make your reports come alive.

While the previous [Power BI BLANK Mastery Part 3-1] was a "design to make totals trustworthy," this [Power BI BLANK Mastery Part 3-2] is a "design to make the screen interpretable for the user."



Comments

Popular posts from this blog

DAX CALENDAR Function Deep Dive and Practical Usage Guide

Standard Deviation (Part 2): Strategic Limitations and Complementary Perspectives in Standard Deviation Analysis

Standard Deviation (Part 1): Measuring Data Volatility and Using the Insights for Better Strategy