Modern utvecklingsmetodik TNMK31 Användbarhet HIIA20 Användbarhet med kognitiv psykologi Teknikdriven design kontra användarcentrerad design Traditionell filosofi Teknikdriven Fokus på komponenter Individuella bidrag Fokus på intern arkitektur Kvalitetsmått genom systemets brister Lösningarna styrs av funktionella krav Användarcentrerad filosofi Användardriven Fokus på lösningen Tvärdisciplinärt teamarbete Fokus på användbarhetsattribut Kvalitetsmått genom systemets fördelar Lösningarna styrs av förståelse för användningssammanhanget Martin Karlsson marka@itn.liu.se K7522 011 36 34 63 2006-05-02 Martin Karlsson - Användbarhet 2 5 stadier som visar på medvetenheten runt användarcentrering och användbarhetstänkande 1. Fientlighet mot användbarhet Utvecklare vill inte höra om användares behov då det ger merjobb för deras del Den enda bra användaren är en död användare Dock kostnadseffektivt på kort sikt Går ej att införa användarcentrering i en sådan organisation om de inte själva inser behovet 2. Utvecklarcentrering Företaget inser att användbarhet är bra Designteamet litar dock på sin egen intuition om vad bra användbarhet är Alla utvecklare är ju också människor (?) Relativt lätt att förespråka mer användarcentrerade metoder Företag brukar fastna i ungefär 3 år i det här stadiet 2006-05-02 Martin Karlsson - Användbarhet 3 2006-05-02 Martin Karlsson - Användbarhet 4 3. Skunkwork usability Företaget inser att man inte kan lita på designteamets föreställning om användbarhet Mycket beslut tas dock på samma vis Man kanske tar in några användare i varje projekt och låter dem testa lite Man förlitar sig på utvärderingar av resultatet, och inte så mycket under processens gång Användbarhetsarbetet anses vara enkelt, och inte så komplicerat som vi vet att det är 4. Projekt med användbarhetsbudget Man planerar för användbarhet, liksom man planerar för annat kvalitetsarbete Huvudmetoden är användningstest och lagom många typiska användare rekryteras Dessa test utförs dock sent i processen För att få ledningen att inse att man måste göra mer, så krävs det att man mäter mer noga hur användbarhetsaspekten påverkar försäljningssiffror 2006-05-02 Martin Karlsson - Användbarhet 5 2006-05-02 Martin Karlsson - Användbarhet 6 1
5. Ledningsplanerad användbarhet Det finns en officiell användbarhetsgrupp som leds av en användbarhetsspecialist som äger all användbarhetsutveckling i företaget Ekonomin är fortfarande inte tillräcklig för full användarcentrering så användbarhetsspecialisten får fokusera på vissa projekt Fokus är fortfarande på användningstest 6. Systematisk användbarhetsprocess Företaget har en metod för att spåra förbättringar av användbarheten i hela processen, ex. Användbarhetsmål Iterativ design är mer vanlig på den här nivån, i alla processer på företaget 7. Integrerad användbarhetsprocess Alla sysslar med användbarhet på företaget Alla projekt börjar med fältstudier Istället för att bara spåra förbättringar så mäter man numera kontinuerligt alla kvalitetsaspekter i processen För att komma hit har företaget spenderat kanske 6-7 år i de tidigare nivåerna 2006-05-02 Martin Karlsson - Användbarhet 7 2006-05-02 Martin Karlsson - Användbarhet 8 8. Användarcentrerad ledning och styrning Användardata styr inte bara individuella projekt utan även vilka projekt som ska genomföras Användbarhetsmetoder påverkar inte bara projektet utan företagsstrategier och andra aktiviteter långt utanför gränssnittsdesign Få företag har nått den här nivån, så troligen tar det runt 20 års aktivt användbarhetsarbete att nå denna nivå av användarcentrering Moderna utvecklingsprocesser De mest kända (RUP) Dynamic Systems Development Method () Extreme Programming (XP) Andra som ni får läsa om i kursboken Object, View and Interaction Design (OVID) Logical User Centered Interaction Design (LUCID) DELTA-metoden Usage-centred design Praktiskt Användarmedverkan vid Systemutveckling (PAS) 2006-05-02 Martin Karlsson - Användbarhet 9 2006-05-02 Martin Karlsson - Användbarhet 10 Knuten till objektorienterad systemutveckling Fokus på systemarkitekturtänkande Baseras på 6 stycken goda vanor inom systemutveckling: 1. Utveckla mjukvara iterativt 2. Förvalta kraven 3. Använd komponentbaserad arkitektur 4. Kontrollera mjukvarukvalitet 5. Kontrollera förändring Det stora vattenfallet är omgjort till en rad mindre och väl definierade vattenfall med hjälp av evolutionär prototyping De iterationer som utförs är snarare inkrement, då man bygger upp delar av systemet (komponenter) Därmed kan man påstå att iterativ utveckling inte nödvändigtvis bedrivs inom ramen för RUP 2006-05-02 Martin Karlsson - Användbarhet 11 2006-05-02 Martin Karlsson - Användbarhet 12 2
RUP är uppdelad i fyra faser, som är sekventiella Faserna är inception (förberedelse), elaboration (utredning), construction (konstruktion) och transition (överlämning) Dessa faser består av ett antal iterationer Arbetet inom varje fas bedrivs inom ramen för ett antal discipliner Varje disciplin innehåller ett arbetsflöde med aktiviteter Denna typ av utvecklingsprocess kallas för tungviktsprocess 2006-05-02 Martin Karlsson - Användbarhet 13 2006-05-02 Martin Karlsson - Användbarhet 14 Det finns ingen disciplin som handlar om användbarhet eller användarcentrering (dock har författarna av kursboken hittat på en egen som passar in i RUP) Användarcentreringen baseras på prototyping av olika slag samt användningsfall (use cases) A use case specifies a sequence of actions, including alternatives of the sequence, that the system can perform, interacting with actors of the system Användningsfall kan vara beskrivna i text Ser då ut som scenarion men har funktionen att dokumentera redan färdiga funktioner istället för att utvärdera sådana som formas... eller med hjälp av modelleringsspråket UML (Unified Modeling Language) 2006-05-02 Martin Karlsson - Användbarhet 15 2006-05-02 Martin Karlsson - Användbarhet 16 Det finns två syften med användningsfall Att beskriva användarens interaktion med systemet från en användares perspektiv Att beskriva systemets uppförande från en systemdesigners perspektiv Det är dock en beskrivning baserad på utvecklarnas villkor, även om den ska beskriva användarnas interaktion Den utvecklare som skriver användningsfallet sätter sig säkert in i användarens situation (kanske inte på rätt sätt), men systemet får högre användbarhet i slutändan Användningsfall blir oftast ett kontrakt mellan utvecklare och användare, och det är svårt att förstå konsekvenserna av dessa Hela definitionen av användningsfall är oklar, det finns många tolkningar och detta försvårar ju självklart ytterligare för en användare eller en kund att förstå vad de skriver under Dock är inte textbaserade kontrakt, exempelvis kravspecifikationer av olika slag, det bästa heller, då de ljuger. Text kan formuleras på mycket tvetydiga vis, och enda utvägen är egentligen en ordentlig interaktionsdesign (principdesign) 2006-05-02 Martin Karlsson - Användbarhet 17 2006-05-02 Martin Karlsson - Användbarhet 18 3
Man delar upp systemet i mindre delar med användningsfall Vilket är mycket bra för utvecklarna, att få en mindre del att arbeta med, de känner då att de utför något bra Men det är en fara att man abstraherar för långt och vissa saker faller mellan stolarna Detta leder ofta till vad som kallas för fragmenterade användargränssnitt, det finns inget flöde genom hela systemet RUP med användningsfall är ett steg åt rätt håll, men det är fortfarande för tungrott och tvetydigt 2006-05-02 Martin Karlsson - Användbarhet 19 2006-05-02 Martin Karlsson - Användbarhet 20 Dynamic Systems Development Method är en process med nio principer som bas 1. Active user involvement is imperative 2. teams must be empowered to make decisions 3. The focus is on frequent delivery of products 4. Fitness for business purpose is the essential criterion for acceptance of deliverables 5. Iterative and incremental development is necessary to converge on an accurate business solution 6. All changes during development are reversible 7. Requirements are baselined at a high level 8. Testing is integrated throughout the life-cycle 9. A collaborative and co-operative approach between all stakeholders is essential har fem faser Feasibility study, business study, functional model iteration, design and build iteration, implementation 2006-05-02 Martin Karlsson - Användbarhet 21 2006-05-02 Martin Karlsson - Användbarhet 22 bygger på användarmedverkan Men man har inte definierat något sätt att hitta ett representativt urval av användare Man förespråkar ett urval där man fokuserar på ett effektivt arbete, framför allt i form av workshops Dessa workshops har dock inget krav på medverkan av representativa användare Extreme Programming XP är en iterativ lättviktsmetod för små till mellanstora projektteam som utvecklar mjukvara som antingen är vagt specificerad eller där förutsättningarna kan ändras utan förvarning XP lovar två saker Att programmerarna varje dag ska få hålla på med något de anser vara meningsfullt. Att de ska slippa bemöta otäcka situationer ensamma och att de får ta besluten som de kan ta bäst själva Att kunden och ledningen får ut mesta möjliga värde ur varje programmeringsvecka. Att kunden och ledningen får se resultat under utvecklingens gång och att de ska kunna ändra projektets riktning när det behövs 2006-05-02 Martin Karlsson - Användbarhet 23 2006-05-02 Martin Karlsson - Användbarhet 24 4
Extreme Programming XP består av ett antal sedvanor (practices) som är baserade på fem stycken värden (values) XP är ingen metod med ett givet ramverk och givna aktiviteter, därför finns egentligen ingen tydlig användarcentrering alls inom metoden Användare förutsätts deltaga i planeringsfasen och interaktionsdesigners förutsätts medverka i processen Extreme Programming En interaktionsdesigner inom ett XP- team ska Välja systemmetafor Skriva stories tillsammans med kund Analysera verkliga användare och deras behov Arbeta iterativt Det finns inget i modellen som hindrar en interaktionsdesigner från att utföra sina vanliga aktiviteter. Detta är upp till XP- teamet vad de vill fokusera på 2006-05-02 Martin Karlsson - Användbarhet 25 2006-05-02 Martin Karlsson - Användbarhet 26 5