Brugerinddragelse i webudvikling

Finn Kensings (med flere) arbejde med MUST metoden, har sigtet imod udforske hvorledes PD kan bruges i en kommerciel sammenhæng. Dette er interessant for os, da dette netop også er vores sigte.

Godt nok har vi i vores problemformulering ikke eksplicit formuleret PD ind i vores undersøgelsesspørgsmål, men PD ligger som vores hovedinspirationsåre. Årsagen til at PD ikke (pt.) er en del af vores undersøgelsesspørgmål er, at vores anvendelsesområde - mindre webudviklingsprojekter - ligger et godt stykke fra “mainstream” PD.

Vi kan bruge Kensing (2003) til i hvert fald 2 ting. For det første placere det os inden for PD-feltet. Vi laver PD inspirerede teknikker i en kommerciel sammenhæng, og derfor kan vi ligger os i forlængelse af Kensings arbejde. For det andet, kan vi lade os inspirere af Kensings erfaringer, og de konkrete teknikker og værktøjer som MUST metoden indeholder.

Etnografisk inspireret
Ved at placere vores arbejde i forlængelse af Kensings, er der dog en del forskelle, som vi bliver nødt til at tage højde for. En af disse forskelle er i hvor høj grad man kan inddrage etnografi i udviklingsprocessen. Kensing argumentere for at inddrage etnografisk inspirerede teknikker: “Kensing and Winograd (1991), Bødker and Kensing (1994), and Simonsen and Kensing (1997) have documented, that it pays to ‘take a deeper look.’ By this we mean that those using traditional methods for IT design tend to rely on what various member of the organization in question present as the problems, instead of investing the time in figuring out what the real needs are.” (Kensing 2003, s. 10)

Det er her at kernen i vores tilgang ligger: Ved at investere mere tid i, at klarlægge hvad der rent faktisk er formålet med websitet eller webapplikationen - set fra bruger perspektiv - bliver resultatet i større overenstemmelse med faktiske brugeres mål. Dette har også genklang i både Coopers (2004) Goal-Directed® design og Garretts (2003) strategy plane.

Kensings vej imod en dybere forståelse af brugerens reelle behov, bygger på etnografisk inspirerede teknikker, dvs. feltarbejde, observation, interview og video-analyse (Kensing 2003, s. 142). I forhold til vores kontekst af mindre webudviklingsprojekter, så er etnografiske undersøgelse problematiske: de tager (lang) tid, de kræver træning og dataene skal bearbejdes til brugbart design-materiale til hele udviklingsteamet.

Spørgsmålet er, om man overhovedet kan få en dybere forståelse af brugernes mål, uden at investere tid og ressourcer?

Men dette må være hovedproblemet i vores speciale projekt: en brugerinformeret kreativ designproces i en kommercielt sammenhæng. Og kommercielt skal i den forbindelse defineres som mindre udviklingsprojekter, baseret på tilbudskontrakter. Hvis man kan lave noget sådant inden for mindre udviklingsprojekter, så har vi virkeligt noget at byde på. Især hvis vi kan udvikle nogle teknikker som kan gøres generelle, således at de kan tages i anvendelse i hvad man kunne kalde almindelige webbureauer.

Igennem læsningen af Cooper (2004) og Garrett (2003) dukker der et centralt spørgsmål til enhver udviklingsproces op: Hvem designer?

Dette kunne lyde som et uskyldigt spørgsmål, men ifølge Cooper og Garretts forståelse af udviklingsprocessen dækker spørgsmålet over årsagen til, at mange websites (og software produkter) bliver dårlige og mindre brugervenlige end vi som brugere egentligt burde acceptere.

En mini-hvem-designer-analyse af en udviklingsproces som jeg typisk møder kunne f.eks. se sådan her ud:

• Kunden og sælgeren/projektlederen fastlægge websites scope (funktionalitet) og i noget omfang informationsarkitekturen.
• Grafikeren udarbejde et layout/brugerflade.
• Udvikleren implementere brugerfladen - og i den forbindelse udfylde han de huller som kunde/sælger og grafikeren har efterladt.

Problemet med denne udviklingsproces er, at alle involverede designer. Da alle involverede er motiverede og pligtopfyldende, føre denne udviklingsproces som regel til udmærkede websites. Men processen lider under den svaghed, at alle involverede skal være lige motiverede og fokuseret på brugeroplevelsen. Når alle designer, så bliver brugeroplevelsen alles ansvar… og derved er der en risiko for, at der ikke er nogle der tager ansvar… overhovedet.

Og endnu engang kan et blog-indlæg afsluttes med et spørgsmål:

Hvorledes kan vores interventioner hjælpe med til at designansvaret placeres (og dermed ansvaret for brugeroplevelsen)?

Der er efterhånden begyndt at dukke nogle ideer op til, hvordan vi kan designe vores interventioner. Vi vil som sagt gerne levere nogle teknikker, som ideelt set kan tages i anvendelse i hvilken som helst udviklingsproces. (Vi husker dog i den forbindelse, at en teknik altid påtvinger brugerene et bestemt perspektiv (Andersen et al. 1986, s. 63)). En indledende formulering af vores interventioner er derfor, at en intervention kunne fokusere på en bestemt del af udviklingsprocessen.

Et arbejdesspørgsmål er i den forbindelse, hvorledes man kan dele udviklingsprocessen op?

Til at svare på dette spørgsmål kan vi f.eks. se hvorledes Cooper ser udviklingsprocessen:

Design -> Program -> Bug test & User test -> Tweak

Yderligere deler Cooper designfasen op i 1) concept, 2) behaivor og 3) interface.

Et andet bud på udviklingsprocessen ser vi i Jesse James Garretts The Elements of the User Experience (2003). Først en illustration af elementerne (den fulde illustration findes her):

Det interessante ved denne model er, at hvert plan bygger på de underliggende planer. Man kan således ikke lave func specs, uden at man har styr på strategien (user needs og site objectives).

Nedenfor ses elementerne sat ind i en proces (kilde):

I alt giver dette os nogle mulige del-processer, som vi kan fokusere den enkelte intervention med:

• Vision
• Strategi
• Funktioner
• Struktur
• Layout
• Test

Andre måde at fokusere interventionerne på
Det var en måde at sætte struktur på vores kommende interventioner, en anden tanke i forbindelse med interventionerne er følgende 3 temaer:

• Ude i felten
• Fokusgruppe lignenden workshops
• Designspil

Indtilvidere er det strøtanker, men mon ikke der er noget at arbejde videre med.

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.