Kreativare interaktionsdesign

Här kommer några enkla tips på hur du kan öka din kreativitet och hitta bättre lösningar (kanske inte bara för interaktionsdesign):

  • Jobba tillsammans med någon annan – det är lättare att komma på nya idéer om man jobbar tillsammans och inspireras av varandra. När man sitter själv framför ett tomt papper är det svårt. Och du, det behöver inte vara en annan interaktionsdesigner som du jobbar med. Själv föredrar jag att jobba ihop redan från början, medan andra föredrar att sitta lite själv först. Se bara till att bolla dina idéer med någon annan.
  • Byt miljö – kanske blir du mer kreativ i poolen? Eller gå till närmsta café och sätt er.
  • Inspireras av andra. Och inte bara de som är i samma bransch, de har man oftast ganska bra koll på. Kolla hur helt andra sajter har löst ett problem eller hämta inspiration från någonting helt annat än en annan sajt. (tex Mobile UI patterns, UI patterns, Pattern tap, Smashing Magazine)
  • Gör massvis av alternativ. Nöjd dig inte med ditt första eller andra förslag. I ett projekt gjorde vi ett flertal djupintervjuer och i samband med analysen av varje djupintervju gjorde vi en snabb skiss på den ultimata lösningen för just den personen.
  • Brainstorming på riktigt. Ibland glömmer vi de grundläggande reglerna för brainstorming, som att inte kritisera. Kasta ur er alla idéer ni kommer på. En idé som kanske inte verkar så bra i ditt huvud kan någon annan spinna vidare på och tillsammans kan det bli något väldigt bra.
Publicerat i Interaktionsdesign, Kreativitet, Metoder | 3 kommentar

Användningstester, inte enkäter

För ett par månader sedan fick jag och en kollega i uppdrag att göra användningstester på ett intranät. Innan vi kom in i bilden hade man gjort ett omfattande arbete med enkäter. Man hade skickat ut en väldigt lång enkät, fått in väldigt många svar och gjort sammanfattning och möjlighet att skära enkätsvaren på alla möjliga vis i Excel. Det kändes som ett arbete som måste ha tagit väldigt lång tid. Det fick mig att fundera på vad värdet med enkäter är och när man bör använda enkäter respektive användningstester eller en kombination.

Träffa användarna istället för att skicka ut enkäter

I det läget vi kom in kändes hela enkätarbetet tyvärr ganska bortkastat. Resultatet av enkäterna pekade framförallt ut var det fanns problem med intranätet, men sa egentligen ingenting om en lösning. Och det är ju inte så konstigt, det går inte att fråga en användare hur han/hon vill ha det, det är ju det som är vårt jobb som interaktionsdesigners – att förstå användarnas behov och realisera det i en lösning för intranätet.

Att se i en sammanställning att många tycker att det är problem med sökfunktionen och att hitta i navigationen kändes ganska onödigt när det var något vi kunde se efter fem minuters titt på intranätet. Dessutom finns det flera punkter som man behöver förstå mer och som inte går att utläsa i en enkät. I enkäterna kunde man se att en avdelning var mindre nöjd med intranätet än andra avdelningar. Direkt när vi kom in på den avdelningen började vi ana att det nog inte var för att intranätet var ett sämre stöd för dem än någon annan avdelning utan att det var en helt annan stämning på den avdelningen än resten av organisationen. De var helt enkelt mer missnöjda med det mesta. I enkäten frågade man bland annat om man kände till en specifik del av intranätet och ställde frågan med det namn som man på redaktionen benämnde den med. Här kunde man i enkäten se att kännedomen var mycket lägre än man hade hoppats på. I vårt arbete kunde vi dock snabbt konstatera att kännedomen om den specifika delen av intranätet var högre än enkäten visade och att man uppskattade den delen, däremot kände man inte till redaktionens benämning på den då det var något som var ganska undanskymt. Det viktiga för organisationen var att man tog till sig innehållet på den delen av webbplatsen inte att man kände till redaktionens benämning därav blev frågan i enkäten egentligen helt irrelevant. Hade man bara tittat på enkäten hade man aldrig förstått det.

Vårt angreppssätt – användningstester och intervjuer

Bland det första vi gjorde när vi kom in i projektet var att ta oss igenom alla enkätsvaren och sen konstatera att det hade vi nog inte så mycket nytta av. Istället satte vi oss och tittade på intranätet och skrev ner ett antal punkter som vi misstänkte var problem med intranätet och som vi ville undersöka vidare. Vi bokade in ett antal möten med medarbetare (ca 15-20 stycken) från olika avdelningar. Under dessa möten satt vi vid medarbetarens vanliga arbetsplats för att få en bättre totalbild av dennes arbete. Varje möte bestod av tre delar och tog totalt ca en timme. Första delen var en intervju där medarbetaren fick prata om sin roll i organisationen, vad de jobbar med och hur en typisk arbetsdag ser ut. I del två var fokus användning av intranätet utifrån roll. Vi frågade medarbetaren vad denne brukar använda på intranätet, sist den använde intranätet (situation och vad), sist den letade efter något på intranätet men inte hittade det, bäst och sämst med intranätet och liknande. I tredje och sista delen hade vi styrda uppgifter och frågor. Där fokuserade vi på delar vi inledningsvis identifierat som delar som kan vara problematiska och som vi skulle vilja veta mer om.

Genom dessa möten fick vi en bra förståelse för förbättringsområden på intranätet och kunde även skissa på förslag till förbättringar. Vi kunde också konstatera att vi tyvärr inte hade haft någon nytta av enkätarbetet. I själva verket hade det till och med vara lite bortkastad tid för oss att ens gå igenom resultatet. Om tiden för enkäterna (att skapa dem, sammanställa dem och för varje medarbetare att svara på dem) istället hade lagts på fler användningstester och intervjuer hade vi fått en mycket bättre förståelse för hur vi skulle ha kunnat förbättra intranätet.
Så när du vill veta vad som är problem och hur du ska lösa dem är det viktigt att du träffar de riktiga användarna. De är inte kvantitet som är det viktiga utan kvalitet. Du behöver förstå användarna och deras behov. För att få kvantitet kan det i många lägen vara mer effektivt att använda sig av webbanalys.

När ska man använda enkäter då?

Jag är ganska negativt inställd till enkäter, så jag tar gärna emot synpunkter på fler tillfällen då de kan vara bra. Jag tycker att de kan vara bra om man vill reda ut grundläggande frågor. Det kan t.ex. vara att få veta hur många av webbplatsens besökare som har en mobiltelefon som de brukar surfa med, som bakgrund till ett beslut.

Jag är tveksam till att lägga ut enkäter för att tex mäta hur lätt det är att hitta på intranätet/webbplatsen före och efter en omstrukturering. Då tror jag mer på att analysera statistik för att få kvantitet kombinerat med användningstester och intervjuer för djupare förståelse.

Relaterade inlägg

Publicerat i Användbarhet, Användningstester, Informationsstruktur, Interaktionsdesign, Metoder | 2 kommentar

1177.se Sveriges bästa sajt inom offentlig sektor

Skumpan hälls upp

I förra veckan släppte Internet world sin topp 100 lista och vi som skriver här på useruser blev så klart extra glada att 1177.se utnämndes till Sveriges bästa sajt inom offentlig sektor.  Vi har alla tre varit inblandade i olika skeden av sajtens utveckling och jobbat med användarupplevelsen, interaktionsdesign och användbarhet, från start av utvecklingsprojektet fram till nu (och framöver). I teamet har vi hela tiden varit flera specialister inom interaktionsdesign, grafisk formgivning och användarupplevelse. Vi har jobbat tight ihop med varandra och med resten av teamet i det agila projektet. Vi har under hela utvecklingen haft kontinuerliga användningstester i varje sprint. Det har varit väldigt kul att jobba i ett projekt där man satsar på användarupplevelse och det känns så klart extra kul när det belönas med fina pris.

På Valtech passade vi på att fira med lite bubbel. Här ser du en stor del av gänget på Valtech som varit med att och utvecklat sajten, tillsammans med en av produktägarna. Alla har så klart inte jobbat samtidigt i projektet, men var och en har bidragit med en viktig del.

Delar av Valtechgänget bakom 1177.se

Publicerat i Övrigt | Lämna en kommentar

Tjänstedesign på Valtech experience days

Har tänkt lägga ut min och Johannes Bäckströms presentation från Valtech Experience Days en tid. Äntligen händer det. Presentationen handlar om vad tjänstedesign är och varför man ska jobba med det. Jag pratar bland annat om hur Mini Cooper har lyckats få mig till en väldigt nöjd kund och marknadsförare av en häftig kundupplevelse. Vi pratar om kundresor och kontaktpunkter och styrkan i att måla upp hela kundens resa (customer journey map) innan man beslutar vad som ska vidareutvecklas i tjänsten. Kolla in filmen eller titta på bilderna nedan.

Relaterade inlägg

Publicerat i Användbarhet, Kreativitet, Metoder, Tjänstedesign | Lämna en kommentar

Agil coach: boktips och reflektioner

Jag har börjat ett nytt uppdrag som agil coach i en organisation som tidigare anammat en del agila tankar och som nu vill prova på ett ännu mer agilt arbetssätt. Jag arbetar tillsammans med ett av teamen i organisationen. Mitt främsta mål med uppdraget är att teamet ska tycka det är ett roligare sätt att arbeta. Det tror jag är största chansen att det nya arbetssättet hänger kvar när mitt uppdrag är slut.

Inför detta uppdrag köpte jag boken Agile coaching av Rachel Davies och Liz Sedley. Jag gillade verkligen boken och sög i mig ny kunskap direkt. Boken är skriven utifrån Rachel och Liz erfarenheter och jag gillar att det finns exempel och praktiska tips, det är inte bara ”så här ska du göra” utan mer tips på olika sätt och mer hur man ska tänka än konkret lösning. Om du jobbar eller vill börja jobba agilt kan jag verkligen tipsa om boken, den är nyttig oavsett roll i teamet. Är du agil coach känns den nästan som ett måste.

Det som var allra mest nyttigt för mig var tips och tankar kring hur man är en bra agil coach, eftersom jag tidigare varit teammedlem eller scrum master. Det som blir den största omställningen för mig är nog att jag inte har något som jag direkt producerar och att mycket tid borde gå ut till att iaktta och fundera på lösningar på problem och förbättringar.

Ett tidigt råd till en scrum coach var ”led genom exempel” där man fick tipset att skriva ner vilka agila principer man vill visa och hur. Jag fick bla ned dessa punkter i min lista:

  • Kommunikation öga mot öga istället för via mail.
  • Inspect and adapt
    • Fråga teamet: vad tycker ni jag ska göra? Vad funkar bra/dåligt?
    • Ge direkt feedback (extra viktigt för mig som är lite konflikträdd)
  • Se till att säga ”Vad tycker målgruppen” och prata utifrån våra beteendebeskrivningar och inte prata utifrån mig som användare. Detta är ju egentligen ingen agil princip utan en princip från användarcentrerad utveckling, vilket jag tycker är minst lika viktigt.
  • Säg inte bara ”Det går inte”, utan hitta ett sätt att komma runt. Titta på vad vi som team kan göra.

En viktig del som jag behöver fundera på hur vi löser i mitt team nu är buggrapportering. I boken skriver de mycket om att när man har ett separat system för att logga buggar resulterar det i en andra gömd backlog. Utöver den vanliga product backlogen finns också bugglistan. Då hamnar vi i ett läge där user stories och buggar inte prioriteras lika och mot varandra. I vissa team sätter man en fast tid till att rätta buggar, men det kan ju göra att man lägger tid på något som ger mindre värde om det är så att det finns user stories som ger högre värde än att rätta de buggar som finns. Eller så är det tvärt om, det finns inte tillräckligt tid att rätta buggar som skulle ge högre värde än de user stories som finns i backlogen. Lösningen på detta skulle vara att se till att buggar som inte hanteras i sprinten hamnar i produktbacklogen tillsammans med user stories med nya önskemål. Jag tror själv att det oftast är den bästa lösningen, men är lite rädd för att hamna i en situation där produktägaren har svårt att värdera värdet av att få en viss bugg rättad jämför med ny utveckling. Ofta kan det ju vara så att varje enskild bugg inte har så stor påverkan, men totalt drar det ner produkten om det finns många buggar. Det går ju också helt emot Broken window tanken och Stop the line inom lean. Jag får klura på den ett tag till helt enkelt och se till att teamet testar sig fram.

Det enda som jag inte gillade med boken var att de verkar tänka på user experience som ett eget team. Det dröjde en ganska lång bit in i boken innan jag läste orden ”user experience team” och därmed insåg att de antagligen hela tiden tänkt att ux inte fanns med i teamet. För mig är det så självklart att ett riktigt scrumteam är tvärfunktionellt och har all kompetens som behövs för att klara uppgiften, vilket måste innebära att user experience kompetensen finns i teamet och inte i nåt annat team. Är UX i ett annat team så blir det ju något slags vattenfall i alla fall där ux behöver göra skisser innan de kan ges till utvecklingsteamet. Då blir det inte så lätt att styra om eftersom teamet inte kan utveckla nåt som ux-teamet inte har skissat. Dessutom missar man ju hela samarbetsbiten där alla kompetenser tillsammans kommer fram till den bästa lösningen och det finns chans att bolla fram och tillbaka under utvecklingen. Som tur var påverkade den här skillnaden i synsätt inte min chans att ta till mig en massa nyttigheter från boken utan för det mesta innehållet spelar frågan ingen roll.

Min nästa bok är Coaching agile teams av Lyssa Adkins, jag hoppas den är lika bra. Har ni några fler boktips?

Relaterade inlägg

Publicerat i Agilt, Metoder | 1 kommentar

Personas eller beteendebeskrivningar?

Personas och beteendebeskrivningar (eller beteendeprofiler som de också kan kallas) är två bra sätt att beskriva målgrupper och deras behov och göra dem mer konkreta.  Genom att ha bra målgruppsbeskrivningar kan man lättare se till att beslut tas utifrån målgrupperna och deras behov. När målgruppsbeskrivningarna är förankrade i organisationen och projektgruppen kan man komma bort från att designa ett system utifrån sina egna behov och istället tänka på målgrupperna. Man kan lyfta diskussioner från ”Om jag använde det här skulle jag vilja…” till ”För Karin vore det nog bättre med…” (om man använder personas) eller ”För Spontanhandlaren vore det nog bättre med…” (om man använder beteendebeskrivningar). Vilken typ av målgruppsbeskrivning som passar bäst beror främst på hur målgruppen och deras behov ser ut.

Personas

Personas är ett sätt att beskriva fiktiva användare som representerar delar av målgrupperna. Ofta beskrivs de med namn, bild, karakteristiska drag och beteenden. Syftet med att beskriva dem så här är att försöka förankra målgrupperna i organisationen. Med en bild, ett namn och en berättelse om personan får de som arbetar i organisationen och i projektet lättare att komma ihåg personan och därmed målgruppen. Nyckeln är att ständigt prata om och visa upp personas så att de blir en naturlig del av projektet och att man  tar beslut utifrån insikter om målgrupperna. Ett lyckat exempel är utvecklingen av antagning.se, en ny webbplats där man söker till universitet och högskola. Där pratade vi ständigt om Lisa, Johan och Pernilla som var våra personas. De blev en naturlig del av vårt arbete och det var väldigt vanligt att produktägare och andra personer på VHS pratade om dem som att de var levande varelser; ”Det här skulle Pernilla gilla, hon skulle kunna hitta liknande kurser och bli inspirerad att söka något mer.”

För att använda personas krävs att målgrupperna är tydliga och att man kan knyta vissa beteenden, kunskaper eller behov till en specifik målgrupp. Det är även bra i de fall där olika målgrupper ska behandlas olika eller har olika regler att förhålla sig till, t ex att Lisa måste skapa ett nytt konto för att kunna anmäla sig till kurser, medan Johan loggar in via ett universitet.

Beteendebeskrivningar eller beteendeprofiler

Beteendebeskrivningar beskriver olika beteende snarare än en viss person. Ibland kallar man dem även för beteendeprofiler. Dessa är bra för att synliggöra att en person i målgruppen kan ha flera olika beteendemönster beroende på situation. De är bra att använda när det inte går att säga att en viss del av målgruppen beter sig på ett visst sätt. Terese har nyligen använt det i ett projekt för en slags e-handelsajt. Där såg vi tydligt att det inte gick att säga att en småbarnsförälder eller en pensionär har ett visst beteende. Det var snarare så att vi kunde se att det fanns t.ex. ”Spontanhandlaren”, som går väldigt snabbt från idé om att handla till att faktiskt köpa, och ”Grundliga undersökaren” som jämför flera olika återförsäljare och snarlika produkter och läser på om produkterna på andra sajter innan h*n slår till. Vi kunde se att en del personer alltid är t.ex. ”Grundliga undersökaren” medan andra personer kan anta olika beteendemönster beroende på situationen. Vi såg även att vissa personers beteende inte gick att stoppa direkt i någon av beteendebeskrivningarna utan plockade vissa delar från två olika beskrivningar. Då vi totalt med våra fyra beteendebeskrivningar hade täckt in alla olika typer av beteenden kände vi oss trygga med våra beskrivningar och kunde ta bra designbeslut utifrån dem.

Vad ska man välja?

Vårt tips är att inte för tidigt bestämma sig för hur man ska skriva målgrupperna utan att först göra målgruppsundersökningar och få en förståelse för dem. Sedan är det dags att fundera på vilken beskrivning som passar bäst. Dels utifrån de beteende- och användarmönster som man ser och dels utifrån organisationen man arbetar med. Ibland passar det ena helt enkelt bättre än det andra. Båda typerna av målgruppsbeskrivningar är någonting man bör arbeta med under hela projektet och hålla levande. Se därför till att uppdatera beskrivningarna allt eftersom ni lär er mer om målgrupperna, så kommer de bara blir mer och mer användbara för er. Se även till att alla inblandade i projektet (både i projektgruppen och intressenter) har koll på målgruppsbeskrivningarna och vilka det faktiskt är som vi gör detta för. Fatta sedan beslut, både stora också små, utifrån dessa målgrupper.

/Anna & Terese

Relaterade inlägg

Publicerat i Användbarhet, Interaktionsdesign, Metoder | 2 kommentar

Användbar skylt?

Jag har stött på roliga skyltar igen. Den här gången på vattenkranarna hos en kund. Från den ena kranen får man vatten, från den andra kolsyra. Så om jag vill ha kolsyrat vatten tar jag då först vatten och häller sen i kolsyra? Jag gillar också hur man valt att använda två olika vattenfall för att illustrera innehållet i kranarna. Vilket vattenfall har kolsyra?

vatten

Den här gången var det inte så svårt att förstå skyltarna även om jag och min kollega fick oss ett gott skratt. Annat var det när jag sprang på skylten vid papperskorgen, den förstår jag fortfarande inte.

Relaterade inlägg

Publicerat i Användbarhet, Övrigt | 2 kommentar

Öppet hus hos Funka

I torsdags var vi (Josefin och Terese) på öppet hus med seminariet ”Så funkar mobilen för blinda” hos Funka. De hade några olika stationer där man kunde prata om tillgänglighet och se hur olika hjälpmedel fungerade.

Mobil för blinda

Det mest intressanta var att se just hur mobilen funkar för blinda. Vi fick se hur en blind använder en iPhone och en äldre telefon utan pekskärm. IPhonen styrdes genom att användaren fick höra vad han drog fingret över och också vad han kunde göra, tex ”Facebook klicka för att starta”. På samma sätt fick han när han surfade i Safari uppläst vad han drog fingret över. Han kunde också höra ett litet knarrande när en sida laddas så att han visste när den var färdigladdad. Problemet där är att man behöver känna till hur en sida funkar så man vet om den laddas om vid tex ett knapptryck eller om det sköts via javascript. Det skiljde sig alltså mot en traditionell uppläsare där man tex får länkarna upplästa och hoppar mellan dem, här är det istället fingret som styr. Han sa att de tog ett tag att lära sig eftersom det skilde sig så pass mycket till hur man använder en vanlig dator. Det häftigaste var nästan att se hur snabbt han ville att det skulle läsas upp och hur han förstod vad de var genom att bara höra de första stavelserna. De appar som demonstrerades var appar som han använt tidigare så han visste vad som fanns på skärmen och vad han kunde göra. Det hade varit intressant att se hur klurigt det hade varit med en, för honom, helt ny app. Med den lite mindre moderna telefonen utan pekskärm fungerade det mer som en traditionell skärmuppläsare och han kunde när han surfade hoppa mellan tex de olika länkarna och få dem upplästa.

Skärmförstorare för synskadade

Vi fick också se hur en skärmförstorare kan fungera. Många synskadade har speciella program som förstorar innehållet på skärmen och som innehåller andra hjälpmedel för att underlätta till exempel navigering. I många fall är det alltså inte tillräckligt att bara förstora i browsern med den inbyggda funktionen när man surfar eftersom vissa element då inte alls förstoras (till exempel scrollbars eftersom bara själva webbsidan förstoras). Skärmförstoraren som vi fick demonstrerad förstorade till önskad zoom och hade stora pilar som visade vilka fält som var inmatningsfält. Mannen som demonstrerade och som själv var synskadad brukade navigera både med musen och genom att tabba sig fram.

Vi fick några nya insikter:

  • Om sidhuvudet är högt och det uppe i vänstra hörnet saknas element som beskriver var man har hamnat kan det vara svårt för en som använder skärmförstorare att förstå var h*n hamnat om inzoomningen är kraftig.
  • Det underlättar för en synskadad som använder tabbning för navigera att tydligt synliggöra vilket element som är markerat just nu. Han gav ett exempel på en toppmeny där ett markerat alternativ hade ett tjockt streck under själva rubriken som tydligt visade vilken rubrik som var markerad. Det räcker alltså inte med den streckade rutan som vanligtvis används.
  • Maximal kontrast behöver inte betyda bästa möjliga förutsättningar för synskadade. Vilka färger och kontraster som fungerar bäst beror på synskadans art och kan variera (men låg kontrast är aldrig bra för en med grav synskada).
  • Det är bra att ha en linje i vänsterkant på sajten som är enkel att följa för att veta var i sidled på sajten man är. Vid kraftig inzoomning som det ofta handlar om är det annars lätt att tappa bort sig.

Tillgängligt för alla – går det?

Vi kom återigen att fundera, som vi har gjort många gånger innan (se tidigare inlägg), på om det går att göra webbplatser maximalt tillgängliga både för personer med funktionshinder och personer utan. Ta kontrastfrågan som exempel. Väldigt hög kontrast som oftast är bra för en synskadad kan vara väldigt irriterande för en person utan synskada. När vi såg vilka stora kontraster den synskadade vi träffade ville ha kände vi att det för oss skulle vara jobbigt att ta till oss informationen på sidan då det skulle blivit så skrikigt. Eller ta problemet med små klickytor. En med synskada kan behöva stora klickytor för att enkelt kunna klicka på ett objekt men för en utan synskada kan stora klickytor istället innebära att grupperingskänslan försvinner när objekt hamnar för långt ifrån varandra och då försämras istället logiken i navigeringen.

Så vad är viktigast? Eller snarare – vilka är viktigast. Det går naturligtvis inte att ha en generell ståndpunkt här, men i många fall måste man välja för att det ska bli riktigt bra för någon av grupperna. Om 98% av användarna inte har någon funktionsnedsättning och sajtens syfte är att tjäna pengar på försäljning, då kanske det bästa är att optimera för dessa 98% och göra vad man kan för övriga utan att förstöra för den stora massan. Men är avsändaren en myndighet som riktar sig till hela populationen och har ett serviceansvar så kanske det är bättre om det är lite sämre för de utan funktionshinder för att alla ska kunna använda sajten. Tyvärr är det aldrig svart eller vitt.

Publicerat i Användbarhet, Tillgänglighet | 5 kommentar

Innehållsstrategi

Det blir tydligare och tydligare att vi måste ta innehållet på allvar. Flera webbkonsultföretag anställer innehållsstrateger/copywriters/språkkonsulter som jobbar med innehållsstrategi och texter, eller Content strategy som det ofta benämns med. Det gamla arbetssättet att bygga en nästan färdig webbplats med strålande design och bra redaktörsgränssnitt och sedan lämna den i händerna på organisationen för att de själva ska fylla den med innehåll, är inte ett hållbart arbetssätt. I många projekt kommer innehållet sist och det är först då som man upptäcker att designen inte riktigt passa ihop med innehållet. Eller att man bara försöker migrera över allt innehåll till den nya webbplatsen och att det inte blir så bra som man tänkt sig. Lika ofta börjar man försent att strukturera innehållet på riktigt och ofta är organisationen inte uppbyggd för att arbeta med innehållet på ett strukturerat sätt.

Innehåll och koncept tillsammans

Börja jobba med innehållsstrategin redan från början så att det kan gå hand i hand med design och koncept. Och se till att det finns en organisation som jobbar aktivt och nära utvecklingsteamet under hela projektets gång. Vanligtvis brukar vi användbarhetskonsulter dra upp riktlinjer för innehållet och hålla workshops med organisationen om vilket innehåll som är prioriterat och hur det ska ta plats i konceptet. Men ofta ligger ansvaret på organisationen att fylla ramarna med det konkreta innehållet. Om de innehållsansvariga inte jobbar tätt ihop med de som utformar design och koncept så är det väldigt svårt att få ihop en bra helhet.

Det finns även många exempel på utvecklingsprojekt där vi gör wireframes och designskisser och fyller på med lite ogenomtänkt text eller kanske till och med lorem ipsum. Självklart förklarar vi för åskådarna att det bara är nonsenstext och att de inte ska hänga upp sig på detaljerna. Självklart hänger de upp sig på rubriker och innehåll och det första de säger är ”Ska det verkligen stå så där?”. Också detta är självklart eftersom nonsensinnehållet stör helhetsbilden och förstör budskapet i konceptet. Koncept och innehåll måste gå hand i hand. På så sätt blir det tydligare att vi är på rätt väg och att konceptet utstrålar rätt budskap.

Men vem ska jobba med innehållet? Det är bra om det finns utvalda innehållsansvariga inom organisationen som känner till varumärke och affärsstrategi och som sedan kan förvalta innehållet, hålla det uppdaterat och vidareutveckla. Dessa personer måste vara involverade i utvecklingsprojektet så att koncept och innehållsstrategi kan formas sida vid sida. Annars blir det en klassiskt dålig överlämning som riskerar att stjälpa både innehåll och design. Men det är också värdefullt att en person utanför organisationen är med och utformar strategin. En expert kan se med nya ögon på det som redan finns och kan hjälpa organisationen att prioritera och rensa.

Saker att tänka på för att lyckas med innehållet på en webbplats.

  1. Det måste finnas en uttalad organisation som har ansvar för innehållet och som jobbar aktivt genom hela projektet och som jobbar tätt ihop med resten av design- och utvecklingsteamet. Det är viktigt att dessa personer har rätt kompetens och engagemang, det är inte ett uppdrag man delar ut till de som har lite tid över. Det behövs en innehållsstrateg/copywriter/språkvårdare eller liknande som kan ta ett helhetsansvar och det måste finnas en strategi för hur beslut tas. Dessa personer måste även ha ansvar för förvaltningen av innehållet. De strategier man har arbetat fram under utvecklingsarbetet måste leva vidare i förvaltningsarbetet.
  2. Samarbeta. Om det finns flera personer som skriver innehåll så är det en fördel att granska varandras texter och bolla idéer med varandra. Det är lättare att upptäcka fel och komma med förbättringsförslag när man ser innehållet på nytt och inte har hunnit bli hemmablind.
  3. Vem är innehållet till för? Precis som med resten av konceptet måste man tänka på användaren eller personan även när man utformar innehållet. Är innehållet anpassat till de prioriterade målgrupperna? Vill ”Lisa” läsa det här? Förstår hon vad som menas? Tilltalar det henne?
  4. Vad är det huvudsakliga budskapet i den information som ska visas? Innehållet måste vara användbart. Hjälper det användaren? Finns det ett behov av innehållet? Är det aktuellt? Vad ska det leda till? Vad är meningen med innehållet? Vilken tonalitet ska användas? Vilket språk och tonläge passar varumärket?
  5. Vilket innehåll ska finnas kvar av det som eventuellt redan finns på den gamal webbplatsen? Vad behöver skrivas om? Vilket innehåll är prioriterat? Vilket ska tas bort? Det är alltid lättare att ha en grund när man skriver och inte behöva skriva från ett blankt papper. Men det är viktigt att verkligen tänka igenom om det innehåll som finns är relevant och viktigt.
  6. Vilka skrivregler och språkregler ska finnas? Jag är ingen påhejare av regler och begränsningar men det kan vara bra med en översiktlig genomgång eller utbildning så att innehållet inte spretar för mycket.

Det lönar sig att ta hand om innehållet och ta fram en innehållsstrategi i projektets första steg. Ett projekt där det funkade bra är VHS och antagning.se där jag och de andra i design/ux-teamet jobbade tätt ihop med språkvårdare och innehållsansvariga under utvecklingsprojektets gång. Det belönades med vinst av Klarspråkskristallen 2011.

Om du vill lära dig mer om content strategy så borde du bege dig till CS forum i London i höst.

Publicerat i Användbarhet, Informationsstruktur, Innehåll, Webbstrategi | 2 kommentar

Tjänstedesign

En allt större del av vår ekonomi utgörs av tjänster. Jag har läst siffror som visar att 70-80% av Sveriges och Europas ekonomier baseras på tjänster. Vi är traditionellt sätt duktiga på att designa både fysiska och digitala produkter. Tjänstedesign handlar delvis om att applicera de metoder som vi använder i produktdesign även på tjänster. Eftersom utbudet av tjänster är stort och det är enkelt att hitta och välja bland liknande tjänster, så måste vi helt enkelt designa våra tjänster ur ett helhetsperspektiv för att de ska bli framgångsrika. Det finns många bra definitioner av vad tjänstedesign eller Service design är och varför företag efterfrågar det. Man kan beskriva det som att planera och organisera personer, infrastruktur, kommunikation och produkter i en tjänst för att optimera användarens upplevelse av tjänsten. Det finns också många diskussioner om hur tjänstedesign förhåller sig till user experience. Det finns helt klart många gemensamma nämnare och grundidén är densamma; det handlar om att förstå användaren. Jag tycker däremot att titlar och begrepp är mindre intressant. Men ur ett säljperspektiv är det enklare att förhålla sig till de begrepp som finns för att förenkla (?) erbjudandet.

Vad är en tjänst och hur designar man den?

Det finns olika typer av tjänster och många olika sätt att beskriva dem på. Några tjänster bygger på att kunden beställer och betalar för att få en aktivitet utförd, t ex att lämna in bilen för reparation eller att gå till frisören för att klippa håret. Andra tjänster handlar om att kunden betalar för en upplevelse, t ex att besöka en djurpark eller flyga luftballong. Vissa tjänster handlar om att sälja kunskap eller förändring, t ex att gå till en träningsanläggning eller gå till en terapeut. Men jag tycker att det är svårt att kategorisera tjänster, eftersom en tjänst oftast består av alla typer av det som jag just beskrivit. Om du går till en massör så betalar du säkert både för att få ryggen i gott skick, men även för att få en skön lugn stund och för att lära dig hur du bättre tar hand om din rygg. Och vad just du är beredd att betala för beror ju på vilka drivkrafter och behov som just du har. Upplevelsen av en tjänst baseras alltså på flera faktorer.

Ju fler tjänster det finns som hjälper oss lösa vårt problem, eller kanske till och med överraskar oss och får oss att upptäcka ett nytt behov, desto kräsnare och mindre lojala blir vi. Om det finns ett bättre sätt så byter vi. För att göra en tjänst lönsam måste vi alltså lyssna på och tolka våra användare för att förstå vad som får dem att välja just vår tjänst. Tjänsten måste upplevas som enkel och effektiv och helst rolig, nyttig och åtråvärd.

För att designa en tjänst behöver man undersöka tjänstens alla kontaktpunkter. Kontaktpunkter eller touchpoints är alla delar av tjänsten som användaren kommer i kontakt med. Det kan vara fysiska produkter, digitala gränssnitt eller kommunikation mellan människor. Varje kontaktpunkt påverkar upplevelsen av tjänsten. Och eftersom användare har olika drivkrafter och behov så påverkar olika kontaktpunkter olika användare på olika sätt. Som vanligt alltså. Därför måste vi självklart definiera de prioriterade målgrupperna, effektmålen för tjänsten/företaget och prata med användarna för att förstå dem och upptäcka användningsmönster och behov. Och sen måste vi testa våra idéer, göra prototyper och testa igen. Som vanligt alltså.

Metoder och verktyg

Förutom det som vi alltid sysslar med när vi jobbar användningscentrerat så finns det lite verktyg som man kan använda för att definiera tjänsten. Det är ofta värdefullt att visualisera alla kontaktpunkter och vad tjänsten består av samt hur användaren förhåller sig till tjänsten.

Customer journey map är en karta som beskriver ”kundens resa” genom tjänsten. I den beskrivs alla kontaktpunkter före, under och efter användandet av tjänsten och ofta beskrivs även möjligheter och problem med de olika kontaktpunkterna.

En Customer lifecycle map används för att visualisera vad som behövs för att attrahera en kund i olika steg av i tjänsten – när kunden funderar på att börja använda tjänsten, när hon använder den och när hon funderar på att överge den. Detta kan vara värdefullt för att förstå olika drivkrafter och engagemang hos användaren samt att visualisera varför och när en användare funderar på att lämna tjänsten.

Det finns en uppsjö av metoder beskrivna i boken This is service design thinking. Servicedesign tools är också bra om man vill få lite inspiration.

Publicerat i Användbarhet, Metoder, Tjänstedesign | 2 kommentar