Jakten på den totala kravbilden Användarkravens betydelse och problematik inom interaktionsdesign

Transkript

1 Jakten på den totala kravbilden Användarkravens betydelse och problematik inom interaktionsdesign Hemtentamen Interaktionsdesign analysmetoder, 5p VT 2004 MDI/Interaktionsdesign, påbyggnadsprogram 60p IT-universitetet Göteborg Kursansvarig: Marianne Karlsson Camilla Orrenäs

2 1. Inledning Användarkrav kan vara lättformulerade och enkla att identifiera medan andra kan vara svårtillgängliga. Hur får man till exempel reda på vad användare vill om de inte själva vet det och hur vet man som designer att man verkligen analyserat rätt användare? I strävan efter att få en så komplett kravbild som möjligt att basera sin nya produkt eller system på måste analysmaterialet i sin tur vara baserat på korrekta grunder, något som bland annat förutsätter att man som designer fångat upp alla nödvändiga krav. I denna uppsats vill jag diskutera olika implikationer med kravidentifiering inom ramen för användarcentrerad interaktionsdesign. Jag ställer mig frågor som vilka typer av krav det finns, i vilken grad är krav tillgängliga och vem är egentligen användaren som ställer dessa krav? Eftersom området är så pass omfattande avgränsas uppsatsen till att stanna kvar kring problematiken på en initial nivå, vilket gör att uppsatsen inte går närmare in på metoder för datainsamling. Uppsatsen ingår som delmoment i kursen Interaktionsdesign Analys 5p på påbyggnadsprogrammet MDI/Interaktionsdesign 60p. 2. Bakgrund En artikel publicerad av Taylor [1] visar att en av nyckelfaktorerna till att IT-projekt lyckas är att kravspecifikationen innehåller tydliga och detaljerade krav. Undersökningen som artikeln stödjer sig på visar att projektfasen är den mest kritiska och att identifieringen av krav tillsammans med otydliga målsättningar orsakade störst felaktigheter. Att ha en klar och tydlig bild av målsättningen anses vara något av det viktigaste inom interaktionsdesign och innebär att veta produktens eller systemets primära syfte. Det kan exempelvis innebära att veta om den nya produktens primära syfte är att vara produktivitetseffektiv eller om produkten skall designas för att ha ett utmanande system eller stödja ett effektivt lärande, etcetera? Att ha vetskap om detta ingår i processen av att förstå användarnas behov och brukar benämnas användbarhetsmål och användarupplevelsemål. Skillnaden mellan dessa består utav hur de olika målen kan mötas och på vilket sätt de mäts. Användbarhetsmål redogör för specifika användbarhetskriterier så som till exempel effektivitet medan användarupplevelsemål redogör för kvaliteten hos användarnas upplevelse. [2]. Vidare är det viktigt att förstå skillnaden mellan vad man behöver och vad man vill ha. Att behöva något kan innebära att en sak eller en funktion krävs för att man skall kunna utföra sin uppgift eller nå sitt mål medan att vilja ha något är betydligt mer subjektivt och kulturellt betingat. Karlsson definierar vilja ha som The forms taken by human needs as they are shaped by culture and individual personality [3], vilket mycket tydligt påvisar dess komplexitet. Det finns inget enkelt svar på vad krav är, det är ett oerhört brett område som rymmer en enorm variation av olika kravställningar, allt från krav på budget till att en 8 årig tjej skall tycka en webbsida är kul. IEEE [4] definierar krav enligt nedan.

3 1) a condition or capability needed by a user to solve a problem or achieve an objective 2) a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard specification, or other formally imposes document. 3) a documented representation of a condition or capability as in (1) or (2). I uppsatsen kommer jag återkomma till olika sätt att kategorisera krav i syfte att belysa komplexiteten. 3. Användarens många ansikten. Jag skulle vilja våga påstå att det första steget i att identifiera användarens krav är att identifiera själva användaren. Att veta vem användaren är kan låta självklart men är inte alltid fallet. Ofta är det många olika typer av personer med olika roller som är inblandade i användningen av en produkt. Ofta blandas den verkliga användaren ihop med till exempel den som beställer produkten/systemet, eller den som sköter underhållet och reparationerna eller den som beställer produkten. Alla de här personerna är också användare men är inte den egentliga brukaren. Dessa övriga användaraktörerna benämns som kravställare [3]. Eftersom dessa kravställare har olika relation till produkten/systemet ställer de följaktligen olika krav därefter. Beställaren ställer exempelvis krav på pris, vilket användaren av systemet kanske inte alls bryr sig om, som i sin tur har åsikter om t.ex. avstånd mellan olika knappar vilket beställaren inte bryr sig om osv. Att inte ha ordentlig insikt i dessa olika roller kan ha förödande konsekvenser. Exempelvis om jag i en användaranalys får underlag om gränssnittet av serviceteknikern, som besitter expertkunskaper, istället för de pensionärer som enkelt skall kunna använda systemet till att hämta ut tågbiljetter, utan att ha någon som helst förkunskap. Hansen [3] definierar en användare som den som använder produkten i enlighet med dess huvudsyfte [min översättning]. En definition som i sin tur kräver både en tydlig vetskap om vad produktens huvudsyfte är, dels en definition på vad använder innebär. Karlssons [3] definierar använda som den fysiska och/eller den mentala aktivitet av att nyttja ett objekt/en artefakt för ett givet syfte [min översättning] och väljer i sin tur att definiera användaren som den människa som är engagerad i en användaraktivitet [min översättning]. Jag tolkar Karlssons definition av användare att till skillnad från Hansons inkludera alla typer av användaraktörer och inte bara den slutliga brukaren. Som designer eller produktutvecklare kan dessa olika användaraktörer även vara besvärliga ur ett annat perspektiv. Exempelvis i situationer när en produkt skall tas fram tillsammans med en beställare kan det vara beställaren som inte förstår eller vill förstå att hon/han inte är den verkliga brukaren. Detta kan resultera i att de krav som framkommit från den verkliga användaren inte anses vara nödvändiga ur beställarens

4 perspektiv, och som då istället försöker välja bort dessa krav av olika anledningar, ofta ekonomiska. Dessvärre blir det nästan alltid en kortsiktigt ekonomisk besparing eftersom produkten inte kommer att hålla måttet i längden. Istället resulterar de bortsedda användarkraven i en icke-effektiv användning för den verklige brukaren och innebär i slutändan kostnadsförluster för företaget. Åtgärden för detta kräver i slutändan en dyr omarbetning eller nyinvestering. Men dessa konsekvenser är som sagt något som det ofta blundas för och som ironiskt kan beskrivas med det gamla visdomsordet snålheten bedrar visheten. Eason [5] delar upp användare i primära, sekundära och tertiära. Primära användare är de som troligtvis blir de frekventa hands-on användarna av systemet. De sekundära användare är tillfälliga användare som vid enstaka tillfällen eller via mellanhänder använder systemet. Oh tertiära är de användare som är berörda av införandet av det nya systemet eller som påverkar dess inköp. Norman [6] tar upp andra exempel på problematik med beställare kontra användare och menar att designprocessen är fånge av företagsbyråkratin som i varje steg av processen lägger till sina egna bedömningar och dikterar de förändringar som de tror sig vara av avgörande karaktär. Ofta är det många led av beställare och inköpare som ligger mellan designern och den slutliga användaren, samtliga med prissättningen som primär angelägenhet. I exempelvis stora beställningar av köks och våtrumsförnödenheter är beställaren ofta en fastighetsägare som beställer av ett byggnadsbolag som i sin tur har en inköpsavdelning som lägger beställningen till tillverkaren. Beställare som efter inköp och installation inte längre hyser något intresse för produkten ifråga. Tillverkarnas primära angelägenhet är dessa beslutsfattare och deras eventuella mellankunder men inte den slutliga användaren. I dessa situationer kan jag se det som att användarkraven kanske aldrig givits tillfälle att formuleras eller stegvis tvingats bortrationaliseras i takt med att beställarnas strävan efter kostnadsbesparingar stramats åt. Som synes är det inte alltid uppenbart vem användaren är när en beställning läggs. Vilket gör att tidigare nämnda definitioner av användare kan vara nödvändiga för att klargöra begreppet för alla inblandande parter och kanske till och med som en påminnelse för en själv som designer när alla övriga kravställare gör sina röster hörda. 4. Olika typer av krav Ovan har det klargjorts att det ofta finns olika typer av användare av en produkt eller ett system och där inte samtliga användaraktörer är den riktiga brukaren. Vidare är den slutliga användaren/brukaren oftast inte beställaren men att beställaren (ibland flera och i olika led) i sin tur även är kravställare. Användarkrav blir således inget enkelt begrepp eftersom de rymmer alla olika användaraktörers och kravställares olika typer av behov och önskemål. Von Dorrien [7] gör en grunduppdelning av kraven i två huvudkategorier; funktionalitetskrav och användbarhetskrav. Funktionalitetskraven talar om vad en produkt ell system skall göra och har i analysstadiet formulerats i en uppgiftsanalys för att sedan i kravspecifikationen delas in i olika nivåer av betydelse, så som önskvärda, viktiga eller nödvändiga funktionalitetskrav. Användbarhetskrav är olika

5 mätbara kategorier av användande och formuleras i en användaranalys och delas i kravspecifikationen upp i fyra olika kategorier vilka beskriver, hur lätt systemet/ produkten är att lära, hur snabbt man kan bli expert eller komma till en viss grad av användningsnivå, hur det verkligen är för användarna att använda systemet och slutligen hur flexibelt systemet/produkten är, det vill säga om det tillåts att man kan göra på sitt eget sätt eller om uppgiften förändras kan systemet följa med. Kravformulering inom användarcentrerad interaktionsdesign kännetecknas av att även innefatta krav på användarens upplevelse av att använda produkten eller systemet i fråga [2]. I litteraturen återfinns olika sätt att sortera in denna kategori av krav. Preece et al [2] väljer som tidigare nämnt att benämna dem för användarupplevelsemål och placerar dem under huvudkategorin användbarhetskrav. En annan typ av uppdelning av krav är i huvudkategorierna funktionalitetskrav och icke-funktionella krav. I denna uppdelning placeras upplevelsekraven i den senare kategorin och benämns look and feel. [8]. Von Dorrien [7] väljer istället att sortera in upplevelsekraven under kategorin Attityd i hennes tidigare nämnda indelning av användarkrav och refererar till dem som användarupplevelsemål. En annan intressant uppdelning som i stor utsträckning illustrerar den mångfald av krav som måste uppfångas i ett interaktionsdesignprojekt presenteras av Preece et al [2]. De menar att indelningen av krav i kategorierna funktionella och ickefunktionella krav är den traditionella uppdelningen inom mjukvaruutveckling men att det generellt hos interaktiva produkter finns en betydligt större mängd relevanta icke-funktionella krav, så som fysisk storlek, vikt, färg osv. Därför krävs det att vi som interaktionsdesigners förstår den funktionalitet som erfordras samt de begränsningar under vilka produkten eller systemen skall fungera eller utvecklas. Detta kan ses som anledning till att det inte är tillräckligt att bara benämna alla dessa krav som inte är funktionella för icke-funktionella krav utan istället bryta ned dem ytterligare. Jag väljer att mycket kortfattat redogöra för vad respektive kategori innebär. De funktionella kraven fångar vad det är produkten skall göra. Datakrav fångar typen, storleken, noggrannheten etc. hos den mängd data som den interaktiva produkten hanterar. Miljökrav eller användarkontextkrav refererar till de omständigheter i vilken den interaktiva produkten förväntas fungera i, vilken delas upp i ytterligare fyra aspekter; den fysiska, den sociala, den organisatoriska samt den tekniska miljön. Användarkrav fångar det karaktäristiska hos den tänkta användargruppen och presenteras i olika användarprofiler, eftersom det finns olika användaraktörer. Användbarhetskrav fångar de användbarhetsmål som finns för en specifik produkt, dvs. att produkten motsvarar förväntan, att den är effektiv, säker, funktionell samt att det är lätt att lära sig hur den fungerar. I denna kategori ryms även de tidigare så omnämnda användarupplevelsemålen dvs. om produkten är tillfredställande, njutningsfull, rolig, underhållande, hjälpsam, motiverande, estetiskt tilltalande, kreativitetsuppmuntrande, belönande, samt känslomässigt förverkligande [2]. En sista uppdelning jag vill nämna är The Volere Requirements Template [8] som delar upp krav i fem huvudkategorier, förutom funktionella och icke-funktionella krav finns det även; projektdrivande, projektbegränsningar, samt projektämnen. Dessa fem huvudkategorier innehåller sedan i sin tur sammanlagt 27 olika underkategorier [bilaga 1].

6 5. Kravens tillgänglighet Som det ovan har konstaterats är det en enorm mångfald och bredd på de krav som måste uppfångas och förvaltas för att ta fram en lyckad användbar produkt eller system. När det gäller att identifiera användarbehov finns det främst två stora svårigheterna som gör att det inte fungerar att bara fråga användarna rakt ut vad de har för behov. För det första är det inte säkert att de själva vet vad de behöver eller vill ha, för det andra är det tänkbart att de inte vet vad som är möjligt att få, exempelvis vilka tekniska möjligheter eller lösningar som existerar. Istället är man tvungen att närma sig frågan genom att lära känna användarna och skapa sig en förståelse dem. Vi behöver förstå deras kapacitet och vad som karaktäriserar dem, förstå vad de försöker åstadkomma, hur de för närvarande åstadkommer det och om de skulle nå sina mål mer effektivt om fick ett annat stöd/hjälp. [2]. Ytterligare problematik stöter man på när det gäller nya innovationer, när det inte finns en färdig definierad målgrupp eller etablerade beteenderutiner kring produkten i fråga. Här finns inte existerande användare att studera och observera utan här tvingas vi tala om tänkta användare/målgrupper och tänkta användningssituationer. I dessa fall är det vanligt att man arbetar med fokusgrupper för att på så sätt lära känna den tänkta användaren och förstå deras behov. Genom att förstå liknande redan etablerat beteende får man en god indikation på det framtida beteendet med den nya produkten. Ännu en svårighet är när nya vardagsprodukter skall introduceras, produkter som är tänkta att användas dagligen av en stor mängd människor. Dessa produkter kräver ofta en kulturell förändring i den tänkta målgruppens beteende och en sådan förändring kräver lång tid [2], vilket gör det ännu svårare att i designprocessen försöka förstå de tänkta användarna, deras användningssituationer och behov. Som nämnts ovan kan inte alltid användarna uttrycka sina behov av olika anledningar. Ett annat sätt att möta denna problematik är att genom utbildning ge användarna ett språk dvs. ett redskap för att kunna uttrycka sina behov. Man använder sig här av narration som metod för att fånga upp icke-formulerbara krav. Metoden går ut på att ge användarna en kompetens till att kunna förmedla och uttrycka saker de inte är vana vid, exempelvis begrepp för olika känslor eller vilket uttryck en produkt förmedlar. [9] En annan aspekt av användarkravens implikation är att de alltid uppstår i en situation, de finns inte bara i sig själv utan sker alltid inom ramen för kontextens villkor. Och eftersom det alltid uppkommer nya aspekter av användandet blir en kravspecifikation alltid föränderlig. Trots att de mycket väldefinierade tydliga kraven från alla de korrekta brukarna och kravställarna förvaltats korrekt i den slutliga designen, blir konsekvenserna att användarna aldrig blir riktigt nöjda eftersom det alltid uppkommer nya krav. De faktorer som låg till grund för kravställningen förändras i och med att vi lär oss utföra dels uppgiften i sig, dels lär oss nya saker som ger oss en förändrad kunskapsgrund. Även situationen förändras i viss mån över tid vilket bidrar till förändrade ursprungsfaktorer som kraven baserades på. Karlsson [10]

7 benämner relationen mellan de tekniska möjligheter och de sätt vi vill tillfredställa våra behov på som behovsdialektik, och liknar den vid en behovsspiral för att påvisa att ingenting är stationärt utan att det hela tiden rör sig framåt. En kravspecifikation kan således egentligen aldrig vara absolut slutlig. Relationen mellan användare, uppgift, produkt samt kontext. Där alla faktorerna är avgörande för de formulerade kraven. Förändras någon av faktorerna är inte kravformuleringen längre tillförlitlig. [10] En användare som interagerar per automatik med en artefakt av något slag är inte medveten om sin handling, det är först när problem uppstår som handlingen blir medveten och användaren kan reflektera över den. Att ställa frågor kring det som sker per automatik är således lönlöst. En lösning är att avsiktligt skapa s.k. brake-downs där problem konstrueras och användaren via manipulation tvingas att reflektera kring användandet. På så sätt kan man få tillgång till användarens subjektiva åsikter om den annars omedvetna interaktionen. [10] Processen av att identifiera användarkrav är i stor utsträckning beroende av i vilken grad användarna själva har tillgång till sina handlingar. Denna tillgång kan beskrivas med isbergsmetaforen där det bara är den lilla delen av isberget som syns ovanför ytan medan den största delen är gömd under vattnet. Ovanför ytan återfinns prestandakrav, där användaren kan beskriva problem eller även lösningar som hon känner till eller sett någon annanstans. Dessa krav kan man komma åt via intervjuer med användaren. Under ytan återfinns den andra typen av krav som benämns baskrav och är de krav som är så själklara för användaren att även om hon ombeds förklara dem inte kan göra det. För att komma åt dessa kan man låta användaren jämföra olika sätt att utföra sin handling på eller plocka bort funktioner och skapa tidigare nämnda brake-downs. Identifieringen av dessa krav sker genom observationer. Den tredje och sista nivån av krav är överraskningskraven även s.k. wow -krav som också återfinns under ytan på isberget. Användaren är här totalt omedveten om dessa krav eftersom de inte på något sätt är självklara. De kan gälla kvaliteter som hon inte visste hon kunde få så som funktioner eller hjälpmedel som hon inte visste fanns. Eller det kan vara interaktionslösningar som användaren utför på ett omständligt vis, men eftersom hon ändå når sitt mål, om än på sitt eget sätt, så upplever hon det inte som ett problem. Det är först när hon blir visad en för situationen bättre eller mer effektiv lösning som hon upplever en wow-känsla.

8 6. Diskussion I strävan efter att identifiera en större andel av den totala kravbilden kan man alltså konstatera att det är vikigt att initialt kartlägga alla olika typer av användaraktörer av systemet eller produkten i fråga. Allt från den verkliga brukaren, det vill säga den som använder produkten i dess avsedda syfte till alla andra som kommer i kontakt med den. Vidare måste man se till att få med alla användarnas krav, inte bara de lättformulerade utan även de som inte kan formuleras, de som befinner sig långt under ytan i det metaforiska isberget. Slutligen måste beställaren tillåta att det är det är den verkliga användarens krav som skall ingå i kravspecifikationen och inte beställarnas rationaliserade och justerade kravbild. Ur ett interaktionsdesignperspektiv av det mer innovativa slaget är det avgörande att kunna formulera krav för helt nya produkter, där man inte kan utgå från hur folk idag använder produkten. I uppsatsen har jag tagit upp att genom att studera liknande redan etablerade beteenden kan man få indikation på det framtida beteenden. I ett parallellt pågående skolprojekt befinner vi oss just i denna situation. Vi håller som bäst på att arbeta fram ett koncept för en ny typ av kontaktsökande. Utan att gå närmare in på konceptet bygger det på att man skall kunna placera ut små knappliknande föremål på offentliga platser innehållandes meddelanden som sedan skall kunna läsas av matchande profil. Meddelandet läses av via en adapter till mobiltelefonen som man håller mot det knappliknande föremålet. Eftersom det inte redan existerar en sådan produkt får vi lära känna våra användare genom att bland annat studera beteendet i liknande aktiviteter där det mänskliga behovet av kontaktsökeri tillgodoses. Liknande aktiviteter har inneburit klassiska kontaktannonser i tidningar där vi studerat hur folk väljer att uttrycka sig, se vad de säger men även studerat hur den tänkta användargruppen idag använder sin mobiltelefon. Vidare har vi kartlagt de olika former som teknik idag erbjuder kontaktsökeri, så som exempelvis chattsidor eller singel-sajter på nätet där engagemanget inkluderade ett aktivt deltagande. Här stöter vi på den problematik som jag tidigare tog upp om nya innovativa produkter som kräver en kulturell förändring. För likt introduceringen av mobiltelefoner kräver vårt koncept en kulturell förändring hos folks beteende. Vårt koncept kräver inte bara ett nytt sätt att lämna och svara på kontaktannonser utan ett helt nytt sätt att lämna och läsa av meddelanden vilket innebär ett helt nytt sätt att bete sig på i offentliga miljöer. Att lämna ett meddelande innebär att sätta fast det knappliknande föremålet på en vägg i en publik miljö, efter att man skrivit in sitt meddelande. Att läsa av kräver i sin tur att någon annan upptäckt det knappliknande föremålet och förstått vad det är för att slutligen ta upp sin mobil, hålla den mot föremålet och läsa av meddelandet. Dessa urval av exempel på våra tillvägagångssätt för att skapa en förståelse för den tänkta målgruppen kommer dock aldrig ge oss en förståelse för hur produkten verkligen kommer att användas efter att den varit implementerad i samhället i ett antal år. Som jag tidigare nämnt är det viktigt att inte vara för restriktiv utan tillåta möjlighet för användarna att ta till sig produkten och kunna anpassa både tekniken och användningsområdet så att det passar användaren själv.

9 Mycket av den litteratur man stöter på i kravsammanhang är inriktad på främst systemdesign. Jag upplever det som att funktionella krav i dessa sammanhang får betydligt större fokus än vad s.k. användarupplevelsemål får. Ett logiskt resonemang kan vara att ju längre från konsumentnivå en produkt eller ett system är ju mindre fokus får användarupplevelsemålen. Kanske är det även så att den traditionella ingenjörsandan lever kvar med en tydlig fokus på just funktionalitet. I interaktionsdesign är det centralt att ha en användarfokus på utvecklingen av produkten och inte en teknisk fokus. Vidare ser jag det som att en ny vardaglig produkt lever i ett slags symbios med det samtida samhället och dess invånare. Användandet av produkten utvecklas i samspel med samhället där en stor mängd olika faktorer dynamiskt påverkar dess utveckling vilket gör att produkten kanske får en helt annan användningsform än ursprungligen tänkt. Om vi som exempel tar mobiltelefoners sms-tjänst. Kunde mobiltillverkarna någonsin kunnat förutsäga användarnas beteende vad gällande att skicka sms? Den tekniska möjligheten fanns ju inte tidigare. Kunde kravet på att få skicka små textmeddelanden verkligen existerat hos användarna innan den tekniska möjligheten existerade? Om historien stämmer så som jag fått den berättad så fanns det ingen önskan eller några identifierade användarkrav på en sådan funktion. Funktionen fanns helt enkelt inlagd för att den var teknisk möjlig. Behovet är ett resultat av introduceringen av mobiltelefoner med denna funktion, där användarna tog till sig funktionen och skapade sig sitt eget användningsområde. Produkten leder till ett förändrat beteendet hos användarna och föder på så sätt varandra. Men jag tror detta bara kan ske om produkten tillåter en viss flexibilitet, det vill säga inte har för restriktiva möjligheter både vad gäller själva interaktion men även vad gäller användningsområdet i sig. Å andra sidan kanske historien är en annan, kanske är det så att det fanns en bakomliggande omfattande undersökning som identifierat ett potentiellt användningsområde för att just skicka små textmeddelanden till varandra. Kanske hade de precis som litteraturen rekommenderar just studerat människors liknande redan etablerade interaktioner och fått lära sig om de potentiella användarnas framtida interaktion. Både Internet-chat och fanns ju att studera. Sms-tjänsten fungerade som ett typiskt wow-krav som ingen från början tyckte de behövde utan upplevde som en kul grej. Idag skulle nog ingen köpa en mobiltelefon om inte den funktionen fanns med. Ett annat exempel är mobiltelefonernas kamerafunktion. Ännu en funktion som användarna inte alls behövde. Många anser fortfarande inte att de behöver den men nästan alla nya mobiltelefoner som kommer ut på marknaden har idag inbyggd kamera. Fortfarande tycker många av dem som har det att det bara är en kul grej men undra hur lång tid det tar innan ingen kan överhuvudtaget tänka sig att köpa en mobil utan kamerafunktion? Jag tycker det skulle vara väldigt intressant att få ta del av hur tanken på att implementera denna funktion kom till. Ligger det omfattande användarundersökningar bakom denna utveckling eller är det så att, trots användarcentrerad produktutveckling i all ära det är tekniken som i smyg styr och inte användarnas behov? Jag undra hur den sanna historien om sms-tjänsten

10 egentligen var? Över tid så förskjuts således dessa överraskningskrav eller wow-krav till att bli krav som användaren förväntar sig skall finnas där och blir tillslut kanske självklara baskrav. Wow-effekten är som sagt övergående men jag kan se det som att det är den som i stor utsträckning driver den innovativa utvecklingen framåt. Främst på grund av att den säkert är konkurrenskraftig men inte minst på grund av att den fungerar som en rolig utmaning för designutvecklarna. När det gäller nya innovativa produkter tror jag formativa utvärderingar lämpar sig mycket väl för att få fram användarbehov och önskemål. Jag tror att vi människor har svårt att relatera till saker och ting som är allt för abstrakta. Således tror jag att arbeta med prototyper i olika nivåer när det gäller innovativ design är mycket givande. När det går att fysiskt relatera till den framtida produkten tror jag att användaren mycket lättare kan tänka sig in i det framtida tänkta användningsområdet och ge feedback som tolkas till identifierbara kravställningar. Kravformuleringar som måste tas med en nypa salt eftersom de inbördes beroende faktorerna; användare, mål/uppgift, produkt fortfarande är helt beroende av kontexten. Och den framtida kontexten går aldrig att till fullo förutspå. 7. Referenser 1. Tayler, A. (2000) IT Projects: sink or swim. The Computer Bulletin, Januari, Preece, J. Rogers, Y. Sharp, H ( 2002 ) Interaction design Beyond humancomputer interaction. New York: John Wiley & Sons, Inc. 3. Föreläsning: Analys, Af Neuman, IT-universitetet, Göteborg, Marianne Karlsson Eason, K. (1987) Information Technology and Organizational Change. Kibdib: Tayler and Francis 6. Norman, D.A. ( 1988/1998 ) Design of everyday things. New York: Basic Books. 7. Föreläsning: MDI, HA1, Chalmers tekniska högskola, Göteborg, Christina von Dorrien. 8. Volere Requirements Specification Template: Föreläsning: Analys, Af Neuman, IT-universitetet, Göteborg, Marianne Karlsson. 10. Föreläsning: Analys, Af Neuman, IT-universitetet, Göteborg, Marianne Karlsson.

11 Bilagor Bilaga 1: Volere Requirements Specification Template