Copying a competitor inherits its untested assumptions

What it is

Moving a competitor’s flow, component, or copy into one’s own product moves more than the visible structure. It also installs unvalidated assumptions packed inside that structure: that users already have a certain account, will tolerate a verification step, will disclose privacy here, will retry after failure rather than quit. Those assumptions may never have been tested on the competitor’s target users, and may exist only to serve that competitor’s business model. Copying treats someone else’s premises as already true for you. The issue is not “looking at the shape.” It is installing undeclared premises into your own task flow.

Why it happens

An interface is a compressed decision: each removed step bets that the skipped check is unnecessary for this population. A competitor’s short path may depend on an existing login, a credit facility, or a support backstop—infrastructure that does not travel with the screenshot. Copiers see the short path, not the account system, legal terms, and silent failure rate that make it hold. Component libraries and demo videos bury the assumptions further: reusable pieces look like neutral parts. Once installed, later tests often compare the copied version with a less similar one, and stop asking whether the premises themselves are true. The false assumption then sits behind the protection of a finished UI.

Studying it

For each step about to be imported, write a premise list (who the user is, what they already have, what happens on failure) and test those premises on the target sample, rather than only measuring end-to-end completion. Count “premise holds,” “premise fails but the task still completes,” and “premise fails and the task fails” separately. A useful contrast is to replay the flow with the competitor’s infrastructure cut (no prior login, no credit, no support) and see which steps collapse. Collapsed steps mark non-portable assumptions.

Where it stops holding

When infrastructure is nearly identical, populations overlap, and failure costs are comparable, the risk of migrating assumptions is lower—premises should still be written down rather than skipped. Regulator-mandated steps (identity, two-factor) are not one competitor’s private bet; copying those steps does not inherit the same class of risk. A complete premise list is visibility, not truth. Default flows in open-source or template projects carry their authors’ setting as well; they are not more neutral because they are free.

Applying it

• Before importing a competitor step, write three lines: what the user is assumed to already have, what the step is betting, and what the user does if the bet loses.
• Walk the copied path from the target user’s real start state (logged out, no ID, weak network) and record where it breaks.
• Steps that fail premise checks do not ship under “match the competitor first”; either validate them or decompose them under your own constraints.
• In review, hold screenshots against the premise list; items that match visually with a blank premise column go back.

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.4 Separate a competitor’s design intent from its actual effect
• Adjacent: Q2.08 Cognitive walkthrough · Q1.01 Framing research questions
• Search terms: unvalidated assumption · copycat design · migrated premises