Boktips: Content Strategy for Mobile

Böcker och artiklar om mobil webb handlar ofta om responsive design eller huruvida man ska ha en native app. Viktiga frågor, men det är rätt skönt att läsa Content Strategy for Mobile som inte alls svarar på sådana frågor. Den handlar om kärnan i många webbplatser, appar och intranät, nämligen innehållet.

Content Strategy for Mobile

Många CMS ser ut som något i stil med Microsoft Word (en WYSIWYG-editor, alltså). Men webben är något helt annat än ett papper eller en PDF. Webbinnehåll behöver kunna publiceras till flera olika plattformar, allt från smarta klockor till fullskaliga webbplatser. Och olika plattformar har olika möjligheter och begränsningar. Vissa är bra på att förmedla ljud, andra är bättre på text eller video.

En modern webb kräver en typ av CMS som låter innehållet vara separerat från visningen av innehåll, vilket inte är fallet med många CMS som WordPress eller EPiServer. Det innebär att innehållet kan hämtas från din Apple Watch eller från en webbläsare i din laptop. Men visningen av innehåll sköts separat, så varje plattform kan visa innehåll på det sätt som passar bäst. I en Apple Watch med hjälp av en native app, i en webbläsare med hjälp av HTML och CSS.

Content Strategy for Mobile handlar dels om varför det är viktigt att bygga sitt innehåll på ett anpassningsbart och återanvändningsbart sätt. Men den handlar också om hur man bygger upp användbart innehåll som är strukturerat för att kunna levereras till olika plattformar.

Konkret och bra för den som inte bara vill bygga bra tjänster utan också skapa innehåll på ett effektivt och långsiktigt sätt.

Tips

Författaren Karen McGranes brandtal på From Business to Buttons.

Bli bättre på presentationer

Jag tycker det är läskigt att hålla presentationer, det är jag inte ensam om. Men det finns också få saker i jobbet som kan få en att känna sig kompetent och viktig som när man gör en bra presentation. Och så älskar jag hantverket, att bygga presentationer som får folk att förstå. Tyvärr har alldeles för många bara blivit liggande eftersom jag inte kommit över tröskeln att presentera.

I onsdags var jag på Mike Monteiros workshop Presenting Design Like Your Life Depends On It (Because It Will), i samband med From Business to Buttons. Vi fick öva på att presentera för varandra och lärde oss massor. Här kommer de viktigaste sakerna jag lärde mig:

Var ordentligt förberedd

Du som presenterar måste ha riktigt bra koll på materialet. Det kommer alltid hända oväntade saker under en presentation. Oväntade frågor kommer komma, oväntade personer dyker upp, någon vill att du hoppar över delar av materialet eller förklarar något på djupet. Ha inget manus, för då tvingas du kunna materialet riktigt bra och du får lättare att hantera det oväntade. Utan manus blir det också lättare att presentera på ett engagerande sätt.

Var öppen för att oväntade frågor och diskussioner kommer upp. Men försök se till att rätt frågor dyker upp genom att inleda presentationen med att berätta varför alla är här, vilken roll folk har och vilken typ av frågor du vill få.

Känn till folks drivkrafter

Alla som deltar har ett mål, ibland kan målet vara att bara komma därifrån. Ett sätt att både göra bättre presentationer och hantera oväntade situationer (som att någon håller en 20-minuters monolog om något du tycker är irrelevant) är att förstå de olika agendor folk har. Som presentatör eller workshopledare är det lätt att skaffa sig en drömbild av vilka diskussioner som kommer komma upp. Den drömbilden bygger på din agenda, ditt perspektiv, designperspektivet. Men om du presenterar för icke-designers kommer åhörarna naturligtvis ha andra perspektiv och andra agendor.

Använd användarcentrerade designmetoder. Analysera målgruppen, deras drivkrafter och designa presentationen för dem, inte för dig själv. Ibland krävs det att du intervjuar deltagarna inför en presentation.

Workshopen i onsdags fokuserade på att presentera design för beslutsfattare/kunder. I den situationen vill de som lyssnar känna sig trygga i att du har gjort ett bra jobb, att allt är genomtänkt och att din design kommer göra företaget framgångsrikt. Det handlar inte om att gå igenom varje liten designdetalj del för del. Det handlar om att sälja – både designen och dig själv som experten som har gjort ett fantastiskt jobb.

Ta kontroll över rummet

Kroppsspråk och röstläge spelar roll. Stå alltid upp när du presenterar. Visa att du är i fokus genom att gestikulera och tala tydligt. Men du behöver inte försöka vara någon annan. Var dig själv, men dig själv när du är som mest engagerad. Om du visar att du brinner för det du pratar om så smittar det av sig.

Det är svårt att bryta sådana här mönster. Jag tror det handlar mycket om att öva, och få feedback.

Be om feedback

Den viktigaste saken i en process är att den förbättras kontinuerligt. Det gäller också ditt sätt att presentera. Tyvärr är det sällan man får någon annan typ av feedback än en klapp på axeln. Riktig feedback kommer inte av sig självt, den måste du be om.

Sammanfattning

För att sammanfatta ska jag bli bättre på att:

  • Vara förberedd och skippa manus
  • Tänka på åhörarna och deras drivkrafter inför en presentation
  • Vara medveten om hur jag presenterar och öva oftare
  • Be om feedback

Tips

Mike Monteiros 13 Ways Designers Screw Up Client Presentations som artikel på medium, som video från From Business to Buttons

Mikes podcast Let’s Make Mistakes

 

Snabb och långsam förbättring

Som in-house UX:are finns det en fråga som återkommer hela tiden. Nämligen var gör jag mest nytta? – framför allt gällande förbättringar, inte nyutveckling. Jag hade en lunchdiskussion med en kollega om det här som fick mig att fundera lite extra.

Jag tänker att jag kan göra nytta för kund och affär på följande olika sätt:

Små, snabba förbättringar

Man kan göra snabba och mindre förbättringar utifrån vad jag kan om designprinciper, kognition och best practices. Typ se över ett formulär eller ett flöde som verkar dåligt. Testa resultatet på användare och bygga. Det bästa med den här typen av förändring är att den går snabbt och om utgångsläget är dåligt kan man få riktigt bra effekter. Lågt hängande frukt.

Men hur vet man var man ska börja? Man vill förstås prioritera sådant som är viktigast för kund och affär, och som dessutom innebär en minimal insats att förändra tekniskt. Gör en översyn. Vad vill affären? Var har användarna störst problem? Och hur ser de tekniska förutsättningarna ut? Ibland finns det saker som inte ens kräver kodlyft som ger stor nytta, till exempel ledtexter.

Konceptuella förbättringar

Större och mer konceptuella förbättringar, som ett helt nytt webbkoncept, kräver förstås större insatser och är ibland kostsamma. Men de kräver också mer i form av användarundersökningar. Dels för att man vill vara helt säker på att användarna kommer förstå det nya konceptet. Men också för att på en konceptuell nivå finns inga best practices, det handlar om att förstå målgruppens behov och designa för dem.

Om jag till exempel får i uppgift att förbättra kontaktformuläret på stockholm.se så kan jag komma på några saker direkt. Det är mycket att läsa och ta ställning till trots att det bara finns två fält, vilket antagligen gör formuläret svårt att ta sig igenom. Jag tror till exempel att många användare inte kommer läsa texten ”det du skickar till kommunen blir allmän handling”. Så om användaren verkligen måste förstå detta skulle jag hanterat det annorlunda. Om användaren inte måste förstå skulle jag flytta texten och göra den mindre framträdande.

Det går alltså att göra rätt mycket bara utifrån kunskap och erfarenhet. Jag behöver inte veta ett jota om användarna på stockholm.se för att kunna göra ordentliga förbättringar av ett sådant här formulär. Men om jag istället ska förbättra informationsarkitekturen eller startsidan eller förbättra hur hemsidan passar in i ett större sammanhang med Stockholms stads övriga tjänster så skulle det genast bli svårare. Nu måste jag veta vilka som besöker sidan och hur deras behov ser ut. Och det finns inga best practices för hur man gör en startsida för Sveriges huvudstads hemsida. Förstås.

Att veta vilka konceptuella förbättringar som är viktigast att göra är klurigare. Visst, webbanalys kan avslöja en hel del om hur väl ett koncept funkar. Men den säger till exempel inget om huruvida det finns användarbehov som tjänsten missar att tillfredsställa helt. Där måste man göra användarundersökningar för att förstå hur glappet ser ut mellan användarnas behov och tjänsterna som tillhandahålls.

Ibland kommer man till och med fram till att det finns nya målgrupper, som man inte visste om. Som när inUse hjälpte Hemnet att förbättra sin sajt. Man kom fram till att många användare bara är inne för att de är intresserade av inredning eller bara tycker om att titta på hur andra har det. Så idag finns en inspiration-flik för den här målgruppen, där Hemnet tjänar pengar på reklam.

Organisationsförbättringar

För ett tag sedan skrev jag om att bygga en mer användarcentrerad designkultur. Att förändra en organisations kultur och processer går ofta långsamt men är också kanske den mest långsiktiga nytta jag kan göra.

Här kan man också fråga sig var man ska börja. Högst upp, skulle jag säga. Även om organisationen inte är hierarkisk så lyssnar folk på chefer. Men man kan också börja gräva där man står, oavsett om man jobbar med småförbättringar eller konceptuella förbättringar. Inkludera kollegor i UX-aktiviteter som intervjuer och användningstester, visualisera och kommunicera vad man gör och varför.

Så vilket sätt att göra nytta på är bäst? Som vanligt beror det på. Men jag tänker att de här tre sätten kan komplettera varandra på ett fint sätt. Om man gör småförbättringar och levererar nytta snabbt så bygger man förtroende som leder till att man får jobba mer övergripande och konceptuellt. Och under tiden, hela tiden tänka på hur man kan sprida ringar på vattnet och förbättra organisationen.

Tips

The Modern UX Organization – föreläsning av Leah Buley om UX-mognad hos organisationer

Boken Subject to change – ett måste för alla

Building UX culture within an organization – av Chris McCann

Effektmål för att styra teamet åt rätt håll

En viktig del av en bra designprocess är tydliga effektmål. Det finns ju alltid anledningar till att man väljer att sätta ihop ett team för att designa och utveckla något. Men det är tyvärr vanligt att beställare och beslutsfattare inte lyckas rama in varför på ett tydligt sätt. Varför vill vi plöja ner en massa pengar i att byta ut det där Intranätet – egentligen? Vad vill vi uppnå?

Med tydliga effektmål från början blir teamets jobb lättare:

  • Effektivare diskussioner. Vilka användarbeteenden är viktigast? Vilken designlösning är bäst? Utan mål blir det lätt att hamna i tyckanden. Med tydliga mål kan man ställa sig frågan ”vilket alternativ uppfyller målet bäst?”, vilket är ett effektivare sätt att lösa problem på än att tycka.
  • Beslutsfattare behöver inte detaljstyra. Chefer, styrgrupp och andra som ska ta ”större” affärsmässiga beslut behöver sätt att styra resultatet. Om de får besluta om effektmål och man kan visa kopplingen mellan designbesluten och effektmålen så får de den möjligheten, de får kontroll. Om de inte har möjlighet att styra på en högre nivå så finns risken att de börjar tycka till om detaljer.
HIPPO – Highest Paid Person’s Opinion
  • Fokus på nyttan. Det är vanligt att man startar ett projekt av tekniska skäl. Infrastrukturen är föråldrad, CMS:et supportas inte längre, Intranätet är byggt i ett obskyrt programspråk som utvecklarna inte förstår. Föråldrad teknik kan vara ett jätteproblem, men ett tekniklyftet är alltid ett medel för att uppnå något, inte ett mål i sig. Vi uppgraderar inte Intranätet bara för att det är kul med ny teknik utan för att till exempel få gladare, effektivare medarbetare och lägre förvaltningskostnader. Det är lätt att hamna i att teknikbeslut får styra, speciellt om många av projektmedlemmarna kommer från tekniksidan. Om teknikbesluten (och designbesluten) kan kopplas till effekter blir det lättare att ta rätt beslut – det vill säga de beslut som leder till mest nytta.

Det är inte helt lätt att definiera ”bra” effektmål. Alltså mål som kan styra teamet i rätt riktning, som teamet kan använda för att ta rätt beslut och lösa problem. Så hur ska man tänka? Så här tror jag:

  • Målen ska representera vad organisationen vill (till exempel ökad effektivitet hos medarbetarna) men man vill också att det ska ha en stark koppling till satsningen. Visst, ett Intranät kan bidra till att folk blir mer effektiva men medarbetarnas effektivitet beror ju också på så mycket annat. Till exempel arbetsledning och utformning av processer och rutiner. Bättre då att bli lite mer konkret och definiera hur Intranätet kan bidra till ökad effektivitet. Kanske genom ökad kommunikation mellan kollegor eller ökad kännedom om rutiner och processer.
  • Målen ska inte peka ut specifika lösningar, till exempel lättare att söka. Varför vill vi att det ska vara lättare att söka på Intranätet? Kanske för att det ska bli lättare att hitta, vilket kan bidra till ökad kännedomen om rutiner och processer. Sök är en lösning och det kan absolut finnas andra lösningar. Till exempel e-postnotifieringar när en rutin ändras.
  • Målen ska förstås också vara något som kan kopplas till nytta för organisationen, vilket oftast innebär en koppling till ökade intäkter eller minskade kostnader. Om det är få som idag använder Intranätet kan man frestas att sätta målet ökad användning. Men ökad användning i sig är inte något som kan kopplas till nyttan. Det kan ju till exempel bero på att det har blivit ännu svårare att hitta, man måste spendera mer tid på Intranätet för att komma åt de där rutinerna och processerna.
  • Det är också en klar fördel om målen är mätbara, så man vet när man har lyckats. När man måste sätta en siffra på målet blir det också mer konkret, till exempel 8 av 10 medarbetare har under en månad tagit del av någon rutin på Intranätet. När metoder för att mäta saknas får man förstås skapa sådana, till exempel genom förbättrad statistik eller enkätundersökningar.

Tips

Aligning UX Strategy with Business Goals på UXPA
Boken Impact Mapping
inUse:s kurs i effektstyrning

Fråga vad användarna tycker – det är okej

Det här är UX-världens kanske mest uttjatade citat (som antagligen inte ens stämmer):

If I had asked people what they wanted, they would have said faster horses.

– Henry Ford

Citatet används ofta för att poängtera att det inte handlar om vad användarna tycker. Man måste förstå användarnas behov för att kunna designa en bra lösning. För användarna är oftast inte designers, de har inte koll på vad som är möjligt att göra och utgår bara från sig själva. De kan inte designa lösningarna själva. Och man kan inte bara utgå från synpunkter och idéer från användare när man väljer lösning. Bra så.

Men det finns också fördelar med att fråga vad användarna tycker och be dem komma med egna idéer:

  • Alla användare är, som bekant, olika. Många är fantasirika och kreativa människor. Många har en grymt bra analysförmåga.
  • Användarna kan ha erfarenheter från webbplatser och system som jag som designer aldrig sett. Om det handlar om ett expertsystem som folk använder ofta så har vissa användare antagligen redan funderat mycket på hur det skulle kunna funka bättre.
  • I en intervju kan frågan Hur skulle du önska att det här skulle funka? dels vara en isbrytare, som får folk att prata. Dels kan den följas upp med frågan Varför skulle du vilja att det funkade så?.

I co-creation tar man det här ett steg längre. Det handlar om att engagera användarna i designprocessen. Istället för att först förstå målgrupper och behov, sedan göra ut en lösning och testa så låter man användarna vara med och designa lösningen. Man kombinerar alltså ”traditionell” research (djupintervju/observation) och konceptdesign till en aktivitet med syftet att förstå både användarnas behov och hur de ser på en lösning.

Sådana här workshops kräver förstås en del planering och tankearbete. Men det kan nog vara ett effektivt sätt att designa på, om det görs rätt. Jag tror ett första steg kan vara att ibland fråga vad folk tycker, och se vart det leder.

Lästips

Co-Creation: Designing With the User, For the User på UX Booth
The UX of Co-Design: Experience Principles for Successful Client Workshops på Adaptive Path
Myth #21: People can tell you what they want på UX Myths

Varför man ska ha ett in-house UX team

För någon månad sedan gick Adaptive Path ut med att de köpts upp av storbanken Capital One. Det här kan vara en del av en trend i USA och jag anar en trend även i Sverige. Företagen skaffar egna UX-team i högre grad, när man tidigare oftare förlitade sig helt på konsulter och byråer utifrån. Själv gick jag från konsult till in-house för något år sedan.

Det finns klart bra saker med att anlita konsulter och byråer. Man kan ta in en expert på ett specifikt område. Man slipper en jobbig anställningsprocess och kan snabbt sätta ihop ett ”dream team” med rätt kompetens utifrån vad som ska göras i ett projekt.

Så varför ska man som företag ha ett eget UX team?

Alltid jobba användarcentrerat, överallt

En UX designer som jobbar i flera år på samma ställe kommer lära sig att navigera i organisationen, ha stenkoll på alla satsningar som görs och få en god känsla för när något inte stämmer. Men framför allt kan man bygga upp ett arbetssätt som garanterar att allt som utvecklas på företaget tas fram enligt en användarcentrerad metod. Annars riskerar man att vissa satsningar görs utan att man alls involverar användare eller har UX kompetens. Det är trots allt rätt jobbigt att ta in konsulter och lätt att ”glömma bort” området UX där kompetensen är lite luddig och svårare att förstå än t.ex. projektledare eller testare.

Levandegöra insikter, principer och strategier

Kontinuiteten blir extra viktig när man jobbar övergripande eller strategiskt. Under min tid som konsult har jag sett en del styrdokument med fina namn som ”webbstrategi”, ”målbild” eller ”personas” som bara ligger och skräpar i ett hörn. Människors beteenden, förväntningar och problemområden förändras hela tiden. Så efter ett tag blir styrdokumenten inaktuella och glöms bort, oavsett hur välförankrade de var en gång i tiden. UX teamet kan se till att kunskapen om användarna alltid hålls aktuell och att styrande principer faktiskt används när nya tjänster tas fram. Oavsett om det är en konsult eller en anställd som gör jobbet.

Samma sak gäller interaktionsprinciper och UI guidelines. Om man jobbar med komplexa tjänster kan man spara mycket tid på att inte bara ta fram principer och guidelines inom ett specifikt projekt utan låta dem leva kvar när tjänsten vidareutvecklas i framtiden. Men de måste förstås hållas aktuella och jobbas med, annars dör dem snabbt.

Långsiktig förändring

We believe in delivery, not deliverables. Some people practice user-scented design, not user-centred design. They churn out documents – sitemaps, wireframes, specifications – but they’re not interested in what happens next. UX is a mindset, not a process – it lasts all the way until the site is live, and after.

Från boken Undercover User Experience Design.

Som konsult vill och ska man leverera. Och visst, det finns jättebra och ansvarsfulla konsulter som också vill förändra organisationer och leverera långsiktig nytta. Men som del av ett in-house UX team blir det extra viktigt att bygga något långsiktigt. Det kan som sagt gälla arbetssätt och strategier, men också organisationens förståelse för användarperspektivet. In-house UX teamet kommer vara mer intresserade av det långsiktiga eftersom de kommer påverkas på längre sikt. De har också, förstås, bättre möjligheter att jobba långsiktigt eftersom de jobbar kvar under en längre tid.

Adaptive Path-gängets bok Subject to Change handlar om långsiktig organisationsförändring – att bygga en användarcentrerad designkultur. Deras tanke om långsiktig nytta och vilja att ta UX design vidare gick till slut så långt att de blev uppköpta av Capital One. Så här skrev Jesse James Garrett i pressmeddelandet:

In many ways, this is exactly the kind of problem Adaptive Path was created to solve: helping a company with the resources, but more importantly the will, to reimagine its strategies, processes, and design solutions to create better experiences for millions of people. It’s a level of impact we’ve never had before, and we’re excited to be here at this moment.

Så om du är ett företag som vill fokusera på användarens behov och göra långsiktig nytta – skaffa ett eget UX team! (och ge teamet utrymme att göra ett bra jobb, men det är en annan historia)

Lästips

Soldiers & Hessians, Ronin & Ninja – jämförelse av att ha eget team vs. konsulter,  på boxesandarrows

The 3 Qs for Great Experience Design – om vad som utmärker framgångsrika UX team, på UIE

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.