Studentlitteraturs logga inUse logga
  • Dela på Facebook
  • Dela på Twitter
  • Dela på Linkedin
  • Dela på Delicious
  • Dela på Linkedin
 
 

Byggfasen

Syftet med byggfasen är att realisera systemet, att ta de specifikationer, prototyper och modeller som tagits fram och omvandla dem till ett verkligt system.

Alla utvecklingsmetoder har sina egna benämningar på de moment som ingår, men oavsett vad man kallar dem handlar det om att gå från beskrivningar som utgår från ett verksamhetsperspektiv, och transformera dem till beskrivningar som utgår från ett teknikperspektiv.

Den designspecifikation som tagits fram skall nu bli till en systemarkitektur, en objektmodell, osv. Därefter skall dessa omvandlas till programkod, databaser, serverkonfigurationer, etc.

Eftersom denna wiki inte beskriver en fullständig utvecklingsmodell kommer vi inte att beskriva allt annat som behöver göras i ett systemutvecklingsprojekt, utan koncentrera oss på det som handlar om design och användbarhet.

Specifikationen av systemets användargränssnitt är det viktigaste instrumentet för att beskriva lösningen. Inte minst för att den kan förstås av såväl beställare som utvecklingsteam och slutanvändare.

Syftet med designarbetet i byggfasen är att:

  • Sätta mönstren för den konceptdesign som tagits fram under idéfasen, och utforma ett användargränssnitt med beteende, presentation och innehåll som säkerställer att produkten kan uppfylla beställarens och målgruppernas syften.
  • Beskriva designen på ett så detaljerat sätt att den kan tjäna som ett underlag för utvecklingsprojektet, så att man i första skedet kan göra tidsuppskattningar och identifiera tekniskt utmanande lösningar, och i andra skedet för att man skall kunna utveckla systemet i enlighet med designspecifikationen.
  • Ta fram skisser och prototyper som successivt kan testas på användare för att säkerställa att det som utvecklas kommer att leda till avsedda verksamhetseffekter.
  • Leda utvecklingsarbetet av användargränssnittet så att produkten utvecklas i enlighet med det beskrivna. Under arbetets gång upptäcker man alltid brister i interaktionsdesignen eller i hur den implementerats, och då måste dessa åtgärdas.

Jobba iterativt

För alla system, webbplatser etc. utom de allra minsta är det bra att jobba i korta iterationer under byggfasen. På så sätt kan man hela tiden hålla koll på att produkten utvecklas i den riktning man vill. När väl mönstren är fastslagna i principdesignen gäller det bara att planera arbetet så att den som designar hela tiden ligger en iteration eller sprint före. Efter det att man fastslagit mönstren för lösningen, vilket görs i principdesignen, så handlar det bara om att planera arbetet så att den som designar hela tiden ligger en iteration eller sprint före.

Ett vanligt misstag är att man går direkt från konceptdesignen, eller direkt från t.ex. en textbaserad kravlista, och börjar utveckla. Man gör alltså nästan inget förberedande arbete mer än att sätta upp utvecklingsmiljöer etc. De produkter som kommer till under sådana förhållanden kommer aldrig att bli särskilt bra. En av de första sakerna som man lägger märke till när man kommer utifrån är att de inte följer en bestämd linje, de är inte konsekventa, när det gäller systemets beteende och utseende.

Var därför inte för snabb med att påbörja utvecklingen. Kolla först att de mönster systemet skall följa finns på plats.

Principdesign: Att sätta mönster

Även om man genomfört en ordentlig målgruppsanalys under idéfasen, så händer det att det saknas viktig information som man behöver ha innan man kan sätta mönstren för den nya designen. I så fall måste den kravinsamling som skett i form av målgruppsanalys under idéfasen kompletteras med ytterligare undersökningar.

Det kan t.ex. handla om att genomföra några fler intervjuer, gå igenom några fler loggfiler, eller prata med supportpersonal för att förstå vilka de vanligaste uppgifterna är, och vad som upplevs som problematiskt med dagens produkt.

Syftet är såklart att ha så mycket på fötterna att man kan beskriva hur man som användare t.ex. skall navigera i det nya systemet, hur skärmytan skall delas in för de viktigaste delarna av systemet, vilka komponenter som skall användas och deras beteende, hur felmeddelanden skall hanteras o.s.v.

Principdesignen syftar alltså till att beskriva de mönster som systemet skall följa. Här bestäms också vilka delar av systemet som ska lyftas fram i gränssnittet och vilka delar som placeras längre bak.

Arbetet tar avstamp i den konceptdesign som tagits fram under idéfasen. Fokus ligger nu på att bygga vidare på de grundidéer som man tror kommer att skapa avsedda effekter, men på ett sätt som säkerställer att systemet följer tydliga mönster.

Detta är mest ”ingenjörsmässiga” delen av designarbetet. Det finns två viktiga anledningar till varför det är så viktigt att etablera och beskriva de mönster som systemet skall följa:

  1. För att användaren lättare skall kunna lära sig, och snabbare skall kunna arbeta med systemet eller tjänsten, och
  2. För att det skall bli billigare och gå snabbare att bygga den.

Det är ofantligt mycket lättare för en användare att både lära sig, och att arbeta effektivt med en produkt om den ser ut och beter sig på ett likartat sätt oavsett var i produkten man befinner sig. Ändå finns det gott om applikationer där knappar och navigeringselement flyttar runt, och där inmatningsfält fungerar på ett sätt i en dialog och på ett annat sätt i en annan.

När det gäller projektet så finns det på samma sätt ofantligt mycket tid att tjäna om man tidigt definierar en eller ett fåtal mallar och en enhetlig uppsättning komponenter som sedan används i utformningen av webbplatsen.

Hur gör man?

Till skillnad från konceptdesignen måste man nu ta in hela problemområdet. HELA systemet måste ju kunna byggas utifrån de mönster som sätts upp i principdesignen. Eftersom man under arbetet med konceptdesignen utgått från och inkluderat funktionalitet som täcker in systemets viktigaste delar blir det sällan några stora förändringar av det grundläggande konceptet när man väl kommer fram till principdesignen. När man hittar något som inte riktigt passar in måste man göra bedömningen om det är tillräckligt viktigt för att man skall rubba på grundkonceptet, eller funktionen ifråga är såpass perifer att systemet som helhet blir bättre om den får en mer undanskymd placering.

En sak som är viktig att tänka på är att man, trots att vi pratar om principer och mönster, redan här måste göra några detaljerade skisser. Syftet med detta är att validera de principer som man tror på. Om man inte prövar dem på några av systemets olika delar och funktioner så vet man helt enkelt inte om de fungerar eller ej.

Tekniksäkring

I arbetet med principdesignen ingår också att kontinuerligt säkerställa att den tänkta lösningen är kostnadseffektiv att utveckla och underhålla. Detta görs genom täta avstämningar med systemarkitekt och utvecklare för att så tidigt som möjligt identifiera lösningsförslag som är onödigt dyra att utveckla. Tillsammans kan man ofta resonera sig fram till en designlösning som är enklare att implementera men ändå kommer att vara lika bra för användarna och ge samma nytta för verksamheten.

Som interaktionsdesigner bör du förvisso ha relativt god kunskap om vad som är tekniskt möjligt att genomföra på den valda plattformen, men kunskapen om programmeringstekniska och underhållsmässiga effekter av förslag har bara teknikerna.

De är dessutom ofta väl insatta i vilka möjligheter som finns att förbättra befintliga gränssnittskomponenter och hur kostsamt det är att eventuellt skapa nya. I en öppen och konstruktiv dialog skapas de bästa lösningarna. Dessutom är det betydligt lättare att skapa engagemang kring en designlösning om fler projektdeltagare varit aktiva i arbetet med att ta fram den.

Dokumentera i en specifikation

I designspecifikationen skall följande framgå:

  • Hur skärmytan skall disponeras, d.v.s. vilka informationsytor som finns och vilken typ av information och funktioner som de skall innehålla. Om produkten är en webbplats beskriver specifikationen också vilken typ av gridsystem som man tillämpar i designen 1, och hur.
  • Övergripande navigering, motsvarande en webbplatskarta för webbplatser
  • Hur olika informationsytor påverkas när användaren interagerar med dem. Det kan t.ex. vara så att ett klick på en länk i en informationsyta gör så att innehållet i en annan informationsyta byts ut.
  • Hur användaren kan navigera mellan systemets olika delar.
  • De viktigaste användningsscenariona, beskrivna som en dialog mellan användarens handling och produktens respons.
  • Exakt vilka komponenter som systemet innehåller och hur de fungerar.

Anledningen till att det är viktigt att beskriva komponenterna är att det är oändligt tidskrävande att beskriva alla tänkbara scenarios.

Genom att beskriva samtliga komponenters beteende räcker det ofta att beskriva de viktigaste scenariorna. Sedan kan utvecklarna själva extrapolera, och programmera delar av systemet utan att det finns någon visuellt detaljerad specifikation.

Detaljdesign: Pixelperfekt spec

I specifikationen ovan kan man välja att stanna vid trådmodeller2 och hänvisa till en befintlig styleguide som beskriver färg och form. Man kan också välja att detaljera designen så att varje enskild pixel har rätt färg och sitter på rätt plats.

Vilket detaljnivå man väljer att lägga sig på beror mycket på:

  • vilken typ av produkt det handlar om,
  • vilken kompetens som finns att tillgå i projektet,
  • hur effektiva verktyg man jobbar med, och
  • var utvecklarna sitter.

Om det handlar om interna system, som kommer att användas av ett fåtal personer så är kraven på bra grafisk design ofta relativt låga. Då räcker det i regel med att man uttrycker designen i form av trådmodeller som sedan implementeras utifrån rådande grafiska mallar.

Om man har tillgång till en interaktionsdesigner som också är en kompetent grafiker så är det i regel inget problem att göra pixelperfekta designskisser. Särskilt inte om personen i fråga använder ett verktyg som hanterar t.ex. lager på ett bra sätt, så att hon inte behöver ändra på 10 olika ställen om man ändrar en detalj som förekommer på flera olika sidor/fönster/dialoger.

En annan faktor som påverkar är hur nära man jobbar tillsammans med utvecklarna. Om man sitter i samma rum, har dagliga möten, och teamet består av utvecklare med god känsla för detaljer så behövs ganska liten insats. Om utvecklarna däremot sitter i Indien eller någon annanstans där både skillnader i avstånd och kultur är större behövs en större insats.

Hantera innehåll

Oavsett till vilken grad man väljer att detaljera designspecifikationen så måste man hålla koll på innehåll, så som texter, bilder, filmer, ljud, etc. Självklart beror ju innehållet på vad för typ av projekt man utvecklar, om det är en hemsida; Vad för hemsida är det då? Är det vetenskaplig eller blogg? Till vilka grupper riktar man in sig på? Allt detta måste man alltid ha i baktanke oavsett vilket projekt man än jobbar med. Självklart så är också innehållet beroende av vilka krav intressenterna har på projektet. Om man inte äger projektet själv är det alltid att rekommendera att jobba iterativt med intressenterna. I och med att det är de som äger projektet, de som har något att förlora på om projektet går under, så är det de som sätter kraven.

Att hålla allting så enkelt och rent som möjligt är ett krav i dagens samhälle, att göra något så användbart som möjligt innebär också att så många olika slags människor som möjligt ska kunna använda det du har utvecklat. Ett av de mest välkända principerna inom design är ”KISS” principen, vilket står för ”Keep It Simple Stupid”. För oavsett vilka som ska jobba vidare med din produkt senare, så ska man nästan alltid skriva med baktanke att den minst kunnande personen man kan tänka sig jobbar med den. Det är även krav på att allting ska se så snyggt ut så möjligt. Tänk på vilka hemsidor du själv tycker om och inte tycker om, se vilka för och nackdelar olika hemsidor har. Och tänk på vad du kan med stolthet sätta ditt namn på.

När man organiserar innehåll på någonting är som att organisera ett klädskåp eller verkstad. För att de ska se så snyggt ut som möjligt kan man inte sätta in vad som helst i den. Allting ska ha sin egen plats i det lilla utrymmet. Man ska även tänka på vilka platser som är mest logisk att sätta ut en viss grej. En ”Home” knapp på en hemsida t ex borde alltid vara det första man ser och ska stå först på sidan. Eftersom att det är en oskriven standard i dagens samhälle blir folk förvirrade om den står längst ner på en hemsida.

Utveckla wikin med mer info om detta.

Stöd under utvecklingen

Under utvecklingen krävs ett löpande stöd från de som arbetat fram designen. Främst handlar det om att svara på frågor som inte besvaras i dokumentationen, och att granska körbara delar allteftersom de blir klara.

På så vis kan behov av korrigeringar återföras till utvecklarna under tiden de arbetar med just denna funktion och har allt aktuellt. Med ett sådant arbetssätt minskas kostnaderna för att genomföra förändringarna betydligt3. Detta fungerar bäst om utvecklingen är indelad i korta cykler, gärna på två eller tre veckor.

Det är vanligt att man som designer hittar avvikelser från interaktionsdesignen. Ibland beror det på att programmerare funnit bättre lösningar, eller att man stött på tekniska problem med den specificerade lösningen. I båda fallen är det viktigt att man fångar upp dessa avvikelser, och godkänna eller göra en ny design.

Om man vill flytta på en vägg i ett hus brukar man först kontrollera om den är bärande. När det gäller interaktiva produkters gränssnitt är interaktionsdesignern den som vet bäst vilka väggar som är bärande. Interaktionsdesignen bygger på avvägda och medvetna beslut och därför kan endast den som fattat dessa beslut avgöra om den del som påverkas är central för produktens förmåga att interagera med användaren, eller om den kan ändras utan allvarliga konsekvenser.

Ibland beror avvikelserna på att programmerare eller grafiska formgivare helt enkelt inte förstått designen. Om det i projektet ingår programmerare och grafiska formgivare som aldrig arbetat med en interaktionsdesign måste den presenteras så att alla kan förstå och använda den. Det viktigaste är att programmeraren förstår mönstret och att det finns beteenderegler som ska programmeras, och att formgivaren förstår vilka komponenter som är ”bärande väggar” och vilka delar som ska formges.

Dokumentera viktiga designbeslut

Under framtagandet av en interaktionsdesign fattas en stor mängd designbeslut.

Ett problem som ofta uppstår är att rent praktiskt hantera de viktigaste av dessa designbeslut. Interaktionsdesign är en iterativ process, vilket innebär att ett beslut som fattats tidigare mycket väl kan komma att rivas upp.

Problemet är då att komma ihåg motiven bakom det första designbeslutet. En enkel men kraftfull teknik är att du skriver ner frågeställningar och beslut i en enkel tabell. En produkt med bra interaktionsdesign stöttar de avsedda målgrupperna och uppfyller användarnas och beställarens förväntningar.

Den bästa interaktionsdesignen är den som inte märks, utan istället låter användaren skriva tidrapporter, lägga om fartygsrutter, eller hitta ett visst telefonnummer utan att hon behövt skifta fokus från uppgiften till produkten.

Ett bra sätt att komma en bra bit på vägen till god interaktionsdesign är att fatta motiverade designbeslut, i princip ska man kunna härleda varje objekt på skärmen till krav från beställare eller olika målgrupper. Även om detta i sig inte garanterar god interaktionsdesign så blir det härigenom möjligt att spåra vilka designbeslut som ligger bakom de brister som upptäcks i användningstesterna. Detta i sin tur gör det möjligt att åtgärda de verkliga problemen istället för att bara lindra symptomen.

Validera det som utvecklats

Utveckla wikin med information om detta.

 

Noter

1 Se t.ex. 960-grid för information om hur just denna grid kan användas.
3 Om kostnader för ändringar uppskattas till 1 enhet under analysfasen så kostar ändringar 1,5 till 6 enheter under utvecklingsfasen och 60 till 100 enheter under underhållsfasen. Bias, R. & Mayhew, D., Cost-Justifying Usability, Acade­mic Press inc., 1994.
 
 

Kommentera

Författare

Bild på författareb Johan BerndtssonBild på författareb Ingrid DominguesBild på medförfattaren Karin HanssonBild på medförfattaren HelenaBild på medförfattaren Angelica SvanerBild på medförfattaren peter erhardBild på medförfattaren Anne RostedBild på medförfattaren Maria SjödinBild på medförfattaren Monika AnderssonBild på medförfattaren Nina LBild på medförfattaren Jens FredholmBild på medförfattaren BjörnBild på medförfattaren EmelieBild på medförfattaren Peter KråikBild på medförfattaren Jorge BerdejaBild på medförfattaren Charlotte BjörkBild på medförfattaren suzana susecBild på medförfattaren Terrell SherriffBild på medförfattaren Gunilla HansellBild på medförfattaren Emilia OlssonBild på medförfattaren gustavjonssonBild på medförfattaren HenrikBild på medförfattaren fredric landqvistBild på medförfattaren Maria KareliussonBild på medförfattaren Lotta UlfströmBild på medförfattaren EmmaBild på medförfattaren Rolf greenBild på medförfattaren Gabriel SvennerbergBild på medförfattaren Peter JantzenBild på medförfattaren Aurora KarlssonBild på medförfattaren Johannes Karlsson

Senaste ändringar

Facebook

Twitter (@anvandbarhet)

 
Creative Commons-licens

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.