Brugerinddragelse i webudvikling

Vi har som et led i vores forberedelse af interviewguide til vores første interview diskuteret hvad vores grundlæggende hypoteser om årsagen til at brugerinddragelse ikke er udbredt i mindre og mellemstore webudviklingsprojekter.

• Mangel på brugerinddragelseskompetencer i virksomhederne
• Eksisterende metoder (og delvist teknikker) fokuserer på større projekter
• Kunderne vil vide hvad de køber

Mangel på brugerinddragelseskompetencer i virksomhederne
Det er ikke mangel på vilje, men mangel på kompetencer, der forhindrer brugerinddragelse i webprojekter.

Det er vores indtryk, at det som sådan ikke er mangel på vilje, der forhindrer at brugerne inddrages i små og mellemstore webprojekter. Det er snarere en manglende viden om hvordan brugerinddragelse kan eksekveres i praksis, inden for de rammer, der stilles i et sådant webprojekt. Selvom organisationen gerne vil arbejde seriøst med brugerindragelse, er det ikke muligt, da den nødvendige viden ikke findes i organisationen. Samtidig er det svært at opsøge denne viden, da den tilgengængelige litteratur beskæftiger sig med langt større projekter i større sammenhænge, hvilket fører videre til den næste hypotese…

Eksisterende metoder (og delvist teknikker) fokuserer på større projekter
Forskningen omkring brugerinddragelse er ofte fokuseret på langt større projekter, altså projekter i millionklassen, er er brugerinddragelsen ofte omdrejningspunktet for projektet. Inden for mindre og mellemstore webudviklingsprojekter er selve produktet omdrejningspunktet - og de eksisterende metoder skyder derfor forbi målet.

Inden for usability har man flere forskellige teknikker til at inddrage brugerne, men disse mener vi ofte kun tillader brugerne at afprøve og teste allerede næsten færdige produkter.

Kunder vil vide hvad de køber
Når man sælger små og mellemstore webudviklingprojekter må man accepterer at kunderne i salgssituationen vil vide hvad de køber. Derfor bliver projekterne allerede i salgssituationen underlagt nogle relativt faste rammer.

Vil vil derfor udarbejde nogle teknikker som sikre at brugerinddragelsen giver de faktiske brugere en reel indflydelse på produktets udformning - samtidigt med at kunder ved hvad de køber.

Da vi i dag lige kort ville blive enige om nogle elementer som vi gerne ville have ind i vores workshops, havde vi pludselig skitseret et muligt framework for vores specialeprojekt.

Det centrale begreb i vores framework er designmateriale. Begrebet har som sådan ikke nogle stærke teoretiske rødder, men bruges f.eks. af Johansson (2005). Dog tror vi på at vi gennem virksomhedsteori (Bertelsens designartefakter) og sekundært også Schöns ide om den refleksive samtale med materialet kan skabe teoretisk grundlag for at anvende begrebet designmateriale.

Ved at anvende designmateriale som vores centrale begreb, kan vi reducere fokus for vores projekt ned til det, at skabe designmateriale.

Det giver os værktøjet til at opstille nogle arbejdsspørgsmål til vores proces. Men inden vi forsætter med at formulere arbejdsspørgsmålene, så vil vi lige forklare figuren som vi skitserede den.

Vi har som de to input til designmateriale planlagt at vi vil lave teknikker til etno-ligth og workshops.

Etno-ligth er vores bud på, hvordan de aktiviteter som sælgere (og andre med kundekontakt) kan udvide deres fokus på at indsamle data til brug for designprocessen. I denne forbindelse er ideen om designmateriale centralt, da de tillade sælgerne at se deres arbejde som et led i designprocessen. De skal således ikke lave radikalt anderledes aktiviteter end i dag, men blot se dem i et andet lys. Eller hvis der i et projekt er flere ressource til rådighed, kan andre end sælgeren sendes ud i felten.

Workshops følger bl.a. design-by-doing tankegangen fra PD og er som sådan ikke noget nyt.

Både etno-ligth og workshops resulterer i nogle data, og disse data vil se som designmaterialer. Vi vil både se de artefakter som der i dag findes virksomhederne og ny mere bruger-fokuserede artefakter som designmateriale. Designmateriale kan således f.eks. være:

• Prototyper
• Personas
• Tilbud
• Kontrakter
• Krav-spec
• Mock-ups
• Wireframes
• Scenarier

Som sagt giver designmateriale-begrebet os muligheden for at stille nogle spørgsmål til vores proces. Til de enkelte designmaterialer kan man f.eks. stille følgende spørgsmål:

• Hvordan skal designmaterialet indgå i udviklingsprocessen?
• Hvilke data skal designmaterialet beskrive?
• Hvordan skal designmaterialet understøtte reflection-in-action eller reflection-on-action?
• Hvordan får vi designmaterialet ind i produktionsmodus?
• Er designmaterialet why, where eller where-to-artefact?
• Hvem skal udarbejde designmaterialet?
• Hvordan inddrages brugerne i skabelsen af designmaterialet?
• osv.

Som en sidste detalje fra vores skitse, har vi således også besluttet, at de aktiviteter vi vil understøtte med vores teknikker er 1) konceptudvikling og 2) interaktionsdesign. Valget af disse to fokusområder er både et resultat er de projekter som vi “tilfældigvis” er blevet koblet på, men også et udtryk for et bevidst valg. Vi mener således at det er i disse to aktiviteter, som der mangler fokus på brugerinddragelsen i. Der er masse af teknikker til brugertests og ekspertgennemgange. Ligesom vi mener at designere og udviklere fuldt ud mestrer at sætte en brugerflade fornuftigt sammen - der er masse af råd og vejledning om hvorledes man laver flotte og brugervenlige websites.

Men der mangler viden om hvad brugerne rent faktisk synes at et website/-applikation skal kunne.

Vi er nu ved at planlægge vores empiriske arbejde i samarbejde med vores 2 samarbejdsvirksomheder (webudviklingshuset og webbureauet). Vi har delt vores arbejde op 2 i dele:

• Interviewfase
• Interventionsfase

Interviewfasen er rimlig lige ud af landevejen, hvor vi laver 2-3 interviews i hver virksomhed.

Interventionsfasen er straks mere snørklet og fuld af udfordringer - men også her hovedindholdet af specialet skal findes.

Vi ved stadig ikke hvad vores interventioner skal indeholde, og spørgsmålene står i kø:

• Hvem skal med? Hvordan finder vi nogle brugere? Hvem skal finde brugere?
• Hvad skal vi vide om projekterne inden vi kan planlægge en intervention? Skal vi vide noget overhovedet? Kan man planlægge en meningsfuld intervention uden at kende konteksten?
• Hvornår skal vi afholde workshopsne? En deadline er god at have, men vi kender ikke til de planlægningen af de projekter vi skal deltage i.

Lige et Jakob Nielsen indspark, som kunne være brugbart for vores projekt.

I Nielsens seneste alertbox opstiller han 3 niveauer af kløfter mellem designere og brugere:

• Level 1: The Designer Is the User
• Level 2: The Designer Understands the Product
• Level 3: Designing for a Foreign Domain

Den slags webudviklingsprojekter som vi vil fokusere på i dette projekt, falder inden for niveau 2. Når designeren er brugeren, er der ikke noget behov for at lave brugerinddragelse. På niveau 3 er kløften mellem designer og bruger så tilpas stor, at man som designer finder det oplagt at inddrage brugerne for mindske kløften. Men i niveau 2 er man tilbøjelig til at springer brugerinddragelsen over, da man mener at man har en så tilpas forståelse, at man ikke behøver at inddrage brugerne.

Men lyt til gamle Jakob Nielsen:

“But you don’t necessarily know the features people need to do their jobs (which are likely completely different than yours). And you don’t know what UI most people will find easy or difficult to use.”

Vi har i dag været til det første planlagte vejledningsmøde siden vi indgik specialekontrakten.

Vejledningen gik dels på vores nuværende status i projektet og det videre arbejde derfra, samt på de teoriafsnit vi hidtil har udarbejdet.  For at starte med det sidste først fik vi ros for vores skrivestil og færdighedsgraden af teksten. Vi vil dog foretage et fokusskifte og begynde at fokusere på det praktiske arbejde sammen med vores samarbejdspartnere, som vi satser på at have endeligt fastlagt inden påske.  Vi kan derefter senere vende tilbage til teoriafsnittet med den nye viden om praksis og de resultater vi opnår der.

Derfor: Praksis here we come!

Spørgsmålet er om ikke vi faktisk laver aktionsforksning?

“Action research refers to research that takes as its starting point the problems of ‘participants within particular, local practice contexts’ (Argyris and Schön, 1996 p.86). Such research approaches have in common that the researcher ‘takes concrete action to
achieve positive change’ (Brandt, 2001 p.28) and exploration of a context simultaneously. Action research is characterized by engagement in a specific problem/assignment usually originating from industry.” Martin Johansson (2005)

Camel et al. (1993) har dette meget intuitive og sigende kontinuum til kategorisere graden af brugerinddragelse i de forskellige metoder:

Især skelnenen mellem konsultativ, repræsentativ og konsensus giver god mening.

Et bud på det unikke ved vores tilgang kunne være, at vi ser to forskellige brugere i en webproduktion. For der første er der brugerne af websitet, som er dem man normalt vil inddrage i en brugervenlighedsarbejdet. Dernæst er der brugerne af administrationssoftwaren (CMS’et). Vi benævner disse som henholdsvis de besøgende og webmasteren. Hvor PD’s medbestemmelse i designprocessen ikke giver mening i forhold til de besøgende, giver det mening af inddrage webmastere på lige fod med de øvrige beslutningstagere.

Det er interessant at læse op på Participatory Designs historie, især den baggrunden i arbejdspladsdemokratisering og emancipering af arbejderne. Denne tidlige PD tilhøre det som Jørgen Bansler betegner som den fagpolitiske (critical) tradition. I vore dage (dvs. vores generations syn forholdet mellem arbejdere og ledelse) er den fagpolitiske vinkel gledet ud af billedet. I dag virker den socio-tekniske tradition som den mere moderne. Hvilket faktisk er paradoksalt, da f.eks. Pelle Ehns Work-Oriented Design of Computer Artifacts (1987) beskriver hvorledes den fagpolitiske tradition bygger på en kritik af den socio-tekniske tradition (Ehns term for fagpolitisk er collective resource) .

På baggrund af opsummeringen i nedenstående sammenligning, vil jeg argumentere for, at vi placerer os mere i den socio-tekniske tradition:

Jonathan Grudins artikel Bridging the Gaps Between Developers and Users (1991) definerer 3 forskellige paradigmer (eller kontekster) for udviklingsprojekter, der hver især giver forskellige forudsætninger for brugerinddragelse:

• Competitively bid contract development
• Product development
• In-house and custom development

Artiklen beskriver hvilke muligheder og forhindringer som hver af de tre paradigmer har for brugerinddragelse. Kontraktudviklingsparadigmet er det paradigme der passer bedst på mindre udviklingswebudviklingsprojekter - der er dog signifikante afvigelser. Vi vil nu gennemgå de karakteristika som Grudin beskriver for kontraktudvikling.

Tilbudsbaseret kontraktudvikling er formet af, at den amerikanske regering har defineret hvorledes at softwareprojekter skulle sendes i udbud. På grund af at vandfaldsmodellen passer naturligt ind i en udbudsforretning blev vandfaldsmodellen grundlag for den amerikanske regerings standarder: “[…] the waterfall model is a natural fit to competitive contract development, where the user organization determines feasibility, prepares a requirements specification, and then issues one or more contracts for design, development, administration, and maintenance.” (Grudin 1991, s. 61)

Inden for webudvikling ser man således stadig sporene fra den tilbudsbaserede kontraktudvikling som Grudin beskriver. Kunden kommer til webbureauet med en specifikation af website og/eller webapplikation, derefter udarbejder webbureauet et tilbud. På baggrund af tilbudet indgås der en kontrakt, der beskriver hvad der skal laves, hvornår det skal leveres og til hvilken pris.

I forhold til brugerinddragelse er vandfaldsmodellen ikke velegnet: “[it] provides minimal opportunity for prototype testing and iterative design, which form the basis of ongoing user involvement.” (Grudin 1991, s. 61)

Kundens specifikation og webbureauets tilbud bliver således grundlaget for design og implementeringen af websitet. Jf. Grudin bliver sådanne tekstbaserede beskrivelser af interaktive systemer til en “mur” mellem brugerne og udviklerne. Muren er ikke uovervindelig, men fordrer ikke samarbejde mellem udviklere og brugere. (Grudin 1991, s. 61) Jf. Grudin (og Cadle & Yeates 2004) er vandfaldsmodellen velegnede, når der er både, er det, som Christensen og Kreiner betegner som lav konstekstuel og lav operationel usikkerhed (1991).

Jf. Grudin er kontraktudviklingens succeskriterium, at der er overensstemmelse med den tekstbaserede specifikation; imodsætning til f.eks. produktudvikling, hvor parametre som brugeroplevelse og brugertilfredshed er afgørende for, om produktet bliver succesfyldt på markedet (1991, s. 62).

Følgende faktorer påvirker udviklingsprocessen jf. Grudin:

• One constraint, the time for involving development partners, wasused to identify the three development paradigms:a single user organization for which there are many potential developers (contract development), a single development group with many potential users (product development), and a single development group with a single user organization (inhouse development).
• the size, charter, and structure of the developmentorganization;
• the nature of the user population
• the degree of design uncertainty
• the presence or absence of other partners or contributors to the project
• the nature of the commitments and agreements among the parties involved
• societal conditions that the partners may be unable to control
• and changes encountered over the life of the project (Grudin 1991, s. 63)

På baggrund af disse faktorer gennemgår Grudin muligheder og forhindringer (og mediatore som vi dog ser bort fra her) for hvert udviklingsparadigme.

Med hensyn til kontraktudvikler skriver Grudin: “User involvement faces the most formidable obstacles in this context, especially with fixed-cost competitively bid contracts.” (1991, s. 64)

Som den primære mulighed for brugerinddragelse i kontraktudviklingsparadigmet, beskriver Grudin, at kontraktudvikling indleder med at at have en veldefineret brugergruppe (1991, s. 64). Dette afviger dog fra webudvikling og udvikling af websites, da disse netop er defineret ved at have en stor (hele verden!), uhomogen og anonym målgruppe.

I forhold til forhindringer beskriver Grudin et eksempel, hvor der er tale om et regeringsprojekt, hvor der er politiske og lovmæssige problemer i at lade udviklings- og brugerorganisation samarbejde. Sådanne problemer ses sædvanligvis ikke i webudvikling.

Men en af de forhindringer som Grudin beskriver, findes også i webudvikling: “The development organization might prefer to commit to a relatively comprehensible and static document rather than try to satisfy unpredictable users.” (1991, s. 64) Det er nu en gang lettere at opfylde en række tekstbaserede krav, end det er at finde på nye problemer, ved at inddrage de reelle slutbrugere. Det virker således mere attraktivt at “gøre hvad kunden siger” og som en udviklingsproces der er lettere at kontrollere. (Men vi ved fra Cooper at customer driven development er det det onde selv!)