Work Understanding: Variants and best practice
Objective. Read the variants view to see the different ways the same process actually runs, so a reader can discuss a faster path as a candidate to test rather than asserting one variant is objectively 'best'.
Variants answers 'how many different ways is this process really being run, and is one of them better?' It turns a single discovered flow into the real spread of paths people take.
See it in the demo
What this screen answers
The customer question is: how consistently is this process run, and does one path outperform the others? A Sales person uses it to show that process variation is real and measurable. A CSM uses it to spot a promising path worth standardising - as a hypothesis to validate, not an order to roll out.
The task
Scope to the process and period, then read the spread of variants and how often each occurs. Look at whether a faster or cleaner variant exists and how common it is. The move is to frame a better-looking variant as a candidate best practice to test, pairing it with the detail screens that would confirm the path is genuinely better and not just faster because the cases were easier.
How to read it
Variants are discovered from captured signal, and a 'best' variant is a label you apply, not a fact the data proves. The classic misread is concluding the fastest variant is the best practice everyone should adopt - the fast cases may have been simpler, lower-complexity, or different in ways the view does not control for. Read a strong variant as a candidate to validate against complexity and quality, not a verdict.
Honest limits
The view does not prove one variant causes better outcomes, and it does not control for case complexity or quality on its own. It does not establish that a fast path is safe to standardise. Confirm with the customer what the intended path is and validate a candidate variant with a measured before/after before calling it best practice.
Interpretation check
The fastest variant is not automatically the best practice - speed may reflect easier cases, so treat a strong variant as a candidate to validate against complexity and quality.
Practical task
On the variants view for one process, identify the variant that looks strongest, write why it looks strong, and write the two checks (complexity and quality) you would run before proposing it as a best practice to validate.
Self-check
The data shows variant B is 30% faster. Should the customer standardise on it?
Not yet. Faster may mean the cases were simpler or lower quality. Treat it as a candidate, check complexity and quality, and validate with a measured before/after before standardising.
Why do variants matter in the discovery story?
They show real process variation that a hand-drawn map misses, and they localise where consistency could be improved - which is a testable hypothesis, not a proven saving.
What makes a 'best practice' label honest here?
It is explicitly a candidate to test, confirmed against complexity and quality and validated with before/after, not a conclusion drawn from speed alone.
Verified vs demo. Screen is live in the demo at /#/variants; exact controls, variant counts and figures are SME-validation-pending.