The design of everyday things. Rune Simensen, 04hbmeda Ergonomi i digitale medier Høgskolen i Gjøvik, høsten 2005

Transkript

1 Rune Simensen, 04hbmeda Ergonomi i digitale medier Høgskolen i Gjøvik, høsten 2005

2

3 Innledning Jeg vil her ta for meg Donald A. Normans bok The design of everyday things (2002). Etter et fortellende resymé vil jeg ta for meg en del av de mest sentrale begreper, slik jeg oppfatter dem. Hensikten er å prøve å formidle min oppfatning om hva dette kan ha å si for oss som designere av grafiske brukergrensesnitt. Jeg vil også tilslutt gi mitt syn på boka. er en nyutgivelse av en bok som ble publisert i 1988 under tittelen The psychology of everyday things. Begge utgavene er gitt ut av Basic Books, New York. Dette skal ikke være en bedømmelse av bokens typografi, men jeg finner det likevel nødvendig å nevne dette: noen steder finner vi uthevet tekst plassert til høyre i spalten, som kapitteltitlene, men med mindre skrift enn disse. De kan likne på avsnittstitler og virker noe forvirrende på leseren. Boka er delt inn i syv kapitler, hver med sitt emne innen designstudie- og utførelse. I tillegg finnes forord både til den opprinnelige utgaven av boka og til 2002-utgaven. Til sist 4 kapitler med hhv. noter, anbefalt lesning, referanser og indeks. Resymè Norman begynner rett på sak i kapittel 1 hvor han forklarer oss hvorfor mennesker gjør feil i forsøk på å benytte de enkleste innretninger i våre omgivelser. Gjennom eksempler får vi demonstrert hvor galt ting kan gå om estetikken settes foran brukervennligheten. Det blir også understreket at når vi ikke greier å stille inn vårt nye digitale armbåndsur eller å sette på vaskemaskinen så er det egentlig ikke vår feil. Det er designet som ikke holder mål. Norman presenterer en del viktige uttrykk som representerer sider ved design som er helt sentrale og avgjørende for vår forståelse om bruken av forskjellige gjenstander og systemer. Han bruker uttrykket affordance. Det kan kanskje oversettes til noe sånt som hvordan ting «tilbyr» seg å bli brukt. For eksempel en stol - den tilbyr seg å bli sittet på, en knapp tilbyr seg å bli trykket på. Visibility, synlighet, er et annet begrep. Vi må kunne se hva som kan benyttes til å operere en innretning korrekt. For å sikre seg at en innretning ikke kan opereres feil, kan man benytte constraints, begrensninger, slik at feiloperasjon blir umuliggjort. For å gjøre tingene enda enklere for brukerne bør man i størst mulig grad benytte prinsippet om mapping, i denne sammenhengen betyr det noe i retning av sammenheng mellom plassering og bevegelse av kontrollorgan og resultatet. 45

4 Når man tar det inn i designprosessen kan man lettere vise oss som brukere hvordan vi skal forholde oss. For gjenstander som er forholdsvis enkle i oppbygning kan vi danne oss det Norman kaller conseptual models, konseptuelle modeller, det er bilder vi danner oss om bruken av en eller annen gjenstand ut fra det vi ser av oppbygningen. Vi tenker oss altså virkemåten ut ifra det vi ser og det vi har av erfaringer. Dette kan være farlig fordi ofte har vi bare småbiter av informasjon å bygge våre antagelser på, men mennesket er slik av natur. Det sier seg selv at når man må anta hvordan man skal betjene panelet i en atomreaktor ut fra fragmentariske opplysninger så kan ting gå fryktelig galt. (Norman nevner atomulykken på Three Mile Island som et «klassisk» eksempel.) Et annet begrep Norman fremhever som meget viktig er feedback, altså tilbakemelding. Når man har utført en eller annen operasjon må man få en øyeblikkelig tilbakemelding slik at man vet hvilket resultat man har fått. Hvis ikke tilbakemeldingen fungerer kan man på ingen måte vite om det man har gjort gir de ønskede resultater. Sett for eksempel at når du setter på blinklyset i bilen for å svinge, og ingen lampe på dashbordet forteller deg at blinklyset er på, eller ingen lyd høres. Hvordan kan du da vite at blinklyset er på når du har passert krysset. Som regel glemmer man at man har satt på blinklyset (jeg vet at det pleier å slå seg av selv, men ikke alltid) og man kan bli utsatt for merkelige situasjoner om man kjører gjennom byen med blinklyset på. Det kan til og med være trafikkfarlig. Norman tar også for seg litt om hukommelsens oppbygging, og kanskje viktigst, hukommelsens begrensninger. Det er to grunnleggende begreper som blir lagt frem for oss; knowledge in the head og knowledge in the world. For oss som designere er dette helt essensielt for å gjøre en god jobb. Knowledge in the head (kunnskap i hodet) betegner de opplysningene vi må ha i hodet, altså det vi må huske, for å kunne utføre en operasjon. Knowledge in the world (kunnskap i verden) er de opplysningene vi kan finne ved å se og dermed kunne oppfatte hvilke tiltak som må til for å utføre ønsket operasjon. Som eksempel kan jeg nevne Microsoft Windows som et forsøk på å legge kunnskapen ut i verden i stedet for i hodet. Det samme gjelder bilens mange kontroller. Knappene er for det meste angitt ved navn (står det lys på en knapp så vet vi at ved å betjene den skrur vi på et eller annet lys). Da har man flyttet kunnskapen ut i verden og vi slipper å huske alle de forskjellige tingene. Dette er helt essensielt for å lette bruken av alle slags innretninger. Viktig å merke seg er at valget om kunnskap i hodet eller kunnskap i verden blir en avveining man må ta under designprosessen fordi man ikke kan få all kunnskapen samlet i «verden», 46

5 man må kunne kombinere dette med kunnskap i hodet. Det er som oftest ikke plass til alle opplysninger om en prosess på en merkelapp ved siden av en bryter eksempelvis. De to faktorene har hver sine fordeler og ulemper, og den ene går på bekostning av den andre. At det er menneskelig å feile vet vi alle. Norman forteller oss noen av grunnene, og hvorfor vi designmessig må ta stilling til dette. Mulighetene for feil bruk, eller feiloperasjon må elimineres. Eller i det minste må mulighetene for feil reduseres til et minimum, og mulighetene for å gå tilbake i det man blir oppmerksom på feilen må være tilstede. For eksempel når man er i et grafisk brukergrensesnitt som Windows og man vil slette en fil, får man spørsmål om man virkelig vil slette denne filen. Er det spørsmålet da relevant? Man har bedt om at filen slettes. Selvfølgelig kan man ha kommet til å klikke på feil valg, men en bedre løsning hadde kanskje vært å utelate spørsmålet om man virkelig ville slette filen. Den ligger jo i søppelbøtta likevel, og kan hentes der om man finner ut at man ikke skulle slettet den likevel. Så kunne man jo heller støttet seg på en sikkerhetsmelding ekstra når søppelbøtta skulle tømmes. Det siste kapitlet i boka, kapittel 7, er på en måte et sammendrag, et forsøk på å neste sammen trådene og framstille det hele i en sammenheng for å gjøre det hele klarere. Norman påpeker at brukeren må settes i sentrum ved en designoppgave. Begrepet user centered design er det overordnede grunnlag for alle sider ved utvikling av både de hverdagslige tingene vi omgir oss med på kjøkkenet, i garasjen, på badet osv, og de mer spesielle ting for begrenset bruk. Det innebærer rett og slett at vi må sette brukeren i sentrum og se designet ut ifra hans posisjon. Vi må altså utvikle for en spesiell bruker. Avslutningsvis får vi servert en rekke gode råd basert på det presenterte materialet. Sentrale begreper Jeg siterer her fra boka (s. 188) syv prinsipper for design (oversatt av meg): 1: Benytt både kunnskap i hodet og kunnskap i verden. 2: Forenkle oppgavene mest mulig. 3: Gjør ting synlige. 4: Sørg for at mappingen er mest mulig innlysende. 5: Utnytt fordelene av constraints mest mulig, både naturlige og konstruerte. 6: Gå ut fra at feil blir gjort. 7: Som siste utvei, standardiser. 47

6 Kunnskap i hodet eller i verden. Dette vil ofte være et spørsmål om estetikk og oversiktlighet. Norman sier at vi ikke kan få begge deler. Vi må velge om vi vil ha kunnskapene her eller der, og at det ene går på bekostning av det andre. Det er i grunn innlysende. Han nevner bilradioen sin som har mange flere funksjoner enn knapper. Rett og slett fordi det ikke er plass til en knapp for hver funksjon, og heller ingen etikett som forteller hva som finnes tilgjengelig på hver knapp. Da må man ta i bruk kunnskap i hodet for å kunne utnytte alle funksjonene man vil ha plass til. Utfordringen da blir jo å samle funksjonene som logisk hører sammen under hver knapp, og samtidig fortelle brukeren hvilken funksjon som til enhver tid er aktiv. I et grafisk brukergrensesnitt er dette utnyttet i veldig stor grad (og mer eller mindre vellykket). Man har menylinje hvor valgene er gruppert under overordnede valg. Man får da via det overordnede valget et hint om hva som befinner seg i menyen, men man må likevel huske hva som befinner seg i undermenyen. F.eks. under menyen fil kan vi anta at valg som angår lagring, sletting osv befinner seg. Men hva med menyvalget verktøy? Da blir det noe vanskeligere fordi det vil variere med typen program det finnes i. I et program som f.eks. Word 2003 (som dette essayet er skrevet i) finnes det ca kommandoer og 23 verktøylinjer. Dette stiller strenge krav til logisk gruppering og til balansering mellom kunnskap i hodet og kunnskap i verden. Et annet spørsmål er om man virkelig trenger alle disse valgene. Hvilke blir brukt i vanlige situasjoner? Bør man dele det opp slik at programmet kan stilles inn for «hverdagsbrukere» og «ekspertbrukere»? For å besvare det må man trekke inn brukere eller personas (som ikke er nevnt i Normans bok, antagelig fordi det er en nyere innovasjon) og foreta en analyse. Det finnes ingen snarveier. Poenget er at det må nødvendigvis bli mye kunnskap i hodet fordi det ikke er plass til å legge dem ut i verden. Da vil man ikke få plass til selve arbeidsområdet. Forenkling av oppgaver Når beslutninger skal tas vil man ha et antall valg man må gjøre for å komme fram til det ønskede mål. Norman kaller dette the structure of tasks (oppgavenes struktur (s. 119)). Hvis man gjennom flere trinn skal fullføre en gitt oppgave via valg vil man i mange tilfeller ha mange valg som blir uaktuelle på grunn av foregående valg. Når det gjelder valg i den gammeldagse, analoge verden hvor man kan velge seg gjennom en liste har man ikke så mange muligheter, 48

7 men når det gjelder et grafisk brukergrensesnitt kan man med få anstrengelser allerede på planleggingsstadiet bestemme seg for å gjøre operasjonene oppgavestyrt. Det innebærer at man kan velge oppgaven man vil utføre og at menyvalg (valgtrær) blir avpasset etter oppgaven, også dynamisk, slik at valg som blir uaktuelle under prosessen ikke lenger er synlige for brukeren. Det samme kan også gjøres for brukerens nivå, slik at man kan velge sitt «ferdighetsnivå» og programmet viser da et utvalg av menyer, valg og opsjoner som er tilpasset nivået. På den måten kan man forenkle brukergrensesnittet og lette den mentale belastningen på brukeren. En annen side ved valg er at man kan komme til å velge feil. Det er en helt vanlig situasjon, men innebærer ofte stor irritasjon og kanskje merarbeid for brukeren. Ved å først redusere antallet valg til kun det som er relevant for oppgaven og deretter gjøre prosessen reversibel slik at man kan kunne gjøre feil uten å måtte gå gjennom hele prosedyren på ny er helt avgjørende for brukerens oppfatning av brukervennligheten. Synliggjøring Det er hva Norman kaller The gulfs of execution and evaluation. The gulf of execution er forskjellen mellom oppgaven som skal utføres og hva man må gjøre for å komme dit. The gulf of evaluation er forskjellen mellom representasjonen av systemets tilstand og brukerens oppfatning av opplysningene. For å gjøre avstandene minst mulig i disse to begrepene (gulf of execution og gulf of evaluation) må man sørge for at brukeren blir gitt tilstrekkelige og tydelige opplysninger. Hvis man for eksempel har som hensikt å lagre et dokument fra sin tekstbehandler er man ikke så veldig interessert i hvor det blir lagret eller hvordan det blir gjort. Man vil gi det et gjenkjennelig navn, lagre det og deretter være i stand til å finne det igjen. Brukeren er sjelden spesielt interessert i harddiskens mappestruktur eller operativsystemets interne filnavn. Likevel må vi forholde oss til dette. En slik prosedyre er med på å gjøre gulf of execution større. Hadde man helt enkelt kunne bedt programmet om å lagre, fått presentert en boks hvor ønsket dokumentnavn skulle skrives, evt. med forslag utfra avsnittstittel eller lignende og deretter en beskjed om at dokumentet var lagret (feedback) under angitt navn ville man ha redusert the gulfs of execution and evaluation til et minimum. I hvertfall i denne spesifikke prosedyren. Imidlertid må man da være sikker på at man finner dokumentet igjen uten å måtte grave dypt i kryptiske mappestrukturer med uforståelige navn. 49

8 Click finish to begin? PCWorld norge, 2005 Mapping En logisk sammenheng mellom kontroller og kontrollert enhet er viktig for å forbedre brukervennligheten av gjenstander, maskiner osv. Jfr. Normans komfyr på sidene Når det gjelder et grafisk brukergrensesnitt blir tingene litt vanskeligere. Det er ikke uten videre gitt hvor knappen som sier «Lagre» skal plasseres for å gi brukeren en logisk oppfatning av sammenhengen. Man må altså forsøke å overføre den analoge verdenens logikk til den digitale, virtuelle verdenen. En måte dette er gjort på kan vi se i programmenes menylinje hvor man har forsøkt å samle valg som mer eller mindre naturlig hører sammen, under samme menyvalg. Men det er vanskelig å bestemme hva som er naturlig mapping i et grafisk brukergrensesnitt fordi et grafisk brukergrensesnitt kan knappest betegnes som noe naturlig. For de aller fleste av oss er dette en fremmed og litt fiendtlig verden. Vi er ikke vant til å bevege oss i virtuelle rom lik grafiske brukergrensesnitt. Likevel er det enkelte ting man bør unngå(se illustrasjon). Constraints Begrensninger er metoder for å unngå feil bruk, feil operasjon og ellers tiltak for å redusere muligheten for feil. At mennesket gjør feil er en akseptert sannhet. Norman nevner disketten som et ypperlig eksempel på godt design hvor begrensninger er innebygd. Selve disketten er ganske elegant, den er utformet slik at man ikke kan benytte den feil og den gir selv beskjed om man prøver å benytte den feil (den passer ikke). Skal man kunne forsikre seg mot feil i et brukergrensesnitt må man sørge for at brukeren får tydelig beskjed om hva et aktuelt valg innebærer. Men det alene sikrer ikke mot feil. Den eneste måten å sikre seg fullstendig mot feil på er å gjøre valg som kan være skadelige, utilgjengelige. Men det er kanskje ikke så lurt. Sett at vi lager et brukergrensesnitt til en tekstbehandler. 50

9 I vår iver etter å benytte constraints gjør vi det sånn at under menyvalget fil er valget slett utilgjengelig hvis vårt dokument ikke er lagret, nettopp for å unngå utilsiktet sletting. Det syntes som en god ide når vi utviklet programmet. Det vi ikke tenkte på var at brukeren kanskje kom i den situasjonen at han ville forkaste hele dokumentet og begynne på nytt. Da vil han bli nødt til å lagre sitt dokument først, for deretter å slette det. Da har vi bommet på målet. Da er det bedre å bygge inn en reversibel prosess som gjør gjenoppretting problemfritt og enkelt. Gå ut fra at feil blir gjort Uansett hvordan man forsøker å hindre feil, enten ved hjelp av begrensninger, tydelig og logisk mapping, forenkling eller tydeliggjøring, så vil feil bli gjort. Vi mennesker blir lett distrahert, vi greier ikke å huske mer enn noen få ting av gangen og en prosedyre kan lett spore av med en liten katastrofe som resultat. Har man imidlertid tatt høyde for dette i designprosessen kan skadene minimaliseres eller kanskje også være fullstendig opprettelige. Et eksempel kan være det som Norman nevnte med en søppelbøtte for hver dag. Det betyr at man har en uke på seg til å gjenopprette skaden som er oppstått fordi man kastet feil papirer. Det samme kan overføres til et grafisk brukergrensesnitt. Vi kjenner alle papirkurven i windows som er en metafor for nettopp papirkurven på kontoret. Her er det tatt høyde for utilsiktet sletting av dokumenter. Når vi er blitt klar over at vi har slettet feil dokument kan vi kikke i vår virtuelle papirkurv og finne det igjen, hvis vi ikke har tømt papirkurven i mellomtiden. Da er det ugjenkallelig fjernet. Men det finnes andre prosedyrer som kan gi feil. Det være seg overføringer i nettbank eller andre prosedyrer som ligger utenfor ens egen domene så å si. Der hvor man ikke kan manuelt gå inn og rette opp eventuelle feil. I slike tilfeller er det av største viktighet at de opplysninger man gir kan verifiseres og bekreftes før en endelig transaksjon finner sted, og man må ha muligheten til å «rulle tilbake» i de tilfeller man finner feil. Men det stopper ikke der. Selv om vi korrigerer og bekrefter kan feil likevel snike seg med. Man må altså likevel kunne søke opp eller kontakte adressaten for korrigerin Men ved å bygge inn reversible valg og bekreftende sluttvalg kan man redusere faren for feil. Standardiser når alt annet går feil Når man ikke kommer utenom det Norman kaller tilfeldig mapping og andre vanskeligheter kan vi ty til standardisering. 51

10 Det er ikke en ønskesituasjon fordi prosedyrer kan da bli ganske ulogiske og vanskelige. En fordel er imidlertid at man trenger kun å lære det en gang. Men skal man standardisere så må man gjøre det snarest mulig, men ikke før man får tatt høyde for nyere teknologi og andre prosedyrer. Standardisering er allerede i utstrakt bruk i grafiske brukergrensesnitt. Det viser menylinjen øverst i skjermbildet. Alle programmer har noen felles menyvalg hvor man finner valgene som er standard. Det hjelper oss brukere å huske hvilken meny vi skal klikke på for å lagre eller for å skrive ut osv. Fordi at det er vanskelig å finne noen annen logisk og brukervennlig måte å fortelle brukeren hvordan han skal forholde seg for å få utført sin oppgave har man her måttet ty til siste utvei. Min mening Boka the design of everyday things er etter min ringe mening en helt ypperlig bok for den som vil lære litt om design. Den gir innsyn i grunnlaget for godt design og innsyn i hvorfor det er nødvendig å designe selv de mest elementære gjenstander. Norman gir oss lettfattelige eksempler som kan overføres til andre situasjoner og som gir oss pekepinner om hvordan det bør gjøres. Absolutt valuta for pengene. Referanser Norman, Donald A, 2002:, Basic Books, New York. PC World Norge, 2005 nr 15, IDG Magazines Norge AS 52