Q2.17.4Competitor intent versus observed effectdesignresearch

Separate a competitor’s design intent from its actual effect

Aliases: design intent · observed effect · intent–effect split

What it is

When looking at a competitor, visible structure is easily read as intended purpose: a progress bar “to reduce anxiety,” forced registration “for personalization.” Intent is a guess about the designers’ aim. Actual effect is what that structure produces in use: completion, error, workarounds, and abandonment. The two often diverge. The competitor’s own marketing, awards, and UI copy are intent statements, not effect evidence. Without the split, analysis treats “looks like it solves X” as “already solved X.”

Why it happens

A readable interface invites intention attribution: the more a control is named like a goal, the more viewers treat the name as the result. Public explanations, changelogs, and marketing pages lock that attribution in. Effect depends on population, setting, and surrounding systems, which rarely appear on the publicly visible surface. A step that reduces choice may lower load, or it may eject struggling users and merely look cleaner. With no effect material, analysts stay on the intent layer and then use intent as evidence that “we should do this too.” Intent talk is often post-hoc; even the other team may never have held that goal.

Studying it

Split each competitor practice into an intent proposition and an effect proposition, then seek public material separately: help docs and release notes lean intent; store reviews, support forums, reproducible walkthroughs, and (where lawful) task tests lean effect. Coding must not fill an effect gap with an intent proposition. If only intent is available, the claim stops at “they present this as the goal,” not “the practice works.” Small replications should use one’s own target users and tasks, not the analyst’s fluent run-through as effect.

Where it stops holding

When real users cannot be reached and the product cannot be used lawfully, the effect layer may be empty; the analysis should drop to structural description. Reverse-engineering coarse metrics (ratings, downloads) cannot locate the effect of one control. Internal products with logs yield thicker effect evidence; “the goal written at launch” and “the metric after launch” still need separate columns. For deceptive or harmful design, intent and effect may align; the split is not an excuse, it prevents reading a harmful effect as unrealized goodwill.

Applying it

  • Fix two columns on every competitor card: intent (source: copy / marketing / inference) and effect (source: observable behavior / third-party reports / replication). Leave effect blank when missing.
  • Do not complete a blank effect column with “this should….” Carry the blank into the decision meeting.
  • For a practice that might be imported, run a minimal replication on your own tasks and users; record completion, error, and quit, not “what we think they meant.”
  • If someone answers “does it work?” with a slogan, require material from the effect column; otherwise the practice is not an adoption argument.

Related

  • Same group: Q2.17.1 Benchmark against similar tasks across industries, not peer products · Q2.17.2 Competitive analysis finds industry convention, not user need · Q2.17.3 Copying a competitor inherits its untested assumptions
  • Adjacent: Q2.06 Usability testing · Q3.11 Logs and instrumentation
  • Search terms: design intent · observed effect · competitor walkthrough

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Q2.17.4