U10.02.1The chosen time window decides the trend's directiondesign

Picking which stretch of time to show can make the same curve argue either direction

Aliases: time window selection · framing window

What it is

Every time series contains both rising and falling segments, and choosing which segment to draw (start from a trough, start from a peak, show only the last three months, drop the early high point) lets the same curve support opposite trend conclusions. Window selection is technically a mandatory chart parameter (how much history to draw), but it is simultaneously a conclusion-level choice—where the window starts largely decides whether readers see "growth" or "decline." Deliberate window cherry-picking is among the stealthiest forms of selection bias, because everything on the chart is true; only "the parts not drawn" are lying.

Why it happens

The window's power comes from trend judgment's dependence on endpoints: visually judging whether a line "rises overall" relies mainly on the relative positions of the first and last points and the slope connecting them. Start at an anomalous low (a pre-promotion dip, a pandemic trough), and normal recent values naturally read as "soaring"; start at an anomalous high, and the same data reads as "steady decline." Periodicity amplifies the effect: any seasonal or cyclical series contains some starting point that makes recent performance look especially good or bad, and a cherry-picker need only scan history for the favorable window. The danger is that a chosen window is indistinguishable on the chart from an honest one—the axes, data, and rendering are identical, the only difference being the span of history covered, which surfaces only if readers actively ask "why does it start here?" Resistant design therefore cannot rely on reader vigilance; it must rely on presentation conventions: showing the ratio of window to available history ("showing the last 6 months; full history in the appendix"), declaring fixed windows ("all monthly reports uniformly show the past 24 months"), and displaying multiple windows side by side in sensitive contexts (3-year / 1-year / 3-month at once).

Where it stops holding

Window choice is not always suspect: a dashboard's default range, mobile screen constraints, and the "compare to the previous period" convention are all legitimate window rationales—the criterion is whether the window serves a stated analytical purpose and is applied consistently. Cyclic data has a technical boundary too: a window shorter than one full cycle (monthly data under a year, daily data under a week) makes trend judgment unreliable in principle, and regardless of intent, trend claims from such windows should be avoided or carry a cycle warning. Consistency is another boundary—this report starts at a trough while the last one started at a peak; the switch itself is a strong signal of window manipulation.

Applying it

  • Declare the window rule for report charts and keep it consistent across periods (fixed length, fixed alignment); when changing the window, state why.
  • Pair key trend conclusions with long-window references (3-year / 1-year / 1-quarter side by side), letting readers check the direction's robustness themselves.
  • For cyclical metrics, annotate the number of complete cycles ("covers 2 full annual cycles"); trend claims from sub-cycle windows must not be framed as long-term trends.
  • Verification: run a "window shift test" on every trend chart—move the start point by one cycle in either direction and see whether the conclusion flips; a flip means the conclusion depends on the window and must be disclosed on the chart.

Related

  • Same group: U10.02.2 Removing unfavorable data points is falsification · U10.02.3 Data range and filter conditions must be stated
  • Nearby: U7.06.1 The default time range determines the conclusion most users will see · U7.06.2 Preset ranges should cover common cycles and allow custom input
  • Search terms: cherry picking · time window bias · trend framing

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/U10.02.1