Illusjonen av hastighet
Er ditt grensesnitt hurtig nok? Faktisk hastighet er viktig for din nettside eller webapplikasjon. Men det finnes en annen form for hastighet, oppfattet hastighet. Denne hastigheten måles ikke i sekunder, men hvor hurtig det føles. Vi kan påvirke dette, ved å visualisere (eller ikke) oppgaver som utføres riktig i forhold til deres oppfattede lengde.
Hastighet går aldri av moten
37 Signals sier ofte at de satser på faktorer som aldri går av moten. Hastighet (sammen med effektivitet og brukervennlighet) er en av disse faktorene. Hastighet i systemer er ikke noe man skulle ønske man hadde mindre av om ett eller ti år.
Hastighet i respons til brukeren er veldig viktig. Hvis ikke brukeren mottar svar fra systemet i den hastigheten man forventer, kan de tro at systemet har hengt seg eller at noe er galt eller ødelagt.
Menneske-maskin
Når det kommer til tilbakemeldinger, forholder vi oss til maskiner på samme måte som til mennesker. Så for å forstå betydningen av hastighet lettere, se for deg en hver interaksjon som en samtale mellom deg og et annet menneske.
Ved å gjøre interaksjonen mennesklig er det lettere å forstå hvorfor man blir oppgitt av trege systemer. Spør du et systemet om noe du definerer som ‘enkelt’, forventer du et kjapt svar tilbake – akkurat som med mennesker. Jo lengre tid du må vente, dess tregere og dummere oppfatter du systemet.
For raskt?
Se for deg at du spør en venn hva du burde gjøre i en vanskelig situasjon, og vennen svarer på et halvt sekund. Du blir irritert fordi vennen oppfører seg likegyldig til spørsmålet. Hvis hastigheten på systemet oppfattes som for raskt, kan man tro at det som ble utført ikke var presist nok eller feil. Eksempel: installasjon av et Adobe-program tar fem sekund 
4 varianter av hastighet
I boken “Designing and Engineering Time” definerer Steven C. Seow fire varianter av hastighet:
Instant (0.1-0.2 sekunder)
Eksempel: Ved å dra en scrollbar forventes øyeblikkelig hastighet – akkurat som man beveger noe i virkeligheten.
Immediate (0.5-1 sekunder)
Eksempel: Hastigheten det tar å vise et nytt foto i et album. Her forventes tilbakemelding inne ett sekund fordi dette sees på som en ‘operasjon’ i forhold til å scrolle.
Continuous (2-5 sekunder)
Nå er vi inneforstått med at datamaskinen må ‘tenke’, oppgaver som tar tid. Her burde du begynne å vise grafikk for å synliggjøre tiden prosessen tar, og hvor lenge det sånn ca. er igjen. Eksempel her vil være å laste inne dokumenter, hente små filer – middels lange oppgaver.
Captive (7-10 sekunder)
Her strekkes brukerens tålmodighet – oppgaver som tar over ti sekunder vil gi brukeren mulighet til å gjøre andre ting imens oppgaven utføres. I tillegg til en grafisk visning av tiden, er det her viktig å opplyse i tid hvor lang oppgaven vil være – og muligens hva slags oppgaver som utføres.
Estimér tid og informer brukeren
Hvis en interaksjon tar over 5 sekunder, altså i spennet ‘Captive’ og utover, er det viktig at du informerer brukeren om hvor lang tid oppgavene vil ta, og muligens hva slags oppgaver som skal utføres. Det er ikke alltid nødvendig for en bruker å vite alle oppgaver som skal utføres, men tidsestimering er veldig viktig.
Ta ‘oppfattet hastighet’ i bruk
Når du designer et brukergrensesnitt, spør deg selv “Hva slags hastighet vil forventes her?” – øyeblikkelig, hurtig – eller en grundig lang prosess. Hvis prosessen er lang, forklar og vis godt – hvis prosessen er kort, trenger du ikke vise noe annet enn resultatet, evt. bruk en kort animasjon fram til resultatet.