Brugerinddragelse i webudvikling

Schön beskriver at reflection-in-action ofte opstår når man bliver overrasket, og man derfor må overveje hvad der førte til den uventede begivenhed (altså det man blev overrasket), og hvordan man kan håndtere den.

Dette får os til at lede tankerne hen på æstetisk interaktion, som vi tidligere har arbejdet med. Her gav vi følgende definition på æstetiske oplevelse:

En æstetisk oplevelse
En oplevelse, der påvirker ens sanseapparat udover den sædvanlige perception, og som flytter eller ændrer én som person.

Med andre ord kan/skal en æstetisk oplevelse give førnævnte overraskelse.

Vi må derfor spørge os selv, hvis vi vil designe workshops, der fordrer reflection in action, kan vi så hente inspiration inden for feltet æstetisk interaktion?  Det mener vi bør udforskes yderligere.

I The Inmates Are Runing the Asylum er Coopers to hovedpointer:

• Design før kode
• Find en kvalitetsansvarlig (gerne en interaktionsdesigner)

I de tidligere blog-indlæg, har jeg kort redegjort for de teknikker som Cooper beskriver. I dette indlæg vil jeg diskutere hvorledes vi kan bruge Cooper i vores speciale-projekt.

En ny udviklingsproces?
En af vores kritikke af Participatory Design er, at det er en meget radikal tilgang til design, som kræver at man organisere hele sin udviklingsproces omkring PD. Samme kritik - dog i en noget mindre målestok - kan man anligge på Coopers metode.

Jf. Cooper må man ikke påbegynde programmeringen, før at der foreligge personas med målbeskrivelser, scenarier og design-dokumenter. Hvis vi adopterede denne ide, ville vi bryde med vores indledende ide om, at vi ikke ville ændre i organisationernes eksisterende udviklingspraksis.

Men spørgsmålet er, om ikke denne ide faktisk er selvmodsigende. På den ene side, har vi en klar politisk agenda, hvor vi gerne vil have inddraget brugerne. Men på den anden side, vil vi ikke ændre for meget på organisationens udviklingspraksis. Kan man inddrage brugerne uden at ændre på processen? Jf. Cooper, er dette et klart “Nej”. Spørgsmål er hvad vi siger?

Det nuancerede svar er, at vi blive nødt til at ændre processen, således at brugerne komme med ind i processen. Men vi skal ændre på processen med respekt for udviklingsorganisationens eksisterende proces, deres kontekst og vilkår. Lige som design kan være inspireret af brugerne, så skal vores designet af vores interventioner være inspireret af dem, der skal anvende dem.

Kunde-drevet udvikling
Et af de vilkår som eksistere for mange webudviklingsprojekter er, at de foregår som kunde-drevet udvikling (Cooper 2004, s. 218). For når alt kommer til alt, så er det kunden der betale for gildet. F.eks. kan man høre sælgeren sige, “uden kunder, ingen opgaver”, og så er evt. diskussioner lagt døde. Det er ofte med reference til, at kunden ikke vil betale for design, at designfasen bliver sprunget over eller afkortet.

Eller (med reference til min POPS2 opgave) så bliver projektets scope defineret under tilbudsfasen, og der er design-ressourcerne sparsomme, da man ikke har sikkerhed for, at opgaven går hjem.

Så spørgsmålet er, hvorledes kan man lave en interaktionsdesignfase under disse vilkår?

Min gennemlæsning af Alan Coopers The Inmates Are Running the Asylum er nu overstået. Jeg vil i dette indlæg beskrive de sidste to af Coopers centrale teknikker: Goal-Directed® design og scenarier.

Goal-Directed design
Goal-Directed design er tæt koblet med personas, da man altid tager udgangspunkt i en personas mål. Cooper skelner mellem personlige, virksomhedsmål og praktisk mål (s. 154) (faktisk også falske mål, som er udeladt her).  Personlige mål er simple og universelle, og tager udgangspunkt i den enkelte persona. Copper giver følgende eksempler på personlige mål:

• Not feel stupid
• Not make mistakes
• Get an adequate amount of work done
• Have fun (or at least not to be bored)

Virksomhedens mål er f.eks. at levere overskud eller tilbyde nye produkter og ydelser. Praktiske mål bygger bro mellem virksomhedens objektiver og den enkeltes objektiver, eksempler på praktiske mål er i den forbindelse:

• Avoid meetings
• Handle the client’s demands
• Record the client’s order
• Create a numerical model of the business

Årsagen til at Cooper skelner mellem disse mål type er, at man som interaktionsdesigner må huske på, at de personlige uhåndgribelig mål altid skal sættes over de praktiske må. Hvis et stykke software lade brugeren nå deres praktiske mål, men undervejs i processen kommer i strid med deres personlige mål, så vil det have en negativ effekt på brugeroplevelsen.

Coopers pointe er derfor, at man i sine personas medtager brugerens personlige mål, således at man ikke blindt fokusere på de håndgribelige virksomehedsmål og praktiske mål. Der kommer bedre design ud af at opfylde brugerens personlige mål.

Scenarier
Cooper beskriver hvorledes scenarier kan bruges til at beskrive de opgaver, som de forskellige personas skal udføre med systemet. Lig med method acting skal interaktionsdesigneren forestille sig hvorledes de forskellige personas vil reagere, når de skal løse forskellige forskellige opgaver.

Cooper anbefaler at man skelner mellem dayli-use, neccassary-use og edge-case scenarier. Denne skelnen tillader at man koncentrere sin energi på de scenarier, der kommer til at være brugt i dagligdagen - dette gælder både i scenariet og i designet. De scenarier som bliver kategoriseret som nødvendigt brug, skal også beskrives i nogen deltaljer, men da de er mindre benyttede end dem til dagligdags brug, er de ikke så kritiske. Med hensyn til de specielle edge-cases, så er deres brugsfrekvens så lav, at man ikke behøver at design oplevelsen i nær så høj grad. Det betyder ikke at man skal undlade dem, blot at det ikke er her energien skal bruges. (Cooper 2004, s. 180-181)

Hvad kan vi tage med?
Det tilbageværende spørgsmål som vi kan kan stille os selv, er hvorledes at dette kan bruges i vores speciale projekt.

F.eks. kunne man forestille sig, at vi lavede en persona-mål-opdagnings-workshop? Eller hvad med en scenarie-workshop? Det er bestemt nogle teknikker, som vi kan lade os inspirerer. Og Cooper argumentere i hans bog godt for, at disse teknikker kan gøre en forskel i udviklingsprocessen.

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.

Vi er så småt begyndt at kunne sætte ord på hvad vi gerne vil bidrage med til feltet. Fra Participatory Design har vi følgende værdier:

• Design by doing (Iivari 2004)
• Gensidig læring (Kensing & Bloomberg 1998, s. 172)
• Design er en kreativ proces (Löwgren 1995) - også understøttet af Schön
• Brugerne som designpartnere (Kensing & Bloomberg 1998)

Disse værdier ønsker vi at tage med ind i webudvikling, men vi ønsker at gøre det inden for de rammer som eksistere i dagens webbureauer:

• Tilbudsbaserede projekter -  projektets ramme (funktionalitet og ressourcer) skitseres tidligt i projektet med henblik på at indgå en kontrakt (Grudin 1991)
• Design udføres af en grafiker (egen fordom)
• Sælgeren har primær kundekontakt (egen fordom)

Kort sagt ønsker vi at udvikle PD inspirerede teknikker med respekt for den eksisterende kultur i webbureauet.

Vi har fire primære teoriretninger (indenfor design), som vi ønsker specialet skal tage udgangspunkt i:

• Participatory design
• HCI
• Schöns pragmatisme - Reflection in action
• Virksomhedsteori

Participatory design

Vores baggrund er participatory design, og vi mener grundlæggende at PD har nogle kvaliteter i forhold til innovation og udvikling. Vi anerkender dog også at PD er meget ressourcekrævende (læs dyrt), og at det som sådan ikke er tænkt til en webkontekst. Vi vil således tage udgangspunkt i PD, men tilpasse det til webudviklingsprocesser.

Teoriafsnittet bør behandle:

• Hvad er PD og hvorfor er det godt?
• Hvordan mener PD specifikt at brugerne skal inddrages?
• hvilke teknikker (interventioner) anvendes i PD

HCI

HCI, mere specifikt webusability orienteret HCI, er naturligvis relevant for vores formål.

Teoriafsnittet bør behandle:

• Hvad er HCI (i denne sammenhæng)
• Hvilke evalueringsmetoder findes der til webapplikationer. Og hvad “giver” de?
• Forsøger HCI at involvere brugerne - hvordan?

HCI er iøvrigt et enormt felt. Hvor skal vi starte og slutte?

Schöns pragmatisme - Reflection in action

Schön er ofte citeret i designsammenhænge og reflection in action konceptet må vel siges at være en grundtanke i informationsvidenskab. Derfor er han naturligvis umulig at komme uden om i vores speciale.

Teoriafsnittet bør behandle:

• Hvad er Schöns opfattelse af praksis - reflection og knowing in action.
• Hvad fordrer det for designarbejde?
• Hvilke allerede kendte teknikker forsøger at understøtte dette.

Virksomhedsteori

Virksomhedsteorien er siden midt-80′erne blevet benyttet som et grundlæggende perspektiv på HCI (Berthelsen og Bødker 2003). Motivationen er at du ikke kan nøjes med udelukkende at se på menneske-maskin-interaktionen, men også må inddrage den kontekst det foregår i.

Teoriafsnittet bør behandle:

• Hvordan bidrager virksomhedsteorien til HCI
• Hvordan relaterer det sig til vores egentlige afsnit om HCI
• Hvilke metoder og teknikker forsøger at understøtte virksomhedsteoriens syn på HCI?

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.