Den viktigste UX-sjekklisten: Se gjennom nettstedet med kundenes øyne

Nettstedet ditt er nettopp redesignet. Det ser flott ut på den store skjermen i møterommet; alle kjenner tilbudet og kan fullføre en bestilling i blinde. Men en kunde kommer inn på telefonen, vet ingenting om selskapet og forlater siden ved første forvirring. Derfor er det ikke nok å kontrollere om et nettsted ser pent ut.

Vi brukte den opprinnelige versjonen av denne sjekklisten som en bred liste for nettsteder og nettbutikker. Over tid samlet den verktøy og enkeltregler som ikke var universelle. Denne versjonen går tilbake til det grunnleggende: hva en person skal kunne gjøre, hva du må kontrollere, og hvordan du oppdager et problem før du begynner å bruke penger på trafikk.

Identifiser først de tre viktigste brukerreisene

En UX-gjennomgang av et helt nettsted kan lett ende i hundre kommentarer. Før jeg åpner analysene, velger jeg derfor de tre reisene som betyr mest for virksomheten. Vanligvis:

• en ny besøkende forstår tilbudet og sender en forespørsel,
• en kunde finner et produkt, legger det i handlekurven og betaler,
• en eksisterende kunde finner support, et dokument eller kontaktopplysninger.

For hver reise skriver du ned startpunktet, forventet sluttpunkt og hovedhindringen. Da fullfører du ikke sjekklisten mekanisk. Du kontrollerer om nettstedet støtter en konkret beslutning.

1. Tilbudet må være tydelig for noen som ikke var med i møtet

• Er det tydelig fra første skjermbilde hva du tilbyr, og hvem det er for?
• Beskriver hovedoverskriften et resultat eller problem, snarere enn et firmaslagord?
• Er neste steg synlig uten at man må lete gjennom menyen?
• Kan besøkende skille mellom de enkelte tjenestene eller alternativene?
• Oppgir du betingelsene og begrensningene som faktisk påvirker beslutningen?

Test det med noen som ikke kjenner selskapet. Gi dem noen sekunder, lukk siden og spør hva selskapet gjør, og hva de ville gjort videre. Dette er ikke en vitenskapelig studie, men den avdekker raskt språk som bare forstås av personer internt i selskapet.

2. Navigasjonen må fungere uten at man må tenke seg om, og uten mus

• Samsvarer elementnavnene med det besøkende leter etter?
• Fungerer lenker, logoen og returen til forrige trinn?
• Er mobilmenyen lesbar, mulig å lukke og fri for viktig innhold som dekkes til?
• Er det tydelig hvor personen befinner seg i en lengre struktur?
• Kan alle viktige kontroller nås med Tab-tasten?
• Er fokus synlig ved bruk av tastatur, og unngår brukeren å bli fanget?

Tilgjengelighet er ikke en spesialmodus for noen få personer. Tilstrekkelig kontrast hjelper også på en telefon i sollys, og et tydelig skjema hjelper noen som har det travelt. For en rask kontroll kan du bruke Easy Checks fra W3C. Dette er en første gjennomgang, ikke en bekreftelse på full WCAG-samsvar.

3. Innholdet må veilede både blikket og beslutningen

• Finnes det én hovedoverskrift og en logisk struktur med videre overskrifter?
• Er avsnittene lesbare, med viktig informasjon som er lett å finne ved skanning?
• Beskriver lenker og knapper resultatet av å klikke på dem?
• Avhenger betydningen bare av farge, et bilde eller en hover-effekt?
• Har informative bilder meningsfull alternativtekst?
• Forstyrrer animasjoner tilbudet, og kan brukerne respektere preferanser for redusert bevegelse?

En sterk farge alene skaper ikke en konverteringsknapp. Først må det være tydelig hva som skjer etter klikket. «Send inn» er en teknisk beskrivelse. «Bestill en innledende samtale» reduserer usikkerheten.

4. Et skjema bør bare spørre om det selskapet faktisk vil bruke

• Har hvert felt en synlig etikett som er koblet til feltet programmatisk?
• Er det tydelig hvilke data som er obligatoriske, og hvorfor de trengs?
• Kan brukeren fylle ut skjemaet på telefon og med tastatur?
• Forklarer en feilmelding både problemet og hvordan det løses?
• Blir korrekt utfylte data stående etter en feil?
• Får brukeren en tydelig bekreftelse og informasjon om hva som skjer videre etter innsending?

I sin veiledning om tilgjengelige skjemaer anbefaler W3C å bare spørre etter data som trengs for å fullføre prosessen. Hvert ekstra felt koster oppmerksomhet og øker arbeidet med datahåndtering. Hvis virksomheten ikke vil bruke informasjonen, bør du fjerne feltet.

5. En nettbutikk må håndtere hele kjøpet, ikke bare en vakker produktside

Kategorier og søk

• Samsvarer filtrene med hvordan folk velger, og kan de enkelt fjernes?
• Er tilstanden uten resultater nyttig, og tilbyr den en annen vei videre?
• Inneholder et produktkort navn, pris, tilgjengelighet og et lesbart bilde?
• Er sortering og filtrering fortsatt brukbart på telefon?

Produktdetaljer

• Er alternativer, pris, merverdiavgift, tilgjengelighet og levering forklart før varen legges i handlekurven?
• Viser fotografiene det kunden trenger for å vurdere produktet?
• Er knappen for å legge i handlekurven synlig uten å dekke innholdet?
• Tilbyr et utsolgt eller utgått produkt et alternativ og en fornuftig vei tilbake?

Handlekurv og bestilling

• Kan varen, alternativet og antallet endres uten at andre data går tapt?
• Er sluttprisen, inkludert levering og gebyrer, kjent i tide?
• Unngår du å kreve registrering uten en forretningsmessig grunn?
• Føres personen tilbake til en forståelig tilstand etter en mislykket betaling?
• Er ordrebekreftelsen entydig, og hindrer den et utilsiktet gjentakelseskjøp?

Regelen om at «det ikke skal være navigasjon i handlekurven» gjelder ikke alltid. Ved et enkelt kjøp kan færre distraksjoner hjelpe. Ved et komplekst tilbud trenger kunden imidlertid å finne betingelser eller produktdetaljer. Test atferd, ikke en tommelfingerregel.

6. Et nettsted må tåle mobil, tregt nettverk og feil

• Lastes hovedinnholdet raskt uten store layoutforskyvninger?
• Reagerer siden på klikk og skriving uten merkbar forsinkelse?
• Har bildene riktige dimensjoner, og lastes de bare inn med nødvendig kvalitet?
• Kan et defekt eksternt skript blokkere en ordre eller et skjema?
• Fungerer viktige reiser i aktuelle vanlige nettlesere og på ekte telefoner?
• Overvåker du tilgjengelighet og feil i viktige trinn?

En laboratoriemåling er veiledning, ikke et forretningsresultat. Følg også ekte brukere og hovedreisen. En annonseringspiksel må ikke være viktigere enn Kjøp-knappen.

7. Verifiser målingen med en test, ikke ved å kontrollere at koden finnes

For hver viktig reise lager du en testforespørsel eller -bestilling. Kontroller at hendelsen sendes én gang, med riktig navn, verdi, valuta og transaksjons-ID. Verifiser deretter at målsystemet ser den, og at den samsvarer med den virkelige ordren.

• Sendes et kjøp bare ved å åpne en takk-URL?
• Dupliseres hendelsen når siden oppdateres?
• Respekterer tagger samtykkestatusen?
• Inneholder datalaget personopplysninger som ikke hører hjemme der?
• Inneholder containeren bare tjenester selskapet bruker?
• Finnes det en ansvarlig for målingen og en registrering av siste kontroll?

For implementering kan du se Slik konfigurerer du Google Tag Manager riktig; for betydningen av hendelser kan du se Google Analytics 4-veiledningen. Sesjonsopptak eller varmekart kan avdekke blindsoner, men bruk dem målrettet, med sensitive felt maskert og i tråd med samtykkereglene. Å ta opp alt «for sikkerhets skyld» er ikke en undersøkelsesplan.

Slik bruker du sjekklisten uten en månedlig workshop

1. Velg én viktig reise og gå gjennom den på en telefon.
2. Gjør det samme med bare et tastatur.
3. La noen utenfra selskapet fullføre oppgaven, og ikke veiled dem.
4. Noter hvor de nølte, ikke løsningen du selv foreslår.
5. Verifiser problemet i analyser, support eller videre tester.
6. Fjern én hindring og gå gjennom hele reisen på nytt, inkludert målingen.

Ikke prøv å erklære et nettsted «UX-ferdig» etter én runde. Tilbudet, enhetene og menneskers forventninger endrer seg. Formålet med sjekklisten er å finne den dyreste friksjonen regelmessig og avgjøre hva som skal løses først.

Hvis du vil vurdere nettstedet i en bredere forretningskontekst, kan du også bruke sjekklisten for nettmarkedsføring. Hvis du trenger å prioritere UX, måling og anskaffelse, kan du beskrive hovedreisen din via kontaktsiden.