Strict Standards: Declaration of action_plugin_indexmenu::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/indexmenu/action.php on line 13 Strict Standards: Declaration of action_plugin_badbehaviour::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/badbehaviour/action.php on line 72 Strict Standards: Declaration of action_plugin_clearhistory::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/clearhistory/action.php on line 81 Strict Standards: Declaration of action_plugin_metaheaders::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/metaheaders/action.php on line 140 Strict Standards: Declaration of action_plugin_blockquote::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/blockquote/action.php on line 61 Strict Standards: Declaration of action_plugin_editsections_es::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/editsections/action/es.php on line 74 Strict Standards: Declaration of action_plugin_swiftmail::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/swiftmail/action.php on line 126
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
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;
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:
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:
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.2
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.3 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.4
Följande 6 steg behöver man som regel genomföra i en målgruppsanalys:
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:
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 indelning5, eller att man kan använda den indelning i marknadssegment 6 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;
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?
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. personor7.
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.:
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:
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.8 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å system9 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ålgruppsanalysen10 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.11
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.
Användbarhet i praktiken - wiki by Ingrid Dominques/Johan Berndtsson is licensed under a Creative Commons Erkännande-IckeKommersiell 3.0 Unported License. Based on a work at anvandbarhet.se.
Kommentera