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.
12 kommentarer til "Illusjonen av hastighet"
Interessant artikkel.
Det slår meg at det er en forskjell på hva som er raskt og hva som oppfattes som raskt, og at det kanskje er det siste man skal levere på.
Jeg har akkurat gått over til iPhone, og har gjort meg noen tanker rundt akkurat det du skriver her. iPhone er på noen operasjoner ubeskrivelig treig, men Apple har animert ventetidene — vinduer “blar”, “fanene” i Safari sklir opp og ned, osv.
Det skjuler virkelig noe av systemets underliggende treghet, og gir meg en fascinerende følelse av responsivitet — selv når jeg vet det ikke er tilfelle.
Takk, Jo. Apple har gjort en god jobb. En ting ang. oppfattet hastighet jeg syns Apple bommer på, er når de bruker den universale loader-grafikken sin, den som snurrer rundt. Du vet aldri hvor lang tid operasjonen vil ta.
Den universale loaderen var fin når den kom, når det var ifm. innlasting av skjema på web. Nå når den brukes på “alt” og i tillegg feil (ref. eksempelet til Tor) blir den bare slitsom.
Når det gjelder tidsindikatorer som disse bør de også ha en indikasjon på når ting har stoppet/er feil. Jeg hadde et problem med en javadings, der gikk loaderen “evig” og jeg følte at ting gikk sykelig tregt, men loaderen hadde faktisk stoppet.
Jeg føler at den første setningen var ekstremt dårlig formulert. Det jeg mente var skjema/funksjonalitet o.l., typisk AJAX-bruk.
Veldig enig, Thomas. Det er langt fra en god løsning.
Jeg tror ikke at det noensinne blir for raskt. Hvis en venn hadde kommet med et innsiktsfullt svar etter et halvt sekund, hadde jeg blitt imponert over evnen til rask tankegang snarere enn å bli irritert over rask reaksjonstid. Jeg hadde også blitt gledelig overrasket dersom min venn allerede hadde sett mine problemer og satt seg inn min situasjon på grunn av gode empatiske evner. Jeg tror man også fort kan venne seg til at innstallasjon av Adobe-programmer bare tar fem sekunder.
Uansett hvor lang tid en operasjon tar, er tiden det tar før systemet responderer viktig. Dan Saffer sier vi trenger å vite at produktet “hørte” hva vi fortalte det og at det jobber med saken. Vi ønsker også å vite hva produktet eller tjenesten holder på med. Han kategoriserer forøvrig reaksjonstid i fire kategorier:
1. Immediate – ( 1 sec) attention could move from task to the product. Several interruptions could lead to a disruption.
4. Disruption – (> 10 sec) could lead to the user dropping out of the process.
Hastighet i systemet kan ikke bli for raskt, nei – men oppfattet hastighet kan bli det. Ta eksempelet med Adobe eller noe annet du oppfatter som en stor oppgave – hvis denne har for kjapp oppfattet hastighet, vil du tro at noe mangler eller kan ha gått galt, i mange tilfeller.
Ser ut til at de fire punktene ble automatisk kortet ned til to, så jeg prøver å få med alle her:
1. Immediate – ( 1 sec) attention could move from task to the product. Several interruptions could lead to a disruption.
4. Disruption – (> 10 sec) could lead to the user dropping out of the process.
Jeg ser poenget ditt, Tor, og ser at de fleste vil tro at det er noe feil når den vanligvis ultratrege installasjonen til Adobe plutselig går unna i en fei. Erfaringsgrunnlag fra dårlige/trege opplevelser kan dessverre lage trøbbel for gode/raske….
1. Immediate(less than .01 sec) push a key – system reacts instantly.
2. Stammer(.01 – 1 sec) slight delay – if frequent could become frustrating otherwise it will most likely be overlooked.
3. Interruption (more than 1 sec) attention could move from task to the product. Several interruptions could lead to a disruption.
4. Disruption(more than 10 sec) could lead to the user dropping out of the process.
Her er lenke til punktene dersom de ikke kommer med riktig denne gangen heller: http://www.norberg-ad.com/analytical-design/archives/6
Takk for godt bidrag, Torstein :)
Dette har også mye med hvordan utviklingen er i det respektive felt det gjelder, og hvilke oppfatninger og forventninger som generelt foreligger for slike operasjoner. Det kan vel trekkes direkte relevans til Verdihierarkiet om hvordan brukere forventer en tjeneste og hvordan den faktisk fungerer, og hvordan leverandøren har funnet metoder til å overgå disse forventningene.
Eksempel fra artikkelen:
De fleste vet at bruk av en datamaskin tar tid til tider (som f.eks ved kopiering av filer). Leverandørens måte å “opphøye” opplevelsen av tjenesten er da å visualisere tidsbruken som kan innfri, og kanskje overgå forventninger ut i fra hvor detaljert det kanskje er.
Internett er vel et av de områdene brukere er mest kravstore og forventningsfulle for hva “det neste” blir. Det kommer jo stadig nye måter å levere tjenester på. google har vært og er ganske hyppig ute å setter nye standarder for utvikling av tjenester, men det er vel også der som med alt annet; brukere har forskjellig forventningsnivå ut i fra hvilken tjeneste de skal bruke på nettet.
Interessant tema.
[...] Les mer om : Illusjonen av hastighet [...]