• Artikel

Mai 2016

Band 31, Nummer 5

Visual Studio – Fördern von Lean UX-Praktiken

Von Karl Melder | Mai 2016

In Visual Studio 2015 hat Microsoft verschiedene neue Debug- und Diagnosefeatures bereitgestellt, die von Andrew Hall im Artikel „Visual Studio – Verbesserungen am Debugging in Visual Studio 2015“ (msdn.com/magazine/mt683794) im MSDN Magazine im März 2016 beschrieben wurden. Für die Features, die erhebliche Änderungen an der Benutzeroberfläche beinhalten, hat Microsoft einen “Lean UX”-Ansatz verwendet, der iterative Experimente mit direktem Benutzerfeedback zum Entwurf nutzte.

Ich möchte Sie über den Vorgang informieren, der zum Entwerfen eines dieser Features – PerfTips – verwendet wurde, und die bewährten Methoden sowie Tipps und Tricks beschreiben, die ich im Lauf der Zeit kennengelernt habe. Das Ziel besteht darin, Ihnen und Ihren Teams das effektive, direkte Integrieren von Kundenfeedback in den Entwicklungsvorgang zu ermöglichen.

Lean UX

Lean UX ist eine Ergänzung der schlanken Entwicklungspraktiken, die in der Branche zu einem Trend geworden sind. Eric Ries definierte „schlank“ als den Vorgang von „Erstellen, Messen und Lernen“ in seinem Buch „Lean Startup“ (Crown Business) aus dem Jahr 2011, in dem er einen Ansatz beschreibt, der als durch „Geschäftshypothesen gesteuertes Experimentieren“ gekennzeichnet ist. Analog dazu ist „Lean UX“ eine Sammlung von Prinzipien und Vorgängen, die sich auf sehr frühe und kontinuierliche Überprüfungen durch Kunden konzentriert. Dabei führen Sie Experimente zum Überprüfen Ihrer Benutzer- und Produktdesignhypothesen in extrem kurzen Zyklen aus. Entwurfsiterationen werden schnell mit einem Schwerpunkt auf dem Lösen echter Benutzerprobleme ausgeführt. Als Referenz können Sie das Buch „Lean UX“ (O’Reilly Media) von Jeff Gothelf aus dem Jahr 2013 heranziehen, in dem er Anleitungen und Arbeitsblätter zur Verfügung stellt, die Teams dabei unterstützen, Klarheit darüber zu erlangen, was sie zu erreichen glauben oder hoffen.

Für das Team, das die Debugbenutzeroberfläche in Visual Studio entwickelt, ist Lean UX ein hochgradig auf Zusammenarbeit ausgelegter Ansatz, bei dem das gesamte Team (einschließlich Programmmanager, UX Researcher, Entwickler und UX-Designer) daran beteiligt war, Ideen zu entwickeln, Hypothesen aufzustellen und die Informationen zu interpretieren, die wir von unseren Kunden hörten und sahen.

Dieser Artikel beschreibt, wie Kundenfeedback vollständig in den Produktentwicklungsvorgang einbezogen werden kann. Es geht darum, schneller aus Fehlern zu lernen. Es geht darum, Feedback zu Ihren Ideen ohne Arbeitsaufwand zu nutzen. Es geht darum, dass nicht nur ein Team aus dem Bereich Entwicklertools diese Vorgehensweise anwendet, sondern dass viele Teams grundlegend ändern, wie Features in einem schlanken Entwicklungsvorgang entworfen werden.

Die Entwurfsherausforderung

Microsoft-Technologie verfügt über eine reichhaltige Quelle von Daten, die Entwicklern ein sinnvolles Verfahren zum Diagnostizieren von Problemen bereitstellen können. In den UX Labs griffen die Benutzer jedoch immer wieder darauf zurück, die Ausführung von Code trotz der Vorteile von Tools wie dem Profiler manuell zu durchlaufen. Die Instrumentierungsdaten bestätigten die geringe Nutzung von Visual Studio Profiler, obwohl die Überzeugung vorherrschte, dass durch dieses Tool die Ermittlung von Leistungsproblemen wesentlich effizienter wäre. Bei einem Tool wie Visual Studio, mit dem ein Benutzer acht oder mehr Stunden am Tag arbeitet, kann es ein schwieriges Unterfangen sein, dem Benutzer das Ändern seiner Arbeitsweise vorzuschlagen. Das Team wollte daher die natürliche Arbeitsweise des Benutzers beim Debuggen von Leistungsproblemen nutzen und eine Umgebungserfahrung bereitstellen.

Wenn ein traditionelles Wasserfallmodell verwendet worden wäre, wären ggf. Fokusgruppen gebildet worden, um frühes Feedback zu erhalten, und es wäre eine ausführliche Spezifikation erstellt worden. Kurz vor dem Abschluss der Codierung wären dann Usability-Tests angesetzt worden. Ein Benutzer hätte Aufgaben erhalten, die sich auf die neuen Features beziehen, und die gefundenen Fehler wären ähnlich wie bei Programmfehlern selektiert worden. Für Visual Studio 2015 wurde ein vollständig anderer Ansatz verwendet.

Die Recherchephase

Anstatt Usability-Tests anzusetzen, sobald Arbeitsergebnisse verfügbar waren, wurden zwei Benutzer jeden Freitag für den Großteil des Produktzyklus eingeplant. Diese Tage wurden informell als „Quick Pulse Fridays“ (Freitage mit schnellem Puls) bezeichnet. Die Benutzer stellten sich für ungefähr zwei Stunden zur Verfügung. Diese Zeit wurde normalerweise auf zwei bis vier Experimente aufgeteilt. Für jedes Experiment wurde eine bestmögliche Schätzung der für die einzelne Aufgabe zu reservierenden Zeit vorgenommen. Jedes dieser Experimente sollte entweder Microsoft dabei unterstützen, die Benutzer und ihre Arbeitsweise kennenzulernen, oder eine Idee auszuprobieren. Entwurfsideen mussten für mindestens drei Wochen positive Ergebnisse erbringen, damit sie nicht verworfen wurden. Ein positives Ergebnis bedeutete, dass Benutzer ernsthaft überzeugt waren, dass sie einen Wert für sie besitzen, die Problemerkennung verbesserten, die Verwendung vereinfachten oder Optimierungen von Schlüsselszenarien darstellten.

Bei der UX-Forschung wird häufig zwischen quantitativer und qualitativer Forschung unterschieden. Dabei nimmt eine Kombination aus Instrumentierung/Analyse und Kundenfeedback eine Leitfunktion bei der Geschäfts- und Produktentwicklung ein. In der frühen qualitativen Forschung bedeutete Feedback die Reaktion der Benutzer auf Ideen. Das Team berücksichtigte nicht nur ihre Aussagen, sondern auch ihre physische Reaktion, den Gesichtsausdruck und den Tonfall. Benutzern wurde außerdem auch eine echte Aufgabe gestellt, etwa das Beheben eines Leistungsprogrammfehlers in einer Anwendung ohne jede Unterstützung des sie beobachtenden Forschungsteams. Das Foto in Abbildung 1 zeigt dies. Man ließ die Benutzer sich abmühen. Das Team fertigte Videoaufzeichnungen für eine spätere Auswertung an und notierte sich Gehörtes und Gesehenes. Durch die Beobachtung der Benutzer konnte das Team ihre Arbeitsweise besser verstehen und nicht angesprochene Anforderungen identifizieren, die der Benutzer ggf. nicht benennt, die jedoch eine erhebliche Verbesserung des Produkts darstellen können.

Eine Forschungssitzung mit einem Benutzer
Abbildung 1: Eine Forschungssitzung mit einem Benutzer

Entscheidend für den Erfolg des Teams war, dass keine Zeit darauf verwendet wurde, Kunden davon zu überzeugen, dass ihnen eine Idee gefällt. Den Benutzern wurde die Idee einfach nur so vorgestellt, wie ihre Verwendung später aussehen würde. Das Team zog sich dann zurück und hörte zu, beobachtete und stellte Fragen, durch die es die Ansichten der Benutzer nachvollziehen konnte. Der Schlüssel zum Erfolg des Teams bestand darin, sich von der ggf. mit positiven Gefühlen verbundenen Idee oder dem Entwurf zu lösen.

Jede Woche wurden andere Teilnehmer eingeladen, um kontinuierlich neue Perspektiven auszuloten. Es gab ein internes Team und einen Zulieferer, der Benutzer rekrutierte, überprüfte und Zeitpläne erstellte. Das Team suchte nicht nach Benutzern, die besonderes Diagnosefachwissen aufwiesen. Laut Rekrutierungsprofil musste es sich einfach nur um aktive Benutzer von Visual Studio handeln. Dies bedeutete, dass jede Woche Benutzer mit unterschiedlichen Kenntnissen, anderem Erfahrungsschatz und verschiedenen Arbeitskontexten an den Tests teilnahmen. Das Team erhielt auf diese Weise die Möglichkeit, jede Woche etwas Neues zu lernen, und es konnte die Übereinstimmungen identifizieren. Das Team konnte außerdem seine Ideen weiterzuentwickeln, um ein breiter gefächertes Publikum anzusprechen.

Ebenso wichtig war es, die Interaktion des Teams mit den Benutzern abzugleichen. Wie eine Frage gestellt wurde, konnte sich dramatisch auf das Ergebnis auswirken und das Gespräch beeinflussen. Das Team gewöhnte sich an, immer offene Fragen zu stellen. Dabei wurden die bohrenden Fragen von den Aussagen oder Aktionen des Benutzers abgeleitet. Wenn ein Benutzer dem Team z. B. mitteilte, dass er etwas nicht mochte, wurde er einfach aufgefordert, mehr darüber zu erzählen. Das Team versuchte, keine Annahmen zu postulieren, und stellte seine Vermutungen und Hypothesen bei jeder sich bietenden Gelegenheit in Frage. Diese Fähigkeiten sind für das UX-Forschungsfeld grundlegend und wurden von allen Mitgliedern des Teams angewendet. Wenn Sie mehr über diese Gesprächsführungstechniken erfahren möchten, empfehle ich das Buch „Lean Customer Development“ (O’Reilly Media) von Cindy Alvarez aus dem Jahr 2014.

Frühe Quick Pulse-Sitzungen und die durch nichts zu erschütternde Arbeitsweise

Zu einem frühen Zeitpunkt im Produktzyklus hatte das Team die Idee, Benutzer bei der Überwachung der Leistung ihres Codes zu unterstützen. Das Team erstellte einen Übungstest und legte ihn den Benutzern von „Quick Pulse Friday“ vor. Selbst nach drei Wochen mit vielen Entwurfsänderungen merkten Benutzer noch an, dass sie nicht sicher seien, für was dieses Feature gut sei und dass sie es wahrscheinlich deaktivieren würden! Es war nicht unbedingt das, was das Team hören wollte. Aber es musste es hören.

Während die Benutzer beim Diagnostizieren von Anwendungsproblemen beobachtet wurden, stellte sich jedoch auch heraus, dass das Team eine Benutzeroberfläche bereitstellen musste, die direkter in die Codenavigations-Benutzeroberfläche integriert war. Zwar waren mehrere Debuggerfenster vorhanden, die zusätzliche Informationen boten. Die Benutzer fanden es jedoch schwierig, mehreren Fenstern gleichzeitig ihre Aufmerksamkeit zu schenken. Das Team beobachtete, dass viele Benutzer den Fokus auf den Code legten und häufig mental die Ausführung des Codes „durchliefen“. Dies mag für Entwickler, die diesen Artikel lesen, selbstverständlich sein. Es war jedoch faszinierend, wie unerschütterlich diese Arbeitsweise trotz der Verfügbarkeit zusätzlicher Tools war, die die Aufgabe effizienter gestalten sollten.

Das Team begann dann, mithilfe von Photoshop Ideen zu präsentieren. Dafür war ein außerordentlich erfahrener Designer erforderlich, der mindestens einen Tag benötigte, um einen Übungstest zu erstellen, der als Grundlage für Feedback verwendet werden konnte. Photoshop eignet sich gut für das Erstellen einer Benutzeroberfläche mit großer Genauigkeit. Das Team stieg dann auf Microsoft PowerPoint und ein Storyboard-Add-In (aka.ms/jz35cp) um, damit jedes Teammitglied schnell Darstellungen seiner Ideen mit mittlerer Genauigkeit erstellen konnte. Diese Storyboards vermittelten den Benutzern einen Eindruck vom möglichen Aussehen des Features. Sie waren jedoch unfertig genug, dass Benutzer erkennen konnten, dass der Entwurf kontinuierlichen Änderungen unterworfen war und ihr Feedback direkte Auswirkungen besaß. Unter dem Strich stellte sich heraus, dass es wesentlich einfacher war, die Arbeit von 30 Minuten zu entsorgen, wenn ein Experiment nicht erfolgreich war. Außerdem konnten Ideen ausprobiert werden, von denen das Team wusste, dass sie in der Praxis nicht funktionieren würden. Das Feedback der Benutzer konnte jedoch die Entwicklung neuer Ideen unterstützen.

Jede Folie in den PowerPoint-Präsentationen stellte eine Benutzeraktion oder eine Antwort des Systems auf diese Aktion dar, damit Feedback zum Benutzerinteraktionsmodell zur Verfügung gestellt werden konnte. Beim Entwerfen der Interaktion wurde ein Cursorsymbol verwendet, das zeigte, wo der Benutzer klicken würde. Dies erwies sich beim Vorstellen von Ideen und Ausarbeiten der Details als sinnvoll. Das Cursorsymbol wurde jedoch entfernt, bevor die Folie Benutzern gezeigt wurde. Auf diese Weise konnte das Team die Benutzer fragen, welche Aktion sie im nächsten Schritt ausführen würden. Der Vorteil dabei ist, dass mögliche Auffindbarkeitsprobleme identifiziert werden konnten. Bezüglich jeder Folie, die eine Antwort des Systems zeigte, fragte das Team außerdem, ob die Benutzer der Meinung waren, Fortschritte zu machen. Auf diese Weise konnte das Team erkennen, ob sein Feedback angemessen war. Diese Feedbacktechnik wird in der UX-Forschung als „Cognitive Walkthrough“ bezeichnet. Sie ermöglicht das Erkennen einiger Probleme in den allerfrühesten Phasen des Entwurfs Ihrer Interaktion und vermittelt schon früh einen Eindruck der möglichen Problembereiche, für die weitere Iterationen und Experimente erforderlich sind, um ein gutes Ergebnis zu erzielen.

Zum Abschätzen der möglichen Auswirkungen einer Idee vertraute das Team darauf, dass Benutzer benennen konnten, wie sie eine Idee in ihrer alltäglichen Arbeitsumgebung verwenden würden und was sie als direkte Vor- bzw. Nachteile ansehen würden. Der Benutzer musste ausführliche und plausible Beispiele anführen, damit das Team darauf vertrauen konnte, dass die Weiterverfolgung einer Idee Sinn machte. Das Team achtete außerdem darauf, ob der Benutzer eine gesteigerte Aufmerksamkeit an den Tag legte, seine Körpersprache expressiver war oder Begeisterung geäußert wurde. Das Team suchte nach Ideen, die Benutzer begeistern und sehr positive Auswirkungen auf ihre Diagnoseerfahrung besitzen würden.

„Toll, das ist fantastisch“!

Das Team musste eine Möglichkeit finden, Leistungsinformationen im Code zu zeigen, die sich nicht auf die Lesbarkeit des Codes auswirken und Benutzern eine Umgebungsdebugerfahrung im Code ermöglichen würden. CodeLens, ein Feature in Visual Studio, mit dem Sie Informationen zum Bearbeitungsverlauf, Programmfehler, Komponententests und Verweise anzeigen können, diente als Inspiration für ein mögliches Interaktionsmodell und den visuellen Entwurf. Das Team experimentierte mit Übungstests für mehrere Ideen und zeigte den Benutzern, wie Leistungswerte innerhalb von Millisekunden angezeigt werden, wenn Entwickler Code durchlaufen (siehe Abbildung 2).

Ein früher Übungstest, der Leistungsdaten in einer Debugsitzung anzeigt
Abbildung 2: Ein früher Übungstest, der Leistungsdaten in einer Debugsitzung anzeigt

Der früheste Hinweis darauf, dass das Team auf dem richtigen Weg war, war ein Teilnehmer (ein Entwicklungsmanager), der beim Durchlaufen der Benutzeroberfläche plötzlich große Begeisterung zeigte. Ich sollte darauf hinweisen, dass ihm nur die angedachte Benutzeroberfläche ohne jegliche Hintergrundinformationen gezeigt wurde. Als ihm bewusst wurde, was er da sah, begann er, detaillierte Fragen zu stellen und wurde sehr lebhaft. Er sagte, dass dies die Lösung eines Problem sei, das sich mit unerfahrenen Entwicklern stellte, die schlechte Codierungsentscheidungen trafen, die dann zu einer schlechten Anwendungsleistung führten. In seinem aktuellen Prozess wurden Leistungsprobleme mithilfe eines arbeitsintensiven Codeüberarbeitungsvorgangs gelöst. Für ihn und sein Team ein hoher Preis. Er war der Meinung, dass dieses Feature seine unerfahrenen Entwickler dabei unterstützen könnte, von Anfang an leistungsfähigen Code zu schreiben. Einer seiner Kommentare war „Kann dieses Feature [PerfTip] Standard [in Visual Studio] sein“? Ein anderer Benutzer merkte Folgendes an, nachdem er den Wert des Features erkannt hatte: „An Visual Studio sind die vielfältigen Funktionen in Codezeilen so bemerkenswert“!

Dieses frühe Feedback inspirierte das Team, dass dieses potenzielle Feature ein Einstiegspunkt für die Diagnosetools sein könnte und einige Auffindbarkeitsprobleme lösen könnte. Das Team stellte die Hypothese auf, dass diese PerfTips als Auslöser für den Benutzer dienen könnten, auch das reichhaltigere Toolset zu verwenden.

Entwerfen der Details

Bis zu diesem Zeitpunkt waren nur Übungstests involviert. In das Schreiben von Code wurde noch keine Zeit investiert. Wenn Ideen vielversprechend waren, wurden in die PowerPoint-Präsentation weitere Details eingebaut, ebenso wie zahlreiche Entwurfsalternativen, mit denen wöchentlich experimentiert werden konnte. Die Grenze dessen, was Übungstests leisten konnten, wurde erreicht, als mehrere Forschungsfragen unbeantwortet blieben:

  • Die Bestätigung, dass der Entwurf für PerfTips beim Debuggen allgemeiner Programmlogikprobleme keine Ablenkung darstellte, sondern beim Behandeln von Leistungsproblemen auffindbar blieb.
  • Das Team wollte, dass Benutzer die Leistungswerte, die seit der letzten Ausführungsunterbrechung erfasst wurden, richtig interpretieren konnten.
  • Die Benutzer hatten vorgeschlagen, dass die Werte nur angezeigt werden, wenn die Leistung schlecht war. Niemand konnte jedoch zuverlässig einen Standardschwellenwert vorschlagen.
  • Es wurde befürchtet, dass der Mehraufwand des Debuggers, der ggf. mehrere Millisekunden betragen kann, den Wert des Features für Benutzer verringern könnte.

Das Team implementierte eine Minimalversion des Features, die unter bestimmten Bedingungen funktionierte. Anschließend wurde eine Anwendung mit Leistungs- und Programmlogikproblemen erstellt, die Benutzer einer Diagnose unterziehen konnten. Die Benutzer wurden gebeten, die jeweilige Ursache des Problems zu identifizieren. Wenn sie dabei nicht erfolgreich waren, konnte das Team den Grund dafür durch das Gehörte und Gesehene ermitteln. Der Entwurf konnte dann geändert und in der folgenden Woche erneut getestet werden. Während dieser Zeit wurde auch eine externe CTP-Version bereitgestellt, die instrumentiert war, und in der der PerfTip mit dem Eigenschaftenfenster verknüpft war, damit Benutzer bei Bedarf auf einfache Weise den Schwellenwert ändern konnten. Das Team zog die folgenden Schlüsse:

  • Die PerfTips waren keine Ablenkung, wenn Benutzer Programmlogikprobleme behoben. Die PerfTips mussten durch eine fast unmerkliche Animation optimiert werden, damit sie besser ins Auge stachen, wenn Benutzer an Leistungsproblemen arbeiteten.
  • Durch einige einfache Änderungen an den Formulierungen (z. B. Hinzufügen des Worts „verstrichen“) konnte die Verwirrung vermieden werden, die einige Benutzer beim Interpretieren der Zeiterfassungsdaten befiel.
  • Schwellenwerte führten nur zur Verwirrung von Benutzern, wenn sie nicht konsistent angezeigt wurden und ein einfacher Wert, der in den meisten Fällen zutreffend war, nicht identifiziert werden konnte. Einige Benutzer behaupteten, dass sie ihren Code selbst am besten kennen und daher auch am besten beurteilen könnten, welche Leistungswerte angestrebt werden sollten.
  • Den Benutzern war bewusst, dass diese Werte aufgrund des Debuggermehraufwands nicht genau sein würden. Sie betonten jedoch immer wieder, dass dies in Ordnung sei, weil das Bruttodelta angezeigt wird.

Nach mehreren Wochen mit zahlreichen Iterationen waren die Ergebnisse durchgehend positiv, wenn das Team Benutzer aufforderte, die Quelle von Leistungsproblemen zu identifizieren. Ohne zu einer Beurteilung aufgefordert worden zu sein, war das Feedback von Benutzern enthusiastisch. Es fielen Kommentare wie „Fabelhaft“ oder „Toll, das ist fantastisch“.

Aufzeichnen von Notizen

Beim Aufzeichnen von Notizen musste das Team lernen, Schlüsse erst nach Beendigung der Sitzung zu ziehen, wenn es sich zusammensetzen und das Geschehene diskutieren konnte. Es stellte sich als sinnvoller heraus, Rohnotizen in Echtzeit aufzuzeichnen, und wortwörtlich alle Benutzeraussagen sowie die Aktionen der Benutzer zu notieren. Grammatik und Rechtschreibung waren dabei Nebensache. Diese Notizen dienten dem Team als Referenz beim Aufarbeiten des Geschehenen und zum Gewinnen von Einblicken in die Muster, die sich im Verlauf mehrerer Wochen herauskristallisierten.

Microsoft OneNote stellte sich als sehr praktisches Tool zum Aufzeichnen der Testpläne des Teams, Erfassen von Rohnotizen und Entwerfen schneller Zusammenfassungen heraus. Es wurde immer eine Person bestimmt, die die Notizen zum Gehörten und Gesehenen aufzeichnete. Auf diese Weise erhielten die anderen Teammitglieder den Freiraum, sich ausschließlich auf den Benutzer zu konzentrieren. Die Livesitzungen konnte das gesamte Team auch dann über Skype verfolgen, wenn eine persönliche Teilnahme nicht möglich war. Alle Mitglieder des Teams waren eingeladen, zuzuschauen und zu lernen. Außerdem wurden die Sitzungen für Teammitglieder aufgezeichnet, die andere Termine hatten und sich die Aufzeichnung zu einem späteren Zeitpunkt anschauen wollten. Die Videoaufzeichnungen ermöglichten dem Team auch, sich nachträglich Aspekten zu widmen, die besondere Aufmerksamkeit erforderten. Die Teamdiskussion über die Ergebnisse jeder Woche informierte darüber, was in der Folgewoche anstand und in welchen Fällen das Erstellen eines formalen Berichts nicht erforderlich war und nur Zeit gekostet hätte.

Zusammenfassung

Der Entwurf und die Entwicklung der PerfTips war nur ein kleiner Ausschnitt der wöchentlichen Experimente. Viele Ideen wurden jede Woche in bis zu vier Experimenten pro Benutzer ausprobiert. Die Überarbeitung der Haltepunkteinstellungen ist ein weiteres Beispiel für die Experimente, die von Woche zu Woche ausgeführt wurden, um sich langsam dem Ziel zu nähern, eine sinnvollere und besser zu verwendende Benutzeroberfläche bereitzustellen. Durch Anwenden von Lean UX konnte das Team das Risiko verringern und sich von dem während der Experimente Gehörten und Gesehenen inspirieren lassen. Durch diese Experimente entfiel das Rätselraten beim Entwerfen der Features. Ideen ergaben sich aus zahlreichen Quellen, und das Team ließ sich durch die Beobachtung der natürlichen Arbeitsweise von Entwicklern inspirieren.

Wenn Benutzer den Wert einer Idee nicht erkennen konnten, war es durch die geringen Kosten für die Erstellung eines Übungstests einfach, diese Idee wieder zu verwerfen. Außerdem beflügelten Fehler neue Ideen. Ich hoffe, dass die Beispiele und Tipps für Lean UX Sie anregen werden, dieses Verfahren auszuprobieren. Die „Lean”-Bücherserie, auf die ich in diesem Artikel verweise, kann Ihnen dabei gut als Richtlinie und Framework dienen, wenn Sie diesen Ansatz übernehmen möchten.

Nehmen Sie am Programm teil

Das Microsoft UX-Forschungsteam sucht nach allen möglichen Entwicklertypen, die direktes Feedback liefern oder an diesem noch laufenden Experiment teilnehmen möchten. Wenn Sie sich registrieren möchten, geben Sie unter aka.ms/VSUxResearch bitte einige Fakten zu Ihrem technischen Hintergrund und Ihrer Erreichbarkeit an.

Mein besonderer Dank gilt all den Menschen, die auf irgendeine Weise an diesem Projekt beteiligt waren. Die „Quick Pulse Fridays“ können nur als „zum Bersten voll“ beschrieben werden. Das Team konnte beobachten, lernen und angestrengt nachdenken, wie eine gut durchdachte und sinnvolle Ergänzung zu Visual Studio bereitgestellt werden kann. Besonderer Dank geht an Dan Taylor, der dem Entwicklungsteam immer einige Schritte voraus sein musste und die technologischen Herausforderungen souverän gemeistert hat. Andrew Hall hat mit seinen umfassenden technischen Kenntnissen und seiner pragmatischen Herangehensweise maßgeblich zu den Fortschritten des Teams beigetragen. Frank Wu sprühte nur so vor Entwurfsideen und besaß die fast schon unheimliche Fähigkeit, Ideen zu konzentrieren und auf einfache Weise umzusetzen.

Karl Melderist Senior UX Researcher und entwirft mithilfe seiner Kenntnisse und Erfahrungen in der UX-Forschung, in Computerwissenschaften, mit Benutzeroberflächen und mit menschlichen Faktoren Benutzeroberflächen. Seit mehr als 15 Jahren widmet er sich der Optimierung der Entwicklungsbenutzeroberfläche in Visual Studio für eine breite Palette von Kunden.

Unser Dank gilt den folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Andrew Hall, Dan Taylor und Frank Wu
Andrew Hall ist ein Senior Program Manager im Visual Studio-Debuggerteam. Nach seinem Collegeabschluss schrieb er Branchenanwendungen, bevor er an die Universität zurückkehrte und einen Masterstudiengang in Computerwissenschaften absolvierte. Nachdem er seinen Masterstudiengang erfolgreich beendet hatte, wurde er Mitglied des Diagnosetoolsteams in Visual Studio. Während seiner Zeit bei Microsoft hat er an den Debugger-, Profiler- und Codeanalysetools in Visual Studio gearbeitet.

Dan Taylor ist Programmmanager im Visual Studio-Diagnoseteam und hat während der vergangenen zwei Jahre an Profiling- und Diagnosetools gearbeitet. Bevor er zum Visual Studio-Diagnoseteam stieß, war Taylor ein Programmmanager im .NET Framework-Team und an zahlreichen Leistungsoptimierungen für .NET Framework und die CLR beteiligt.

Frank Wu ist Senior User Experience Designer und beschäftigt sich zurzeit mit dem Entwerfen und Bereitstellen der besten Bearbeitungs- und Diagnosebenutzeroberfläche für alle Entwickler. Er hat während der letzten 10 Jahre an Sicherheitssoftware, Windows Server-Produkten und Entwicklertools gearbeitet, nachdem er seinen Masterstudiengang in HCI erfolgreich abgeschlossen hatte.