Idéfasen syftar till att beskriva en idé om en digital tjänst på ett sådant sätt att det går att ta beslut om att bygga den eller inte. Idéfasen ska ge ett underlag som kan troliggöra eller avfärda att man kommer att få en nytta som är större än investeringen. Idébeskrivningen skall också kunna användas som byggunderlag.

När idéfasen startar finns ofta redan en tanke om vilka värden den nya tjänsten skall skapa. Det vår arbetsmodell gör är att den hjälper till att analysera och beskriva värdekedjan. Detta blir möjligt därför att vi utgår från att nyttan uppstår i användningen. Vi menar att effekter i verksamheten (monetära eller andra värden) kan uppstå endast då användarna upplever en nytta som är större än den ansträngning som de gör : därför devisen nyttan uppstår i användningen.

Ta SMS som exempel – som är ganska knöligt att använda, men som ger en påtaglig och snabb nytta – därför använder vi tjänsten om och om igen! Tänk dig sedan in i hur det är med tidrapporteringsrutiner. Användare drar sig ofta för att tidrapportera…helt enkelt därför att de upplever att de lägger ner mer arbete än den nytta de får. Lärdomen är att om motivationen och den upplevda nyttan är hög, så kan produkten tillåtas vara (men behöver såklart inte vara) knölig. Om motivationen är medel eller låg så måste lösningen utformas så att användarens arbetsinsats minimeras och nyttan maximeras – först då kan förväntade värden uppstå.

Idéfasen handlar om att systematiskt reda ut de stora frågorna, så att man (i mesta möjliga mån) slipper tampas med dem längre fram i projektet då man börjat bygga, eller i förvaltning. Det är annars mycket vanligt att man kommer in i byggfasen och

• Inte har klart för sig vilken nytta som tjänsten skall skapa för verksamheten. Om man inte vet vad tjänsten skall skapa för värden för användarna och verksamheten så kan man inte:
• värdera lösningsförslag. Om det inte finns en tydligt syfte med produkten är all design lika bra.
• avgöra om tjänsten fungerar som tänkt. Utan tydligt syfte med produkten är det mycket svårt att hitta entydiga mätpunkter för att kontrollera att förväntade positiva värden för användarna och verksamheten uppstår.
• styra byggprojektets omfattning och inriktning. Utan tydligt syfte är risken överhängande att omfattning och inriktning svänger utan att man märker det.
• Inte har klart för sig vilka som skulle använda tjänsten. Om man inte känner målgrupperna och deras behov, så gissar man. Det betyder att man riskerar att lägga tid på lösningar som ingen vill ha.
• Saknar prioriteringar. Om man inte vet vilka målgrupper som är viktigast och vilka behov som måste tillgodoses först, så blir det svårt att planera projektet rätt. Det blir också svårt att veta vad man kan välja bort när man hamnar i tids- eller kostnadsnöd.

Idèfasen består därför av tre delar, som självfallet inte slaviskt behöver utföras i sekvens.

Syftet här är att tydliggöra vilka nyttor (effekter) som den nya produkten förväntas skapa för verksamheten. Det brukar finnas projektmål som beskriver vad projektet förväntas leverera. Det är nödvändigt för att styra projektet, men duger inte för att ge underlag för god design. Det behövs också effektmål, som beskriver vilken skillnad (för verksamheten och för användarna) som tjänsten skall skapa när den används fullt ut.

Vi ser ofta effektmål som är otydliga, exempelvis ”tjänsten skall vara användbar” eller som snarare beskriver verksamhetsmål och inte vad tjänsten i sig förväntas åstadkomma: ”omsättningen skall öka med 20% under året”. Problemet med att effektmålen är otydliga är att det blir svårt att avgränsa projektet. Risken är överhängande att man gör tillägg och ändringar under projektets gång som fördyrar projektet, men som inte nödvändigtvis gör produkten bättre.

Det finns olika tekniker för att beskriva effektmål. Vi själva föredrar att ta fram en Effektkarta ® som skiljer sig från andra tekniker genom att den avgränsar målbeskrivningen till att omfatta endast de effekter som just denna produkt kan åstadkomma. På så sätt finns sedan en direkt koppling till vad som ska mätas och följas upp i projektet och i förvaltningen.

Vi föredrar att samla kunskap med hjälp av intervjuer med beslutsfattare och idégivare. Intervjuerna är undersökande och utforskande med syftet att ta reda på svaret på frågan ”vad har blivit bättre i verksamheten när tjänsten används fullt ut”. För att kunna göra denna typ av intervjuer måste man som kartläggare ha en hel del för-förståelse, så att man kan ställa frågor som tydliggör tjänstens roll i verksamheten. Ledare och beslutsfattare har ju hela verksamheten som sitt perspektiv (eller i alla fall sitt expertområde) och kan inte förväntas avgränsa sina tankar och idéer till den digitala tjänsten enbart!

För att kunna ställa spetsiga frågor kan man förbereda sig på flera sätt: - Läs på om verksamheten. Årsredovisningar, verksamhetsberättelser och för offentliga verksamheter: regeringsuppdraget är ovärderliga källor för att få en bild av vad som värderas högt för verksamheten. - Utvärdera liknande tjänster. Vad gör dem framgångsrika? Vad saknas. - Utvärdera befintliga tjänster som finns i verksamheten. Vilken slags nytta skapar de? Vad är det som uppskattas hos dem, vad är det som saknas? - Läs projektdirektiv eller projektidéer. Vilka slags produktmål beskrivs, eller kan anas här?

En annan teknik att samla in underlag för att formulera effektmål är workshops. Det kan fungera väl i en verksamhet där man redan tänkt en hel del runt den nya tjänsten, exempelvis ett produktbolag. Vi föredrar att använda workshop som reflekterande och inspirerande tillfällen, inte för att samla in information.

När väl intervjuerna är genomförda är det dags att formulera effektmål. Här är det inte ovanligt att man kan se olika typer av ambitionsnivåer och olika omfattningar för lösningen. Det kan också vara så att man upptäcker att en interaktiv produkt kanske inte är det bästa sättet att åstadkomma det man vill, som i exemplet med Kent Påhlsson och möbelföretaget.

Tekniken för att formulera effektmål omfattar fyra steg– som inte nödvändigtvis utförs i sekvens;

1. Formulera vilka typer av effekter som tjänsten förväntas ge? Syftar tjänsten främst till effektivisering, eller skapas den för att inspirera till något visst beteende? Några exempel på områden: effektivitet, stärkt varumärke, kunskap, intresse, enkelhet, snabbhet, arbetstillfredsställelse.
2. Formulera vad som skall ha hänt inom respektive typ av effekt. Vad är det man kan tänka sig att utvärdera eller mäta inom respektive typ? Vad är det specifikt som just denna tjänst kan åstadkomma? Om vi tänker oss att skapa en ny plattform för samarbete eller ett intranät – är det rimligt då att tro att den skall leda till minskad personalomsättning om man vill mäta arbetstillfredsställelse? Det finns många andra aspekter som påverkar personalomsättning än just intranätet. Kanske det är bättre att utvärdera hur användare upplever att intranätet gjort deras arbete roligare/enklare/meningsfullare….?
3. Formulera hur mätning kan göras – om du tänker följa upp effektmålen. Kan detta loggas i lösningen, behöver man testa i användning eller kan man göra enkäter?
4. Formulera när mätning borde göras och vilka värden man då kan förvänta sig: ”Efter 1 års användning skall 9 av 10 användare uppge att … ”

Det viktigaste är att ha en bild av 1 och 2. 3 och 4 kan man vänta med tills det läge där det är klart att man vill styra projektet mot effekt.

Det är viktigt att måla upp de olika omfattningar och ambitionsnivåer som man skulle kunna tolka ut ur intervjuerna. Nästa steg är nämligen att få till ett beslut om omfattning och ambitionsnivå. Ett sådant beslut kan kräva 1-2 workshops där ledare och beslutsfattare får en genomlysning av möjligheterna och får klart för sig vad olika avgränsningar betyder.

Örebro kommun berättar på sin egen blogg om hur de använt effektstyrning som metod. Här handlar det om utvecklingen av ett nytt intranät. De delar också frikostigt med sig av själva effektkartan:

• Effektkarta – Översikt
• Effektkarta – Alla
• Effektkarta – Administratören
• Effektkarta – Den undrande
• Effektkarta – Spanaren
• Effektkarta – Samarbetaren
• Effektkarta – Spridaren

För att vi skall kunna utveckla en tjänst som användarna både kan och vill använda måste vi förstå deras drivkrafter, och om det handlar om ett system som skall användas i arbetet, deras ansvar, och arbetsuppgifter.

För att få denna kunskap genomför vi en målgruppsanalys.

Målgruppsanalysen är grunden för att bygga rätt produkt. Även om beställarens krav är mycket tydliga måste den slutliga produkten även möta målgruppernas behov. En väl genomförd målgruppsanalys får till effekt att:

• Utvecklingsarbetet kan fokuseras på de egenskaper och funktioner som är viktigast för produktens framgång.
• Tiden som annars går åt för att diskutera ”vad användarna egentligen vill ha” kan minskas markant.
• Projektet kan undvika att bygga funktioner som i slutändan inte kommer att användas.
• Mer frekvent använda funktioner blir enklare att finna och mer behagliga att använda.
• Livscykelkostnaderna för produkten minskar väsentligt.¹

Syftet med att genomföra en målgruppsanalys är att samla verkliga behov från olika typer av användare - målgrupper - som skall använda tjänsten. Även då krav som är ”självklara” och sammanhangsberoende. En eller flera kartläggare utför och ansvarar för målgruppsanalysen.

Begreppet målgrupp används för att beteckna en grupp användare som har likartade förväntningar på, och syften med att använda, produkten.

Analysarbetet syftar till att definiera och beskriva dessa grupperingar så att kunskapen om målgrupperna kan användas för att styra designbeslut och utformningen av tester.

Det finns många tekniker som kan användas för att genomföra en målgruppsanalys. Enkäter, intervjuer, fokusgrupper och observationsstudier är vanliga.²

Våra erfarenheter är att en kombination av intervju och observation är det mest kostnadseffektiva när det gäller att ta reda på vad användarna faktiskt behöver, och hur de verkligen gör när de använder en viss tjänst.

Fokusgrupper kan vara bra för att få idéer, men för att ta reda på verkliga behov är de tämligen bristfälliga.³ Enkäter kan vara bra, men bara om du verkligen vet vilka frågor som är viktiga att ställa, något som man vanligtvis inte vet i början av ett projekt då man bara har sina egna förutfattade meningar att bygga på.

Den information som samlas in kan bestå av rena fakta, men lika viktigt är att samla in kunskap om ”mjuka” värden, exempelvis om målgruppernas värderingar och förväntningar. Detta ger ofta värdefull information om hur motiverade de är att använda tjänsten, vilket säger något om hur mycket arbete de är villiga att lägga ner för att lyckas.

I många projekt sker ingen målgruppsanalys att tala om. Istället nöjer man sig med att intervjua ett antal ”representativa användare”.

Problemen med detta förfarande är många. Inte minst att man ofta får krav som står i direkt konflikt med varandra, och eftersom man inte delat in användarna i målgrupper och prioriterat dem mot varandra blir det svårt att se vilka krav som är viktigare än andra o.s.v.

Nyckeln ligger i att kombinera intervjun med observationsstudier. Att bara ställa frågor räcker inte. För att vi skall förstå, och för att användaren skall kunna förmedla det som är viktigt, så måste intervjun ske i det sammanhang där arbetet utförs, helst samtidigt som det faktiskt görs.

Om man intervjuar en användare om hur ett visst arbete, eller en viss uppgift utförs, så kommer hon per definition att utelämna de detaljer som för henne är ”självklara”. Eftersom hon anser dem just självklara så behöver de varken nämnas eller förklaras. Problemet är bara att dessa detaljer ofta är avgörande för om tjänsten kommer att bli bra eller ej, och nästa tillfälle för användaren att upptäcka detta kanske inte kommer förrän hon använder den färdiga tjänsten, och då är det både sent och dyrt att genomföra förändringar.

Ett annat problem med intervjuer utan observation är att användaren beskriver hur arbetet borde utföras, inte hur hon faktiskt gör i praktiken. Vi människor utför dagligen mycket komplicerade uppgifter, utan att för den skull ha förmågan att korrekt beskriva hur vi gör.

När kunskaperna om målgrupperna är otillräckliga görs antaganden och gissningar i projektet. Med en målgruppsanalys säkerställs att utvecklingen inte baseras på tyckanden.

En målgruppsanalys ska självfallet genomföras så tidigt som möjligt i ett projekt. Bäst effekt får du om du gör den direkt efter att du skapat dig en första bild av beställarens krav. Då kan du i målgruppsanalysen göra observationer och ställa frågor som ger svar på frågor som uppstått i effektkartläggningen.

Om beställaren har en bild att produkten ska användas i en säljsituation bör du exempelvis ta reda på hur säljaren gör idag för att förevisa produkterna, avsluta affären och hur eventuell uppföljning går till.

Om man missat att genomföra en målgruppsanalys i början av projektet går det bra att komplettera med detta senare. Dock minskar såklart möjligheterna att genomföra förändringar på ett kostnadseffektivt sätt ju längre projektet går.⁴

Följande 6 steg behöver man som regel genomföra i en målgruppsanalys:

1. Definiera frågeområden
2. Rekrytera intervjupersoner
3. Genomför intervju och observation
4. Analysera och sammanställ materialet
5. Prioritera
6. Presentera

En målgrupp är alltså en grupp av användare som har likartade förväntningar på produkten, och som kommer att använda produkten på ett likartat sätt.

Med utgångspunkt i de antaganden som gjorts under effektkartläggningen bör vi nu fundera igenom vilka frågeområden som är relevanta under själva intervjun. Exakt vilka områden som är relevanta varierar från fall till fall, men det kan t.ex. handla om:

• Mål – Vad vill användarna uppnå med att använda produkten, vilket syfte har de med produkten? Vad är viktigt för dem? Finns det distinkta grupper, vad har de gemensamt?
• Kunskap om arbetet – Skiljer sig målgruppernas kunskap om arbetet eller de uppgifter som skall genomföras åt? Är skillnaderna så stora att det spelar roll?
• Annan kunskap - Har användarna erfarenheter från liknande produkter eller tjänster? Vilka, och vad innebär det i så fall?
• Erfarenhet – Hur stora är skillnaderna i erfarenhet mellan de som använder eller arbetar med produkten? Är det relevant att dela in användarna i erfarna och mindre erfarna?
• Vilka uppgifter som produkten skall stödja? Finns det skillnader? Utförs t.ex. vissa uppgifter främst av vissa grupper eller roller?
• Användningsfrekvens – Finns det skillnader i hur ofta produkten, eller olika delar av produkten, används?
• Ålder – Vilka åldersgrupper kommer att använda produkten? Var återfinns de flesta användarna?
• Kön – Är något kön överrepresenterat? Är det så mycket att det spelar någon roll?
• Värderingar – Finns det några mönster när det gäller värderingar? På vilket sätt skulle det kunna vara avgörande?
• Konkurrens - Vilka liknande produkter använder användarna idag? Vad skulle få dem att föredra denna produkt framför andra?
• Kultur – Finns det kulturella skillnader av betydelse? Kommer produkten att användas av personer i olika länder, och/eller som har olika syn på, och respekt för, t.ex. hierarkier.
• Fysisk miljö – i vilken fysisk miljö ska produkten användas? Är det bullrigt, finns solljus, kör användaren bil samtidigt etc.? Detta kan t.ex. vara avgörande för om man t.ex. överhuvudtaget kan använda ljud som en del i designen.

Som du säkert märker så är inte alla av ovanstående frågeområden lämpliga för en intervju. När det gäller t.ex. ålder och kön så finns det andra, mer effektiva sätt att fånga in dessa uppgifter.

För beställaren är det ofta bra om produkten passar så många som möjligt! Det finns gott om exempel där beställaren hävdat att produkten är till för ”alla”.

Sanningen är att en produkt skapad för just alla sällan passar någon.

Det är dessutom mer kostsamt att bygga en produkt med hög användbarhet om det finns flera divergerande målgrupper än att specialisera sig på ett litet antal målgrupper med likartade behov.

För att göra rätt prioriteringar i projekten och fatta goda designbeslut måste målgrupperna prioriteras. Prioriterade målgruppers behov ska tillgodoses och dessa behov kommer att ges förhållandevis mycket utvecklingstid.

Behov från målgrupper med låg prioritet kan komma att väljas bort om projektet hamnar i tidsnöd eller behöver spara på kostnader.

En vanlig missuppfattning är att målgrupper är detsamma som befattning eller annan organisatorisk indelning⁵, eller att man kan använda den indelning i marknadssegment ⁶ som man redan har.

Beställaren bör ansvara för att finna lämpliga personer att intervjua om de finns i den egna organisationen, eller om de är kunder. När det handlar om publika lösningar kan en rekryteringsfirma hjälpa till.

Det går självfallet att statistiskt beräkna hur många personer som bör intervjuas och observeras, totalt och per målgrupp. I praktiken ger det sällan särskilt mycket att intervjua fler än 5 personer per målgrupp, och redan efter 3 intervjuer brukar de viktigaste mönstren börja bli tydliga. Antalet överraskningar minskar sedan snabbt i efterföljande intervjuer.

Om man inte har någon hypotes om hur användarna bör delas in i målgrupper kan man alltid börja med att intervjua 5-10 användare för att få en bättre känsla, och sedan komplettera med fler intervjuer allteftersom.

Varje intervju tar i regel 1-3h styck.

Den kombinerade intervjun/observationen genomförs på den plats och i det sammanhang där produkten ska användas. Det betyder att den utförs i de mest skilda sammanhang; i kontorsmiljö, i hemmet, på ett labb, i en buss, på ett torg, i en bandvagn, i en cockpit osv.

Uppgiften är att samla kunskap om alla de faktorer som är viktiga att ta hänsyn till för att kunna bygga en produkt med hög användbarhet. Som i många andra sammanhang så är det bra om man har möjlighet att bolla upplägget och sina observationer med någon annan, det är därför bra om fler än en person är inblandad i målgruppsanalysen.

När du genomför intervjuerna - kom ihåg att du gör intrång i en medmänniskas vardag. Var tydlig med dina avsikter och tänk på att vara så vänlig och behaglig som möjligt. Även om humor ofta är ett bra verktyg, så är det ofta direkt olämpligt att skoja om en medmänniskas arbetssituation. Du känner ju faktiskt inte till vilket förhållande hon har till sitt arbete och bör respektera hennes situation. Dessutom kan det ju vara så att ett av syftena med det system som du bidrar till att utveckla är minskade personalkostnader. Även om det är ovanligt kan du med andra ord uppfattas som ett direkt hot.

Varje intervju/observation utformas olika beroende på vilken typ av produkt det handlar om, men ett generellt mönster skulle kunna se ut såhär;

1. Introduktion. Presentera dig själv och förklara att du vill ställa frågor samtidigt som användaren ska utföra det arbete som produkten ska stödja. Om produkten används i en yrkesrelaterad situation kan du säga att användaren kan betrakta dig som ”nyanställd” och att du vill lära dig hur arbetet ska utföras. Beskriv att resultatet av intervjun kommer att användas för att utforma produkten och därför är mycket värdefullt.
2. Be användaren beskriva vilka uppgifter som hon har och som skulle kunna stödjas av produkten. Ställ frågor om vilken roll de har, vilken kunskap som krävs, hur man lär sig och vad effekten blir om man gör fel. Frågor om hur ofta man använder systemet eller genomför en specifik uppgift är viktiga, men kan vara svåra att svara på. Om det går kan det därför vara bra att ta reda på detta genom att gå igenom systemets loggfiler efter intervjuerna.
3. Be sedan användaren genomföra de vanligaste arbetsuppgifterna, eller helt enkelt observera användaren då hon utför sitt vanliga arbete. Ställ frågor om handgrepp och avväganden som görs. Lägg märke till fakta som användaren hämtar från minnet, kollegor, listor, pärmar, andra system etc. Titta efter hur denna kringinformation är organiserad. Lägg märke till om användaren för egna noteringar och fråga varför. Fråga om begrepp du inte förstår, kort och gott ställ frågor så att du kan återge vilka faktorer som är viktigast för att just denna användare skulle trivas med den nya produkten. Det största hotet mot ett bra resultat är din egen prestige. Det kan kännas pinsamt att erkänna att man inte förstår, och det är lockande att försöka verka mer insatt än man är. Resultatet blir då en i högsta grad bristfällig analys, som inte alls kommer att ge projektet valuta för den investerade tiden.
4. Ställ frågor om andra, mer sällan förekommande uppgifter och hur de utförs.
5. Ställ frågor om användarens upplevelse av arbetet. Vad får användaren att känna sig nöjd/stolt? Vad motiverar henne att utföra arbetet? Vad skulle vara särskilt viktigt för henne i den nya produkten?
6. Avslutning. Tacka för att du fått störa användaren. Summera resultatet och beskriv återigen vad det ska användas till. Kontrollera om det passar sig att återkomma om du har detaljfrågor.

Sammanställ sedan dina anteckningar från intervjun samma dag eller senast dagen efter. Man glömmer fort…

Nu är det dags att väga samman den information som framkommit i intervjuer/observationer till mer generella kunskaper om målgrupperna. Detta arbete underlättas väsentligt om det har varit två kartläggare som utfört intervjuerna. Om du ensam gjort intervju/observation kan det underlätta att du – innan du börjar skriva – beskriver vilka erfarenheter du gjort för en annan person som ska ingå i utvecklingsprojektet.

Fakta som kommit fram bör beskrivas i en rapport. Rapporten bör innehålla följande information per målgrupp: * Målgruppens namn och kort beskrivning av viktiga egenskaper. Antal användare som ingår i denna målgrupp (procentuellt, uppskattningsvis)? * Information om användningsfrekvens. Använder de produkten eller något liknande idag, hur ofta?

• Drivkrafter – Vilka förväntningar har målgruppen på produkten och vad hindrar/skrämmer dem? Vilka syften har de med att använda produkten?
• Användningssituationer – I vilka tillfällen använder målgruppen produkten? Hur påverkar den fysiska situationen användningen? Används andra hjälpmedel eller produkter samtidigt? Hur ser användarens mentala och sociala situation ut vid användningstillfället? Är användningssituationen stressig, svår, prestigeladdad, tråkig, spännande o.s.v. Är användaren ensam eller sker användningen i grupp? Vilka krav ställer användningssituationen på produktens utformning?
• Uppgifter – Vilka uppgifter utför målgruppen och hur ofta? Hur genomförs uppgiften, finns det någon naturlig ordning. Vilka hjälpmedel (om några) används?
• Övriga kännetecken – Kunskap, erfarenhet, värderingar, förväntningar etc. som är av betydelse för produktens utformning.

Hur ”putsad” rapporten bör vara beror på om den bara skall vara ett stöd för dig själv när du gör analysen, eller om den skall användas som projektdokumentation. Oavsett om det finns en presentabel rapport eller ej så bör du ta fram kortfattade beskrivningar av de viktigaste målgrupperna, s.k. personor⁷.

På 1 A4-sida beskriver man en fiktiv person som man ger namn, foto, ålder, drivkrafter, arbetsuppgifter, intressen, erfarenheter, värderingar, preferenser etc. som sedan får representera just denna målgrupp.

Även om den inte skall vara längre än en A4, ska beskrivningen ändå vara så fyllig att den kan vara ett konkret stöd när man skall ta fram designkonceptet. Den skall både kunna fungera som en guide när man ställer sig frågor som t.ex.:

• Skulle funktionen hjälpa denna målgrupp att genomföra sitt jobb? Skulle hon vilja använda den?
• Vad skulle hon behöva för stöd för att lära sig använda funktionen?
• Hur bör vi utforma den för att den skall funka så bra som möjligt för just den här målgruppen?

Ett av de viktigaste momenten är att prioritera målgrupperna baserat på den information som framkommit under effektkartläggningen. Vilka målgrupper är viktigast för att vi skall uppnå syftet med produkten?

En viktig faktor är ofta volym, hur stor del av användningen som en specifik målgrupp representerar. Men det kan lika gärna handla om en målgrupp som är trendsättare, och därigenom kan hjälpa till att åstadkomma en viss beteendeförändring, eller vad det nu är man är ute efter.

Även om analysen nu finns dokumenterad så är det av avgörande betydelse att den också presenteras muntligt för beställare och projektmedlemmar.

Anledningen är dels att förvånansvärt många har svårt att finna tid att läsa igenom denna typ av analyser, trots att de är oerhört viktiga för projektet, och dels att det alltid finns frågor som man missat att ta med. Genom att gå igenom materialet med beställare och projektmedlemmar och fånga upp dessa frågor kan materialet sedan kompletteras och utgöra en solid grund för det fortsatta arbetet.

Innan själva mötet är det naturligtvis viktigt att projektledaren fått en egen genomgång, så att hon inte får några större överraskningar under mötet.

En presentation av resultatet kan följa denna mall:

1. Beskriv tillvägagångssättet kortfattat.
2. Beskriv målgrupperna, beskriv gärna användningssituationen, något som förvånade dig, något som sades – helt enkelt sådant som ger liv till berättelsen och gör det lättare att förstå och komma ihåg. Avslöja aldrig en enskild persons identitet.
3. Förklara varför du föreslår den prioritering av målgrupper och användningsmål som du gör.
4. Diskutera resultatet, och om projektet är redo, fatta beslut om prioriteringen. Därmed vet man i projektet vilka målgrupper och vilka behov som måste tillgodoses framför andra, vilket ökar styrbarheten i projektet. Om beslut fattas på mötet – var noga med att se till att dessa noteras av projektledaren.

Konceptdesignen syftar till att beskriva och visualisera hur den avsedda nyttan skall uppstå. Både nyttan för verksamheten och nyttan för användarna. Det handlar om att troliggöra att den tänkta lösningen faktiskt kommer att leda till det önskade resultatet.

Det räcker dock inte med att man har bra argument och tydliga bilder som visar varför systemet kommer att leda till de avsedda effekterna. Det måste också se snyggt ut och kännas bra i magen. Annars blir det svårt att övertyga en beställare att lägga hundratusentals, eller kanske miljontals kronor på att utveckla systemet. Ett bra koncept handlar därför nästan lika mycket om att skapa något visuellt tilltalande som något som har tydlig koppling till verksamhet och användare.

Konceptdesign handlar inte om att beskriva exakt vilka mönster som systemet skall följa, exakt hur det skall fungera, eller hur det skall se ut in i minsta detalj. Detta görs istället under arbetet med att beskriva systemets principdesign och detaljdesign i projektets byggfas. Det vore alldeles för tidigt att lägga tid på detta nu, vi vet ju faktiskt inte ens om systemet skall byggas eller ej, eftersom detta beslut fattas i vägskäl 1 med bland annat konceptdesignen som grund.

I designarbetet bör du alltid utgå från de verksamhetseffekter som systemet skall leda till. Om du t.ex. arbetar med en nyhetssajt som lever på annonsvisningar, och målet är att öka antalet annonsvisningar så är detta ditt fokus.

Användbarhetsområdet brukar annars förses med etiketter som ”användarcentrerat”. Nyttan av en tjänst eller ett system uppstår när det används, så på sätt och vis är det korrekt, men för att nå de uppsatta målen så räcker inte det, vi måste arbeta ”effektfokuserat”.

Ofta innebär detta en intressant och utmanande balansgång eftersom de verksamheter som är eftersträvansvärda ibland gör tjänsten i fråga mindre attraktiv för slutanvändaren.

Ta exemplet med nyhetssajten ovan. Annonser och reklam ses sällan som något positivt av slutanvändaren, och fick hon välja skulle sajten sannolikt vara helt utan reklam, men utan reklamintäkterna skulle det inte vara möjligt för nyhetssajten att existera överhuvudtaget.

Om man skall lyckas med målet att öka antalet annonsvisningar måste detta göras på ett smart sätt, så att besökarna inte väljer att överge sajten till förmån för någon konkurrent. Det gäller alltså att öka antalet annonsvisningar utan att försämra upplevelsen för besökarna, och om möjligt utforma sajten så att annonserna blir ett mervärde.

Vi har tidigare beskrivit hur du kan börja ta reda på vilken nytta som systemet eller tjänsten bör leda till både för verksamheten och för användarna. Med detta som underlag kan du nu börja skissa på hur systemet eller tjänsten bör se ut och fungera.

Det finns hundratals olika sätt att utforma ett visst system. Problemet är att det stora flertalet är dåliga, eller åtminstone inte så bra som de skulle kunna vara.

För att inte fastna för tidigt för en specifik lösning är det viktigt att aktivt sträva efter att ta fram så olika designförslag som möjligt i början.

Detta är lättare sagt än gjort. Ett vanligt fel är att man lämnar pappersstadiet alldeles för tidigt, och börjar med detaljdesign på det förslag man kom på först.

Om projektbudget och andra omständigheter tillåter så försök att rigga arbetet så att ni är flera personer som jobbar tillsammans med att ta fram konceptet. Det går bra att vara ensam, men att vara 2-4 personer som är involverade är ofta det allra bästa.

Det som krävs för att ta fram ett riktigt bra koncept är kunskap inom interaktionsdesign, affärsutveckling, grafisk form, den specifika verksamheten och den tekniska plattform som ev. kommer att användas.

Börja med att samla inspiration. Fundera på vad det är för typ av system som skall byggas. Vilka problem är det som skall lösas? Utgå från de åtgärder i effektkartan som ger störst effekt. Vilka delar eller funktioner kommer att vara viktigast i det nya systemet?

Vad finns det för liknande system? Finns det några konkurrenter som man kan lära sig något av? Finns det någon helt annan typ av system som man kan inspireras av?

Vilka situationer ska produkten användas i? Ställer de helt olika krav? Lösningar som man kan inspireras av kanske passar för helt andra situationer?

Om det handlar om relativt ny teknik, som t.ex. multitouch på stora skärmar eller gästbaserade användargränssnitt - vad finns det för forskning som gjorts inom området?

Sätt upp effektkartan, personabeskrivningarna och allt annat som du hittat och som du tror skulle kunna bidra till en bra produkt på väggen. En bildskärm är helt enkelt ett för litet ”titthål” för att man skall kunna ta in all information samtidigt.

Börja sedan skissa. Håll dig till papper och penna, gärna i storformat på vägg.⁸ Spendera ett par timmar med att bara göra snabba, grova skisser som du breder ut på ett bord, eller sätter upp på väggen bredvid det andra materialet som du samlat på dig.

En viktig sak med konceptstadiet är att ägna lite extra tid eftersom det nu är billigt att utforska flera alternativa lösningar. Det är alltså viktigt att flera olika koncept skapas så att man inte fastnar i en lösning från början. Tillåt vilda idéer och utforska dem även om du nästan med en gång känner att de inte håller fullt ut. Det kan finnas detaljer i dem som du senare vill återvända till, och ta med i en annan designlösning.

En vanlig fallgrop tidigt i designarbetet är att man förälskar sig i någon detalj och ägnar för mycket tid åt den, även om den inte riktigt passar in i resten av designen. Om det vill sig riktigt illa blir du så förälskad i just denna detalj att du försöker klämma in den i alla fall, och att systemet eller webbplatsen då som helhet blir sämre än det hade kunnat vara. När du känner att något inte riktigt passar in, dokumentera idén på ett papper eller i en anteckningsbok direkt, så att du känner dig trygg i att du inte glömmer av idén, men återgå sedan till det ”stora” konceptet.

Något som är otroligt viktigt i designarbetet är att snabbt förstå vilka begrepp som är ”nyckelbegreppen” i just det här systemet. Vilka objekt är centrala för användaren, och vilka status kan dessa objekt ha?

Det finns alltför många exempel på system⁹ där de som byggt systemen inte förstått värdet av att direkt ge användaren en överblick över dessa objekt och deras status, och knyta viktiga funktioner till dessa.

Istället möts användaren av ett tomt fönster, med knappar eller en menyrad med funktioner. Först efter det att man valt en funktion kan man se objekten och deras status.

Denna typ av användargränssnitt är ofta en följd av funktionscentrerade utvecklingsmetoder, där man i teamet fokuserat på att göra klart en funktion i taget och sedan gjort dessa funktioner tillgängliga på den ”startsida” som visas när man startar systemet. Tyvärr blir resultatet ett system som både ger dålig överblick, och blir onödigt svårjobbat eftersom användaren måste hoppa mellan olika ”moduler” eller funktionsområden trots att hon jobbar med samma samling objekt.

Om det är möjligt så se till att ha tillgång till den person som genomfört effektkartläggningen och målgruppsanalysen¹⁰ under tiden du skissar. På så sätt kan du snabbt ställa de kompletterande frågor du eventuellt behöver ha svar på för att komma vidare.

När ni har skissat så länge att du känner att du inte kommer längre väljer du ut de 2-3 olika koncept som du tror mest på, och detaljerar dem lite mer. Låna goda idéer av de andra skisserna, och det inspirationsmaterial som du samlat på dig.

Utan att lägga alltför mycket tid är det nu dags att dokumentera designkoncepten på ett sätt som gör att du/ni kan presentera dem för alla dina projektkollegor. Syftet är att hitta förtjänster och brister med de olika varianterna - helt enkelt att göra dem bättre.

Boka ett arbetsmöte där ni tillsammans går igenom designförslagen. Inför mötet skall alla ha läst igenom det underlag som finns från effektkartläggning och målgruppsanalys. Ofta är det dessutom bra att ha med sig en stor utskrift med effektkartan, och utskrifter med personabeskrivningarna som man sätter upp på väggen i mötesrummet.

Genom att utgå från de designkoncept som tagits fram kan gruppen nu snabbt och effektivt diskutera sig fram till hur förslagen skulle kunna förbättras ytterligare. Syftet är hela tiden att systemet skall leda till det önskade resultatet på ett så kostnadseffektivt sätt som möjligt.

Under mötet är det ofta bra att använda utskrifter av designkoncepten som man kan kladda direkt på för att förklara vad man menar. Efter mötet kan man sedan rita rent, och arbeta vidare med de eller det koncept som man tror mest på.

Om man behöver så kan man naturligtvis arbeta vidare med upprepade möten tills man känner sig nöjd med resultatet.

Ett av de viktigaste momenten i avstämningarna är att säkra att den föreslagna lösningen går att bygga till en acceptabel kostnad.

Det är därför viktigt att ha teknisk kompetens närvarande vid avstämningarna. De lösningsförslag som konceptet innehåller kan ur ett tekniskt perspektiv vara onödigt krångliga att utveckla. I diskussionen kan man ofta hitta alternativa sätt att uppnå samma effekt, utan att ge avkall på kvaliteten.

Som så många andra gånger så handlar det om kompromisser. Den perfekta lösningen, i den mån man lyckas specificera den, är alltid oändligt dyr. I arbetet med konceptdesignen måste man därför hela tiden väga de föreslagna lösningarna mot utvecklingskostnaden och välja de lösningar som ger bäst effekt till lägst kostnad.

Man vill ju inte gärna bränna halva utvecklingsbudgeten på någon detalj, som förvisso är snygg, men som inte har någon direkt bäring på den effekt som produkten skall leda till.

Resultatet bör dokumenteras i form av en presentation eller motsvarande, där kopplingen mellan effektkartan och konceptdesignen blir tydlig.

Ett effektivt sätt är att gå igenom de viktigaste delarna av effektkartan och för varje del peka ut hur de skall realiseras i systemet - antingen på skisser eller i en klickbar prototyp.

Poängen är att man då kan visa hur lösningen skall se ut och förklara varför just detta är en bra lösning om man vill få ut just de verksamhetseffekter som angivits i effektkartan. Man får en tydlig koppling ”From Business to Button”.

Detta gör också att design inte reduceras till tyckanden, som till sist avgörs av konsensus eller den bäst betaldes åsikt.¹¹

Om både projektgrupp och beställare känner sig övertygade om att ett system som ser ut och fungerar som det som presenteras kommer att leda till de avsedda effekterna har man kommit långt.

Om man verkligen vill känna sig säker så kan man dock enkelt skapa en prototyp och genomföra ett användbarhetstest för att validera att det faktiskt funkar så som det var tänkt.

Utveckla wikin: Kort beskrivning av resultatet av arbetet under idéfasen och hur man tar beslut om att gå vidare.

Här måste beslutsfattarna ha allt underlag som gör att de känner sig trygga med att den beskrivna lösningen har förutsättningar att skapa den tänkta nyttan.