Hvorfor Mock-ups?
Mock-ups er gode til at visualisere noget tidligt i design stadiet, og fremmer aktiv involvering af brugerne. Men hvorfor virker de når de er så low tech? De fremmer brugerinvolvering, de er forståelige der er ingen misforståelser mellem den og den rigtige ting, de er billige og sjove at arbejde med.

Vi opfandt det ikke.
Mock-ups er blevet brugt i mange sammenhænge før. Børn har været gode at at lege med mock-ups. De har været brugt i udstillinger hvor produktet ikke er færdigt endnu. Industrielle designere har brugt mock-ups i mange år, specielt til ergonomisk design.
Vores vision er at lave design lege til at forestille sig hvordan arbejds processen kunne være. Vi fokuserer på hardware og software funktionalitet.
Men er mock-ups rigtige design artefakter? Ja det er de, det vil vi argumentere for.

Sprog lege
Vi er ledet af konceptet; hvad et billede beskriver er fastlagt af dets brug. Dette er en holdning af Ludwig Wittgenstein’s Philisophical Investigations (1953). - vi er rådet til at tænke på de sproglege mennesker laver, hvordan vi kan medvirke i menneskelige aktiviteter fordi vi har lært at opføre os i henhold til ikke nedskrevne regler.
Det sværeste med at lege og lave scenarier med en mock-up er at udforme et design sprog som giver mening for alle de involverede. designeren iscenesætter ved at finde og understøtte måder for samarbejde. Fremtids workshops, metaforisk design og organisatoriske design lege er eksempler på hvordan man kan iscenesætte og skabe et fælles sprog. I disse workshops spiller en mock-up en vigtig rolle da man har noget at referere til.

Praktisk erfaring og ready-to-hand brug
Der er mere til mock-ups og sprog lege end bare sprog. Den gør også parktisk erfaring mulig.
Der var et stort breakdown mellem designere og brugere i UTOPIA projektet. Designerne have lavet system beskrivelser men brugerne kunne ikke forstå dem. De mindede ikke brugerne om kendte arbejdssituationer. Derfor lavede de mock-ups af funktionaliteten. Brugerne kunne nu ved hjælp af mock-ups deltage i designet. I starten af en design ide går man ud fra at; i begyndelsen alt had du kan forstå er hvad du allerede har forstået. I dette design paradoks har vi været inspireret af Heidegger, Winograd & Flores, og Dreyfus & Dreyfus. Der bliver snakket om ready-to-hand og present-to-hand da en af typograferne skal afprøve mock-uppen. Den frembrød ingen breakdown i brugerens forståelse, den var ready-to-hand i hans aktivitet. Men da den ikke var det samme som hans traditionelle typografiske værktøjer skete der breakdown i hans readiness-to-hand til at bruge mock-uppen. Han skulle f-eks. bruge en mus i stedet for en kniv.
Praktisk erfaring i bruger involveret design er nødvendigt for at understøtte brugernes ready-to-hand brug af deres fremtidige værktøjer. Altså mock-up er god når brugeren skal være fokuseret på at gøre arbejdet, i stedet for at analysere objekter og relationer.
En design-by-doing sprog leg.

Anden generations mock-ups
Kunne involvere overhætte, slide projekter, båndafspiller, og video.
I den ande mock-up i UTOPIA projektet brugte vi en slide projekter og en skærm til bag skærmsprojektering. Den lignede nu meget mere det endelige produkt. Display interaktionen var simuleret med et slide show og input devices med et rigtigt touch. Denne mockup var specielt god til personer som kun brugte den i kort tid af gangen de og nemt forstille sig hvordan den virkede. Det negative er det dette er dyrere at lave og svære at ændre igen.
Enkle mock-ups: fordele og ulemper
Den er billig og kan hjælpe med at generere nye visioner.
Der er ingen forvirring mellem simulationen og virkelige ting.
Disse mock-ups fører genre til kollaborative modifikationer.
Men de har sine begrænsninger, det kan tage tid at ændre en mock-up, men det betyder også at man skal have en god computer forståelse for at kunne eksperimentere med teknologien.

Computere i mock-ups: overkomme ulemperne
Det samme gælder, kan man visualisere hvad der skal ske. Denne type kaldes storyboard prototyping. Når man går fra mock-ups og storyboards prototypes til rigtige prototypes bliver det muligt at vise rigtige computer funktionaliteter.

Effektive værktøjer
Et eksempel på et computerbaseret hypermedie design miljø kaldet DesignSupport.

At lave passende rigtige begrænsninger
Man skal have et højt kendskab til computere i design gruppen når man arbejder med mock-ups. Ellers kan man ikke komme med passende forslag, hvis ikke må man udforske funktionaliteter på computeren.

Mere funktionalitet
Computere kan bruges til at overkomme mock-uppens utilstrækkelighed. Men prisen er dyr, f.eks. i reduceret brugerinvolvering. Den bedste mock-up er en mellemting mellem pap og computer.

Whats the purpose?
Successfuld evaluering af mock-uppen kræver planlægning og handling, men også forpligtelse fra brugerne. Næsten hver en afvigelse fra det færdige system i en mock-up kræver aktivt arbejde fra brugerne.

Mock-ups; prototype the real thing or both or?
Grunden til at pap mock-ups er så effektive er af igen forveksler dem med det virkelige produkt. Ved brugen af computere er det anderledes. Det kan være svært ikke at mixe computer og mock-up.

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.