R4.13.1visible-surface reviewdesign

Review judges the visible interface, not internal implementation

Aliases: reviewer-visible UI · screens not source · reachable surface

What it is

A reviewer is a person with a build and a device, not a reader of the repository. What they judge is the screens they can reach: copy, prices, buttons, empty states, login walls. “We actually charge on day seven” in the server, “you can actually skip this” in a flag, “there is actually another flow” in an experiment — if the reviewer cannot walk it, it is not evidence. Call the criterion visible-surface review: the docked object is the showable interface, not the internals.

This is not the same layer as “review rules constrain interaction and copy.” That layer says rules enter the design space. This layer says what counts as evidence — only what is on a screen. Benevolent backend fairness, unseen, equals nothing.

Why it happens

Review is a remote usability check whose instruments are eyes and fingers. Source, the config console, and support scripts are not in the inspection bundle. The product therefore splits into two realities: the one promised to users, and the one visible internally. Review wires up only the first. A demo account that skips the paywall shows the reviewer a free product; the paid path never entered the criterion. A five-percent experiment hides the failing flow from whoever was not sampled, so that flow was never submitted.

The design implication: align the reachable surface with the rules, not intent with the rules. Putting fairness, price, and exit inside Settings → About → Terms, and not on the main path a reviewer will walk, is passing off internals as interface. The gate does not read the impersonation.

Where it stops holding

Enterprise apps that cannot be demoed without a login are usually asked for a demo account; “visible” then includes the screens that account can open, still not the source. Security machinery (pinning, anti-cheat) is not supposed to be shown, and this criterion does not demand that it be. Error states a reviewer cannot trigger (a payment failure that exists only in one region) may escape this pass, without changing the criterion — what users can reach later can still return in re-review or complaints. A web admin console that is not in the store bundle is not on trial under this visibility rule.

Applying it

  • Ship the submit build with debug switches that hide paywalls, permissions, or login turned off. What the reviewer gets must be the surface a normal user gets.
  • Put price, auto-renewal, cancel, and permission purpose on main-path screens, not only in the server or in email.
  • Demo accounts prepared for review must pass the same walls as real accounts. A special “reviewer, no walls” account is a different product.
  • Verify by installing the submit build on a never-signed-in device, no console. Screenshot every reachable screen and contrast it with the internal flowchart. Steps in the flow and missing from screenshots do not exist for review. Any behavior that needs the config console to explain is not showable.

Related

  • Same group: R4.13.2 Forced steps before first launch are high-risk design · R4.13.3 The cost of rejection is the release cycle, not the size of the patch
  • Adjacent: R4.07 App Store review
  • Search terms: visible-surface review · store review · reviewer-visible UI

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/R4.13.1