Q6.07.3Framework dimension overloaddesignresearch

Applying every framework dimension without product stage dilutes measurement focus

Aliases: stage-blind HEART · full-framework dashboard · dimension overload

What it is

Putting every dimension of HEART or another framework on a live report, without asking what the current stage is actually betting on, thins the focus. That is framework dimension overload. A product with no stable return yet that shows Retention, Happiness, and Task success side by side will spend the meeting rotating stories across three columns, while the only thing that can change its fate this stage may be whether the first task can be finished. Overload looks like this: the framework is full, and the decision still does not know which column to read first.

Why it happens

A complete diagram of a framework has teaching value. Once the diagram is treated as an implementation checklist, empty cells produce fill-in anxiety. Stage decides which cells have a signal now: pre-launch almost has no observation window for Retention; Adoption is still unstable in a feature-exploration period; Task success may no longer be the bottleneck in mature monetization. Hard-wiring a dimension with no window onto the dashboard gives noise the same visual weight as the real question. Attention is zero-sum: extra columns steal follow-up time from the bottleneck column, and they blur the experiment gate—any column’s rise can be told as the framework working. Overload is therefore not “knowing a bit more.” It is mistaking the framework’s coverage for the current priority.

Studying it

Sample measurement plans by stage (no stable return / first value not yet established / mature optimization), and count framework dimensions in the default view, dimensions actually cited in the meeting, and the gap between them. Larger gaps mean heavier overload. A meeting experiment also works: show the same decision-makers a “all dimensions” report and a “two dimensions this stage” report, and compare whether they can name the one problem that must move this week. Track experiments guided by overloaded plans and see whether pass reasons scatter across every dimension with no pre-declared focus.

Where it stops holding

Overload is not the claim that a stage may watch only one dimension. A mature product can watch retention and task success together, provided both have a window and a decision. Task success tied to regulation or safety does not vanish from reports because “this is a growth stage,” though it need not occupy the center of the default home. Teaching, audit, and external briefings may use the full framework diagram, so long as the default operating view still contracts by stage. The opposite of overload has its own risk: shrinking to one dimension with no restore condition slides into one-sided optimization, which is a different claim.

Applying it

  • On the framework table, mark each dimension’s stage status: primary this stage, watch only, or no observation window yet.
  • Put only “primary” on the default dashboard; fold watch columns; omit no-window columns.
  • Bind the experiment gate to the primary dimension; a rise on another dimension must not be the success story on its own.
  • Re-mark status at stage changes; do not permanently display the full poster set.

Related

  • Same group: Q6.07.1 HEART maps happiness, engagement, adoption, retention, and task success onto goals and signals · Q6.07.2 Frameworks name dimensions differently, but all require goals before metrics · Q6.07.4 A framework supplies a thinking structure; specific metrics still need product-level customization
  • Adjacent: Q6.01 Classification frameworks · Q1.09 Exploration versus confirmation stages
  • Search terms: framework dimension overload · product-stage metrics · HEART

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Q6.07.3