![\"Project](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/project-scoping-workshop-1.jpg\")
<\/p>\n<\/p>\n
Montagmorgen, 08:30, ein Meeting-Raum irgendwo im dritten Stock eines B\u00fcrokomplexes. Am Tisch: mehrere Entwickler, Projektleiter, Marketingvertreter und zwei UX-Spezialisten. Das Budget f\u00fcr die n\u00e4chsten drei Monate ist gesichert. Ziel des\u00a0Workshops ist es, die ersten Arbeitspakete f\u00fcr einen langfristigen Plan zu schn\u00fcren, um ihre komplette Software zu \u00fcberarbeiten und nutzerfreundlicher zu gestalten. W\u00e4hrend des Workshops stellt sich heraus, dass es insgesamt vier Arbeitspakete gibt, wobei jede anwesende Projektleiterin davon ausgeht, dass ihr Paket Priorit\u00e4t hat. Es entsteht ein l\u00e4ngerer Streit, in Folge dessen beschlossen wird, alle Pakete gleichzeitig anzugehen. Nachdem die ersten Budgets aufgebraucht sind, ist die Entt\u00e4uschung gro\u00df \u2013 nichts ist fertig geworden, kein Fortschritt im Vergleich zum Status Quo ist zu erkennen. Das Projekt wird daher gestoppt und in die ungewisse Zukunft vertagt.<\/p>\n
Dienstagnachmittag, 14:30, das B\u00fcro der Gesch\u00e4ftsleitung. Anwesend sind neben drei engen Vertrauten der Gesch\u00e4ftsleitung der Leiter des Entwicklungsteams und zwei Vertreter einer externen UX-Agentur. Geplant wird die Neuentwicklung einer Software \u00fcber die n\u00e4chsten beiden Jahre. Man ist sich sicher: Die Software wird ein durchschlagender Erfolg. Deshalb wurde das Budget f\u00fcr die komplette Entwicklung bereits zugesichert. Die Software wird in-house entwickelt und nach zwei Jahren wird eine gestalterisch anspruchsvolle, mit internen Mitarbeitern ausgiebig getestete und f\u00fcr gut befundene Software auf den Markt gebracht. Die potentiellen Kunden wussten bisher nichts von der Neuentwicklung, da man nicht wollte, dass vor Release etwas \u00fcber das innovative Produkt bekannt wird.<\/p>\n
Ein Jahr sp\u00e4ter: Die Software ist mittlerweile zw\u00f6lf Monate am Markt, aber wurde bisher nur ein einziges Mal verkauft \u2013 und das an ein Tochterunternehmen. Zwei Jahre Entwicklung sind damit umsonst gewesen. Die UX-Agentur wird aus dem Projekt entfernt, da es offenbar nicht gelungen ist, ein f\u00fcr die potentiellen Benutzer ausreichend spannendes Erlebnis zu bieten.<\/p>\n
\u2014<\/p>\n
Projekte wie diese beiden \u00fcberspitzt skizzierten gibt es wie Sand am Meer. Ein motivierter Projektstart, ein tolles Team \u2013 und am Ende der gro\u00dfe Frust, den niemand so wirklich herleiten kann. Doch woran liegt das? Was kann man tun, um solche Frustsituationen und vor allem Geldgr\u00e4ber zu vermeiden?<\/p>\n
<\/p>\n
Betrachtet man beide Szenarien im Nachhinein, stellt man fest: Die aufgetretenen Probleme h\u00e4tten tats\u00e4chlich vermieden werden k\u00f6nnen. Schauen wir uns beide Beispiele und die Ursachen ihrer jeweiligen Frustration noch einmal an:<\/p>\n
Es wurden viele F\u00e4den aufgegriffen, jedoch keiner zu Ende verfolgt. Man hatte f\u00fcr jedes Problem anscheinend eine grobe L\u00f6sungsvorstellung, jedoch konnte niemand WIRKLICH eines der Probleme im Detail l\u00f6sen, da sich hinter der verlockenden Fassade der L\u00f6sungsskizze nur ein leerer Raum mit einem gro\u00dfen \u201cToDo\u201c-Schild befand.<\/p>\n
Eigentlich wurde doch alles richtig gemacht: Designs wurden entworfen, getestet und umgesetzt, spezifiziert, \u2026 und das umsonst, denn dem Produkt fehlte ein starker Business Case, wodurch es sich nicht verkaufen lie\u00df. Offenbar wurde ein Problem gel\u00f6st, welches nicht existierte.<\/p>\n
\u2014<\/p>\n
Was haben diese Projekte gemeinsam? Ganz einfach \u2013 im Nachhinein betrachtet h\u00e4tte man diesen Frust durch saubere Vorarbeit noch vor Beginn der ersten Arbeiten vermeiden k\u00f6nnen.<\/p>\n
![\"Phasen](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/project-scoping-workshop.jpg\")
<\/p>\n
Der Schl\u00fcssel liegt also in der Projektvorbereitung und -definition. Was ist unser Projekt? Worum geht es, welches Problem l\u00f6st unser Produkt? F\u00fcr wen ist es gedacht? An wen verkaufen wir \u00fcberhaupt?<\/p>\n
Um diese Fragen zu beantworten, hat sich in unserem Continuous UX<\/a> Prozess der \u201eProject Scoping Workshop\u201c als effektiver Projektstart etabliert. Ziel des Workshops ist es, alle produktrelevanten Perspektiven an einem Tisch zu versammeln und gemeinsam eine Projektdefinition zu erarbeiten, auf die sich alle anwesenden Stakeholder committen k\u00f6nnen. Hierbei gilt es, folgende Aufgaben zu meistern:<\/p>\n Klingt nach einer Menge Arbeit? Ja, schon. Aber in erster Linie erfordert das Vorgehen etwas Disziplin. Jeder einzelne Punkt kann innerhalb von 1-2 Stunden bearbeitet werden. Denken wir zum Vergleich noch mal an Szenario 2 und die zwei Jahre Entwicklungszeit zur\u00fcck \u2013 DAS war eine Menge Arbeit, allerdings ohne Ergebnis. Dagegen sind ein paar Stunden wenig. Schauen wir uns die Aufgaben einmal im Detail an.<\/p>\n Nat\u00fcrlich k\u00f6nntest du es dir einfach machen und nur die Personen an den Tisch holen, die das gleiche Projektverst\u00e4ndnis wie du haben \u2013 aber helfen dir diese Kollegen wirklich, neue Perspektiven zu finden?<\/p>\n Versuche daher, eine m\u00f6glichst breite Teilnehmergruppe zusammenzustellen. Reibungen und Konflikte sind bereits vorprogrammiert? Umso besser, dann k\u00f6nnt ihr die aus dem Weg r\u00e4umen, bevor es zur teuren Projektarbeit kommt.<\/p>\n Versuche beim Zusammenstellen der Teilnehmer folgende Rollen einzubeziehen:<\/p>\n Tipp: Bisher haben sich 6-7 Teilnehmer als eine gute Zahl herausgestellt. Mehr Teilnehmer f\u00fchren meist zu langwierigen Diskussionen, die auf Grund der vielen verschiedenen Meinungen sehr schwer zu moderieren sind. Weniger Teilnehmer hingegen f\u00fchren zu einer \u201eVerw\u00e4sserung\u201c des Ergebnisses, da sich individuelle Meinungen zu stark durchsetzen k\u00f6nnen.<\/p>\n Die schwierigste Aufgabe direkt zu Beginn: Versuche, alle L\u00f6sungen f\u00fcr eine Weile zu vergessen und dich zusammen mit deinem Team allein auf reale Probleme realer Nutzer zu konzentrieren. Es werden immer Teammitglieder am Tisch sitzen, welche bereits ein genaues Bild der sp\u00e4teren L\u00f6sung vor Augen haben. Versuche, sie zu \u00fcberzeugen, diese L\u00f6sungen f\u00fcr eine Weile beiseite zu stellen, denn unser einziges Ziel im Project Scoping Workshop ist es, herauszufinden, welche Bed\u00fcrfnisse wir bei den sp\u00e4teren Nutzern des Produkts zu erf\u00fcllen versuchen. Das WARUM zu kl\u00e4ren ist also das Ziel, nicht das WIE.<\/p>\n Tipp: Achte auf Formulierungen wie: \u201eDer Nutzer m\u00f6chte Feature XY haben\u201c<\/em>. Dahinter verbirgt sich der (meist unbewusste) Versuch, eine L\u00f6sung als Bed\u00fcrfnis zu formulieren. Das zugrunde liegende Bed\u00fcrfnis ist oft real, muss jedoch grundlegender formuliert werden. Mache den Teilnehmern des Workshops klar: Jedes Feature, dass kein Nutzerbed\u00fcrfnis erf\u00fcllt, ist f\u00fcr uns nicht relevant!<\/p>\n Wir haben es im Szenario 2 gesehen: Ein Projekt kann in der Durchf\u00fchrung noch sauber ablaufen \u2013 wenn es sich nicht verkauft, war im Zweifelsfall alle Arbeit umsonst. Finde daher heraus, wo derzeitige Businessprobleme oder -Gelegenheiten liegen und definiere gemeinsam mit deinem Team ein m\u00f6glichst stark darauf fokussiertes Ziel. Auch hier gilt nach wie vor: WIE ihr euer Ziel erreichen wollt, ist erst einmal sekund\u00e4r, es geht hier darum, WAS ihr erreichen m\u00f6chtet.<\/p>\n Tipp: Setzt euch nicht nur ein Ziel, sondern auch ein messbares Kriterium, anhand dessen ihr mit Ende des Projektes pr\u00fcfen k\u00f6nnt, ob ihr wirklich erfolgreich wart. In unserem zweiten Szenario w\u00e4ren dies zum Beispiel m\u00f6glicherweise Verkaufszahlen gewesen.<\/p>\n Der Erfolg eines Produkts h\u00e4ngt nicht ausschlie\u00dflich vom sp\u00e4teren Benutzer ab \u2013 es gibt deutlich mehr Stakeholder, die im Produktzyklus eine Rolle spielen. Angefangen von der Person, die entscheidet, euer Produkt zu kaufen, bis hin zum Servicemitarbeiter \u2013 sammele alle Stakeholder, die mit eurem sp\u00e4teren Produkt in Ber\u00fchrung kommen oder ein Interesse an dessen Erfolg haben k\u00f6nnten. Danach lege mit deinem Team fest, welchen dieser Stakeholder ihr prim\u00e4r bedienen m\u00fcsst, um euer zuvor gesetztes Businessziel zu erreichen.<\/p>\n Tipp: Der Abgleich mit dem Businessziel f\u00fchrt dazu, dass vermeintlich wichtige Stakeholder pl\u00f6tzlich Priorit\u00e4t verlieren. So ist es bei einer Messedemo vielleicht geschickt, ein UI zu bauen, welches sich komplett an die Bed\u00fcrfnisse eines Messebesuchers bzw. Entscheiders anpasst und nicht an die eines sp\u00e4teren Endnutzers.<\/p>\n Mit dem Businessziel und den Stakeholdern in der Tasche wird es konkreter. Nehmt euch den f\u00fcr den Business Case relevantesten Stakeholder vor und modelliert f\u00fcr dessen Rolle eine Persona. Um sich sp\u00e4ter im Designprozess besser in eure Persona hineinversetzen zu k\u00f6nnen, versuche m\u00f6glichst detailreich zu arbeiten, denn so werden Emotionen und Empathie geweckt.<\/p>\n Tipp: Redet im Folgenden von eurer Persona immer mit ihrem Namen, nicht von \u201eder Persona\u201c oder \u201edem Bediener\u201c. Ihr werdet merken, dass euer Team sich deutlich besser in die Haut eurer Persona hineinversetzen kann, wenn der Name jedem ein Begriff ist. Druckt die Persona aus und h\u00e4ngt sie an die W\u00e4nde eurer R\u00e4ume, um sie \u00fcber den gesamten Projektverlauf hinweg lebendig und pr\u00e4sent zu halten. Hier entwickeln wir mit dem LeanScope ein Persona-Tool<\/a>, mit dem ihr in Minuten ein druckf\u00e4higes Persona-Poster erstellen k\u00f6nnt.<\/p>\nJetzt Personas erstellen<\/span><\/a><\/span>\n <\/p>\n Nun wird es noch konkreter. Schreibe mit deinem Team ein Nutzungsszenario (\u201eContext of Use\u201c), in welchem die Persona mit den vorher definierten Problemen in Ber\u00fchrung kommt. Versuche dabei m\u00f6glichst detailreich zu arbeiten, denn nur so k\u00f6nnt ihr die Probleme und Bed\u00fcrfnisse eures Protagonisten verstehen und euch in die Story hineinversetzen. Auch hier \u2013 werdet gerne emotional, aber \u00fcbertreibt es nicht.<\/p>\n Tipp: Wenn du m\u00f6chtest, kannst du das Szenario parallel auch mitscribbeln. Das sorgt oft f\u00fcr gute Stimmung und hilft, Details zu finden, auf die man sonst niemals gekommen w\u00e4re.<\/p>\n Ihr habt es geschafft! Ihr wisst nun, wen ihr in welcher Rolle und in welchem Kontext gl\u00fccklich machen m\u00fcsst und welches Ziel ihr hiermit erreichen wollt. Wenn wir an unser Szenario 1 (Eierlegende Wollmilchsau) zur\u00fcckdenken, lag genau hier das Problem. Es gab keine Persona, kein wichtigstes Gesch\u00e4ftsziel und erst recht kein Nutzungsszenario, welches die Interaktion der Persona mit dem aktuellen System beschreibt. Genau betrachtet wurden eigentlich nur \u00dcberschriften von m\u00f6glichen Szenarien gesammelt, ohne jedoch in ein einziges detailliert hineinzuschauen. Fasst am Ende eures Workshops die Quintessenz dessen, was ihr erreicht habt, noch einmal in einem griffigen Satz zusammen: das \u201eProduktstatement\u201c, auf dass sich alle Teilnehmer committen k\u00f6nnen. Nach wie vor solltet ihr L\u00f6sungen ausklammern \u2013 beschreibt einfach nur, wen ihr beim Erreichen welches Zieles unterst\u00fctzen wollt. Ein Beispiel k\u00f6nnte so aussehen:<\/p>\n Mit Abschluss des Pilotprojekts im Juli 2019 wird Manfred der Maschinenbediener vom HMI dabei unterst\u00fctzt, die Werte des Datenblattes fehlerfrei in das System zu \u00fcbertragen, um Produktionsfehler zu vermeiden.<\/p>\n Tipp: Das abschlie\u00dfende Statement ist eine Zusammenfassung der vorhergegangenen Schritte. Lasst es jedoch keinesfalls aus Bequemlichkeit oder Zeitmangel weg, da es s\u00e4mtliche Erkenntnisse eures Workshops b\u00fcndelt. Ihr habt hier die einzigartige M\u00f6glichkeit, alle Teammitglieder auf ein gemeinsames Ziel, formuliert in einem griffigen Satz, einzuschw\u00f6ren.<\/p>\n Kaum ein Szenario spielt sich genau in dem Raum und mit den Personen ab, die beim Project Scoping Workshop teilnehmen. Du wirst also mit deinem Team Entscheidungen und Annahmen \u00fcber Persona und Szenario treffen, die im Nachgang verifiziert werden m\u00fcssen \u2013 denn was bringt die beste Zielsetzung und Modellierung, wenn die Realit\u00e4t ganz anders aussieht? \u00dcberpr\u00fcfe also im nach dem Scoping:<\/p>\n Tipp: Warte nicht mit der \u00dcberpr\u00fcfung. Versucht, euer Projekt erst nach der Verifizierung zu starten, um auf eventuelle \u00c4nderungen am Projektkurs vorbereitet zu sein.<\/p>\n Es kann und wird immer passieren, dass es im Projektverlauf unvorhergesehene Schwierigkeiten, Kurs\u00e4nderungen oder sogar Projektstopps gibt. Mit einer sauberen Vorbereitung in einem Project Scoping Workshop lassen sich jedoch die Risiken f\u00fcr einen Totalausfall auf ein absolutes Minimum reduzieren, da das Projekt auf stabilem Boden gestartet wird.<\/p>\n Detaillierteres Wissen zu Durchf\u00fchrung, Moderation und Form des Project Scoping Workshops vermitteln wir bei Interesse auch in unseren UX Academy Schulungen.<\/a><\/p>\n <\/p>\n Wir haben Dein Interesse geweckt? Schau Dir unsere Leistungen<\/a> an!<\/strong><\/p>\n\n
1. Stelle deine Workshop-Teilnehmer zusammen!<\/h3>\n
\n
![\"Problemraum](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/problems.gif\")
<\/p>\n2. Fokussiere dich auf Probleme, nicht auf L\u00f6sungen!<\/h3>\n
3. Finde einen starken Business Case!<\/h3>\n
4. Sammele alle Stakeholder!<\/h3>\n
![\"Persona](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Persona-Poster.jpg\")
<\/p>\n5. Modelliere eine Persona!<\/h3>\n
6. Schreibe ein Szenario!<\/h3>\n
![\"Produktstatement\"](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Produktstatement-Ablauf-1.jpg\")
<\/p>\n7. Formuliere ein Produktstatement!<\/h3>\n
8. \u00dcberpr\u00fcfe deine Annahmen!<\/h3>\n
\n
![\"Project](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/research.jpg\")
<\/p>\nZusammenfassung<\/h2>\n
Finde die richtigen Teilnehmer!<\/h3>\n
\n
Fokussiere dich auf Probleme!<\/h3>\n
\n
Finde einen starken Business Case!<\/h3>\n
\n
Sammele alle Stakeholder!<\/h3>\n
\n
Modelliere eine Persona!<\/h3>\n
\n
Schreibe ein Szenario!<\/h3>\n
\n
Formuliere ein Produktstatement<\/h3>\n
\n
\u00dcberpr\u00fcfe deine Annahmen<\/h3>\n
\n