Horizen
Alle designprincipper

Adfærd

Doherty Threshold

Når et system svarer på under 400 millisekunder, holder brugerens opmærksomhed sammen. Bliver svaret langsommere, falder fokus fra hinanden, og oplevelsen med det. Doherty-grænsen er grunden til, at hastighed ikke er en luksus, men en del af selve brugsoplevelsen.

Hvor grænsen kommer fra

Walter Doherty og Arvind Thadani målte hos IBM i 1982, hvordan svartider påvirkede produktivitet. Under 400 ms skete der noget særligt.

Folk arbejdede ikke bare hurtigere. De blev i flowet og fik mere fra hånden, end selve tidsbesparelsen kunne forklare.

Hvad det betyder i praksis

En knap der reagerer med det samme. En side der tegner sig med det samme. En bekræftelse der ikke lader vente på sig.

Under grænsen føles produktet som en forlængelse af brugerens tanke. Over den bliver de mindet om, at de venter på en maskine.

Faldgruber

Ikke alt kan svare på 400 ms, og så handler det om at fylde ventetiden rigtigt. Skeletons, optimistiske opdateringer og tydelig fremdrift kan holde den oplevede hastighed oppe.

Følt hastighed tæller lige så meget som målt hastighed. En god ventetilstand kan redde det, teknikken ikke kan nå.

Sådan bruger vi det

Hastighed er en del af fundamentet, ikke noget man pynter på til sidst. Vi bygger på ren kode og hurtige svartider fra dag ét.

Det er den slags kvalitet, man ikke ser, men altid mærker. Præcis der, hvor et solidt fundament adskiller sig fra et hurtigt overfladisk resultat.

Andre designprincipper