Workshop: Creativiteit en Methodologie binnen het Ontwerpgericht Onderzoek Nick Degens & Chris Dijksterhuis Lectoraat User-centered Design (UCD) Opleiding Communicatie en multimedia design (CMD) 31/01/2017

Huidige functie: Lector User-Centered Design Even voorstellen…. PhD: Designing an agent-based intercultural training tool (Wageningen Universiteit) PhD: Measuring mental workload for user adaptive aid (Rijksuniversiteit Groningen) Een greep uit CV: Educatieve Games voor Intercultureel Trainen, Ontwerpgericht Onderzoek, Technologie voor Gezondheidsprofessionals Een greep uit CV: InCar interface ontwerp, User Experience Onderzoek, Smartglasses voor demente ouderen Huidige functie: Senior Onderzoeker ‘New Technologies’ en Hogeschooldocent Onderzoek bij CMD Huidige functie: Lector User-Centered Design

Communicatie en Multimedia Design Anno 2016 … Vroeger... Economische (Communicatie) opleiding Creatief technologische opleiding Maken van een Prototype (van een digitaal interactief product) Uitvoeren van een ontwerpgericht onderzoek (onderzoekend ontwerpen) Opleveren van een advies(rapport) Uitvoeren van een praktijkgericht onderzoek

Tijdens deze workshop Belangrijkste doel: Wat zijn (goede) ontwerpvoorwaarden? Waarom is systematiek nodig in het creatieve ontwerpproces? Wat is de rol van de ontwerpvoorwaarden in het ontwerpproces? 0 - 15 minuten – Korte inleiding 15 – 50 minuten – Doen! 50 – 65 minuten – Bespreking

Je wilt een ontwerp dat een probleem oplost In den basis: Er is een situatie die beter kan (probleem) Je maakt een product Situatie is verbeterd (probleem opgelost)

Gaat helaas niet altijd goed…

Waarom zouden ontwerpers onderzoek willen? In een creatief proces zijn vele oplossingen mogelijk immers… Maar… we willen vermijden dat we alleen maar op ons gevoel afgaan (“dit leek mij wel leuk”) Beter om op een onderbouwde manier naar een oplossing toe te werken Communicatie-doeleinden met alle stakeholders

Indeling onderzoekstypen* Onderzoek richt zich op generatieve oplossingen / principe oplossingen voor een bepaald type veldproblemen (van Aken en Andriessen, 2011) Hoog Ontwerpgericht wetenschappelijk onderzoek Fundamenteel onderzoek Focus op fundamentele verklaring “Whereas natural science tries to understand reality, design science attempts to create things that serve human purpose.” March & Smith, 1995 Zuiver toegepast ‘ontwerpgericht onderzoek’ Laag Laag Hoog Focus op toepassen *Gebaseerd op Stokes, 1997

Ontwerpgericht onderzoek

Ontwerpgericht onderzoek uitvoeren… Probleem 1. Probleemanalyse/ exploratie 2. Ideeëngeneratie 3 Prototypering 4. Evaluatie 1. Van probleemoriëntatie naar ontwerpvoorwaarden 2. Van ontwerpvoorwaarden naar een uitgewerkt concept 3. Van uitgewerkt concept naar (varianten van) een interactief prototype 4. Van interactief prototype naar definitieve ontwerpvoorwaarden (eventueel met verbeterd prototype)

Hoe ziet dat er dan uit? Abstract (Niet gelinkt aan een specifiek ontwerp) Specifiek (gelinkt aan specifiek ontwerp) Vooronderzoek & Theorie Ontwerp-voorwaarden Ontwerp-Beslissingen Prototype Ideeën genereren

Van Theorie naar Design – Vb. The aspect of uncertainty in outcome is an important one for our playcentric process because it is a key motivator for the players. If players can anticipate the outcome of a game, they will stop playing. You have probably been in this situation before – when one player is so far ahead that no one will be able to catch up. At this point, everyone generally agrees to end the game (Fullerton, 2008, p. 32). Vooronderzoek &Theorie This is an example of a piece of theory that the student chose. It’s important to ask the students what it actually means, so be sure to let them read it and ask them what this piece of theory would entail (perhaps give examples of games they’ve played themselves?)

Van Theorie naar Design – Vb. Ontwerp-voorwaarden Players need to encounter unexpected situations in the game This is the requirement that the student formulated based on the description of the theory. Important here to look back at how a requirement should be formulated (for instance, this is missing its ‘success criterium’.

Van Theorie naar Design – Vb. Ontwerp-beslissingen At certain moments throughout the interval training you will be chased by a dog. If the dog catches up with you, your score will decrease. So, how did the theory get translated into a specification. Well, the student decided to implement a ‘dog’ that chases the user from time to time. It is unexpected, as the user doesn’t know when it will happen, and is tied to the points of the user (so they will be surprised, but then motivated to ‘beat’ the dog). Discuss with the students if this is a plausible specification and if it really follows what the theory said. Important here to get the discussion started.

Van Theorie naar Design – Vb. Prototype Here you can see the final design. Does it follow the specification as stated by the student? Is it clear to the user? There are still many questions that need to be answered here.

Het spel Zes verschillende blokjes Een bouwwerk

Het team evalueert of aan de ontwerpvoorwaarden voldaan is De opdracht De opdrachtgever: selecteert een kaartje (en laat deze niet zien aan het projectteam). Dit is de opdracht stelt 3 ontwerpvoorwaarden op. Deze ontwerpvoorwaarden mogen geen specificatie zijn, maar nog abstract Deze abstracties mogen betrekking hebben op eigenschappen van de blokken (vorm, oriëntatie, kleur, positie t.o.v. elkaar) Deze abstracties mogen betrekking hebben op ‘holistische’ eigenschappen van de opdracht Eén ontwerpvoorwaarde mag niet meer dan 2 eigenschappen (zoals oriëntatie of vorm) benoemen. Werk in groepen van 5 Rolverdeling 1 opdrachtgever 4 leden in het projectteam Opdrachtgever geeft ontwerp- voorwaarden Het team bouwt Het team evalueert of aan de ontwerpvoorwaarden voldaan is De opdrachtgever evalueert het bouwwerk en stelt (eventueel) extra voorwaarden op . Wanneer de opdracht voldoende is benaderd, wordt iemand anders in het team opdrachtgever en doen een andere opdracht. Vraag: hoeveel iteraties waren nodig, en wat bleek een efficiënte manier van voorwaarden opstellen

Een illustratie klassikaal Wit is staat centraal. De meeste blokken staan rechtop. Het moet op een boorplatform lijken. Er staat een rij blokken knus bij elkaar. Het geheel heeft geen scherpe punt. De meeste blokken bevinden zich onder het vlak Enzovoort…..

En nu jullie!

Debriefing Wat vragen: Hoe ging de ervaring? Wat ging goed/slecht onverwacht? Wat hou je over van deze ervaring? Wat zou je de volgende keer anders doen? Wat zijn goede strategieën m.b.t. het opstellen van de ontwerpvoorwaarden (winnaars en verliezers)? Wat zegt dit ons over het ontwerpproces? Important to stress the same message again, it’s a creative process, not necessarily a best option. Whatever gets the job done!

Verschillende mensen, Verschillende uitkomsten Er zijn verschillende alternatieven, maar welke is het beste? Dat is een moeilijke vraag, daarom praten we vaak over “good enough” in ontwerpgericht onderzoek. En wanneer noemen we het dan “good enough”, als het het probleem oplost. Important to stress the same message again, it’s a creative process, not necessarily a best option. Whatever gets the job done!

Duidelijk omschreven? “A clear and concise requirement… Must consist of a single requirement, Should be no more than 30-50 words in length, Must be easily read and understood by non-technical people, Must be unambiguous and not susceptible to multiple interpretations, Must not contain definitions, descriptions of its use, or reasons for its need, and Must avoid subjective or open-ended terms.” (projekt Gruppen). See this presentation for more information (it’s intended for user requirements, but these aspects fit neatly to our concept). http://www.slideshare.net/guest24d72f/8-characteristics-of-good-user-requirements-presentation

Verschillende types requirements? User Experience requirements Usability (e.g. is de interface intuïtief?) Visueel (e.g. ziet het er mooi uit?) Mechanieken (e.g. blijven mensen het gebruiken?) Technische requirements Hardware (e.g. kunnen we complexe 3d simulaties draaien?) Software (e.g. kan de gebruiker externe software draaien in de virtuele werkomgeving?) Functionele requirements Gedrag (e.g. worden de revalidatie-oefeningen wel gebruikt in de app?) Cognitie (e.g. sluit het aan op de voorkennis van de gebruiker?) En zo nog veel meer. Let the students (each with their different expertise) give some more examples of each point. The goal here is to make people think about different types of design requirements (for different purposes and aspects of the to-be-design game). It’s best to differentiate between the functional requirements of the game (what should the game change in users), process-related requirements (is it fun/good to use) and technical aspects (technical feasability). There are many more though however, and there is no exhaustive list.

Scope Robertson & Robertson. Mastering the Requirements Process “M = Mandatory requirement. 'This feature must be built into the final system.' D = Desirable requirement. 'This feature should be built into the final system unless the cost is too high.' O = Optional requirement. 'This feature can be built into any system we have.' E = Possible future enhancement. 'This feature may be used in the final system, however we just want the feature in and of itself.‘” Pretty self-explanatory, important to state as not everything has the same level of priority. Robertson & Robertson. Mastering the Requirements Process

Systematisch ontwerpen Let the students (each with their different expertise) give some more examples of each point. The goal here is to make people think about different types of design requirements (for different purposes and aspects of the to-be-design game). It’s best to differentiate between the functional requirements of the game (what should the game change in users), process-related requirements (is it fun/good to use) and technical aspects (technical feasability). There are many more though however, and there is no exhaustive list.

Nog verdere vragen? Chris Dijksterhuis Senior Onderzoeker Nieuwe Technologie Hogeschooldocent Onderzoek CMD c.dijksterhuis@pl.hanze.nl Nick Degens Lector User-Centered Design d.m.degens@pl.hanze.nl | @nickdegens Let the students (each with their different expertise) give some more examples of each point. The goal here is to make people think about different types of design requirements (for different purposes and aspects of the to-be-design game). It’s best to differentiate between the functional requirements of the game (what should the game change in users), process-related requirements (is it fun/good to use) and technical aspects (technical feasability). There are many more though however, and there is no exhaustive list.