Sensitive fields belong after trust is established

What it is

Sensitive fields are inputs whose leak carries identity, money, or social cost: national IDs, income, medical history, precise address, payment credentials. They should appear after people have seen a purpose and formed a minimum of trust in this form—not on the first screen because a completeness checklist says so. Trust material is a checkable identity (brand, domain, one sentence of purpose), a few low-sensitivity answers already given, and a local explanation of why this item is needed now. This entry is about where sensitive items sit in the flow. It is not about whether ordinary fields follow a lived schema, and not about wrapping address lines into a visual cluster.

Why it happens

People run a privacy calculus: perceived benefit minus perceived risk. An ID number on screen one makes risk full while benefit is still empty; closing is the rational move. After a few cheap answers, benefit becomes concrete (a quote is computing, a slot is held), and the same ID looks less costly to disclose—not because the risk changed, but because sunk answers make leaving now more expensive. A second layer is purpose visibility. When the sensitive item sits directly under “we use this to check coverage, not for marketing,” risk is pinned to one purpose. Parking that sentence in a footer or a privacy policy opened once does not enter the calculus. Placement answers “when to ask,” not where the data is stored afterward. Hiding a sensitive item in the corner of a visual group without delaying the question only postpones the fright; it does not build trust.

Studying it

Compare the same sensitive item in first, middle, and last position, crossed with presence or absence of an in-place purpose line. The task must be abandonable, or the risk judgment never shows.

Independent variables: ordinal position of the sensitive item, purpose copy in place versus only on a policy page, whether low-sensitivity items are completed first. Dependent variables: arrival and leave rate on that field, rate of refusing the item but continuing to submit, post-task rating of whether the ask felt justified, whether the policy link was opened.

Fake ID numbers in the lab blunt risk; the measure becomes annoyance, not avoidance. Use real account contexts or high-fidelity consequences (“this goes to your employer”). Do not credit a conversion lift from “fewer fields overall” to delayed sensitive items.

Where it stops holding

Regulated intake that must collect at the opening (KYC for a financial account, allergy history in triage) cannot be postponed for comfort; trust material has to share the viewport with the field rather than the field moving away. Users already signed in who just disclosed the same item in the previous task are less shocked by a repeat. On a public screen or a shoulder-surfed phone, asking later is not enough—people need masking and minimal dwell, not position. For highly privacy-sensitive groups, delay is insufficient; they need skip or supply-later.

Applying it

• Move national IDs, income, medical history, and payment credentials to after purpose is stated and at least two low-sensitivity answers exist; put one sentence of destination directly above the field, not a link to a privacy policy alone.
• If law requires collecting first, keep the position but bind issuer, encryption, and purpose into the same viewport as the box; do not show an empty field and make people hunt for the explanation.
• Sensitive items that may be skipped must not be marked required; a skip should store “not provided,” not a blank pretending to be an answer.
• Verify by isolating that field’s arrival and leave in the funnel, comparing “asked early” with “asked after the explanation.” Leave rate down but whole-form completion flat means abandonment only moved later, and purpose still never entered the calculus.

Related

• Within the group: H1.02.1 Field order should match how people already organize the information · H1.02.2 Related fields need to form a visual group
• Adjacent: O4.01 Trust signals · O1.03 Purpose limitation · H4.02 Purpose explanation
• Search terms: privacy calculus · sensitive fields · just-in-time disclosure