Design MetaData
Retour d’expérience sur un atelier de design interactif interdisciplinaire dans une démarche d’innovation ouverte Design MetaData: Report on a interdisciplinary design workshop

1. Introduction

Les formations de designer et d’ingénieur divergent par une multitude de facteurs parmi lesquels nous pouvons citer : les méthodes, techniques et approches. Néanmoins, designers, ingénieurs et autres corps de métier collaborent souvent dans des contextes industriels, dans le but de concevoir des dispositifs interactifs et leur expérience utilisateur. Ce travail collaboratif requiert un partage des tâches lors de missions comme la conception de services, d’expériences, de systèmes ou d’autres artefacts.

La collaboration de ces deux cultures se heurte en général à des incompréhensions liées à leur cloisonnement disciplinaire. Les étudiants en ingénierie peuvent percevoir l’activité du designer comme une surcouche esthétique, et les étudiants en design réduisent souvent le travail d’ingénierie à un problème d’implémentation. Il est connu que la compréhension de problème et la conception d’un système par un étudiant en design et en ingénierie sont radicalement différentes (Lawson, 1979). Ces différences sont à la hauteur de leur complémentarité. Notre hypothèse est que la rencontre de ces deux approches est génératrice de solutions innovantes.

Cet article rend compte du travail réalisé durant les trois éditions de l’atelier. Nous présentons tout d’abord les motivations qui nous ont poussés à concevoir ces ateliers. Ensuite nous discutons de l’état de l’art des travaux relatifs. Par la suite nous détaillons les principes de l’atelier : son modèle, ses méthodes et ses enjeux. Nous présentons ensuite les travaux réalisés par les étudiants. Puis nous rapportons et discutons les observations effectuées au cours de ces trois éditions. Enfin, nous discutons des problèmes que nous avons identifiés et de leurs implications dans le contexte de l’enseignement interdisciplinaire du design interactif.

2. Motivation

2.1. Innovation ouverte et exploration

Notre institut a pour mission d’anticiper, d’accompagner et d’analyser les mutations des pratiques culturelles permises par les technologies numériques, et de contribuer parfois à les faire émerger. Dans ce cadre, nous menons un travail de veille, mais aussi de design exploratoire et appliqué. Dans ces travaux, nous cherchons à identifier des usages et scénarios émergents. Ces tâches sont généralement effectuées par des chercheurs affiliés à notre institut mais dont le temps est limité. Ces chercheurs travaillent la plupart du temps sur des projets précis tant en termes de scénario que de technologie, et pour lesquels peu de temps est consacré à la partie exploratoire et à des scénarios plus divergents de leurs objectifs. Ils ne peuvent donc pas explorer l’ensemble des espaces de conceptions posés par les problématiques de recherche de l’institut.

2.2. Production de prototypes fonctionnels

L’une des motivations de cet atelier est d’explorer de nouveaux scénarios et cas d’usage, mais aussi de produire des prototypes fonctionnels. À travers l’implémentation des scénarios, nous visons plusieurs objectifs : l’évaluation, la pédagogie et la communication.

• Évaluation : pour une personne non experte, comme un utilisateur potentiel, il est parfois difficile de se projeter dans un dispositif interactif uniquement sur la base de maquettes, d’idées et de scénarios. A contrario, un prototype fonctionnel permet d’évaluer dans des conditions plus réalistes la validité d’une interface et d’un scénario d’usage.

• Pédagogie : transformer un concept en prototype implique un grand nombre de prises de décisions qui se complexifient dans un contexte interdisciplinaire. Apprendre à identifier, à formuler, à éliciter, puis à prendre ces décisions en concertation avec des groupes hétérogènes nous semble être une compétence essentielle à acquérir.

• Communication : un prototype permet de rendre publics et de communiquer les projets dans des modalités différentes (Seago et Dunne, 1999) et de manière plus convaincante qu’une vidéo de démonstration ou qu’une maquette.

2.3. Interdisciplinarité

Le design interactif est par définition un domaine multidisciplinaire (Saffer, 2010). Par exemple, dans les écoles et le milieu universitaire, le design interactif mélange des disciplines comme l’architecture, les interfaces hommes-machines, l’ingénierie, l’informatique, les sciences humaines. Ce métissage est d’autant plus riche dans l’industrie, notamment dans les agences, chez les commanditaires ou les consultants, où l’on rencontre souvent, autour d’un même projet, une équipe composée de designers, d’ingénieurs, d’un responsable de projet, mais aussi d’un responsable éditorial, et d’autres corps de métier. Bien que la constitution d’équipes pluridisciplinaires soit la norme en entreprise, c’est loin d’être le cas dans les écoles de design ou d’informatique.

3. État de l’art

Fallman (2008) identifie trois approches de l’activité de recherche en design : la pratique du design, l’exploration par le design, et l’étude du design. Cet atelier de travail se situe sur un axe entre pratique du design, et exploration du design. Comme le rapporte et synthétise Löwgren (Löwgren, 1995), on peut distinguer deux approches du design différentes dans la conception de logiciel : le design technique et le design créatif. Ils opposent ces deux approches par leurs méthodes, processus, objectifs, et positions de l’auteur. L’atelier présenté dans cet article tente d’étudier dans quelle mesure ces deux approches peuvent être rapprochées dans une démarche créative. Wolf et al. (2006) commentent l’importance du design créatif dans la recherche sur les interactions entre l’homme et la machine. Ils distinguent cette approche d’autres approches telles que le design centré utilisateur et le design participatif. Lors de cet atelier, nous suivons une démarche similaire.

4. Description des ateliers

Le design de cet atelier a été fortement inspiré par l’approche décrite par Raskin (2010), où il présente une stratégie d’innovation ouverte mise en place à la fondation Mozilla. À partir de ce travail, nous avons défini un programme d’ateliers pour des étudiants de design et d’écoles d’ingénieurs de quatrième année universitaire. Dans cette section, nous décrivons, d’une part, le modèle et les méthodes de l’atelier et, d’autre part, les variations liées aux différentes éditions.

4.1. Calendrier et méthode

Un calendrier idéal est établi en début d’atelier (tableau 1). Il constitue pour les étudiants une référence où chaque étape de la réalisation est listée dans un ordre chronologique. Ce planning est un repère que les équipes sont encouragées à suivre. Vers le milieu du semestre, une première phase de conception se termine et la phase de réalisation démarre. C’est un moment où la collaboration interdisciplinaire passe de tâches communes à des tâches complémentaires. Les étudiants ingénieurs et designers sont amenés à solliciter leurs compétences-métier. Les étudiants entrent dans une phase où la communication devient essentielle à la production. Les points de rencontre entre disciplines sont l’occasion de prendre connaissance des avancées de chacun et de critiquer ou de remettre en cause certains progrès. Bien que le respect du calendrier soit un objectif pour chaque édition, il a connu chaque fois des arrangements liés aux contraintes des écoles respectives ou de l’avancée individuelle des projets.

Tableau 1. Planning de l’atelier

Chaque semaine de l’atelier est rythmée par une session de travail collectif de 2 à 4 heures. Cette session a lieu avec l’ensemble des étudiants et l’équipe pédagogique. Cette session se déroule selon le modèle suivant :

1. Livraison : les étudiants présentent des livrables par projets/équipes à toutes les personnes de l’atelier.

2. Revue par les pairs : les étudiants sont encouragés à critiquer constructivement ces livrables, les encadrants aident à la médiation.

3. Besoins : les étudiants sont interrogés sur leurs besoins de ressources pédagogiques supplémentaires. Si un besoin est identifié, un cours sera fait par un encadrant sur le sujet la semaine suivante.

4. Encadrement : les étudiants travaillent par équipe avec un ou plusieurs encadrants qui viennent répondre à leurs demandes.

5. Coordination : les étudiants de chaque équipe se réunissent pour planifier et préparer leur prochain livrable projet et le valide avec un encadrant.

Cette description de session est le modèle que nous avons cherché à mettre en place ; il a pu s’adapter aux besoins des étudiants et aux contraintes de la situation. Par exemple, quand les étudiants sollicitent un cours sur un savoir ou un savoir-faire particulier (ex. : comment faire un bon wireframe ?), nous réduisons le temps d’encadrement et de revue par les pairs pour le dédier à la présentation.

4.2. Éditions

Nous avons réalisé trois éditions de cet atelier (2011, 2012, 2013) détaillées dans le tableau 2. Ce qui est commun à toutes ces éditions est le calendrier, la méthode et le titre. En revanche, les variations entre éditions ont porté sur des facteurs tels que la thématique, les problématiques soulevées, les acteurs encadrants, les écoles et étudiants engagés, et l’équilibre entre étudiants en design et en ingénierie.

Tableau 2. Récapitulatif des différentes éditions

4.3. Thématique

Le titre de l’atelier Design Metadata suggère l’axe de réflexion central qui demeure en quelque sorte une méta-problématique sous-jacente aux ateliers : quels usages des métadonnées peut-on imaginer pour le futur ?

Figure 1. Flyer Design Meta data éditions : (a) 2011, (b) 2012, (c) 2013

L’édition 2011 a été mise en place avec les écoles ENSCI, Strate College et Esilv. Elle a été menée sur le thème de la production et de la navigation de métadonnées pour la vidéo en ligne. L’objectif des problématiques principales de l’atelier était d’imaginer des scénarios utilisateurs dans différents contextes d’application. Pour l’édition 2012, le thème de travail était le « Data Journalisme » et la visualisation d’information. Cette édition s’est distinguée par deux facteurs qui ont eu de sérieuses répercussions sur l’atelier. En premier lieu, des étudiants en 4^e année de l’école Centrale Paris ont rejoint des étudiants des écoles habituelles. Par ailleurs cette édition a été impactée par une erreur de sélection du niveau des étudiants d’une école de design, qui étaient en première année et non en quatrième année. Pour l’édition 2013, nous avons rassemblé tous les étudiants dans un atelier unique et ouvert à de nouvelles écoles. Cinq écoles ont ainsi participé : l’Ensad, l’Ensci, Strate College, l’Hetic et l’Esilv. Cette édition a été menée sur le thème du mashup. Ouverte à davantage d’écoles, cette édition comptait plus d’étudiants par groupe et plus de groupes ou projets pour le même temps d’encadrement.

5. Cas pratiques

Afin d’illustrer de manière concrète les travaux réalisés lors de cet atelier, nous présentons dans cette section deux projets par édition. Ces projets ont été sélectionnés afin d’illustrer différentes dimensions de l’atelier, comme la finition du prototype, la proximité avec le sujet et le degré de collaboration interdisciplinaire.

5.1. CoBalt

Figure 2. Image extraite de la vidéo de démonstration de Cobalt

5.2. Création Urbaine Lumineuse Tactile (CULT)

Figure 3. (a) À gauche, extrait de la vidéo de scénario de CULT.
(b) Au milieu, rendu de dessin réalisé avec le prototype.
(c) À droite, interface de retour et de développement du prototype

5.3. KEP

5.4. Tamizer

Figure 4. Tamizer : a) la signalétique au sol présentant chaque étape de navigation, b) l’affichage à l’écran, c) photo lors de la présentation du prototype

5.5. Codeplay

Codeplay est un projet créé pendant l’édition 2013-Mashup. Il a été initié par Pauline Gourlet, étudiante à l’ENSAD, et conçu et réalisé par deux développeurs, Damien Degrémont (HETIC), Jean-Baptiste Minvielle (HETIC), et trois designers Pierre Berthelot Kleck (Strate College), Valentin Fontaine (ENSAD), Jade Gardais (Strate College). Le sujet original de Codeplay était de proposer un projet à la fois éducatif, ludique et basé sur des éléments physiques, tangibles. Le projet devait répondre au thème du mashup par la logique d’assemblage d’objets. L’équipe a choisi d’appliquer ces principes à l’enseignement de la programmation informatique, et de cibler les jeunes enfants (de 5 à 8 ans). Confrontée à des problèmes techniques liés aux interfaces tangibles, l’équipe a décidé de livrer une maquette sur écran, accompagnée de prototypes non fonctionnels des parties tangibles. Ces éléments contenus dans une housse pour tablette tactile peuvent être assemblés comme un jeu de construction. Cette maquette et une vidéo de présentation du projet ont pu être présentées lors de l’exposition.

Ce projet a permis de repenser la thématique de l’année sous une forme radicalement différente des trois autres équipes, pour lesquelles un mashup se composait nécessairement de médias. Les contraintes techniques qui découlent des choix de conception n’ont pas permis d’arriver au prototype fonctionnel. Néanmoins ils ont permis à l’équipe d’explorer un espace de conception peut-être plus audacieux.

Figure 5. Prototypes d’objets tangibles créés durant l’atelier

6. Discussion

Ces trois éditions de l’atelier nous ont permis de mettre à l’épreuve notre calendrier et la méthodologie employée. Toutes les équipes ont réussi à produire un prototype pour la plupart fonctionnel, souvent accompagné d’une vidéo de scénario. Les retours des étudiants, de leurs écoles respectives ou encore des professionnels venus assister aux présentations des prototypes sont globalement positifs, témoignant sans doute du niveau d’exigence de l’atelier, de la finition de certains prototypes ou encore de la qualité des idées développées. Sur le plan méthodologique, les étudiants ont acquis une démarche d’analyse et d’innovation éprouvée dans les milieux professionnels. Cependant, l’observation des trois ateliers nous a permis d’identifier certains manquements et problèmes récurrents que nous allons discuter dans cette section. Chaque édition aura été l’occasion de tester de nouvelles configurations pour tenter d’améliorer les objectifs de l’atelier, notamment la collaboration interdisciplinaire. Cette section aborde à la fois les questions propres à l’enseignement du design et du prototypage (état de l’art, contrainte de développement) et les questions propres à l’interdisciplinarité (revue par les pairs, gestion de projet, interdisciplinarité) sous-jacentes à l’ensemble de notre atelier. Nous adressons à chaque problème des facteurs d’amélioration potentiels comme autant d’ingrédients nécessaires à l’interdisciplinarité pour la conception créative et la réalisation d’interfaces.

6.1. Analyse de l’état de l’art

Lors de l’édition 2013, le travail de réflexion préalable à la conception a été plus mince que dans les groupes précédents, et le niveau d’innovation des projets en a pâti. Sans cette étape de recherche et d’articulation de l’état de l’art, les projets ont tendance à se focaliser sur l’aspect ludique des concepts. Nous pensons aujourd’hui que cette étape d’état de l’art est primordiale dans le processus de l’atelier. A contrario lors de l’édition 2012, le travail d’état de l’art a été plus soigné ce qui a eu pour conséquence une phase d’exploration de l’espace de conception plus prolifique. Il ne s’agit pas nécessairement d’effectuer un état de l’art exhaustif d’un domaine d’application, mais plutôt d’introduire les enjeux d’un scénario ou d’une thématique à travers l’étude et l’analyse précise d’un service ou d’une interface. C’est un exercice intéressant pour les étudiants qui s’attèlent à décrypter et à déconstruire ce qui leur apparaissait parfois comme une évidence.

6.2. Dynamique de groupe hétérogène

Au fil des années, les groupes se sont complexifiés en accueillant des étudiants provenant parfois de trois ou quatre écoles différentes. Or, nous avons observé que, pour les groupes présentant une grande mixité d’écoles, la dynamique de groupe est plus difficile à maintenir sur toute la durée de l’atelier. Nos contacts en présentiel ou par courriel avec ces groupes obtenaient peu ou pas de réponse, témoignant d’un certain désengagement. Pour les ateliers à venir, nous avons envisagé une solution afin de répondre à ce problème. Nous tenterons de responsabiliser l’ensemble de l’équipe en introduisant un rôle de référent auprès de l’équipe encadrante. Le référent aura pour tâche de gérer le projet. Nous espérons que cela pourra indirectement maintenir le niveau d’engagement de chacun.

6.3. Revue par les pairs

La démarche de revue par les pairs de chaque livrable s’est heurtée à plusieurs problèmes : (i) un manque d’engagement général des étudiants sur cette activité, (ii) la formulation de commentaires peu constructifs et (iii)finalement, un aspect chronophage sur le reste de la session. Nous avons observé des difficultés pour engager les étudiants dans cette action. Nous pensons que cela est peut être lié à plusieurs facteurs d’inhibition : (i) le fait d’exposer une critique à des personnes non familières pouvant être perçue comme inhibant, par ailleurs (ii) le fait que la critique puisse être perçue comme négative, aspect auquel on souhaite se soustraire et soustraire les autres, et enfin (iii) le fait de manquer d’une grille d’évaluation qui aide à identifier des points d’amélioration du projet présenté. Une des pistes d’amélioration est de proposer des formulaires papier par étape de livraison avec une grille d’évaluation prédéterminée par type de livrable afin (i) d’engager les étudiants dans ce processus, (ii) d’aider les étudiants à positionner leur projet dans la grille ainsi que leurs réactions, et, enfin, (iii) de structurer des retours de manière constructive. En plus d’expliciter les tenants et aboutissants de la méthode, il pourrait être nécessaire d’introduire l’exercice comme un livrable.

6.4. Prototyper et concevoir rapidement, contraintes et bénéfices

Dans les équipes qui n’ont pas pu mettre en place un prototypage rapide, les difficultés provenaient (sans exclusivité de la cause) : (i) d’un temps de définition du projet trop long, (ii) de la difficulté à choisir le bon environnement technologique, (iii) d’une mauvaise communication intergroupe, (iv) du manque de culture des méthodes agiles pour certains étudiants ingénieurs. Dans ce dernier cas, nous avons observé que les ingénieurs ne voulaient pas commencer l’implémentation sans avoir l’équivalent d’un cahier des charges stabilisé. Si Tamizer a réussi à utiliser une méthode agile, c’est peut-être grâce aux contraintes techniques prédéfinies. Or, le processus de prototypage rapide n’est pas nécessairement une condition de succès. En effet, dans le projet MUP, un développeur a su très vite proposer un prototype. La conséquence a été que les designers se sont éloignés de la réflexion sur les détails du design d’interaction pour travailler davantage sur l’habillage visuel.

6.5. Une interdisciplinarité à approfondir et élargir ?

Certaines équipes telles que Tamizer et KEP ont très bien réussi à mettre en place des dynamiques d’échange interdisciplinaire tant dans la phase de conception que dans la phase de réalisation. Dans certains cas, nous avons observé des échanges plus difficiles liés à plusieurs facteurs comme le périmètre du projet, la culture inhérente à la discipline de chacun, l’écoute. Dans un projet comme CodePlay, la problématique (apprentissage de la programmation) adressait directement l’expertise des ingénieurs et aurait pu amener les étudiants à dépasser la complémentarité des profils au profit d’une analyse partagée de l’activité de programmation. Peut-être cela aurait-il demandé davantage de médiation entre les deux disciplines ? Dans un contexte de collaboration interdisciplinaire, il pourrait être plus pertinent de faire travailler les étudiants sur une mission ou un scénario imposés. La résolution de problème, démarche familière pour les deux disciplines, sera plus facile à investir pour les étudiants, que de devoir créer de toutes pièces un dispositif innovant uniquement sur la base d’une thématique. Dans cet atelier, notre attente forte de création et d’innovation de la part des étudiants est peut-être un facteur inhibant pour certaines équipes durant la phase de conception.

7. Conclusion

Nous avons présenté Design MetaData, un atelier de design interdisciplinaire d’innovation ouverte. Après avoir décrit les motivations de l’atelier, nous avons détaillé les méthodes employées et le calendrier de travail mis en place. Par la suite, nous avons présenté les thématiques explorées lors des différentes éditions ainsi qu’une sélection de projets pour chacune de ces éditions. La description de ces projets nous a permis d’identifier différents facteurs qui ont contribué aux succès et aux échecs de l’atelier. Nous avons ensuite discuté ces facteurs afin d’identifier des pistes d’amélioration. Malgré la réussite relative de cet atelier, il n’est pas question de considérer cette méthodologie comme une recette définitive sans prendre en compte les multiples facteurs de chaque situation. Pour les prochaines éditions, il est prévu de mettre en place des procédures plus formelles afin d’aider l’évaluation de chacun des paramètres du dispositif. Cet article propose une approche parmi d’autres pour organiser un atelier d’innovation par le design aboutissant à la réalisation d’un objet technique. Nous assistons de plus en plus à la mise en place d’ateliers de ce type plus ou moins formels, mêlant design technique et design créatif dans un circuit court. Nous pensons que ces approches peuvent ouvrir de multiples perspectives génératives et innovantes.

Remerciements

Nous remercions avant tout les étudiants pour leur participation ainsi que les écoles de design Strate College, Ensci et Ensad, et les écoles d’ingénierie Esilv, Hetic, Centrale Paris. Nous remercions aussi l’agence ANR pour le financement, notamment celui du projet Periplus. Nous remercions aussi notre partenaire, Microsoft France.