Interaction ‘09 workshop: Skjemadesign med Luke W

Luke Wroblewski jobber hos Yahoo og har skrevet boka Web form design. Boka beskriver flere best practice i utforming av skjemaer på web basert på omfattende forskning fra teamet med og rundt Wroblewski.

Han er skikkelig god på eksempler og er flink til å vise hvordan ting kunne vært gjort annerledes i stedet for la det være med kritikken på skjema han kommer over. Han la opp sesjonen slik at vi fikk presentert et skjema og litt tid til å ramse opp mangler og feil ved det. Gjennom resten av foredraget hadde vi deretter bingo. Jeg vant en utgave av boka hans. Yay!

Nedenfor lister jeg opp notatene mine fra best practice presentasjonen og lenker til relevante ressurser.

Path to completion

  • Skap en tydelig sti mot ferdigjøring
  • Bruk progresjonsindikatorer for å kommunisere omfang, status og posisjon
  • Hvis det kreves betydlig tid eller oppslag av informasjon, vurder å bruke en startside
  • Bruk mer generelle progresjonsindikatorer for skjemaer med variable sekvenser

Hovedmålet med skjema er å fullføre det, det er viktig med en tydelige skannelinje, både for at brukeren ikke skal gå glipp av input og fordi du ved å se skjemaet skal få en oversikt over hva som forventes. Han forteller om en google-folklore som forklarer hvorfor de har en footer nederst på siden: Hvis det ser ut som om siden fortsetter nedeover, skroller gjerne folk. Hvis det ser ut som om siden er sluttet (med en footer) skroller ikke folk. Google satte inn en footer fordi folk trodde at nettstedet brukte ekstremt lang tid på å laste inn, siden den var veldig stor og hvit med uvant lite innhold (gamle dager).

Label alignment

  • For å redusere tiden til ferdigjøring og datainput er kjent: top-justert
  • Når vertikal skjermplass er en begrensning: høyre-justert
  • For ukjent eller avansert dataoppføring: venstre-justert

Se bloggpostene om justering av labels og labler inne i inputfelter.

Help & tips

  • Minimer mengden med hjelp og tips som kreves for å fylle ut et skjema
  • Nærliggende og synlig hjelp til en dataforespørsel er mest nyttig
  • Når folk kanskje er usikre på hvorfor og hvordan svare, vurder et automatisk inline system
  • For komplekse eller gjenbrukte skjemaer, vurder bruker-aktiverte systemer
  • Bruk inline hjelp om ikke du har mye hjelpinnhold (tekst, grafikk, diagrammer)
  • Bruk en konsistent hjelpseksjon hvis du har mye hjelpinnhold

Bruk gjerne mouseover for å vise forklaring til feltene eller dynamiske input-hjelpetekster som hos Wufoo. Bruk pop-up vindu hvis det er mye hjelpetekst, eller seksjoner som hjelp-funksjonen til Windows. På en tidligere versjon av eBay fikk du 18 (!) forskjellige hjelp-innganger når du skulle selge et produkt.

Inline validation

  • Bruk inline validering til input som har potensiell høy feilrate
  • Bruk foreslått input for å fjerne uklarhet
  • Kommuniser begrensninger

Han viser eksempel fra opprettelse av bruker på Twitter. Hvordan du får beskjed om hvor kraftig passordet ditt er, er et annet eksempel. Hvordan de gir brukerne tilbakemelding i Yahoo Answers er et eksempel på god feedback.
Eksempel på inline validation hos Yahoo Answers

Primary & secondary actions

  • Unngå sekundær-funksjoner hvis det er mulig
  • Imotsatt fall, ivareta en tydelig visuell forskjell mellom primær- og sekundær-funksjoner
  • Sammenstill primær-funksjoner med input-feltene for en tydelig sti mot ferdigstilling

Primary action er den viktigste detaljen på skjemasiden, den må stikke ut. Separer den fra andre, bruk farger og tekstlenker for å skille. Hans forskning viser at det er veldig naturlig for brukeren å trykke første knappen nede til venstre. Veldig få trenger å gå tilbake i en wizard, se bloggposten om plassering av knapper.

Actions in progress
Du trenger ikke en egen valg-boks til å huke av at brukeren godtar avtalen, eller lignende, la det være en del av submit-aktiviteten. Ikke deaktiver submit-knappen, la den være synlig hele tiden.

Errors

  • Kommuniser tydelig at en feil har oppstått: topplassering, med visuell kontrast
  • Sørg for at feilene får handlingsgivende hjelpemidler for å rette opp feilene
  • Assosier aktuelle felter med primær feilmelding
  • “Fordoble” the visuelle språket der hvor feil har oppstått

De må være synlige, gi god hjelp og bruk dobbelt visuelle formateringer, både farge og tyngde. Husk at noen brukere er fargeblinde. Toppnivå beskjed samt en indikering på hvilket felt det gjelder.

Unnecessary inputs
Fjern unødvendige inputfelter. Du trenger foreksempel ikke oppgi hvilket kredittkort det skal betales med, da tallene på kredittkortet gir denne informasjonen. Se bloggposten om internasjonale adressefelter i webskjemaer. Trenger en bruker oppgi både fullt navn, epostadresse og lage et brukernavn ved førstegangsregistrering av en tjeneste? Nei, rensk bort og ta hensyn til det viktigste.

Form organizations

  • Ta deg tid til å evaluere hvert spørsmål du spør
  • Forsikre deg om at skjemaet snakker med en stemme
  • Etterstreb konsistens
  • Hvis et skjema naturlig brytes opp i noen få korte emner, bruk én nettside
  • Hvis et skjema inneholder et stort antall spørsmål som bare relaterer seg til hverandre med få emner, prøv sammensatte nettsider
  • Hvis et skjema inneholder et stort antall spørsmål relatert til et enkelt tema, bruk en lang nettside

Ikke vreng organisasjonen i et skjema. Før en samtale med brukeren. Han demonstrerer hvordan et enkelt kontakt oss-skjema kan gå fra fint til forferdelig etter at forskjellige avdelinger av en organisasjon får være med å forme det.
Eksempel på hvordan et skjema preges av avdelinger i en organisasjon

Gradual engagement

  • Prøv å unngå registreringsskjemaer
  • Reflektér tjenesten din sin hovedessens gjennom enkle interaksjoner
  • Gjør folk vellykket med en gang
  • Hvis du autogenerer kontoer, forsikre deg om at de er enkelt tilgjengelig
  • Ikke fordel de forskjellige inputfeltene til et registreringsskjema over sammensatte sider

Dependent inputs

  • Hvis det er mange avhengige inputs, bruk side-nivå
  • Vertikale og horisontale faner yter like bra, men har utfordringer ved gjensidig utelukkelse
  • Lang liste med innledende inputs, få avhengige inputs for hver, bruk drop-down meny
  • Short list of initial options og få avhengige, exposed inline.
  • Oppretthold et tydelig slektskap mellom innledende valgmuligheter
  • Assosiér tydelig supplerende inputs med trigger-input
  • Unngå “hopping” som atskiller innledende valgmuligheter

Additional inputs

  • Planlegg supplerende inputs etter prioriterte brukeres behov
  • Mest effektivt når det er brukerinitiert
  • Unngå overdreven hopping mellom sider
  • Sørg for veier ut
  • Oppretthold en konsistent tilnærming

Tanker om fremtiden
Huffduffer bryter helt med skjemeoppstillingen og lar brukeren registrere seg gjennom tekst (lose the form factor).
Hvordan huffduffer har designet registreringsskjema

Sign up forms must die

Nettjenester bør engasjere brukerne, forklar og vis tjenesten, la registreringen være resultatet. La folk begynne å bruke tjenesten din med en gang.

Han demonstrerer ulike familitrenettsteder og hvordan geni.com gjør det annerledes og bedre fordi de lar brukeren begynne å lage et familietre med en gang. Første handling knyttes til det du egentlig vil lage/har kommet til nettstedet for å gjøre
Registrering hos geni.com

Tilsvarende jumpcut.com, hvor du lærer tjenesten ved å bruke den (nå er riktig nok jumpcut lagt ned…). Patientslike.me har også en annerledes og god start på tjenesten, du velger ditt utgangspunkt og får registreringsvalget senere
Hvordan patientslikeme.com lar deg teste innholdet.

Tripit er en annen tjeneste du lærer ved å bruke: send reiseplanene til de på epost og du får inntrykk av hvordan tjenesten virker.

Han mener også at tjenester bør bli flinkere til å finne “smart defaults”, altså forhåndsutfylte valg som dekker 80% av tilfellene. Særlig reiseselskaper kan bli flinkere til dette, enten ved å lese hvor den besøkende befinner seg og foreslå det som utgangspunkt, eller huske “typiske reisestrekninger” brukeren gjør.

Han nevner videopplastning på youtube som et eksempel på veldig godt skjema der de har forstått brukerens aktivitet. Dette skjemaet var et skjemavelde før, tungvindt og omfattende, hvor masse detaljer om videoen skulle fylles ut før du fikk laste opp videoen. Nå har de snudd helt og ber de laste opp videoen med en gang. Mens den laster i bakgrunnen fyller du ut de elementære feltene, og kan velge å legge til mer informasjon når videoen er ferdig lastet. Youtube har revidert dette skjemaet i 3 år.

Han har holdt foredrag om skjemadesign i mange sammenhenger, og selv om jeg ikke hadde lest hele boka, kjente jeg til resultatene fra arbeidet deres blant annet gjennom bloggen hans. 4-timers workshop i skjemadesign forventet jeg dermed hadde litt flere elementer ved seg enn oppramsing av best practice, og var derfor litt skuffet at vi ikke hadde mer hands-on praktiske oppgaver. Men han har som nevnt gode eksempler og best practice er veldig nyttig i skjemadesign fordi det er ofte veldig konkret.

Vi fikk stille spørsmål og diskutere momenter. Han passet på å føye til “it depends…” ofte både under presentasjonen og diskusjonen fordi skjemadesign er ikke rett frem. Og som han sa: “Jeg får ofte spørsmål fra folk som sier at disse best practice ikke går an å bruke på deres skjemaer, fordi skjemaene er skikkelig kompliserte. Hvis du tenker at du gjør noe skikkelig komplisert og står fast ved det, har du i utgangspunktet et problem. Du må i tilfelle jobbe ekstra hardt for å gjøre det enkelt.”

Se også eksempler fra presentasjon han har gjort tilgjengelig tidligere på bloggen sin (pdf).

Ingen kommentarer ennå

Vil du kommentere?

E-postadressen din vil ikke bli vist til andre