Noter til Design in Action

01mar08

System design and user involvement

Når man designer computersystemer er det viktig med en aktiv og direkte involvering av brukere. For å finne ut hvordan computerapplikasjonen fungerer i en brukssituasjon, så må brukerne ha mulighet til å prøve det ut (experience it). Dette kalles envisionment.

Prototyper er meget nyttig for å finne uuttalte aspekter i brukeres arbeide, og for å få brukerne til å bidra til design av verktøy. I envisionment, er breakdowns noe som kan lede til endring av prototypen, og dermed muligens endre den fremtidige applikasjonen.

Different approaches to prototyping

Tre kategorier innenfor prototyping:

• The prototype becomes the system approaches. –> supplerer en tradisjonell kravspesifikasjon med en prototype av brukerinterface aspekter, før implementasjonen starter. Primært for å få brukere til å justere detaljer i systemet. brukt primært til å demonstrere features, og ikke å la brukere prøve dem ut aktivt.

• Executable specification approaches. –> oppnå en full, formel spesifikasjon av hva det fremtidige system skal inneholde. Skrevet på et formelt språk som brukerne ikke forstår.

• Exploratory approaches. –> mock-ups, simuleringer og ”trow away” prototype utvikles. Målet er å lage “quick-and-dirty” sketsjer, for å klargjøre krav til det nye systemet. Men her er det ikke ofte brukerne blir involvert.

Cooperative prototyping to simulate user participation and creativity

De tradisjonelle metodene (beskrevet over) tar lite hensyn til brukerinvolvering. Derfor introduseres en annerledes metode: cooperative prototyping. Den har røtter i de nevnte metoder, men her vil de demonstrere at prototyping kan være en samarbeidsaktivitet mellom brukere og designere. Cooperative prototyping har som mål å etablere en designprosess hvor både brukere og designere deltar aktivt og kreativt ut ifra dere forskjellige kvalifikasjoner. Brukernes ferdigheter må bringes i kontakt med nye tekniske muligheter. Dette kan gjøres i en simulert fremtidig arbeidsituasjon eller i en virkelig brukssituasjon. Når breakdows forkommer, kan brukere og designere analysere situasjonen, for å finne ut om grunnen er en dårlig/ufullstendig designløsning, eller om det er andre grunner. For at brukerne skal kunne få full erfaring med prototypen, er det viktig at de får utprøve den over et stykke tid.

Examples of Cooperative Prototyping

Det presenteres to eksempler med bruk av cooperative prototyping:

Prototyping of graphic user interfaces

Her brukte de HyperCard på en Macintosh.

Dette eksempel går ut på å utvikle en prototype for pasientsystem på en tannlegeklinikk.

Før prototype-session ble det designet en initial prototype. Session startet med en demonstrasjon av denne for tannlegeassistentene. Deretter ble tannlegeassistentene delt inn i grupper på 2-4 personer. De fikk beskjed om at dette var en fleksibel prototype som kunne endres som man ville. Designeren holdt seg litt i bakgrunnen for å la tannlegeassistentene utforske prototypen og prøve den ut mens de så for seg at de utførte sine daglige oppgaver. Designer brøt kun inn ved breakdown situasjoner.

De fikk flere systemforbedringer ut av denne session, som ble gjort underveis i session. det var også noen forbedringer som krevde litt programmering, da merket de at tannlegeassistentene ble utålmodig fordi de ikke forsto hva som foregikk. Det var også noen forbedringsforslag som ikke kunne gjøres undervei i session, fordi det var store endringer/ tok for lang tid.

Det var en utfordring å skulle bryte inn i session for å endre prototypen underveis, og deretter fortsette evalueringsprosessen.

Dette eksempel viser at, hvis man gir dem en sjanse, er det mulig for en gruppe arbeidere, å komme opp med konstruktiv og kreative bidrag til designet av deres computerapplikasjoner.

Videre viser også eksempelet at det ikke er nødvendig å ha en ferdig utviklet prototype før den skal brukes, man kan endre den underveis.

Prototyping in an organizational setting

Her ble 4. generasjonssystemet ORACLE brukt.

Det arbeides med administrasjonen på en dansk trade school, og dette eksempel tar for seg en del av dette, en prosjektgruppe som arbeider med lagring (gemming) og gjenfinning. Deres oppgaver var å organisere skolens filer så det ble mer effektivt, og til sist i form av en computerapplikasjon.

Konsulentene/spesialistene starter med å intervjue deltagerne og observere deres arbeid. Deretter samles gruppen, og etter innledende diskusjoner, ble tre alternativer til måter å arkivere filene på, foreslått. Det ble laget scenarioer for hvert alternativ. De fikk inspirasjon ved å besøke andre arbeidsplasser.

Etter dette, ble en innledende papir-basert sekvens av skjermbildesimuleringer, diskutert i gruppen. Denne mock-up’en illustrerte én av de tre alternativene.

På basis av disse diskusjoner, bygget konsulentene/spesialistene den første prototypen. Etter hvert som man fikk en mer stabil versjon av prototypen, ble den også brukt i den virkelige arbeidssettingen. Men dette kunne ikke programmeres direkte i ORACLE, de ble nødt å bruke Pascal til å programmere i. I neste steg, når prototypen skulle utvides, ble man nødt å omstrukturere hele databasen, og kaste vekk hele den tidligere prototypen. (Styrelsen forsto ikke poenget med dette, og insisterte på å bruke den prototypen som var. Det fungerte selvfølgelig ikke.)

I noen uker ble (den nye) prototypen brukt daglig, under oppsyn av konsulentene/spesialistene. De hjalp til når det forekom breakdowns.

Ved å integrere prototypene inn i organisasjonens setting, ble det mulig å fokusere både på individuell bruk og på samarbeid mellom folk. Dette eksempel viste at samarbeids issues og det å kjøre prototyper direkte i organisasjonen, var viktig i forhold til en cooperative designprosess.

How to get going with cooperative prototyping

Det er avgjørende for arbeidsgruppen å etablere en felles forståelse for prosessens mål, status til produkter utviklet underveis i prosessen, og rollen til prototyping overordnet i designprosessen. Videre, må man nødvendigvis håndtere noen organisasjonsproblemer, for å etablere en basis for å utføre cooperativ prototyping i et spesifikt prosjekt.

Establishing project groups: making a workable group versus involving a large user group.

Det er mye man skal tenke på når man skal etablere en kompetent gruppe med brukere I design/prototype aktiviteter. Man vil gjerne ha mange ulike typer brukere, men det skal heller ikke være for mange. Det viktigste er å etablere en arbeidsgruppe sammen med kompetente brukerrepresentanter. Det er også viktig et designerne og brukerne blir godt kjent men hverandre for at de skal kunne samarbeide godt, og alle skal ha mulighet til å bidra. Samarbeide er viktig for å vedlikeholde den kontinuerlige læringsprosessen mellom brukere og systemutviklere.

Prototyping er en læringsprosess, og generelt er prototyper en god måte å opplære fremtidige brukere på.

En god ide dersom det er en stor organisasjon er å starte i en del av organisasjonen, deretter bringe denne prototype videre til en annen del som bidrar på den, og så til en neste del etc.

Setting up prototyping sessions: designers as conductors versus users being in charge

Brukerne bør ha mulighet til å utprøve prototypen over lenger tid, og designerne kan så bidra dersom breakdows oppstår. Det er designerne som vet hvordan prosessen bør settes opp, men det er viktig at prosessen tilrettelegges i forhold til brukernes behov og ønsker.

Providing prototypes: showing fantasy versus being limited by the tools

Dersom dårlige prototyper presenters for brukerne, er det selvfølgelig en fare for å miste poenget, men man kan si at et dårlig eksempel er bedre enn ingen eksempel, hvis prototypens status blir gjort klar. Manglene med en prototype kan kompenseres med en god forklaring av dem.

Det finnes en rekke verktøy man kan bruke i forbindelse med cooperativ prototyping. F.eks. Smalltalk, LISP verktøy, HyperCard.

Alternativer kan være gode å ha, de kan stimulere til brukernes fantasi og dermed oppfordre gruppen til å diskutere forskjellige måter å organisere arbeidet. En måte å få brukerne til å foreslå alternativer, er å illustrere hvor enkelt man kan endre på prototypen.

Maintaining communication: describing requirements versus experiencing work

Designere bør måske studere brukernes arbeide mer nøye og diskutere med dem videre, før forslag kan forstås. Det er viktig å huske at brukerne er nøkkelen til design av et brukbart system og designerne er nøkkelen til å fremme brukernes krav i det tekniske designet av systemet. Det utfordrende ved design av en applikasjon, kan være å finne balansen mellom at den skal være nyttig for brukerne og ha en høy teknisk kvalitet sett fra et teknisk synspunkt.

Users perception of the process: realistic prototypes versus unrealistic expectations

Prototypene skal være realistisk og stabile nok for at brukerne kan styre evalueringen. Men det er også viktig å fra starten av, gjøre oppmerksom på at prototypene bare er grove skisser. Prototyper kan skape blindhet omkring at det kan være andre måter å løse problemene på.

Maintaining focus: A technical versus a work-oriented focus

Kunnskap om domenet er avgjørende!

Diskusjon i en prototypesession foregår ofte rundt interaksjonen med computeren, og ikke om hvordan arbeidet i organisasjonen rundt computeren er. Det er viktig å ikke få for teknisk fokus.

Getting resouces: adding more resources to early activities versus lowering development costs

Det som muligens krever mest resurser er deltagelse fra flere brukere. De dyreste feil eller mangler i et system er de som gjøres i de tidlige fasene, hvor fokus er på analyse og design. Cooperative prototyping kan hjelpe til å forutse noen av de dyre feiltrinnene, og mest sannsynlig redusere utviklingskostnadene.

Design as an ongoing process

Cooperativ prototyping kan brukes for å bedre kvaliteten til computersystemer sett fra brukeren synspunkt, dvs brukerne kan få et system som er mer tilpasset deres behov og kan bedre kvaliteten på deres arbeide. Design er en løpende prosess. Cooperativ prototyping skal ikke ses på som en tilgang til å produsere det ultimate computersystem for et applikasjonsdomene. Det bør heller ses på som en av de første stegene i den løpende utviklingsprosessen.

Filed under: Noter: uge 5   |  Leave a Comment