UX-kurs del 16: Nu knyter vi ihop säcken!

Bina på bilden har inget med texten nedan att göra. Inte mannen heller.

Hej å hå!
Det här blir sista kraschkursinlägget för den här gången. Jag tänkte att jag ska försöka knyta ihop säcken lite grann. 

Den här "kursen" har syftat till att ge enkel info kring vad en UX-mupp jobbar med och varför. Vi började med att prata om vad UX egentligen är, för att gå vidare och jiddra om grejer som handlar om informationsinhämtning och att identifiera mål och såna grejer. Sen trillade vi hastigt och lustigt in på interaktionsdesign för att avsluta det hela med några inlägg om strategier och liknande.

Det blev lite rörigt  och om jag hade kunnat gå tillbaka i tiden så hade jag kört i en annan ordning. Något sånt här kanske det borde ha sett ut istället för kökkenmöddingen som alla ni fans fick stå ut med:

UX-kurs del 1: Vad är UX?
UX-kurs del 14, UX-strategi
UX-kurs del 15, service design
UX-kurs del 2: Mål som mål
UX-kurs del 3: Mål som mål, del två
UX-kurs del 4: researchdags!
UX-kurs del 7: Workshops
UX-kurs del 5: Intervjumetod
UX-kurs del 6: Bias
UX-kurs del 8: personor
UX-kurs del 12, informationsarkitektur
 UX-kurs del 9: Interaktionsdesign, grunderna. Typ
UX-kurs del 10: interaktionsdesign, designmönster
UX-kurs del 11: Interaktionsdesign, använd hjärna dessa principer
UX-kurs del 13, användningstester


I alla fall. 

Jag har fått frågan om hur man kan tänka kring alla dessa fantastiska visdomar och hur man kan använda dem i verkligheten. Som den ödmjuka tjänare jag är så ska jag försöka ägna resten av inlägget år någon form av säckihopknytning. Men först så listar jag några grejer som visar att du jobbar på ett ställe som INTE håller på med design.

Hur jobbar man inte med UX i en organisation?

• "Vi vet redan vad användarna vill ha" Intressant, berätta mer om hur ni på ett magiskt sätt kan veta vad användarna "vill ha"!
• "Vi har inte tid med att träffa användare, vi testar internt istället" Kul, för ni som jobbar med grejen sedan flera år tillbaka kan säkert sätta er in i en användares situation...
• "Det är för dyrt" Nej. Det som är dyrt är att göra något som ingen vill eller kan använda.
• "Det är asviktigt med UX, men just i det här fallet har vi redan koll" Har ni? Nej det har ni inte.
• "Jorå, vi kör UX, kolla bara på skisserna jag gjort". UX är inte samma sak som att rita interaktionsdesignskisser, gaddammit!

Istället för tramset ovan så kan det gå till så här:

Strategiskt mumbojumbo

Till att börja med måste vi förstå att UX handlar om att skapa och leverera en produkt/tjänst som är anpassad efter användarnas och kundernas behov. Grejen man bygger och säljer måste underlätta livet för en eller flera målgrupper, så produktstrategin måste innehålla ett UX-tänk, annars går det åt skogen. Vidare så måste man se tjänsten i sin helhet. Det räcker inte att ha en kalasbra app om kundtjänst inte funkar. Och vice versa. En UX-designer måste förstå hela tjänsteupplevelsen och ha möjligheter att hjälpa till med att förbättra den. 

För att förstå de behov som finns måste vi blir bra på att på riktigt samla in och analysera de behov och drivkrafter som finns. För att göra det så måste man träffa riktiga användare/kunder. Det är ett rekvisit för förståelse. Punkt slut. Stjärnstopp. Det går inte att sätta sig in i någons upplevelse av något om man aldrig träffar personen och kollar läget. Det här fattar de flesta rent intuitivt, men ibland så kör man fast redan här, av de orsaker som jag listat ovan. 

Utöver de här sakerna så har vi såklart rena metodgrejer som måste in i strategin. Exempel: Ska vi jobba med lean ux? Vad har det för implikationer vad gäller kravställning och utvecklingsmetodik? Vad händer om vi stannar kvar med den metoden vi använder idag? Fördelar, nackdelar? Vi kanske kan göra ett experiment?

Ska det här med UX funka så måste du alltså vara med och fatta beslut på strategisk nivå. Fast det räcker inte. Läs vidare!!!

Var som en smittsam sjukdom

Smittsamma sjukdomar sprids när folk nyser på varandra. Typ. De är nära varandra och utbyter snor och/eller andra kroppsvätskor. På ungefär samma sätt ska du som vet en massa grejer om användarna se till att fler personer än du får kunskap. Jag menar såklart inte att du ska snora ner dina kollegor, men jag menar att du ska träffa dem och berätta för dem vad du lärt dig. På så sätt kan även en person som aldrig träffat en riktig användare få någon sorts uppfattning om varför vi gör det vi gör och hur vi tillsammans kan förbättra upplevelsen för användarna. Genom kundresekartor, intervjuanteckningar och personor kan alla få insikter i användarnas behov och dessutom förstå att alla delar av organisationen måste samverka för att användarupplevelsen så bli så göttig som möjligt.

Sunka ner dig

Jag menar inte bokstavligt alltså. Du måste fortfarande borsta tänderna och byta småbyxor med hyfsat jämna mellanrum. Det jag menar är att det räcker inte med att se till att produktstrategin har ett designperspektiv eller att du vet en massa om vad folk som använder eller vill använda din tjänst behöver. Det räcker inte ens att du berättat för folket runt omkring dig vad du lärt dig. Det du behöver göra nu är att omsätta din strategi och dina kunskaper i praktiken. Skita ner naglarna. Och hjälpa kollegorna att göra samma sak. 

En viktig grej, kanske den viktigaste, är att jobba nära, både fysiskt och organisatoriskt med alla de som skapar något som en användare kommer i kontakt med. Om du ska vara med och göra en redesign av en del av sajten så sitter du såklart tillsammans med utvecklarna. Om du ska hjälpa till med first line support-grejer så jobbar du såklart med supportavdelningen. Om du är med i ett projekt som går ut på att synka språkbruk och begrepp som används så ser du till att folk från alla avdelningar samverkar i projektet.

Alltså: Se till att du alltid jobbar med de personer som producerar något som kunderna/användarna kommer i kontakt med. Du ska INTE sitta själv och drömma ihop grejer som du sedan i ensamt majestät delar ut till massorna som om det vore en sanning. Viktigt! OK?

Börja om från början

Så snart du fått ut något till en användare, och det kan röra sig om en skiss eller ett koncept, så börjar det hela om från början. Stämmer de antaganden på strategisk nivå som du gjort? Funkar den här grejen tillsammans med de andra grejerna vi kommunicerar till kunderna? Hänger alla på firman med varför det var viktigt att bygga den här nya grejen? Om svaret på någon av frågorna är nej så måste du se till att justera och förändra så att allt flyter på. Och ju längre feedbackloopar desto trögare blir det ju såklart att justera något som visade sig vara mindre bra. Det kan till och med ett barn räkna ut.

Till och med ett barn (så länge det är hyfsat begåvat) kan också räkna ut att saker som "magkänsla" och "för att jag säger det (och jag är din chef)" är dåliga mätmetoder för att se om det man gjort är bra.

Sammanfattningsvis, dårå

Ska det här med UX funka, och det måste det göra, annars kommer ni stå med missnöjda kunder en dag (med allt vad det innebär), så bör UX-grejerna genomsyra hela verksamheten. Det räcker inte att bara köra strategi-muppande och sedan glömma bort att själva knapparna på sajten måste vara najs att trycka på. Det räcker heller inte att skippa de strategiska delarna av UX och sedan tro att man kan fatta rimliga beslut kring vad som ska byggas och hur, eftersom besluten då dras ur en hatt. 

När man väl har gjort en grej så måste man se om det man gjorde blev bra eller inte och ju större grejer man gör i taget, desto svårare och mer omständligt blir det att utvärdera. 

Sådär, då jag jag samlat ungefär 15 års erfarenhet (eller är det ett års erfarenhet och 14 års upprepning?) i 16 blogginlägg. It´s been av wild ride, men jag kommer snart tillbaka. Jag har nämligen till allas stora glädje/förskräckelse/likgiltighet en massa andra UX-relaterade prylar jag vill skriva om...

UX-kurs del 15: Service design

GREAT service experience!

Hej Interwebs!

Första gången jag hörde talat om service design kan ha varit omkring 2009 och de senaste fyra-fem åren har det blivit ett hett begrepp och många som tidigare titulerat sig som ux-designer vill också kalla sig service designer (kolla bara min linkedin-profil. Jag är inte bara ux-designer, utan även service designer!...). Mest, tror jag, för att positionera sig. För faktum är att jag uppfattar service design och UX-design som ungefär samma sak. I alla fall. Idag ska vi prata service design. Det kan också kallas för tjänstedesign och själv använder jag båda begreppen omväxlande lite oproffsigt och förvirrande sådär.

Vad är service design? Enligt wikipedia: 

"Service design is a form of conceptual design which involves the activity of planning and organizing people, infrastructure, communication and material components of a service in order to improve its quality and the interaction between service provider and customers (min kursivering)."

Det handlar alltså om att förbättra kundupplevelsen genom att ta hand om kundupplevelsen. Det vill säga samma sak som UX-design. Det som service designern gör som ux-designern traditionellt inte har gjort är att se till helhetsupplevelsen. Idag är det dock ingen skillnad som jag ser det, men det finns vissa artefakter (leveranser alltså) som kan ingå i ett uttalat service design-uppdrag. Och den mest service designiga av alla service design-grejer är den heliga kundresekartan.

Upplevelsekarta eller experience map eller kundresekarta eller customer journey map

Jag tycker att ovanstående begrepp är ungefär samma sak, medan en del förmodligen får en stroke när jag klumpar ihop dem på detta blasfemiska vis. Men det är deras problem, inte mitt. Jag är väldigt förtjust i den här typen av kartor och jag önskar att jag själv uppfunnit. dem. Men eftersom jag blott är en hantverkare och inte någon visionär så får jag helt enkelt nöja mig med att bruka hammaren, inte uppfinna den. Orsaken till den (besvarade) kärleken är att jag gillar att man ganska enkelt kan visualisera något som är ganska komplext. 

En sån här karta innehåller en kunds kompletta upplevelse av en tjänst och kan delas upp i olika faser, typ före under och efter nyttjande av tjänsten. Utöver det har vi de kontakter kunden har med tjänsten och även vilka delar av leverantören av tjänsten som påverkas av och påverkar kunden. Sjukt bra uppfinning, detta. Eftersom jag inser mina måleriska och beskrivande begränsningar i det skrivna språket så kan den nyfikne kolla in bilden nedan. Den föreställer exemplet blodgivning och återspeglar mina upplevelser som blodgivare. I verkligheten så hade man förstås använt de researchmetoder om jag beskrivit tidigare (intervjuer, statistikkollande, observationsstudier, prototyping etc), men nu får det bli att jag som vanligt drar exemplet ur min hatt:

Ponera att vi fått i uppdrag att hjälpa landstinget att få fler att ge blod.

Först tar vi fram en sorts grund, där vi delat upp upplevelsen av blodgivning i olika faser, samt upplevelser, positiva och negativa:

Det verkar ju, baserat på vår research, som att det största hindret inte är att få folk att gilla blodgivning, utan de största problemen med upplevelsen finns någon annanstans. Steg två kan bli att försöka visualisera upplevelsen i form av en linje:

Deppigt att steget innan besöket drar ner helhetsupplevelsen :(

Se där, ja. Folk tycker själva "ta sig till blodgiveriet" är jobbigt. Det är svårt att faktiskt ta sig iväg till blodcentralen och ge blod. Det är ju en tydlig dipp där i mitten! 

Nästa steg är inte att dippa deppa ihop, utan istället försöker vi hitta ställen där vi utan allt för stora åthävor kan skapa positiva effekter och på så sätt nå målen:

Titta! de ändringar vi vill ta tag i lyser som små solar! Yey!

OK, nu vet vi vad vi vill åtgärda, men vem ska ta tag i detta? Vem ska "äga processen"? Här kommer en ny dimension in, nämligen att vi internt kan använda kartan till att kommunicera det vi vill ändra. Och om vi har en gemensam bild av vad vill vill fixa till så blir det enklare att få med alla som behövs på samma linje/tåg/enas/hitta en gemensam värdegrund etc. Kolla:

Och pow! så är det hela inte ett webbporjekt längre!!

Det visar sig att vissa av grejerna vill vill fixa till inte har så värst mycket med webben att göra, utan till exempel så har ju flera av blodgivarna sagt att de skulle ge blod om de kunde gör det efter jobbet. Det blir plötsligt en fråga för personalavdelningen och facket att ta hänsyn till. Samtidigt så måste vi ju ta reda på om det verkligen stämmer. En ur UX-teamet tar på sig att kolla upp om det är vanligt att folk helt enkelt inte har tid att ge blod.

Dessutom så verkar det ju som om folk inte vill fylla i hälsodeklarationen på centralen, utan vill göra det på väg dit. Vad gör man då med datorerna som står där? Behövs de fortfarande? Lokalansvarige får ta den pucken.

Nåväl. Efter ett litet tag så har vi genomfört vissa ändringar och hur ser det nu ut med den allmänna upplevelsen? Jo, kolla här:

Kom igen nu, personalavdelningen. Vad händer? Och mobilteamet, tar ni tag i formulären nästa sprint eller?

Jo men kolla, hälsodeklarationen går nu att fylla i på telefonen! Sweet! Man loggar bara in med E-leg, så är det klart när man är framme. Men andra delar går inte riktigt lika bra. Strunt samma, det verkar ju ändå som att helheten förbättrats! Nu är det bara att kolla om det leder till fler blodgivningar. Vilka mål hade vi satt upp nu?

Det finurliga

Det finurliga med det här upplägget är alltså att alla i en organisation får en gemensam bild över hela tjänsteupplevelsen och inte bara den lilla tårtbit som ingår i ens eget stuprör.

OK, det var Service design, det. Men håll i hatten, för inom kort kommer det en sammanfattning av hela kraschkursen!

UX-kurs del 14: UX-strategi

Innan vintern ska vi ha intagit Moskva, tagit fram personor och gjort användningstester!

Oh. My. God. Strategi. Hur jävla coolt är inte det? Man måste ha en strategi, annars kollapsar allt, det vet ju alla. Eller hur? Och en strategi bör vara genomtänkt in i minsta detalj, och en strategi ska vara frukten av många års hårt arbete, för hur ska man annars kunna veta att den är sann?

Well, det är klart man bör ha en strategi för användarupplevelsen, men tyvärr är ordet strategi behäftat med en massa jobbiga undertoner som ställer till det en del när man använder det begreppet. Strategi kommer från den militära världen men strategi i IT-världen och strategi i den militära världen är inte riktigt samma sak. Om du frågar en militär om strategi så handlar det i princip om hur man ska göra för att skydda sitt land, på en väldigt hög abstraktionsnivå och med mängder av inräknade parametrar. Det handlar alltså om grejer på internationell nivå. 

När vi pratar UX-strategi så bör det vara lite mindre uppstyrt. Men inte i betydelsen slappt, utan i betydelsen lättrörligt och mer kortsiktigt. För saker som är väldigt uppstyrda och väldigt långsiktiga tar lång tid att ta fram. Och saker som tar tid att ta fram hinner bli gamla innan de sjösätts.

Vad är du UX-strategi och hur fixar man ihop en sån?

Jo, UX-strategi handlar i korthet om hur du ska möta användare/kunder och hur de ska hjälpa dig att uppnå de verksamhetsmål som finns. "Men håll i dina hästar nu, säger den minnesgode, det här låter ju lite om en effektkarta?"

Ja, vilken lustig slump va? Givetvis är det så att du kan använda en effektkarta för att dokumentera din ux-strategi och givetvis är det så att du kan använda metoden effektkartläggning för att ta fram din ux-strategi. Finurligt! Det räcker alltså med att vara någorlunda haj på effektkartläggning så kan du skriva ux-strateg på din linkedin-profil!?

Nja. Det kräver faktiskt lite mer. Till exempel är det ju en bra idé om du kan hjälpa till med att identifera just UX-aktiviteter som ska bidra till med att nå målen. Och för det kanske du måste ha åtminstone ett par fler ess i rockärmen än bara effektkartor.

Så vilken typ av frågor behöver din ux-strategi svara på? Jo det rör sig om saker som gör att din tjänst/produkt/grej blir mer populär hos kunderna/användarna, till exempel. Jag drar som vanligt hypotetiska exempel ur min hatt, men det kan exempelvis vara:

• Vilka är våra kunder/användare?
• Gör Målgruppsanalys med intervjuer etc
• Titta i våra analysverktyg för att kombinera statistik med kvalitativt
• Hur ska vi nå fler kunder/användare?
• Analysera intervjuresultat
• Benchmarka mot våra konkurrenter, vad har de som vi saknar och vice versa?
• Vilka drivkrafter har kunderna/användarna?
• Intervjuer med användare
• Vad saknar vi för att tillgodose deras drivkrafter?
• Gör en genomlysning av vår verksamhet- supportkedjan, marknadsföring, kundbemötande i sociala medier etc för att förstå vad vi behöver ändra internt
• Jämför vår upplevelse av oss själva med kundernas/användarnas bild av oss
• Hur gör vi för att tillgodose dem?
• Ta fram actions på de svagheter som finns och utvärdera kontinuerligt
• Vad i vår tjänst har svagheter och var finns styrkorna?
• Gör en kundresekarta och identifiera svagheter och styrkor

Om du jobbar med att försöka införa en designkultur i din organisation så kanske andra typer av punkter också ingår, som till exempel:

• Hur gör vi UX-aktiviter mer synliga på företaget?
• Skriv anteckningar när du intervjuar användare och skicka ut till kollegorna
• Ta fram personor och distribuera till alla på företaget
• Bli bättre på att sätta upp designskisser och liknande på väggarna, så att alla får se vad vi håller på med 
• Hur får vi kollegorna att få upp ögonen för vad UX är?
• Få kollegorna att läsa om och prata om den där ux-kraschkursen som finns på webben
• Ett par kollegor deltar på användningstesterna varje gång
• Köp in lättlästa böcker och diskutera dem med kollegorna
• Ha återkommande UX-designföreläsningar

UX-strategin är alltså ett sätt att identifiera mål, ta fram nuläge och se vad som kan göras för att målen ska uppstå. 

UX-kurs del 13, användningstester

Ett misslyckat missiltest eller en illustration av iterativt arbete!?

Om interaktionsdesign är UX-designens grundbult så är användningstester en sorts UX-designens heliga graal. Med ett användningstest kan du få alla stakeholders att kräla i stoftet inför dig.

Nåja, inte riktigt kanske. Men användningstester är jäkligt bra om du vill se hur en person interagerar med en produkt. Och det är bra med tanke på att en UX-designer rätt ofta ägnar sig åt att ta fram produkter. 

En del tycker att användningstester inte är så himla nödvändiga, för det går ju lika bra att kolla av grejerna själv. Joråsåatteeee... Faktum är att om det finns en tjänst du gillar och som är enkel att använda så är sannolikheten rätt stor att grejen har blivit användningstestad. 

En del företag har testlabb med envägsspeglar, kameror i alla upptänkliga vinklar och så vidare. Det är säkert skitbra med såna labb på många sätt. Men jag har ärligt talat rätt svårt att tänka mig en avslappnad testperson sittandes i ett sånt här labb:

"Känn dig som hemma, bry dig inte om den enorma spegeln bakom dig." Design (kanske) by Josef Fritzl.

Dock: jag får väl erkänna att jag aldrig har jobbat med ett sånt här labb, så bry er inte allt för mycket om det jag skrev ovan.

I alla fall.

När ska man göra användningstester? Och blir det inte väldigt dyrt? är frågor man kan ställa sig. Ok, jag låtsas att någon ställde just de frågorna. 

Svaren är att du ska göra användningstester oftare än du tror och det är inte dyrt. Men för att det här inlägget inte ska vara superkort så tar jag och utvecklar det hela lite.

Är det inte jäkligt dyrt?

Nej. Det är inte jäkligt dyrt. Att bygga en produkt och plöja ner mängder av timmar och energi och pepp, bara för att se den floppa pga obegriplighet och sugigt användargränssnitt är dyrt. Det är däremot väldigt billigt att ett par gånger i månaden stämma av om det man tror är en gudomligt smart idé är en gudomligt smart idé, eller om man drömt ihop något fullständigt vansinnigt pga group think och andra lustiga företeelser. Du gör tester för att det ska bli bra och då blir det billigare i slutändan. 

Kostnadsaspekten hänger ibland ihop med en sorts rädsla att kraschtesta sin design. För tänk om det inte var något bra, hur blir det då med min streetcred på företaget? Den här rädslan maskeras ibland med en kostnadsaspekt: "Närå, vi kan testa internt, vi vet vad användarna vill ha. dessutom blir det jäääkligt dyrt och vi ligger redan efter i tidplanen. Kolla bara mitt GANTT-schema här. Nästa milestone är redan på måndag. Mmm-kaaayyy?"

Den här oviljan att utsätta sina idéer för verkligheten är märkligt nog rätt vanlig hos folk. Kanske särskilt hos de som har mycket att förlora på att idén är dålig. Men det är väl rimligtvis bättre att testa om idén är bra INNAN den stora releasedagen? Kan man tycka.

Hur gör man användningstester?

Att göra ett användningstest är ingen särskilt avancerad apparat. I alla fall om man inte vill göra det till en sådan. Men då blir det dyrt. Och vi vill inte att det ska vara dyrt. Det finns en fin bok som Steve Krug skrev en gång i tiden. Den heter Rocket surgery made easy. Förutom att bokens titel är fullkomligt brilliant (jag gubb-skrockar nöjt varje gång jag tänker på den) så är innehållet väldigt bra. Den behandlar hur man gör användningstester billigt och enkelt och utan utrustning som påminner om CIA:s Polygraph-test. Men eftersom jag av copyrightskäl förmodligen inte får citera hela boken här så gör jag ett eget försök av mina egna erfarenheter. Here we go:

• Ring några personer. Helst såna som tillhör målgruppen, men i värsta fall går det bra med vem som helst. I alla fall om det ni designar inte är något superspecifikt. Men ponera att du är med och tar fram en tjänst som ska hjälpa folk att matcha ihop folk som har beggade kläder med folk som vill ha beggade kläder, då går nog vem som helst bra att använda som testperson. Om du designar ett nytt VR-gränssnitt för stridspiloter kanske du inte kan höra av dig till kompisarna i Mammagruppen, däremot. Förutsatt att ingen av dem är stridspilot förstås. Be dem komma och hälsa på på kontoret med en timmas mellanrum ungefär. Eller för added mysighet: besök dem hemma eller på deras jobb om det är ok för dem.

• Förbered ett test. Ofta brukar jag försöka testa av grejer som jag har en känsla av är lite skeva och såna grejer som är centrala för att hela konceptet ska hålla ihop. Testet brukar innefatta dels lite "hur känns det här då" -frågor och "vad tror du händer om du gör så där"- frågor, men framför allt så brukar jag sätta ihop några scenarion. Till exempel: "Du är trött på att garderoben är full av kläder du inte använder, men orkar inte gå ner till stadsmissionen. Istället har du beslutat att ge bort dem. Här har du en app på din telefon, kör hårt!" Eller "Det plingar till i telefonen, ett sms säger att du har en intressent för en av dina klädhögar. Vad gör du nu?" Sen får testpersonen helt enkelt berätta vad den gör och visa på de skisser/den prototyp/ det färdiga systemet eller vad det nu kan vara.

• När några personer har gjort samma test (en och en givetvis), så sammanställer du dina observationer. Förhoppningsvis så upptäcker du ett mönster i deras beteende och vips så har du förbättringsförslag. Bra va!?

• Justera det du upptäckte och börja om från början. Till slut har du the design to rule them all.

"Men Eric", frågar nu den präktiga eleven längst fram i klassrummet, "hur vet jag att jag har hittat alla problem med designen?" Jag är glad att just du ställer just den här frågan. Svaret är att det vet du inte. Jobbigt va? Men du känner garanterat till fler problem med designen än du gjorde innan. Eller hur? 

Om man inte upptäcker några risker med sitt designkoncept så har man förmodligen gjort minst ett av två (eller flera fel):

Man var för feg när man tog fram sitt designkoncept och/eller testet är felaktigt genomfört på något vis. Man kanske väldigt väldigt gärna vill att testet ska "gå bra" och hjälper testpersonerna lite för mycket om de kör fast, till exempel. Ett test utan jobbiga resultat är en varningsklocka. Så sluta vara feg som ux:are och sluta upp med att fuska med testerna. Det är som att fuska i patiens. Meningslöst.

När gör man användningstester?

Så fort och så ofta man orkar. En del verkar ha fått för sig att ett användningstest endast kan göras på en färdig eller nästan färdig produkt, för annars går det ju inte att klicka på knapparna. Ja, det låter ju väldigt rimligt. Jag är säker på att det är så man gör när man ska testa om en ny typ av bromsar funkar på en bil: Bygg klart hela bromsssystemet och sen ut på vägarna. Full fart, ba! Annars vet man ju inte om det funkar for realz.

Nej. Givetvis testar man även på tidig konceptnivå, fast då har testet kanske ett annat tema. Istället för att kolla om knapparna sitter rätt så kanske man ser ifall den konceptuella idén överhuvudtaget är begriplig eller om man varit för smart när man tog fram det nya konceptet. Men man testar också färdiga, halvfärdiga och trekvartsfärdiga produkter.

Hur ska man dema testresultatet?

För det första är det absolut bästa om chefens chef sitter med på testet, förutsatt att hen kan hålla flabben under testets gång. Annars blir det rött kort. Även andra personer ur teamet är hemskt gärna välkomna. Men någon måtta får det vara: man kan ju inte sitta där 12 personer och glo på när någon stackare försöker få ordning på det designförslag som testas. Stämningen kan nog bli lite lätt awkward då.

En annan bra grej kan vara att spela in det som händer på skärmen samtidigt som man spelar in det som testpersonen säger. Sen kan man köra en demo och visa alla hur muspekaren åker omkring samtidigt som testpersonen desperat pratar på om hur hen tänker. Det är sjukt effektivt. Det är också något som öker på komplexiteten ytterligare: en grej som diskuteras i UX-kretsar är vilka screenreaders som är bra och det är rimligtvis ett tecken på att den här approachen är lite omständlig. Men om du får den att funka så är det jäkligt mäktigt och funkar som ett sjukt starkt argument: "jaha, men du såg ju själv, fyra av fem hittade inte de FAQ-frågor de behövde. Det kanske kan tyda på något, eller vad tror du om det?"

Det vanligaste är nog annars att man helt enkelt, kanske med lite screenshots, berättar hur det gick. Det är minst effektfullt, men enklast.


Sammanfattningsvis: Användningstester är ett billigt och bra sätt att ta reda på om det man har designat är bra eller inte. Det funkar lika bra på koncept som på färdiga produkter.

UX-kurs del 12: informationsarkitektur

In soviet russia information architects you

Hej världen!
Idag ska vi prata om något som är sjukt viktigt när det gäller att skapa en begriplig värld, nämligen informationsarkitektur.

Vad är informationsarkitektur? Jo det är att identifiera grejer som på något vis är besläktade med varandra och sätta ihop dem till en begriplig struktur. Det här är ju såklart löjligt viktigt för en person som besöker en webbplats, men även i andra sammanhang avgör informationsarkitekturen om en persons upplevelse av något är bra eller inte. Om vi tar ett konkret, actual reality-exempel: 

Din lokala ica-affär

När du går in i affären så tänker du dig att yoghurten finns bredvid mjölken, och cornflakespaketen står bredvid hyllan med Start-müsli och knäckebrödet står nära skogaholmslimpan, men kanske ännu närmare rågbrödet.

På så sätt har du en mental bild av hur du kan hitta i butiken och även om du aldrig varit inne på just den här affären, så vet du att bara du hittar det nyttiga rågbrödet så finns din älskade skogaholmslimpa i närheten. Det är alltså informationsarkitektur i den faktiska verkligheten, där informationen består av riktiga grejer.

Det här låter ju rätt enkelt, men ibland tokar butikschefen till det (ja, jag tittar på dig nu, butikschefen för Ica Aspudden) och är lite för smart för sitt eget bästa. Hen tänker att "hey, vi sätter varmkorven, korvbrödet och ketchupen på samma ställe! Jag är ett geni!" Ja, det är du kanske, men om du har noterat hur 99% av alla andra butiker har ställt de här sakerna så kanske du ändrar åsikt? Rent informationsmässigt så är alla de här grejerna sammankopplade, men vår mentala modell över hur en mataffär är uppbyggd säger att detta är ett absurt sätt att gruppera grejer.

However: i den virtuella verkligheten så kan man lösa det här! Hur då? Jo, låt säga att du lagt varmkorv i din "varukorg". Då kanske webbsajten är så slug att den föreslår ketchup, korvbröd och folkisar också. Yeah!

Informationsarkitektur är kort sagt det sättet informationen på till exempel en webbplats är grupperad och sorterad. En bra informationsarkitektur är asviktig när det gäller att förstå hur ma hittar och var man hittar saker på webbplatsen. Och en bra informationsarkitektur är en informationsarkitektur som är begriplig för besökaren.

Gör inte så här!!

Hur som helst. 
När man tar fram en informationsarkitektur så finns det mängder av fällor att gå i. Jag tar upp ett par vanliga nedan:

• "Vår sajtstruktur ska återspegla vår organisationsstruktur! Det är logiskt och skitsmart!" Hell no, det ska den inte! Ett vanligt misstag att tro att en besökare av din webbsajt bryr sig om vilken avdelning som ligger under vilken i den internpolitiska/byråkratiska djungeln. Det finns INGEN besökare av en webbplats som är det minsta intresserad av huruvida marknad ligger under it eller kundtjänst. Ingen. Sajtstrukturen ska givetvis återspegla besökarnas uppfattning av vad som är en rimlig informationsarkitektur. Inte din. Som vanligt.
• "Jag vet vad som är vettigt, för jag är expert på området!" Ja och just för att du är expert så är det ett rimligt antagande att du INTE vet hur en normalanvändare tycker att informationen borde delas upp och sorteras. Abby Covert har ett bra exempel från ett informationsarkitekturuppdrag hon hade där hon hjälpte en frukt- och gröntdistributör att gruppera grejer: rent objektivt är avocado en frukt, men det bryr sig förmodligen ingen utom Carl von Linné (expert) sig om. De valde därför att gruppera avocado inom gruppen för grönsaker. Kolla in föreläsningen här (youtube). 
• "Hm, de här passar liksom inte riktigt in här, ska vi köra en "Övrigt"-kategori?" Nej det ska ni absolut inte göra. Det ni ska göra är att tänka en gång till och faktiskt se över hur de här sakerna kan grupperas. En övrigt-kategori är bokstavligt talat som att spela "Finns i sjön", det vill säga fruktansvärt.
• "Fuck informationsarktitektur, vi har en fet sökgrunka istället!" Feta sökgrunkor är ju asbra, men vad händer med de användare som inte gillar/förstår eller orkar begripa hur söken funkar? dessutom: någon ska väl ändå göra jobbet med att tagga upp allt så det blir sökbart på ett bra sätt. Eller ska det bara vara någon sorts fritextsök? Typ som stockholm.se verkar ha:

  

  Är det verkligen troligt att jag vill hitta något sorts protokoll från 2013 när jag söker på "förskola liljeholmen"?

Gör så här istället

"Men, hur ska man göra då, Eric? Detta verkar vara ett omöjligt uppdrag!" Nej det är det inte, ta det lugnt. Alltså, man ska ta reda på användningssammanhanget och baserat på det så ska man ta fram en informationsarkitektur. Och hur tar man reda på sammanhanget då? Jo, man pratar med den som beställt grejen man jobbar med OCH man pratar med de som förväntas använda grejen när den är klar. Har vi hört det förut? Ja, det har vi. Tjatar jag? Ja, det gör jag? Lyssnar ni? Ja, det hoppas jag.

Du måste prata med användarna av grejen. OK? OK.

UX-kurs del 11: interaktionsdesign, använd hjärna dessa principer

Old school hjärnforskning

Hej igen. Sist pratade vi om designmönster som kan vara bra att använda när du designar. En annan grej är att ha i bakhuvudet är att vi må vara de smartaste på jorden, men vi är bara apor med kläder på. Våra hjärnor är rejält begränsade när det gäller att hantera och analysera information. Det finns dock några knep man kan ta till för att underlätta hanteringen av ett användargränssnitt. Om man har koll på de här så kommer ens design bli rejält mycket enklare att begripa än om man bara blåser på utan koll.

Vi är ju som sagt en sorts apor (förlåt alla kreationister) och därför så funkar våra hjärnor på ett visst sätt.

Så om du vill designa något som är bättre än dåligt så är det bra att ha lite koll på några av de här kognitiva begränsningarna förutsättningarna.

Och för en gångs skull kommer jag prata om grejer som faktiskt går att belägga vetenskapligt. Effektkartors överlägsenhet, lean UX:s fantastiskhet, Personors magiskhet och så vidare är egentligen bara mer eller mindre kvalificerade gissningar, men vetenskap är vetenskap. Woho!

Arbetsminnet

Alltså, vi är inte så jäkla smarta. Vårt arbetsminne till exempel är skrattretande risigt, faktiskt. Och därför är det en bra idé att låta den stackars användaren av en tjänst att slippa tvingas ha en massa saker i huvudet när hen använder tjänsten. Eftersom arbetsminnet är så hopplöst svagt hos en människa är det en bra idé att begränsa antalet grejer som man måste hantera. En vis man (Ola heter han) sade en gång att det bästa användargränssnittet är en stor, skålformad knapp, och även om han är ute och cyklar så har han en poäng. Om du bara kan göra en grej i taget så blir det enklare att hålla ordning på vad som går att göra. Dessvärre så blir det en rätt begränsad tjänst, så det funkar nog inte i alla sammanhang. Men principen är bra. 

Enligt Cowan, som är en tvättäkta forskare (för en gångs skull), kan en människa hålla ungefär fyra grejer i huvudet samtidigt. Och med det i bakhuvudet så måste du som UX-person vara bra på att gruppera grejer på ett rimligt sätt.

Gruppering av grejer

Vi är bra på att tolka in att saker som på ett eller annat sätt liknar varandra också hänger ihop. Det är bra att ha i bakhuvudet när du designar. Kolla här:

 

Tre grupper av grejer. Komplexiteten ökar med först former, sedan färger.

Man märker sätt snart att det krävs någon form av gruppering för att få ordning på de färglagda formerna längst till höger. I alla fall om man är intresserad av att visa på någon form av samband. Kolla här nere vad som händer när jag grupperar:

Här ser vi tre olika grupperingar av den sista bilden ovan. Plötsligt blir det lättare att avgöra vilka former som hänger ihop.

Hur ska då detta översättas till "vår värld"? Vår rosaskimrande UX-bubbla? Jo låtsas att de olika formerna är grupper av funktioner eller kombinationer av funktion och information. Funktioner/information som på ett eller annat vis hänger ihop ska vara nära varandra. Då fattar förhoppningsvis de flesta ungefär hur ditt användargränssnitt ska tolkas. OK? OK.

Fitt´s law

Fitt´s law handlar i korthet om att ju större en grej är, desto lättare är det att träffa den grejen. Den här lagen går att beskriva matematiskt på en massa olika sätt. Men det behöver man inte lägga något avseende vid. Det viktiga är att hantera den här lagen när man designar. Det gäller inte minst (höhö) när du designar något som ska funka på en liten skärm. Det är ju såååå lockande att göra knapparna lite mindre, för då får det plats fler. Men fall inte för den lockelsen, ta istället bort allt krafs som inte är superviktigt, så kommer de stora fina knapparna få plats. Jag lovar.

Mentala modeller

Mentala modeller kan sägas vara en sorts designmönster som är baserade på människors tidigare erfarenheter. Ponera att du vill läsa en bok på webben. Det är första gången du läser en bok på webben. Det finns då ett par mentala modeller du kommer att använda dig av för att klura ut hur du gör. Dels den fysiska boken: du kanske kommer att "dra" i hörnet av sidan, eller swipa för att se om du kan "bläddra", eller så kommer du prova att scrolla i texten, för kanske boken funkar som en vanlig webbsida? 

Tyvärr är det så att en designer är ofta för smart för sitt eget bästa och bygger upp sin egna mentala modell för hur man borde interagera med e-boken. En mental modell som kanske inte delas med andra människor, särskilt inte den apa med kläder på som försöker läsa en bok på webben för första gången.
Folk använder sina mentala modeller för att försöka förutsäga hur appen, sajten, tjänsten funkar. 
Det är därför viktigt att man har lite koll på vilka mentala modeller de målgrupper man designar för har. Så att man inte designar något som är perfekt för en målgrupp bestående av en person, nämligen sig själv. 

För den som behöver rörliga bilder för att förstå kommer här ett exempel från lillebror i väst:

Hick´s law

Den här lagen beskriver hur antalet valmöjligheter ökar tiden det tar för en människa att fatta ett beslut. Ju fler grejer du kan välja mellan, desto längre tid tar det att bestämma dig. 

Låt oss illustrera med ett exempel: du är på ett konditori och ska köpa fika. Det finns fyra olika sorters chokladbollar, fem olika sorters kanelbullar, fyra olika sorters wienerbröd och så vidare. I värsta fall åker du på analys-paralys och kan inte ens besluta dig för vilken sorts fikabröd du ska ha till ditt kaffe (som finns i 14 olika varianter).

Jämför då det med att du ska köpa fika på ett ställe med sammanlagt fyra sorters fikabröd. Och kaffet finns med eller utan mjölk. Vad går fortast?


Det häftiga, med UX-mått mätt alltså, med alla de här principerna är att de hänger ihop ganska så tätt: Om du inte grupperar blir det svårt att bestämma var du ska titta och om du inte vet var du ska titta så tar det längre tid att sortera dina intryck och så vidare.

Den här "lektionen" riskerar att aldrig ta slut om jag inte bryter någonstans och det får bli här. Vilket på sätt och vis är synd för det finns fler spännande grejer i samma härad. Men det får bli ett annat inlägg

UX-kurs del 10: Interaktionsdesign, designmönster

Smörmönster

Åkej. Sist pratade vi ju lite om vad interaktionsdesign är och vad man har det till. Idag tänkte jag prata om den lates lösning, nämligen designmönster.

Ett designmönster är ett färdigt designkoncept för olika sammanhang och behov. Du känner till flera av dem varesig du vill eller ej. Till exempel hamburgerikonen, datumväljaren, ordbehandlarformateringsraden ovanför textytan. Och så vidare. Det finns även andra typer av designmönster som är mer konceptuella, som till exempel mobile first, som går ut på att man börjar designa för små apparater först.

jag tänkte prata lite kortfattat om hur du kan använda designmönster och var du hittar dem.

Men först ett varningens ord om designmönster. Det finns såna som är dåliga , för ett designmönster är inte automatiskt bra bara för att det existerar. Det är ungefär som mat. All mat som finns existerar, men all mat är inte god. Ät inte äcklig mat och använd inte dåliga designmönster.

Varför designmönster?

Du kör ett designmönster av två skäl: 

• Det är dumt att uppfinna hjulet om någon annan grottmänniska redan gjort det.
• Det är sannolikt att en användare känner igen något som finns på fler ställen. Igenkänning är svårt att överskatta i UX-sammanhang och är en sorts (med all rätt) helig UX-kossa.

Hur vet man då vilket designmönster som är bäst för just dina användare? Det vet man dessvärre inte. Designmönstren är en genväg, men det är ju inte säkert att det är rätt sorts genväg. För att veta det måste man testa grejerna. Som vanligt.

Alltså, det finns kanske inte så mycket mer att säga om designmönster. Eller så fins det massor, men jag föreslår att du istället kollar själv, så jag drar upp några länkar också:

UI-patterns

pttrns

Elements of design

Och en bra bok:

Designing interfaces

UX-kurs del 9: Interaktionsdesign, grunden. Typ.

Great UX!

Igår pratade vi om personor, idag blir det Interaktionsdesign. Interaktionsdesign är UX-designerns smör och bröd. Interaktionsdesign är, som den kvicktänkte kanske kan klura ut, att designa interaktion. Och än så länge handlar det oftare om att rita upp en webbsajt eller ett system och mindre ofta om att rita upp en "immersive 3d-virtual reality multisensory interface":

Framtidens aftonbladet.se-"upplevare"

En gång i tiden hette det att vi var interaktionsdesigners. Det var efter "användbarhetsarkitekt", men före UX-designer eller service designer (tror jag). Egentligen skiljer det inte så mycket åt de tre olika beskrivningarna, men just interaktionsdesign är bara en delmängd av UX-design. Rörigt? jag vet, men så är det ibland i livet. 

Jag kommer att behöva bryta ner interaktionsdesigndelen av kraschkursen i flera delar, men det är lugnt, jag kommer att guida er igenom delarna med varsam hand.  

Vi börjar med Interaktionsdesign, grundprinciperna, för det är vad det här inlägget heter. Och tråkigt nog blir det rätt lite faktiskt interaktionsdesign, utan mer en massa metaprat om interaktionsdesign. Bit ihop, det blir mer konkret lite senare. Jag lovar!

Interaktionsdesign är, precis som allt annat en UX-designer pysslar med, hjälp till kommunikation. allt vi får ur oss på jobbet syftar egentligen till att skapa ett underlag för samtal och att få förståelse, empati för andra människors behov och drivkrafter. I tidigare inlägg har jag pratat om effektkartor och gud vet vad, men även de "artefakterna" är till för att kommunicera en idé eller ett behov. Samma sak då med interaktionsdesign.

Vad är då interaktionsdesign? Tja, det är en teckning på ett användargränssnitt, kan man säga. När en UX-designer pratar om wireframes eller interaktionsdesign så är det ofta teckningar som beskriver hur ett system eller en app, eller en webbsajt, eller en diskmaskin ska funka tillsammans med den som använder grejen. Det är kort sagt en prototyp av något.

Interaktionsdesign kan vara olika detaljerad och bestå av olika material. Hur designskisserna ser ut och eventuellt beter sig beror på vem som är mottagaren av skisserna och hur långt man kommit med sin idé.

Ett (mycket) hypotetiskt exempel: 

Plucke har fått i uppdrag att ta fram ett helt nytt sätt att interagera med en telefon. Efter att intervjuat användare och stakeholders och identifierat mål med projektet och tagit fram en effektkarta kör han igång.  

Uppdraget består i att skapa möjligheter att starta och interagera med appar med hjälp av armbågen eller nästippen. Användarna är en grupp personer som behöver använda telefoner på just detta sätt. Det kanske rör sig om bagare som har händerna fulla med deg hela dagarna, men som ändå vill kunna dra igång spotify, eller busringa polarna. För vem vill gå upp klockan tre på morgonen och jobba utan att kunna lyssna på AC/DC medan degen knådas? 

Plucke börjar med att ta fram ett antal koncept av varierande kvalitet. Nu är det kanske Plucke själv som är mottagaren av designen och han tar fram alla dessa idéer för att hitta minst en han tror på. Förmodligen samarbetar Plucke med någon. En annan UX-designer, en utvecklare eller beställaren, för med lite tur har Plucke någon att bolla idéerna med redan här. Kanske han rent av kör en designstudio (kommer i ett senare inlägg , lugn, bara lugn) för att hitta några bra förslag.

För att ta reda på om hans koncept håller så tar han en gammal iphone som har fått ett papper tejpat över displayen. Pappret innehåller ett antal ditritade ikoner och användargränssnittsidéer. Plucke besöker att bageri och kollar om bagarna kan komma åt ikonerna med armbågen och hur de beter sig för att använda apparna med armbågen. På så vis ser Plucke hur bagarna upplever det här nya bagar-anpassade användargränssnittet. Plucke kan dra slutsatser vad gäller storlek på knappar etc för armbågsanvändare och justera designkonceptet efter dessa slutsatser.

När Plucke sedan ska beskriva för beställaren hur stora knappar som behövs och vilka grejer som behöver designas så har han valt att snygga till sina skisser lite. Han vet nämligen sedan tidigare att beställaren lätt snöar in på detaljer och vill slippa onödiga diskussioner om att knappar etc ser allt för handritade ut. Han berättar även vad som funkade och vad som inte funkade i det ursprungliga konceptet, och visar på skisserna vad han ändrat.

När så det indiska teamet av utvecklare ska bygga detta armbågsinterface så ser Plucke till att tydligt beskriva flöden, exakt placering av knappar och så vidare. Han har satt ihop en klickbar prototyp för säkerhets skull. På detta vis ser han till att han och utvecklarna förstår varandra. Det är hans ansvar att de förstår varandra, det är ju nämligen han som är UX-designer. Hade utvecklingsteamet istället suttit tillsammans med Plucke så hade han inte behövt vara lika övertydlig, då det är otroligt mycket enklare att prata design med någon som sitter i samma rum som en själv.


Update kl 13.41, fredag 13 maj:
En av mina trognaste fans, martin skickade just denna bild till mig. exemplet är visst inte ås hypotetiskt trots allt. Här har vi Martin fullt upptagen med att interagera med sin telefon medelst näsan!Om Plucke bara hade fixat detta användargränssnitt för 144 veckor sedan!

Martin utför onämnbara ting med näsan

Kontentan

Kort sagt: interaktionsdesign har en kommunikativ funktion. Dess utseende och beteende är helt beroende på mottagaren av interaktionsdesignen och vad som ska kommuniceras. Det är inte Pluckes preferens som avgör hur hans interaktionsdesign ska se ut, utan mottagarens. 

Härnäst pratar vi om designmönster!