Brugerinddragelse i webudvikling

Den centrale teknik som Cooper beskriver i The Inmates Are Running the Asylum (2004) er personas. Personas er hypotetiske arketyper af rigtige brugere (s. 124). Jf. Cooper har personas følgende fordele:

• Design for én person giver bedre (præcist) design
• Designet fokusere på personaens mål
• Personas sætter en stopper for diskussionen om valg af features
• Personas indeholde mere realistiske beskrivelser af færdigheder

Et af Coopers råd er, at man designer til én primær persona. Gennem et eksempel med et In-flight entertainment (IFE) system, viser Cooper hvorledes at man ved at vælge en primær persona, kan designe et system som kan bruges - effektivt og nydelsesfuldt - af alle brugere (s. 138 ff.).

IFE systemers målgruppe minder på den måde om websites, der netop også har det designproblem, at det skal kunne bruges af “alle”. Som Cooper præcist beskriver, så er design for “alle” dømt til at blive dårligt design for alle. Design for alle mangler præcision, og leder til en designproces der mangler fokus, derved opfylder et program kun alles mål halvt. Ved at designet sigter imod at løse et specifikt problem for en specifik bruger, giver det større mulighed for at det resulterede produkt bliver succesfyldt.

Personas vs. PD
Personas har både ligheder og forskelligheder med Participatory Design. Personas sigter - ligesom PD - mod at lade brugeren komme ind i designprocessen. Gennem kendskab til brugeren og brugerens mål giver det større mulighed for at designe et system, som de faktiske brugere også finder behageligt at benytte.

Men personas og PD har flere forskelle end ligheder. Cooper foretrækker personas frem for rigtige mennesker, da “The other major problem with real users is that, beeing real, they have funny quirks and behavioral anomalies that interfere with the design process.”

PDs værdi om gensidig læring, genfinder man naturligt nok ikke i personas - det er trods alt svært at lære en fiktiv person noget… I udarbejdelsen og brugen af personas, er det kun designere og udviklere der lære om brugerne.

I designet af websites og (IFE systemer) er det også nyttesløst at sigte efter gensidig læring. For hvad skulle nogle enkelte involverede brugeres læring, have af effekt på hele den reelle brugergruppes forståelse og accept af det givne system. Værdien om gensidig læring har således kun værdi, når man kan komme i kontakt med den helt faktiske slut-bruger-gruppe. F.eks. i en virksomhed der skal have implementeret et nyt time-/sags-styringssystem, kan en række brugerrepræsentanter fungere som brohoved for adoptionen af systemet. Det samme gør sig ikke gældende for en række tilfælde website brugere.

Derfor er personas et godt bud på en teknik, når det drejer sig om en større, differentierende, anonym målgruppe. Men vi ser også personas og PD som komplementerende teknikker.

Personas som allestedsværende bruger-repræsentant
I Coopers designpraksis er personas “so important that we cram them down everyones throat”. Dette citat griber fat i en af de problemstillinger som vi i vores interventioner også vil forsøge at løse. Der er ikke meget sjovt i afholde interventioner, hvis ikke interventionens resultater siver ind i den allerede eksisterende designpraksis. Cooper bruger personas i alle interaktioner med ledere, designere og udviklere. Man kan simpelthen ikke have en samtale om programmets udformning eller funktionalitet, uden at det involverer brugen af personas. Personas bliver derved til en fælles referenceramme for alle involverede.

Det kunne derfor være et hint til vores teknikker, at vi skal se, om vi kan finde på noget, der gør, at vores interventioner resultere i noget, der kommer til at indgå i designpraksisen. Eller udtrykt i virksomhedsteoretiske termer, så skal vores teknikker indgår i den kollektive virksomhed.

Jeg er i gang med at læse Alan Coopers The Inmates Are Running the Asylum (2004), bogen er på Informationsvidenskab er mest kendt for sin beskrivelse af personas. Af det jeg har læst indtil videre, så kan jeg se, at vi kan bruge Cooper til at underbygge de pointer, som vi selv har iagttaget i vores professionelle virke.

What does “Done” look like?
Cooper beskriver, hvorledes at softwares uhåndgribelig natur gør det ekstremt svært at vurdere, hvornår et stykke software er færdigt. Cooper bruger følgende lignelse for at illustrere hans pointe: Når man bygger et hus, så har alle involverede en klar ide om, hvad det vil sige, når huset er færdigt. Og man har nogle ret præcise arkitekttegninger til at beskrive hvorledes det færdige hus ser ud. (Cooper 2004, s. 43)

I software forholder det sig anderledes. Jeg kan bedst beskrive det med, at det materiale som man bygge software med, ikke har nogen direkte synlig sammenhæng med det materiale, som man den færdige produkt er udformet i - skærmbilleder. Det er koden der beskrive det færdige stykke software, men det er sjældent ud fra koden, at man vurdere om det software-programmet er færdigt. Dermed ikke sagt at man skal bruge koden til at vurdere færdigheden af et stykke software, det er nemlig lige så ubrugeligt som brugerfladen. Nej, det der er pointen er, at det produkt som øjet ser, ikke nødvendigvis skaber værdi for den endelige bruger.

Most software is designet by accident
En af Coopers hovedpointer er, at interaktionen med software slet ikke bliver designet bevidst (2004, s. 22). Interaktionen med softwaren er et biprodukt af dets produktion, hvis man skal sige det lidt firkantet.

Cooper sammenligner designet af software med designet af ler-hytter. Det karakteristiske ved ler-hytter er, at de bliver designet og bygget af beboerne selv. Coopers pointe med denne sammenligning er, at ledere, grafiske designere og programmøre udarbejder softwarerens brugerflade, sådan som de selv kan lide den. Og endvidere glemmer man, at hver gang at der bliver tilføjet eller fjernet en funktion, så har det indflydelse på den samlede interaktioner.

Dette leder Cooper til at skelne mellem brugerflade-design, og interaktions-design (Cooper 2004, s. 23). Der er således en væsensforskel på at designe den visuelle brugeflade, og designe den samlede interaktion med programmet. Ifølge Cooper leder brugerfladedesign til, at man se kode og brugerflade som to uafhængige dele.

Det er et uomtvisteligt faktum, at koden har indflydelse på de muligheder der er for brugerfladen. Det er derfor at der skal være overenstemmelse mellem koden og brugerfladen, og derfor skal kode og brugerflade ses i sammenhæng: Der er brug for interaktionsdesign.

Jf. Cooper tænker interaktionsdesigneren først det konceptuelle igennem, dernæst programmets opførsel (behavior) og til sidst kommer han til brugerfladen (interface).

Hvad kan vi så tage med?
Interaktionsdesign skal være en bevidst aktivitet - håndteret af en med ansvaret for hele den samlede interaktion.

Dette stiller nogle udfordringer i forhold til vores agenda. Hvis vi gerne vil tage Coopers ide om interaktionsdesign ind i vores teknikker, så skal det ske på en måde, der stadig kan fungere i den organisatoriske virkelighed, som findes i de virksomheder vi kommer ud i. Så spørgsmålet som vi skal tage med er:

Hvordan kan interaktionsdesign indgå i vores interventioner?

Og forøvrigt i forhold til PD
Der er overenstemmelse mellem Coopers tanke om, at man skal se på hele den samlede interaktion, og så vores værdier fra Participatory Design. Vi vil gerne se design som en kreativ proces, der har andre værdier, end at implementere en feature-liste. Og det er blandt andet Coopers pointe: Interaktionsdesign skal levere “power and pleasure to users”.

Vi har i ugens løb arbejdet med at skabe et overblik over vores teori og i forlængelse heraf hvilken litteratur som vi vil bygge vores beskrivelse af disse teori på. Vi har forfinet vores tidligere struktur, således at den generelle HCI del af blevet erstattet med den mere snævre Praktisk web usability.

• Participatory Design
• Virksomhedsteori
• Schön
• Praktisk web usability

Participatory Design
Vi har efterhånden gentaget vores inspiration fra PD nogle gange her på bloggen, men helt kondenseret så handler det for os om, at participatoriske designprocesser har nogle værdier:

• Brugerne som designpartnere
• Designprocessen som kreativ proces (ustruktureret og udforskende)

Virksomhedsteori
Vores brug af virksomhedsteorien er tosiddet. For det første er virksomhedsteorien et bud for en teoretisk framework for HCI (og i mindre grad PD). Og netop derfor, vil vi for det andet bruge virksomhedsteorien som teoretisk forståelsesramme for den virkelighed som vi kommer og iagttager - både mht. interviews og vores egne interventioner.

Yderligere har virksomhedsteorien bidraget med ideen om designartefakter, som bliver interessant for os, når vi skal til at overveje hvorledes interventionernes data (findings) skal indgå i den videre desigproces.

Schön
Vi vil supplere virksomhedsteorien med Schöns pragmatiske syn på designarbejdet. Vi er enige med Schön i hans syn på den reflektive praktiker, hvor at praksis ikke blot er udøvelse af teori. Vi vil således basere vores interventioner på, at den faktiske praksis er en syntese af teori og intuition og reflektioner (knowing-in-action, reflection-in-action og reflection on action).

Praktisk web usability
Da vores formål er at bringe PD inspirerede teknikker ind i webudvikling, vil vi også basere vores teknikker på en forståelse af den eksisterende litteratur inden for web usability. F.eks. vil vi basere os på Mike Kuniavskys Oberserving the User Experience  og Jesse James Garretts Elements of the User Experience. Vi mener at disse to bøger repræsentere en hovedstrøm inden for praktisk web usability (måske især i USA). Og de kan således tilføre en modvægt til den marxistisk inspirerede PD tradition.

Som nævnt bruger vi denne uge på at (forsøge at) danne os et overblik over hvilken teori vi vil anvende i specialet. Som mange andre specialestuderende sikkert har fundet ud af før os, finder vi mindst 3 spændende nye artikler for hver artikel vi kommer igennem. Ligesom de mange tanker om teori konstant leder os på nye spor og teorier om design.

Vi har derfor brugt lidt tid på at overveje hvordan vi forestiller os teori afsnittet skal bygges op. Indledningsvist kan vi slå fast at teorien kan indeles i to overordnede kategorier: teorier om hvad design er, hvordan det fungerer i en kontekst osv. F.eks. Virksomhedsteori og pragmatisme. Og mere konkrete designmetoder, som f.eks. contextual design, PD og et væld af underliggende metodikker.

Endvidere må vi overveje hvorvidt vi skal afsøge litteraturen for eksisterende bud på hvordan man kan lave brugerinddragelse i webudvikling. Dette synes i sig selv nokmateriale til et speciale i sig selv.

Vores foreløbige svar er, at vores udgangspunkt er participatory design, og det er derfor på denne baggrund vi vil udvikle interventioner til brugerindragelse. Derfor beskæftiger vi os med teorier som lægger sig op ad, eller udgør en del af fundamentet for participatory design.

I dag har vi påbegyndt vores arbejde med specialets teoretiske fundament. Vi har sådan set bare gået i gang der hvor vi havde lyst og vi syntes at der var noget interessant. Vi er således gået i gang med at se på Schöns tilgang til design og Participatory Design.

For begges vedkommende gælder det, at de er i deres indledende stadier. De spørgsmål som vi arbejder ud fra er:

• Hvad er det der definere den pågældende teoriretning?
• Hvordan passer den ind i det, vi har tænkt os i vores speciale?

I forhold til PD er det definerende, at PD teknikker og værktøjer er målrettet imod at forbinde designere og brugere, således at der opstår gensidig læring: Designere opnår kendskab om brugernes arbejdspraksis og brugerne opnår kendskab til den nye teknologis muligheder (Kensing & Blomberg 1998). Præcist hvorledes vi vil bruge dette i vores speciale, det står således åbent pt.