Tested three grids. Found a fourth.

Context

A pre-order is a big spreadsheet in disguise. For each product, the user types a quantity per size and assigns it to a delivery date. Shoes can have 14 sizes; some products come in several colourways. Multiply that by a full catalogue and every extra click becomes real time lost.

Trigger

The team had three candidate layouts for the product grid, and strong opinions about all of them. Before spending development time, I wanted evidence. Each grid organises the same three things differently: sizes, delivery dates, and the action that saves quantities to the cart.

Experiment Design

Each participant used all three grids, in a rotated order, with a different fictional dealer each time. On every grid they:

• Placed a multi-delivery order
• Edited an existing line
• Explained how they would delete a delivery

We measured time, task ease (SEQ, 1–7), satisfaction (UMUX-Lite converted to a SUS-equivalent score) and a final ranking. Participants were internal sales reps and super users, the people who lead pre-orders today. Twelve sessions were planned; seven took place.

Result

Grid A led on every measure. Everyone completed every task, so the differences are about effort and satisfaction, not success. But even the winner sat below the industry benchmark of 68. None of the grids was good yet. A was the least bad.

The twist: order mattered more than the grid

Whichever grid people saw third scored far lower, regardless of which one it was. The drop from fatigue was bigger than the gap between any two grids.

What users told us

The comments agreed more than the scores did. Four themes came up again and again:

• See every size at once. A's core strength, and the main reason people ranked it first.
• Too many Add to cart buttons. One tester kept forgetting to click. That's a risk of lost order data, not a comfort issue.
• Edit and delete on the line. C's icons at the end of each line were the most liked detail of B and C.
• Delete was confusing everywhere. People split between the cart and the delivery list. A mental-model gap no grid layout fixes.

Trade-offs & Resistance

The data, the testers and the architecture each pushed back on a clean answer.

Engineering said no to the obvious fix. Testers wanted one Add to cart for the whole page. The architects ruled it out: too many inputs to submit in one request. Auto-save per product, which they confirmed as feasible, solves the same problem without the performance cost.

What I'd do differently

• Plan for no-shows. Recruit 15 for 12 seats. Losing five sessions broke the rotation and weakened every comparison.
• Shorten the session. Three full grids per person was one too many. Fatigue became the loudest signal in the data.
• Test the edge cases. We covered 14-size shoe runs but only 4 colourways. Some catalogues have 10. The next prototype has to survive that.

Strategic Insight

Don't pick a winner. Combine what worked and fix what no grid fixed. Rather than pick a grid as-is, I proposed keeping A as the base and fixing what it did badly. Delivery selection moves out of each product into one sticky bar at the top of the page, with a running count and total. Choose a delivery once, then type.

Auto-save per product removes the per-row buttons entirely. Nothing left to forget, nothing lost.

Where it stands: in progress

The direction is with product management for a decision. Next comes one prototype, a quick test with two or three people, and iteration on that single version. Testers received a short summary of what they told us and what we're doing with it, because people who give you their time should see where it went.

Metrics are from a small qualitative study (n = 7) and indicate direction, not statistical significance. Wireframes are simplified illustrations, not product screens.