Grain should match the user’s expertise

What it is

Support can work with three bands: tone, length, whether to compensate. Legal wants “introduce no new facts, keep the jurisdiction clause number, passive voice.” Spreading legal’s set onto support turns a generate tool into specialist software that has to be learned; spreading support’s three bands onto legal keeps people off the dimensions that actually change the artifact. Expertise-matched control grain asks that the resolution of adjustable dimensions follow people’s ability to tell those dimensions apart on this task: if they can tell them apart, they must be able to tune them; if they cannot, tuning is noise.

It assumes control already exists. It is not diagnosing retry-only. It also does not require that one person be able to switch back and forth between coarse and fine — that is another product decision. Here the demand is only that the dimensions in front of this person are discriminable for this person.

Why it happens

A control dimension is control only when someone can map “tune this” onto “that part of the artifact will move.” Otherwise it is ritual. An expert’s perception has already sliced the task into many independently tunable axes; a novice’s perception still has those axes stuck together, grasping only “good or not,” “long or not.” Spreading expert axes too early, novices cannot build the mapping and will twist at random or give up. Handing novice axes to experts, experts feel their hands tied and go write long prompts around the controls — the controls failed to offer them their grain.

Mismatch has a social layer too. Frontline staff given expert controls are treated as “you should know this”; training cost and mis-operation rise together.

Studying it

First, with cards or think-aloud, measure how many dimensions two groups can independently name on the task. Then build the UI at fine, medium, and coarse, crossed with the two groups. Dependent variables: share of dimensions used correctly (tuning X moves the artifact on X and not on other axes), unstrategic twisting, bypassing controls with long prompts, subjective “are these knobs for me.” Independent variables: whether dimension names use that group’s jargon, whether there is a live preview.

The gold standard is the axes each group can name. Do not judge “they didn’t use them all” against the designer’s list. Unused may be the match working: extra axes were never theirs.

Where it stops holding

The same person has different expertise on different tasks: someone who writes code is a novice on legal text. Match task expertise, not job title or account tier glued on at random. People with no expertise on the task at all may still find the coarsest grain too fine, and should fall back to examples or a human. For accessibility, “can tell apart” is limited by input method; grain must also match operable step size, not only concepts. This entry does not treat the product strategy of too many dimensions turning the tool into specialist software. It treats whether the person in front can discriminate the axes in front.

Applying it

• Name controls with words that role actually speaks, in a count no larger than the axes they can list independently on cards. Extra axes go under More, not on the main path.
• Do not dump expert-fine axes into the novice default. Grow fine axes from role, recent tasks, or “I tune these often,” rather than one global Advanced switch for everyone — unless you have separately decided to build switching.
• Every axis must preview: twist it, and the matching place on the artifact moves. Delete axes that do not move.
• Check: support and legal each do the same class of document. If support facing a legal-grade ban list twists at random or quits, grain is too fine; if legal facing three tone bands starts writing long prompts around them, grain is too coarse. Main-path axes should sit inside the list they named in advance.

Related

• Same group: L2.06.1 Output must be directly editable · L2.06.2 An interface that only offers retry is an interface with no control
• Nearby: L2.04 Complementarity of Parameter Controls and Natural Language · L2.13 Control Granularity and Editability · L2.03 Examples and Template Guidance
• Search terms: expertise-matched control grain · perceptual control axes · role-appropriate parameters