Rapport från UX Open 2014

För några år sedan fanns det inga UX-konferenser i Stockholm alls. Nu finns det flera, vilket är helt fantastiskt.

UX Open, som hölls för tredje året i fredags, bygger mycket på deltagarmedverkan. Dels hålls korta blixttal på 10 min, dels är man med i gruppdiskussioner där deltagarna bestämmer ämne. I år var det också paneldebatter där alla fick delta. Väldans bra upplägg, för det kändes som att rummet var sprängfyllt av kompetens. Och man blir också mer på tårna av att inte bara sitta och lyssna på föreläsningar.

Daniel Anundi inledde med att prata om Service Recovery, den del av tjänstedesign som handlar om att hantera när någon går fel i tjänsteleveransen. Insatsen för att få en ny kund motsvarar insatsen för att behålla fem befintliga. Ändå glömmer man ofta bort att designa för de felsituationer som kan uppstå. Daniels exempel var ett hotell som förstörde en klänning i tvätten och inte bara kompenserade genom att betala för köpa nya kläder. De anlitade också en personal shopper och gav paret en oförglömlig upplevelse under ett restaurantbesök.

Man kan fundera på om den här hotellkedjan tjänar på att kompensera kunder på ett så här ambitiöst sätt. Enligt en studie i den här boken ska företagen sluta försöka överträffa folks förväntningar eftersom överträffade förväntningar inte leder till ökad lojalitet. Sant eller ej, hotellkedjan tjänade säkerligen på just den här kompensationen eftersom historien fått så stor spridning.

Sigrun Tallungs jobbade med användbarhet i polissystemet Pust. Hela Pust-Siebel-haveriet är ett bra exempel på vad som händer om man låter beslut kring teknisk plattform styra i alldeles för hög grad. Och om man låter fel personer besluta om teknisk plattform. Målet med föregångaren Pust-Java var att det skulle vara lätt att använda. Målet med Pust-Siebel var billig förvaltning. Men billigt blev det inte. Man räknar med att Pust-Siebel kostat ca 126 miljoner innan det lades ner.

Några kortisar:

  • Det pratades mycket om användarundersökningar av olika slag. Alla verkar tycka det är en självklar del av UX-arbetet. Bra!
  • Bästa konkreta tipset var att låta stakeholders spela användare och intervjua varandra inför användarintervjuer. På så sätt upptäcker de vilka (felaktiga) antaganden de gör om användarna. Genialt!
  • Kundundersökningar, målbilder och designprinciper. För att funka måste de repeteras, revideras och jobbas vidare med. Häng t.ex. upp på väggar där folk befinner sig eller repetera i början av varje möte.
  • Vi UX:are borde lägga mer tid på att kommunicera vårt jobb – och mindre på att leverera.

Riktigt bra konferens, tack till arrangörerna! Jag ser redan fram emot nästa år. Eller som Maryam skrev:

Jens Wedin tog en massa fantastiska foton. Kolla in.

Annonser

Bygga en användarcentrerad designkultur

Under tiden jag filade på det här postade Christopher McCann på EPiServer den här texten på samma ämne. Jag tyckte den var bra, så läs gärna den också 🙂

Som UX designer brottas man ofta med att förändra en organisations designkultur till att bli mer användarcentrerad. Att ta med användarna mer i processen, basera beslut på vad man vet om användarna, öka kunskapen om användarnas behov och kommunicera utifrån ett användarperspektiv. Det kan vara svårt.

Process

Alla UX designers har nog en bild av hur den ultimata processen ser ut. Men alla som försökt jobba enligt sin ”drömprocess” vet att det är svårt. Vi är alltid begränsade till trista saker som budget och tid.

Jag tror man ska vara tuff, följa drömprocessen men banta ned den. Göra alla moment. Om det inte finns tid eller budget så kompromissa inte genom att ta bort moment. Gör momenten kortare, enklare, snabbare. En djupintervju med en kompis mamma är bättre än ingen alls. Ett användningstest med en kollega är bättre än inget alls. Om man gör alla moment så kommer folk runt omkring börja förstå processen, även om det kan kännas futtigt och löjligt ibland.

Inkludera andra i processen så mycket det bara går. Det är energikrävande och tar tid men folk som jobbar tillsammans förstår varandra så mycket bättre. Att ensam få till en förändring är snudd på omöjligt. Man måste skaffa sig allierade och då gäller det att få folk att förstå, på riktigt. Speciellt beslutsfattare vill man ha som allierade. Om en beslutsfattare högre upp fattar så kan det få riktigt bra ringar på vattnet.

Beslutsfattande

Beslut om vad som ska utvecklas och när sker oftast i flera nivåer. Någon i ledningsgruppen kanske beslutar om att en tjänst ens ska börja utvecklas. Mindre beslut kring utformning tas oftast längre led, t.ex. av en utvecklare eller UX designer.

Det är vanligt att designbeslut bygger på magkänsla eller personliga tyckanden. Eller i alldeles för hög grad utgår ifrån tekniska förutsättningar. För att besluten på alla nivåer ska bli mer användarcentrerade och leda till tjänster som folk faktiskt gillar måste man förstås jobba användarcentrerat på alla nivåer. För att det ska hända måste man sprida kunskapen om användarcenterad design i alla led. Och för att det i sin tur ska hända måste folk förstå värdet.

I en liten eller platt organisation tror jag helt enkelt olika kompetenser ska börja jobba tillsammans så man förstår varandra bättre. En utvecklare/arkitekt och en UX:are kanske ska vara aktiv i ledningsgruppen. Eller ledningen kanske ska besöka projekten regelbundet och vara med på användarundersökningar.

När detta inte går får man missionera. Att få utvecklare att förstå är oftast enkelt, speciellt om man jobbar agilt, eftersom man har ett tight samarbete. För beslutsfattare ”högre upp” kan man försöka dra paralleller mellan användarcentrerad design och nytta. Jag har ibland använt effektkartan, som jag skrivit en massa om. Den kan funka bra för att visa kopplingen mellan affärsnytta, kunskap om användare och designbeslut på ett tydligt sätt.

Konkreta goda exempel och framgångssagor kan också funka bra. Men det är viktigt att fokusera på varför man jobbar som man gör och hela tiden relatera till nyttan så den som lyssnar inte får känslan av att man bara gör en massa onödigt extrajobb.

Lästips

Boken Subject To Change av Merholz och Wilkens handlar om precis det här och är svinbra

Applied UX Strategy Part 1: Maturity Models på UXMatters handlar om UX-mognad i organisationer

Mapping Business Value to UX på UXMatters handlar om att mappa UX till affärsnytta

Design som förändrar beteenden

Nyår känns långt bort just nu, men jag kom att tänka på nyårslöften idag. Ni vet, 2014 ska jag köpa mer ekologiskt, gå ner i vikt eller sluta röka. Nyårslöften är intressanta för de sätter fingret på något. Ett beteende man vet att man vill förändra.

Nyårslöften ska vara tydliga, de ska enkelt kunna artikuleras på fyllan med ett champagneglas i handen. Men det finns alltid ett motstånd av något slag. Ett nyårslöfte ska inte vara för enkelt. Här är de vanligaste enligt SIFO 2013:

  1. Äta hälsosammare (48 procent).
  2. Börja träna (42 procent).
  3. Stressa mindre (19 procent).
  4. Läsa fler böcker (12 procent).
  5. Få ordning på ekonomin (10 procent).
  6. Dra ner på alkoholen (9 procent).
  7. Ge vänner och familj mer tid (9 procent).
  8. Sluta röka eller snusa (8 procent).

Det här är alltså beteende förändringar som folk vill göra men inte alltid lyckas med. Vi UX designers letar ju efter beteenden hos de vi designar tjänster för. Och jag tänker att vi kanske skulle kunna inspireras av den här listan. För om hjälper folk med de här beteendeförändringarna samtidigt som vi gör en bra tjänst i övrigt tror jag vi kan glädja våra användare lite extra. På Kano-modellens språk, fler delighters.

Ett av mina favoritexempel på en produkt som gör något ”extra” för att glädja mig är min våg. Den heter Withings Wireless Scale och är en smart våg som är uppkopplad mot mitt WiFi så man kan se en viktkurva i en webapp. För några månader sedan kom en automatisk uppdatering. Plötsligt visar den ett litet paraply om det kommer regna under dagen.

Withings Scale

Jag älskar det här. Dels för att det inte var något jag förväntade mig när jag köpte vågen. Men mest av allt för att vågen förändrar mitt beteende. Det är lika enkelt att väga sig som att ta fram telefonen och kolla om det ska regna. Så jag väger mig oftare. Och går runt och tjatar om min fantastiska våg.

Vi pratar ofta om drivkrafterna som får en användare att välja att använda en tjänst. En drivkraft kan ju vara något snabbt och flyktigt, som jag vill snabbt veta min vikt. Och vi kan tillfredsställa den drivkraften på ett superenkelt och effektivt sätt. Men för att göra något extra, något innovativt och verkligen få nöjda användare behöver vi veta varför folk vill veta sin vikt. Vi behöver jobba med mer grundläggande drivkrafter, som jag vill ha kontroll på min vikt eller kanske jag vill gå ner i vikt. Det är vad en våg är till för.

På samma sätt kan en yogakurs vara till för att stressa mindre, en träningsapp vara till för att motivera mig till att börja träna, och en internetbank till för att få bättre ordning på min ekonomi. Eller kanske göra tid för roligare saker än bankärenden. De som förstår det, genom att satsa på att förstå sina användare och deras drivkrafter på djupet, lyckas oftare än andra.

Saker jag lärde mig på UX Open

Igår var jag på UX Open, Martin Christensens UX-konferens som hölls för andra året. I år bestod UX Open av 17 korta inspirerande föreläsningar på 10 minuter, följt av gruppdiskussioner. 10-minuters-formatet är perfekt tycker jag, man hinner aldrig tappa intresse eller zona ut och samtidigt får mängder av olika perspektiv på kort tid.

Jonas Söderström berättade om de designprinciper som den brittiska staten tagit fram och som översatts till svenska. Principerna kanske inte innebär så mycket nytt men jag tycker de är vettiga och välformulerade. Det kan ge tyngd att ha någon sorts auktoritet att peka på istället för att ta fram egna principer.

Begrepp och vad vi kallar oss är nästan en obligatorisk diskussion på sådana här tillställningar. Erik Westerdahl pratade om skillnaden mellan Service Designers och UX Designers och en av gruppdiskussionerna handlade om vad vi kallar oss. Det verkar som att de flesta av oss fortfarande ska ”kunna allt” snarare än att vi är specialiserade på ”ren” interaktionsdesign, informationsarkitektur eller användarundersökningar. Det är både bra och dåligt, förstås. Någon behöver har helhetsbilden. Men hur ska man kunna bli riktigt bra på något om man ska kunna allt? Anneli Olsen fick till roligaste tweeten apropå service design-diskussionen.

Linda Mattsson pratade om Daytonas sätt att göra användningstester hela tiden genom att bjuda in testpersoner en timme varannan vecka. På så sätt blir testerna verkligen gjorda. Bra idé tycker jag, man kan alltid testa mer och det är lätt att slösa för mycket energi på saker som att förbereda testerna och hitta testpersoner när man väl testar.

Quentin Cook pratade om Spotifys nya sätt att kommunicera designbeslut och undvika inkonsekventa gränssnitt. Designbeslut kommer alltid tas, av designers, utvecklare eller chefer. På större företag måste man hitta ett sätt att hantera kommunikationen, ofta med hjälp av en style guide. Problemet med style guides är att de är tungrodda och svåra att underhålla. När nya funktioner ska till som inte passar in måste style guides arbetas om och då måste också produkten jobbas om så det inte finns skillnader mellan produkt och style. Spotifys alternativ är ett antal övergripande designprinciper plus ett front end-ramverk med gränssnittskomponenter (typ Bootstrap) som alltid är synkroniserade med själva produkten.

Det fanns också gott om bra diskussioner, inspirerande historier och bilder på söta katter. UX Open är det bästa som hänt UX-communityt i Stockholm på länge. Tack Martin, bra jobbat!

När projektformen inte funkar

Många digitala produkter slutar utvecklas och glöms bort alldeles för tidigt.

Så här går det enligt min erfarenhet ofta till: När projektet är klart, helst inom tid och budget, firar man (det är bra). Sedan går projektmedlemmarna åt olika håll, med undantag för några som blir kvar och ska jobba med förvaltning. Förvaltning innebär att man hanterar buggar. Ska det till något större behövs ett nytt projekt dras igång. Det leder till att man duckar för större förändringar.

Det finns ofta en övertro på vad som kan levereras inom projektets tid och budget. Klart man är alltid tvungen att prioritera bort saker, det är en sak. Men framför allt har man inte hunnit ta sig tid att lära sig om hur användarna faktiskt använder produkten som levereras, på riktigt.

Det går att göra hur mycket användningstester, djupintervjuer och fokusgrupper som helst under projekttiden. Det är ändå inte förrän när precis hela produkten är färdigimplementerad och har använts under en längre tid som man kan säga hur den används och uppfattas.

Det här är ett extra stort problem när man tar fram komplexa system som användarna jobbar intensivt med varje dag. En sådan situation är svår att användningstesta med en prototyp.

Det är också ett problem när man tar fram en ny och innovativ produkt, eller en social tjänst som bygger på att många använder den samtidigt. Det funkar inte att fråga användarna om de kommer köpa eller gilla produkten, hur ska de kunna veta det?

Resultatet när man inte vet tillräckligt om hur användarna kommer använda produkten blir självklart en dålig produkt med ”dålig UX”, alltså fel funktionalitet presenterad på fel sätt.

Leverera tidigare

Dels behöver man sätta produkten (den riktiga produkten, inte prototypen) i händerna på användarna tidigare. För att komma dit tror jag man måste slarva lite. Inte slarva så mycket med det användaren ser utan med strukturerna och koden bakom. Även om det känns fel måste man prioritera att få ut något snabbt istället för att bygga en perfekt systemarkitektur. Man kan slarva med saker som skalbarhet, dokumentation, driftsäkerhet och annat tekniskt som behövs men inte syns.

För att börja slarva på det sättet måste man prioritera upp kunskap om användandet och prioritera ned teknisk elegans. Alla som jobbar med projektet måste förstå varför.

Kontinuerlig förbättring istället för projekt

Dels tror jag man skulle behöva sluta driva projekt med start och slut. Man behöver se utvecklingen som en investering som börjar men aldrig tar slut. I början bränner man mer pengar, förstås. När det är läge minskar man på tempot gradvis. Kalla det inte förvaltning, utan kontinuerlig utveckling och förbättring i rätt tempo. Självklart kontinuerliga användarundersökningar, utvärderingar och redesign när man lär sig mer om hur produkten används. Inget är slaget i sten.

Det här är klart svårt eftersom beslutsfattare gillar budgetar och deadlines. Det handlar om en förändring i hur man tänker kring IT-satsningar och budgetar i stort.

Boktips: Lean UX

Lean UX book

Tanken på UX design som en del av den agila utvecklingsfilosofin har funnits i några år nu. I början handlade mycket om designteam som jobbar en sprint före ett utvecklarteam, i ”staggered sprints”. Det här funkade inte för alla och folk som Anders Ramsay började prata om integrerade team och tvärfunktionellt samarbete. Alla i teamet är delaktiga i allt, alltså, inklusive användarundersökningar och design.

Eric Ries bok The Lean Startup kom ut 2011 och handlade om produktutveckling genom prototypframtagning och experimenterande. Den blev enormt hypad och en hel lean startup-rörelse föddes. UX Designers som Jeff Gothelf hade samma idéer, fast i en UX-kontext. Istället för att göra långa förstudier för att komma fram till vad vi ska bygga så bygger vi något quick-and-dirty, testar på den tänkta målgruppen och förbättrar.

Gothelfs bok Lean UX handlar mest om delad förståelse och hur vi kan jobba mer effektivt genom att samarbeta över olika kompetensområden, från ett designerperspektiv. Men den handlar också om produktutveckling genom experimenterande och andra sätt att jobba mer lean. Alltså sätt att leverera mer nytta med mindre insats.

Boken är inspirerande och man känner igen sig i mycket. Den innehåller både övergripande principer och konkreta beskrivningar av vanliga problem när man jobbar på det här sättet. I vissa kapitel där man beskriver case tänker jag att jag vill veta mer. Få mer en konkret bild av hur man till exempel väljer ut vad som ska utvecklas först, vilket är en utmaning när minimalt designarbete ska göras ”up-front”. Här tycker jag det finns en liten lucka. Det finns inte heller så mycket tips på konkreta modeller eller hur man kan lösa det dagliga arbetet.

Men å andra sidan är boken föredömligt kort. Det är bra eftersom den borde vara obligatorisk läsning för alla som jobbar med användarupplevelse eller produktledning. Eller tja, kanske alla som jobbar med att ta fram digitala produkter.

Nu hoppas jag att även Anders Ramsays bok Designing with Agile: Lean User Experience for Successful products kommer ut i år. Misstänker att Ramsay kommer fokusera mer på det praktiska.

Effektkartan – mina bästa tips

Det absolut vanligaste sökordet folk använder för att komma till min blogg är ”effektkarta”. Eftersom jag gillar effektkartor och har använt dem i en massa projekt så tänkte jag dela med mig av några tips.

Inledande workshop med rätt personer

En workshop (eller flera) där man tillsammans bygger en effektkarta kan vara en bra start på ett projekt. Men för att workshopen ska bli effektiv är det viktigt att man samlar rätt personer utan att man är för många. Tre till fem personer tycker jag funkar bäst och man behöver:

  • Beslutsfattare. Någon eller några tunga beslutande personer och helst den som ”sponsrar” projektet, alltså sitter på pengarna och beslutar om projektets varande eller icke varande. Till exempel en VD, CIO, CTO eller avdelningschef. Denna person är viktig för att kunna definiera ett effektmål. Den är också superviktig att förankra hos.
  • Verksamhetsexperter. Någon eller några som har koll på hur verksamheten fungerar och vilka målgrupper som finns. Försök hitta en ”spindel i nätet” som har övergripande kunskap och inte bara kan en viss avdelning eller produkt. Kundtjänst och marknadsavdelning är bra ställen av börja leta på.
  • Teknisk expert. Om något ska implementeras är det bra att ha med någon eller några som kan tekniken och kommer ha en strategisk roll i implementation. Till exempel en senior utvecklare, systemarkitekt eller teknisk projektledare. I effektkartläggningen är det viktigt att hålla diskussionerna på en icke-teknisk och övergripande nivå, men det är väldigt skönt att ha någon som direkt kan svara på vad som är lätt och svårt. Dessutom är det viktigt att det nyttofokuserande och användarcentrerade arbetssättet förankras med någon på tekniksidan.

Håll effektkartan kort

Effektkartan kan användas som en arbetsmodell för att styra mot nytta, prioritera rätt och ”göra rätt saker”. Men den är också mycket användbar för förankring och kommunikation. Nya projektintressenter och projektmedlemmar kan snabbt följa och förstå hur åtgärder eller funktioner motiveras. Att man inte bara förstår vad som ska göras utan varför är viktigt för att människor ska kunna jobba effektivt och bidra med nya idéer.

När effektkartan fyller en viktig pedagogisk funktion är det bra om den inte är för omfattande. Det gör den också lättare att underhålla. Jag tror inte allt behöver finnas med i kartan, speciellt inte åtgärder och funktioner på låg nivå. Istället brukar jag begränsa mina effektkartor till koncept och principer på hög nivå.

Betrakta effektkartan som en samling hypoteser som ska valideras

De målgrupper och drivkrafter som identifieras i en inledande workshop är inget annat än kvalificerade gissningar som kan ligga långt från verkligheten. För att validera att hypoteserna stämmer kan vi gå två vägar.

Antingen gör vi en s.k. målgruppsanalys för at analysera de potentiella målgrupperna med hjälp av traditionella UX-metoder som djupintervjuer, observationer och dataanalys. Den andra vägen är att ta till olika typer av experiment för att validera, enligt Lean Startup-modellen. Effektkartan kan fungera som ett bra verktyg för att jobba strukturerat med hypoteser och validering, vilket jag har skrivit om förut och som Gojko Adzic skrivit en bra bok om, Impact Mapping.

Vad som fungerar bäst beror på situation men jag tror det bästa är en kombination av traditionell målgruppsanalys och experimenterande.

Oavsett vilken väg vi väljer är det viktigt att alla som kommer i kontakt med effektkartan förstår att den från början är mycket hypotetisk och behöver valideras och kompletteras på ett strukturerat sätt.

Effektkartan är aldrig klar

Vissa verkar tro att bara för att effektkartan är ett dokument som börjar produceras tidigt i processen så måste den bli klar och ”signas av” av någon beslutsfattare. Men om kartan signas av blir det svårt att senare få till förändringar. Om vi jobbar med interaktionsdesign parallellt med utveckling, enligt agila principer, måste kartan självklart få växa fram kontinuerligt. Insikter från diskussioner med projektintressenter, från användningstester och statistik måste få påverka kartan, oavsett om insikterna kommer i tidiga workshops eller strax innan lansering.

Vattenfalls-UX är ineffektivt, kostsamt och tråkigt. Vi borde lära oss samarbeta och anpassa hur vi jobbar med metoder som effektkartläggning för att tillåta förändring och kontinuerligt upptäckande, inte bara kontinuerlig leverans.

Tänk efter själv och ha kul!

Jag gillar verkligen idéerna bakom effektkartan och effektstyrning, men det finns inte ett rätt sätt att arbeta på. Kartan och tankarna bakom kan användas på olika sätt. Jag har t.ex. använt effektkartan som ett stöd vid kreativa workshops och för att hjälpa en startup hitta sina viktigaste affärskritiska hypoteser. Det finns säkerligen en massa kreativa sätt att använda den på i andra situationer.

Kartans struktur behöver inte heller vara slagen i sten. Adzics modell Impact Mapping täcker inte bara in målgrupper som bidrar till nyttan genom sin användning. Den inkluderar också aktörer som mer indirekt bidrar till nyttan, som beslutsfattare. Den här utökningen har nog både för- och nackdelar. Poängen är att om man förstår effektkartan och situationen kräver en förändring eller utökning så kör på!

Vidare läsning

Gojko Adzics e-bok Impact mapping kom ut November 2012, så den är purfärsk. Boken innehåller en massa om hur man jobbar med effektkartor kombinerat med moderna principer som Agil metodik, Lean UX, Lean Startups och Design thinking. Rekommenderas starkt för alla som jobbar med effektkartläggning, även om Gojkos Impact Map skiljer sig lite från Domingues och Balics effektkarta. Boken är dessutom både snygg, kort och billig.

Mikael Sköld höll presentationen Bättre effektkartor på UX Open, där finns också en del tips.