Perspective

Votre portfolio de design pédagogique a besoin d'une chaîne de preuves

Un échantillon fini montre ce que vous avez construit. Une chaîne de preuves montre comment vous avez enquêté sur le problème, choisi une réponse, testé celle-ci et compris ses limites.

Votre portfolio dit que vous résolvez des problèmes de performance. Où puis-je vous voir faire cela ?

Un échantillon poli peut montrer vos compétences en production. Il peut aussi laisser la plus grande affirmation sur la page sans soutien. Je peux ouvrir le cours, admirer la mise en page, et ne toujours pas comprendre pourquoi le cours devait exister.

Si vous voulez un portfolio qui montre votre jugement en conception d'apprentissage, donnez au lecteur un moyen de suivre une décision. Qu'avez-vous remarqué ? Quelles preuves ont changé votre interprétation ? Pourquoi avez-vous choisi cette réponse ? Que s'est-il passé quand quelqu'un l'a essayé ?

Je considère cela comme une chaîne de preuves. Chaque lien permet à une autre personne d'examiner le raisonnement au lieu d'accepter le titre.

Commencez par une affirmation que quelqu'un peut examiner.

L'échantillon est une pièce du dossier. Ce n'est pas l'ensemble du dossier.

Cela ne signifie pas écrire un long essai à côté de chaque projet. Cela signifie choisir les quelques détails qui rendent vos décisions les plus conséquentes compréhensibles.

Connectez quatre liens.

Pour un premier passage utile, je connecterais quatre choses : le problème, les preuves, la décision, et le test.

Le problème : décrivez l'écart dans le travail. « Les employés ont besoin d'intégration » nomme un programme. « Les nouveaux coordinateurs ne peuvent pas compléter de manière indépendante un transfert précis » décrit quelque chose que vous pouvez examiner.

Les preuves : montrez ce qui a informé votre interprétation. Cela pourrait être une observation, un résultat d'entretien, un processus approuvé, ou un échantillon de travail. Expliquez ce que le matériel soutient et ce qu'il ne peut pas établir.

La décision : identifiez un choix qui a affecté l'expérience. Peut-être avez-vous remplacé un aperçu du processus par une pratique de transfert. Expliquez l'alternative que vous avez envisagée et la raison pour laquelle vous avez choisi différemment.

Le test : montrez comment vous avez vérifié le choix. Un examen de prototype peut révéler des instructions confuses. Une tâche pratique peut révéler des informations manquantes. Aucun ne prouve automatiquement un résultat commercial.

Quand l'un de ces liens manque, étiquetez l'écart. Une prochaine étape honnête est plus utile qu'un résultat inventé.

Montrez la chaîne dans un petit projet.

Voici un projet de portfolio hypothétique : aider les coordinateurs de projet à transférer le travail à une autre équipe.

La demande initiale est un module d'intégration. Dans cet exemple, les échantillons de transfert suggèrent que le problème récurrent est que les coordinateurs énumèrent les activités complètes mais omettent les décisions non résolues. Un propriétaire de processus confirme quelles informations l'équipe réceptrice a besoin.

Le designer propose un modèle de transfert et une courte activité pratique. Le modèle soutient la tâche réelle. La pratique demande au coordinateur de décider ce que l'équipe réceptrice doit savoir avant d'accepter le travail.

Un extrait de cas d'étude concis.

« J'ai concentré le prototype sur les décisions non résolues parce que les échantillons de transfert montraient qu'elles étaient souvent manquantes. J'ai associé un modèle réutilisable avec une pratique plutôt que de créer un large module d'intégration. Le premier test examinerait si les utilisateurs peuvent identifier la décision manquante, enregistrer son propriétaire, et expliquer ce qui reste bloqué. »

Remarquez ce que cet extrait ne revendique pas. Il ne dit pas que le prototype a réduit le travail supplémentaire, amélioré la productivité, ou économisé de l'argent. Ce sont des résultats possibles à enquêter, pas des résultats à attacher à une démonstration.

Le portfolio pourrait montrer le résumé d'observation anonymisé, une décision de conception annotée, le prototype fonctionnel, et le plan de test. C'est suffisant pour rendre le raisonnement visible sans télécharger chaque note de réunion.

Séparez un résultat réel d'un résultat prévu.

Un projet auto-initié peut démontrer du jugement. Il ne peut pas fournir des preuves que vous n'avez jamais collectées.

Si votre public est hypothétique, dites-le. Si vous avez interviewé deux personnes, expliquez cette base étroite. Si vous n'avez pas testé le prototype, écrivez « test prévu » plutôt que « solution validée ».

Je distinguerais trois niveaux de preuves dans une étude de cas :

  • Preuves de conception : qu'est-ce qui soutient la réponse que vous avez choisie ?
  • Preuves d'utilisation : que s'est-il passé lorsque les gens ont essayé l'expérience ?
  • Preuves de performance : que s'est-il passé plus tard dans le travail, et quoi d'autre aurait pu l'influencer ?

Vous n'avez peut-être que le premier niveau. C'est un point de départ légitime. Expliquez la prochaine observation dont vous auriez besoin avant de faire une affirmation plus forte.

Pour l'exemple de transfert, un test de prototype réussi pourrait montrer que les participants identifient des propriétaires de décision manquants. Cela laisserait cependant ouverte la question de savoir si le modèle est utilisé lors des transferts réels et si l'équipe réceptrice le trouve utile.

Garder ces limites claires rend le cas plus crédible. Cela donne également à un intervieweur quelque chose de concret à discuter avec vous.

Éditez pour les décisions, pas pour la chronologie du projet.

Une étude de cas n'a pas besoin de raconter tout dans l'ordre où cela s'est produit.

"D'abord j'ai analysé, puis j'ai conçu, puis j'ai développé" indique au lecteur que vous avez suivi un processus. Cela ne leur dit pas ce que le processus vous a aidé à découvrir.

Commencez par la décision qui a changé le projet. Peut-être avez-vous restreint le public, supprimé du contenu, changé le format de livraison, ou découvert que l'activité demandée pratiquait le mauvais comportement.

Ensuite, montrez les preuves derrière cette décision. Incluez un artefact qui facilite l'inspection : un avant-après annoté, un court extrait d'une analyse de tâche, ou une observation de test liée à une révision.

Donnez également à votre contribution une limite claire. Si quelqu'un d'autre a mené la recherche, écrivez-le. Si vous avez conçu la pratique mais n'avez pas géré le déploiement, écrivez-le. La collaboration a sa place dans une étude de cas crédible.

L'utilisation de l'IA nécessite la même clarté. Expliquez ce qu'elle a aidé à produire, comment vous avez examiné la sortie, et une décision matérielle que vous avez prise concernant son utilisation ou son rejet. Une liste d'outils explique la pile ; elle n'explique pas votre contribution.

Auditez un échantillon avant d'en ajouter un autre.

Ouvrez votre échantillon de portfolio le plus fort et demandez-vous si quelqu'un qui n'est pas familier avec le projet peut répondre à ces questions :

  1. Quel problème spécifique tentiez-vous de résoudre ?
  2. Quelles preuves soutenaient votre interprétation ?
  3. Quel choix de conception nécessitait un jugement ?
  4. Qu'avez-vous testé, observé ou prévu de tester ?
  5. Qu'est-ce qui reste incertain ?

Si les réponses manquent, améliorez le cas avant de créer un autre échantillon. Un deuxième artefact poli ne réparera pas une affirmation non soutenue dans le premier.

Gardez l'expérience en direct facile d'accès et l'explication facile à parcourir. Montrez suffisamment de raisonnement pour qu'un lecteur comprenne le travail, puis laissez-le explorer l'échantillon.

Pour moi, c'est le standard à viser : un portfolio qui permet à quelqu'un d'examiner comment vous pensez et comment vous vérifiez votre pensée.

Donnez au lecteur des preuves qu'il peut suivre, pas seulement un résultat qu'il doit admirer.

Lectures connexes

Un scénario n'est aussi bon que la décision qu'il pratiqueUtilisez une décision pratique concrète pour rendre le raisonnement derrière un échantillon de portfolio visible.

Learning Rewired Lab™

Construisez un cas défendable avant d'écrire l'étude de cas.

Le Lab est l'espace de travail professionnel complet pour transformer une demande d'apprentissage en une solution de performance défendable. Remettez en question la demande, examinez le système, concevez la réponse et planifiez les preuves dans un projet connecté.

Remettez en question la demande, examinez le système et concevez pour la performance avant que la production ne commence.

À l'intérieur du Lab
  • Un enregistrement de projet connecté
  • Demande et diagnostic de performance
  • Outils d'apprentissage orientés produit
  • Flux de travail de conception assistés par IA
  • Application pratique en milieu de travail