PACT EN ONTWERPPROCES

Transcriptie

1 PACT EN ONTWERPPROCES Ontwerpen van Interactieve Systemen Frans Wiering 13 februari 2017

2 Huishoudelijk projectopdrachten staan online teams aanmelden uiterlijk donderdag 16-2 matchmaking in pauze werkcollege vandaag zelf verdelen over zalen BBG-001, BBG-023, BBG-083, BBG-214 nog geen vaste plek werkcollege 20 februari met je groepje (van 6) een website of app evalueren kies vantevoren en bereid individueel voor (scoreformulier) 2

3 Waar staan we? College 1: ontwerpen interactieve systemen interactieve systemen human-centred design featuritis affordance College 2: human factors (7 + 1) ergonomie geheugen aandacht fouten informatieverwerking situated action distributed & embodied cognition perceptie kennis in de wereld, kennis in het hoofd 3

4 Waar staan we? College 1: ontwerpen interactieve systemen interactieve systemen human-centred design featuritis affordance College 2: human factors (7 + 1) ergonomie geheugen aandacht fouten informatieverwerking situated action distributed & embodied cognition perceptie dagmenu PACT (hfst 2) probleem in kaart brengen ontwerpproces (hfst 3) 4 hoofdactiviteiten persona s en scenario s 4

5 Benyon s mantra: PACT People Activities Contexts Technologies systemen ontwerpen voor mensen die activiteiten verrichten in een bepaalde omgeving met behulp van technologieën gewenst resultaat: peopletechnology system designers want to get the right mix of technologies to support the activities being undertaken by people in different contexts (Benyon p. 43) 5

6 My first PACT analysis people? activities? contexts? technologies?

7 Waarom PACT analyse eerste verkenning ( scoping ) van een bestaand of nog te ontwerpen P-T systeem langs de 4 PACT dimensies raamwerk om betrekkelijk snel de onderwerpen te benoemen die in de ontwerpfase van toepassing zijn pijnpunten, uitdagingen wat is de ontwerpruimte globaal beeld van het gebruik van het systeem nuttige input voor persona s, scenario s en requirement niet te snel jezelf vastleggen op een bepaalde oplossing PACT analyse ontwerp 7

8 PACT Analyse voor app 2e-hands autohandel People Autohandelaars, -importeurs en -merkdealers zijn de doelgroep. Deze mensen zijn gewend te werken met een computer, dus er is een basiskennis aanwezig. Werken met een smart phone of tablet wordt minder vaak gedaan, dus is een eenvoudige en duidelijke gebruikersinterface noodzakelijk. De gebruikers zijn gemotiveerd en hebben een drukke agenda. De gebruikers hebben verstand van auto s, autorestwaardes en het daarin gebruikte vakjargon. Het is mogelijk dat er mensen gebruik maken van het product die een andere taal spreken. Toegankelijkheid van het systeem moet toestaan dat mensen met kleurenblindheid de app ook kunnen gebruiken. Activities Deze taken zullen de gebruikers uitvoeren met onze applicatie: Autogegevens van eigen fleet bekijken (foto s, prijzen, technische specificaties ) Een auto toevoegen aan de fleet Foto s toevoegen Auto s verwijderen Autogegevens wijzigen Restwaarde automatisch laten bepalen Eenvoudig publiceren op de beschikbare online verkoopkanalen (Marktplaats, Autotrack, Autotrader, Autoweek, Autoscout24, NederlandMobiel.nl etc.) Auto s aan- en afmelden bij het RDW Contexts De activiteiten vinden plaats als de gebruiker: Een tweedehands auto heeft binnengekregen en de gegevens wil invoeren Bestaande informatie wil inzien en/of wijzigen Een of meerdere auto s wil publiceren op online verkoopkanalen Een auto heeft verkocht bron: presentatie Rob Vermeulen Een individu of een grote groep mensen kunnen gebruik maken van de applicatie. Gebruikers hoeven geen hulpmiddelen mee te brengen om de applicatie te bedienen. Technologies De deelnemers moeten de applicatie opstarten, dit zal met een simpele druk op een knop gebeuren. De gebruikersapplicatie zal op een tablet moeten draaien. Zowel Apple (ios) als Android (versie 4.0+) zal ondersteund moeten worden. Voor RDW meldingen, restwaardebepalingen en publicaties op verkoopkanalen zal gebruik worden gemaakt van reeds bestaande web services. college-appdevelopment.pptx

9 PACT: Mensen human factors (college 2) mentale modellen sociaal/cultureel 9

10 Mentale modellen a person s thought process for how something works (Carey 1986) bepaald door ervaringen en conventies schept verwachtingen beïnvloedt keuze van metaforen in interactieve systemen 10

11 Mentale modellen maximale verklaring tegen minimale kosten (in termen van Kahneman: thinking fast) eigenschappen onvolledig onnauwkeurig instabiel vage begrenzing onwetenschappelijk, magisch zuinig ( parsimonious ) 11

12 Kaart als mentaal model Breukelen Vredenburg Uithof 12

13 Mentale modellen waarom belangrijk? The designer s conceptual model is the designer s conception of the look, feel, and operation of a product. The system image is what can be derived from the physical structure (including documentation). The user s mental model is developed through interaction with the product and the system image. Designers expect the user s model to be identical to their own, but because they cannot communicate directly with the user, the burden of the communication is with the system image. Norman, DOET, fig kennis in het hoofd, kennis in de wereld 13

14 Mentale modellen van interactieve systemen Janet Murray, Inventing the Medium (2012), p

15 Bekende mentale modellen in OIS gestures wizard 15

16 Sociale verschillen en cultuur kennis (novices en experts) motivatie verplicht of vrijwillig cultuurverschillen taal, schrift gebruiken, rituelen symbolen 16

17 Metro van Los Angeles 17

18 Spaans Koreaans Chinees Armeens Japans Russisch Thai Cambodjaans 18

19 OV Amsterdam 19

20 Mensen: samenvatting Fysiek Psychologisch Sociaal 20

21 PACT: Activiteiten tijdsaspecten samenwerken complexiteit veiligheid aard van de content 21

22 Tijdsaspecten frequentie doe je iets eenmaal, een enkele keer, of vaak? tijdsdruk maakt makkelijke dingen moeilijk continu of onderbroken kun je verder waar je gebeleven was? responstijd hoe lang duurt het voor systeem op je actie reageert? hand-oog coördinatie: 100 millisec oorzaak-gevolg: 1 seconde frustratie: > 5 seconden 22

23 Andere aspecten activiteiten alleen of met anderen communicatie en coördinatie complexiteit: is de taak vaag of precies? een vakantie zoeken vs. vakantie boeken consequenties van fouten fysieke en digitale veiligheid voorkomen van fouten sturing geven data-invoer keyboard, scanner media beeld, geluid 23

24 PACT: Context Fysiek Sociaal Organisationeel 24

25 Context Fysiek Sociaal Organisationeel 25

26 Context Fysiek Sociaal Organisationeel 26

27 PACT: Technologie Input Output Communicatie Content (Processing / AI) (PACT analyse besteedt in principe geen aandacht aan interne werking technologie) 27

28 Checklist PACT People physical differences, ergonomics psychological differences mental models social differences Activities temporal aspects cooperation complexity safety-critical nature of the content Contexts physical environment social context organisational context Technology input output communication content (processing) Benyon hanteert deze onderverdeling van de PACT elementen. Dit is een handige checklist voor je eigen PACT-analyse. 28

29 Ontwerpproces in vogelvlucht Envisionment Understanding Evaluation Conceptual Design Physical het afstemmen van de PACT elementen in een bepaald domein 29

30 Understanding analyse van het probleem gebruik PACT dimensies verder uitdiepen, bij voorbeeld: Toyota: Five Whys uitkomst: requirements vereisten van het systeem 30

31 Stakeholders all people who will be affected by any system that results from the process of interactive system design (Benyon, p. 50) 31

32 Stakeholder map 32

33 Waarden, macht en conflicten 33

34 Wie heeft controle over de website?

35 Requirements something the product must do or a quality that the product must have (Robertson and Robertson 1999) functionele requirements wat doet het systeem? functionaliteit, interactie Niet-functionele requirements hoe doet het systeem het? wat heeft het systeem voor eigenschappen? technologie, esthetiek, bruikbaarheid, security 35

36 Hoe kom je aan requirements? communicatie met stakeholders (discussie, interviews, vragenlijsten, workshops) verzamelen van verhalen van gebruikers observatie van bestaande systemen en gebruikers analyse van werkprocessen, gedrag, markt enz. 36

37 Ontwerp Wat is het voor systeem? Hoe werkt het systeem? Conceptual Design Physical 37

38 Conceptueel ontwerp kennis in de wereld, kennis in het hoofd Welke functies en kennis moet het systeem bevatten? Wat moet iemand weten om het systeem te kunnen gebruiken? Focus ligt op wat, niet op hoe Analyseren, b.v. object action analysis, ER modellen Visualiseren bv. rich pictures rich picture van een telefoonhulplijn conceptual design in 2 minutes (Nokia): 38

39 Fysiek ontwerp Van abstractie naar concreet ontwerp hoe gaat het systeem werken? Operational design: de werking van het systeem, structuur en opslag van de content Representational design: look and feel van het systeem: kleuren, vormen, icons, layout Interaction design: hoe werken mens en systeem samen? 39

40 Envisionment Voorstellen en presenteren van ideeën schetsen lo-fi en hi-fi prototypes scenario s storyboards 40

41 Prototype voorstelling van het werkende systeem speciaal de interactie allerlei vormen throwaway paper lo-fi, low expectation hi-fi prototype interactie echt, werking fake bv. in HTML, Powerpoint prototyping software gevaarlijk, want hi-fi = high expectation 41

42 Evaluatie Experts heuristisch (guidelines) cognitive walkthrough (mentale modellen) Gebruikers coöperatief, co-discovery, experimenten Metrieken eye-tracking, snelheid, tevredenheid, leertijd, aantal fouten In verschillende stadia van ontwerp 42

43 Ontwerpproces: de activiteiten Envisionment Understanding Evaluation Conceptual Design Physical 43

44 Ontwerpproces door de tijd The Double-Diamond Model of Design. Start with an idea, and through the initial design research, expand the thinking to explore the fundamental issues. Only then is it time to converge upon the real, underlying problem. Similarly, use design research tools to explore a wide variety of solutions before converging upon one. (Slightly modified from the work of the British Design Council, 2005.) discover define develop deliver Norman, DOET, p

45 OIS Project 1: specificatie, basisontwerp 2. prototype implementatie 45

46 Persona s en scenario s 46

47 Persona s Concrete representaties van verschillende types mensen waarvoor een systeem of service wordt ontworpen hebben een naam, achtergrond, life style, doelen, wensen en verlangens, etc. pas op voor stereotypering Waarom is dit belangrijk? 47

48 Persona s 48

49 Een slaapcoach ontwikkelen 49

50 Persona let op hoe de persoonlijkheid uitgediept wordt motivatie emotie life style, hobbies werk en familie relatie tot technologie enz 50

51 Scenario s concrete verhalen over mensen die de technologie gebruiken geven inzicht en reflectie in tal van interactieaspecten en dus in requirements gaan uit van persona s en hun typische gedrag, doelen en waarden rijke beschrijving voor Situated Action (human factors) 51

52 Voorbeeld slaapcoach scenario In termen van Benyon is dit een concreet scenario 52

53 Het kan ook als filmpje 53

54 Scenario-gebaseerd design Abstract Specificatie van design constraints Formalisering echte ervaringen abstracte patronen interacties met het systeem formele beschrijving Verhalen Conceptuele scenario s Concrete scenario s Use cases Wat willen en doen mensen Genereren van ideeën en requirements Envisioning en evaluatie Specificatie en implementatie verhalen specificaties 54

55 Scenario-gebaseerd design in project Verhalen Conceptuele scenario s Concrete scenario s Use cases Wat willen en doen mensen Genereren van ideeën en requirements Envisioning en evaluatie Specificatie en implementatie als het lukt, ook verhalen conceptuele scenario s in ieder geval persona s concrete scenario s use cases 55

56 Use cases wie doet wat met het systeem? stapsgewijs vanuit gebruikersperspectief menselijke gebruikers, andere apparaten, hardware, software taal sluit aan bij gebruiker 56

57 Waarschuwing: terminologie elke methodiek geeft een andere betekenis aan de termen user story, scenario en use case software project user story (Scrum) conceptueel scenario (Benyon) UML use case veel verder geformaliseerd dan bij Benyon Informatiesystemen (blok 4) scenario s komen na use cases hier zul je mee moeten leven... 57

58 Voorbeeld: Verhalen A story extracted from a series of interviews on how office workers organized their personal information: The Guilt Pile You receive something you feel that you ought to read but, because it's not vitally important, you don't want to do it immediately. Instead, you toss it on a pile of documents which probably sits on a work surface in a corner of your office. You feel good. Things are under control, and with a minimal investment of time! Time passes. The pile gets higher and higher. It begins to look like there's literally a mountain of stuff you ought to read. You begin to feel uncomfortable. Provoked by the pile's height, you sort through it, discarding articles that no longer seem interesting, perhaps selecting one or two to read. The winnowed pile -- now of a much more manageable size -- is put back in its place. You feel good. Things are under control again. 58

59 Voorbeeld: Verhalen I like this story because it not only explains how people use piles, but why they use piles. It provides the design rationale behind piles. It is able to do this effectively because stories describe not just actions, but feelings and motivations. This story captured something that struck me when interviewing people about how they organized information in their work environments: Almost everyone was embarrassed at how poorly they managed information. They felt bad because they had lost control over their information, and they felt good at the times when they had managed to sort through everything and organize it, no matter how casually. The desire to feel good and on top of things rather than bad and out of control is one with which most people can empathize. People recognize themselves and their desires in the story. 59

60 Hoofdbegrippen PACT mensen, activiteiten, contexten en technologieën mentaal model, conceptueel model, system image understanding stakeholders functioneel en niet-functionele requirements conceptueel ontwerp fysiek ontwerp envisionment lo-fi en hi-fi prototypes evaluatie double-diamond model of design persona s verhalen, conceptuele en concrete scenario s, use cases 60