Interactive Reporting and User Experience Questions

Design dashboards with appropriate interactivity: filters, drill-downs, tooltips, and bookmarks. Balance flexibility with simplicity; avoid analysis paralysis from too many filters. Understand how to guide users toward insights through progressive disclosure.

EasyTechnical

78 practiced

What are tooltips in the context of dashboards and what are five practical best practices for designing tooltips that help users interpret visualization points without overwhelming the view? Provide examples of content to include and content to avoid in tooltips.

MediumTechnical

83 practiced

Conditional formatting and alerts can help surface anomalies but also cause 'alarm fatigue'. Propose UX rules and implementation strategies for conditional formatting that minimizes false alarms, supports user trust, and remains actionable when used across many visuals.

Sample Answer

Situation: Dashboards use conditional formatting and alerts to surface anomalies, but excessive or noisy signals create alarm fatigue and erode trust.

Proposal (UX rules + implementation strategies):

1. Signal hierarchy and severity levels- Define discrete severity tiers (info, warning, critical) with distinct visual encodings (color, icon, border) and prioritized notifications.- Only escalate to interruptive channels (email/SMS/push) for critical tier.

2. Precision over verbosity- Use threshold windows (e.g., sustained deviation over N periods or statistical significance) before flagging.- Support both absolute and relative thresholds (e.g., >$10k loss OR 20% drop vs. prior week).

3. Contextualized alerts- Show trending sparkline, recent baseline, sample size, and confidence (p-value or z-score) in the tooltip/panel so users can judge signal quality.- Include root-cause hints (related metric correlations) when available.

4. User control and personalization- Allow users to tune sensitivity per metric (rolling window, threshold, smoothing) and mute/subscribe to channels or time windows (quiet hours).- Provide role-based defaults: executive dashboards show high-level criticals only; analysts get lower-level noisy signals.

5. Explainability and audit trail- Record why an alert fired (data values, rule) and who changed thresholds. Surface false-positive feedback option to improve rules.

6. Aggregate and dedupe- Group related alerts into digestible summaries (e.g., “Payments: 3 related anomalies”) and collapse duplicates across visuals to avoid repetition.

7. Progressive disclosure & affordances- Keep visuals clean: use subtle accents (light tint, thin border) for low-severity; reserve bold color fills for critical issues. Clicking expands to detail view with history and actions (acknowledge, assign, create ticket).

Implementation notes:- Implement server-side detection that evaluates rules centrally (consistent across visuals) and publishes alert metadata to the front end.- Use statistical methods (EWMA, seasonality-adjusted z-scores) to reduce spurious detections.- Provide telemetry: track user responses to alerts to refine default thresholds using feedback loops.

Example:- Sales dashboard: only flag a "warning" if daily sales drop >20% AND below 95% of 28-day moving average for 3 consecutive days; escalate to "critical" and notify ops if concurrent drop in transactions and payment failures >2%.

Outcome: fewer false positives, clearer prioritization, greater trust, and actionable alerts tailored to roles and workflows.

MediumTechnical

68 practiced

In Power BI, write a DAX measure (no need to run code) that calculates the rolling 7-day average of daily active users (DAU) given a table DailyMetrics(Date, ActiveUsers) and a proper Date table. Explain any assumptions and how your measure handles missing dates.

Sample Answer

Assumptions:- There is a proper Date table named 'Date' with a column Date[Date] marked as the model date table.- Relationship: Date[Date] (one) → DailyMetrics[Date] (many).- "Rolling 7-day average of DAU" means the average of ActiveUsers for the current date and the previous 6 calendar days.- Clarified treatment of missing dates: I'll provide two options — (A) treat missing dates as zero (useful when no activity = 0) and (B) ignore missing dates (average only available days).

A) Rolling 7-day average, treating missing dates as zero:

Rolling7DayAvg_DAU_Zero =
VAR EndDate = MAX('Date'[Date])
VAR WindowDates = DATESINPERIOD('Date'[Date], EndDate, -6, DAY)
VAR SumActive = 
    CALCULATE(
        SUM(DailyMetrics[ActiveUsers]),
        WindowDates
    )
RETURN
DIVIDE(SumActive, 7, 0)

Explanation: Sum active users over the 7-calendar-day window then divide by 7. Missing DailyMetrics rows for some dates are treated as 0 because SUM only sums existing rows; dates without rows contribute 0 to the sum. Use DIVIDE to avoid division-by-zero.

B) Rolling 7-day average, ignoring missing dates (average over days with data):

Rolling7DayAvg_DAU_OnlyDays =
VAR EndDate = MAX('Date'[Date])
VAR WindowDates = DATESINPERIOD('Date'[Date], EndDate, -6, DAY)
VAR AvgActive =
    AVERAGEX(
        WindowDates,
        VAR d = [Date]
        RETURN
            CALCULATE( SUM(DailyMetrics[ActiveUsers]), 'Date'[Date] = d )
    )
RETURN
IF( ISBLANK(AvgActive), 0, AvgActive )

Explanation: AVERAGEX iterates each date in the 7-day window and computes the sum of ActiveUsers for that date (0 if none). AVERAGEX then averages across only those dates in WindowDates — but if you want to exclude days with no rows entirely, wrap the inner calculation to return BLANK() when there is no data, and AVERAGEX will skip BLANKs.

Notes on missing dates:- Option A gives a true calendar rolling average (denominator always 7), appropriate when missing = zero.- Option B can be adjusted to exclude empty days; decide based on business semantics.- Both rely on the Date table to ensure continuous calendar coverage and correct windowing across gaps, months, and leap years.

HardTechnical

122 practiced

You are leading a cross-functional stakeholder workshop to define filtering, navigation, and default behaviors for a new cross-functional dashboard. Outline the agenda, artifacts you will produce (e.g., persona maps, interaction matrix), facilitation techniques to prioritize requirements, and how you'll validate and sign off on the final decisions.

EasyTechnical

78 practiced

Define 'progressive disclosure' in the context of interactive BI dashboards. Describe a concrete example (including which controls and visuals you'd show first vs. on demand) for a sales operations dashboard intended for both executives and analysts. Explain how progressive disclosure reduces cognitive load and how you'd document the pattern for designers and engineers.

Sample Answer

Progressive disclosure is a UX pattern that surfaces only the most relevant information and controls up front, while hiding advanced options or detailed visuals until the user requests them. In BI dashboards it prevents overwhelming users with complexity, letting different audiences (executives vs analysts) get the right level of detail from the same dashboard.

Concrete example — Sales Operations dashboard:- Default (visible to all on first load): - Top KPIs: Total Revenue, Bookings, YoY growth (big numeric tiles) - High-level visuals: Revenue trend line (last 12 months), Regional heatmap - Primary filter bar: Time period selector, Region selector, Business Unit dropdown - Quick insights callout (top 3 anomalies)- On-demand (collapsed panels, drilldowns, or tabs for analysts): - Expanded cohort table with customer-level rows, margin and ARPU - Advanced filters: Product SKU multi-select, sales rep, channel, contract type - Statistical visuals: Waterfall, cohort retention chart, regression summary - Export and SQL/query editor access

How it reduces cognitive load:- Minimizes choices and visual noise initially, so executives can scan key metrics quickly.- Prevents “filter paralysis” by showing only primary slicers; analysts can reveal advanced filters when doing deep-dive work.- Supports progressive mental models: users build context with summary then explore details, reducing memory and attention demands.

Documenting the pattern for designers and engineers:- Create a pattern spec with: - Wireframes for default vs expanded states, accessibility notes, responsive behavior - A decision matrix describing which controls/visuals are default vs on-demand and the audience rationale - Interaction rules (e.g., click KPI to open focused drill panel; deep-link URL state for shared views) - Data and performance constraints (pre-aggregations for default load, lazy-loading for on-demand queries) - Acceptance criteria and QA checklist (load times, state preservation, user permission gating)This ensures consistent implementation across Tableau/Power BI/Looker and aligns design, data, and engineering decisions.

Unlock Full Question Bank

Get access to hundreds of Interactive Reporting and User Experience interview questions and detailed answers.

Join thousands of developers preparing for their dream job.