• Article

Mai 2016

Volume 31,numéro 5

Cet article a fait l'objet d'une traduction automatique.

Visual Studio : alimenter les pratiques Lean UX

Par Karl Melder | Mai 2016

Dans Visual Studio 2015, Microsoft a publié plusieurs fonctionnalités nouvelles de débogage et de diagnostics détaillées par Andrew Hall dans le 2016 mars article de MSDN Magazine, « Améliorations de débogage dans Visual Studio 2015 » (msdn.com/magazine/mt683794). Pour les fonctionnalités qui impliquent des modifications importantes à l'expérience utilisateur, Microsoft a adopté une approche « Lean UX » à l'aide des expériences itératifs avec rétroaction directe pour informer la conception.

Je souhaite partager avec vous, le processus qui a été utilisée pour concevoir une de ces fonctionnalités, conseils sur les performances, ainsi que les meilleures pratiques, conseils et astuces récupérés au cours du processus. L'objectif est d'inspirer et permettent aux administrateurs et vos équipes plier efficacement des commentaires directement dans votre processus de développement.

Lean UX

Lean UX est un complément aux pratiques de développement lean tendances de notre secteur. Eric Ries défini lean comme la pratique de « Build, mesures et en savoir plus » dans son livre 2011, « Le Lean démarrage » (couronne entreprise), où il décrit une approche « expérimentation hypothèse métier ». De même, Lean UX est un ensemble de principes et les processus qui se concentre sur la validation client très précoce et en cours, où vous effectuez des expériences pour valider les hypothèses de conception de produit dans les cycles de très courtes. Itérations de conception sont effectuées rapidement l'accent sur la résolution des problèmes des utilisateurs réels. Une bonne référence est le carnet de Jeff Gothelf 2013, « Lean UX » (o ' Reilly Media), où il fournit des conseils et des feuilles de calcul pour aider les équipes donnent plus de clarté à ce qu'ils pensez ou objectifs.

Équipe de la fourniture de l'expérience de débogage dans Visual Studio, Lean UX est une approche hautement collaborative où toute l'équipe, y compris des responsables de programme, les chercheurs de l'expérience utilisateur, les développeurs et concepteurs UX, impliqué pour générer des idées, hypothèses, de création et d'interpréter ce qui a été entendu et vu de nos clients.

Cet article concerne entièrement adoption des commentaires des clients dans le processus de développement de produit. Il s'agit échouent plus rapidement vers l'avant. Son propos mise en route vos commentaires sur vos idées sans tous les bits de travail. Il ne concerne pas seulement une équipe dans la division developer tools de cela, mais un grand nombre d'équipes radicalement la façon dont les fonctionnalités sont conçues dans un processus de développement lean.

Le défi de conception

Technologie Microsoft a une source importante de données qui peuvent offrir aux développeurs un moyen utile pour diagnostiquer les problèmes. Toutefois, dans les laboratoires de l'expérience utilisateur, les utilisateurs à plusieurs reprises reviennent à parcourir manuellement l'exécution du code en dépit de l'avantage fournis des outils tels que le profileur. Le trou de données d'instrumentation à l'utilisation du profileur Visual Studio malgré la conviction qu'il peut établir des performances de recherche de faible émet un processus beaucoup plus efficace. Pour un outil tel que Visual Studio, où un utilisateur passe au moins huit heures de jour, le demander à un utilisateur de modifier sa méthode de travail peut être une entreprise difficile. Par conséquent, l'équipe souhaitait tirent parti de méthode de travail naturel de l'utilisateur lors du débogage des problèmes de performances et offrent une expérience ambiante.

Une approche plus traditionnelle de cascade avait été prise, groupes de discussion peut ont été effectués pour recevoir des commentaires, une spécification détaillée écrite et de codage lors de près de terminer, facilité d'utilisation études auraient été planifiées. Un utilisateur aurait été donné tâches exercé les nouvelles fonctionnalités et triés les problèmes trouvés comme terminée avec des bogues. Pour Visual Studio 2015, une approche très différente a été effectuée.

Le processus de recherche

Au lieu de la planification des études de convivialité lorsque le travail bits étaient disponibles, les deux utilisateurs ont été prédéfinies vendredi pour la majorité du cycle du produit. Ces jours ont été appelés de façon informelle « Vendredi d'impulsion rapide ». Les utilisateurs ont été fournis pour environ deux heures, où leur temps a été divisé en général, les expériences de deux à quatre. Pour chaque étude, une meilleure estimation a été examiné combien de temps doit être dédié. Chaque expérience concernait aider Microsoft à en savoir plus sur les utilisateurs et leur fonctionnement, ou sur essayer une idée. Idées de conception époque, survivaient au moins trois semaines d'obtenir des résultats positifs afin d'avancer avec eux. Un résultat positif destinés aux utilisateurs que soit pensé fortement avait la valeur pour ces, une augmentation de la découverte, rend plus facile à utiliser ou pourrait illustrer les améliorations pour des scénarios clés.

Recherche de l'expérience utilisateur est souvent classé quantitative et qualitative, où une combinaison de commentaires instrumentation/analytics et client guides de développement de produit. Dans les premières phases de recherche qualitative, commentaires signifiait réaction des utilisateurs à vos idées. L'équipe a pris en compte, pas uniquement leur dit, mais leur réaction physique, expressions du visage et ton de voix. Les utilisateurs ont eu une véritable tâche, telles que la résolution d'un bogue de performances dans une application sans l'assistance de l'équipe de recherche comme elles ont été observées, comme illustré à la photo dans Figure 1. Cela signifiait que laisser l'effort déployé aux utilisateurs. L'équipe prendrait vidéo d'entre eux pour une consultation future et prendre des notes sur les deux ce qui a été entendu et vu. Regardez les utilisateurs a permis à l'équipe à comprendre leur façon de travailler et identifier les besoins en non-textuelle un utilisateur ne connaît pas forcément de demander, mais peut fournir une amélioration considérable du produit.

Une Session de recherche avec un utilisateur
Figure 1 une recherche Session avec un utilisateur

Ce qui était essentiel au succès de l'équipe a été sans passer votre temps à essayer de convaincre les clients à avoir une idée. Les utilisateurs ont montré simplement l'idée en termes de ce qu'elle serait similaire. Puis l'équipe en retrait précédent simplement écouté, surveillés et aux questions qui ont permis à l'équipe de comprendre les points de vue de l'utilisateur. La clé du succès de l'équipe a la possibilité de se détacher de l'idée ou conception peut avoir pensé fortement sur.

Chaque semaine participants différents sont recrutés pour un flux constant de nouvelles perspectives. Il était une équipe interne et un fournisseur qui recrutés, filtré et planifié des utilisateurs. L'équipe ne recherchait pas les utilisateurs qui disposent d'une expertise spécifique avec les diagnostics ; au lieu de cela, le profil de recrutement a été simplement les utilisateurs de Visual Studio. Cela signifiait que chaque semaine sont les différentes compétences, expériences et contextes de travail. L'équipe a donné la possibilité d'apprendre quelque chose de nouveau chaque semaine et il permettent d'identifier les éléments cohérents. L'équipe peut également évoluer ses idées pour réussir avec un public plus large.

Tout aussi important a été l'équilibrage de la façon dont l'équipe interagissait avec les utilisateurs. Comment une question a été posée peut considérablement affecter le résultat et biais la conversation. L'équipe a développé l'habitude de toujours poser des questions ouvertes, où les questions d'approfondissement ont été dérivées de l'utilisateur dit ou a. Par exemple, si un utilisateur a dit l'équipe qu'ils n'aime pas quelque chose, ils ont été invités simplement « Nous en dire plus à ce sujet. » L'équipe a tenté de ne pas supposition et un défi ses hypothèses et les hypothèses dès que possible. Ces compétences sont de base pour le champ de l'expérience utilisateur et ont été adoptées par tous les membres de l'équipe. Si vous souhaitez en savoir plus sur ces techniques de l'interrogation, je vous recommande de Cindy Alvarez 2014 livre, « Lean client Development » (o ' Reilly Media).

Premières Sessions rapide-impulsion et la façon de travailler Unshakeable

Très tôt dans le cycle de produit, l'équipe de se familiariser avec une idée pour aider les utilisateurs à analyser les performances de leur code. L'équipe créé une maquette et voilà devant les utilisateurs rapide impulsion vendredi. Ce qui a été émis régulièrement, même après trois semaines de modifications de conception, était qu'elles n'étaient pas vraiment ce qu'il était d'et qu'ils « seraient probablement désactiver! » Il n'était pas nécessairement que l'équipe souhaitait entendre, mais il doit écouter.

Toutefois, lors du visionnage également les utilisateurs à diagnostiquer les problèmes d'application, il est devenu évident que l'équipe devait une expérience utilisateur qui a été plus directement partie de l'expérience de navigation de code. Bien qu'il y a plusieurs fenêtres du débogueur qui fournissent des informations supplémentaires, il était difficile pour les utilisateurs à faire attention à plusieurs fenêtres à la fois. L'équipe a observé de nombreux utilisateurs en conservant leur le focus dans le code, souvent mentalement « code de parcours » l'exécution. Cela peut sembler évident à tout développeur de cet article, mais ce que fascinant était unshakable comment cette méthode de travail est malgré la présence d'autres outils sont conçus pour faciliter la tâche.

L'équipe a commencé la préparation des idées à l'aide de Photoshop, où il faudrait un concepteur expérimenté extrêmement une jusqu'à un jour pour générer une simulation qui peut être utilisée pour les commentaires. Photoshop a tendance à se prête à la création d'une interface utilisateur avec haute fidélité. Au lieu de cela, l'équipe démarré à l'aide de Microsoft PowerPoint et un complément de storyboard (aka.ms/jz35cp) que tous les membres de l'équipe permettent de créer rapidement des représentations sous forme de fidélité moyenne de leurs idées. Ces tables de montage séquentiel attribué aux utilisateurs une idée de ce à quoi il peut ressembler, mais ils ont été assez grossière pour les utilisateurs de déterminer qu'il a été une conception en cours d'exécution et que leur entrée a un impact direct. L'effet net est qu'il était beaucoup plus facile de jeter un investissement de 30 minutes lors de l'échec d'une expérience. En outre, vous pouvez tester les idées que l'équipe savait ne fonctionnera pas dans la pratique, mais les commentaires des utilisateurs permet de générer de nouvelles idées.

Pour obtenir des commentaires sur le modèle d'interaction utilisateur, chaque diapositive dans les ponts PowerPoint représenté une action de l'utilisateur ou de réponse du système à cette action. Lors de l'élaboration de l'interaction, une image d'icône de curseur pour montrer où cliquez sur l'utilisateur peuvent être ajoutée. Cela est utile lorsque le partage des idées et de travailler sur ces détails. Toutefois, l'icône du curseur sont supprimée avant de les afficher aux utilisateurs. C'est autorisée à demander aux utilisateurs qu'ils le feraient ensuite, l'équipe offrant ainsi une méthode de remise de l'identification des problèmes de détectabilité possibles. Pour chaque diapositive de réponse du système que l'équipe demanderiez également si les utilisateurs pensé qu'ils ont été sa progression, qui permettent de l'équipe de savoir si elle a été commentaires adéquates. Cette technique de commentaires est appelée un « processus cognitifs procédure pas à pas » dans la recherche de l'expérience utilisateur et peut vous aider à identifier certains problèmes sur les toutes premières phases de la conception de votre interaction, tout en vous donnant un sens anticipée de domaines de préoccupation nécessitant plus expérimentation correctement et itération.

Pour évaluer l'impact potentiel d'une idée, l'équipe reposait sur la capacité de l'utilisateur à définir plus précisément comment il peut utiliser l'idée de son environnement de travail quotidien et qu'il a perçu peut être directes avantages et des inconvénients. L'utilisateur devait fournir des exemples détaillés et plausibles pour l'équipe de devenir sûr que l'idée était conviendra. L'équipe également envisagé pour voir si l'utilisateur a commencé à une attention spéciale, obtenir plus d'attrait animée et express. L'équipe recherchait idées attractives utilisateurs et susceptibles d'avoir un impact très positif sur leur expérience de diagnostic.

« Wow, c'est incroyable! »

L'équipe besoin d'une méthode pour afficher des informations sur les performances dans le code qui n'affecte pas la lisibilité du code et fournit aux utilisateurs une expérience de débogage de code ambiante. Filtre code, une fonctionnalité de Visual Studio qui vous permet d'afficher des informations sur l'édition de l'historique, bogues, des tests unitaires et des références, fournis sur un modèle d'interaction potentielle et la conception visuelle d'inspiration. L'équipe terminé les exercices de maquettes de plusieurs idées montrant comment les clients en tant que développeur parcourt le code, il serait affiche les chiffres de performances en millisecondes (voir Figure 2).

Une maquette anticipée affichant les données de performances dans une Session de débogage
Figure 2 une maquette anticipée affichant les données de performances dans une Session de débogage

L'indication au plus tôt que l'équipe a à quelque chose a été lorsqu'un participant, qui était responsable du développement, vous avez très heureux lorsqu'il a été passé en revue l'expérience. Je dois insister sur qu'il a été simplement a montré l'expérience proposée sans aucune information d'arrière-plan. Comme il se rendit compte qu'il a été voir, il commencent à poser des questions détaillées et vous avez animé tout à fait comme il spoke. Il a dit que ce serait une solution à un problème, qu'il a eu avec ses développeurs novices mauvaises décisions codage qui ont provoqué des performances médiocres des applications. Dans son processus en cours, les problèmes de performances ont été résolus via un processus de révision de code fastidieux, qui était une taxe lourde sur lui et son équipe. Il semble que cette idée pourrait contribuer à ses développeurs novices apprendre à écrire du code de performant pendant qu'ils ont été tout d'abord élaborer leur code. Il y a apporté des commentaires tels que, « ce [conseils sur les performances] stratégie [dans Visual Studio]? » Un autre utilisateur, après avoir pris conscience que sa valeur remarqué, « Visual Studio remarquable fait les fonctionnalités lorsque vous êtes sur une ligne de code! »

Cette commentaires aussi l'équipe motivés par cette fonctionnalité potentielle en cours d'un point d'entrée pour les outils de diagnostic, résolution des problèmes de découverte. L'équipe hypothétique que ces conseils sur les performances peut être un déclencheur pour les utilisateurs à s'aventurer sur notre jeu d'outils plus riche.

Concevez les détails

Tout ce que fait jusqu'à présent impliqué uniquement les données factices : aucun investissement de codage. Si les idées obtenu de traction, au niveau de détails ont été créé dans PowerPoint « clics, » ainsi qu'un grand nombre d'alternatives de conception à faire des essais avec une fréquence hebdomadaire. Toutefois, la limite de ce qui peut être fait avec des données factices a été atteinte lorsque plusieurs problèmes de recherche est restée :

  • Validation que la conception pour des conseils sur les performances lors du débogage de problèmes courants de logique n'était pas une distraction, mais est resté détectable lors du traitement des performances émet.
  • L'équipe souhaitait les utilisateurs à interpréter correctement les chiffres de performances, qui ont été traitées de la dernière pause dans l'exécution.
  • Les utilisateurs avaient suggéré affiche uniquement les valeurs lorsque les performances étaient préoccupant, mais personne peut en toute confiance suggérer un seuil par défaut.
  • Problème risque de diminuer la charge du débogueur, qui peut ajouter plusieurs millisecondes, sa valeur pour les clients s'est produite.

L'équipe a implémenté une version minimale de la fonctionnalité qui fonctionnait sous certaines conditions. Ensuite, une application avec des problèmes de performances et une logique permettant aux utilisateurs de diagnostiquer a été créée. Les utilisateurs ont été invités à identifier la cause spécifique du problème. Si elles n'étaient pas réussites, l'équipe peut déterminer pourquoi les utilisateurs n'ont pas été réussites en ce qui a été entendu et vu. La conception peut être modifiée, puis essayez à nouveau la semaine suivante. En outre, pendant cette période, une version CTP externe a été remise qui a été instrumenté, où les conseils sur les performances était liée à la fenêtre Propriétés pour les utilisateurs pourraient changer facilement le seuil s'ils souhaitent. L'équipe a conclu :

  • Conseils sur les performances n'étaient pas une confusion lorsque les utilisateurs ont été résolution des problèmes de logique. En fait, les conseils sur les performances nécessaires pour être modifiés avec des animations subtiles pour les rendre plus visibles lorsque les utilisateurs ont été traitant de problèmes de performances.
  • Certaines simples modifications de la formulation, telles que l'ajout du mot « écoulé, » libéré tous les utilisateurs de confusion eu sur l'interprétation des données de minutage.
  • Seuils confondu uniquement aux utilisateurs lorsque s'affichait cohérente et une valeur simple qui fonctionne dans la plupart des cas n'a pas pu être identifiée. Certains utilisateurs dit parce qu'ils savaient leur code meilleur, qu'ils seraient le mieux placé pour juger de ce qui serait le temps de performance raisonnable.
  • Les utilisateurs reconnu que les valeurs ne serait pas exactes en raison de la surcharge du débogueur, mais ils dit à plusieurs reprises qu'ils ont été correctement avec lui comme ils seraient regarder différences bruts.

En général, sur plusieurs semaines d'itérations, l'équipe obtenu des résultats positifs lorsque les tâches des utilisateurs pour identifier la source des problèmes de performances. Sans intervention, commentaires enthousiaste avec commentaires, par exemple, « Formidable » a également donné aux utilisateurs et, « Oui, c'est incroyable! »

Prise de Notes

Lorsque vous prenez des notes, l'équipe appris à éviter de placer toutes les conclusions que jusqu'à ce que la session lorsqu'il fut temps à s'asseoir ensemble pour décrire ce qui est arrivé. Quel était le plus utile était de prendre des notes très brutes en temps réel, une tentative d'écriture vers le bas textuellement tout ce dont les utilisateurs dit et ce qu'ils font. L'orthographe et grammaire était pas. Ces notes de publication est devenu la référence de l'équipe lors de l'actualisation de lui-même sur l'évolution et de laisser dessiner insights parmi les modèles qui ont été vu sur plusieurs semaines.

Microsoft OneNote est devenu un outil très pratique pour effectuer le suivi de l'équipe qui a été planification à tester, capturer des notes brutes et créer un brouillon de résumés. Il y a toujours été un désigné des notes qui a capturé ce qui a été entendu et vu. Cela a donné l'autres membres respiration salle à complètement le focus sur l'utilisateur. Pour ceux qui ne peut pas participer, les sessions en direct sont partagées avec l'équipe à l'aide de Skype ; tous les membres de l'équipe a été invité à regarder et en savoir plus. En outre, les sessions ont été enregistrées pour les membres de l'équipe qui avaient des conflits de réunion et souhaitez regarder plus tard. Les enregistrements vidéo permettent également de l'équipe de consulter les domaines nécessitant une attention particulière. La discussion d'équipe sur les résultats de chaque semaine informé de la semaine suivante, où écrire un rapport formel n'était pas nécessaire et aurait simplement ralentissent tout ce qui serait être fait.

Synthèse

La conception et le développement des conseils sur les performances a été uniquement une section de ce qui a été fait dans les expériences hebdomadaire. Idées ont été étudiées, les expériences de quatre par utilisateur, chaque semaine. La redéfinition des paramètres de point d'arrêt est un autre exemple d'expériences qui ont été exécutés semaine à l'autre pour effectuer une itération à la fourniture d'une expérience plus utile et pratique. En appliquant Lean UX, l'équipe a pu réduire les risques, lors de la recherche à partir de ce qui a été entendu et observé pendant les expériences d'inspiration. Ces expériences a pris le hasard lors de la conception de fonctionnalités. Idées provenant de nombreuses sources et ont été inspirées par regarder comment les développeurs fonctionnait naturellement.

Si les utilisateurs n'a pas pu afficher la valeur dans une idée, le coût pour créer une maquette faible facilité recommencer. En outre, les défaillances suscitent nouvelles idées. J'espère que les exemples et conseils pour Lean UX vous incitera à l'essayer. La série « Lean » de la documentation référencée dans cet article vous sera ainsi qu'un repère et un cadre pour adopter cette approche.

Participer au programme

L'équipe de recherche Microsoft UX recherche tous les types de développeurs de commentaires directs, ainsi que de participer à cette expérience en cours. Pour vous inscrire, inclure un peu plus sur votre formation technique et comment mieux vous contacter aka.ms/VSUxResearch.

Je souhaite remercier à toutes les personnes qui ont participé à une manière ou d'une autre avec ce projet. Vous pouvez décrire uniquement les vendredis impulsion rapide comme « surchargée » avec l'équipe de surveillance, de formation et très réfléchir sur la fourniture d'un ajout bien pensée et réfléchie à Visual Studio. Remerciements doivent passer à Dan Taylor qui devait Restez à l'équipe de développement et qui cible les défis technologiques avec aplomb. Andrew Hall conservé l'équipe vers l'avant avec son des connaissances techniques et une approche pragmatique. Frank Wu conservé les idées de conception entrant et PRÉDISPOSITION capable d'une idée se résument et trouver un moyen de simplicité.

Karl Melderest chercheur senior expérience utilisateur qui a appliqué régulièrement sa formation et l'expérience de recherche de l'expérience utilisateur, informatique, l'interface utilisateur et les facteurs humains conception UXes. Pour les dernières 15-plus années il a travaillé pour améliorer le développement d'expérience dans Visual Studio pour un large éventail de clients.

Remercie les experts techniques Microsoft suivants pour avoir relu cet article : Andrew Hall, Dan Taylor et Frank Wu
Andrew Hall est responsable de programme senior au sein de l'équipe du débogueur Visual Studio. Après la promotion de l'université, il a écrit des applications métier avant de retourner à l'établissement de cette maîtrise en informatique. À l'issue de sa maîtrise, il a rejoint l'équipe des outils de diagnostic dans Visual Studio. Pendant son temps chez Microsoft, il a travaillé sur le débogueur, du Générateur de profils et les outils d'analyse de code dans Visual Studio.

Dan Taylor est responsable de programme dans l'équipe Diagnostics de Visual Studio et a travaillé sur les outils de profilage et de diagnostics pour les deux dernières années. Avant de rejoindre l'équipe Diagnostics de Visual Studio, Taylor était responsable de programme dans l'équipe .NET Framework et a contribué à nombreuses améliorations des performances pour le .NET Framework et le CLR.

Frank Wu est le Concepteur d'expérience utilisateur senior actuellement en mettant l'accent sur la conception et de fournir la meilleure modification et diagnostics expérience pour tous les développeurs. Il a travaillé sur les logiciels de sécurité, les produits Windows Server et les outils de développement pour les 10 dernières années après avoir obtenu sa maîtrise de HCL.