Jag läste en artikel om User Experience (användarens upplevelse av en produkt) häromdagen. En person hade kommenterat texten med den väldigt vanliga kommentaren om UX. Han sa att “allt vi behöver göra är att låtsas vara en användare och utvärdera vad vi har byggt ur den synvinkeln”. Detta håller jag tyvärr inte med om. Vi är alltför partiska som produktdesigners och utvecklare, vi känner till för mycket om hur produkten fungerar. Dessutom tillhör vi troligast inte den avsedda målgruppen, vi kommer inte att använda produkten i en faktisk situation för att lösa ett faktiskt behov, så det kommer bli mycket svårt för oss att låtsas tillräckligt.
Men vad vi kan göra är att luta oss tillbaka på forskningsresultat som kan appliceras på de allra flesta människor och därmed de flesta av våra användare. Dessa resultat kallas designprinciper och med deras hjälp kan vi lyfta vår produkt upp till en bättre nivå. Detta är det minsta du kan och bör göra för dina användare.
Nedan har jag listat de designprinciper som jag oftast använder. De är hämtade från Nielsens 10 tumregler, Shneidermans 8 gyllene regler, Benyons 10 principer för interaktionsdesign och Usability Body of Knowledge. Vissa principers namn är svåra att översätta till svenska, därmed har jag behållit allihopa på engelska.
Stöd användarens mentala modell…
- Consistency – Använd samma användningsmönster för olika men liknande funktionalitet i produkten. Var konsekvent gentemot liknande produkter, följ standarder och konventioner. Notera att både konceptuell och faktisk konsekvens är viktig.
- Familiarity – Ta reda på vilka produkter din avsedda målgrupp använder idag och följ konventioner i dessa. Använd allmänt kända begrepp och uttryck. Om konceptet är helt nytt, finn en passande metafor som hjälper dem att överföra gammal kunskap till den nya domänen.
Hjälp användare att förstå vad hen ska göra…
- Simplicity – Skapa den enklaste design som löser problemet. Eliminera onödiga steg och element i produkten så att användaren kan fokusera på uppgiften.
- Constraints – Begränsa användaren så att hen inte kan göra saker som är olämpliga i produkten. Specifikt bör man hindra användare från att göra allvarliga fel genom att begränsa möjliga vägar och söka bekräftelse på farliga operationer.
- Affordance – Designa funktioner så att det blir självklart hur de fungerar. Exempelvis bör knappar alltid se ut som knappar och länkar alltid se ut som länkar.
Se till att användaren känner sig trygg…
- Visibility & Feedback – Försök att synliggöra vilka funktioner som finns och vad systemet gör för tillfället. Konstant och konsekvent återkoppling kommer att öka användarens känsla av att ha kontroll.
- Recovery – Tillhandahåll enkla sätt för användaren att ångra sig eller återgå i produkten, speciellt när det gäller misstag och fel som uppstått. Detta inkluderar att alltid ge användaren en utväg om ett visst vägval var oavsiktligt.
Behandla användaren väl…
- Conviviality – Utforma produkten så att den är artig, vänlig och allmänt trevlig. Ingenting förstör en produkt mer än ett aggressivt felmeddelande eller ett abrupt avbrott i användarens arbetsflöde. Gemytlighet är ledordet.
Vi kan använda de här designprinciperna för att reda upp existerande problem i vår produkt men när vi designar nytt. För att hitta problem kan man gå igenom produkten med en designprincip i åtanke i taget och försöka finna oegentligheter. För att designa nya funktioner på bästa sätt, lär dig och ditt team de här (väldigt få) designprinciperna.
Kom ihåg att för att ta användarens upplevelse av din produkt till riktigt bra nivå så måste du validera med faktiska användare. Annars kan vi inte kalla det för användarens upplevelse, eller hur?
Jag kan bara hålla med. Jag använder ofta designprinciper i den projekt jag är med i. Det fungerar både när jag gör expertutvärderingar. Designar nya system eller sysslar med research.
Ofta är det ett bra ramverk för en själv när jag arbetar och ser mig själv som målgrupp. Ofta fungerar de bra att kommunicera till produktägare och beställare (vem vill inte ha ett bra system?) men det jag märkt är att det kan vara lite svårt att kommunicera till utvecklare. Ofta tycker de att de är för flummiga och de inte har hjälp av dessa i sitt vardagliga arbete. Ofta får jag bryta ner principerna till designmönster och atomer för att de ska förstå kopplingen till det de arbetar med.
Håller du med?
Tack Jens! Skönt med support. 🙂
Jag har nog oftast lyckats kommunicera principerna till utvecklarna också, utan att behöva skapa designmönster, men då har jag förstärkt principen med några blandade exempel.
Bra sammanslagning! Skönt att man slapp göra den själv. Nielsen’s heuristics har ju några år på nacken nu och har fått sällskap av andra rön. Får jag extremt tråkigt nån dag kanske jag ger mig på att hitta svenska rubriker. Kanske. 😉