Gruppen gick tillsammans igenom de olika läsavsnitten där vi i logisk ordning tog upp nyckelord som vi identifierat och så klart nyckelord (HCI-teori) som vi fått som riktmärken inför seminariet. Vi samtalade och diskuterade kring de olika termerna och avsnittens syfte och nytta för oss i det här projektarbetet - för att bland annat försäkra varandra om att vi förstått innehållet och hjälpa & uppmuntra varandra att omsätta så mycket nyttigt som möjligt i projektet.
Vi började med kapitel 13 där vi ansåg huvudfokus var delat mellan vad, var, varför, hur saker kan utvärderas och betoningen av att alltid återgå, reflektera och bygga vidare på det som vi gjort i projektet tidigare - alltså implementera och att dra nytta av en iterativ process.
Vi ansåg att vi hela tiden jobbat på det här sättet då vi vanligtvis börjar de olika träffarna (övningar, seminarier, egna träffar) med att briefa alla om vad vi gjorde sist. Det här har två syften: info till den som eventuellt inte kunde vara där & för att korta ner dödtiden i början/accelerationssträckan till dess att vi börjar driva projektet framåt och vidare igen.
Vi reflekterade även lite över In-the-wild observationer/utvärdering eftersom det upplevdes vara det mest relaterbara för oss, på grund av intervjuerna (vår främsta input-källa utöver det kursen erbjudit) vi genomförde på plats i Vasaparken.
Kapitel 15 hade ett gäng ord och koncept som vi lade tid på att förstå/utreda. Det främsta exemplet var ‘Heuristik’ (Heuristics) som vi översätter till accepterade principer med erkänt mätbart resultat.
Vi tyckte också att det var spännande hur det lades fram att det inte nödvändigtvis krävs så många experter/testare för att ändå upptäcka en stor del av befintliga problem i användargränssnitt och/eller olika människa-dator system. Enligt en del i kapitlet går det med tre till fem personer att uppmärksamma ca 75 % av användarproblemen - och det känns väldigt bra och inspirerande då det antalet testare inte är så svårt att uppnå. Då kan det tillochmed vara möjligt för oss att vara lite kräsna i urvalet av testare istället för att bara välja några random personer som råkar vara i närheten (undvika “bocka av en uppgift från en lista”-mentalitet). Vi känner ju nu lite olika personer på KTH eller i Stockholm (Vasaparken) som kan testa, identifiera och ge svar/lösningar till olika förutspådda & nya problempunkter.
Vi pratade lite kort om metoden inspektion - alltså att utan direkt anknytning till användaren analysera & utvärdera vad det nu handlar om - och att blanda in experter som genom deras erfarenhet vet eller kan förutspå ungefär vad som kan gå fel och/eller olika användares beteénden. Det som boken kallar för predictive methods.
I samband med det kom vi även in på Analytics & statistics (kartlägger användningen utan att användaren blandas in eller i vissa fall vet om det) och pratade lite om vi - i och med det egna projektet - har möjlighet/rättighet att logga beteénden eller åsikter då det är barn det handlar om och i viss mån möjligtvis även politiskt-kopplade åsikter.
Kort bakgrund: vi har mellan ÖVN 3 och SEM 2 haft en träff där vi beslutade att gå vidare med ett koncept där vi tänker ta fram en mjukvara för att barn & skolklasser skall kunna planera, bygga & ge förslag till förbättringar av nya eller befintliga parker.
Vi ansåg att, eftersom huvudsyftet för vår produkt är att involvera yngre i stadsplanering och utformningen av parker, vi därför inte direkt gör större intrång på deras integritet. Det går ju så klart även att inkludera en terms & agreement ruta så användaren får godkänna (i samråd med sina föräldrar/lärare om så krävs). Alternativt att användaren kan välja att vara anonym.
Slutligen för det här kapitlet pratade vi några minuter om Fitts' law. Det mest nyttiga vi sade här var att det är lämpligt att vi exempelvis placerar nästkommande knapp (i menyer eller mellan sidbyten) på samma ställe så det direkt blir en logisk koppling och den ytan “ägs” av samma funktion som på föregående sida.
Angående ISO 9241-210 så pratade vi om de olika direkta fördelarna med att hålla fokus på human-centered design under framtagningsprocessen. Vi återkopplade till ett föreläsningsexempel där skillnaden mellan user-centered och human-centered lätt identifierades genom en mjölkningsmaskin. I user-centered ligger fokus på kossan medan i human-centered ligger fokus på människan/människorna kopplade till det här scenariot (vilka i det här fallet annars blir andrahandsanvändare).
Förutom att Human-centered approachen sparar/tjänar in pengar för projektet & kunden så skapas även bättre och trevligare förutsättningar kopplade till den sociala delen. Genom att exempelvis produkten/tjänsten mer troligt blir ganska trevlig att använda.
Vi gick igenom definitionen av usability; “extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use” och pratade om effectiveness och efficiency, hur de orden översätts till svenska (till synes samma ord effektivitet) men hur effectiveness framförallt utgår från i vilken mån målen uppnås och efficiency är kopplat till mängden resurser som förbrukas relativt uppfyllandegraden av målen.
Vi listade de sex grundprinciperna för användarcentrerat projektarbete
- djup förståelse av användare, uppgift, miljö
- involvera användare
- design drivs av utvärdering - användare
- processen bör vara iterativ
- design tar hänsyn till hela användarupplevelsen (“start” till “stäng av”)
- arbeta med personer som har olika färdigheter och olika bakgrund/perspektiv
När seminarieledaren kom förbi för att checka av gruppen satt vi och diskuterade Open-source och hur det direkt svarar på många av ovanstående punkter (och även tidigare teori). Hanna sa att Open-source mycket riktigt är vanligt vid utveckling av tjänster/till utvecklingsverktyg men att det samtidigt ju kan bli vad som helst av det - svårt att kontrollera resultatet vilket direkt i de flesta fall av projekt (såväl vårt) är önskvärt.
Om ISO 9241-11 pratade vi först om sätt att mäta användbarheten och hur det för att göra detta och väga in många aspekter krävs att mål, användningssammanhang & målgrupp är bestämda och detaljerat beskrivna.
Mål skall vara kopplade till målvärden som kan jämföras mot befintliga värden och även här finns tre områden att utvärdera
- grad av tillfredsställelse (‘frånvara av obehag’)
- exempelvis genom hur länge användaren stannar på sidan eller hur långt ner användaren scrollar
- eller kort personlig utvärdering efter användingen, typ tummen upp/ner eller olika smiley-symboler som en skala.
- ändamålsenlighet
- effektivitet
där det minst bör finnas ett mål per område/grej (“användaren skall minst klara av … på X sekunder/minuter/…”).
Det andra som vi gjorde här var att gå igenom ett par nyckelord.
Praktisk utvärdering - hur mäter man användbarhet
Några exempel som vi kom på var: är folk sjuka mycket, vilket resultat uppvisas, vilken tid tar det.
Jämförande utvärdering - jmf produkter/tjänster
Hur betygsätts de olika (från användare, från oss som utvecklare, från …)
Vi gick igenom dokumentet Key principles for user-centred systems design och de 12 punkterna som där togs upp men upplevde inte att vi hade något ytterligare att kommentera, som vi inte redan precis tagit upp.
Slutligen så gav vi tid åt diskussionsfrågorna som vi tagit med oss till seminariet.
En fråga var Vilken/vilka utvärderingsmetod/er är mest rimlig och relevant för oss?
Vi tyckte att öppen utvärdering (alltså okontrollerad) skulle fungera bra och att utvärderingen kan implementeras direkt i produkten genom lite mer finurlig form av rate this-funktion (något som går fort och inte känns för krystad eller påtvingade). Ett bra exempel som vi uppmärksammade och kan ha som förebild är Facebook messenger som efter varje telefonsamtal ber att du väljer antal stjärnor (1-5) hur bra du upplever ljudkvaliteten var - detta tar upp hela skärmen och går typ fortare att fylla i än att kryssa bort + att frågan känns relevant för användaren då det ger skenet av att företaget anstränger sig för att leverera bättre kvalite och höja användarupplevelsen.
En annan fråga var Hur kan vi göra tjänsten självförklarande?
Vi pratade om hur vi kan utforma gränssnittet så användaren inte behöver kolla igenom massa tutorialvideor för att överhuvudtaget kunna börja använda produkten. Vi gjorde återkopplingar till bland annat Fitts' lag och kommentarerna vi gjort kring det: ikoner med samma funktion på samma plats. Dessutom så kan vi med goda skäl anta att användaren är van att hantera olika datortjänster/ipad- eller smartphone-appar då vi riktar in oss på unga/skolelever (som med största sannolikhet har en egen telefon/dator/… och varit i nära kontakt med en stor mängd olika IT-tjänster). Vi får helt enkelt se till att ta efter och likna det som gjorts bra i andra tidigare applikationer som vi uppskattar och sedan utföra tester på diverse lämpliga användare.
En tredje fråga som vi tog upp - som vi även varit inne och snuddat på tidigare var Är det ok att vi samlar in åsikter eller data från användare? då det i viss mån/vissa fall kan ses som politiska åsikter och det främst är minderåriga vi riktar in oss på. Vi anser att det inte hindrar användandet (och därför framtagningen av tjänsten/projektet) men att hyfsat enkla åtgärder kan tas för att undvika att det ser ut som att vi är ute efter att samla in information om och från barn.
Inga kommentarer:
Skicka en kommentar