Checkout form field count vs Baymard checkout research (alias, address2, company/VAT, phone)

[boo-code]

Summary

The one-page checkout guest form showed 12 visible form fields before the consent checkboxes. Baymard Institute's public checkout research (https://baymard.com/blog/checkout-flow-average-form-fields) reports the industry average at 11.3 fields while "most sites need only 8 form fields in total for a checkout flow", and identifies exactly the optional-field patterns the form used.

Findings and fixes

1. Alias was the first address field a buyer met. An address-book nickname is an account concept, not a purchase field; a first-time guest has no basis for naming an address. Removed from the checkout form in Reduce the checkout address form to the essential fields #99 (the save paths already default an empty alias; the field stays in the modal and the account address book).
2. Address Complement (address2) was always visible. Baymard measured 30% of test participants coming to a stop at Address Line 2 and recommends hiding it behind a link. Collapsed behind a native disclosure in Reduce the checkout address form to the essential fields #99 (renders open when required by the address format, filled or invalid).
3. Company and VAT number were always visible. Collapsed behind one "Add company details" disclosure in Reduce the checkout address form to the essential fields #99, same keep-visible rules.
4. Phone gave no reason for asking. A translated purpose hint now renders under the field: State what the phone number is used for on the checkout form #100.

With 1-4 the default guest form shows 8 fields, matching the research target while keeping every capability reachable.

Related fixes that came out of the same audit

• No payment method was preselected for a first-time buyer (Baymard: preselect the most popular method so "the majority of users can proceed without a deliberate choice") — fixed in Preselect the first payment option when the buyer holds no choice yet #98.
• The invalid e-mail message was generic while the postcode message already stated the expected format — made adaptive in Make the invalid email error message adaptive #97.

Out of this module's scope

Baymard's delivery-selector guideline "Use 'Delivery Date' Not 'Shipping Speed'" (https://baymard.com/blog/shipping-speed-vs-delivery-date, 41% of sites fail it) cannot be satisfied by this module: the core Carrier model only carries a free-text delay string, not computed delivery dates. Left here as a Core-level enhancement candidate.

[boo-code]

Delivery/payment/country audit against the same public research — two items:

• No payment method was preselected on a fresh guest checkout (every first-time buyer faced one extra mandatory decision, and the "Please select a payment method" stop was reachable at submit). Baymard's payment-selection research (https://baymard.com/blog/payment-method-selection) recommends preselecting the most popular method so "the majority of users can proceed without a deliberate choice". Fixed in Preselect the first payment option when the buyer holds no choice yet #98 — the first option in merchant position order is selected server-side when no valid persisted choice exists.
• Delivery options show a speed string, not a date ("Delivery next day!"). Baymard's "Use 'Delivery Date' Not 'Shipping Speed'" (https://baymard.com/blog/shipping-speed-vs-delivery-date, 41% of sites fail it) cannot be satisfied by this module alone — the core Carrier model only carries a free-text delay. Core-level enhancement candidate.

[boo-code]

Validation-flow item: the guest e-mail error message was generic ("Please enter a valid email address.") regardless of what was wrong — missing @, missing domain and a missing local part all read the same, while the postcode error already stated the expected format. Baymard's error-message research (https://baymard.com/blog/adaptive-validation-error-messages — 86% of sites show generic validation messages) recommends stating exactly what is wrong. Fixed in #97 with three adaptive, translated messages plus the generic text as fallback.