Institutionen för informationsteknologi

Användarcentrering och användbarhet

Nyhet - bok om användarcentrering

Jan Gulliksen och Bengt Göransson har skrivit en bok om användarcentrering; "Användarcentrerad systemdesign". Den finns nu tillgänglig i handeln. Mer information finns på bokhemsidan.

Workshop om användarcentrerad systemdesign

Vår workshop den 22 augusti 2002 genomfördes med deltagare från både industri och forskning. Under dagen gick vi igenom och diskuterade våra tolv principer för användarcentrerad systemdesign.

  • Användarfokus – verksamhetens mål, användarnas arbetsuppgifter och behov skall tidigt vara vägledande i utvecklingen.
  • Aktiv användarmedverkan i utvecklingen – representativa användare skall aktivt medverka, tidigt och kontinuerligt genom hela systemets livscykel.
  • Evolutionär utveckling – systemet skall utvecklas iterativt och inkrementellt.
  • Gemensam och delad förståelse – designen skall dokumenteras med en för alla inblandade parter enkelt förståelig representation.
  • Prototyping – tidigt och kontinuerligt skall prototyper användas för att visualisera och utvärdera idéer och designlösningar med slutanvändarna.
  • Utvärdera verklig användning – mätbara mål för användbarheten och kriterier för designen skall så långt som möjligt styra utvecklingen.
  • Explicita och uttalade designaktiviteter – utvecklingsprocessen skall innehålla dedikerade och medvetna designaktiviteter.
  • Tvärdisciplinära team – utvecklingen skall utföras av effektiva team med en bredd av kompetenser.
  • Användbarhetsförespråkare – erfarna användbarhetsförespråkare skall involveras tidigt och kontinuerligt under hela utvecklingsprojektets gång.
  • Integrerad systemdesign – alla delar som påverkar användbarheten skall integreras med varandra.
  • Lokalanpassa processerna – den användarcentrerade processen skall specificeras, anpassas och införas lokalt i varje organisation.
  • En användarcentrerad attityd – en användarcentrerad attityd skall alltid etableras.

Dagen inleddes med en diskussion om vad användarcentrerad systemdesign/utveckling (ACSU) egentligen är, och huruvida begreppet har slagit igenom i industrin. Listan nedan innehåller några av diskussionspunkterna.

  • Handlar användarcentrering enbart om att involvera användare m h a ett antal tilläggsaktiviteter, eller är det en helt igenom annorlunda process som kräver stora förändringar hos både beställare och leverantör? En snäv ansats byggd på specifika tilläggsaktiviteter för med sig att användarcentrering lätt kan uteslutas ur utvecklingsprocessen. Vi ser också att "användbarhetsexperter" är bland de första som får gå när industrin drar ner. Personer med snäv kompetens och som arbetar med aktiviteter som lätt kan lyftas ut ur processen, kan också lätt "lyftas ut" från företaget. Däremot kan man genom att arbeta med kravprocessen och kalla användbarhet för något annat behålla både arbete och plats i utvecklingsprojekten. En definition av användarcentrering som en helt ny process, kan å andra sidan lätt upplevas som för tung och svår att genomföra. Det blir lätt en läpparnas bekännelse utan förändringar i praktiken. "... ändra arbetssätt, ta med användare, då ser de ut som fiollådor, det finns ingen direkt vilja och ambition."
  • Constantine och Lockwood propagerar för användningscentrerad systemutveckling, dvs att man ska fokusera på användning istället för användare, och i stort sett hålla dem på armlängds avstånd. Men finns det egentligen någon motsättning? Användningen är central men man måste samtala med användarna. Användningscentrering kanske är ett tecken på att man inom systemutvecklingskretsar är "rädda för" att involvera användare eftersom processen då blir mindre ingenjörsmässig och mer svårhanterlig.
  • Vissa menade att de stora problemen ligger i beställningsprocessen, att man saknar användbarhetsexpertis hos beställaren och därför inte kan beställa användbara system. Idag finns kompetens inom användbarhet och ACSU företrädesvis hos leverantören. Användbarhet måste lyftas fram i kravprocessen och denna måste göras mer användarcentrerad.

Vad gäller principerna ansåg många av deltagarna, framförallt praktiker, att tolv principer är för mycket. Det blir svårt att presentera en så stor mängd information för, t ex, en kund eller projektledare utan kunskap och erfarenhet av användarcentrering. Vissa ansåg också att principerna är för omfattande och "gräver för djupt" i själva utvecklingsprocessen. Vi vill dock hävda att de måste vara omfattande, eftersom det krävs en genomgripande förändring av processer och attityder för att arbeta användarcentrerat. Att genomföra enklare tilläggsaktivteter för att "göra det lite bättre" är inte samma sak som att arbeta användarcentrerat.

Resultatet av vårt arbete med principerna, däribland dagens diskussioner, har sammanfattats i ett papper som vi skickat till CHI'03. Vi länkar till pappret så fort som möjligt.

Projektbeskrivning

Under den här rubriken har vi samlat ett antal projekt som är nära förknippade med varann. Varje projekt är i princip en naturlig fortsättning på det föregående, där vi arbetera vidare med de resultat vi får fram. Projekten behandlar alla användbarhet och användarcentrerad systemutveckling i någon form. Syftet med vår forskning är att studera och prova metoder och processer för integrering av användbarhetsaktiviteter och användarcentrering i systemutveckling - i praktiken.

De enskilda projekten är:

Dessa projekt är tätt förknippade med varann, i princip följer de varandra i tid, där ett projekt är en fortsättning på det föregående. Vi har därför valt att beskriva dem tillsammans.

Aktiviteter

För tillfället har vi inga inplanerade nya aktiviteter. Vi uppdaterar då och då vår lista över länkar och andra informationskanaler.

Nedan beskrivs våra aktiviteter tillsammans med intressenter. För beskrivning av vår senaste aktivitet, se ovan.

Workshop om användbarhet och RUP

Hösten (2001) genomförde vi en workshop tillsammans med våra intressenter om användbarhet och RUP. Diskussionerna sammanfattas kortfattat nedan. En något längre sammanfattning samt bidragen från deltagarna finner du på ACSU och RUP.

Dagen inleddes med ett antal korta presentationer om de olika användarcentrerade utvecklingsprocesser som deltagarna använder i sina organisationer/företag. I diskussionerna som följde berörde vi bl.a:

  • Vem har ansvar för användbarhet - i många projekt och organisationer finns personer som till namnet är ansvariga för användbarheten men som sällan ges några befogenheter att fatta beslut eller styra designen.
  • Användare - många deltagare beskrev problem med att involvera användare i processen. Ett problem är då man tar in användare från verksamheten och placerar dem på heltid i projekten. Efter två veckor är de inte längre representativa och de blir istället gisslan.
  • Integrera eller separara - ska användbarhetsarbetet införas med hjälp av specifika roller och arbetsflöden, eller ska det integreras i andra aktiviteter/arbetsflöden? Det finns för- och nackdelar med båda angreppssätten.
  • Användningsfall, krav och prototyper - protypen först och krav/användningsfall sedan eller tvärtom? Vissa menade att det är enbart med via krav och användningsfall som man kan få in användbarhet, medan andra ansåg att kravdrivna (användningsfallsdrivna) processer gärna blir blir otympliga och att benägenheten till förändringar under gång minskar.
  • Attityder - en vanlig attityd bland utvecklare gentemot användbarhet är att man vill ha enkla svar och checklistor.

Efter dagens diskussioner lyckades vi komma fram till några gemensamma slutsatser och frågor

  • För att nå ut med användarcentrering och användbarhet måste man förhålla sig till RUP eftersom den är den förhärskande utvecklingsmodellen för tillfället.
  • Vi behöver definiera de olika begreppen för att kunna föra vettiga diskussioner.
  • Det behövs troligen en roll för användbarhet.
  • Vilken attityd till användare vill vi kommunicera - är de informationskällor enbart eller kan de bidra i design-processen.
  • Många utvecklingsmodeller kräver alldeles för mycket dokumentation. De enda som förstår och läser dokumentationen är de som skrivit den.

Dag om Usability Champion

Den 27 mars, 01, diskuterade vi rollen Usability Champion tillsammans med representanter från våra intressenter. Dagen bjöd på många intressanta idéer, bl a diskuterade vi ansvarsområden för en sådan roll, samt vilka krav på kompetens och erfarenhet som bör ställas på den person som axlar rollen. Nedan sammanfattas diskussionerna, en längre sammanfattning finns på Usability Champion - vem är det?.

Ansvarsområden för en usability champion borde omfatta:

  • Kravarbete - Deltagarna argumenterade för att det är genom kraven man kan få in användbarheten i projekten. Därför är ett självklart ansvarsområde för UC att identifiera krav - UC ska hjälpa beställaren/kravställaren att ställa krav
  • Visualisering - Det ligger också på UC att visualisera dessa krav i form av skisser och/eller prototyper.
  • Design - UC har också ansvaret för designen av "användarens hela upplevelse" - eller systemets beteende.
  • Utvärdering och uppföljning - UC bör 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.

Krav på kompetens och erfarenhet är bl a följande

  • någon form av akademisk bakgrund, samt kunskap inom både beteendevetenskap och datavetenskap
  • känsla för grafisk design
  • erfarenhet av användarcentrerad systemutveckling samt projekledning
  • ledaregenskaper, lyhördhet, respekt, pondus och kommunikationsförmåga

En usability champion ska kunna vara både missionär och visionär, samt problemlösare.

Länkar, böcker, m m

Boken Object Modeling and User Interface Design har kommit ut. Jan Gulliksen och Bengt Göransson (båda UU) samt Magnus Lif har bidragit med ett kapitel om användarcentrering och moderna systemutvecklingsmodeller (t ex RUP).

Nedan listas några länkar som kan vara av intresse.
Länkar om användningsfall och RUP:

  • www.usecases.org - innehåller tips om böcker, länkar till artiklar, mallar, diskussionsforum och annat matnyttigt. Skapad och underhållen av Alistair Cockburn. Cockburn har också skrivit en intressanta och tankeväckande artiklar om varför systemutveckling är så svårt.
  • The Use Case Zone - ytterligare en sajt där man samlat ihop länkar till artiklar, m m. Här finns en hel del om svårigheterna med att skriva bra användningsfall. Ansvarig är Andy Pols. Tyvärr verkar sajten inte ha uppdaterats sedan okt 2000 - en hel del av länkarna pekar rätt ut i svarta hål, men andra lever fortfarande.
  • Essential use cases - användningsfall fast på ett annat sätt. Constantine och Lockwoods sajt om ett annat sätt att skriva användningsfall. Du kan också läsa en intervju med Constantine om ämnet.
  • UnifiedProcess.org - ett forum om RUP. Innehålller ett antal diskussioner om RUP - för att delta aktivt måste du registrera dig som användare. Du kan dock läsa åtminstone delar av inläggen som "gäst". Ansvarig är AxelJosefson & Co AB, ett företag som uppenbarligen lever på att sälja RUP-kunskap.
  • UI RUPture - Kritik mot användningsfallsdriven utveckling kopplat till UI-design. En serie artiklar i uidesign.net där detta är den senaste. Längst ner i artikeln finns länkar till de föregående artiklarna.

Länkar om alternativa sätt att se på systemutveckling

  • Manifesto for Agile Software Development - tröttnat på monumentala, allomfattande metoder och modeller som leder till "documania"? "Going Agile" är svaret. Ett kortfattat manifest, samt en sida som leder vidare till ett antal modeller som säger sig vara agile. Bl a har Martin Fowler skrivit en form av översikt över diverse modeller där han diskuterar deras "agility".
  • OPEN - ett alternativ till RUP
  • eXtreme Programming - något helt annat än RUP

Diverse:

Deltagare

Uppdaterad  2003-07-22 12:11:21 av Erik Borälv.