Studentlitteraturs logga inUse logga
 
 

Skillnader

Här visas skillnader mellan den valda versionen och den nuvarande versionen av sidan.

bok:byggfasen [2010-09-22 14:25]
berndtsson
bok:byggfasen [2012-04-11 11:50] (aktuell)
nihongo
Rad 5: Rad 5:
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. 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 systemariktektur, en objektmodell, osv. Därefter skall dessa omvandlas till programkod, databaser, serverkonfigurationer, etc.+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. 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. 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.
- 
-{{ :bok:wikiinterface2b.png|}} 
Syftet med designarbetet i byggfasen är att: 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.   * 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 kan 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.+  * 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.   * 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.   * 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 ===== ===== 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. 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.
 +{{ :bok:kalender.png|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. 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.
Rad 28: Rad 25:
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. 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 ===== ===== 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 ytterigare undersökningar. +Ä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. 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.
Rad 52: Rad 50:
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. 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.
 +{{ :bok:design3.png|}}
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. 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. 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 ==== ==== 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. 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.
 +{{ :bok:design4.png|}}
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. 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.
Rad 74: Rad 71:
  * 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 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.   * Hur användaren kan navigera mellan systemets olika delar.
-  * De viktigaste användningsscenariorna, beskrivna som en dialog mellan användarens handling och produktens respons.+  * 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.   * Exakt vilka komponenter som systemet innehåller och hur de fungerar.
Rad 80: Rad 77:
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. 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 ===== ===== Detaljdesign: Pixelperfekt spec =====
 +{{ :bok:design5.png|}}
I specifikationen ovan kan man välja att stanna vid trådmodeller((S.k. wireframes, se [[http://en.wikipedia.org/wiki/Website_wireframe|wikipedias definition för mer information]].)) 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. I specifikationen ovan kan man välja att stanna vid trådmodeller((S.k. wireframes, se [[http://en.wikipedia.org/wiki/Website_wireframe|wikipedias definition för mer information]].)) 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.
Rad 91: Rad 87:
  * var utvecklarna sitter.   * 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 med utifrån rådande grafiska mallar.+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. 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.
Rad 99: Rad 95:
===== Hantera innehåll ===== ===== 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.+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 ===== ===== Stöd under utvecklingen =====
Rad 108: Rad 109:
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 betydligt((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.)). Detta fungerar bäst om utvecklingen är indelad i korta cykler, gärna på två eller tre veckor. 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 betydligt((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.)). 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 specifiserade 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. +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. 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.
 
 

Författare

Bild på författareb Johan BerndtssonBild på författareb Ingrid Domingues

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.