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.

Annonser

Boktips: Managing to learn

A3 är ett pappersformat. Men det är också en modell som används flitigt inom det berömda Toyota Production System. Tanken är att man kan sammanfatta allt man vet om ett problem och dess lösning på ett A3-papper. Formatet gör det lätt att förklara innehållet för andra. Men egentligen handlar det om något mycket större.

A3 handlar om problemlösning. En A3 skapas för att hantera ett problem, t.ex. ett problem i organisationen. För att hitta lösningen på problemet måste man gå vetenskapligt till väga. Ta reda på problemets underliggande orsaker, varför?, genom att prata med de som påverkas av och påverkar problemet. Akta sig för att dra förhastade slutsatser eller välja första bästa lösning.

När det grundläggande problemet har hittats tar man fram flera lösningar, tillsammans med de som påverkas av och påverkar problemet. Lösningarna testas genom experimenterande och utvärdering, Plan-Do-Check-Act.

Bokens format är bra. Den berättar en historia om en ung ingenjör som får i uppgift att ta fram en A3 för att hantera ett problem. Han blir skolad av en mer senior kollega. Boken berättar alltså en historia, precis som en bra A3 ska göra. Det gör den väldigt lättläst.

Även om boken handlar om att lösa organisationsproblem och utöva ledarskap är det lätt att dra paralleller till det jag gör. Bra UX design handlar om precis det här, tänker jag. Lära sig mer om ett problem  genom att prata med användarna, de som påverkas av och påverkar problemet. Ta fram flera lösningar och utvärdera. Det är inspirerande att samma principer, den vetenskapliga approachen, kan användas för att lösa olika typer av problem på olika nivåer. Boken får mig att respektera systematisk problemlösning och experimenterande ännu mer. Och förstå hur det kan användas för att ta ansvar för ett organisationsproblem. Väldans bra.

Boken på Amazon

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.

Boktips: Subject to Change

Subject to Change (2008) är skriven av fyra Adaptive Path-medarbetare och handlar om hur man gör för att vara framgångsrik genom att fokusera på kundupplevelse och uppmuntra förändring. Eller ja, egentligen snarare varför det är bra att fokusera på kundupplevelse och förändring än hur. Poängerna är ungefär:

Att företagen måste inse att kundupplevelse är fundamentalt för att lyckas och börja tänka på hela upplevelsen, inte bara att en produkt eller en avdelning ska leverera kvalitetsupplevelser. För att kunna ta ett upplevelseperspektiv fullt ut måste man göra kundundersökningar och kunskapen om slutkunderna ut i organisationen. Den får inte begränsas till researchers eller UX designers.

Att design och prototyping är viktigt då det låter oss testa många lösningar, förstå kundupplevelsen och samarbeta kring en lösning.

Att agil och iterativ utveckling innebär lägre kostnad, lägre risk och högre kvalitet eftersom misstag som görs under vägen inte behöver påverka slutresultatet.

Poängerna beskrivs med en massa exempel på företag och produkter som har eller inte har lyckats. Och jag tycker det var lätt att relatera det som skrivs till hur jag skulle kunna jobba på ett bättre sätt, trots att det inte finns så mycket praktiska beskrivningar av arbetssätt.

Den del som gav mig mest var den om kundundersökningar och vikten av att inte jobba isolerat. Vi som gör kundundersökningar kan leverera så mycket mer nytta om vi t.ex. involverar de som fattar besluten och de som möter kunderna varje dag.

Kort, bra, inspirerande, mycket läsvärd. Tack för lånet, Martin.

Steget från utvecklare till UX designer

Jag blev glad när jag läste den här artikeln om hur författaren gick från att vara utvecklare till UX designer. Känner igen mig i mycket och vet att det finns många utvecklare där ute som drömmer om att göra användningstester, skapa personas och pitcha wireframes för projektledare som står redo med fogsvansen i högsta hugg. Så jag plankar Boon Chew och skriver om hur jag började med UX/användbarhet, kanske är någon där ute intresserad.

Till skillnad från artikelförfattaren hade jag läst en del högskolekurser på området ”Människa-Dator Interaktion”, men min examen är i datavetenskap. Vad jag kommer ihåg fick man lära sig om kognition, alltså hur hjärnan jobbar med information, och en hel del om tekniker som kunde användas för att beskriva hur människor arbetar med system. De hade ofta tre- eller fyrstaviga förkortningar som HTA eller GOMS.

På kurserna fick vi också öva på att rita användbara gränssnitt, vilket var kul. Så när jag och en vän fick våra första jobb som Javautvecklare på ett litet spelföretag gjorde vi prototyper för spelet med papper, pennor och post-its. När jag bytte jobb och började utveckla webbapplikationer på ett litet företag inom telekomtjänster med 5 utvecklare fortsatte jag med det.

Jag gillade verkligen att utveckla men en dag köpte jag en bok som heter Användbarhet i praktiken (nu finns den som wikibok) som förklarade hur man kan arbeta för att uppnå användbarhet på ett hyfsat lättbegripligt sätt. Det finns bättre böcker på ämnet men den här är på svenska vilket hjälper, kort sagt gjorde den jobbet för mig. Jag insåg hur användbarhetsarbete kan gå till rent praktiskt, vilket universitetskurserna inte lyckats förmedla.

Användbarhetsarbete verkade jätteintressant och det fanns en del utrymme för att påverka utvecklingsarbetet på jobbet så jag började jobba mer med design, prototyputveckling och användningstester. Efter ett tag fanns det tyvärr inte så mycket användbarhetsarbete kvar att göra, bara utveckling, så jag bytte jobb för att ta steget fullt ut.

Min nya roll, vad den nu kallas, är både roligare och jobbigare än att vara utvecklare.

Roligare eftersom man kommer närmare kvalitetsaspekterna hos en tjänst. Man känner att man gjort en skillnad i högre grad och det man gjort syns mer, det finns inget skönare än en användare som gillar ens design. Man får också jobba mer med olika typer av människor, det är kul att få intervjua en aktiemäklare eller en mekaniker och förstå hur de arbetar och tänker. Sedan är det mer kreativt, vilket kanske är roligast av allt.

Jobbigare eftersom man oftare får stå till svars för sitt arbete. Vilken chef som helst kan ha åsikter om placeringen av en knapp men få kan förstå och kritisera programkod, och jag är ofta ensam ansvarig för placeringen av knappen. Detta gör att jag känner större ansvar för det jag gör men också mer press.

Jag skrev för ett tag sedan om vilka fördelar och nackdelar som finns med att ha utvecklarbakgrund så det behöver vi inte ta igen.

Boktips: A Project Guide to UX Design

På kurserna i Människa-Dator Interaktion på Umeå Universitet lärde man sig en massa teorier och filosofier. Jag kände redan då att något fattades och det blev riktigt uppenbart senare när man fick för sig att jobba med användbarhet ”på riktigt”. Boken Användbarhet i praktiken (som nu finns som wikibok) blev en ögonöppnare men det skulle lika gärna kunna varit den här boken, A Project Guide to UX Design, som handlar om hur man jobbar användarcentrerat i projekt. I motsats till Don’t Make Me Think som jag skrev om här innehåller den inga design-guidelines, istället handlar den om best practices för hur man kan arbeta. Den handlar om hur du fångar upp behov från beställare och användare, hur du använder dessa behov och landar i en prototyp via Personas, Site maps och Wireframes och hur du testar designen på dina användare.

Boken är släppt 2009 vilket är skönt. Innehållet känns aktuellt både i exemplen och i metoderna, man pratar aktuella designverktyg och agila projektmetodologier.

Det märks att författarna har stor erfarenhet. Boken tar ofta upp sådant som kan vara svårt i arbetet och i kommunikationen med andra projektmedlemmar. Den presenterar ofta många olika arbetssätt och listar för- och nackdelar, många böcker framför bara ett arbetssätt. I metoder för användarresearch presenteras t.ex. sex olika metoder.

A Project Guide to UX Design är som titeln antyder en guide till användarcentrerade projekt, ovärderlig för en nybakad interaktionsdesigner. För den som redan hittat ett arbetssätt man trivs med innehåller den dels alternativa arbetssätt och dels har den en massa bra insikter när det gäller relationen och kommunikationen mellan projektmedlemmar.

Är det något jag saknar så är det kopplingen mellan affärsnytta och användarnas behov, och mer om hur man prioriterar. Effektkartan skulle göra den här boken ännu bättre!

Boktips: Dont Make Me Think

Jag läste precis klart boken Don’t Make Me Think av Steve Krug och här kommer en liten recension.

Boken är kort och lättläst, full av färger och bilder. Ingen dagstidningskvalité, man har lagt lite krut på den tryckta produkten. De första kapitlen, och större delen av boken, ägnar sig åt designråd för interaktionsdesign av webbsidor. Till exempel hur en användare söker av en sida efter information, hur sidans navigation bör fungera, utformning av förstasidan o.s.v.

Efter det kommer en del som handlar om användningstester och hur man praktiskt utför tester med liten budget. Boken avslutas med ett kapitel om hur man hanterar besvärliga chefer.

Don’t Make Me Think vill vara den bok om användbarhet alla som utvecklar webbsidor har tid att läsa och det lyckas den bra med. Bra exempel och roliga anekdoter gör att ideérna och råden sjunker in och det är lätt att relatera dem till ens egna projekt.

Som introduktion till webb-användbarhet är den nog perfekt. För mig som läst lite innan och jobbat en del ger den nog inte lika mycket, men en del bra och läsvärda påminnelser om vad som är viktigast att tänka på.

Den senaste upplagan är från 2005 och lärdomarna är fortfarande aktuella men exemplen känns mossiga. Inte så konstigt med tanke på utvecklingstakten på webben.

Don’t Make Me Think på Adlibris

Don’t Make Me Think på Amazon

Nästa bok på min lista är A Project Guide to UX Design av Chandler/Unger. Den verkar mycket lovande, återkommer.