UX Crash Course: exécuter des critiques

Une critique est une invitation pour les autres ayant des perspectives différentes pour aider à souligner ce qui fonctionne et ce qui ne fonctionne pas avec un design. C’est différent d’un terrain.
Dans le Fondations de conception pour les développeurs Ebook gratuitnous discutons du processus de présentation de votre travail aux clients et de la façon dont vous pouvez tirer le meilleur parti de cette expérience. Étant donné que le tangage implique souvent (à un petit niveau) une critique du travail, il est probablement préférable de prendre du recul et de parler de la façon dont un terrain et une critique peuvent être différents – et où ils se chevauchent parfois.
Pitching vs critique
Le premier et principal endroit dans lequel le tangage et la critique diffèrent est l’objectif final de la session. Un terrain est destiné à obtenir l’approbation des parties prenantes et de l’officiel «allez-y» sur ce que vous avez créé. Parfois, dans le cadre de cela, les parties prenantes offriront des opinions sur ce qu’elles pensent être modifiées – et ces suggestions peuvent devoir être mises en œuvre avant d’être disposées à aller de l’avant avec les prochaines étapes du projet.
Une critique, en revanche, n’a que l’objectif final d’entendre différentes perspectives et d’obtenir des commentaires sur le travail. Il n’y a pas de signature officielle sur le travail à la fin d’une critique, pas de ferme «oui» ou «non» – juste (espérons-le) de nouveaux ides sur ce que vous avez créé.
Pour cette raison, une hauteur vise généralement à se concentrer sur le positif. Par exemple, même s’il est bon d’être ouvert aux commentaires lors d’un terrain, je ne mettrais en évidence spécifiquement les pièces du travail dont je ne me sentais pas confiant. Au moment où vous faites du travail sur un terrain, vous devez sentir que c’est la bonne solution – et (idéalement) avoir la recherche d’utilisateurs pour sauvegarder cela.
Contrairement à cela, une critique est une invitation pour les autres avec des perspectives et des expériences de vie différentes pour vous aider à percer des trous dans un design et à trouver des lieux pour l’amélioration. C’est l’occasion de trouver ce qui fonctionne, ainsi que ce qui ne l’est pas. Cela ne veut pas dire qu’une critique devrait être dure, blessante ou insultante – cela ne devrait absolument pas. Cependant, vous n’essayez pas de vendre personne sur l’idée que c’est la bonne réponse. Cela fait plutôt partie du processus de veille faire Finez-vous avec quelque chose dans lequel vous vous sentez suffisamment confiant pour lancer.
Comme vous l’avez probablement déjà deviné à partir de ces descriptions, le tangage et la critique se produisent également dans différentes parties du processus de création de produits. Un terrain se produit à la toute fin du processus de conception; Il s’agit d’une présentation du travail (principalement) terminé, avec une petite pièce à l’itération avant le développement. Une critique peut (et devrait!) À tout moment du processus de conception et ne nécessite pas de travail terminé.
Donc, pour résumer:
Pas | Critique | |
---|---|---|
But | Approbation | Commentaires / exploration |
Se concentrer | Pisitifs / points de vente | Faiblesses / améliorations possibles / trouver ce qui fonctionne par rapport |
Quand | Processus de fin de conception | N’importe où dans le processus de conception |
Nécessite un travail fini | Oui | Non |
Cadres de critique populaires
Bien que vous puissiez, bien sûr, ouvrir votre travail pour critiquer et utiliser une approche autoguidée ou plus décontractée, certaines personnes (débutants, surtout – les deux leaders et les participants) trouvent utile d’avoir un peu plus de structure. Si cela vous ressemble, envisagez d’utiliser l’un des cadres de critique existants suivants pour façonner et guider la discussion. Tous peuvent vous offrir des commentaires précieux, de sorte que celui que vous atteignez est entièrement à vous – tout comme le type d’informations que vous recherchez.
J’aime, je souhaite, et si?
En utilisant le « j’aime, je souhaite, et si? » (IL / IW / WI) Encourage les répondants à décomposer leurs commentaires dans ces catégories: «J’ai vraiment aimé la fonctionnalité de B. J’aurais aimé pouvoir faire un plus tôt dans le processus. Et si nous avons ajouté un menu Nav pour le mettre en surbrillance plus efficacement? »
IL / IW / WI fonctionne si bien car il encourage les gens à résoudre des problèmes plutôt que de simplement se plaindre. Bien que cela prenne un peu de configuration et de temps pour expliquer, ce n’est pas trop délicat et offre une place précieuse pour les nuances. Après tout, tout le monde peut trouver quelque chose qu’ils aiment (ou n’aiment pas) à propos d’une expérience – c’est la partie facile. Penser à la façon dont ils préfèrent voir quelque chose la fonction est une question plus difficile.
Bien que les informations comme / aversion puissent être quelque peu utiles, c’est aussi infiniment plus Utile pour savoir comment quelqu’un souhaite que quelque chose fonctionne. Qui offre un aperçu de pourquoi Ils n’aimaient pas ça – d’informations, ils n’auraient peut-être même pas pu mettre des mots à If If demandé directement («Je ne sais pas, ça ne se sentait pas bien»). En demandant aux participants d’éviter les déclarations «Je n’aimais pas» et de recentrer ces pensées à «Je souhaite…» et «et si…», vous vous retrouverez avec des commentaires beaucoup plus axés sur l’action.
Rose, bourgeon, épine
Si vous cherchez une approche plus simple pour les débutants pour la critique, «Rose, Bud, Thorn» (RBT) peut être le bon choix pour vous. RBT demande aux répondants de regarder ce qui fonctionne bien (Rose), ce qui a le potentiel d’être génial avec quelques petits ajustements / ajustements (bourgeon) et ce qui était un point de douleur actif (Thorn).
RBT est très accessible et facile à comprendre pour tout le monde. Alors que IL / IW / WI prend parfois un peu d’explication et nécessite quelques exemples, la plupart des gens sont à bord avec RBT à peu près immédiatement. En fait, beaucoup ont utilisé le même cadre non professionnel pour parler des expériences de vie, de leur journée au travail ou à l’école, etc.
Cependant, il est important de souligner (si vous guidez la session) que les épines ne devraient pas simplement être des choses que les participants n’aiment pas – elles devraient être de véritables frustrations ou points de douleur. Par exemple, «Je ne pense pas que le bouton devrait être bleu» n’est pas une épine, mais «il est difficile de revenir à la page d’accueil après avoir rempli le formulaire».
Squack
Squack est un cadre de rétroaction créé par Julie Jensen; Il signifie des suggestions, des questions, des signaux d’utilisateur, des accidents, des problèmes critiques et des félicitations. Bien qu’il ait quelques pièces mobiles de plus que les autres, il est également idéal pour appeler des choses spécifiques, ce qui le rend particulièrement bon pour les séances de critique approfondies avec d’autres conception et professionnels du développement.
Les suggestions sont des commentaires ou des pensées que le critique sait plus subjectives qu’objectifs (ce qui en fait le bon endroit pour ce commentaire «Je ne pense pas que le bouton devrait être bleu» plus tôt). C’est un excellent moyen d’élever des idées tout en reconnaissant qu’ils sont personnels et pas nécessairement basés sur les données.
Les questions sont bonnes pour soulever un problème pour lequel le réviseur pourrait ne pas avoir encore la réponse. Souvent, pendant les séances de critique, nous ressentons le besoin de sauter juste à dire quelque chose – offrir des commentaires utiles d’une manière ou d’une autre. Mais parfois, nous devons en savoir plus avant de pouvoir le faire. Construire dans l’espace pour les questions peut être un rappel utile.
Les signaux des utilisateurs sont l’endroit idéal pour capturer la recherche des utilisateurs ou les résultats des tests d’utilisation. Si vous voyez quelque chose qui ne s’aligne pas sur les informations que vous avez recueillies lors des interviews des utilisateurs, c’est l’endroit idéal pour évoquer cela.
Les accidents sont pour des erreurs évidemment involontaires – et croyez-moi, il y en a toujours un ou deux. Rien ne fera dérailler un terrain officiel plus rapidement qu’une faute de frappe. Les gens se sentent parfois sous-préparés pour offrir des commentaires de conception, ils s’accrocheront donc aux choses qu’ils savoir C’est sûr que ce ne sont pas corrects. C’est idéal pour empêcher cela en attrapant des liens cassés, des erreurs et d’autres erreurs évidentes.
Les problèmes critiques sont des choses qui entraîneront immédiatement des problèmes pour l’utilisateur si elles sont incluses. Cela pourrait être un problème d’accessibilité qui empêche le produit de respecter une certaine norme, un langage que l’équipe juridique doit examiner ou d’autres problèmes cruciaux à résoudre.
Enfin, les félicitations sont (bien sûr) du crédit où le crédit est dû pour les choses qui fonctionnent bien. Dans tous les systèmes de critique, il est important de laisser de la place pour les bonnes choses – pas simplement parce que c’est agréable d’entendre (et c’est le cas), mais aussi parce que nous ne voulons pas changer ou perturber involontairement une partie du produit qui fonctionne bien dans Nos efforts pour réparer les pièces qui ne le font pas.
Pour une plongée plus profonde dans le cadre Squack, consultez le livre de Jensen Squack pour améliorer les commentaires.
Source link