Les collectivités territoriales et les services de l'Etat sont confrontés à de multiples enjeux : crise des finances publiques, augmentation des dépenses sociales, défiance croissante des administrés, concurrence des solutions proposées par des communautés numériques très agiles. La bonne nouvelle, c'est que des solutions existent pour faire mieux avec moins ! L'innovation publique, c'est possible grâce aux apports de ce que l'on appelle la pensée design, qui permet de repenser le service offert à l'usager. Ce MOOC a été réalisé en partenariat avec le Conseil départemental du Val d'Oise, pionnier dans la mise en oeuvre de ces approches. Son originalité ? Nous vous proposons une expérience d’apprentissage très riche basée à la fois sur l'expertise de spécialistes du sujet et sur l'expérience de nombreux acteurs publics de terrain, qui mettent en œuvre cette approche et apportent leur témoignage dans les différents modules. Notre objectif ? Vous donner les compétences pour coordonner un projet d'innovation publique s’appuyant sur une approche design de service, quels que soient le domaine et le contexte dans lesquels vous travaillez. Bienvenue dans ce MOOC ! Thierry Sibieude et l'équipe pédagogique
Yoan Ollivier, Plausible Possible
Loading...
En provenance du cours de ESSEC Business School
Innovation publique et pensée design, l'innovation sociale au service des territoires
19 notes
ESSEC Business School
19 notes
À partir de la leçon
Etape 3 de l'approche design : l'expérimentation / implementation
Nous allons dans cet épisode faire un zoom sur la 3ème étape de l’approche du design thinking, celle de l’expérimentation ou implementation dans le langage d’Ideo. C’est l’étape au cours de laquelle on va aller à la rencontre des futurs utilisateurs du service pour tester la solution et l’améliorer par un processus itératif.
Que teste-t-on pendant la phase d’expérimentation ? Comment mener cette phase à bien ? Qu’apporte le prototypage ? Comment mesurer la pertinence d’une solution ?
Rencontrer les enseignants
Thierry SibieudeProfesseur
Droit et Environnement de l'Entreprise
[MUSIQUE]
[MUSIQUE] Je m'appelle Yoan Ollivier,
de l'agence Plausible Possible, je suis designer de service,
et je travaille principalement pour des collectivités.
L'expérimentation ça va intervenir plutôt en fin de parcours, au moment où un
projet est relativement décidé et où on va le mettre à l'épreuve du réel, donc,
de ce point de vue-là, ça veut dire qu'en tant que designer,
on va intervenir surtout sur la mise en place d'un cadre expérimental,
c'est-à-dire essayer de définir quels sont les éléments que l'on va tester ou non, on
ne va pas tester l'ensemble d'un service, mais on va aussi tester les éléments les
plus saillants, les plus représentatifs, ceux qui vont faire le plus de sens
dans la modification que le projet va avoir sous l'usage du service proposé.
On pourrait dire qu'il y a à peu près trois types d'acteurs.
Il y a les personnes qui organisent le test,
ils peuvent être les designers ou les services qui sont concernés,
les personnes qui sont les opérateurs, les gens qui vont faire marcher le service,
et les utilisateurs, ceux qui pour qui le service est fait.
En tant que concepteurs, on va travailler avec ces trois types de personnes
dans un premier cas principalement sur
la manière dont on est capable de cerner le périmètre d'un test d'expérimentation
pour pouvoir le laisser à disposition et vérifier leurs enseignements.
Les opérateurs que l'on va embarquer, parce qu'ils vont devoir eux-mêmes
changer leur pratique, leur manière de faire, et être les acteurs de ce test.
Dans la plupart des cas,
c'est les opérateurs qui vont jouer un jeu de rôles pour essayer pour remettre
en situation le test pour pouvoir en tirer les enseignements.
Donc, ils sont à la fois, les acteurs et les capteurs de ces enseignements.
Et enfin, on va avoir les utilisateurs qui sont les personnes qui nous donnent,
somme toute, la plupart des retours, qui sont les personnes à qui on fait
vivre le test et qui nous expliquent comment ces rapports fonctionnent.
Et dans tous les cas,
l'objectif va être d'essayer de réussir à interroger une diversité de situations
de manière à vérifier la robustesse de l'expérimentation qu'on va avoir.
Si on a que les mêmes types de retours, on va être dans une situation qui nous
donnera des enseignements qui risquent d'être relativement pauvres.
Donc l'objectif, c'est bien réussir à capter quels sont les différents types
d'acteurs qu'on va pouvoir questionner, quels sont les différents de contextes.
Dans un premier cas, c'est bien de délimiter cette diversité-là, mais aussi
savoir la restreindre, parce que si on fait une expérimentation sur un trop grand
nombre de sites ou de situations, on a aussi le risque se de perdre dans une
expérimentation qui perdra du sens, parce qu'elle essayera de tout questionner.
Ensuite en terme de points de vigilance, l'un des point important,
c'est nous ne sommes pas en train de tester la réalité,
l'expérimentation est toujours un système de conception en tant que telle,
donc elle doit pouvoir nous ramener les enseignements.
Au moment où l'on fait une expérimentation,
il faut bien savoir que, on a de grandes chances que ça ne fonctionne pas
et laisser la place à cette erreur-là et laisser le temps de pouvoir comprendre les
erreurs que retire l'expérimentation, font partie du champ de conception.
L'expérimentation c'est un processus qui peut prendre du temps.
Dans certains cas, certains éléments peuvent être testés très rapidement parce
qu'on est sur une sorte de reconnaissance directe.
La signalétique,
l'information sont des éléments que l'on peut tester très rapidement.
Par contre, les changements d'usages,
pouvoir comprendre comment est-ce que dans un processus de suivi long, on est capable
de pouvoir accompagner un changement entre l'état initial et l'état proposé.
Cette transition, elle doit pouvoir être prise en compte et elle va déterminer la
longueur de l'expérimentation qu'on va pouvoir faire.
Une difficulté lorsqu'on lance une expérimentation,
c'est d'être capable d'en donner la fin.
Parce que par définition, on est sur des systèmes qui sont perfectibles
et dans un monde rêvé de designers, ce serait une expérimentation permanente,
qui serait plutôt inconfortable pour les utilisateurs.
De fait, il faut qu'on soit capable de déterminer en amont
quelle sera la date de fin d'une expérimentation.
Pour choisir cette date de fin, généralement ça pose la question de
l'élément dont je parlais tout à l'heure qui est la durée de l'expérimentation,
on va questionner cette durée-là, mais la fin de l'expérimentation va arriver au
moment où on a l'ensemble des informations qu'on souhaitait obtenir et dont la
situation dans laquelle qu'on est capable de réagir et arbitrer par rapport à ça.
L'expérimentation c'est pas une fin en soi,
c'est un moyen qui doit nous permettre d'obtenir des enseignements du terrain,
aux vues d'une solution proposée et de pouvoir en vérifier la résistance.
L'expérimentation c'est pas un fait designer,
on doit pas être l'acteur principal qui réalise l'expérimentation,
il faut que ça soit pensé comme logique d'accompagnement dans lequel on va pouvoir
suivre les opérateurs pour qu'ils puissent tester, comprendre.
Et, en premier lieu, l'un des retours qui est le plus informel et qui est difficile
à pouvoir capter, c'est ce retour et ce changement d'expériences et d'expertises
qui auraient été vécus par les opérateurs après une expérimentation.
Le deuxième point, c'est il faut pouvoir capter un ensemble d'informations
aux vues d'une expérimentation, c'est-à-dire être capable de documenter,
des photographies, des films, des témoignages.
Ça va aussi être des retours documentés sous forme d'outils qui vont nous
permettre de collecter les retours d'utilisateurs
sur le changement de perception, est-ce que c'est mieux,
moins bien, est-ce que on se sent plus à l'aise, est-ce que c'est plus fluide.
La qualification des retours des utilisateurs va être important.
Enfin, il y a une question qui est aussi quelles sont les données factuelles qu'on
est capable de retirer, parce que si le design est souvent très orienté vers des
questions de qualité, de qualitatif, il serait dommage de pas se priver du temps
d'expérimentation pour avoir des retours qui sont chiffrés, et à ce moment-là,
la question va être d'identifier quels sont les bons indicateurs qui font que
l'expérimentation va nous donner des retours.
Est-ce qu'il y a une augmentation du nombre de coup de téléphone entre
avant et après l'expérimentation.
Est-ce qu'on a diminué le nombre de mail,
est-ce que l'on a augmenté la fréquentation d'un site, est-ce que l'on
a diminué le retour et la fréquence de venues de quelqu'un dans un espace.
C'est autant de questions qu'il va falloir chercher à identifier.
Lorsqu'on va lancer une expérimentation dans le designer,
on va travailler sur différents éléments.
On va travailler cadre, on va travailler les objets de l'expérimentation,
on va travailler les éléments de recueil de l'expérimentation, Lorsque l'on va
travailler sur le cadre, c'est qu'on va définir quels sont les objectifs
d'une expérimentation, à quoi elle va servir, qu'est-ce qu'elle va vérifier.
De ce point de vue-là, il faut que chaque expérimentation, chaque élément de test,
soit très circonscrit dans son espace et dans son temps de manière à bien
tester la vérificateur d'un facteur, ou de deux au maximum,
mais essayer d'être plutôt humble dans le choix des différents éléments test,
de manière à pouvoir avoir des résultats effectifs.
Quand on va travailler cette expérimentation dans le designer, soit on
va être dans une logique de suivi, soit on va être dans une logique de prototypage.
Lorsqu'on est dans une logique de prototypage, de fait,
on va arriver avec des éléments tangibles,
on va arriver avec des plaquettes qui sont des fausses plaquettes, on va transformer
un accueil, on va travailler la relation et la liste de questions qui vont être
faites par un agent, avec tous ces éléments de prototypes-là,
ils doivent être vérifiés avec les équipes en amont, pour que le moment du test venu,
ce soit quelque chose de fluide et d'agréable pour les personnes.
Il n'y a rien de pire que de faire un test qui met en échec les opérateurs qui
ont travaillé dessus.
Enfin, c'est aussi poser la question très en amont de la manière dont on va
collecter les informations et de la manière dont on va pouvoir
restituer l'expérimentation.
Est-ce que on a une caméra qui filme en temps continu l'évolution des transports.
Est-ce que on fait des interviews après le test de différents utilisateurs.
Est-ce qu'on a une grille de notation qui est uniquement utilisée par les
opérateurs.
C'est autant de questions mais qui doivent être réfléchies
en amont en expérimentation de façon à ce qu'aux sorties de de l'expérimentation,
qu'on ait bien les éléments qui soient intéressants à traiter et qui nous
permettent d'outiller l'aide à la décision
des personnes qui vont pouvoir réfléchir à la suite du service.
La nature des tests, elle va être très différente en fonction des projets, on
peut très bien tester des objets, tester des services ou tester des processus.
En fonction de ces trois critères là,
on est face à des degrés de changements et de modifications de l'existant qui sont
assez différents qui font que le test est plus facile à réaliser.
Lorsque l'on teste un objet ou un espace on est face à une réaction très directe de
la part des usagers.
En fait, il vont découvrir l'objet qu'on leur présente et il ne vont pas
forcément se poser la question de sa nature.
Est-ce qu'il y réponds ou non à a question, et c'est l'unique objectif
qu'ils auront en tant qu'utilisateurs, et c'est le retour qu'ils vont faire.
Lorsqu'on teste un service,
on est face à une situation qui est plus dispersée dans le temps.
On aura sans doute une information initiale, le changement d'un site web,
le changement d'une plaquette, le changement d'une somme de petits éléments
constitutifs du service, qui fait que le test va être relativement être plus
complexe parce qu'on va devoir essayer d'insérer ces différents éléments dans un
processus existant, et de voir comment est-ce qu'il des modifications.
Donc on est face à un test qui, déjà sous entend,
que l'on est déjà dans un processus de changement.
Lorsqu'on va tester un processus, on est directement dans un processus de
changement et c'est là toute la difficulté, c'est qu'en
testant des modes de relations, on les fait vivre, et lorsqu'on les fait vivre,
il y a forcément des crispations qui peuvent exister.
[MUSIQUE]
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2018 Coursera Inc. Tous droits réservés.
