# data[].attributes.body
(IM) 'testen' en 'user testing' is typisch design thinking vocabulair. Wat is het nut van gebruik van andere woorden? Ik zie het doel niet.

Ook hierbij uitgaan van de principes van Design Thinking. Zie:

# data[].attributes.attachment_link.title
FHIL | Stages of Design Thinking | TESTING

# data[].attributes.headline
exploreren ‘wicked problem’ vanuit verschillende perspectieven (disciplines) 

# data[].attributes.subject
exploreren ‘wicked problem’ vanuit verschillende perspectieven (disciplines) 

# data[].attributes.body
schetsen / formuleren verschillende oplossingsrichtingen

# data[].attributes.headline
maken van verschillende prototypes voor gebruikers  

# data[].attributes.subject
maken van verschillende prototypes voor gebruikers  

# data[].attributes.body
Zou ik wat anders formuleren. B.v.: Maken van low res en high res protoypen die een inzicht geven in gebruikersdata: Zie: https://www.youtube.com/watch?v=FnJIJEUBLms&feature=youtu.be

# data[].attributes.attachment_link.title
FHIL | Stages of Design Thinking | PROTOTYPE

# data[].attributes.body
Waarom willen we hier een methodiek vastleggen? Je kunt wel zeggen dat een student een bepaalde variatie aan methodieken aantoont.

Ik zou wel een voorstander zijn om te zeggen dat er een balans moet zijn tussen qualitative en quantitative ondzeroeksmethodieken. Uiteraard is variatie een must. (IM)

# data[].attributes.body
Ook hierbij zou ik geen methodiek vastleggen. Wel zou je kunnen zeggen dat studenten schetsen kunnen maken op een overdraagbaar / professioneel presentatie niveau

(IM) ik heb een beetje moeite met het interperteren van iets op 'professioneel niveau', hoe maak je dit meetbaar, en waarom willen we dat van 3de jaars studenten eisen? En; professionele standaard is ook per bedrijf weer anders.. vind ik echt te vaag en niet zo realistisch.  Overdraagbaar lijkt me wel een mooi criterium.
Methodieken zou ik ook niet vastleggen, wat is het nut daarvan? We zouden wel kunnen vragen of studenten zich meer visueel willen uiten/visueel communiceren in de deliverables.

(EB)
schetsen  - dan denk ik meteen aan tekenen :-)
ik zou het ook  niet vastleggen!

# data[].attributes.body
Klankborden is een beetje ouderwets woord. Persoonlijk zou ik meer voelen voor principes uit de design thinking, zoals b.v. empathize. Zie: https://www.youtube.com/watch?v=XcYrvvu2ElM&feature=youtu.be

# data[].attributes.attachment_link.title
FHIL | Stages of Design Thinking | EMPATHY

# data[].attributes.headline
maken bruikbare eindversie> welke methodiek?

# data[].attributes.subject
maken bruikbare eindversie> welke methodiek?

# data[].attributes.body
Zie ook eerdere opmerkingen.

EB - bruikbaar - zie opm. verderop!

# data[].attributes.headline
Leeruitkomst experimenteren.  De student ontwerpt en creëert op basis van analyses en via verschillende iteraties en ontwikkelloops creatieve oplossingen voor complexe vraagstukken uit de grootstedelijke agglomeratie. Hij doet dat in samenwerking met partners uit het werkveld en andere disciplines uit het creatieve domein

# data[].attributes.subject
Leeruitkomst experimenteren.  De student ontwerpt en creëert op basis van analyses en via verschillende iteraties en ontwikkelloops creatieve oplossingen voor complexe vraagstukken uit de grootstedelijke agglomeratie. Hij doet dat in samenwerking met partners uit het werkveld en andere disciplines uit het creatieve domein

# data[].attributes.body
super belangrijk in climb 3!
Studenten dienen prototype voor te leggen aan mensen, misschien "heavy users, superfans, potentiële users/gebruikers, maar kunnen ook experts bevragen

YESSS!!!!! heeel fundamenteel vor Design Thinking en innovatie. Absolute must, ook om bias en assumptions zichtbaar te maken.

# data[].attributes.body
Ik weet niet of je letterlijk het maken van een infographic als skill moet vragen. Wel zou je de principes van data presentatie kunnen meenemen zoals deze bij infographic worden gehanteerd. We bieden in Rotterdam een keer een workshop infographics aan. In de praktijk zie ik ze (nog) niet letterlijk terug.

(EB) Nee - studenten dienen inzicht te geven in het proces (dat kan je vormgeven dmv van een infographic of niet), en de design rationale - welke keuzes zijn gemaakt tbv onderzoeksmethode, gebruik van tools, maar ook tov de inhoud (zoals het concept en het prototype).  infographic is handige tool, maar we willen studenten juist de vrijheid geven zelf de vorm te kiezen - die voor hun werkbaar is!

IM; eens met beide, infographic als skill is niet perse nodig, wel graag de skill om je werk krachtig en overzichtelijk te visualiseren, maar daar is een infographic maar een voorbeeld van.

# data[].attributes.body
Dit is een belangrijke. Wat betreft het testplan zouden we daar een aantal paramaters op los kunnen laten. B.v. een realistisch en tijdgebonden plan waarin de student aangeeft hoeveel iteraties er gedaan gaan worden en op welke wijze de data die voortkomt uit het testen zal worden vastgelegd.

De testdag is in feite de hackaton. Even wat randvoorwaarden:

Externe locatie
Betrekken van werkveldpartner
Betrekken van eindgebruikers
Betrekken van partijen die kunnen ondersteunen in de realisatie (dus ter plekke zaken kunnen bijstellen.

(EB)
Testplan maak je, die organiseer je niet.
Onze studenten schrijven een test"plan", op basis waarvan zij diverse user tests uitvoeren. In Diemen organiseren de studenten geen hackathon.

IM; yes heel belangrijk, We kunnen ook het testen nog meer faseren; van pre-test tot executie van de daadwerkelijke test bij diverse stakeholders. Dit kan in de vorm van een hackaton, maar kan ook zeker anders. Doel van een user testing/ testplan uitvoeren is om feedback te verzamelen over het prototype/concept waarmee de iteratie onderbouwd wordt. En om los te komen van eigen aannames en informatie in te winnen van relevante stakeholders (bijv potentiele eindgebruikers, partners, partijen die eea eventueel zouden kunnen gaan ontwikkelen, overheid/gemeenten) User testing en het test plan zijn dan eigenlijk 'research' waarbij de 'onderzoeksaanpak' heeel goed doordacht is terwijl je wel erg openstaat voor de feedback. Het vergt hier dus onderzoeksvaardigheden en analytische skills, maar ook storytelling en uiteraard communicatie/visualisatie skills.

# data[].attributes.body
Wij hebben in Rotterdam de presentatie aan de opdrachtgever en het assessment van elkaar losgekoppeld. Het eindevent is feitelijk de overdracht. Dus moet voorzien zijn van documentatie etc. Waarmee de werkveldpartner vooruit kan. Dat is in veel gevallen niet het volledige portfolio, maar de bruikbare delen daaruit,.

IM; eens met bovenstaande

# data[].attributes.headline
onderbouwen op basis van onderzoeksgegevens en literatuur 

# data[].attributes.subject
onderbouwen op basis van onderzoeksgegevens en literatuur 

# data[].attributes.body
Conform de normen zoals we die binnen alle opleidingen hanteren. Dus APA. Daarbij gaat het ook analyseren  van gegevens.

(EB) vraag is wat ( en tot welke niveau) verwachten we dat studenten hun onderzoeksdata presenteren. Dit staat nu niet uitgewerkt bij de assessment criteria. In de design criteria beschrijven ze wel wat ze gedaan hebben en wat ze op basis van deze gegevens voor acties hebben gedaan (keuzes gemaakt, aanpassingen aan prototype etc.)

IM: Eens met EB en APA!
Ik zou het liefste zien dat studenten relevante (!) onderzoeksgegevens tonen die bepaalde keuzes onderbouwen. Ik ben niet zo geniteresseerd in alle ruwe onderzoeksdata, zoals de transcripties van een interview, maar alleen de conclusies en/of een samenvatting van onderzoeksactiviteiten die relevant zijn voor het begrijpen/verantwoorden van belangrijke gemaakte keuzes.

# data[].attributes.headline
concluderen op basis van analyse testgegevens/ input gebruikers

# data[].attributes.subject
concluderen op basis van analyse testgegevens/ input gebruikers

# data[].attributes.body
Ik zou in plaats van analyse testgegevens hier liever het woord interpreteren willen gebruiken.

(EB) NB onderzoeken <--> creëren gaan steeds hand in hand. Onderzoek wordt vooral in climb 1 (discover) en climb 3 (user testing) uitgevoerd, maar kan eigenlijk gedurende de gehele periode uitgevoerd worden.

Concluderen op basis van onderzoeksdata lijkt me dan ook relevanter. (elke climb een ander deel centraal, als je je hier richt op alleen het eindresultaat - zou je op de eindconclusies kunnen doelen. Maar in de design rationale dienen alle keuzes *dus continue proces van interpreteren en concluderen)

# data[].attributes.headline
evalueren: (zelf) bepalen van relevantie of kwaliteit van de resultaten  

# data[].attributes.subject
evalueren: (zelf) bepalen van relevantie of kwaliteit van de resultaten  

# data[].attributes.body
Volgens mij gaat het er dus om in hoeverre je input hebt gegeven aan het wicked problem. Kenmerk is natuurlijk dat het probleem feitelijk niet op te lossen is. Maar interessanter is eigenlijk welke (nieuwe) vragen er allemaal naar boven zijn gekomen.

IM; Nieuwe vragen die opkomen zijn indd interessant. en wellicht is het zinnig om studenten te laten reflecteren op betaalde aannames die ze hebben/hadden en in hoeverre deze onderschreven of ontkracht zijn? Zodat studenten zich meer bewust worden van aannames die ze toch in veel stadia van het project hebben.

# data[].attributes.headline
Wat wordt van de student verwacht qua experimenteren?

# data[].attributes.subject
Wat wordt van de student verwacht qua experimenteren?

# data[].attributes.body
Ik weet niet of we zaken moeten kwantificeren, maar ik zou meerdere iteraties terug willen zien waarin de student binnen de gegeven tijd een realistisch aantal relevante richtingen van het probleem heeft verkend. Misschien zelfs een overweging om ipv experimenteren itereren te zeggen. Het gaat om meerdere herhaalde experimenten.
IM; eens met bovenstaande, mooi gezegd Rene (?) . meer itereren gebruiken omdat iteraties minder randome zijn dan experimenten, maar juist een rode lijn vertegenwoordigen waarin het een op het ander doorpakt.

# data[].attributes.body
verschillende oplossingsrichtingen?

# data[].attributes.body
IM: indien het hier gaat om diverse versies(lees: iteraties) van het prototype dan: JA! absoluut
Indien het hier gaat om diverse concepten omzetten naar een prototype dan; NEE. Omdat het prototyping proces juist gaat om focus en trechteren, als je dan weer gaat divergeren en diverse concepten tastbaar maakt in de vorm van prototypes dan duurt het alleen maar langer. Dan is je idea selection phase niet sterk genoeg geweest.

# data[].attributes.headline
maken van bruikbare eindversie van prototype

# data[].attributes.subject
maken van bruikbare eindversie van prototype

# data[].attributes.body
(EB) ik weet niet of het haalbaar is (en zelfs wenselijk is) dat het prototype daadwerkelijk bruikbaar is. Wat is bruikbaar? een paper prototype van een stoel, kun je bijv. niet gebruiken  als stoel en zou daarmee niet bruikbaar zijn? Hoe kunnen we van studenten vragen of een prototype daadwerkelijk "bruikbaar" is....

Waarschijnlijk doelt men hier op prototype wat in lijn is met oplossingsrichting en door gebruikersgroep  (users) als wenselijk bestempeld is oid?

Ik zou zeggen - anders formuleren!

IM: interessante opmerkingen, ik vind 'bruikbaar; ook een lastige, het lijkt te suggereren dat het laatste prototype functioneert en dit is (toch vaak budget technisch) niet mogelijk. Suggestie: in plaats van 'bruikbaar' kan je ook zeggen 'waardevol', dat het prototype op conceptueel niveau dus waardevol is voor opdrachtgever en eindgebruiker (hangt ook samen met wenselijk/desirable)

# data[].attributes.headline
onderbouwen op basis van onderzoeksgegeven en literatuur

# data[].attributes.subject
onderbouwen op basis van onderzoeksgegeven en literatuur

# data[].attributes.headline
conclusies op basis van analyse testgegevens / input gebruikers

# data[].attributes.subject
conclusies op basis van analyse testgegevens / input gebruikers

# data[].attributes.headline
evalueren: (zelf) bepalen van relevantie of kwaliteit van de resultaten

# data[].attributes.subject
evalueren: (zelf) bepalen van relevantie of kwaliteit van de resultaten

# data[].attributes.body
gaan deze skills bij het project of ook indvidueel?

# data[].attributes.body
Zie ook opmerking bij creëren. Grofweg gaat het om low res en high res prototypes. Afhankelijk van  het vraagstuk of de gekozen oplossingsrichting zoekt de student een methodiek hierbij. Dit is moeilijk van te voren vast te leggen.

EB _ (early prototyping, paper prototyping, rapid prototyping, etc.....
eigenlijk maakt het label niet uit.
Dient op relevante wijze het concept - of een deel daarvan , tastbaar te maken
IM: eens met bovenstaande, methodiek vastleggen kan beperkend werken; elk project is anders en dat is juist het leuke ervan. Er zijn eindeloos veel methoden om prototypes te maken, tangible en digital, maakt niet uit, zolang het doel maar helder blijft: het concept visualiseren/tastbaar maken zodat het ervaren en of gecommuniceerd kan worden om zo feedback te verzamelen.

# data[].attributes.body
Ik heb hier moeite mee: grootstedelijke agglomeratie

Waarom willen we dit zo framen? Ik begrijp dat grootstedelijke vraagstukken een speerpunt zijn in de domeinvisie. Echter sluit je hiermee heel andere zaken uit die ook interessant kunnen zijn binnen CGI.

# data[].attributes.body
Voorbeeld van assessment form Summative group, SEMESTER 1

# data[].attributes.attachment_link.title
ASSESSMENTFORM CGI group 20181002 - EN DEF_TEAM1 S1 #2

# data[].attributes.headline
maken van bruikbare eindversie van prototype  

# data[].attributes.subject
maken van bruikbare eindversie van prototype  

# data[].attributes.body
Ook dit zou ik wat anders formuleren. Feitelijk maak je nooit een "bruikbare eindversie", maar eerder een versie waarmee de werkveldpartner voldoende input krijgt voor verdere (door)ontwikkeling.

Nog een toevoeging: het doel van het prototype is om de (vaak) abstracte concepten tastbaar te maken, zodat belanghebbenden (partner, eindgebruiker, andere stakeholders) kunnen reageren op het concept. Op deze manier kan je in een vroeg stadium al waardevolle feedback verzamelen voor een volgende iteratie. Het prototype hoeft niet perse functioneer/bruikbaar te zijn, wel dient het concept( het gedachtegoed achter het prototype) bruikbaar of waardevol te zijn. Het prototype is dus een tool/vehicle om het concept te itereren en te toetsen/testen. (IM)