Loading
Anteckningar från workshop om rollen Usability Champion, 2001-03-27.
Denna aktivitet genomfördes inom ramen för projektet Användbara metoder för användbara system, avdelningen för MDI, institutionen för IT, Uppsala Universitet.
Anm: I texten har jag använt ordet system, eftersom det inte finns någon bra översättning av ordet "software" till svenska. System kan i det här fallet betyda skräddarsytt system för en viss verksamhet, en web-sajt, ett intranät, eller en produkt. Det är alltså i ganska vid bemärkelse jag använder ordet system.
Dagen inleddes med två korta föredrag om användbarhetsdesignern och hur denna roll kan implementeras i RUP-drivna projekt.
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
Bakgrunden till rollen användbarhetsdesigner är Gould & Lewis' fyra principer för "design for usability" (Gould, Boies, Ukelson, 1997) . De är
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
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
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.
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.
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
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
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.
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.
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!
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.
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.
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?
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.
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.
Vilken kompetens krävs för rollen usability champion? Hur skulle en anställningsannons se ut? Vi satte samman följande punkter.
Hur skulle då en annons se ut? Kanske så här...
Vi söker en usability champion
Vi söker dig som vill, kan och orkar arbeta för hög användbarhet i våra system/produkter. Du är den som bär användbarhetsarbetet framåt, som ansvarar för användbarheten i våra projekt, som driver utveckling av metoder och tekniker för att förbättra användbarhetsarbetet ytterligare.
Kort sagt, du är en självklar auktoritet inom användbarhetsområdet, är både visionär och missionär samt står oförtröttlig på användarnas sida!
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:
| Länktyper på denna sida: | PDF-dokument |