Workshop - usability champion

Dagen inleddes med två korta föredrag om användbarhetsdesignern och hur denna roll kan implementeras i RUP-drivna projekt.

Användbarhetsdesignern - bakgrund och definition

Bengt Göransson, Uppsala Universitet och Enea Redina, inledde med att prata om bakgrunden till och definitionen av begreppet användbarhetsdesigner (Göransson, Sandbäck, 1999). Man började skissa på denna roll i föregångaren till vårt projekt, Design for Usable Systems (DUS). Användbarhetsdesignern skulle kunna ses som en usability champion.

Användbarhet uppstår inte av en slump, det räcker inte heller med att definiera en ny roll. Det krävs att hela organisationen fokuserar på användbarhet och arbetar användarcentrerat i projekten. Vad utmärker då användbarhetsfokuserade företag och organisationer? Bengt tog upp följande punkter

• De sätter användarna först och håller dem hela tiden i sikte, synliga
• De lär sig så mycket de kan
  • alla ska besöka en användare, på kontoret eller i hemmet (beroende på användningskontext)
  • de delar information
  • de frågar kunden
• Snabbare är bättre - de testar ofta och hoppar över rapporterna

Bakgrunden till rollen användbarhetsdesigner är Gould & Lewis' fyra principer för "design for usability" (Gould, Boies, Ukelson, 1997) . De är

• tidig och kontinuerlig fokus på användarna och deras uppgifter - förstå användarna och deras arbetsuppgifter
• empiriska mätningar - man måste testa sina lösningsförslag genom att utvärdera prototyper
• iterativ utveckling - cyklisk process med design, utvärdering, ny design...
• integrerad utveckling - alla aspekter av användbarheten utvecklas tillsammans

Användbarhetsdesign bygger på Gould's och Lewis' fyra principer. Det är skilt från det mer ingenjörsmässiga angreppssättet, "usability engineering" (Nielsen, 1994). Användbarhetsdesign skulle kunna ses som en blandning av Nielsen's resonemang och det resonemang om design som Cooper för i "Inmates are Running the Asylum" (Cooper, 1999).

Det kräver genomgående förändringar av process och attityder i en organisation att börja arbeta användarcentrerat. Framförallt attityder är centrala för att man ska lyckas med ett användarcentrerat angreppssätt, det måste genomsyra organisationen - i en sådan organisation kan användbarhetsdesignern vara den som kan sälja in budskapet, och arbeta operativt i projekten. I organisationer där rätt attityder saknas kan det vara meningslöst att prata om användarcentrering, i sådana fall kanske det mera ingenjörsmässiga angreppssättet fungerar.

Bengt argumenterade för att man måste samla ansvaret för användbarheten till en person, även om flera arbetar med den. Dessutom bör alla i en organisation utbildas inom området användbarhet så att man höjer den "lägsta nivån". Några av motiven till en samlande roll, en användbarhetsdesigner är

• Man tydliggör användbarhetsaspekterna i projekten. Användbarhet kommer upp på agendan.
• Användarna vet inte alltid vad som är bäst för dem.
• Systemutvecklarna har inte alltid kompetens, intresse eller förmåga att åstadkomma användbara system.
• Systemutvecklarna har sällan tid för mer dedikerad design av användargränssnitt och användbarhet.
• Man undviker »my-baby-syndromet«.
• Dokumentationen från utvecklingsarbetet är ofta svår och tidsödande att förstå för andra än de som deltagit i utvecklingsprojektet.
• MDI och domänkunskap är ofta väldigt komplext.

Vad gör då en användbarhetsdesigner? Det beror givetvis på projektet, storlek, komplexitet, domän, etc. Men förenklat kan man säga att användbarhetsdesignern fungerar som länken mellan utvecklings- och användarorganisationerna. Några ansvarsområden som tillhör användbarhetsdesignern är

• Ser till att utvecklingsprocessen hålls användarcentrerad.
• Deltar aktivt i designprocessen och de designbeslut som rör användbarheten.
• Deltar i alla utvecklingsfaser och användbarhetsrelaterade aktiviteter.
• Jobbar nära både användarna och utvecklarna.
• Vara "specialist" inom området människa-datorinteraktion - men ändå en generalist

Hur ställer sig då enna roll till andra liknande roller, t ex användbarhetsarkitekt, interaktionsdesigner eller grafisk designer? Bengt menar att användbarhetsdesignern har ett större helhetsansvar och större befogenheter för användarcentreringen och användbarhet. Han/hon är mer drivande i processen än vad traditionella användbarhetsroller är. Den skulle kunna ses som en miniversion av en fullständig användbarhetsorganisation. Rollen kräver dessutom kunskap både inom beteendevetenskap och teknik. Bengt såg också att någon form av projektledarskap följer med rollen.

Användbarhetsdesignern i RUP

En av deltagarna redogjorde för arbetet i sin organisation med att implementera rollen användbarhetsdesigner i RUP (Rational Unified Process). Användbarheten skulle kunna ses som ett eget arbetsflöde i RUP - det finns både för och nackdelar med detta. Ett av argumenten mot är att användbarheten finns överallt, t ex i kravidentifiering, i UI-design, i test. I RUP kan inte ansvaret för en artefakt/aktivitet delas av flera, därför är det mot RUPs principer att samla ansvaret för något som återkommer i ett flertal artefakter/aktiviteter i ett eget arbetsflöde. Å andra sidan är det ett sätt att göra användbarheten synlig.

Tanken med användbarhetsdesignern är att han/hon ska vara med från början vid verksamhetsmodelleringen, genom hela processen till slutet. I stora projekt ska användbarhetsdesignern vara med på kontinuerlig basis, på minst 50% deltid. I mindre projekt är det snarare fråga om punktinsatser, t ex modellering och GUI-design samt utvärderingar. Hur mycket användbarhetsdesignern deltar styrs också av komplexiteten i systemet. För komplexa system krävs en användbarhetsdesigner kanske på heltid, medan det i enkla system kanske räcker med att användbarhetsdesignern fungerar som stöd och bollplank till UI-designern.

Man har inte ersatt UI-designer med en användbarhetsdesigner. UI-designern har kvar ansvaret för designen av gränssnittet, medan alla användbarhetsaktiviteter (de få som finns i RUP) har flyttats över till användbarhetsdesignern. Den stora skillnaden mellan dessa roller är att UI-designern har interaktionsdesign som specialitet medan användbarhetsdesignern i första hand är beteendevetare med MDI-inriktning. Man måste noggrant specificera ansvar och befogenheter för respektive roll i projekten. Användbarhetsdesignern ansvarar också för att projektet arbetar på ett användarcentrerat sätt och han/hon arbetar mycket nära projektledaren.

Båda rollerna (användbarhetsdesigner och UI-designer) har satts som "obligatoriska" i organisationens konfigurering av RUP. Det innebär att i de fall man väljer att inte inkludera någon av dem i ett projekt måste man motivera varför. I den här organisationen (med egen dataavdelning) sitter användbarhetsdesignern på leverantörssidan. Frågan om hur man motiverar ännu fler personer och roller i projekten har man lyckats lösa genom att beställarsidan inkluderar krav på att projekten innehåller en användbarhetsdesigner i sina beställningar.

Ett av problemen är att man lider av ett "arv" - man har tidigare lagt ansvaret för användbarhet på personer utan egentlig kompetens inom området. Efter principen att "den som programmerar VB också kan det här med användbarhet". Man kommer därför att införa en certifieringsprocess för användbarhetsdesignern, som kommer att omfatta utbildning och praktik.

Konfigurering av RUP och införandet av användbarhetsdesignern har varit en lång och mödosam process, men i den aktuella organisationen blev införandet av RUP snarare en möjlighet att få in användbarheten än ett hinder. Den utvecklingsprocess man använde tidigare hade inget utrymme för användbarhetsaktiviteter.

Usability Champion - i projektet

Vad är en usability champion, vad gör han/hon i projekt, vilka områden och vilka aktiviteter ansvarar han/hon för. När och i vilken utsträckning deltar en usability champion (UC) i projektarbetet. Vilka "sida" ska UC finnas på - leverantörens eller beställarens? Dessa och många andra frågor var underlag för dagens diskussion.

Som inledning och (eventuell) inspirationsskälla visades klipp ur "How To Design Usable Systems", (Gould, Boies, Ukelson, 1997, p 239). De menar att integrerad design krävs för att man ska kunna designa och imlementera användbara system. Med integrerad design menar de bl a

• ”Integrated design requires that one group, at the very beginning, be given sufficient resources (money, personnel, time, authority) to drive and control usability, and to invent what is needed to make usability good.”
• ”Integrated design requires that this group sign up to guarantee good usability.”
• ”It requires that the usability people be outstanding, be given the responsibility (and accountability), and have good tools.”

Gould, et al, pekar också ut ett antal områden och aktiviteter inom ett utvecklingsprojekt som denna roll/person/grupp har ansvar för. Listan omfattar följande punkter

• alla användbarhetsaspekter beaktades i den initiala designen
• en person (tilllsammans med lämpligt antal medarbetare) hade ansvar för alla användbarhetsaspekter
• användarmanual, andra manualer, on-line-hjälp, utbildningsmaterial, support, etc
• identifiering av krav och behov vad gäller funktionalitet
• användargränssnitt
• systemets tillförlitlighet och svarstider
• installation, anpassning och underhåll

Ett ganska omfattande ansvar, med andra ord, för vilket författarna också kritiserats. Finns det någon som kan axla det här ansvaret i stora komplexa projekt? Författarna argumenterar dock att det faktiskt redan i varje projekt finns en person som har ansvar för hela systemet, där användbarhet bara är en del. Frågan är väl dock om någon annan än de själva har lyckats implementera integrerad design fullt ut i något projekt? Kanske är ambitionsnivån för hög.

Med detta som utgångspunkt började vi diskutera usability champion och vilka ansvarsområden rollen omfattar. De beskrivs nedan.

Krav

Deltagarna argumenterade för att det är genom kraven man kan få in användbarheten i projekten. Därför är identifiering av krav ett självklart ansvarsområde för UC - UC ska hjälpa beställaren/kravställaren att ställa krav. Det gäller både "funktionella" krav och typiska "användbarhetskrav". Det räcker dock inte att behandla användbarheten som en del av kravarbetet enbart. Krav och mätning täcker inte helheten, utan användbarheten måste in i alla faser i projektet, inte minst i designarbetet.

En av deltagarna argumenterade för att alla krav på funktionalitet borde uttryckas i termer av "användbarhetskrav". Användbarhet kan alltså inte delas upp i "nytta" och "lätt att använda". Istället omfattar användbarheten med nödvändighet också nyttan av systemet, dvs att användaren inte bara kan använda de tjänster systemet erbjuder på ett lätt och smidigt sätt, utan även har nytta av dem i den givna användningssituationen. Om man utgår från den definitionen av användbarhet kan funktionaliteten inte separeras från användbarheten. Istället föreslog deltagarna att man diskuterar i termer av systemets beteende.

Vi diskuterade också kort användningsfallens roll i utvecklingen. Alla var eniga om att de inte är lämpliga att designa användargränssnitt från. Istället bör man utgå från skisser och prototyper samt de krav man tar fram med användarna och skriva användningsfall utifrån dem.

Visualisering - kommunikation

Det ligger också på UC att visualisera dessa krav i form av skisser och/eller prototyper. Dels för att hjälpa beställaren/användarna att ställa nya/kompletterande krav. Dels för att skapa en design som kan lämnas till systemutvecklarna för implementation. Detta innebär att en stor del av kommunikationen om systemets användning hamnar på UC. En av deltagarna beskrev hur en stor del av all kommunikation i projekten, även den som inte handlar om användbarhetsfrågor, hamnade på hennes axlar "med eller mot min vilja".

I kommunikationen ingår också att dokumentera interaktionsdesignen och de designbeslut som fattas. Ett problem är att den dokumentationen kan bli betungande i projekt som bygger stora och komplexa system. Därför bör man hålla dokumentationen på en så låg ambitionsnivå som möjligt - t ex i form av en dagbok, som, om den blir för stor, kan "sorteras om" efter andra kriteria än datum. Det räcker med att skriva ner en "slogan" så att man kommer ihåg vilket designbeslut det rör sig samt en motivering till varför man fattade beslutet.

Ett problem som diskuterades under dagen är också hur man överför kunskapen från UC till, t ex, systemutvecklare som ska implementera designen. Skisser, prototyper, textuella beskrivningar, användningsfallsmodeller räcker inte till. Det uppstår alltid frågor och sker förändringar under implementationen (konstruktionens svarta hål). Måste UC vara med hela tiden? Vissa menade att det var så, andra att man borde kunna dokumentera på ett sådant sätt att UCs deltagande åtminstone kan minska under implementationsfasen, till att kanske röra sig om punktinsatser. Ett annat sätt att angripa problemet med kunskapsöverföring är att systemutvecklarna deltar i de tidiga faserna, t ex är med och träffar användare och bygger prototyper. I stora projekt med många utvecklare finns givetvis problemet att alla inte kan vara med, men det borde inte förhindra att någon eller några är med. Oavsett storlek på projekt är en viktig faktor att man arbetar tätt tillsammans, att man har täta kontakter, sitter tillsammans och pratar med varann!

Design

UC har också ansvaret för designen av "användarens hela upplevelse" - eller systemets beteende. Ett svårt begrepp som omfattar både "look and feel", dvs både utseende och beteende. Här såg vi problem i projekt där flera specialister designar "sina" aspekter i gränssnittet, t ex grafisk profil. Vem ska i så fallet ha ansvaret för den grafiska designen? Den grafiska designern eller UC? Användarens hela upplevelse omfattar även estetiska aspekter och om UC ska ha hela ansvaret ingår även dessa.

Verifikation och uppföljning

I den ideala världen kan UC följa med, inte bara under själva utvecklingsprojektet utan även i användningen av systemet. Då, först, kan man konstatera om systemet verkligen uppfyller de behov som användarna har på ett bra sätt. Tyvärr är det sällan möjligt, åtminstone inom konsultvärlden. Dock bör UC alltid ha ansvaret att se till att utvärderingar av lösningsförslag alltid sker under utvecklingsprojektet och att användbarheten alltid verifieras i samband med leverans.

Projektledning

Den som arbetar med användbarhet i ett projekt hamnar lätt i någon form av projektledarroll, formell eller informell. Det beror troligen dels på att mycket av "kommunikationsansvaret" lätt hamnar hos den personen, dels på att det är en av de personer i projektet som har en helhetsbild av systemets användning. Är det rent av så att bästa sättet att garantera användbarheten är att UC axlar projekledaransvaret? Dvs om man bara har några få personer med kompetens inom MDI ska man hellre sätta in dem som projektledare än skapa en ny "användbarhetsroll" för dem?

Specialister kontra generalister

Ska ansvaret för användbarhetsarbetet verkligen läggas på en person (eller en grupp specialister) som Gould, et al, föreslår. Ska vi verkligen ha usability champions? Vissa deltagare argumenterade för att det är bättre att lära upp alla utvecklare inom MDI-området. Att höja den lägsta nivån vad gäller kunskap om användbarhet i projektet så att alla kan ta ett ansvar för dessa frågor i de delar där de är involverade. Det finns helt enkelt inte tillräckligt många personer av den typ som krävs för att axla UC-rollen, för att det ska räcka särskilt långt.

Ett annat argument för ett "distribuerat" användbarhetsansvar är att användbarheten borde vara en så självklar del i utvecklingsarbetet att vi inte ens borde prata om det i termer av användbarhet. Alltså borde vi heller inte ha speciella roller som arbeter med det. Mot detta argumenterade flera att där är vi inte ännu. Användbarhet är inte en självklar del som man inte behöver prata om utan det kräver systematiskt strukturerat arbete och en framhävd roll i processen. Nackdelen med att göra användbarheten synlig med hjälp av en speciell roll är att man då också kan välja bort den, för att "spara" pengar. Det borde ändå gå att få in användbarheten via krav, eller via andra "flummiga" begrepp som kvalitetsfokus, användarfokus eller kundnytta.

Ett argument för ett "centraliserat" användbarhetsansvar är att det faktiskt finns företag och organisationer där man arbetar med en liknande roll. Dvs man har någon som ansvarar för hela "användarupplevelsen". Detta ställer dock stora krav på processen för övrigt, och förmodligen på beställarens mognad.

Webben - en annorlunda process?

På grund av sammansättningen i gruppen, kom mycket av diskussionerna att färgas av hur man arbeter med utveckling av web-baserade lösningar, t ex intranät. Frågan är hur mycket detta påverkar hur användbarhetsarbetet kan genomföras. Har man t ex en annorlunda projektkultur, med inslag från reklamvärlden där man sedan länge är van att arbeta i team med olika specialister? Underlättar det i så fall införandet av en UC-roll i dessa projekt? Å andra sidan arbetar man kanske i mindre utsträckning tillsammans i den här typen av team - vilket skulle kunna medföra svårigheter om någon av disciplinerna ges mer ansvar än övriga. I traditionell systemutveckling gör den vanlige systemutvecklaren lite av varje i projekten. Där är alla snarare generalister än specialister.

Kompetens

Vilken kompetens krävs för rollen usability champion? Hur skulle en anställningsannons se ut? Vi satte samman följande punkter.

• Någon form av akademisk bakgrund ansågs nödvändig - inom något "relevant" område, gärna med ett tvärvetenskaplig inslag.
• Kunskap inom både beteendevetenskap och datavetenskap ansågs viktigt. En beteendevetare som har erfarenhet av programmering eller en systemutvecklare med erfarenhet av MDI-arbete. Känsla för grafisk design ansågs också viktig. Hur man skaffat sig kunskapen är mindre intressant - däremot krävs "fingertoppskänsla".
• Kunskap om systemutvecklingsprocessen ansågs nödvändig, liksom kunskaper om användarcentrerade metoder och tekniker. Vi diskuterade huruvida det var nödvändigt med egna praktiska erfarenheter av metoder och tekniker, eller om det räcker med att ha deltagit i projekt, som t ex projektledare, där andra ansvarat för den typen av aktiviteter. Några ansåg att det räcker med att känna till hur användarcentrerade metoder och tekniker används så att man kan planera för dem, t ex hur och när användare ska involveras i processen. Andra deltagare ansåg att praktisk erfarenhet var nödvändig.
• Praktiska erfarenheter av projektledning är nödvändig för en usability champion. Liksom flerårig erfarenhet av system- eller produktutveckling.
• Vad gäller de tekniska delarna ansåg de flesta att en usability champion måste ha en grundläggande förståelse för möjligheterna och begränsningarna i den teknik som används.
• Mindre viktig ansågs kunskap om användarnas verksamhet vara - här var vi dock inte helt överens. Kunskap om den bransch eller verksamhet som systemet ska stödja underlättar naturligtvis användbarhetsarbetet, men det kanske är viktigare i mer specialiserade eller komplexa sammanhang. Bengt berättade om utvecklingsbolag som jobbar med medicinsk industri, där man anser att det är lättare att anställa t ex farmaceuter och utbilda dem i programmering än att utbilda programmerare om verksamheten inom den medicinska industrin.
• Vad gäller personliga egenskaper ansågs ledaregenskaper viktiga, t ex lyhördhet, respekt, pondus och kommunikationsförmåga. Usability champion måste vara handlingskraftig och drivande. Han/hon ska vara både visionär och missionär, samt en problemlösare - "metodfascister" göre sig icke besvär!

Hur skulle då en annons se ut? Kanske så här...

Det finns inga enkla svar på vad en usability champion är och om den rollen behövs eller om ansvaret för användbarheten ska vara "decentraliserat". Det beror givetvis på projektets storlek och sammansättning, samt systemets storlek och komplexitet. Dock gav dagen några idéer som kan sammanfattas så här:

• det behövs en speciell roll för att lyfta fram användbarheten i projekten
• den här rollen har ansvaret för bl a kravarbetet, visualisering och kommunikation, all design som på något sätt bidrar till användbarheten samt utvärderingar och verifiering av användbarheten - det är ett ansvar som kräver stora befogenheter och som innebär att man har en ledande och drivande roll i projektet
• det ställs stora krav på denna roll - en usability champion behöver flerårig erfarenhet av användarcentrerad systemutveckling samt projektledning, och behöver dessutom ha kunskap inom både teknik och beteendevetenskap. Han/hon måste också kunn leda, driva, entusiasmera, lyssna, missionera och "visionera"
• trots detta behöver vi utbilda utvecklarna så att de kan ta ett större ansvar för användbarheten i projekten. Med de krav som ställs på en usability champion räcker de inte till på långt när

• Cooper, A. (1999), The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity,Sams:Indiapolis, Indiana
• Gould, J.D. Boies, S.J. Ukelson, J. (1997). How to Design Usable Systems, in Helander, M. Landauer, T.K. Prabhu, P. Handbook of Human-Computer Interaction, Second revision, Elsevier Science B.V., Amsterdam, the Netherlands.
• Göransson, B. Sandbäck, T. (1999), Usability Designers Improve the User-Centred Design Process. Brewser, S. Cawsey, A. Cockton, G. Human-Computer Interaction Ð INTERACT Õ99 (Volume II), Edinburgh Press, the UK.
• Nielsen, J. (1994), Usability Engineering,Morgan Kaufmann, San Francisco