Brugerinddragelse i webudvikling

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!)

I artiklen Participatory Design in Commercial Settings - a conceptual framework giver Kensing (2002) en delvis besvarelse på dette spørgsmål: “What would it take to for PD to become an integral part of IT design practitioners’ repertoire for action?” (Kensing 2003, s. 381)

I vores specifikke kontekst, kunne dette omformuleres til: “Hvordan kan brugerinddragelse blive en integreret del af mindre webudviklingsprojekter?” Men i denne omformulering mister man fokus for hvem vores interventionsdesign henvender sig til. Inden for den almindelige projektledelse er man fokuseret på at tildele ansvar (f.eks. Cooper 2004).  Et af de spørgsmål som vores interviews skal have afdækket er således, hvem skal være ansvarlig for brugerinddragelsen?

Dette kan der dog ikke gives et generelt svar på, da dette vil variere fra organisation til organisation.

Der er dog også forskel på at være ansvarlig for brugerinddragelsen, og så være ansvarlig for interaktionsdesignet (Cooper 2004). Selvom man gennemføre en eller flere interventioner, der giver værdifulde resultaterne, så nytter det ikke noget, hvis man ikke har autoritet til at dette udmønter sig i designet.

Vi ved også fra PD litteraturen, at der ikke bør være et skel mellem designere og implementørerne (Kensing 2003, s. 322), i vores kontekst henholdsvis brugerdragelsesansvarlig og grafiker. Det er optimalt for designet, hvis det er den, der er ansvarlig for designet, også er ansvarlig for at gennemføre interventionerne.

Men at gennemføre sådanne organisatoriske forandringer, høre ikke direkte ind under dette speciale. For det første fordi vi specialets fokus ikke ligger på organisationsforandring. Og for det andet fordi vi ikke mener, at man bare kan “gennemtvinge” sådanne forandringer i tilfældige organisationer.

En IT-designer
Generelt for Kensings artikel - og andet arbejde - støder man ofte på betegnelsen IT-designer. IT-designeren er ansvarlig for brugerinddragelse og designet af det nye it-system, og anbefalinger til hvorledes it-systemet indgår i organisationens strategi og arbejdspraksis. “The responsibility of the IT designers is […] is to engage organizational members to in developing an understanding of the needs and opportunities of the organization in question, as well as in designing of one or more coherent visions of change.” (Kensing 2003, s. 322). Der er store sammenfald med Coopers (2004) interaktionsdesigner. Problemet med at etablere en sådan rolle er, at denne rolle ikke findes i de webudviklingsorganisationer, som vi har kendskab til.

Det umiddelbare svar på, hvorfor at der ikke findes en sådan rolle i webbureauer er, at projekterne simpelthen ikke er store eller komplicerede nok til, at have en fuldtids interaktionsdesigner. Dette kan der nok også føres bevis for, men derfor er resultatet stadigvæk, at brugerinddraglse er fraværende og user experience opstår adhoc og tilfældigt.

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.