![\"ux](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/ux-metrics-illustration-small.jpg\")
<\/p>\n<\/p>\n
Ich freue mich, dass ich heute meinen allerersten Blogbeitrag mit euch teilen darf. Wie sind wir hier gelandet?<\/p>\n
Ich habe vor kurzem bei Centigrade angefangen und (mit dem Risiko, dass das hier nach einem Werbeartikel klingt) ich kann wirklich sagen, dass es eine gro\u00dfartige Erfahrung war. Wir Mitarbeiter werden nicht nur wie “ Human Resources“ behandelt, sondern wie echte Menschen. Man hat mir Selbst\u00e4ndigkeit, Verantwortung und vor allem Vertrauen geschenkt. Ich muss sagen, das ist wirklich ein tolles Gef\u00fchl! Anstatt mich als neue Mitarbeiterin mit einer Million Projekten zu \u00fcberh\u00e4ufen, wurde ich in ein einziges eingearbeitet, und hatte die M\u00f6glichkeit, ein Thema meiner Wahl zu recherchieren und diesen Blogbeitrag dar\u00fcber zu schreiben. UX-Metriken haben mich schon immer interessiert, vor allem die Frage, wie man sie mit geringem Aufwand integrieren kann, um mehr Stakeholder zum Mitmachen zu bewegen, daher fiel mir die Wahl relativ leicht. Also, los geht’s!<\/p>\n
Fangen wir mit einer Definition an. Mir gef\u00e4llt diese hier:<\/p>\n
„UX-Metriken sind eine Reihe quantitativer Daten, die verwendet werden, um das Benutzererlebnis zu messen, zu vergleichen und das Nutzererlebnis im Laufe der Zeit zu verbessern.“ [1]<\/strong><\/p>\n Was f\u00fcr mich hier heraussticht, ist der Teil „im Laufe der Zeit“. Das hei\u00dft, der allererste Schritt ist eigentlich, in eine kontinuierliche Nutzerforschung zu investieren, sowohl manuell als auch automatisiert, um wirklich brauchbare Daten zu bekommen. Das w\u00e4re also der erste wichtige Schritt. Aber keine Angst, wir schauen uns auch an, wie wir mit minimalem Aufwand und ohne bereits etablierte kontinuierliche Nutzerforschung, UX Metriken etablieren k\u00f6nnen. Schauen wir uns weiter an, warum ich denke, dass UX Metriken ein wichtiges Werkzeug f\u00fcr jeden UX Experten sind.<\/p>\n Qualitative Nutzerforschung ist gro\u00dfartig, um unsere Nutzer besser zu verstehen, Ideen zu generieren, Problembereiche zu navigieren und L\u00f6sungen zu erstellen. Kurz gesagt, qualitative Daten beantworten die Frage nach dem Warum? Aber wie k\u00f6nnen wir messen, wie gravierend ein von uns entdecktes Usability-Problem wirklich ist? Ist es uns gelungen, unser digitales Produkt im Laufe der Zeit zu verbessern? Wie w\u00e4hlen wir den besten aus unterschiedlichen L\u00f6sungsans\u00e4tzen aus? Hier kommen quantitative Daten ins Spiel, die die Fragen „Wie viele?“, „Wie oft?“ und „Wie viel?“ beantworten.<\/p>\n Du hast also User Research studiert oder arbeitest mit engagierten User Researchern zusammen, die einige Jahre Erfahrung gesammelt haben, sich der kognitiver Verzerrungen bewusst sind und wissen, wie man sie vermeidet (siehe den Artikel<\/a> meiner Kollegin). Du hast wissenschaftlich solide Studien durchgef\u00fchrt und dann gemeinsam fundierte Ergebnisse und L\u00f6sungen erarbeitet, sie ansprechend zusammengefasst und dein Storytelling perfektioniert, so dass du deine Erkenntnisse interaktiv und \u00fcberzeugend pr\u00e4sentieren kannst. Dennoch bekommt das Konzept keine Zustimmung bei den Stakeholdern? Da bist du nicht allein! Es kann wirklich schwierig sein, die Zustimmung der Stakeholder allein auf der Grundlage qualitativer Ergebnisse zu erhalten. Sobald wir jedoch die Probleme der Nutzer quantifizieren und damit die Frage „Wie viele?“ beantworten k\u00f6nnen, sprechen wir die Sprache der Stakeholder. F\u00fcr mich, sind Metriken die \u00dcbersetzung der Nutzerforschung in greifbare, vergleichbare Zahlen und dadurch visualisierbar in Diagrammen und Grafiken. Und wer kann schon der \u00dcberzeugungskraft eines gut gelungenen Diagramms widerstehen? Als UX-Experten denken wir immer an unser Publikum, warum also nicht auch im Falle unserer Stakeholder?<\/p>\n Karl Pearson war ein Wissenschaftler der Statistik, der f\u00fcr seine Erkenntnisse weltweit bekannt ist. Das Pearsonsche Gesetz besagt:<\/p>\n „Wenn Leistungen gemessen werden, verbessert sich die Leistung. Wenn die Leistung gemessen und die Ergebnisse berichtet werden, steigt das Niveau der Verbesserung noch schneller.\u201c<\/p>\n Mit anderen Worten: Die Messung der Nutzererfahrung f\u00fchrt nicht nur dazu, dass die Stakeholder mitziehen, sondern auch dazu, dass die Nutzererfahrung tats\u00e4chlich verbessert wird. Wenn du die Stakeholder in deine Metriken mit einbeziehst und ihnen \u00fcber die Trends der Metrik im Laufe der Zeit Bericht erstattest, wird sich die User Experience noch st\u00e4rker verbessern. Da die Verbesserung des Nutzererlebnisses das ultimative Ziel eines jeden User-Experience-Experten ist, gibt es f\u00fcr mich keinen besseren Grund, so bald wie m\u00f6glich mit dem Einsatz von UX-Kennzahlen zu beginnen.<\/p>\n Betrachten wir also, welche Metriken es gibt und wie man am besten mit dem Einsatz von Metriken in Projekten beginnt.<\/p>\n Es gibt zahlreiche unterschiedliche Metriken, auf die ich in diesem Blogbeitrag nicht alle einzeln eingehen werde. Stattdessen werde ich die – meiner Meinung nach – am einfachsten zu erfassenden Metriken vorstellen, mit denen man leicht loslegen kann. Solche Metriken, die keine komplizierten Formeln verwenden, wenig Programmierung oder spezielle Technik erfordern. Wenn du bereits User Research betreibst, vor allem kontinuierlich, sollten die von mir identifizierten Metriken nicht allzu schwierig in deine Arbeitsabl\u00e4ufe zu integrieren sein.<\/p>\n Metriken k\u00f6nnen im Allgemeinen nach ihren verschiedenen Messzielen gruppiert werden. Es gibt unterschiedliche Namenskonventionen, die von verschiedenen Frameworks und Experten verwendet werden, und sie k\u00f6nnen manchmal etwas unterschiedlich gruppiert werden, aber mir gef\u00e4llt diese Zusammenfassung der UX-Messziele: Performanz, Pr\u00e4ferenz, Perzeption [2]<\/strong>.<\/p>\n Um ein besseres und pr\u00e4ziseres Verst\u00e4ndnis der Nutzererfahrung f\u00fcr dein Produkt zu bekommen, ist es immer eine gute Idee, eine Mischung von Metriken aus diesen drei Kategorien zu w\u00e4hlen.<\/p>\n Wie immer in der User Research m\u00fcssen wir kognitive Verzerrungen ber\u00fccksichtigen und zwischen Metriken unterscheiden, die messen, was der User sagt („attitudinal“) und was der User tats\u00e4chlich tut („behavioral“). Es ist immer am besten, eine Mischung aus „attitudinal“ und „behaviroal“ Metriken zu w\u00e4hlen, um akkuratere Resultate zu erhalten.<\/p>\n Es folgt eine Liste der einfachsten Metriken f\u00fcr den Einstieg. Ich habe sie nach ihren Messzielen (Performance, Pr\u00e4ferenz, Perzeption) gruppiert und in „attitudinal“ und „behaviroal“ Metriken unterteilt, damit die Auswahl leichter f\u00e4llt und du dir dein eigenes Metrik-Framework zusammenstellen kannst, mit dem du die User Experience deines Projekts m\u00f6glichst genau messen kannst.<\/p>\n „Behavioral“ Metriken:<\/strong> Task success rate, Task completion time, Task error rate<\/p>\n Diese Messungen sind einfach errechnete Durchschnittswerte der Erfolgsrate, der Bearbeitungszeit oder der Fehlerrate f\u00fcr alle Nutzer. Wenn du keine kontinuierliche Nutzerforschung betreibst oder die Stakeholder den Wert von Nutzertests (noch) nicht verstehen, ist es h\u00e4ufig sinnvoller, die Fehlerrate zu messen, da alle Nutzererfahrungen zu Fehlermeldungen f\u00fchren und einfache Code-Hooks eingesetzt werden k\u00f6nnen, um diese zu z\u00e4hlen. Denk daran, deine Fehlerspanne im Auge zu behalten (die mit einem einfachen Online-Rechner berechnet werden kann).<\/p>\n „Attitudinal“ Metriken:<\/strong> SEQ oder SUS (Erwartung\/Pre-Task und Erfahrung\/Post-Task)<\/p>\n SUS steht f\u00fcr System Usability Scale und ist eine g\u00e4ngige Methode zur Messung der Nutzerwahrnehmung. SEQ ist eine sehr vereinfachte Version der SUS, so dass sie f\u00fcr den Anfang die n\u00e4chstliegende sein k\u00f6nnte. Hier<\/a> ist ein Beispiel daf\u00fcr, wie wir die SEQ in einem Metaverse-Forschungsprojekt eingesetzt haben. Der Trick, um diese Wahrnehmungsmessung in eine Performanzmessung zu verwandeln, besteht darin, sie zweimal zu erfragen. Wenn wir den Nutzer bitten, die Umfrage vor der Erledigung einer Aufgabe und danach erneut auszuf\u00fcllen, kann sie als Performanzmessung verwendet werden. Wenn wir diese Umfrage f\u00fcr mehr als eine Aufgabe ausf\u00fcllen und die Daten der verschiedenen Aufgaben in ein Diagramm eingeben, kann sie sogar eine visuelle Darstellung der zu priorisierenden Themen liefern. Ein Beispiel daf\u00fcr finden wir unten.<\/p>\n Albert, William & Dixon, E. (2003). Is this what you expected? The use of expectation measures in usability testing<\/p><\/div>\n „Behaviroal“ & „Attitudinal“ Metriken:<\/strong> Prototypen, A\/B-Tests oder multivariate Tests<\/p>\n Beim Testen der Nutzerpr\u00e4ferenzen m\u00fcssen wir an den Return on Investment (ROI) denken. Am Anfang der Produktreise gibt es viele offene Fragen, und wir k\u00f6nnen nicht einfach mit einem A\/B-Test von zwei Varianten des Button-Placements beginnen. Das w\u00fcrde bedeuten, dass wir von der Annahme ausgehen, dass die Journey zu diesem Button das ist, was der Nutzer bevorzugt. Daher ist es \u00fcblich, mit einem Prototyp-Test zu beginnen und sich dann zu einem A\/B-Test zur Detailverbesserung vorzuarbeiten. Das folgende Diagramm bietet eine sch\u00f6ne Veranschaulichung, welche Art von Benutzertest in welcher Phase des Projekts angemessen ist, um die Risiken von Annahmen und Ungewissheiten zu reduzieren.<\/p>\n The Fountain Institute: Getting started in User testing and experimentation as Designers Guide (thefountaininstitute.com\/blog\/getting-started-in-testing-and-experimentation-a-designers-guide<\/a>)<\/p><\/div>\n Auch wenn die obige Grafik den Stakeholdern pr\u00e4sentiert wurde und sie aufgrund eines mangelnden Verst\u00e4ndnisses f\u00fcr UX nicht f\u00fcr Benutzertests zu begeistern sind, kann dies vielleicht helfen, die Stakeholder zu \u00fcberzeugen:<\/p>\n Statistisch gesehen kann man 85% der Usability-Probleme mit nur f\u00fcnf Nutzern [3] (oder, je nach Komplexit\u00e4t des Projekts, f\u00fcnf Nutzern pro Persona. Mehr dazu kannst du hier<\/a> nachlesen) feststellen, so dass ein einfacher Prototypentest gar nicht so viel Zeit und M\u00fche kostet, wie deine Stakeholder vielleicht denken. Halten dem Team immer wieder vor Augen: Ein fr\u00fchzeitiges Testen ist billiger, als ein Produkt auf der Grundlage von m\u00f6glicher Weise falschen Annahmen zu entwickeln und erst dann festzustellen, dass es die Probleme der Nutzer nicht l\u00f6st.<\/p>\n \u201eBehavioral\u201c:<\/strong> Fingerklopfen w\u00e4hrend der Erledigung einer Aufgabe<\/p>\n Heutzutage gibt es viele Anwendungen, die die Beobachtung des Nutzerverhaltens erleichtern, auch ohne komplizierte Ger\u00e4te. Ich finde allerdings dieses sehr einfache Methode zur Messung der kognitiven Belastung, die ein Benutzer bei der Erledigung einer Aufgabe erf\u00e4hrt, sehr effizient:<\/p>\n Bitten den Nutzer, w\u00e4hrend der Erledigung einer Aufgabe wiederholt und recht schnell mit dem Finger zu klopfen. Wenn die kognitive Belastung zunimmt, verlangsamt sich die Frequenz des Fingertippens oder h\u00f6rt sogar kurzzeitig auf, w\u00e4hrend sich der Benutzer voll und ganz auf seine Aufgabe konzentrieren muss.<\/p>\n \u201eAttitudinal\u201c:<\/strong> SEQ oder SUS (evtl im Vergleich mit Konkurrenten)<\/p>\n Die Umfragen SEQ und SUS habe ich bereits weiter oben erw\u00e4hnt. Es handelt sich dabei um eine gro\u00dfartige Methode, f\u00fcr die es bereits generelle Leitlinien gibt, wie die Ergebnisse zu interpretieren sind:<\/p>\n Hadi Althas 2018: How to Measure Product Usability with the System Usability Scale (SUS) Score (uxplanet.org\/how-to-measure-product-usability-with-the-system-usability-scale-sus-score<\/a>)<\/p><\/div>\n Diese Kategorien sind f\u00fcr alle Stakeholder sehr leicht zu verstehen, und deshalb k\u00f6nnen wir mit ihnen \u00e4u\u00dferst aussagekr\u00e4ftige Diagramme erstellen.<\/p>\n Und das waren schon alle Metriken. Es sind wirklich nicht viele und diese sind doch relativ einfach zu etablieren.<\/p>\n Wenn du ein Pragmatiker bist, so wie ich, dann fragst du dich jetzt wahrscheinlich: Okay, aber wie k\u00f6nnte ich nun wirklich damit anfangen? Was ist hier der erste Schritt? Mit welcher Metrik fange ich an?<\/p>\n Ich w\u00fcnschte, ich k\u00f6nnte jetzt ein Framework vorstellen, wie z. B. das Google HEART-Framework, das USER-Framework oder irgendein anderes Framework, und dann behaupten, man m\u00fcsse nur diese Metriken eine nach der anderen implementieren, und schon k\u00f6nne man loslegen! Allerdings ist keines dieser Frameworks f\u00fcr s\u00e4mtliche Projekte geeignet. Das HEART-Framework von Google beispielsweise verwendet verschiedene Metriken zur Messung von H<\/strong>appiness, E<\/strong>ngagement, A<\/strong>doption, R<\/strong>etention und T<\/strong>ask-Erfolg, die f\u00fcr Google oder andere B2C-Produkte gut funktionieren. Jedoch sind Adoptions- und Retention-Metriken f\u00fcr B2B-Produkte oft nicht aussagekr\u00e4ftig.<\/p>\n Jared Spool meint dazu:<\/p>\n „Die Theorie, dass eine gro\u00dfe, einheitliche Metrik uns sagen kann, wie gut unsere Produkte und Dienstleistungen sind, ist leider nur ein Traum.\u00a0 <\/strong>Eine solche Metrik gibt es nicht wirklich. <\/strong>Es gibt viele M\u00f6glichkeiten, Erfolg zu messen.“<\/strong><\/p>\n Und ich meine: Man muss sich f\u00fcr jedes Projekt – oder sogar f\u00fcr jeden Anwendungskontext – eigene Metriken zur Erfolgsmessung (und -definition) erarbeiten.<\/p>\n Die Messung von Zielen ist auf verschiedenen Ebenen m\u00f6glich, wie in der unten stehenden Grafik dargestellt. Wenn wir ein Ziel messen das zu allgemein ist, wird es schwieriger zu erkennen, was wir tun k\u00f6nnen, um die Metrik (und die User Experience) zu verbessern. Je pr\u00e4ziser bzw. je tiefer wir in die Ebenen einsteigen k\u00f6nnen, desto genauer k\u00f6nnen wir messen, bewerten und schrittweise optimieren.<\/p>\n Centigrade (Thomas Immich, Britta Karn) 2020: Nutzungsdatenanalyse<\/p><\/div>\n Um die m\u00f6glichen Metriken zu identifizieren, bietet sich der Goals, Signals, Metrics Prozess von Google in Kombination mit unseren Messzielen Performanz, Perception und Pr\u00e4ferenz an.<\/p>\n Angenommen, du beginnst ein neues Projekt, hast eine generative User Research durchgef\u00fchrt und ein oder mehrere Ziele f\u00fcr deine Persona(s) identifiziert, dann hast du bereits den ersten Schritt zur Definition der Metriken f\u00fcr dein Projekt getan. Gl\u00fcckwunsch! Wenn du nun den Goals, Signals, Metrics-Prozess verwendest und mindestens zwei der Metriken Performance, Preference und Perception ausw\u00e4hlst, wobei du darauf achtest, eine Mischung aus Behavioral und Attitudinal Measures zu verwenden, kannst du ganz einfach dein eigenes erstes Set an Metriken erstellen, mit dem du loslegen kannst.<\/p>\n Das h\u00f6rt sich etwas kompliziert an, aber sehen wir uns einmal an, wie Goals Signals Metrics funktioniert und wie diese mit den Metriken Performance, Preference und Perception kombiniert werden kann.<\/p>\n Goals Signals Metrics ist sehr simpel: Zun\u00e4chst legt man die zu messenden Goals fest und identifiziert dann die Signals, die zeigen, dass dieses Ziel erreicht wurde. Andere nennen dies „Objektives“, aber die Kernaussage bleibt dieselbe. Signals k\u00f6nnen mehrere f\u00fcr dasselbe Ziel sein. Ein Beispiel: In der Abbildung unten habe ich das sehr allgemeine Ziel verwendet, dass der Nutzer seine Aufgaben erledigen kann. Hierf\u00fcr kann es mehrere Signale geben. Es k\u00f6nnte sein, dass es eine niedrige Fehlerquote gibt, es k\u00f6nnte aber auch sein, dass die Zeit f\u00fcr die Bearbeitung der Aufgabe niedrig ist. Man muss sich also wirklich sicher sein, wann man welche Signale w\u00e4hlt. Man sollte sich immer fragen, welche Signale tats\u00e4chlich f\u00fcr das Ziel sprechen, das man zu messen versucht, und ob sie im Kontext der User Journey zutreffen. (z. B. Manchmal ist eine lange Verweilzeit bei einer Aufgabe besser, solange die Aufgabe am Ende abgeschlossen ist. Beispielsweise wenn das Ziel darin besteht, dass der Nutzer das Produkt erkundet). Das bedeutet auch, dass es langfristig und zur genaueren Messung sogar besser ist, ein Ziel mit verschiedenen Signalen zu messen (und um sicherzustellen, dass diese sich in die gleiche Richtung bewegen und unsere Daten korrelieren).<\/p>\n Das bedeutet auch, dass es auf lange Sicht und f\u00fcr eine genauere Messung sogar besser ist, ein Ziel mit verschiedenen Signalen zu messen (und sicherzustellen, dass sie denselben Trend zeigen und unsere Daten aufeinander abgestimmt sind). Kurzfristig oder f\u00fcr den Anfang ist es akzeptabel, unser Ziel mit einem einzigen Signal zu messen, solange wir wirklich sicher sein k\u00f6nnen, dass dieses Signal tats\u00e4chlich aussagt, ob unser Ziel erreicht wird.<\/p>\n Auf dem Board weiter unten habe ich dargestellt, wie die Metriken f\u00fcr einige sehr allgemeine und \u00fcbergreifende Ziele aussehen k\u00f6nnten. Nat\u00fcrlich sollte man solche allgemein gehaltene Ziele niemals f\u00fcr das eigentliche Produkt verwenden und stattdessen so spezifisch wie m\u00f6glich sein. Die Wahl der Ziele und der Metriken ist ebenso wichtig wie die Art und Weise, wie sie ermittelt werden.<\/p>\n Schon bei der Entscheidung, welche Metriken gemessen werden sollen, sollten die Stakeholder mit einbezogen werden, damit nicht nur das UX-Team f\u00fcr die Metrik zust\u00e4ndig ist. Alle sollten sich dessen bewusst sein und einverstanden sein, dass es sich um eine sinnvolle Metrik handelt; denn schon hier beginnt der Einsatz der Metrik zur Verbesserung des Stakeholder-Buy-in. Dies ist vergleichbar mit den Akzeptanzkriterien oder der „Definition der Fertigstellung“ in einem agilen Entwicklungskontext.<\/p>\n Nat\u00fcrlich w\u00e4re es keine User-Forschung, wenn es nicht auch Verzerrungen oder Regeln g\u00e4be, die wir im Auge behalten m\u00fcssen. Genauer gesagt: Goodharts law.<\/p>\n Auf UX-Metriken angewandt bedeutet das Goodharts Gesetz, dass wir, sobald wir eine Metrik zur Messung eines bestimmten Verhaltens eingef\u00fchrt haben, so sehr mit dem Versuch besch\u00e4ftigt sind, die Werte zu verbessern, dass wir vergessen, warum wir sie \u00fcberhaupt gew\u00e4hlt haben und ob sie immer noch das misst, was wir messen wollen. Daher ist es wichtig, die Metriken st\u00e4ndig aus verschiedenen Blickwinkeln zu betrachten, verschiedene Metriken zur Messung eines Ziels zu verwenden und die von uns gew\u00e4hlten Metriken zu hinterfragen, insbesondere im Laufe der Zeit.<\/p>\n Ich hoffe, dass euch mein Blogartikel gefallen hat und dass er euch bei der Anwendung von UX-Metriken in euren Projekten genauso helfen wird, wie mir. Zum guten Schluss m\u00f6chte ich nat\u00fcrlich noch allen UX-Experten danken, auf deren Ideen und Erkenntnissen ich zur\u00fcckgreifen konnte, um diesen Artikel zu schreiben. Vielen Dank daf\u00fcr! Eine detaillierte Liste meiner Quellen befindet sich am Ende des Artikels.<\/p>\n \u00dcbrigens: Ich freue mich darauf euch bald wiederzusehen, denn ich werde meine eigenen Vorschl\u00e4ge in meinem aktuellen und in zuk\u00fcnftigen Projekten umsetzen und in einem UX Metrics 2.0 Blogpost dar\u00fcber berichten!<\/p>\n —<\/p>\n [1]<\/a> Ratkliff & Kelakar 2020: https:\/\/www.userzoom.com\/ux-blog\/what-ux-metrics-and-kpis-do-the-experts-use-to-measure-experience\/<\/a><\/p>\n [2]<\/a> Jeff Humble 2022: https:\/\/www.thefountaininstitute.com\/free-masterclass-ux-metrics?utm_source=webinar&utm_medium=talk+slide&utm_campaign=DPE+Fall+2022<\/a><\/p>\n [3]<\/a> Jakob Nielsen 2000: https:\/\/www.nngroup.com\/articles\/why-you-only-need-to-test-with-5-users\/<\/a><\/p>\n The Fountain Institute: Choosing the Right Metrics https:\/\/www.youtube.com\/watch?v=wBxnuk4sIns<\/a><\/p>\n Bill Albert, Tom Tullis 2008: Measuring the User Experience: Collecting, Analyzing, and Presenting UX Metrics<\/p>\n Ben Davison 2019: UX Metrics https:\/\/www.youtube.com\/watch?v=PU5i-Y1m1l4<\/a><\/p>\n1. Qualitativ vs. Quantitativ<\/h3>\n
2. Buy-in<\/h3>\n
3. Pearsons Law<\/h3>\n
Welche UX-Metriken gibt es?<\/h2>\n
\n
Performanz<\/h3>\n
![\"Average](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild5-3.png\")
Pr\u00e4ferenz<\/h3>\n
![\"Progress](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild6-4.png\")
Perception<\/h3>\n
![\"SUS](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild7-4.png\")
Wie fange ich nun wirklich<\/em> an?<\/h2>\n
![\"System](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild8-4.png\")
Goals Signals Metrics kombiniert mit Performance Perception Preference<\/strong><\/h3>\n
![\"Performance](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Bild4-4.png\")
<\/p>\nBuy-in beginnt schon mit der Einf\u00fchrung einer Metrik<\/strong><\/h3>\n
Goodhart’s law<\/strong><\/h3>\n