HCI

Håndbog for forretningsarkitekter & enterprise arkitekt

Forretningsarkitekten forstår forretningen, teknologierne og kan arbejde med strategier og processer på tværs af organisationen.

Enterprise arkitekten kan udvikle en fremtidig enterprise arkitektur, der kan forstås af forretningen så den kan blive fulgt i praksis.

Human computer interaction

HCI er en forkortelse for Human computer interaction, eller på dansk menneskelig computer interaktion og handler om, som navnet indikerer, hvordan mennesker interagerer med computeren (teknologien).

I det kommende afsnit beskrives hvilke metoder og teorier der bør overvejes under udvikling af nye applikationer.

 

Terminologien der bruges hedder ”brugervenlighed og brugeroplevelse” (usability and user experience) og handler om brugervenligheden og selve oplevelsen af at bruge teknologien. Brugervenlighed handler om, at slutbrugeren kan finde ud af at bruge teknologien på en hurtig og nem måde, hvor brugeroplevelse handler om, hvor lækkert det føles for slutbrugeren, mens han/hun gør det (hvilket begge er subjektivt).

 

Overordnet så drejer HCI sig, om at systemudvikle, hvor man udvikler på baggrund af forståelse af:

brugeren → design→ udvikle en prototype→ og evaluering i en iterativ proces. Figur 1 illustrerer udviklingsmodellernes forskellige faser.

 

 

 

 

 

 

 

 

 

 

Figur 1: Interaction design livscyklus.

 

Kritisk så er denne udvilkingsmodel en funktionalistisk udviklingsmodel, fordi den bruger en ”jeg ved, at jeg ved” tankegang, og altså føjer den samme opskrift hver gang.

 

 

Motivation og teknologiaccept

Motivation og teknologiaccept afhænger af hvordan brugeren oplever innovationen (det som udvikles).

 

Barnes og Huff, 2003, har udviklet teknologi-accept-modellen, som kan forudsige udfaldet af brugernes vilje, til at optage innovationen (se figur 2).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figur 2: teknologiaccept

 

Barnes og Huff mener at en persons adoption af en teknologi, afhænger af deres erfaringsgrundlag og andres påvirkning. Brugere vil nemlig sjældent tage en teknologi i brug, medmindre de kan se en rigtig god grund til at bruge den. Det skal give noget ekstra at bruge den, og den skal passe ind i hverdagen og de andre teknologier, man anvender. Det er også vigtigt, at en teknologi giver en god brugeroplevelse, for derved at øge brugen af denne. Det er defor, også vigtigt at teknologien er brugbar for brugeren, samt at dens kompleksitet stemmer overens med brugernes kompetencer. Fokus er at få brugeren af en innovation til at købe den, beholde og bruge den.

Nyttigheden af innovationen vil kunne måles i den relative fordel. Brugbarheden vil give sig til udtryk i innovationens kompatibilitet, hvordan teknologien passer ind i brugerens liv og vaner, dens kompleksitet og observerbarhed. Med kompleksitet menes hvor nem teknologien er at anvende, og observerbarhed betyder hvor nemt det er for brugeren, at se resultater af innovationen. Disse faktorer vil have stor betydning for hvorvidt, brugeren vil vælge at anvende innovationen og derfor er dét parametre, vi skal være meget opmærksomme på, gennem hele processen. Vi vil især i udarbejdelsen af prototypen, have fokus på disse parametre, som kan være altafgørende i udviklingen og succesen af vores applikation.

 

 

Drama

Drama i ”Human Computer Interaction” er et scenarie hvor man forestiller sig, hvordan interaktion med applikationen vil foregå. Man ”leger” at man har opfundet applikationen og forestiller sig forskellige interaktioner med applikationen, ligesom en drejebog for en filminstruktør. Ved dette værktøj, opdager man forskellige muligheder og risici, der ville være forbundet med applikationen, i en given situation. En sådan dramatisering hjælper projektdeltagerne til at fokusere på det samme, analysere overfladisk samt hjælpe til at finde forskellige designmuligheder.

 

Drama er et rigtigt stærkt og centralt værktøj for applikationens videreudvikling. Ved at projektets medlemmer, får skitseret applikationens brugerformål har man et fælles holdepunkt, som er grundlæggende for resten af projektet. Det er i denne fase at medlemmernes egne ideer til applikationen bliver fremlagt og analyseret.

Efter Dramafasen er innovationens hovedfunktion identificeret, og gruppens deltagere er nu afklarede omkring fokus og hvad applikationen skal kunne gøre.

 

Personas

En persona er en beskrivelse af en fiktiv stereotyp, der tager udgangspunkt i målgruppen og derfor repræsenterer de træk målgruppen har.

En persona indeholder segmentets kontekst, dens sociale og kulturelle holdninger og er med til, at give en mere dybdegående empatisk identifikation af dem. Man får altså en bred forståelse for hvem man har med at gøre, og derefter er man bedre i stand til at sætte sig ind i deres sted i en given situation.

 

Scenarier

Scenariet er et kommunikationsredskab, mellem designgruppen og testpersonen, via en fortælling omkring hvordan han/hun agerer i en given situation.

Scenariet indeholder en begyndelse, hvor der er en præsentation af brugeren og sted. En midte, der fortæller motivationen (kan være en sindstilstand) bag handlingen og en slutning, der beskriver slutresultatet, som kan være negativt eller positivt.

 

Scenariet og persona går hånd i hånd, og ud fra en empirisk forståelse af brugeren, kan man bedre forstå hvordan personaen agerer i en given situation. Denne information giver designere en ”kravspecifikation”, ud fra brugerens synspunkt.

 

Prototyping

En prototype er en måde at udtrykke en design idé på, så hurtigt som muligt. Prototypers detaljeringsgrad kan variere helt fra papirsketchs (low-fidelity) til avancerede teknologiske modeller (high-fidelity). Det vigtige er, at det er en hurtig måde at afprøve et design på. Om prototypen bliver det endelige produkt, kan være meget forskelligt, men det er et led i en iterativ proces, som leder til et færdigt produkt. Via test af prototypen, kan man opnå hurtig feedback fra brugerne og derved ændre, og tilpasse til dennes respons. Deraf kan man også spares for en del omkostninger, fordi man ikke er på det forkerte spor for længe.

En anden grund til at man foretager prototyping, er fordi ideer kan virke perfekte i ens hoved, mens virkeligheden kan se helt anderledes ud når de skal realiseres.

Det er også en god hjælp for at undgå, at se de kodemæssige eller fysiske begrænsninger ved sit design. Ved et samarbejde med udviklerne af en teknologi, er det også en stor hjælp så man kan visualisere, hvad man gerne vil have og derved overlevere sine tanker.

Interaction prototyping er når man interagerer med prototypen. Det vil sige at man leger at applikationen fungerer, og dermed interagerer med den. Denne interaktion giver projektgruppen, bedre mulighed for at udtrykke det, de har så tydeligt oppe i deres eget hoved, ud til resten af gruppen.

 

Såvel som en prototype kan være low-fidelity, kan et storyboard til scenarieopbygning være low-fidelity, for bedre at underbygge en low-fidelity prototype, da denne mangler en masse detaljer, hvorfor de scenarier man gennemløber heller ikke kan omfatte detaljeret brug af et produkt.

 

Evalueringsteori

Evaluering af mobile enheder er væsentligt mere kompliceret end desktop-enheder, fordi mobile enheder kan blive udsat for en del flere kontekster.

Det er vigtigt at evaluere designideer, så hurtigt og ofte som muligt, for hele tiden at holde sin løsning så meget i overensstemmelse med det analyserede, som muligt.

Evaluering handler om at sætte sit design ind i en reel kontekst, for at afprøve det. ”lige meget hvor godt du tror dit design er, vil det altid have fejl”

Evaluering handler IKKE om at teste design-ideer, men om at teste rigtige designs i rigtige kontekster (hvilket sagtens kan være low-fidelity prototyper).

 

Ting der skal tages i betragtning når man vælger evalueringsteknik:

  • Graden af fidelity af designet
  • Hvem vil du benytte til din evaluering (eksperter, end-users, erstatninger for end-user)
  • Hvor vil du foretage din evaluering (i et kontrolleret laboratorium miljø, i den rigtige kontekst eller begge). Det anbefales for mobile enheder i hvert fald at lave en evaluering, under de forhold som man regner med at designet bliver udsat for. Herigennem vil det også være nemmere at finde muligheder for designet, som man ikke havde tænkt på, frem for at lave det i et laboratorium, hvor fantasien måske ikke lader sig udfolde nær så meget.
  • Hvilken ”vægt” ønsker man af sine resultater. Forskellige typer af evalueringer giver forskellig tyngde i resultaterne. Alt fra små anekdotebeskrivelser og noter, til videre udvikling og helt ud til komplekse statistiske analyser, der giver rationelle kvantitative videnskabelige beviser på, hvor godt et design performer.

 

Tænke - højt - test

En tænke-højt-test er en brugertest, som gør observatøren i stand til at høre hvad brugeren tænker.

Den udføres ved at brugeren skridt for skridt ”siger sine tanker”. Brugeren skal altså ikke kommunikere med observatøren, blot sige hvad der går igennem hans/hendes hoved, ved udførsel af scenariet.

En sådan test, giver information omkring hvilke ting (for eksempel i et program), der volder problemer eller spekulationer for brugeren. Omvendt er den også oplysende omkring hvilke elementer, der er underholdende eller nemme for brugeren.

Hvis man gerne vil vide hvordan selve programmet bliver modtaget af slutbrugeren, er en ”tænke højt test” et vigtigt stykke værktøj, men det skal siges at testen skal udføres på en person, der passer til slutburgerens persona og gerne på flere, for at få en bredere mening.

 

Når man har designet en low-fidelity prototype kan man, via en testperson, udføre forskellige interaktionstests med applikationen. Vi kan dermed blive klogere omkring brugerens evner til at interagerer med det nye design, og hvor designet skal tilrettes for bedre at understøtte brugeren.

 

Bemærk at designerne vil ofte se sig blindt på designet, som virker simpelt og overskueligt for dem når de kender alle aspekter i det, hvorfor en tænke - højt - test er en billig måde at fange de største designfejl.