Prefill must remain editable

What it is

If a value the application wrote cannot be changed, prefill is coercion. Must remain editable means a prefilled input is still an ordinary editable control: selectable, deletable, replaceable with another record. What is submitted is the value when the person leaves the field, not a read-only snapshot of the profile. A field that looks like an input but is readonly, or that takes no caret on click, is locked. User override after browser autofill is override on the browser’s side. This entry is about the application not writing its own profile as untouchable. Whether the source is named, and whether the value is accurate, do not cancel this.

Why it happens

Prefill is a guess; the exit from a guess is an edit. Once locked, a stale or mismatched value has no outlet: abandon the task, or submit the wrong value. Products often lock to “keep it consistent with the profile,” which dumps the profile-update problem onto the current task: people cannot use a temporary address for this shipment. A second layer is the illusion of editability. A grey disabled state is at least honest. Worse is something that looks pressable and opens “go change the profile in Settings, then come back.” The current task is interrupted; many people quit or submit anyway. Editable also does not mean silently rewriting the profile. Submit can use this time’s value and leave the profile as it was, unless the person clearly says “use this from now on.” Binding a one-task override to a durable profile update makes people afraid to edit.

Studying it

Build a prefilled address as directly editable, readonly, and “change it in Settings.” The task is to ship to an address that is not the profile.

Independent variables: edit path (in place / read-only / outbound to Settings), whether the edit writes back to the profile, whether a second confirm “also update profile” is required. Dependent variables: whether a new address can be submitted without leaving the form, abandonment, accidental profile changes, completion time.

In the lab Settings is next door, so outbound cost is understated. Make Settings require a fresh sign-in or lose already-filled items to approach a real interruption. “Eventually submitted the right address” is not evidence of in-place edit—some people copy out, edit elsewhere, and paste back. That is a bypass of the lock, not a reason to accept the lock.

Where it stops holding

Fields locked by regulation (a legal name already verified, not changeable this time) should look read-only and explain “not this time, here is the process,” not masquerade as inputs. Computed read-only results (tax, a price from options) were never prefill and should not inherit “must be editable.” When an admin fills on someone else’s behalf, what must be editable is this submission, not necessarily the subject’s profile. A disabled field whose value still submits makes people think they edited; disabled-and-still-submitted prefill is a lock that also lies.

Applying it

• Keep prefilled fields focusable, deletable, and typeable. Do not use readonly or a missing caret to “protect the profile.”
• If this override should not write back, allow in-place edit to submit, plus an optional “also update profile” off by default.
• Legal items that can only change through another process should be clearly read-only with a pointer to that process, not fake inputs.
• Verify by changing the profile address to a temporary one and submitting without visiting Settings. Open the profile after submit and confirm it was not quietly overwritten unless the person opted in. Make the field readonly as a counterexample and confirm the current task cannot be finished in place.

Related

• Within the group: H1.09.1 Prefill cuts typing but can insert the wrong value · H1.09.2 Prefill must name its source
• Adjacent: E2.21 Read-only, disabled, and non-editable · H1.13 Smart prefill and autofill · H8.09 Edit mode versus view mode
• Search terms: editable prefill · readonly · override default