H1.12.2delete fields without a purposedesignresearch

Fields whose purpose cannot be explained should be deleted

Aliases: unjustified field · data purpose test · purpose audit

What it is

If the team cannot say who uses a filled value in which rule, which report, or which screen, the field does not belong in the current task. No purpose, delete is a purpose test, not an aesthetics test, and not “mark it optional.” Marginal leave tells you which item is expensive. The purpose test tells you which item should not have been bought. Deferral moves when you ask. Deletion cancels the ask. Purpose must name a consumer, not “we might need it for ops later” or “a fuller profile would be nicer.”

Why it happens

A field with no consumer still charges a full micro-decision and produces a record nobody reads. People use “why are you asking” to decide whether to give it; no answer, and the item becomes a trust break, not merely extra seconds. A second layer is purpose drift. The field had a consumer once (gender for a campaign). The campaign ended, the consumer vanished, the field survived because it was already on the form. The deletion rule is the current consumer, not the historical one. Items with no purpose are also the easiest to over-collect: no downstream constraint, nobody stops the next ask. The purpose test puts the burden of adding a field back on the proposer—name the consumption point before spending a chance to leave.

Studying it

Run a field-purpose audit: for each item, write the consumer (system / person / legal clause), when it is used, and what happens if it is absent. Remove items with no consumer and compare completion and downstream complaints.

Independent variables: whether the item can name a current consumer, whether the audit deletes or leaves it as optional. Dependent variables: whole-form completion, whether downstream “cannot proceed without this data” appears, ratings of whether the ask felt justified, share of new fields that pass the audit.

In interviews, business owners will call “might be useful” a consumer; ask for the last actual read. Leaving it optional is not a passed audit—that only swaps the cost of a purposeless item from required to visible. Legal clauses must point at a real article, not “compliance needs it.”

Where it stops holding

When stating the purpose to the user would expose a risk rule (a device field for fraud), the UI may stay quiet, but the internal audit must still name the consumer and ask whether silent collection would do. A genuine legal item has a consumer (that statute); it cannot be deleted, but the article and destination must be written as one sentence the user can read. Experimental fields should have an end date and drop off the main path automatically, rather than wait for the next audit.

Applying it

  • Build a purpose sheet for the current form: field, consumer, last time it was read. Delete empty rows; do not convert them to optional.
  • New fields enter the page only after this sheet is filled. “Complete profile” and “ops later” are not consumers.
  • Re-run the audit every quarter; items whose consumer has vanished leave the main path.
  • Verify by picking three items at random and asking someone outside the product to name the consumer; failure makes them deletion candidates. After deletion, watch completion; if downstream does not fail for missing data inside a stated window, deletion holds. Keep an “make it optional” control and confirm its completion lift is smaller than deletion.

Related

  • Within the group: H1.12.1 Every field carries an abandonment cost · H1.12.3 Collecting later beats collecting everything now
  • Adjacent: O1.03 Purpose limitation · O1.02 Data minimization · H4.02 Purpose explanation
  • Search terms: purpose limitation · field audit · data minimization

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H1.12.2