Design af interaktion

Hvorfor? Det virker måske lidt naivt, men at spørge hvorfor der er behov for et interaktionsdesign, giver svar på hvordan brugeren opfatter programmerne. Alle kendte programmer har et interaktionsdesign, dog har de fleste programmer nogle underprogrammer / funktioner, som ikke har et interaktionsdesign. Interaktionsdesignet skal give brugeren muligheden for at anvende systemet. Løbende i udviklingsprocessen af et program, finslibes interaktionsdesignet, således den passer over ens med den ønskede interaktion.

Behov For at en præcis og anvendelig interaktion kan finde sted, skal behov og krav kortlægges. Der er tit, hvor IT-systemer ikke kan opfylde brugerens behov eller krav, fordi udvikleren ikke forstod hvad brugeren skulle bruge IT-systemet til. Udviklerne har tendens til at fokusere på tekniske udfordringer end systemets brug. Udgangspunkt Identificer behov og krav Generer design Evaluer design Byg interaktiv version Resultat: Færdigt design

Stakeholder De fleste programmer anvendes i dag af flere millioner mennesker. Dette kan være fra Facebook (1,5 mia. brugere) til Microsoft Office (1,2 mia. brugere) og til den lokale bank, hvor der også eksisterer et IT-system. I hver af disse er det muligt at lave en stakeholder-analyse. En stakeholder, er en person, som har interesse i systemet, eller i brugen heraf.

Stakeholder Eksempel: Et IT-system kunne være bankens IT-system, som skal bruges af ansatte til styring af kundeinformationer og finansielle midler. Primære stakeholders: Personer, der direkte bruger systemet Eksempel: Ansatte i banken Sekundære stakeholders: Personer, der ikke bruger systemet, men bliver påvirket heraf Eksempel: Kunder i banken (privatpersoner og virksomheder) Tertiære stakeholders: Personer der indirekte påvirker eller påvirkes af systemet Eksempel: Konkurrenter, aktiemarkedet, forsikringsselskaber, aktionærer

Stakeholder Opgave 1: Vi kan forestille os, at vi skal udvikle et IT-system, som et flyselskabs ansatte og ansatte i rejsebureauer kan bruge til bookning af flybilletter. Beskriv de tre stakeholder typer. Den primære er rejsebureauets ansatte Den sekundære er dig (kunden) når du ringer til dem Den tertiære det er flyselskabets ansatte Opgave 2: Overvej, hvordan det ændrer de tre grupper af stakeholdere, hvis vi i stedet designer et system, som kunderne selv kan benytte til bookning af billetter. Den primære er kunden selv Den sekundære er rejsebureauets ansatte Den tertiære er flyselskabets ansatte Tid: 10 minutter

Persona Det er muligt at klarlægge brugernes behov, som vi i starten af faget fandt frem til. Her lægges der primært vægt på de primære og sekundære stakeholders. I dette emne taler man om to teknikker, persona og scenarier. Persona: En beskrivelse af en konkret påfundet person, som om der var tale om en virkelig person. Ideen med at bruge personas er at tvinge designere af IT-systemer til at tænke på rigtige brugere, når de beskriver kravene til systemet, så de ikke kun fokuserer på de tekniske krav. Opgave: Løs ”7.02a Persona” Tid: 20 Minutter

Scenarie Scenarie: Et scenarie er en beskrivelse af den menneskelig aktivitet ved IT-systemet, trin for trin. Eksempel: Et system skal anvendes for at fastlægge et møde for nogle personer. Brugeren tilføjer brugerne ved hjælp af navnene og tilføjer mødets varighed og hvornår det ca. skal starte. Systemet skal herefter tjekke, hvorvidt alle kan deltage og melder tilbage til brugeren med en række datoer. Herefter kan brugeren vælge et tidspunkt. Som en option, så vil det være muligt at sende mødeindkaldelsen vha. mail.

Generering af design Når persona/scenarie er opklaret og behov og krav kendes, så starter udviklingen af designet. Der er stort fokus på, hvordan brugergrænsefladen skal se ud (skal der være mus, tastatur, touch screen?), hvordan skal brugergrænsefladen virke (skal den være meget nemt, eller skal den være for avancerede brugere?) Udgangspunkt Identificer behov og krav Generer design Evaluer design Byg interaktiv version

Generering af design Typisk vil brugergrænsefladen blive testet i (næsten) alle mulige scenarier. Det kan gøres ved hjælp af prøvekørsler - eksempel på emulatorer:

Generering af design Alle programmer gennemgår prøveperioder – også kaldet trials. Programmer vil blive delt op i alfa og beta prototyper, som i nogle særtilfælde gøres tilgængelig for offentligheden. Prototyper kan kategoriseres i tre grupper, som del af ”Generer design” i modellen: Papirprototype Fysisk prototype Kørende prototype

Generering af design Papirprototype: En prototype af programmet, lavet på papir. Illustrationer af skærmbilleder og detaljer hvordan interaktionen er. Ved hjælp af flere sider papir, kan programmets opgave illustreres. Fysisk prototype: Der er tale om en model i original størrelse. Dette er godt, hvis produktets omfang og beliggenhed i hånden / på bordet, skal testes. Her er fokus på hardware, dog ikke på software. Den kan kombineres med en papirprototype. Kørende prototype: Test af software (emulatorer eller i fysisk model). Der vil ofte være tale om enkelte dele der afprøves. Opgave: Overvej hvad en prototype kan bruges til at undersøge, og hvad den ikke kan. Tid: 5 Minutter

Evaluering af design Når en prototype er klar, skal den evalueres. Dvs. prototypen testes for dens usability (vær opmærksom på, at det afhænger af testpersonen) Usability kan defineres (Molich, 2002) som: Let at lære (ligger vægt på indlæring) Let at huske Effektivt at bruge Forståeligt Tilfredsstillende at bruge

Evaluering af design Let at lære: Fokus på indlæring og den nødvendige tid for at lære programmet. Eksempelvis kan en dankortautomat betjenes uden stor indlæring. Let at huske: Kompetencen skal ikke forsvinde, efter at systemet er bleven lukket ned. Det afhænger stærkt af brugen af systemet. Facebook kontra skatteopgørelse. Effektivt at bruge: Systemet skal være med til at løse problemstillingen hurtigt. Hurtigt, er en overordnet definition og afhænger af problemstillingen. Den skal yderligere sikre, at problemet løses rigtigt.

Evaluering af design Forståeligt: Programmet evalueres hvorvidt brugeren forstår, hvad programmet reelt gør, brugeren skal altså ikke være i tvivl, at et tekstdokument er gemt, hvis vedkommende gemmer. Tilfredsstillende at bruge: Den subjektive oplevelse. Tænk for eksempel på biler, hvor funktionen (at kunne køre) og de første fire punkter er meget ens fra bil til bil. Men den store forskel er den subjektive oplevelse. Opgave: Tag et system, du kender godt og vurder, om det er brugbart. Du kan tage hvert af de fem elementer i definitionen og overveje, hvordan systemet klarer sig på det punkt. Tid: 5 Minutter

Evaluering af design Evalueringen af usability omfatter typisk 6 trin: Grundlag Planlægning Forberedelse Udførelse Fortolkning Dokumentation Fastlægger formålet og fremgangsmåden i evalueringen Den praktiske klargøring af udførslen Et individ (testperson) afprøver prototypen / endelig version Usability-problemer identificeres fra observation Rapportskrivning af evalueringen

Evaluering af design Opgave: Løs ”7.02b Usability-evaluering” Tid: 20 Minutter

Nye teknologier Nyere teknologier medfører nye modeller, derfor udvikles også begrebet usability, for at håndtere den stigende anvendelse af IT-systemer i hverdagen. Fun Emotionally fulfilling Rewarding Supportive of creativity Aesthetically pleasing Motivating Helpful Entertaining Enjoyable Satisfying Usability goals Efficient to use Effective to use Safe to use Have good utility Easy to learn Easy to remember how to use