Brukskvaliteter och riktlinjer:

Transkript

1 LIU-KOGVET-D--04/21--SE Brukskvaliteter och riktlinjer: mål och medel i designprocessen Kristin Lundgren Linköpings universitet Institutionen för datavetenskap Kognitionsvetenskapliga programmet

2

3 SAMMANFATTNING Sammanfattning En vanlig ansats till god användbarhet är att låta designern falla tillbaka på kända riktlinjer för IT-design. Att använda sig av riktlinjer i designprocessen är dock inte helt bekymmersfritt, det är ofta svårt att veta när, var och hur de bör tillämpas. Det huvudsakliga syftet med uppsatsen är därför att ta reda på hur riktlinjer bättre kan integreras i designprocessen. Den lösning som föreslås är att koppla samman riktlinjer med brukskvaliteter. Detta görs med hjälp av metoden objectives tree, vanligt förekommande inom industridesign. Eftersom brukskvaliteter identifieras genom att studera användaren och den kontext där produkten ska användas ger dessa en verklighetsanknytning som riktlinjer saknar. Förhoppningen var därför att användningen av riktlinjer skulle förenklas om de applicerades i relation till brukskvaliteter. För att besvara forskningsfrågan genomfördes en fallstudie av handdatordesign på GoldPen Computing AB. Designfallet visade att tillvägagångssättet hjälpte till att prioritera mellan olika riktlinjer och att tillämpningen av dem underlättades. En annan vinst var att designbesluten blev väl härledda och dokumenterade. i

4

5 FÖRORD Förord Först vill jag tacka GoldPen Computing AB och min handledare Zoltan Hübsch för möjligheten att genomföra fallstudien hos dem och för allt stöd och all hjälp jag fått på vägen. Jag vill också tacka min handledare på IDA, Martin Wiman, för all praktisk hjälp och vägledning i samband med uppsatsen. Ett stort tack också till alla kabelreparatörer som har stått ut med att ha mig hängandes över axeln i deras dagliga arbete. Ni har varit en värdefull tillgång under hela studien. Tack Sara, god vän och kurskamrat, för att du har lyssnat på mig när jag har behövt prata och för alla värdefulla råd du har kommit med. Stort tack också till min familj och mina vänner, som hela tiden har funnits där och stöttat mig när det har behövts. Linköping, september 2004 Kristin Lundgren iii

6

7 INNEHÅLLSFÖRTECKNING Innehållsförteckning INLEDNING...1 BAKGRUND TILL UPPSATSEN...2 SYFTE...2 ADRESSAT...2 UPPSATSENS DISPOSITION...2 TEORI...3 BRUKSKVALITETER...3 Användbarhet...3 Användbarhetsmål...4 Användarupplevelse...5 Kvalitet i bruk...5 Bruk i flera dimensioner...6 Bruk av brukskvaliteter...7 RIKTLINJER...8 Olika typer av riktlinjer...9 Tillämpning av riktlinjer...10 KRITIK MOT RIKTLINJER...12 En studie av riktlinjers användning...12 Problem med riktlinjer...13 OBJECTIVES TREE METHOD...15 Procedur...15 PROBLEMFORMULERING...17 FALLSTUDIE...17 HANDDATORER...19 GRUNDLÄGGANDE OM HANDDATORER...19 Liten skärm...19 Inmatning...20 Mobilitet...20 DATORN SOM ARBETSREDSKAP...21 RIKTLINJER FÖR HANDDATORER...22 DESIGNPROCESSEN...23 PROCESSEN...23 DESIGNFALL...24 RIKTLINJER...24 v

8 INNEHÅLLSFÖRTECKNING BRUKSSITUATION...25 Bruket av systemet idag...27 Bruket av systemet i framtiden...28 Användaren...28 Sammanställning av brukssituationen...29 BRUKSKVALITETER...30 Minimalism...32 Tolerans...32 Förlåtande...32 Relevans...33 Identitet...33 Följsamhet...33 TRÄDDIAGRAM...33 DESIGNBESLUT...34 Designbeslut: Funktionalitet...34 Designbeslut: Öppen struktur...36 Designbeslut: Styra inmatning...38 Designbeslut: Terminologi...38 RESULTAT...41 DISKUSSION...49 MITT TILLVÄGAGÅNGSSÄTT...49 För vem?...50 Fördelar...51 Nackdelar...51 RIKTLINJER...51 För vad?...52 För vem?...52 BRUKSKVALITETER...53 För vem?...53 SAMMANFATTANDE DISKUSSION...54 SLUTSATS...55 FRAMTIDA FORSKNING...55 REFERENSER...57 APPENDIX A: RIKTLINJER...61 APPENDIX B: DESIGNDAGBOK...69 APPENDIX C: DESIGNBESLUT...75 vi

9 FIGURFÖRTECKNING Figurförteckning Figur 1 Olika typer av designriktlinjer och nivå av vägledning. 10 Figur 2 Strukturen på ett objectives tree. 16 Figur 3 Det tillvägagångssätt som ska testas med hjälp av designfallet. 18 Figur 4 Foton tagna under de kontextuella intervjuerna. 27 Figur 5 Bild över brukssituationen. 30 Figur 6 Det affinitetsdiagram som skapades under designprocessen. 32 Figur 7 Minimalism. 35 Figur 8 Relevans. 35 Figur 9 Systemets funktionalitet. 35 Figur 10 En första konkretisering av systemets struktur. 36 Figur 11 Följsamhet. 37 Figur 12 Identitet. 37 Figur 13 Skisser som visar på hur felrapporteringens fliksystem ser ut. 37 Figur 14 Date Picker - en komponent för att välja datum. 38 Figur 15 Mina uppdrag den första vyn som användaren möts av. 39 Figur 16 Inscannad bild av det ursprungliga träddiagrammet. 41 Figur 17 Träddiagram för brukskvaliteten minimalism. 42 Figur 18 Träddiagram för brukskvaliteten tolerans. 43 Figur 19 Träddiagram för brukskvaliteten förlåtande. 44 Figur 20 Träddiagram för brukskvaliteten relevans. 45 Figur 21 Träddiagram för brukskvaliteten identitet. 46 Figur 22 Träddiagram för brukskvaliteten följsamhet. 47 vii

10

11 INLEDNING Inledning Inom interaktionsdesign finns idag en mängd olika tekniker och metoder att använda sig av för att skapa användbara produkter. Enligt Jan Borchers [11] är den absolut största vinsten med några av dessa att de tvingar designern att tänka på att någon, och framför allt att någon annan, kommer att använda systemet när det är färdigt. Ett exempel på en sådan teknik är designriktlinjer, en blandning av teoretisk kunskap, erfarenhet och sunt förnuft. Syftet med riktlinjer är att de ska ge förslag om vad som bör finnas med och vad som bör undvikas i designen, helt enkelt att hjälpa designern att ta rätt designbeslut [25]. En annan metod är att arbeta med brukskvaliteter; egenskaper som användningen av ett visst system bör kännetecknas av. Dessa kvaliteter kan användas genom att utgöra mål som designern ska sträva efter att uppnå. Dessa båda tillvägagångssätt skiljer sig en del från varandra, främst vad gäller hänsyn till vem som faktiskt ska använda sig av produkten eller systemet. Riktlinjer ser likadana ut oavsett användare eller användningskontext och dessutom är det ofta svårt att utläsa för vilken typ av produkter som riktlinjerna är anpassade för. Kan till exempel samma uppsättning riktlinjer appliceras både på applikationer för stationära såväl som för bärbara datorer? Och kan de användas oberoende av användare och användningskontext? Riktlinjer har fått en hel del kritik just på grund av att de är svåra att tillämpa, det vill säga att det är svårt att veta när, var och hur de bör användas i designprocessen. Frågan kan ställas om det överhuvudtaget går att använda sådana gyllene regler inom ett område som bygger mycket på designerns egna kreativa och innovativa förmåga. Om Borchers har rätt i sitt påstående så är det kanske själva processen att använda sig av tekniker såsom designriktlinjer som är det mest givande för den slutliga designen, och inte hur många eller vilka riktlinjer som har använts. I ett försök att bättre utnyttja designriktlinjer i designprocessen har metoden objectives tree valts ut för att koppla samman riktlinjer med produktens brukskvaliteter. Förhoppningen är att brukskvaliteterna ska bidra till att det blir enklare att välja ut vilka riktlinjer som bör appliceras på en specifik design och på så sätt också ge ett bättre underlag för olika designbeslut. 1

12 INLEDNING Bakgrund till uppsatsen Uppsatsen är skriven på uppdrag av GoldPen Computing AB i Linköping [15]. Företaget arbetar med mobila informationslösningar för användare som arbetar ute i fält. Informationslösningarna delas av företaget in i tre huvudområden; inventering, projektering och diregering. Gemensamt för företagets alla applikationer är att de är utformade för att användas på mobila datorer. Uppdraget gick i stora drag ut på att förse företaget med riktlinjer som kan användas vid utformningen av framtida applikationer för handdatorer. Någon mer specifik frågeställning gavs inte och studien har således till stor del utformats utifrån personliga intresseområden och rådande forskningsläge. Syfte Uppsatsens huvudsakliga syfte är att ta reda på och ge insikt i hur riktlinjer bättre kan integreras i designprocessen. Förhoppningen är att resultatet av studien ska kunna användas som stöd i framtida designprocesser. Adressat Uppsatsens främsta målgrupp är personer som intresserar sig för interaktionsdesign och användbarhet. Den riktar sig också till personer inom branschen för IT, med fokus på handdatorer. Uppsatsens disposition Teori Problemformulering Handdatorer Designprocessen Resultat Diskussion Slutsats Beskrivning av brukskvaliteter, designriktlinjer och metoden objectives tree. Det teoretiska ramverket mynnar här ut i uppsatsens problemformulering. För att besvara denna ska en felrapporteringsapplikation för handdator utformas. För den som är intresserad ges här en kortare introduktion till området handdatorer. Här redogörs för designprocessens alla faser, både teori och genomförande. De träddiagram som har skapats under designprocessen med hjälp av metoden objectives tree visas. Designprocessen och resultatet diskuteras och koppling till problemformuleringen görs. Slutsatser utifrån arbetet och diskussion om hur framtida forskning inom området bör bedrivas. 2

13 TEORI Teori I detta avsnitt presenteras teorier om brukskvaliteter, designriktlinjer och metoden objectives tree. Brukskvaliteter För att kunna förklara begreppet brukskvalitet, eller kvalitet-i-bruk som det också kallas, är det viktigt att först redogöra för begrepp såsom användbarhet, användbarhetsmål och användarupplevelse. Användbarhet Traditionell systemutveckling har länge handlat om att konstruera system som uppfyller vissa funktionella krav, utan tillräcklig kännedom om slutanvändarnas kognitiva eller fysiska förmågor och utan en tydlig bild av hur kontexten ser ut där systemet ska användas [4]. I dagens systemutveckling räcker det inte längre med att utveckla produkter som rent tekniskt fungerar som de ska, produkterna måste också vara lätta att använda och passa in i kundens och användarens arbetssituation [5]. Trots det saknar många designprocesser ett användarcentrerat angreppssätt och misslyckas därför med att ta till vara på användarnas behov och önskemål [4]. Termen användbarhet myntades för ungefär 20 år sedan med förhoppningen om att ersätta det mer vaga och subjektiva begreppet användarvänlig [7]. Användbarhet, som numera länge har varit ett centralt begrepp inom MDIområdet (människa-dator interaktion) sågs till en början som en maximalt god anpassning mellan systemets användningsegenskaper och det generella vetandet om mänskligt tänkande och handlande [20, sid 149]. Numera finns det en mer subjektiv syn på begreppet användbarhet, något som visar sig i ansatser såsom kontextuell design och participativ design där användarens upplevelse av att använda systemet spelar en större roll än tidigare [20]. ISO [16] definierar användbarhet enligt följande: the effectiveness, efficiency and satisfaction with which specified users can achieve specified goals in particular environments Ett system bör alltså genomföra uppgiften (effectiveness), genomföra uppgiften med liten ansträngning på så kort tid som möjligt (efficiency) samt vara 3

14 TEORI tillfredsställande att använda (satisfaction) [14]. Definitionen poängterar också betydelsen av att ta hänsyn till det faktum att ett system har specifika användare, att de i sin tur har specifika mål och att systemet används i en specifik miljö. Begreppet användbarhet definieras ibland också som att en artefakt ska vara lätt att lära, effektiv och tillfredsställande för användaren att använda [25]. Det kan vara svårt för en produkt att uppfylla alla dessa kriterier samtidigt och det är därför viktigt att tydliggöra vilka som är de primära målen. Är det viktigare att produkten är så effektiv som möjligt eller är det viktigare att den är rolig och underhållande? Enligt Preece et al [25] skiljer sig dessa två typer av mål i termer av hur de operationaliseras, det vill säga hur de kan uppnås och med vilka medel. Att uppnå mål av typen användbarhetsmål handlar om att uppnå vissa användbarhetskriterier, som till exempel effektivitet. Att uppnå mål av typen användarupplevelser handlar istället om att nå upp till en viss kvalitet av användarens upplevelse. Det kan vara viktigt att inse skillnaderna mellan användbarhetsmål och användarupplevelser och att vara medveten om att varken alla användbarhetsmål eller alla användarupplevelser lämpar sig för alla interaktiva produkter. Vissa kombinationer passar inte heller alltid bra ihop, det kan till exempel vara svårt att utforma ett säkerhetssystem som är både säkert och roligt. Vad som är viktigast och som bör prioriteras högst beror på användningskontexten, uppgiften och vilka de tänkta användarna är. [25] Användbarhetsmål Användbarhet har länge handlat om att skriva ner formella och mätbara kriterier och därefter se hur många av dessa kriterier som produkten uppfyller. Detta synsätt hör främst hemma inom usability engineering och har på grund av kravet på just mätbarhet fått en hel del kritik. En risk med synsättet är att hela utvecklingsprocessen endast inriktas mot sådant som går att mäta, på bekostnad av viktigare överväganden, som till exempel användarens upplevelse av att använda systemet. [19] Preece et al [25] räknar upp följande användbarhetsmål som utvecklaren ska sträva efter att uppnå med sin design: Effectiveness Efficiency Safety Utility Learnability Memorability - artefakten ska vara effektiv - artefakten ska vara ändamålsenlig och effektiv - artefakten ska vara säker - artefakten ska göra stor nytta - artefakten ska vara lätt att lära sig - artefakten ska vara lätt att komma ihåg 4

15 TEORI Shackels definition av användbarhet från 1986 [i Faulkner, 14], ofta refererat till som LEAF, består av learnability, effectiveness, attitude och flexibility. Ytterligare en uppsättning, ganska snarlika, användbarhetsmål är Jonas Löwgrens samling REAL : relevance, effectiveness, attitude och learnability [21]. Användarupplevelse Användarupplevelse, det vill säga hur användaren upplever interaktionen med produkten, definieras i subjektiva termer och kan därför vara svår att mäta objektivt. Preece et al [25] ger följande exempel på olika användarupplevelser: satisfying, enjoyable, fun, helpful, aesthetically pleasing och rewarding. Enligt Arvola [1] är det inte tillräckligt att designa enbart med användarupplevelser i åtanke. Han anser att det är långt bättre att fokusera på användningen, bruket, snarare än användaren eftersom designrymden då med fler variabler blir ännu mer komplex. Att designa för praktik, kultur, samhälle, gemenskap, samarbete, etik, konstruktion och användarupplevelse istället för endast användarupplevelse innebär att designrymden utvidgas ytterligare. [1] En sådan utveckling av begreppet användarupplevelse är kvalitet-i-bruk (quality in use), där utgångspunkten är själva bruket, eller användningen av en artefakt. Kvalitet i bruk Utifrån användarens perspektiv är det just upplevelsen av att använda systemet som är den kritiska faktorn för att en produkt ska anses användbar [4]. Bara för att kvaliteter såsom användarupplevelser inte är så lätta att mäta objektivt får det inte hindra utvecklaren att fundera på dem [19]. Begreppet kvalitet-i-bruk, eller brukskvalitet som det ofta kallas, är liksom användbarhet inte ett helt enkelt begrepp att förklara. I en del ergonomiska standarder (t ex den redan nämnda ISO ) används också begreppen användbarhet och kvalitet i bruk synonymt. ISO/IEC [17] definierar brukskvaliteter som användarnas syn på systemets kvalitet, och att de endast kan mätas när systemet används [6]. Löwgren är inne på samma spår och definierar brukskvaliteter som certain properties of a digital design that are experienced in its use [22, sid 1]. Brukskvaliteter är alltså utmärkande för designen och förser med ett språk som designern kan använda för att kommunicera det önskvärda resultatet på. Kvalitet är i sig ingen absolut egenskap, utan beror i allra högsta grad på i vilken kontext något sker [5]. Brukskvalitet är förutom av användaren beroende av de omständigheter i vilka systemet används, innefattande faktorer såsom [6]: uppgift som systemet ska utföra utrustning (hårdvara, mjukvara och material) fysisk omgivning social omgivning 5

16 TEORI Kännetecken hos de tänkta användarna som kan vara värda att lägga märke till är dennes kunskap, färdigheter, erfarenhet, utbildning, ålder och fysiska förmågor. Om alla dessa detaljer noteras tidigt i designprocessen kan detta bidra till att rätt designbeslut tas samt ge en bra utgångspunkt för utvärdering av systemet. Målet bör vara att ta reda på de överliggande målen med all användning av systemet. [6] Bevan [6] listar fördelarna med vad förbättrade brukskvaliteter skulle innebära för en produkt. Dessa är enligt honom: Förbättrad tillgänglighet Förbättrad effektivitet Produkten blir mer effektiv och ändamålsenlig Ökad produktivitet (ett väl utformat system tillåter användaren att koncentrera sig enbart på uppgiften) Minskat antal fel (misstag kan bero på att systemet inte stämmer överens med användarens mentala modell) Minskat behov av utbildning Ökad acceptans (det är lättare att använda och lita på ett väldesignat och lättåtkomligt system) En förbättrad kvalitet i bruk bidrar med andra ord till en förbättrad användbarhet, något som kanske inte är helt förvånande eftersom begreppen ibland används synonymt. Bruk i flera dimensioner I en syntes av flera kända modeller av begreppet brukskvalitet lyfter Arvola [2] fram tre sorters bruk som är fundamentala för ett systems olika roller och funktioner; det praktiska, sociala och estetiska bruket. Designern måste förutom dessa tre bruk hantera de begränsningar och möjligheter som etik och konstruktion innebär. Nedan förklaras detta ytterligare. Det praktiska bruket specificerar mål som designen ska leva upp till. Det är också i slutändan möjligt att värdera och mäta hur väl dessa uppnås, vilket till stor del är vad usability engineering handlar om. Det praktiska värdet av att använda en produkt är alltid relativt dess sociokulturella kontext och det är också beroende av användarens mål, behov, färdigheter och kunskap. Det sociala bruket handlar om på vilket sätt systemet används i relation till andra människor. Det kan handla om att använda systemet som en del i ett samspel med andra människor eller om att systemet kan stå för en gemensam representation som personer kan enas eller kommunicera kring. Det estetiska bruket har en intressant relation till det sociala bruket eftersom den som betraktar systemet befinner sig i en social och kulturell kontext. De estetiska egenskaperna finns varken i subjektet eller i objektet utan snarare i relationen dem emellan. Estetik handlar alltså inte i det här fallet endast om 6

17 TEORI skönhet eller om artefakten är vacker, utan snarare om hur samspelet mellan subjekt och objekt fungerar. Det är alltså först genom att använda systemet som den estetiska helhetsupplevelsen realiseras. Etik innebär i det här sammanhanget att designern måste fundera över vilket slags samhälle som skapas i och med designen, vilka värden som den bär med sig och huruvida designern vill vara ansvarig för resultatet av att sätta produkten i bruk. Överväganden kring konstruktion handlar om det material som ska utformas, minneskapacitet, processorhastighet, skärmstorlek etc. Materialet måste användas på bästa sätt samt bibehålla prestanda och robusthet till en rimlig kostnad. Bruk av brukskvaliteter Om en eller flera önskvärda brukskvaliteter identifieras tidigt i designprocessen är det lättare att utveckla en slags riktning för designen. Dessutom underlättar det att ha något konkret och eftersträvansvärt att prata om. I takt med att arbetet går från konceptuella till detaljerade faser kan de önskvärda kvaliteterna gradvis göras om till mer specifika mål. [22] För att ta reda på vilka brukskvaliteter som bör känneteckna användningen av en viss produkt måste någon i designteamet ge sig ut i brukssituationen, omgivningen där artefakten används, och försöka identifiera vem den tänkta användaren är och vilka uppgifter som utförs. När designern försöker hitta brukskvaliteterna kan denne gå in i den framtida användningssituationen och fundera över vad användningen av systemet bör kännetecknas av.... Designern måste alltså också försöka täcka in alla dimensioner av bruket; det praktiska, sociala och det estetiska såväl som de möjligheter och begränsningar som finns vad gäller etik och konstruktion. Först därefter kan en lista över önskvärda brukskvaliteter skrivas ner, en lista som till viss mån liknar REAL och LEAF, men som kommer att vara betydligt mer relevant för det specifika systemet. Brukskvaliteterna bör därefter användas för att värdera olika designalternativ och ge stöd för olika designbeslut. [2] I designprocessen är det sedan viktigt att hela tiden tänka på och reflektera över hur designen tar hänsyn till de olika brukskvaliteterna. 7

18 TEORI Exempel på brukskvaliteter Efter att ha försökt förklara begreppet brukskvalitet ges här några exempel på hur sådana kan formuleras och definieras. Playability, eller spelbarhet, har att göra med användarens motivation. Spelbarhet kan vara svårt att uppnå i många system, men är samtidigt en mycket eftertraktad brukskvalitet som lämpar sig väl för kommersiella applikationer där konsumentens tycke och smak kan få ekonomiska konsekvenser. Ett spel har till exempel hög spelbarhet när användaren efter ett avslutat spel uttrycker bara en gång till. [22] Pliability, eller följsamhet (egen översättning), är en annan brukskvalitet som Löwgren [22] särskilt framhåller. Följsamhet kännetecknas av att systemet känns mottagligt och att övergången mellan tanke och handling kan ske snabbt och direkt. Ofta är användningen idag onödigt begränsad av underliggande databaser och andra programmeringstekniska hinder, något som kan försvåra chanserna att uppnå följsamhet. Följsamhet lämpar sig förmodligen också särskilt bra i situationer där systemet används som arbetsredskap och det är viktigt att användaren känner sig som ett med systemet. Riktlinjer Ett annat, näst intill motsatt tillvägagångssätt, av att skapa sig en bild av användbarhet är genom att konstruera så kallade designriktlinjer. Riktlinjer härstammar från en blandning av teoretisk kunskap, erfarenhet och sunt förnuft. De skrivs ofta på ett preskriptivt sätt och ger förslag om vad som bör finnas med och vad som bör undvikas i designen. Preece et al [25, sid 21] uttrycker det: the do s and don ts of interaction design. [25] Syftet med riktlinjer är att samla designkunskap, formulera den som regler och använda dem vid utformningen av nya produkter [31]. Riktlinjer är inte tänkta att specificera exakt hur ett gränssnitt ska designas eller vilken färg och form en specifik ikon ska ha. Tanken är snarare att riktlinjer ska fungera som en slags påminnelse för den som utformar systemet, en slags försäkran om att vissa delar i systemet finns med. [25] På så sätt kan utvecklingen av produkter som är användbara, konsistenta och som överensstämmer med givna konventioner möjliggöras [29]. 8

19 TEORI Enligt Shneiderman [27] är fördelarna med designriktlinjer flera. De kan bidra till konsistens mellan flera olika designers, dokumentera praktisk erfarenhet, dra nytta av empiriska resultat och förse designteam med tumregler som kan vara bra att ha tillhands när designbeslut måste tas. En åtskillnad kan göras mellan principer som härstammar från psykologin och de som har uppstått genom erfarenhet av att jobba med en speciell applikation. Vissa riktlinjer refererar till mer generella principer, en del specificerar detaljer i gränssnittet och andra fokuserar mer på gränssnittets presentation och beteende. [27] En del riktlinjer är generella rekommendationer för användbarhet medan andra definierar en stil som utvecklare av en viss typ av applikationer förväntas att följa [29]. Olika typer av riktlinjer Det uppstår lätt en förvirring om vad en riktlinje egentligen är för något. En del pratar om usability design principles, andra om usability heuristics, och vissa väljer att kalla dem för design concepts. En salig blandning av olika termer kan tyckas men nyckeln är att förstå hur olika nivåer av vägledning skiljer sig och hur de kan och bör användas. [25] Riktlinjer är den mest generella termen som används för att referera till alla former av vägledning [25]. Designprinciper såsom Normans designa för fel befinner sig på en generell nivå och kallas ibland för tumregler, eller designkoncept, när de används i praktiken. De används som påminnelser om vad som ska finnas och vad som ska undvikas i gränssnittet, till exempel att göra det möjligt att ångra en handling om användaren gjort fel. [24][25] Användbarhetsprinciper, såsom Nielsens tala användarens språk [i Faulkner, 14] är en mer specifik nivå av vägledning och kallas också de för tumregler när de används i praktiken. Med hjälp av användbarhetsprinciper kan gränssnittet testas genom en så kallad heuristisk utvärdering [25]. Användbarhetsprinciper liknar designprinciper, men är ofta ännu mer preskriptiva. Tumregler, eller heurestiker, används för att referera till design- och användbarhetsprinciper när de appliceras på ett särskilt designproblem [25]. De är ganska vaga men ändå omfattande eftersom de förklarar olika fenomen, till exempel kognitiva. Förklaringarna kräver dock en hel del förförståelse vilket gör dem ganska svårhanterliga. [30] Regler är en mer specificerad form av vägledning som refererar till en speciell föreskrift som måste följas. Regler är med andra ord riktlinjer som alltid bör följas. Ett exempel på en sådan regel är ha alltid en bakåt- och en framåtknapp i en webbläsare. [25] 9

20 TEORI En standard är en speciell slags regel som systemutvecklaren måste arbeta efter, som till exempel vilken sida av vägen man ska köra på ingen sida är egentligen bättre än den andra, varvid olika länder också har antagit olika standarder [14]. En standard är något som är till 100% bestämt, en riktlinje är något som oftast stämmer [30]. QWERTY-tangentbordet är ett exempel på en standard som blivit vida accepterad. Ursprungligen konstruerades tangentbordet för mekaniska skrivmaskiner med syftet att undvika att de som skrev på dem skulle skriva så fort att tangenterna fastnade i varandra. Moderna tangentbord har inga tangenter som kan fastna i varandra men layouten är kvar som ett kvarglömt arv från en omodern teknologi. Trots att QWERTY-tangentbordet inte fördelar ansträngningen lika över våra fingrar och händer så skulle det inte vara en bra lösning att ändra standard eftersom negativ transfer då skulle påverka användaren. [14] TYP AV RIKTLINJE Regel Designprincip Användbarhetsprincip Tumregel Generell Standard Specifik NIVÅ AV VÄGLEDNING Figur 1 Olika typer av designriktlinjer och nivå av vägledning. I figur 1 presenteras en modell över de olika typer av riktlinjer som finns. Beroende på vilken nivå av vägledning de ger kan de också användas på lite olika sätt i designprocessen. Tillämpning av riktlinjer Riktlinjer måste alltid användas med en viss förståelse av när de går att applicera och när de inte är lika lämpliga. Enligt Nielsen [30] går de flesta väldokumenterade riktlinjer att dra nytta av och det går därför inte att bortse ifrån alla riktlinjer. Däremot kan det ibland finnas anledning att bryta mot några av dem, helt beroende på situationen. [30] Riktlinjer kan vara speciellt bra att följa då det inte finns någon användbarhetsexpertis i designteamet. Alla riktlinjer måste dock specificeras, det vill säga göras mer konkreta och tolkas utifrån situationen och designerns egen erfarenhet innan de kan användas. [30] Generella riktlinjer bör utvecklas och expanderas så att de blir mer applikationsspecifika och beroende av det material produkten ska utformas i [27]. En anpassning av riktlinjer är nödvändigt för att de ska bli lättare att förstå och för att designern ska veta när 10

21 TEORI de bör appliceras på designen [25][30]. Nielsen [30, sid 4] uttrycker det: It s a matter of the usability of the usability principles, really. Den som är ansvarig för designen av gränssnittet bör tidigt i designprocessen se till att det genereras en uppsättning av riktlinjer att arbeta utifrån. Varje projekt har olika behov men riktlinjer för ordval, ikoner, skärmens layout, input, output, interaktionstekniker samt riktlinjer för inlärning och utbildning bör alltid övervägas enligt Shneiderman. [27] När riktlinjer ska specificeras för en viss process eller produkt bör detta ske som en social process inom företaget. Procedurer för att distribuera riktlinjerna, att upprätthålla dem och för att tillåta undantag och godkänna förbättringar bör etableras. Riktlinjer ska enligt Shneiderman [27, sid 100] ses som a living text that is adapted to changing needs and refined through experience. Om hela utvecklingsteamet är eniga om riktlinjerna fortskrider implementationen snabbare och med färre designändringar. [27] Väldokumenterade riktlinjer bidrar också till designprocessen genom att till viss del automatisera designen och se till så att den blir konsistent och komplett. Dokumenteras dessutom designbesluten med stöd i riktlinjerna kan alla i teamet ta del av dem och kommunikationen underlättas. [27] Riktlinjer kan med andra ord fungera som ett stöd i allt det beslutsfattande som förekommer i designprocessen [26]. Riktlinjer kan, förutom under själva designprocessen, också användas för att utvärdera ett systems användbarhet. En heuristisk utvärdering innebär att ett gränssnitt utvärderas utifrån en uppsättning riktlinjer utan att slutanvändaren behöver involveras. Då kan problem med designen identifieras men dessvärre ger inte metoden några konkreta lösningar på hur de uppkomna problemen bör lösas. En annan nackdel är det faktum att den heuristiska utvärderingen inte tar någon hänsyn till de faktiska slutanvändarna och hur de tycker och tänker. Trots nackdelarna är heuristisk utvärdering ett relativt enkelt och kostnadseffektivt sätt för utvecklaren att försäkra sig om att åtminstone några av alla designriktlinjer efterföljs. [14] 11

22 TEORI Exempel på riktlinjer För att ge en bättre bild av hur en riktlinje kan se ut ges här några exempel, hämtade ur tre olika uppsättningar (Norman [24], Nielsen [i Faulkner, 14] och Shneiderman [27]). Dessa uppsättningar beskrivs mer utförligt i appendix A. Gör mappningen rätt Ledtrådar till hur en produkt fungerar får vi ofta genom att titta på den. Relationen mellan två saker, mellan kontrollerna och resultatet av att använda kontrollerna, kallas för mappning. Som ett exempel på en bra mappning är när vi vill få bilen att svänga. Genom att vrida ratten åt höger (medsols) svänger också bilen till höger. Likaså bör designers tänka på att utforma IT-artefakter med en bra mappning mellan kontroller och resultatet av dem. Tala användarens språk - Dialoger som systemet för med användaren bör uttryckas tydligt med ord, meningar och termer som användaren är bekant med. Huvudsaken är att språket inte uttrycks i allt för tekniska termer som bara utvecklarna själva förstår. Ge informativ feedback Varje handling som användaren gör bör resultera i feedback från systemet. För vanliga och mindre betydande handlingar behöver responsen inte vara så omfattande men för ovanliga och större handlingar bör systemet tydligt tala om att någonting har skett. Användaren ska aldrig behöva vara osäker på i vilket tillstånd systemet befinner sig i. Kritik mot riktlinjer Nu när vi vet hur riktlinjer kan se ut och hur de bör tillämpas är det intressant att titta närmare på de problem som ofta förknippas med att använda dem. En studie av riktlinjers användning Tetzlaff och Schwartz [29] har utfört en studie där de har tittat på hur utvecklare använder sig av riktlinjer när de genomför en designuppgift. Syftet med studien var bland annat att ta reda på vilken roll riktlinjer egentligen har i designprocessen och hur så kallade style guides används i praktiken. Få deltagare uppgav inledningsvis att de använde riktlinjer i deras dagliga arbete som utvecklare och designers. 12

23 TEORI Det visade sig till exempel att en del designers ifrågasatte vissa av riktlinjerna eftersom de ansåg att användningen av dem endast skulle orsaka användbarhetsproblem istället för att lösa dem. I en sådan situation hamnar designern i ett dilemma och det kan bli svårt att avgöra om riktlinjen till varje pris ska följas eller om det är bättre att följa sitt eget tycke och smak. Tetzlaff och Schwartz kom fram till att riktlinjer som resulterar i mindre bra produkter inte bara bidrar till att utvecklaren känner missnöje för just den specifika riktlinjen utan påverkar också dennes syn på riktlinjer i stort. Vad som också tydligt framgick ur studien var att riktlinjer med exempel och grafiska illustrationer var mer omtyckta och refererade till än de utan. Trots att exemplen egentligen endast var till för att illustrera den tillhörande texten ansågs i praktiken texten vara till för att kommentera de grafiska exemplen. De mer erfarna deltagarna i studien tyckte inte att de mer generella riktlinjerna såsom förse med feedback och tala användarens språk var särskilt informativa. Mer specifika riktlinjer med detaljerade strategier för designen välkomnades däremot och övervägdes mer noga och konsistent. Studien kom också fram till att riktlinjers främsta syfte bör vara att fungera som ett komplement till andra metoder, som till exempel iterativa användbarhetstester eller dylikt, och att de inte bör skapa en situation där designern blir helt beroende av att använda dem. Problem med riktlinjer Att använda sig av riktlinjer är alltså inte helt problemfritt. Det finns en stor mängd uppsättningar av olika riktlinjer och det kan vara svårt att välja vilka som ska appliceras på ett specifikt designproblem. Deras validitet och tillämpbarhet beror också på i vilken kontext de ska användas. Riktlinjer beskriver sällan motiven bakom eller argumenterar för varför de finns vilket gör det är svårt att avgöra var, när och hur de bör tillämpas för att göra mest nytta. [31] Problemen med riktlinjer kan enligt van Welie et al [31] sammanfattas i följande punkter: de är ofta för enkla eller för abstrakta de kan vara svåra att välja ut de är svåra att tolka de kan stå i konflikt med varandra de har ofta problem med auktoritet vad gäller deras validitet En av anledningarna till problemen är att de flesta riktlinjer ger förslag på en generell absolut validitet när de i själva verket endast bör appliceras i en specifik kontext. Sammanhanget är avgörande för att veta vilka riktlinjer som kan användas och varför. Utan kunskap om denna och om användaren kan designproblemen inte lösas på ett tillfredsställande sätt. [31] Det finns inte några riktlinjer som går att använda i alla sammanhang och om en riktlinje 13

24 TEORI beskrivs och motiveras allt för kortfattat är risken stor att en oerfaren designer drar fel slutsatser om när och hur den bör tillämpas [26]. Riktlinjer är ofta för abstrakta eller för specifika. Abstrakta riktlinjer, såsom Shneidermans åtta gyllene regler [27], kan vara bra för att känna igen en dålig design men ger inte några konstruktiva förslag på hur man kan lösa ett specifikt problem. Om riktlinjer däremot är skräddarsydda bara för att passa in i ett visst sammanhang och därför är allt för specifika (t ex Microsofts riktlinjer [23]) kan det vara svårt att dra nytta av dem i ett annat sammanhang. [11] Ofta är det också svårt att förstå varför riktlinjen ser ut som den gör och vilket problem den är avsedd att åtgärda [31]. För att en riktlinje ska göra någon nytta krävs att den avslöjar sin orsak och uppkomst. En dåligt och knappt utformad riktlinje bidrar inte med särskilt mycket till den ständiga dialogen designern måste föra med både sig själv och designteamet, utan hävdar snarare endast därför att. En riktlinje som baseras på bevis är istället mer användbar eftersom den kan ge designern en bättre förklaring till varför den bör tillämpas. [26] Riktlinjer kan ofta härledas till teorin eller till kognitiv psykologi men ibland hamnar riktlinjer i dessa samlingar av misstag. Om ett system utformas för en speciell plattform är det viktigt att försäkra sig om att riktlinjer som passar just den plattformen används. [14] Det är också viktigt att inse att riktlinjer kan förändras över tid och bli omoderna. Hur snabbt de blir omoderna beror dock på typen av riktlinjer. En lokal stilguide kan snabbt vara inaktuell medan användbarhetsprinciper knappt ändras alls. [26] En designer måste därför noga undersöka vilka riktlinjer som finns kvar på grund av en bra anledning och vilka som finns kvar bara för att de alltid funnit där. Faulkner [14] kallar detta för att göra en guideline review. Riktlinjer kan dessutom ge sken av att motsäga varandra och designern kan få svårt att lösa designproblemet som en konsekvens av detta [31]. Riktlinjer är ofta ganska breda och generella och det kan bli nödvändigt att bryta mot dem för att uppnå en god design [14]. Designern kan också bli tvungen att kompromissa mellan olika riktlinjer. Ett exempel är då designern försöker begränsa användargränssnittet med påföljden att informationen blir desto mindre synlig. Riktlinjerna constrain och visibility står då i konflikt med varandra. Samma sak kan hända då en enda riktlinje används. Ett exempel på det är affordans - ju mer designen försöker efterlikna det verkliga fysiska objektet, till exempel en knapp, desto mer klottrig och svår kan den bli att använda. Ytterligare exempel är om designern försöker utforma ett gränssnitt konsistent med något så kan det resultera i inkonsistens med något annat. Ibland kan till och med inkonsistenta gränssnitt vara enklare att använda än konsistenta, det kan dock ta längre tid att lära sig ett sådant gränssnitt något som också måste beaktas vid val av lösning. [25] 14

25 TEORI Rabourn ställer i en debattartikel [26] frågan hur det kommer sig att riktlinjer har fått ett så dåligt rykte och poängterar att riktlinjer inte ska ses som regler som måste upprätthållas, och att de inte eliminerar designerns kreativa och innovativa förmåga. Hon menar att riktlinjer är en viktig del av designprocessens strategi. Designprocessen är en argumentativ process där designern hela tiden måste reflektera över vad ett designbeslut kan få för konsekvenser och vilka kompromisser som kan bli nödvändiga att göra. En riktlinje är inte slutet på konversationen utan istället en viktig del av den, enligt Rabourn. Många av de dokumenterade riktlinjer som finns kommer förmodligen att förbli olästa, missförstådda och förbisedda. Ju längre och komplexare ett dokument är, desto större är risken. [29] Av den anledningen och på grund av problematiken med selektion, validitet och applicerbarhet behövs alternativa tillvägagångssätt för att använda sig av riktlinjer. Objectives tree method Metoden är utvecklad av Nigel Cross [13] och förekommer främst inom industridesign där den används som utgångspunkt för design av produkter med dåligt definierade krav. Syftet med metoden är att reda ut vilka som är de primära målen med produkten och vilka mål som kan behöva uppnås på vägen samt vilka relationer som finns dem mellan. Inom industridesign är det vanligt att utgå från ett så kallat ill-defined problem när designprocessen startar och trots att kunden kanske inte riktigt vet vad den vill ha måste designern ha något att arbeta mot och att sträva efter. Ett viktigt första steg i designprocessen är därför att just försöka ta reda på vilka målen med produkten är. Målen kan sedan ändras och justeras i takt med att en bättre förståelse för problemet växer fram eller i takt med att nya förslag på lösningar uppstår. Om målen ändras under processens gång kommer också medlen för att uppnå dem att ändras. Målen bör uttryckas i sådan form att de kan förstås av både kund och designer, men allra helst också av alla inblandade i designprocessen. Cross tar upp det mycket vanliga problemet med att personer i samma designteam kan ha olika mål med designen och att det då får konsekvenser på slutprodukten. Metoden objectives tree ger en värdefull lösning på hur mål kan struktureras och uttryckas för att bättre kommunicera dem med alla inblandade parter. I det diagram som metoden genererar visas också hur olika mål är relaterade till varandra och hur det hierarkiska mönstret av mål och delmål ser ut. [13] Procedur Först görs en lista över alla designmål, eller design objectives. Listan kan bestå av en blandning konkreta och abstrakta mål som designern måste försöka uppnå. Cross poängterar betydelsen av att målen till en början är mycket vaga och kortfattade, till exempel produkten måste vara säker. För att målen sedan ska bli mer precisa måste uttalanden som det ovan utvecklas och klargöras ytterligare. Ett sätt är att ställa sig frågan vad målet egentligen betyder, det vill 15

26 TEORI säga vad som menas med just det uttalandet. Frågor som är användbara för att utveckla och klargöra målen är varför, hur och vad. Varför ska produkten vara säker? Hur kan säkerhet uppnås? Vad handlar problemet egentligen om? [13] Efter att målen har uttryckts ska listan över dessa ordnas i grupper med mål på högre nivåer och mål på lägre nivåer. Det bör tydligt framgå att vissa mål är av större betydelse än andra. Målen grupperas sedan så att varje grupp har att göra med ett högre mål, till exempel säkerhet. Inom varje grupp sorteras sedan delmålen hierarkiskt så att målen på en lägre nivå tydligt särskiljs som medel för att nå målen på den högre nivån. En värdefull vinst med att strukturera målen är att det ger designern tid för reflektion och listan över mål, delmål och medel kan i och med detta uppdateras och utökas ytterligare. [13] Därefter konstrueras ett träddiagram som visar på hierarkiska relationer och inbördes förhållanden mellan målen. Det kan vara lättare att tänka på alla delmål som rötter snarare än som grenar (eftersom diagrammet ritas upp och ner). Att arbeta sig nedåt i trädet ger sedan en indikation om hur ett mål på en högre nivå kan uppnås. Att arbeta sig uppåt i trädet ger en indikation om varför ett mål på en lägre nivå är viktigt att uppnå i designprocessen (se figur 2). [13] Hur? Varför? Figur 2 Strukturen på ett objectives tree. Träddiagrammet ger en bild av problemet och kan bidra till en förbättrad förståelse av problemet och en bättre konsensus i gruppen. Det ska ses som ett tillfälligt mönster som kan komma att ändras i takt med designprocessens fortskridande. Det är enligt Cross inte själva träddiagrammet som är av störst värde, utan processen att arbeta med metoden eftersom denna tvingar designern att ställa frågor kring problemen, målen och hur de ska uppnås. [13] 16

27 PROBLEMFORMULERING Problemformulering Jakten på användbarhet och väl utformade artefakter är inte helt okomplicerad. Begreppet användbarhet kan i sig förklaras och definieras på en mängd olika sätt. Tekniker såsom att använda sig av designriktlinjer är heller inte helt lätta att förstå sig på för den oinvigde. Det behövs nya tillvägagångssätt för att bättre dra nytta av all designkunskap och erfarenhet som finns bland alla dessa riktlinjer, tumregler och användbarhetsprinciper. Ett försök att göra detta skulle kunna vara att försöka koppla samman brukskvaliteter med riktlinjer. På så sätt kan kunskap om användaren och om brukssituationen, en massa erfarenhet och kunskap om människan och dess kognitiva förmågor tillsammans utgöra grunden för en designprocess som i slutändan leder fram till en uppskattad och användbar produkt. Om brukskvaliteterna ses som de primära målen som ska uppnås, kan riktlinjerna ses som medlen för att uppnå dem. En metod för att strukturera mellan mål och medel är objectives tree. Genom att använda den metoden kan ett träddiagram genereras som beskriver både hur brukskvaliteterna ska uppnås men också varför en viss riktlinje bör tillämpas. Det övergripande problemet är således att ta reda på om användningen och tillämpningen av designriktlinjer underlättas av att de appliceras i relation till systemets identifierade brukskvaliteter. Uppsatsens problemformulering är: Kan brukskvaliteter och metoden objectives tree användas som ett verktyg för att underlätta användningen av designriktlinjer? Fallstudie För att testa tillvägagångssättet (figur 3) genomfördes en fallstudie av handdatordesign på GoldPen Computing AB. För att besvara problemformuleringen har designprocessen därefter noga analyserats. Delfrågor som besvaras under designprocessen: Vilka brukskvaliteter bör bruket av applikationen kännetecknas av? Vilka riktlinjer anses särskilt användbara för applikationen och varför? 17

28 PROBLEMFORMULERING ANVÄNDARE PDA Gå ut och titta efter vilka brukskvaliteter bruket (bör) kännetecknas av Brukskvalitet Använd metoden objective tree method Hur? Varför? RIKTLINJER Välj ut och tillämpa riktlinjer som kan bidra till att uppnå brukskvaliteterna (målen) Figur 3 Det tillvägagångssätt som ska testas med hjälp av designfallet. 18

29 HANDDATORER Handdatorer Eftersom problemformuleringen besvaras genom ett designfall där en applikation för handdator ska utformas, följer här ett avsnitt där grundläggande teorier inom området redogörs för. Grundläggande om handdatorer Handdatorer har på grund av dess mobilitet blivit ett vanligt arbetsredskap ute i fält där de kan användas för att samla in och kolla upp information. Utformningen av applikationer för handdatorer kräver andra designstrategier än de som används för utformningen av stationära datorer. Idag ser de flesta handdatorer dock ganska snarlika ut men formfaktorn (relationen mellan handdatorns dimensioner; dess bredd, höjd, djup, vikt och konfiguration) kommer förmodligen att öka i takt med att fler produkter kommer ut på marknaden. [32] Det finns framförallt två kända operativsystem för handdatorer; Palm OS och Microsoft Windows CE. Palm OS bygger på ett minimalistiskt tänkande och har endast de absolut nödvändigaste funktionerna. Microsoft Windows CE finns i tre varianter: Pocket PC, Handheld PC och Smart Phone och är alla miniatyrer av operativsystemet Windows. En stor skillnad mellan Palm OS och Windows CE är att Palm inte har något filhanteringssystem, varje applikation håller själv ordning på sina filer. [32] I jämförelse med stationära datorer har handdatorer betydligt mindre skärm, svårare inmatningsmöjligheter, begränsat minnesutrymme och inte lika kraftigt operativsystem. Detta och det faktum att de är bärbara innebär en rad utmaningar, men också möjligheter, för gränssnittsdesignern. [12][32] Liten skärm Gemensamt för alla handhållna datorer är att de har små displayer. Det innebär inte bara nackdelar för den som ska använda dem utan också för designern som ska utforma gränssnittet [32]. Designern måste utnyttja skärmytan på bästa möjliga sätt och samtidigt tillmötesgå kraven på vilken information som användarna behöver komma åt [12]. Varje pixel och varje kvadratmillimeter av skärmen räknas och det kan bli nödvändigt att reducera detaljer såsom ramar och skuggor för att tjäna så mycket utrymme som möjligt [3]. Antalet kontroller som ska visas måste noga övervägas och de bör dessutom vara stora nog så att 19

30 HANDDATORER användaren kan använda sig av fingret för att trycka på dem eftersom den tillhörande pennan lätt kan tappas bort. [28] Skärmens begränsningar resulterar därför ofta i kompromisser mellan informationens tydlighet och navigeringens komplexitet [12]. Det finns två starka krafter som designern måste försöka balansera mellan; den fysiska begränsningen (att designa gränssnittet litet nog att passa in på den lilla skärmen) och den funktionella begränsningen (att designa gränssnittet tillräckligt stort för att kunna visa den information som behövs). [18] Nu för tiden har de flesta handdatorer färgskärm. På grund av det begränsade minnet och det faktum att en handdator har touch screen går dock en viss synlighet förlorad på en sådan skärm. Dessutom ska handdatorn kunna användas i direkt solljus vilket försämrar synligheten ytterligare. [32] Inmatning Ett annat stort problem med handdatorer är inmatning av data. Den vanligaste metoden är att använda sig av en penna. Pennan kan i sin tur användas på lite olika sätt för att skriva in text. Användaren kan antingen fritt skriva anteckningar (sparas som skisser), använda sig av handstilsigenkänning (som känner igen särskilda tecken, bokstäver eller ord) eller använda ett QWERTYtangentbord på skärmen. Tangentbordet anses oavsett storlek vara den lättaste inmatningsmetoden. [32] På grund av svårigheterna med inmatning bör denna begränsas och förenklas i så stor utsträckning som möjligt [12]. Detta kan till exempel göras genom att låta användaren välja mellan olika alternativ istället för att själv skriva in text. För att ha menyer med valbara alternativ som passar in i sammanhanget krävs en god kännedom om arbetssituationen, uppgiften och användaren. Mobilitet Eftersom handdatorer är avsedda för mobilt bruk bör de vara små, väga så lite som möjligt, vara batterisnåla och ruggade samt vara lätta att hålla och använda i en stressig och påfrestande situation [12]. Handdatorer kan också tas med i princip överallt och användas i en mängd olika sammanhang och för en mängd olika uppgifter. Kristoffersen och Ljungberg [19] har tittat närmare på lite olika användningskontexter och har där hittat några gemensamma särdrag som skiljer sig mycket från den traditionella kontorsmiljön. Den mobila användaren arbetar ofta utanför datorn och de primära arbetsuppgifterna är inte beroende av handdatorn. Den typiske kontorsarbetaren jobbar å andra sidan till stor del inuti datorn med att skriva dokument, skicka e-post, göra beräkningar etc. Den mobila användaren använder sina händer för att manipulera fysiska objekt såsom verktyg eller annan utrustning medan kontorsarbetaren oftast har händerna på tangentbordet. Den mobila användaren måste ofta koncentrera sig på saker 20

31 HANDDATORER utanför datorn, kontorsarbetaren kan till större del rikta hela sin visuella uppmärksamhet på dataskärmen. Den mobila användaren förflyttar sig under tiden han jobbar med uppgiften medan kontorsarbetaren oftast genomför uppgiften från en plats. [19] Den mobila och den stationära användningen skiljer sig alltså till stor del från varandra och systemen bör därför inte utformas utifrån samma förutsättningar. Trots det beror de flesta problemen med mobila datorer på att gränssnittet har utformas utifrån samma principer som för stationära datorer. [19] Många designers är inte bekanta med de unika krav som handdatorer ställer och de försöker därför använda stationära metaforer på designen. Att designa applikationer som ska köras på handdatorer är radikalt olikt att utforma applikationer som ska köras på stationära datorer. Anledningarna till det är flera: begränsad skärmyta och minneskapacitet, begränsad uppmärksamhet från användaren och avsaknad av tangentbord. Dessutom sker interaktionen med fingrarna eller med en penna och en applikation för handdator ersätter sällan den stationära datorn så att kunna integrera med den är ofta nödvändig. [28] Trots dessa uppenbara skillnader mellan stationära och mobila datorer vill utvecklare ofta rakt av föra över en applikation från en stationär dator till en bärbar. I de fallen är det ingen bra idé att översätta koden rakt av från ett operativsystem till ett annat. Om programmet ska göras om för att köras på en handdator måste antalet funktioner skäras ner på grund av redan nämnda anledningar. Utvecklaren måste tänka om utifrån användarens perspektiv och endast behålla den viktigaste funktionaliteten. [32] Det är helt enkelt nödvändigt att programmera och skräddarsy ett nytt program för varje unik plattform [12][28]. Om handdatorn ska kunna integreras med en stationär dator (vilket är troligt) är det en bra idé att låta den stationära datorn ta hand om de mer tidskrävande och komplexa uppgifterna [28]. Datorn som arbetsredskap Ett av Coopers [12] främsta tips för design av inbyggda system, såsom applikationer för handdatorer, är att inte tänka på artefakten som en dator. Användarna kommer att ha helt andra förväntningar på produkten, och ofta också ha ganska specifika förväntningar på vad den ska klara av (och inte klara av). Användarna kommer ofta att förvänta sig att direkt och snabbt komma åt den information de vill ha, utan att behöva leta sig fram i ett krångligt filsystem. De flesta sådana system används i en specifik kontext och med ett speciellt syfte och det är viktigt att undvika frestelsen att göra dem allt för generella. Användare tjänar mer på en produkt som hjälper dem att göra en begränsad uppsättning uppgifter mer effektivt, än en produkt som försöker möjliggöra så många uppgifter som möjligt. [12] 21