inf1500 - introduksjon til design, bruk, interaksjon ... · inf1500 – introduksjon til design,...

INF1500 – Introduksjon til design, bruk, interaksjon Utviklingsprosesser og tilnærminger 1 |

01.09.14

INF1500 - Introduksjon til design, bruk, interaksjon Utviklingsprosesser og tilnærminger 01. september 2014 Institutt for Informatikk, Universitetet i Oslo [email protected]


01.09.14

Oversikt • Praktisk informasjon: tilbakemeldinger, konkurranse, grublegruppa, Maker Faire etc.

• Obligatoriske oppgave 0

• Kapittel 9: • Tilnærminger til design

• Basisaktiviteter i interaksjonsdesign

• Kategorier av brukere i UCD

• Tradisjonell systemutvikling

• Livssyklusmodeller i HCI

• Eksempler på ulike prosesser og tilnærminger (Apple, Google og Microsoft)


01.09.14

Tilbakemeldinger • Det er viktig at dere gir oss tilbakemelding på kurset underveis:

• Hvordan er forelesningene?

• Hvordan er gruppetimene?

• Hvordan er de obligatoriske oppgavene?

• Hvordan er ukesoppgavene?

Kontaktpunkter

• Kurs, pensum, eksamen, lærebok foreleser

• Ukesoppgaver, obligatoriske oppgaver, gruppetimer, sykdom, utsettelse gruppelærer

• Lenger sykdom, tilrettelegging, forsinket innlevering studieadministrasjonen

• Anonyme henvendelser, generelle tilbakemeldinger kontaktstudent

Ingrid Thorkildsen [email protected]


01.09.14

Konkurranse

• Holdes på fem tilfeldige forelesninger i løpet av semesteret (i tillegg til gruppetime og midtveis)

• Helt frivillig å delta!

• Man bruker sitt eget brukernavn når man deltar

• 7 spørsmål, og man får 2 poeng per riktige svar + (1 bonuspoeng) maks 15 poeng per forelesning

• Premieres på siste forelesning


01.09.14

Grublegruppa

• Et ekstratilbud for de flinkeste studentene våre…

• Hvor mange er interessert?

• En dobbelttime 5-6 ganger i løpet av semesteret (med meg/gruppelærer)

• Det blir sendt ut en Doodle på e-post for å finne et tidspunkt

• Eksempler på tematikker:

• Ekte cases med oppfølging fra «eksperter»

• Mer diskusjon og reelle problemstillinger enn i ukesoppgavene

• Tidligere gode/dårlige obligatoriske oppgaver

• Tidligere gode/dårlige eksamensbesvarelser

• Forskningsartikler


01.09.14

Foto: Sjur Fredriksen / fredriksenphoto


01.09.14


01.09.14

Lysark • Fargeforklaring på lysark:

• Rød – MÅ læres. Kjernepensum.

• Oransje – BØR læres. Statarisk pensum.

• Grønn – KAN læres. Kursorisk pensum.


01.09.14

(UXMastery.com)


01.09.14

Oppstart

Krav

Spesifikasjon

Design

Implementasjon

Testing

Tradisjonelt har vi begynt å tenke på utforming her…

Implementert grensesnitt her…

Testet løsningen her…

Fungerer det?

Når bør vi begynne å tenke på design?


01.09.14

Hva inngår i interaksjonsdesign? • Prosess:

• Målorientert problemløsning

• En kreativ og skapende aktivitet

• Det må tas beslutninger hele veien

• Det finnes ulike tilnærminger


01.09.14


01.09.14

Fire tilnærminger • Det finnes fire tilnærminger til design:

• User-centered design (brukerorientert design)

• Activity-centered design (aktivitetssentrert design)

• Systems design (systemdesign)

• Genius design (genidesign)

• Disse glir veldig ofte over i hverandre og vanskelig å rendyrke dem

• Ulike designproblemer vil antyde ulike tilnærminger

• Viktig å skille mellom hva som selv er foretrukket, og hva som er best for problemløsningen


01.09.14

1. User-centered design (UCD) • Fokus på brukeren av løsningen

• Bruker vet best og er den eneste som får lov til å styre og påvirke designet

• Designerens hovedoppgave er å transformere brukerens behov og mål til designløsninger

• Brukers behov, ønsker og begrensninger tas i betraktning i hver aktivitet i utviklingen

• Typiske metoder og teknikker som brukes:

• Etnografi

• Contextual inquiry

• Brukbarhetstesting


01.09.14

2. Activity-centered design (ACD) • Fokus på aktiviteten til brukeren og omgivelsene rundt bruken av en løsning

• Er altså ikke opptatt av brukerens behov og mål

• Stammer fra aktivitetsteori og sosialvitenskapen

• Interessert i brukerens oppførsel, væremåte og karakteristikk


• Observasjon

• Intervjuer

• Etnografi


01.09.14

3. Systems design • Strukturert, rigid og holistisk tilnærming med fokus på kontekst

• Fokus på systemet som utvikles, dvs. mennesker, maskiner, enheter, objekter etc.

• Siden systemet står i fokus brukes tilnærmingen ofte i komplekse problemer

• Ser brukeren i forhold til konteksten, og brukeren setter mål for systemet


• Modellering (UML, ERD)

• Brukerhistorier

• Intervjuer


01.09.14

4. Genius design • Designeren skaper ideer som brukeren vurderer i etterkant av designprosessen

• Brukeren er ikke involvert i selve designprosessen

• Avhenger av designeres kunnskap, erfaring og kreativitet

• Typisk Apple-filosofi (iPod 1 ble designet uten direkte brukermedvirkning)

• Overraskende vanlig tilnærming i den virkelige verden


• Observasjoner

• Studier av liknende produkter og tjenester

• Rapid prototyping


01.09.14

Apple sin filosofi (1) • Snakker ofte om at designet handler om folket og brukerne

• Mener målet ikke er å tjene penger, men å lage gode produkter

• Ønsker å lage løsninger som brukerne forstår og klarer å bruke

• Men hvordan er utviklingsprosessen?


01.09.14

Apple sin filosofi (2) • Designere får fritt spillerom (teknologi, kostnadsrammer, ressurser)

• Mange (mange) runder med prototyping – snakker ofte om pixel-perfect prototypes

• Designerne er brukere selv – ekspertbrukere

• Konsepter og prototyper er ofte kun tilgjengelig for en lukket gruppe mennesker

• Utviklerne settes først på saken når konseptet er godkjent

(TheNextWeb, 2012) (MacTalk, 2009)


01.09.14

Apple sin filosofi (3) • Intervju med Jonathan Ive på spørsmål om designprosessen hos Apple:

• "The Design Process at Apple is very much about “designing and prototyping and making. When you separate those…the final result suffers.”

• Designers need to be “…to be light on your feet, inquisitive and interested in being wrong.”

• Design’s goal is “…to design and make better products. If we can’t make something that is better, we

won’t do it.”

• The design team works in a collaborative environment with people from different disciplines and different “areas of expertise.”

• When an opportunity arises, designers need to ask the “stupid” questions. “…What if we do this, combine it with that, would that be useful? This creates opportunities that could replace entire categories of device, rather than tactically responding to an individual problem.”

• Sometimes an innovation can come from “the smallest shift” that “suddenly transforms the object, without any contrivance.”

(DesignSoJourn, 2012)


01.09.14

(5.) Participatory design (PD) • Stammer fra Skandinavia, deriblant forskning i Norge (DESIGN-gruppen)

• Fokus på å aktivt involvere alle brukere og aktører igjennom hele designprosessen

• Holder ikke bare å forstå brukeren, de må også være med på å forme løsningen

• Opptatt av forskning og prosessen – hvordan brukere involveres


• Workshops

• Brainstorming

• Storyboard


01.09.14

Mer om user-centered design (UCD) • Fokuset i dette kurset ligger på UCD

• Donald Norman beskriver user-centered design som en filosofi hvor brukere og

brukbarhet settes foran estetikk.

• Brukersentret tilnærming baserer seg på: • Tidlig fokus på brukeren og oppgaven som skal løses: Direkte studier av

brukers oppførsel, samt deres kognitive, antropomorfiske holdningsmessige egenskaper.

• Empiriske undersøkelser og resultater: brukers reaksjoner og prestasjoner ved bruk av scenarioer, manualer, simuleringer og prototyper blir observert, tatt opp og analysert.

• Iterativ design: en repeterende prosess hvor problemer som oppdages under

brukertesting fikses, og testes på nytt.


01.09.14

Graden av brukerinvolvering

• Bruker involveres som en del av designteamet: • Heltid konstant input, men mister kontakt med resten av brukerne

• Deltid sporadisk input, og ofte veldig stressende pga. annen jobb

• Kortsiktig inkonsistent gjennom prosjektet

• Langsiktig konsistent, men mister kontakt med brukere

• Brukere kontaktes via nyhetsbrev, internettforum og massemedia:

• Når et bredere publikum bør gi bedre grunnlag for å forstå brukergruppen

• Trenger toveiskommunikasjon

• Brukere involvert etter at produktet er sluppet

• Kombinasjon av disse tre tilnærmingene


01.09.14

Fire basisaktiviteter 1. Identifisere brukernes behov og etablere krav

2. Utvikle alternativer til design som løser problemet

3. Prototype ulike versjoner av løsningene

4. Evaluere de ulike løsningene Behovsanalyse

kravspesifikasjon

Design prototype

Evaluering analyse

Obligatorisk oppgave 1




01.09.14

Fire basisaktiviteter 1. Identifisere brukernes behov og etablere krav

• Hvem er våre målbrukere?

• Hvilken støtte kan vår interaktive løsning tilby?

2. Utvikle alternativer til design som løser problemet • Foreslå løsninger som imøtekommer kravene

• To subaktiviteter:

• Konseptuelt design: produsere en konseptuell modell for produktet, dvs.

hva produktet skal gjøre, hvordan det skal oppføre seg, og se ut etc.

• Fysisk design: forslag til produktets detaljer, dvs. farger, lyder, bilder som brukes, menydesign, ikoner grensesnitt etc.


01.09.14

Fire basisaktiviteter 3. Prototype ulike versjoner av løsningene

• Ikke nødvendig å programmere et program, det finnes andre muligheter, f.eks. papir-

prototyper, storyboards, trefigurer, skisser etc.

• F.eks. bruk av trebrikke under utvikling av PalmPilot

4. Evaluere de ulike løsningene • Avgjøre brukbarhet og respons på produktet eller designet

• Kreve brukerinvolvering gjennom utviklingen


01.09.14

Praktiske spørsmål • Hvem er brukerne?

• Hva mener vi med brukernes ”behov”?

• Hvilke krav skal vi stille til løsningene?

• Hvordan kan vi generere alternativer?

• Hvordan velger vi mellom de ulike alternativene?

Krav og behov dekkes i kapittel 10 og gjennomgås neste uke

Bør tenkes gjennom til obligatorisk oppgave 1


01.09.14

Hvem er brukerne av systemet? • Ofte ikke så åpenbart:

• De som interagerer direkte med produktet

• De som håndterer og administrerer brukere

• De som mottar output fra produktet

• De som tar beslutninger i forhold til innkjøp

• De som bruker konkurrentens løsninger

Her er det mange potensielle intervjuobjekter til obligatorisk oppgave 1


01.09.14

Og hvordan bruker de systemet? • Hvilke enheter tar vi utgangspunkt i når vi designer et system?

• Internet of Things?

• Mobile first?

• Responsive design gjennomgås på forelesningen 15. september 2014


01.09.14

Microsoft sin filosofi (1) • Tradisjonsrikt og etablert selskap som møter stadig ny konkurranse

• Ble "tvunget" til å tenke brukersentrert

• Bruker åpenbart flere løsninger og prosesser avhengig av hvilket produkt som utvikles

• Ulike team i ulike prosjekter som utvikler på ulike måter

• Har ikke alltid mulighet til å bedrive mikro-utvikling

• «Technology can master complexity, but design must master simplicity» Surya Vanka, Head of the User Experience Excellence group, Microsoft


01.09.14

Microsoft sin filosofi (2) • Forstå hvem er egentlig brukeren? Bakgrunnsundersøkelse og informasjonsinnhenting for å gi designere en dypere innsikt i behov, motivasjoner og utfordringer blant brukere.

• Forestille hva kan vi tilby? Ny innsikt og konseptuelle gjennombrudd resulterer i nye ideer om hva som kan tilbys brukere.

• Spesifisere hvordan blir resultatet? Designere og andre utviklere etablerer en detaljert spesifikasjon av produktet de snart lanserer.

• Implementere her er produktet! Prosessen hvor det endelige programmet presenteres og leveres.

• Vedlikeholde hvordan kan vi bli bedre? Programvaren gjennomgår stadig evaluering for å møte nye behov. Designteamet vil få kontinuerlig tilbakemelding som omformes til programvareendringer.


01.09.14

Microsoft sin filosofi (3) • Erez Kikin-Gil, Senior UX Lead, Windows Live Web Communications product team

• Fire-faset utviklingsprosess:

• Forstå Den første som gjøres er å undersøkelse hvilke utfordringer som må møtes. Her baserer man seg på markedsundersøkelser, produktplanlegging etc.

• Idéskape Fase hvor ideer utvikles. Her brukes skissering, scenario, brainstroming, storybook. På dette tidspunktet er alle andre i teamet (utviklere, testere etc.) også designere.

• Test Brukertesting blir gjennomført i flere runder. Først med alfatesting in-house (i dedikerte MS-labber) og deretter med betatesting ute hos brukere. Brukte metoder inkluderer observasjon, deltagelse, videoer etc.

• Kommuniser Resultatet kommuniseres tilbake til interessenter av prosjektet gjennom formelle og uformelle kanaler. Ingen innad begrensning på hvem som får tilgang på resultater.


01.09.14

Interessenter i systemutviklingsteori


01.09.14

Interessenter i systemutviklingsteori

• Alle personer, grupper eller systemer som enten direkte eller indirekte påvirkes av systemet

• Sluttbrukere som interagerer med systemet, men også alle som påvirkes av bruken

• Kalles stakeholders på engelsk

• Ideelt sett: alle bør involveres og det bør tas hensyn til alle er det mulig å gjennomføre i praksis? vil alles hensyn og krav være forenlig? er alle egentlig interessert i å høre på alle andre?


01.09.14

«Onion» model

Konsulent

Finansiell mottaker

Negativ interessent

Utvikler

Media

Politisk mottaker

Grensesnitt- systemer

Innkjøper

Funksjonell mottaker

Operational Support

Vedlikeholds- operator

Normal operator

Samfunnet

Omfattende systemet

Systemet

Produktet

Sponsor

Befolkning

Operasjonell support

Politikere

Løst oversatt fra «A Taxonomy of Stakeholders» Ian F. Alexander, 2005


01.09.14

Tre kategorier av brukere i UCD (Eason, 1987)

• Primærbrukere

Brukere som interagerer hands-on med systemet regelmessig

• Sekundærbrukere: Brukere som innimellom, eller via noen andre, interagerer med systemet

• Tertiærbrukere: Brukere som blir berørt av innføring av systemet eller påvirker det


01.09.14

Hvordan generere alternativer?

• Mennesker liker å forholde seg til det de vet fungerer

• Men for å designe alternativer er det viktig å ”tenke utenfor boksen”

• Systemutviklere er mest opptatt av den raskeste og mest effektive løsningen som tilfredsstiller en liste med krav

• Interaksjonsdesignere er trent i å vurdere ulike alternativer og inspirere brukeren til å tenke nyskapende og kreativt

• Hvordan skape alternativer? • Teft og kreativitet: undersøk og syntetiser

• Søk etter inspirasjon: studer liknende produkter eller se på helt ulike produkter


01.09.14

Hvordan velge blant alternativer?

• Evaluering med brukere eller andre designere, for eksempel gjennom prototyping

• Tekniske gjennomførbarhetsanalyse: hva er mulig med teknologien som finnes?

• Kvalitetsterskler: brukbarhetsmål kan lede til brukbarhetskrav som kan brukes som kriterier som kan kontrolleres jevnlig: • Sikkerhet hvor trygg er løsningen?

• Funksjonalitet hvilke funksjoner er overflødige?

• Oppgaveløsning er det nok support og informasjon tilgjengelig? Hvordan

er oppgavedekningen?

• Prestasjon hvordan er prestasjonen til brukerne?


01.09.14

Struktur Hva? Identifisere behov og etablere krav

Bakgrunnsstudier Intervjuer Spørreskjemaer Meningsmålinger

Use case Oppgaveanalyse Persona Scenario Kravspesifikasjon

Hvordan? Designe alternativer

Ulike prototyper: Skisser, storyboards, wireframes, fysiske prototyper etc.

Hvor bra? Evaluere løsninger

Gjennomganger (walkthrough) Brukbarhetstesting Feltstudier Heuristisk evaluering


01.09.14

Livssyklusmodeller (Her er mye kuttet ut i den tredje utgaven av boka – bruk foilene)

• Livssyklusmodeller angir hvilke aktiviteter som inngår i utviklingsprosessen og

hvordan de relaterer til hverandre

• Brukes som redskap for ledelse og måling av fremdrift i en utviklingsprosess

• Forenklede modeller av virkeligheten

• Har utspring fra tradisjonelle systemutviklingsmodeller

• Livssyklusmodeller i HCI skiller seg fra tradisjonelle utviklingsmodeller i systemutviklingsteori ved at det er mer brukersentrert, og begreper og modeller er bredere og løsere brukt.

• Emnet INF1050 tar for seg systemutviklingsmodellene på en grundig måte


01.09.14

En enkel livssyklusmodell for UCD


01.09.14

Tradisjonell systemutviklingsmodell: Fossefallsmodellen • Den første velkjente systemutviklingsmodellen

• Lineær modell hvor hver aktivitet først starter når forrige er fullført

• Tar ikke hensyn til endringer

underveis i utviklingen

• Mulighet til å gjennomgå og evaluere løsninger med brukere er ikke inkorporert i denne modellen.

• Brukes lite i praksis i dag, også i system- utviklingsverden.


01.09.14

Tradisjonell systemutviklingsmodell: Spiralmodellen • Oppstod som et alternativ til fossefallsmodellen

• En risikodrevet modell med hovedvekt på analyse av risiko og prototyping

• Brukere involveres for å identifisere og

kontrollere risiko

• Oppfordrer til å vurdere alternativer

• Hver loop representerer en iterasjon, dvs. en fase i utviklingsprosessen.


01.09.14

Analogi: systemutvikling er som konstruksjon

• Tenk på hvordan bygninger bygges:

• Krav – regulerte krav, fysiske begrensninger

• Arkitektur – plantegning, 3D-modeller

• Konstruksjon – materiale, elementer

• Forskjellen:

• Vedlikehold: bygninger forandrer seg lite over tid

• Design: bygninger er mindre komplekse

• Antall tilstander

• Fjern en brikke


01.09.14

Krav, design og implementasjon

• Krav:

• Beskrivelse av HVA systemet skal gjøre (eller hvilke kvaliteter det skal ha)

• Fra en kundes eller klients synsvinkel

• Ikke uttrykt med tanke på løsning

• Design:

• En beskrivelse av HVORDAN vi vil implementere en løsning

• En modell, prototype eller skisse som imøtekommer kravene

• Gjøres før implementeringen slik at de kan evalueres


01.09.14

Verfisering og validering

• Verifisering designe produktet riktig (kontrollerbart)

• Validering designe det riktige produktet (kontrollerbart?)

• The formality gap validering vil alltid avhenge av subjektive vurdering

• Abstrakte modeller hjelper oss med å knytte beskrevet modell med virkelig modell


01.09.14

Livssyklusmodell: Star model

• Stammer fra empiriske studier av interaksjonsdesigneres arbeidsvaner

• Viktige egenskaper: • Evaluering står i sentrum av alle aktiviteter

• Ingen spesiell rekkefølge på aktivitetene, utvikling kan starte hvor som helst

• Muliggjør både top-down og bottom-up tilnærming (gjerne om hverandre)

• Kalles ofte for ”yo-yoing” av systemutviklere


01.09.14

Livssyklusmodell: Star model


01.09.14

Livssyklusmodell: ISO9241-210

• Videreutvikling av ISO13407 (2. utgave av læreboka)

• Baserer seg på en grunnleggende forståelse av bruker, oppgave og omgivelser

• Viktige egenskaper: • Prosessen er drevet og målt gjennom brukersentrert evaluering

• Designprosessen tar for seg hele brukeropplevelsen

• Designteamet innehar som oftest av tverrfaglig kompetanse

• En iterativ prosess


01.09.14

Livssyklusmodell: ISO9241-210

ISO9241-210 ISO13407

inf1500 - introduksjon til design, bruk, interaksjon ... · inf1500 – introduksjon til design,...

Documents