Brugerinddragelse i webudvikling

Faldt lige over nogen der laver det samme som os:

At the University of Rochester’s River Campus Libraries we have included users in technology development with great success. “Participatory design” entails collaboration among designers, developers, and users from the earliest stages of conception through to implementation of websites and other technology. Using participatory methods, a project to redesign the library website began with workshops to identify user needs and preferences. The results of these workshops led to the identification of key tasks for the main page. They also generated a hierarchy of tasks for sub-pages and rich information about how students and faculty members use current websites in their work. In our article, we explain our reasons for running participatory design workshops, describe our methods, review participants and recruitment, and summarize key findings. We also include information about our local implementation and general conclusions about the value of design workshops for website design and development.

Participatory Design of Websites with Web Design Workshops…

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.

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.

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.