Så testar du om en artikel löser läsarens problem

Skriv granskningsunderlaget innan du går igenom texten:

Läsare: [en specifik typ av person]. Avsikt: [vad personen vill förstå eller besluta]. Uppgift: Efter att ha läst kan personen [observerbar handling] utan att behöva något outtalat steg eller någon outtalad källa.

Till exempel:

Läsare: En redaktör som granskar en praktisk webbartikel. Avsikt: Avgöra om utkastet hjälper den avsedda läsaren. Uppgift: Tillämpa en granskning av slutförandevägen och dokumentera ett beslut om att publicera, revidera eller avvisa, med motivering.

Den här skillnaden spelar roll. ”Lära sig om innehållskvalitet” är ett informationstema, inte en testbar uppgift. ”Hitta det saknade förkunskapskravet i en instruktionsartikel och revidera det relevanta avsnittet” går att testa.

Begränsa omfattningen så att det finns ett tydligt slut på uppgiften. En guide kan förklara hur man jämför två produkter, förbereder ett dokument, felsöker en inställning eller väljer mellan olika alternativ. Den behöver inte besvara alla närliggande frågor för att lösa den angivna uppgiften.

GOV.UK:s vägledning om innehåll och publicering rekommenderar att man identifierar användarnas behov och planerar innehållet utifrån dem. Googles egna frågor för självbedömning handlar på liknande sätt om huruvida en avsedd målgrupp skulle ha nytta av innehållet, om läsarna får lära sig tillräckligt för att nå sitt mål och om de får en tillfredsställande upplevelse (Google Search Central). Det här är användbara frågor, men redaktören måste fortfarande omvandla dem till ett konkret test av om uppgiften kan slutföras.

Lista de handlingar som läsaren måste utföra, i rätt ordning, för att slutföra uppgiften. Ta med beslut, beräkningar, indata, kontroller och överlämningar – inte bara artikelns rubriker.

En praktisk kartläggning kan se ut så här:

Markera sedan varje steg som täckt, delvis täckt eller saknat. ”Täckt” innebär att läsaren kan agera utifrån artikeln, inte bara att ämnet nämns.

En artikel om ett budgetkalkylblad kan till exempel förklara hur man summerar utgifter, men utelämna vilken tidsperiod som ska användas, om skatt ska ingå i summan eller hur en oregelbunden räkning ska hanteras. Den centrala beräkningen finns med, men vägen till slutförd uppgift brister redan vid indata.

En användbar granskningstabell är:

Tabellen visar om utkastet är komplett som verktyg. Den hindrar också redaktören från att belöna en välskriven inledning samtidigt som ett saknat förkunskapskrav förbises.

Många praktiska artiklar brister redan före den första instruktionen eftersom de förutsätter kunskap, tillgång eller förhållanden som läsaren saknar. Granska varje steg genom att ställa fyra frågor:

Ange antaganden uttryckligen. Om en beräkning använder en procentsats ska du definiera basen. Om en installationsguide är beroende av en viss programvaruversion ska du ange relevant version eller funktion. Om en artikel jämför alternativ ska du säga vilka förhållanden som gör varje alternativ lämpligt.

Skilj mellan nödvändiga indata och valfria förbättringar. Läsaren ska kunna avgöra om något krävs för att gå vidare eller bara är till hjälp. Placera förkunskapskrav före proceduren, där de kan förhindra onödigt arbete.

Leta också efter dolda omvandlingar. Behöver läsaren konvertera enheter, ta bort mellanslag, välja ett datumintervall eller tolka ett felmeddelande? Ge i så fall regeln eller ett kort exempel. Hitta inte i tysthet på ett värde för en saknad indata. Berätta för läsaren vad som behöver hämtas, vilket antagande som ska dokumenteras eller när metoden inte kan slutföras.

En artikel är mer trovärdig när den beskriver felvillkor tydligt. ”Om resultatet är tomt, kontrollera om källfältet innehåller något” är mer användbart än att antyda att metoden alltid fungerar. Granskningen bör dokumentera varje punkt där läsaren rimligen kan köra fast.

Fråga dig vilket slags stöd varje betydelsefullt påstående behöver. En definition kan behöva en auktoritativ källa. En procedurinstruktion kan behöva en förstahandsmanual eller en dokumenterad specifikation. En rekommendation kan behöva angivna kriterier och en tydlig förklaring av hur de leder fram till rekommendationen.

Skapa en påståendelogg med fyra kolumner: påstående, vilket läsarbeslut som påverkas, använda belägg och formuleringens styrka. Den sista kolumnen är viktig. Beläggen kan stödja ”kan”, ”vanligtvis” eller ”krävs”, men inte automatiskt ”alltid”, ”bäst” eller ”garanterat”. Bevara källans villkor och begränsningar.

Föredra ursprungliga källor eller förstahandskällor när de dokumenterar själva företeelsen. W3C:s förklaring av WCAG 2.2 Reading Level anger till exempel att komplex text ska ha en version som är lättare att förstå eller kompletterande innehåll när den angivna läsnivån överskrids. En redaktör kan använda den källan för att motivera en kontroll av textens komplexitet, utan att dra den obelagda slutsatsen att ett enda läsbarhetsvärde gör varje artikel tillgänglig.

Beläggen bör stå intill påståendet de stöder, som i exemplet, i stället för i en orelaterad källista. En källista är användbar vid granskning, men den kan inte reparera ett stycke vars formuleringar går längre än beläggen. Kontrollera datum, versioner och omfattning, särskilt för instruktioner som gäller programvara, standarder eller policyer.

En läsbar artikel är inte bara trevlig att läsa; den minskar arbetet med att hitta, förstå och tillämpa en instruktion. Granska utkastet där det ska användas:

W3C:s vägledning förklarar att korta, vanliga ord och kortare meningar i allmänhet är lättare att avkoda, samtidigt som det påpekas att komplext ämnesinnehåll kan vara lämpligt för en specialiserad målgrupp. Redigeringen bör därför minska onödiga svårigheter utan att ta bort nödvändig precision. Förenkla inte bort ett villkor som påverkar resultatet.

Använd tabeller för återkommande jämförelser, numrerade listor för sekvenser och korta stycken för resonemang. Om ett steg kräver ett beslut ska villkoret stå omedelbart före handlingen. Om en term är oundviklig ska du definiera den första gången den används och sedan använda samma term konsekvent.

Läs artikeln en gång som en person som skumläser och en gång som någon som utför uppgiften. Den som skumläser ska kunna hitta det utlovade resultatet, förkunskapskraven och vägen till svaret. Den som utför uppgiften ska kunna följa stegen utan att behöva återskapa författarens tänkta ordning.

Den bästa kontrollen före publicering är ett litet uppgiftstest med en person som liknar den avsedda läsaren men inte har skrivit utkastet. Ge personen uppgiftsbeskrivningen och artikeln. Be hen arbeta självständigt och bara berätta var hen letar eller vad hen behöver – inte om hen tycker om artikeln.

Observera om personen:

Dokumentera konkreta friktionspunkter: ett saknat fält, en tvetydig etikett, ett överhoppat villkor, ett oförklarat resultat eller ett externt beroende. Betrakta inte en läsares lyckade gissning som bevis för att artikeln är tydlig. Fråga: ”Vad i artikeln fick dig att göra så?” Om svaret är ”Det visste jag redan” kan utkastet fortfarande ha en lucka.

Efter testet klassificerar du varje problem som blockerande, fördröjande eller kosmetiskt. Åtgärda blockerande problem först: saknade förkunskapskrav, farlig tvetydighet, felaktig ordningsföljd och saknade vägar för undantag. Testa sedan den ändrade vägen igen. Ett läsartest visar inte att innehållet är användbart för alla, men det kan avslöja om någon annan än författaren kan utföra den angivna uppgiften.

Analysdata kan visa vad som hände efter publiceringen – till exempel besök, sökningar, avhopp eller interaktioner – men bevisar inte i sig att läsaren slutförde uppgiften. Ett kort besök kan betyda att svaret hittades snabbt; ett långt besök kan betyda att läsaren var förvirrad. Betrakta beteendedata som en utgångspunkt för vidare undersökning, inte som en ersättning för granskningen av vägen till slutförd uppgift.

Om data finns tillgängliga ska du koppla dem till en specifik hypotes: ”Läsarna kanske inte hittar förkunskapskravet” eller ”Felsökningsgrenen kanske är otydlig”. Granska det relevanta avsnittet, upprepa uppgiftstestet och revidera bara när beläggen stöder ändringen. Förvandla inte ett mätvärde till ett påstående om nytta utan att observera eller på annat sätt verifiera läsarens resultat.

Googles vägledning om innehåll för människor ber innehållsskapare att bedöma innehållets kvalitet, källor, fullständighet och om läsarna når sitt mål. De frågorna stämmer överens med den här granskningen, men inget dokument från ett söksystem kan garantera att ett enskilt utkast löser en enskild uppgift. Det redaktionella beslutet grundas fortfarande på utkastet, dess belägg och den observerade vägen.