Group by the dimension the user is deciding on, not by a database field

What it is

Results can be grouped on many axes: content-type id, shard, CMS channel, file extension, price, seller, condition. The axis that helps is the decision dimension currently in use to choose, not the column that is easiest to GROUP BY in the table. For shoes, grouping by size and condition serves the decision; grouping by asset_type=sku_variant or warehouse number projects an internal field as an interface category. Scatter/Gather-style methods whose features are irrelevant to the task produce clusters that hold algorithmically and fail as a choice.

Aligning with a decision dimension asks “once split, can people use this to choose,” not “can the database cluster it.”

Why it happens

Choice walks an attribute space. People compare objects on the few attributes the current task has activated—which day to fly, who ships, which version is editable. Grouping makes one attribute the primary structure of the list, which is a decision to “compare on this first.” If that attribute is an internal field (channel code, index type, a coarse language-detector tag), comparison happens in a category the user does not have: the list looks chunked, and inside each chunk they still have to rescan on the real attributes. Grouping has not reduced decision steps; it has added a meaningless heading.

Worse, a wrong primary structure suppresses the right one. Splitting “the PDF and the web page of the same report” by file type makes people look twice, once per group; their decision was “which report,” and type was only a carrier. The internal field becomes a partition, the decision dimension is torn across groups, and working memory has to stitch across the split.

Studying it

Elicit the task’s decision attributes first, then see whether the grouping axis coincides with them.

• Paradigms: an open pretest or card sort asking “what would you use to decide which row to open”; the same result set grouped by the decision axis, by an internal field, and by textual clustering, then a choice task. Retail size-versus-category-id, and enterprise project-versus-site-collection, are typical contrasts.
• Independent variables: whether the grouping field was nominated by users as a decision attribute, whether group titles use user language.
• Dependent variables: choices that can only be completed by crossing groups, rate of treating group titles as relevant categories, task steps.
• Methodological note: the “natural grouping” developers nominate is often the schema. Gold labels must come from users’ decision talk, not from the schema. The decision axis on one collection changes with the task (buy versus return versus find the invoice); one grouping cannot be assumed to serve every task.

Where it stops holding

Exploratory browsing with no clear decision attribute can use topical text clustering as a temporary axis; it need not wait for a choice dimension that does not yet exist. In regulated or professional UIs (by case number, by record type) those formal fields are the decision axis, and internal field and decision dimension coincide. Extremely mixed retrieval (files + people + messages) needs a type split in order to pick a channel first; type is then the first cut of the decision, not warehouse-number internality.

Applying it

• Before a grouping scheme, write “what would make someone pick one of two rows.” Use only nominated attributes as group axes.
• Refuse to default to type_id, channel, shard, or extension as groups. Those are secondary filters at most.
• Title groups in decision language (“other colours of this model,” “other coverage of this event”), not internal codes.
• Verify by asking someone uninvolved to complete a real choice from the group titles, then “what is this group helping you compare.” If the answer is “not sure, maybe file kind,” the axis is still a field. If they can name the choice they are making (size, seller, version), the axis has aligned.

Related

• Within the group: G3.15.1 Multiple sources of the same entity should collapse to one representative · G3.15.2 Near-identical but distinct results should be grouped, not listed side by side · G3.15.3 Grouping hides within-group differences and needs an expand path · G3.15.4 Dedup rules must be intelligible so known items do not silently vanish
• Adjacent: G1.06 Faceted classification · G3.08 Filters · G3.05 Result ranking
• Search terms: decision dimension · search result clustering · facet of choice