Slik gjennomfører du en oppgavebasert revisjon av informasjonsarkitekturen

Revider representative brukeroppgaver og de realistiske rutene til målet før dere vurderer menyen, tegner et nytt nettstedskart eller godkjenner en migrering. En overfylt navigasjon, en side med mange utganger eller gjentatte klager kan peke mot et problem, men sier ikke om årsaken er manglende innhold, en uklar etikett, svak internlenking, dårlige søkeresultater eller en kontroll som er vanskelig å bruke. Velg derfor først en viktig oppgave, definer hva et vellykket resultat er, og følg alle sannsynlige veier dit. Da blir revisjonen et beslutningsgrunnlag for konkrete forbedringer, ikke en samling løse observasjoner om sider og menyer.

Hvilken beslutning skal revisjonen gi grunnlag for?

Revisjonen skal utformes rundt én tydelig beslutning, for eksempel om en seksjon bør repareres, etiketter bør endres, en migrering kan forberedes, eller dokumentasjonen faktisk støtter en bred redesign. Informasjonsarkitektur omfatter organisering, etiketter og navigasjon som hjelper mennesker med å finne informasjon, forstå hvor de er og hvilke muligheter de har, og fullføre ønskede oppgaver. En oppgavebasert IA-revisjon undersøker derfor om det eksisterende rutesystemet støtter utvalgte oppgaver; den er ikke samtidig en innholdsfortegnelse, teknisk SEO-revisjon, full tilgjengelighetsvurdering eller ferdig redesign.

Avgrens hvilke målgrupper, mål, startsituasjoner, sidetyper, enheter, språkversjoner, tilganger og steg i reisen som er med. Hvis en innlogget kunde ser andre ruter enn en ny besøkende, må observasjonene knyttes til riktig tilstand. Det samme gjelder når mobilvisning, norsk og engelsk innhold eller eksterne landingssider endrer valgmulighetene. Konklusjonen gjelder disse undersøkte kontekstene, ikke en tenkt gjennomsnittsbruker. Før inspeksjonen begynner, avtal også hvilken dokumentasjon beslutningstakerne trenger for å velge et avgrenset tiltak eller be om mer undersøkelse.

• Registrer kjente fakta uten å blande inn tolkning.
• Før observert brukeratferd som egne funn med oppgave og kontekst.
• Merk ekspertens inspeksjonsfunn som faglige vurderinger, ikke som observert svikt.
• Skriv ubekreftede årsaksforklaringer og interessentpåstander som hypoteser.
• Knytt hvert funn til beslutningen revisjonen faktisk skal informere.

Hvordan bygger dere et representativt oppgavesett fra dokumentasjon?

Bygg oppgavesettet ved å formulere ønskede resultater med ord målgruppen selv kan kjenne igjen, uten å røpe sidenavnet eller den antatte navigasjonsveien. GOV.UK anbefaler å undersøke hva mennesker prøver å gjøre, hvordan de gjør det i dag, hvilke problemer de møter, og hvilket resultat de trenger. Skriv derfor heller en situasjon og et mål enn en instruksjon som «gå til Kundeservice». For hver oppgave dokumenterer dere målgruppe, utløsende behov, mulige startpunkter, vellykket resultat, forventet mål og kilden som gjorde oppgaven relevant.

Hent kandidater fra brukerundersøkelser, analyse, interne søk, støttehenvendelser, tilbakemeldinger, tidligere studier, observasjon og medarbeidere som arbeider tett med brukerne. Disse kildene har ulik bevisverdi: analyse og søkelogger viser handlinger, men ikke nødvendigvis hensikten eller årsaken, mens påstander fra interessenter forblir hypoteser til de støttes av brukerinnsikt. En Digital.gov-studie utviklet realistiske oppgaver fra tidligere undersøkelser og vurderte dekningen før testing. Poenget er dokumentert opphav, ikke å kopiere studiens antall oppgaver eller deltakere.

• Ta med hyppige oppgaver som påvirker mange, men ikke la volum alene bestemme utvalget.
• Inkluder oppgaver med store konsekvenser dersom feil vei kan skape betydelig friksjon eller tapte muligheter.
• Synliggjør vanskelige oppgaver der tidligere funn viser tvil, omveier eller behov for hjelp.
• Representer målgrupper og tilstander som ellers lett blir oversett, når de omfattes av beslutningen.
• Definer på forhånd hvilket innhold eller hvilken handling som viser at hver oppgave er fullført.

Hva skal et arbeidsark for oppgaver og ruter inneholde?

Arbeidsarket skal koble hver dokumenterte oppgave til resultatet, sannsynlige ruter, inspiserte signaler, observert atferd, diagnose, tiltak og ny test i én sporbar rad. Registrer mål og destinasjon ved siden av realistiske startpunkter: en ekstern landingsside, en temaside, et innlogget område, et søkeresultat eller intern søk. Kartlegg både blaing, kontekstuelle lenker og søk. Ikke anta at alle starter på forsiden, eller at én vellykket vei dekker alle relevante enheter, tilganger og situasjoner.

Ved hvert veivalg noterer dere hvilket synlig signal personen møter, hvilken forventning signalet skaper, hvor valget faktisk fører, og om det er mulig å oppdage og rette et feilvalg. WCAG 2,2 suksesskriterium 2,4,5 krever mer enn én måte å finne en side i et sett på, bortsett fra sider som er resultater av eller steg i en prosess. Relaterte lenker, nettstedskart, søk og omfattende navigasjon er blant de dokumenterte teknikkene. Revisjonen må bevare unntaket og ikke gjøre kriteriet til en ubetinget regel.

• Behold en entydig oppgave-ID og kilden som begrunner oppgaven.
• Beskriv startkontekst og alle plausible bla-, lenke- og søkeruter.
• Loggfør synlige etiketter, grupperinger, stedsangivelser og søkeuttrykk ved hvert veivalg.
• Skill observert handling fra forskerens forklaring og styrken på dokumentasjonen.
• Før ansvarlig eier, minste foreslåtte endring og planlagt ny test i samme rad.

En oppgavebasert IA-revisjon spør ikke om nettstedskartet ser ryddig ut, men om mennesker kan nå et nødvendig resultat gjennom realistiske og dokumenterte ruter.

Hvordan inspiserer dere hele ruten, ikke bare menyene?

Inspiser hele ruten ved å gå fra hvert realistisk startpunkt gjennom globale og lokale menyer, knutepunkter, sidegrupper, overskrifter, stedsangivelser, kontekstuelle lenker, internt søk og frem til innholdet eller handlingen som fullfører oppgaven. Etiketter skal vurderes ut fra forventningen de skaper i akkurat denne sammenhengen. Microsoft anbefaler å planlegge navigasjon rundt brukernes perspektiver, vanlige oppgaver og mentale modeller, og beskriver gode etiketter som presise, kjente, konsise, skannbare og tydelig forskjellige. Kort er ikke automatisk klart; målet er en presis forventning.

Kontroller om personen kan se hvor hun er, hvilket nivå hun har nådd, hvilke relevante valg som finnes videre, og hvordan hun kan hente seg inn etter en blindvei. WCAG 2,2 suksesskriterium 2,4,6 krever at overskrifter og etiketter som finnes, beskriver emnet eller formålet. Kriterium 3,2,3 sier at gjentatte navigasjonsmekanismer skal beholde samme relative rekkefølge, med mindre brukeren selv setter i gang en endring; det forbyr ikke lokal eller sekundær navigasjon. Dette er avgrensede kontroller, ikke en full tilgjengelighetsvurdering.

• Sammenlign eksterne landingssider med interne innganger til den samme oppgaven.
• Kontroller global og lokal navigasjon uten å forutsette at én av dem er hovedveien for alle.
• Vurder om knutepunkter og sidegrupper samsvarer med forventningen som tidligere etiketter skapte.
• Se etter tydelige overskrifter, brødsmuler eller andre signaler som viser plassering og neste steg.
• Undersøk om kontekstuelle lenker finnes der behovet oppstår, ikke bare andre steder i hierarkiet.
• Prøv relevante interne søk og vurder resultater, omformuleringer, målgjenkjenning og fullføring.
• Gjenta viktige oppgaver når enhet, språk, tilgang eller sidetilstand faktisk endrer ruten.
• Tolk søk som en mulig foretrukket rute, ikke automatisk som bevis på navigasjonssvikt.

Hvilken metode bør validere den usikre delen av ruten?

Velg metode ut fra hva dere fortsatt ikke vet om ruten. Ekspertinspeksjon og eksisterende atferdsdata kan peke ut sannsynlige feil, men et inspeksjonsfunn skal ikke omtales som en observert brukerfeil. Kortsortering passer når spørsmålet gjelder forventet gruppering eller kategorispråk. Digital.gov beskriver åpne sorteringer som undersøkelser der deltakerne lager og navngir grupper, mens lukkede sorteringer bruker forhåndsdefinerte kategorier. Metoden kan informere organisering og språk, men validerer ikke en komplett ferdig rute med menyer, lenker, søk og kontroller.

Bruk tretesting når dere vil isolere om hierarkiet og etikettene gjør en destinasjon mulig å finne uten påvirkning fra sidedesign. Metoden kan avsløre kategorier som trekker deltakere i ulike retninger, men utelater mye av det gjengitte grensesnittet. Bruk oppgavebasert brukertesting når spørsmålet omfatter den faktiske navigasjonen, sidesignaler, kontroller, internlenker, søk, feilretting eller fullføring. NIST beskriver slik testing med representative brukere og representative oppgaver, der fullføring, feil, tidsbruk, kommentarer og tilfredshet kan være relevante observasjoner.

• Velg ekspertinspeksjon for å formulere og avgrense hypoteser som senere kan undersøkes.
• Velg kortsortering når usikkerheten gjelder hvilke elementer som hører sammen, eller hvilke kategorinavn deltakerne forventer.
• Velg tretesting når dere trenger et renere svar på om hierarki og etiketter leder til riktig mål.
• Velg testing på det gjengitte nettstedet når samspillet mellom menyer, sideinnhold, lenker, søk og kontroller er avgjørende.
• Mål bare det som hjelper beslutningen: fullføring, hjelp, feilvalg, omveier, tilbakegang, tidsbruk, omformulerte søk, trygghet på målet eller deltakerens begrunnelse.
• Undersøk avvikende ruter selv når oppgaven fullføres, fordi forklaringene kan vise tvetydige grupper eller gyldige alternative veier.

Hvordan blir funn til avgrensede tiltak eller en redesignbeslutning?

Gjør funnene handlingsrettede ved først å klassifisere den faktiske feilen og deretter velge den minste endringen dokumentasjonen støtter. En innholdsmangel skal ikke ende som et forslag om ny hovedmeny, og en utilgjengelig kontroll skal ikke skjules i en generell kategori for dårlig finnbarhet. Prioriter med synlige vurderingsgrunnlag: hvor viktig oppgaven er, hvilke målgrupper som berøres, hvor ofte feilen ble observert, konsekvensen, styrken på dokumentasjonen og avhengigheter i gjennomføringen. Unngå et universelt, vektet IA-tall som skjuler skjønnet bak en tilsynelatende presis sum.

• Dekning: nødvendig innhold, handling eller tilstand mangler eller er ufullstendig.
• Inngang: et sannsynlig startpunkt tilbyr ingen plausibel vei videre.
• Etikett: signalet beskriver ikke målet eller bruker ukjent eller inkonsekvent språk.
• Gruppering: innholdet ligger et uventet sted, eller kategorier overlapper på en tvetydig måte.
• Orientering: personen forstår ikke plassering, nivå eller neste relevante steg.
• Krysslenke: en nødvendig videre vei mangler der behovet oppstår.
• Søk: relevante uttrykk gir manglende, misvisende eller vanskelige resultater.
• Konsistens: gjentatte mekanismer skifter navn, rekkefølge eller virkemåte.
• Interaksjon: strukturen er rimelig, men den gjengitte kontrollen eller utformingen hindrer bruk.

Koble hver feiltype til et proporsjonalt tiltak: innholdskorrigering, ny etikett, reparert lenke, annen gruppering, forbedret søk, omstrukturering av en seksjon eller, når funnene faktisk krever det, bred redesign. Test de berørte oppgavene og rutene på nytt før tiltaket erklæres vellykket. En redesign er best begrunnet når viktige feil gjentar seg i relevante kontekster, støttes av observert dokumentasjon, er strukturelle fremfor lokale og ikke rimelig kan løses med avgrensede forbedringer. Mangler én av disse forutsetningene, er neste steg ofte en reparasjon eller mer målrettet undersøkelse.

Avslutt revisjonen med en beslutning om ny test, ikke automatisk med et nytt nettstedskart. Involver en erfaren informasjonsarkitekt eller UX-forsker når oppgavesettet, forskningsdesignet eller de strukturelle avveiningene overstiger teamets kapasitet. Dersom funnene reiser tilgjengelighetsspørsmål, bør en kvalifisert tilgjengelighetsspesialist gjennomføre den relevante samsvarsvurderingen. Kontrollene av flere veier, beskrivende etiketter og konsistent navigasjon i denne metoden dekker bare utvalgte WCAG-kriterier og dokumenterer ikke at hele nettstedet oppfyller WCAG. Behold arbeidsarket som sporbar dokumentasjon for eierskap, gjennomføring og neste revisjon.