The account area is part of the conversion system.
Why order history, tracking, security, and returns should be designed as retention and trust journeys—not administrative pages.
TL;DR
Summary
Ecommerce teams optimize the path to purchase, then often treat the account area as administration. That is a category error.
- Treat the account area as a service journey.
- Lead with product, status, and the next action.
- Measure task success before claiming revenue impact.
What happened
Baymard Institute published a major update to its Accounts & Self-Service UX research on 9 September 2026. The work adds mobile observations and revisits a field it last studied at scale in 2018.
Baymard reports more than 4,000 hours of new research, 1,400+ usability issues observed during testing, a complementary survey of 1,000+ US adults, and 57 new or updated guidelines. The public article focuses on security and sign-in, order management and tracking, and returns.
- research hours
- 4,000+
- observed issues
- 1,400+
- surveyed adults
- 1,000+
- updated guidelines
- 57
Source-reported totals for the overall research program, not the sample for every individual finding.
Users arrive with a job—not a desire to manage an account.
A customer opening an account area usually wants one answer: Where is my order? Can I change it? Which version did I buy? Can I return it? When will I receive the refund? Is my saved payment information secure?
Yet the interface is often organized around order IDs, internal statuses, generic “View details” controls, or policy documents. That structure reflects the merchant's records instead of the customer's intent.
In one Baymard example, a participant opened four orders to find a previously purchased item because the list exposed only order numbers and dates. In another, tracking omitted the expected delivery date, forcing the participant to search the carrier site for the answer.
Open imageOrder contents hidden behind collapsed records
Open imageProduct identity appears only after opening an order
Observed interface example
A record-first list hides the information needed for recognition.
Baymard reports that one participant opened four orders before finding the product she wanted to buy again.
Record-first
Task-first
Oak desk lamp · Black
Delivered 09 September
- Product identity
- Current status
- Expected date
- Relevant action
Why a task-first account experience works
01
Recognition over recall
Product thumbnails and names let users recognize a purchase. Order numbers ask them to remember an arbitrary reference—or inspect several records.
02
Answers before activity
Tracking should lead with the expected delivery answer, then expose the carrier events that support it.
03
Explain the boundary
When an action is unavailable, say why. A missing return button creates doubt about whether the user is even in the right place.
04
Control protects trust
Security and refund choices should make users feel protected—not steered, trapped, or forced to contact support.
Open imageMerchant tracking view without the answer users seek
Open imageCarrier page makes the expected date explicit
Observed interface example
Tracking activity is not the same as a delivery answer.
The merchant view exposes events, while the carrier view answers the user's primary question: when should the order arrive?
Design principle
The interface should confirm that the user is in the right place—even when the answer is no.
Conversion is a loop, not a receipt.
The conventional funnel ends at purchase. For repeat commerce, a more useful model continues through fulfilment, use, service or return, trust, and the next purchase.
The account area could affect customer effort, support demand, buy-again behavior, and retention. Those effects should be measured—not assumed. Faster task completion proves that the interface works better; it does not automatically prove that revenue increased.
Purchase
Fulfilment
Self-service
Trust
The account area sits between fulfilment and the next purchase. It is where customers decide whether the relationship still feels clear and fair.
Task success
Can users identify an order and act without leaving the merchant site?
Support demand
Which contacts exist only because the interface failed to explain state?
Repeat behavior
Does clearer history make known products easier to buy again?
Trust & retention
Does the post-purchase experience make the next purchase feel safer?
Strong usability evidence. No public revenue claim.
The source describes a large ecommerce research program combining qualitative usability observations with a quantitative survey, including retesting and updating earlier findings. That gives the identified problems more weight than a heuristic review alone.
The public article does not isolate the conversion or retention uplift of individual remedies. The survey population is US-based, and merchant category, order frequency, return policy, and account sensitivity can all change the appropriate design.
Evidence boundary
The research supports the presence of usability problems and observed user behavior. Any effect on conversion, revenue, or retention remains a hypothesis until measured in the product where the change is made.
Open imageNo return action or eligibility explanation in the order list
Open imageOpening the details still does not explain the boundary
Observed interface example
A missing action does not explain whether the return window is closed.
When the return action disappears without a status or date, users may search policy pages or contact support to understand what happened.
What I would test next
Experiment 01
Recognizable order cards
Showing product identity, status, and the next relevant action will help repeat customers complete self-service tasks with less effort.
- Change
- Replace order-number-first collapsed rows with product-led summaries.
- Primary metric
- Successful self-service task completion
- Secondary metrics
- Time to action · unnecessary order opens · support contacts · buy-again rate
- Audience / segment
- Customers with two or more completed orders
- Potential risk
- More visible information can make mobile lists dense. The hierarchy must stay compact.
Experiment 02
Closed return state
Explaining return ineligibility inside the order will reduce uncertainty compared with silently removing the return action.
- Change
- Show “Return window closed on [date]” with a short explanation and contextual help path.
- Primary metric
- Return-related support contacts per ineligible order
- Secondary metrics
- Repeated navigation · time to resolution · customer effort · next purchase
- Audience / segment
- Customers viewing an order outside the return window
- Potential risk
- A prominent help path may increase contact volume even if it improves clarity.
Experiment 03
Delivery answer first
Leading with the latest expected delivery date will improve tracking success without forcing users to leave for the carrier site.
- Change
- Show expected date and confidence state before carrier, progress, and subevents.
- Primary metric
- Tracking completion without leaving the merchant site
- Secondary metrics
- Carrier-site exits · support contacts · repeat tracking visits
- Audience / segment
- Customers with an in-transit order
- Potential risk
- Merchant and carrier estimates can disagree. The source and timestamp must be visible.
The sale is not the end of conversion. It is the start of the evidence.
Customers use the post-purchase experience to decide whether buying again feels safe.