Dark Mode: Warum Websites das neue Feature unterstützen sollten

Der Dark Mode für digitale Interfaces ist ein ziemlich heißes Thema. Erst kürzlich stellte Microsoft Office seine Suite auf Dark Mode Kompatibilität um. Sogar ein eigener Trailer wurde dafür produziert. Mit den neuen Betriebssystem iOS und iPad OS Versionen von Apple hält der Dark Mode auch Einzug auf die mobilen Endgeräte der Apple Nutzer. Android kann dies bereits etwas länger. Der Verbreitung des Features wird es jedoch neuen Schub verleihen.

Durch die größere Verbreitung wird es Zeit über die Anpassung der eigenen Website und Webapps nachzudenken.

Website Nutzer im Dark Modus nicht mit Licht fluten

Aus eigener Erfahrung kann ich sagen, wie schnell man sich an den Dark Mode beim Mac OS gewöhnen kann. Ich selbst nutze One Switch – Fireball Studio als App, die den Dark Mode mit Sonnenuntergang aktiviert. So ist das Arbeiten in lichtärmeren Umgebungen für die Augen angenehmer.

Viele native Programme wie Mail, Kalender und auch Code Editoren unterstützen den Dark Mode bereits komplett. Im Web sieht das Bild jedoch anders aus. Sobald man in den Browser wechselt, werden Nutzer relativ schnell wieder mit hellen Sites geflutet. Das Erlebnis kann dann schnell anstrengend werden. Es gibt bereits einige Browser Plugins, die versuchen für alle Websites einen Dark Mode zu generieren. Jedoch haben Unternehmen hier keinen Einfluss auf die Farbgestaltungen und das Corporate Design. Besser wäre es daher von Haus aus, die Unterstützung des Dark Modes einzubauen, um die volle Kontrolle der Darstellung zu haben.

Aktuelle Browser Versionen wie Chrome, Safari und Firefox unterstützen den Dark Mode bereits und können auch an Websites, die Info zum Licht abschalten weitergeben. Jedoch muss der Support auch innerhalb der Website implementiert sein.

Wir haben mit PHMU.de den Dark Mode implementiert und erhoffen uns so ein angenehmeres Surfen bei Nutzern und die Schonung der Augen.

Wie du Tailwind CSS im Vue.js-Projekt nutzen kannst

Du hast erfolgreich ein Vue-Projekt gestartet (wie das geht haben wir hier aufgeschrieben) und möchtest nun TailwindCSS als Utility-Framework zur Entwicklung nutzen? Dann zeigen wir dir im folgenden Beitrag, wie du das relativ einfach hin bekommst.

Zuerst musst du die notwendigen Packages installieren:

npm install tailwindcss autoprefixer
-- ODER --
yarn add tailwindcss autoprefixer

Dann kannst du mit dem folgenden Command das tailwindcss.config.js file in deinem Projekt erstellen:

npx tailwind init

Ist das erledigt, kannst du unter assets einen neuen Ordner /css erstellen und dort die Datei tailwind.css anlegen. Hier fügst du folgende Imports hinzu:

@tailwind base;
@tailwind components;
@tailwind utilities;

Nun müssen wir der Vue-App mitteilen, dass die CSS-Styles genutzt werden sollen. Dafür importieren wir unsere neue tailwind.css in die App.vue.

import Vue from 'vue';
import App from './App.vue';

import './assets/styles/tailwind.css';

Im letzten Schritt passen wir unser postcss.config.js an. So geben wir an, dass wir beide Plugins nutzen wollen.

module.exports = {
  plugins: [
    require('tailwindcss'),
    require('autoprefixer'),
  ]
}

Ist das erledigt, können wir prüfen, ob alles funktioniert. Füge am besten eine Tailwind-CSS-Klasse wie bg-red-500 einem div in App.vue hinzu und schaue ob du die Änderung nach dem Livereload siehst. Passt alles? Perfekt, dann hast du erfolgreich TailwindCSS zu deinem Projekt hinzugefügt.

Bundle-Größe optimieren

Tailwind vergrößert dein CSS immens. Wenn du also nun npm run build ausführst solltest du die Veränderung sehen. Über 679 KiB ist das CSS nun groß. Das bekommen wir jedoch relativ einfach reduziert.

File                                      Size             Gzipped

dist/js/chunk-vendors.9080b304.js         119.90 KiB       41.68 KiB
dist/js/app.d8b6098b.js                   7.19 KiB         2.58 KiB
dist/service-worker.js                    0.96 KiB         0.54 KiB
dist/js/about.edf670de.js                 0.44 KiB         0.31 KiB
dist/css/app.6504396d.css                 679.39 KiB       85.10 KiB

Um nicht genutzte Tailwind-CSS-Klassen aus deinem Bundle zu entfernen, nutzen wir PurgeCSS in Verbindung mit PostCSS. Dazu füge zuerst das notwendige Package dem Projekt hinzu:

npm install purgecss  @fullhuman/postcss-purgecss

Ist die Installation abgeschlossen, müssen wir in der PostCSS Config folgende Änderung vornehmen:

const purgecss = require(“@fullhuman/postcss-purgecss”);

module.exports = {
    plugins: [
      require(‘tailwindcss’),
      require(‘autoprefixer’),

    // Only add purgecss in production
    process.env.NODE_ENV === 'production'
      ? purgecss({
          content: ['./src/**/*.html', './src/**/*.vue'],
        })
      : '',
  ],
}

Wenn wir nun npm run build erneut starten, sollten wir bereits drastische Verbesserungen bei der CSS-Datei erkennen.

File                                      Size             Gzipped

dist/js/chunk-vendors.9080b304.js         119.90 KiB       41.68 KiB
dist/js/app.d8b6098b.js                   7.19 KiB         2.58 KiB
dist/service-worker.js                    0.96 KiB         0.55 KiB
dist/js/about.edf670de.js                 0.44 KiB         0.31 KiB
dist/css/app.69044861.css                 2.14 KiB         0.81 KiB

2.14 KiB damit lässt sich starten!

Links:

Setup eines VueJS Projektes mit der Vue CLI

Um ein neues VueJS Projekt zu starten gibt es verschiedene Wege. Der einfachste und angenehmste Weg ist das Setup mithilfe der Vue CLI. Um die CLI nutzen zu können, müssen zuerst die notwendigen NPM Module global installiert werden. Dazu kann folgender Command im Terminal ausgeführt werden:

npm install -g @vue/cli

#oder 

yarn global add @vue/cli 

Läuft die Installation erfolgreich durch, steht danach ein neuer Command im Terminal zur Verfügung. Mit vue -v lässt sich beispielsweise prüfen, welchen Version der Vue CLI nun installiert ist.

Das Projekt Setup über die CLI

Um ein Projektsetup zu starten kann man nun mithilfe von vue create + den gewünschten Projektname den Setup-Prozess über das Terminal starten.

vue create vue-setup

Nach dem Command startet ein kleiner Wizard, der durch das Setup führt. Zunächst wird man gefragt, ob man die Konfiguration manuell durchführen oder das Standard-Setup das nur Babel und ESLint beinhaltet, nutzen möchte. Wir wählen zunächst manuell mit den Pfeiltasten und anschließender Leertaste um zu sehen, welche Möglichkeiten angeboten werden.

Im manuellen Modus erscheinen nun alle Optionen und Packages die genutzt werden können. Beispielsweise kann ich relativ schnell und simpel den Vue Router meinem Projekt dadurch hinzufügen. Aber auch das Setup für Unit- und End-to-End Testing lässt sich anwählen.

Nachdem die gewünschte Auswahl vorgenommen wurde, lässt sich die Installation des Projektes und der nötigen Packages starten.

Mithilfe der CLI UI ein visuelles Projektsetup

Sollte man nicht zu den Terminal-Liebhabern gehören, lässt sich mithilfe eines modernen Interfaces ebenso ein Projektsetup durchführen. Dazu startet man im Terminal zunächst die UI mit:

vue ui

Dadurch öffnet sich auf Port 8000 das Vue UI Interface. Über Project Create startet man den bereits aus der CLI gewohnten Prozess beim Initialisieren eines neuen Projektes.

Zunächst lässt sich über der Speicherort aussuchen und der Projektname angeben. Ebenso kann zwischen npm oder yarn als Standard Package Manager gewählt werden. Eine Festlegung ist aber kein Muss. Sind die Einstellung getroffen, wird auch hier der Wizard Prozess gestartet.

Auch über die UI kann ein manuelles Setup durchgeführt werden, wenn zum Beispiel schon während des Setups der Vue Router oder Vuex hinzugefügt werden sollen.

Nach dem erfolgreichen Setup ist man startklar und kann sein Vue Projekt weiterentwickeln.

Prototyping: Wie du deine Idee testfähig machst

”Das müssen wir mal prototypen!”, “Lasst uns das mal bauen.”, “Das sollten wir vorher testen.” – Irgendwann kommt der Punkt, an dem man seine Ideen vom reinen Papierkonzept in ein anfassbares und erlebbares Produkt überführen möchte. Je eher dieser Moment eintritt, desto besser. Ein gut durchdachter Prototyp ist in der Lage reale Reaktionen bei Testern hervorzurufen. Das Ziel eines Prototyps ist die Machbarkeit einer Idee auf drei Ebenen zu klären:

  • Ist die Idee technologisch machbar?
  • Ist sie wirtschaftlich tragbar?
  • Schafft die Idee einen wirklichen Nutzen?
Das Ziel deiner Idee

Ich bin der Meinung das Hauptziel des Prototypen sollte es sein, die Idee greifbar und erlebbar zu machen. Man übergibt den Nutzer quasi ein Geschenk und beobachtet ihn dabei, wie er es nutzt.

Jetzt wird es spannend: Wie reagiert der Nutzer, wie nutzt er das Produkt?

Um Prototyping gut durchführen zu können, empfiehlt sich oft ein Hinterfragen des eigenen Mindsets. Wir sollten wegkommen davon, die perfekte Lösung entwickeln zu wollen und lieber eine bevorzugen, die gut genug ist. Zudem ist der Prototyp nicht als Langzeit-Lösung zu sehen, vielmehr als temporäre Lösungen die weitere Änderungsschleifen auslösen kann und soll.

Zeit sparen und schneller Einsichten gewinnen

Leider erleben wir in unserer täglichen Arbeit und Workshops allzu oft, dass Prototypen als perfekte Langzeit-Lösung gedacht werden, wodurch die ganze Kraft des eigentlichen Ansatzes verloren geht.

Frage dich: Wie kann ich die Zeit bis zum Testen verkürzen?

Wir können uns bei der Produktentwicklung zwei virtuelle Linien vorstellen. Der erste Meilenstein ist erreicht, wenn das Produkt die Grundfunktion beinhaltet, die getestet werden soll. Sobald dieser Punkt erreicht ist, sollten Nutzer in die ersten Tests einbezogen werden. Unsere Idee ist somit in ein reales und erlebbares Produkt überführt worden, dass gut genug zum Testen ist. Wir ersparen uns wertvolle Zeit und erhalten zudem erste Einsichten, was Nutzer unter dem Angebot verstehen und wie sie es für sich nutzen.

Entgehe der Gefahr, dass du dich in deine Idee verliebst

Wir alle kennen es, wie überzeugt man von seiner eigenen Idee sein kann und wie schmerzhaft es wird, wenn diese auf die Realität trifft. Mit der richtigen Geschwindigkeit im Entwicklungsprozess kann man sich vor diesem emotionalen Tief schützen. Teste ich frühstmöglich meine Idee als Prototyp, nehme ich Nutzerreaktionen mit einem hohen Änderungswillen auf. Ich verstehe, dass meine Ursprungsidee am Nutzer vorbeiging und ich nachjustieren muss. Je länger ich an meiner Idee im Verborgenen arbeite, desto geringer wird dieser Wille und ich neige eher zur Perspektive, dass die Nutzer einfach zu inkompetent sind, mein Produkt zu verstehen und zu nutzen.

Beginnen wir das Prototyping mit der Ideenentwicklung, entgehen wir diesem Dilemma und sind offen für Änderungen während des Prozesses.

Arten von Prototypen

Sobald klar ist, dass es vorteilhaft seine Idee und Hypothesen frühzeitig zu testen, stellt sich die Frage, wie genau ein Prototyp aussehen kann. Auf die Frage, was genau der perfekte Prototyp ist, gibt es leider keine allgemeingültige Antwort. Zielführend ist es immer, mit den Annahmen bezüglich meiner Idee zu starten, die am kritischsten für den Erfolg sind. Das heißt, wenn die gewählte Annahme so nicht eintritt, ist meine Idee nutzlos oder liefert nicht genügend Wert für den Nutzer.

Im Designbereich unterscheidet man zwischen Low-Fidelity Prototypen wie Mockups oder Storyboards bis hin zu High-Fidelity Typen wie klickbare Interfaces mit dem wichtigsten Grundfeature. Gerade Storyboards eignen sich um den Informationsfluss zu testen bzw. Abbruchskriterien für Nutzer zu identifizieren. Low-Fidelity Prototypen benutze ich verstärkt in der Konzeption von Produkten, jedoch nicht in Nutzertests.

High-Fidelity-Prototypen wie zum Beispiel eine Landingpage mit einem realem Kaufabschluss (die gewählte Zahlungsart der Nutzers wird jedoch nicht belastet) machen reale Aktionen und Reaktionen von Nutzern deutlich. Ist der Kunde bereit, einen in seiner Wahrnehmung realen Kaufabschluss zu tätigen, stehen die Chancen gut, dass die präsentierte Idee einen hohen Nutzen für den Nutzer hat.

Wenn dir klar bist, was du testen möchtest und mit welcher Art von Prototyp du den Test durchführen willst, bist du bereit für die Umsetzung.

Baue deine Westernkulisse

Wenn man sich an die Umsetzung eines Prototypen macht, hilft es im Generellen sich zu überlegen, welche Westernkulisse man aufbauen möchte.

Die Metapher mit der Westernkulisse finde ich für das Vorgehen ziemlich passend (die Idee habe ich von hier), da genau dieser Ansatz darstellt, wie der Prototyp gedacht werden sollte. Die Hauptstraße ist für den Nutzer vollkommen detailliert dargestellt und real erlebbar. Sobald
eine der Nebenstraßen betreten wird, ist der Prototyp natürlich erkennbar.

Man sollte sich die Frage stellen, wie sieht meine Hauptstraße für den Nutzer aus. Welche Funktionen muss ich ausgestalten und welche kann ich andeuten, muss ich aber nicht wirklich funktionsfähig machen. Wenn es dir gelingt, dass der Nutzer die Hauptstraße in deinem Produkt, deiner realen Idee entlangläuft und nicht bemerkt, dass es sich um einen Prototyp handelt, wird er so reagieren, wie er auch auf das finale Produkt reagieren würde.

Mit diesen Einsichten kannst du dein Produkt erfolgreich iterieren und einen wirklichen Mehrwert für deine Nutzer schaffen.👏🏻👏🏻

Why-How-Laddering: Definiere die passende Challenge

Eine gute Challenge kann den Start und Verlauf eines Innovationsprojektes positiv beeinflussen. Genauso kann aber auch eine zu allgemein bzw. zu offen formulierte Challenge das Projekt und Vorgehen beeinflussen. Um die passende Challenge zu finden sollte man sich Zeit nehmen und auch auf die korrekte Formulierung der Frage achten. In diesem Post stellen wir die Why-How-Laddering Methode vor.

Was wird benötigt:

  • Ein Moderator
  • Flipchart-Marker oder Whiteboard-Stift
  • Ein großes Blatt Papier (A1 oder noch besser A0) oder ein Whiteboard

Beim Why-How-Laddering soll die Fragestellung der Challenge angepasst werden. Grundlegend werden immer Fragen nach oben mit “Warum…” und nach unten mit “Wie…” gestellt. Wie klettern im Laddering wie auf einer Leiter nach oben oder unten.

Das Grundprinzip der Methode: Nach oben “Warum”, nach unten “Wie” fragen

Beispielsweise haben wir die Frage “Wie werde ich Popstar” zur Überarbeitung erhalten. Die Challenge ist ein Beispiel für eine eher ungeeignete Ausgangsfrage für ein Design Thinking Projekt. Sie benennt kein konkretes Problem und die Zielgruppe “ich” ist sehr begrenzt.

Zur Überarbeitung der Frage wird sie in die Mitte geschrieben und daraufhin der Prozess gestartet. Zum Beispiel mit der Frage: “Warum will ich Popstar werden?”. Hierbei erscheinen Antworten wie Ruhm, Anerkennung oder Aufmerksamkeit naheliegend.

Start mit den Fragen “Warum will ich Popstar werden?”

Um nun aus diesen eine neue Fragestellung ableiten zu können, ist es sinnvoll diese neuen Begriffe im Laddering einzuschließen. Beispielsweise kann nun gefragt werden: “Wie komme ich zu Ruhm?”. Auf dieser Grundlage eröffnen sich neue Felder, die durch die Ausgangsfrage nicht beachtet wurden.

Neue Themenfelder ergeben sich

Nun scheint die klare Lösung nicht mehr so einfach. Eine Umformulierung der Challenge könnte beispielsweise lauten “Was muss ich tun um mir ein außergewöhnliches Talent anzueignen?”. So wurde die sehr explizite Lösung schon etwas geöffnet. Das Laddering kann beliebig erweitert werden.

Laddering zur Umformulierung der Challenge

Die Methode sollte solange durchgeführt werden, bis eine natürliche Sättigung der Fragen auftritt. Danach kann eine neue Fragestellung gesucht werden.

Was eine gute Challenge ausmacht

Um eine Design Challenge erfolgreich bearbeiten zu können, ist es aus unserer Sicht wichtig, dass drei wesentliche Grundvoraussetzungen erfüllt werden.

  1. Benennt die Design Challenge ein klares Problem? Achtung: Symptome oder Lösungsansätze sind nicht das Problem an sich: Eine zu eng gefasste Problemstellung bietet zu wenig Spielraum, weil eventuell schon ein Lösungsansatz enthalten ist. Eine zu breit gefasste bietet dagegen wenig Bodenhaftung und erschwert konkrete Lösungen.
  2. Ist das Problem aus Nutzersicht beschrieben? Meist hilft ein solcher Blickwechsel enorm bei der Entwicklung und Validierung von sinnvollen Lösungsansätzen.
  3. Ist die Situation, in der sich das Problem für den Nutzer bemerkbar macht, klar beschrieben? Eine gute Situationsdefinition gibt wichtige Hinweise darauf, was das Team während der Verstehen-Phase durch Beobachtung und Interviews erleben sollte.

Es macht definitiv Sinn sich zum Start eines Innovationsprojektes oder Design Thinking Prozesses  kritisch mit der gegebenen Fragestellung bzw. Challenge auseinanderzusetzen und diese gegebenenfalls umzuformulieren. Dazu kann das Why-How-Laddering eine gute Möglichkeit sein, das Level und den Fokus der Ausgangsfrage zu verschieben.

Die Gefahr von Superhelden im Team

Jedes Team kennt sie – selbsternannte Helden des Arbeitsalltag, die vermeintlich perfekten Teamplayer. Regelmäßig finden sich Jobbörsen und Stellenanzeigen die bekannten Buzzwords wie “Superhelden“, “Coding-Rockstars” und “Ninjas”

Was falsche Superhelden auszeichnet

Unternehmen erschaffen regelmäßig diese Superhelden-Bilder. Kulturen in denen Workaholics bejubelt werden tragen nicht selten stark dazu bei. Dabei vergisst man jedoch oft grundlegende Dinge:

Working more doesn’t mean you care more or get more done. It just means you work more. Workaholics wind up creating more problems than solutions. 

Jason Fried, Rework

Kollegen, die mal wieder länger sitzen und für sich den Perfektionismus beanspruchen, aber eigentlich nichts anderes tun, als unnötige Details zu optimieren. Nicht selten, sind sie der Meinung, dass sie ihr Team gerade mal wieder im Alleingang gerettet haben. Sie erledigen den Hauptteil der Arbeit, können alles mindestens ein kleines bisschen besser und andere Teamkollegen behindern grundsätzlich eher Ihren Erfolg. Keiner ist ihnen ebenbürtig, geschweige denn versteht etwas von den eigentlich unlösbaren Problemen, die sie gerade wieder einmal lösen. Genau das sind die Superhelden ist unserem Arbeitsalltag jeder ist ihnen schon einmal begegnet, entweder als Kollege oder Projektpartner. Aus der eigenen Perspektive sicherlich eine sonnige und wohl verdiente Spitzenposition, im Hinblick auf die Teamkultur jedoch durchaus eine sehr große Gefahr. Durch Alleingänge und ihren ständigen Wunsch nach Anerkennung torpedieren sie die eigentlichen Werte, die ein Team teilen sollte:

  • Demut: Man kann und wird nicht alles wissen
  • Respekt vor der Arbeit der anderen
  • Ständige Bereitschaft Wissen zu teilen

Diese drei Werte sind für uns eine nachhaltige Grundlage für eine funktionierende Teamkultur. Gerade in der heutigen Welt können Teamstrukturen über den Erfolg eines ganzen Unternehmens entscheiden.  Das Verständnis für einander bringt Lösungen hervor, die ein Einzelner nie bedenken bzw. erahnen kann.

Probleme nicht mit Zeit bewerfen

Jeder kennt Probleme, die uns länger fordern als gedacht. Es entstehen schnell die Gedanken, “Ich habe schon soviel Zeit investiert, ich kann jetzt nicht aufhören.” Genau hier entscheidet sich, ob man in den Superhelden-Modus wechselt oder nicht. Verbittert versucht man die Aufgabe zum Laufen zu bekommen, vergräbt sich und denkt nicht daran andere um Rat zu fragen. Aufhören wird oft mit Aufgeben oder gar Scheitern verglichen. Aber genau das ist der Fehler. Wenn aus geplanten 2 Stunden, schnell 16 Stunden werden, sollte man relativ schnell ans Aufhören denken. Die Gefahr noch mehr wertvolle Zeit unnötig zu verbrauchen, ist viel größer. Zudem verringert sich das eigene Gefühl darüber, was jetzt noch Sinn macht oder nicht. Keiner kann müde noch wirklich gute Entscheidungen treffen. Abstand, eine Nacht drüber schlafen, Abschalten – sind die eigentlich Dinge, die wir in diesen Fällen tun sollten.

Wahre Superhelden brauchen keinen Umhang

Die wahren Superhelden in unseren Team können sich eingestehen, wenn sie etwas nicht wissen. Sie sind bereit andere zu fragen bzw. zu helfen, wenn ihre Teamkollegen nicht weiterkommen. Die Offenheit ständig neue Dinge zu lernen, macht sie fit für die Zukunft. Der Perspektivwechsel hilft beim Verstehen. Sie bewerfen Probleme nicht mit Zeit, sondern überlegen bereits wie sie schneller zum Ziel kommen können. 

Produktfeatures schnell und einfach priorisieren

Gerade in der Produktentwicklung ergeben sich während des Entwicklungsprozesses zahlreiche Ideen und Verbesserungen, die genau betrachtet und priorisiert werden sollten. Nicht selten entsteht bei mangelnder Einstufung der Ideen ein verschwommenes Bild vom finalen Produkt, das wichtige Entwicklungsressourcen falsch bindet. In diesem Text zeigen wir, wie mithilfe der Impact-Effort-Matrix eine simple aber sehr effektive Einordung der Vorhaben gelingt.

Was wird benötigt:

  • Rechteckige Post-its, wir mögen gelb
  • Sharpies (für Insider der Begriff für geeignete Stifte zum Beschreiben von Post-its) oder einfach gesagt, dicke Stifte zum Schreiben
  • Ein großes Blatt Papier (A1 oder noch besser A0) oder ein Whiteboard

Die Matrix erstellen und Items vorbereiten

Die Impact Effort Matrix ist ein spannendes und gleichzeitig einfaches Instrument, um eine Priorisierung von Aufgaben, Entwicklungstickets oder auch Meilensteinen während der Produktentwicklung anzugehen. Wie der Name schon sagt, handelt es sich dabei um eine 2 mal 2 Matrix mit den Achsen Aufwand und Einfluss. Um starten zu können, zeichnet man das Grundraster der Matrix auf ein großes Blatt Papier oder Whiteboard und deutet die Vierteilung durch Mittelachsen an.

Das Grundlayout der Matrix ist schnell erstellt



In der Zwischenzeit sollten alle zu priorisierenden Items auf einzelne Post-its geschrieben werden, sodass anschließend die Lösungsideen einzeln bewertet werden können.

Alle Items auf einen Post-it schreiben

Die Items im Team bewerten

Im Idealfall ordnet man die Features in einer gemeinsamen Teamrunde innerhalb dieser Matrix an. Dabei sollte durchaus diskutiert werden, jedoch im Rahmen der vorgegebenen Kategorien. Am besten nimmt sich ein Teammitglied ein Item und bewegt es zunächst auf der horizontalen Achse bis das Team über den Aufwand einstimmig entschieden hat. Nun ist die vertikale Achse und somit der Einfluss des jeweiligen Items dran. Auch hier verschiebt das Teammitglied so lange die Karte bis die richtige Position für das Item erreicht ist. Dieses ganze Prozedere führt man mit allen vorhandenen Karten durch.

Wir suchen nach hohem Einfluss und geringem Aufwand

Sobald alle Items in der Matrix angeordnet sind, ergibt sich ein gewisses Bild innerhalb der Matrix. Es ist naheliegend und zielführend, sich relativ schnell den Bereich hoher Einfluss, geringer Aufwand genauer anzuschauen. Alle Items, die sich hier befinden sollten hoch priorisiert und zügig umgesetzt bzw. validiert werden.

Die befüllte Matrix lässt nun Schlussfolgerungen zur Priorisierung zu

Abschließend können alle Lösungsideen in dem Bereich hoher Einfluss, geringer Aufwand mit einem Punkt markiert werden, sodass sie bei späterer Verwendungen schnell wieder erkennbar sind.

Die Impact-Effort-Matrix ist eine gute Methodik, um schnell und einfach eine Priorisierung der anstehenden Produktfeatures ableiten zu können. Besonders im Team hilft die Vorgehensweise, um ein gemeinsames Verständnis für die kommenden Entwicklungsschritte aufzubauen.