Användarens förvirring är din bugglista

”Hur gör jag X?”

Om samma fråga återkommer i supporten vill jag se vad som händer innan kunden ställer den. Ofta finns något i gränssnittet, texten eller flödet som vi behöver ändra.

Det är bekvämt att kalla det en användarfråga. Då kan någon svara och stänga ärendet. Men kunden imorgon kommer kanske fastna på exakt samma ställe.

Frågan är början på undersökningen

”Varför fick jag inget mejl?” kan betyda att bekräftelsen är otydlig. Det kan också betyda att mejlet faktiskt inte skickades.

”Hur avslutar jag prenumerationen?” kan bero på en svårhittad funktion, en oklar text eller ett krångligt arbetssätt.

Gissa inte orsaken för snabbt. Följ förloppet och se vad personen försökte göra. Annars riskerar ni att förbättra en knapp när felet ligger någon helt annanstans.

Gör återkommande frågor till förbättringsarbete

Samla de vanligaste frågorna och gruppera dem efter vad användaren försöker åstadkomma. Gå sedan igenom var det tar stopp.

• Saknas information innan personen börjar?
• Går det att hitta rätt funktion?
• Förstår man vad som har hänt efter ett klick?
• Fungerar det tekniska flödet?

Välj ett återkommande problem och ändra det som verkar orsaka frågan. Följ sedan upp både supportärendena och om användarna lyckas utföra uppgiften.

Färre frågor är bra om folk klarar sig själva. Det är mindre bra om de har gett upp eller inte längre hittar hur de ska få hjälp.

Ibland behövs en förklaring

Alla frågor är inte designfel. Vissa uppgifter är komplicerade, vissa begrepp behöver förklaras och nya användare kan behöva stöd.

Men en FAQ ska inte bli en ursäkt för att lämna ett uppenbart problem orört. Om ni måste förklara samma onödigt krångliga steg varje vecka är det rimligt att försöka förenkla steget.

Supporten har redan kontakt med dem som fastnar. Se till att den kunskapen når dem som kan ändra produkten.