Management Prozesse, die unsere Welt verändern

Was wir tun

More onion entwickelt effektive Strategien, überzeugende Kreativkonzepte und Kampagnen-Tools. Damit unter- stützen wir Organisationen beim Campaigning

und Fundraising. Unser Ziel ist immer, die größtmögliche gesellschaftliche Wirkung mit den vorhandenen Ressourcen zu erreichen, unabhängig von der konkreten Taktik oder dem Bereich der Arbeit.

In den letzten 10 Jahren Agenturarbeit und von hunderten Projekten haben wir gelernt, dass es dafür vor allem eines braucht: gute Management-Prozesse. Das bedeutet Arbeitsabläufe, vorhandene Ressourcen und Einschränkungen von außen gut zu balancieren. Also die Komplexität von “Knowledge Work” zu navigieren und am Ziel anzukommen.

In diesem kurzen Dokument möchten wir euch zeigen wie wir arbeiten, was wir gelernt haben und welche Prozesse unserer Erfahrung nach große Wirkung für Organisationen entfalten können.

Die wichtigsten Empfehlungen

Don’t set out your requirements in stone at the beginning of the project - encourage new ideas throughout and your objectives will be met faster, more efficiently and at less cost.

1. Es lohnt sich den detaillierten Inhalt (“Scope”) des Projektes nicht genau festzulegen - dadurch können neue Ideen und sich ändernde Anforderungen noch mit einbezogen werden. Leg ein klares messbares Ziel fest, aber bleib flexibel bei der Wahl welchen Weg in Richtung Ziel du beschreiten möchtest. Dadurch können Ziele oft billiger und besser erreicht werden.
2. Mach keine üblichen Ausschreibungen und Auswahlverfahren. Arbeite stattdessen mit einer Agentur zusammen, die Erfahrung damit hat, Projekte auf iterative Art und Weise umzusetzen (oder organisiere ein Pilot-Projekt, um eine Agentur zu testen). Sonst kommt oft am Ende des Projektes heraus, dass die gewählte Agentur den Budget-Rahmen sprengt oder die Anforderungen nicht erfüllen kann.
3. Wähle einen “agilen” Prozess, um Projekte umzusetzen. Dadurch können auch noch Änderungen gemacht werden, wenn die einschlägige Idee aus dem Design oder der Konzeption erst etwas später in der Projektlaufzeit kommt. Wenn du zu Beginn alles in Stein meißelst, dann verpasst du Möglichkeiten zur Verbesserung und Innovation.
4. Sorge dafür, dass das Produkt deines Projektes so oft wie möglich in seiner Gesamtheit zu sehen und zu testen ist, nicht nur einzelne isolierte Teile. Idealerweise werden diese Zwischenschritte sogar veröffentlicht. Damit kannst du Feedback von vielen Leuten einholen während der Projektlaufzeit und dieses Feedback auch direkt umsetzen.
   Zum Beispiel zahlt es sich aus, eine Website schon zu launchen, wenn sie noch nicht perfekt ist. Dafür kannst du zum Beispiel testen, ob deine Annahmen bezüglich der Zielgruppe korrekt sind. Die Ergebnisse dieser Tests kannst du direkt mit einfließen lassen.
5. “Fail early, fail cheaply” bedeutet zentrale Annahmen über das Projekt möglichst früh einem Realitäts-Check zu unterziehen. Je früher du herausfindest, ob deine Annahmen korrekt sind, desto billiger ist es für dein Projekt. Im schlimmsten Fall erfährst du erst nach dem Abschluss des Projektes, dass eine grundlegende Hypothese falsch war. Das ist teuer.
6. Das nächste Mal, wenn du eine Agentur beauftragen willst und du eine offene Ausschreibung in Erwägung ziehst, stell dir die folgende Frage: "Werde ich tatsächlich zum besten Ergebnis und zur besten Agentur für mein Projekt gelangen, oder entscheidet zum Schluss einfach die Qualität der Verkaufspräsentationen?"

Im folgenden Dokument erklären wir diese Punkte im Detail.

Komplexe Projekte und deren Eigenschaften

Kreativarbeit, digitale Kommunikation und Software-Entwicklung finden sich in der Kategorie des “Knowledge Work” wieder. “Knowledge Work” zeichnet sich dadurch aus, dass Teams gemeinsam oft komplexe Probleme lösen müssen. Kreative Köpfe entwickeln für Kampagnen Ideen, Texte und Designs, die Menschen überzeugen können selbst aktiv zu werden.

Im Bereich der digitalen Kommunikation reicht es nicht, den Job einmal zu erlernen. Es werden jedes Jahr neue Rollen geschaffen und Team-Mitglieder müssen Kanäle und Konzepte implementieren, die es 2 Jahre zuvor schlichtweg noch nicht gab. Software-Entwickler*innen beschäftigen sich zum Beispiel damit, Benutzer*innen eine möglichst einfache und schnelle Website bereit zu stellen, während im Hintergrund hoch komplexe Systeme und Abläufe stehen.

Diese Komplexität führt zu großen Herausforderungen bei der Abwicklung von Projekten.

Projekte im Bereich “Knowledge Work”, wie die oben genannten Beispiele, können sehr schwer vorhersehbar sein, was diese Projekte riskanter macht als andere.

Was, wenn eine scheinbar großartige und kreative Idee es einfach nicht schafft, Unterstützer*innen zu mobilisieren?

“Knowledge Work” ist leider auch nicht sehr einfach zu replizieren. Hat eine Maßnahme für eine Organisation und Situation sehr gut funktioniert, bedeutet dies nicht, dass es beim zweiten Mal den gleichen Erfolg haben wird. Es sind zu viele Faktoren im Mix.

Nachdem “Knowledge Work” in einer sich stetig wandelnden Umgebung stattfindet, kann das Resultat niemals 100% perfekt sein. Zum Beispiel kann bei einer Website etwas am Beginn des Projektes eine sehr gute Lösung sein. Beim Launch 3 Monate später könnten jedoch bereits neue Kanäle aufgetaucht sein, oder die Schnittstelle zu einem der vielen Systeme (wie der Fundraising-Datenbank) kann sich komplett verändert haben. Denke an die Geschwindigkeit, mit der Menschen den Wechsel zu mobilen Endgeräten vorgenommen haben - innerhalb von 1-2 Jahren haben die meisten Organisationen einen Sprung von ca. +30% mobiler Nutzer*innen erlebt).

Also: sich stetig ändernde Umstände führen zu anderen und neuartigen Anforderungen an das Projekt, was die Abwicklung des Projektes schwer vorherzusehen macht.

Aufgrund der inhärenten Komplexität von Projekten im Bereich “Knowledge Work”, gibt es keine Garantie auf Erfolg. Aber es gibt Prozesse, die das bestmögliche Ergebnis liefern und diese nutzen wir bei more onion.

Traditionelles Projektmanagement

Traditionelles Projekt-Management wird oft anhand folgender Phasen definiert, die zum Projekt-Erfolg führen sollen:

1. Initiation
2. Definition & Planning
3. Launch & Umsetzung
4. Monitoring
5. Evaluation

Dieser Prozess ist sehr gut, solange alles nach Plan läuft. Es wird vorbereitet, umgesetzt und dann evaluiert. Wenn sich die Umstände ändern, beispielsweise während der Entwicklung einer neuen Website, wird diese Methodik des Projekt-Management etwaige Schwachstellen erst am Ende des Projekts aufdecken. Dann wurde nach einigen Monaten Entwicklung eine Website produziert, die nicht den neuen Anforderungen entspricht.

Hier sind einige Beispiele, was sich mitten im Prozess ändern könnte:

1. Ein zentraler Stakeholder identifiziert relativ spät im Prozess, dass eine wichtige Funktion im ersten Konzept nicht enthalten war.
2. Deine Organisation gewinnt eine Kampagne und daher sind viele der neuen Funktionen für diese Kampagne nicht mehr nötig. Erst bei der nächsten Kampagne in einem Jahr werden manche dieser Funktionen vielleicht wieder gebraucht.
3. Es wurde eine Sicherheitslücke gefunden, die alle Betriebssysteme und Browser dazu veranlasst, das Verhalten ihrer Programme zu ändern (was zufällig auch das Verhalten des eigens entwickelten Systems ändert).

Wie oft hörst du von Projekten, die den Zeitplan nicht eingehalten haben oder total über das Budget hinausgeschossen sind? Wie oft hörst du, dass Projekte ihr Ziel nicht erreichen?

Das passiert oft, weil ein etwas altmodischer Prozess zum Einsatz kommt, wodurch sich das Team und das Projekt nicht gut an geänderte Umstände anpassen können. Projekte schaffen es nicht, neue Anforderungen einzuplanen oder sind bereits beim Launch wieder obsolet. Oder Projekte können den Zeitplan nicht einhalten, weil die Priorisierung und der genaue Inhalt des Launches nicht angepasst werden konnten.

Die Anforderungen zu Beginn des Projektes nicht komplett fest zu zurren führt dazu, dass neue Ideen während der gesamten Laufzeit gefragt sind. Meist können so Ziele schneller, billiger und effektiver erreicht werden.

Wir empfehlen den Prozess des Sammelns von Anforderungen mit externen Expert*innen gemeinsam durchzuführen. Dadurch erhält man einen externen Blick auf die Lage und schafft es oft den Fokus auf den tatsächlichen Zielgruppen für das Projekt zu behalten.

Die gute Nachricht ist, dass es Prozesse gibt für den Umgang mit komplexen und unvorhersehbaren Projekten. Die zentrale Idee dieser Prozesse ist es, Risiko zu minimieren.

Das inhärente Risiko bei Projekten

Ein komplexes Projekt umzusetzen wird immer riskant sein. Daran wird sich nichts ändern.

Die meisten Projekte scheitern, weil sie die Zielsetzungen nicht erfüllen, oder weil sie deutlich teurer oder später umgesetzt werden, als nötig. Beide dieser Fälle führen zu hohem Risiko für Organisationen. Gute Prozesse können das Risiko nicht eliminieren, aber es kann abgeschwächt werden.

Wenn dem Projekt-Team folgende Dinge ermöglicht werden, führt das zu einem niedrigeren Risiko für das Projekt:

1. Nach dem Entwickeln eines tiefgehenden Verständnisses für die Zielsetzungen, werden verschiedene mögliche Lösungen ausgearbeitet und getestet.
2. Sich schnell auf neue Anforderungen einstellen und anpassen können.
3. Die Anforderungen werden nicht zu Beginn des Projektes fixiert. Änderungen sind willkommen, wenn sie zu einer besseren / effektiveren / schnelleren / billigeren Erreichung des Zieles führen.
4. Die Zielsetzungen werden genutzt, um eine klare Priorisierung vorzunehmen. Daraus wird abgeleitet, welche Features umgesetzt und welche Taktiken realisiert werden.
5. Möglichst früh und auf möglichst billige Art und Weise zu testen, ob die grundlegenden Hypothesen und Annahmen korrekt sind. Das passiert durch die Entwicklung von Prototypen und eigens für Tests entwickelte Projekte, die eine Art “Reality-Check” darstellen. Wenn etwas nicht funktioniert, kann man im Projektzeitraum daraus lernen.
6. Teile des Projektes in kleineren, aber aus User Sicht gesamten, Einheiten ent- wickeln und launchen. Dadurch kann stetig Feedback von außen gesammelt werden.
7. Menschen sind wichtiger als Prozesse. Prozesse sollen helfen und die Arbeit im Team einfacher machen, nicht die Freiheit der Team-Mitglieder einschränken und die Arbeit bürokratisieren. Text und Dokumentation ist gut, aber es wird niemals die Erfahrungen und Erinnerungen des Teams ersetzten, das ein Projekt umgesetzt hat.
8. Ermächtige Teams sich selbst zu organisieren. Das ist besonders bei der Umsetzung von kleinen Experimenten wichtig, die das Risiko des Projektes minimieren.
9. Stetige Verbesserung jeder Person im Team und des Prozesses ist sehr wichtig. Neue Möglichkeiten erforschen, an die Grenzen des Machbaren kommen, neue Gefahren für Projekte kennen lernen und neue Anforderungen erfahren: all das passiert nur während der praktischen Arbeit an Projekten.

Diese Prinzipien werden üblicherweise umgesetzt, wenn eine Form des “agilen” Management angewandt wird.

Warum ist eine Ausschreibung (RFP) für solche Projekte nicht ideal?

Eine der verbreitetsten Wege eine Agentur oder eine Software-Lösung zu kaufen, ist eine offene Ausschreibung (Oft als “RFP” bezeichnet). Es werden klare Anforderungen formuliert, einige Anbieter eingeladen mitzumachen und diese schicken dann ein Angebot zurück.

Leider führt genau diese Methode oft zu schlechten Ergebnissen. Eine Ausschreibung hat zum Ziel Kosten zu vergleichen. Das Problem ist, dass die angebotenen Leistungen und Lösungen sehr unterschiedlich sind. Eine Agentur bietet eine billige, dafür weniger nachhaltige Lösung (zukünftige Kosten sind höher).

Eine andere Agentur interpretiert die Anforderungen doch etwas anders. Die Kosten direkt zu vergleichen ist also nicht sinnvoll. Erst am Ende des Projektes oder einige Jahre danach kommt heraus, ob die Agentur im Rahmen des Budgets bleibt oder nicht.

Nachdem es bei der Ausschreibung zwangsläufig einen fixierten “Scope” des Projektes gibt, können Agenturen neu gewonnene Erkenntnisse während der Umsetzung nicht mehr einfließen lassen. Wie bereits erwähnt ist das jedoch die Voraussetzung, um komplexe Projekte erfolgreich umsetzen zu können. Die von Beginn an definierten Anforderungen führen dazu, dass das Team Stück für Stück die gesamte (bereits vorgegebene) Lösung umsetzt. Dadurch kommt ein weiteres Risiko zu tragen: wenn Puzzle-Stück für Puzzle-Stück entwickelt wird, kann nicht das “große Ganze” getestet werden. Dadurch wird das gesamte Ergebnis erst zum Schluss geprüft. Wenn dann Probleme auftauchen, müssen Änderungen mit neuem Budget in einem Folgeprojekt vorgenommen werden.

Offene Ausschreibungen führen dazu, dass Agenturen vorgefertigte Lösungsansätze für vermutlich etwas unklare Anforderungen präsentieren, die keinen Reality-Check vorsehen.

Manchmal werden Ausschreibungen auch genutzt, um sehr unterschiedliche Ansätze zur Problemlösung zu sammeln. Hier ist jedoch festzuhalten, dass sich erst im Laufe eines Projektes herausstellen wird, welche Lösungen die besten sind. Das im Vorhinein zu planen, ignoriert die Eigenschaften von komplexen Projekten.

Eine Ausschreibung wird oft genutzt, um den Vergabeprozess zu rechtfertigen und objektiver zu gestalten. Praktisch ist die Wahl einer Agentur auf Basis eines Angebots jedoch in etwa wie der Kauf eines Hauses, nachdem man eine kurze Broschüre gesehen hat. Ausschreibungen sind deutlich nützlicher, um die Verkaufspräsentationen von Agenturen zu beurteilen, als tatsächlich eine gute Partnerin für dein Projekt zu finden.

Natürlich sollte die Wahl einer Agentur auch nicht einfach auf Bauchgefühl basieren.

Eine kurze Zusammenfassung

1. Ausschreibungen führen zu keinem brauchbaren Vergleich der Kosten, weil meist komplett unterschiedliche Dinge verglichen werden
2. Ausschreibungen verleiten Agenturen dazu, nötige Prozesse zu überspringen und eine konkrete Lösung zu einem Problem vorzuschlagen, das nicht vollkommen bekannt ist (anstatt durch die Phasen eines iterativen Prozesses zu gehen)
3. Anforderungen sind nicht geeignet, um verschiedene Optionen zu vergleichen, weil sich meist erst während des Projektes herausstellt, was die beste Option für das Problem ist
4. Anforderungen führen zu Projekten, die wie Puzzles entlang eines GANTT-Charts entwickelt werden. Dadurch ist das Risiko hoch, dass am Ende des Projektes das Ziel nicht erreicht wird.
5. Das Festlegen von Anforderungen zu Beginn des Projektes führt dazu, dass neue Erkenntnisse nicht einfließen, Chancen verpasst werden und veränderte Umstände ignoriert werden

Statt solchen offenen Ausschreibungen empfehlen wir, eine Konversation mit diversen Agenturen zu führen, die für dich tatsächlich interessant und kompetent wirken. Definiere die Einschränkungen (Budget, Zeitplan) und die genaue Zielsetzung. Dann bitte sie darum, den Prozess zu erklären mit dem sie das Ziel erreichen wollen. Anschließend kannst du zum Beispiel eine Agentur buchen, um ein kleines Pilotprojekt umzusetzen. Konzipiere ein Projekt, das dir und deiner Organisation hilft zu lernen und neue Anforderungen zu finden.

Manchmal kann dieses Pilot-projekt auch die erste Iteration von einem größeren Projekt sein. Du kannst bei kleineren Projekten mit deutlich weniger Risiko herausfinden, ob eine Agentur es schafft deine Zielsetzungen zu erreichen oder nicht. Wenn alles gut läuft, kannst du die Agentur für mehr Arbeit am Projekt beauftragen.

Wenn du etwas mehr Budget hast, kannst du diesen Prozess noch verbessern indem du mehrere Agenturen damit beauftragst, ein Pilot-Projekt für dich umzusetzen. So kannst du verschiedene Agenturen und ihre Arbeitsweisen kennen lernen, dein Projekt weiter bringen und musst noch nicht dein gesamtes Budget auf ein Pferd setzen.

Durch diese Vorgangsweise wirst du sehen, ob die Agentur tatsächlich deine Zielsetzungen erreicht

• sich an Budget-Vorgaben hält
• Zeitpläne beachtet
• und wie es für dich ist, mit der Agentur zusammenzuarbeiten

Die Grundlagen von “Agile management”

Wir sind überzeugt, dass agile Management-Methoden die beste Lösung für die Umsetzung komplexer Projekte ist.

Agiles Management hat seinen Ursprung in der Software-Entwicklung. Im letzten Jahrzehnt hat es sich jedoch durch Start-Ups und die digitale Transformation relativ schnell auf andere Bereiche ausgebreitet. Agile wurde entwickelt, weil große

Software-Projekte laufend viel zu spät gelauncht wurden und die Anforderungen der Nutzer*innen nicht erfüllt haben.

“Things change fast in the world of the internet.”

In unserer schnelllebigen, komplexen Welt ist es nicht möglich, einem neu zusammengesetzten Team 50 Seiten Spezifikation zu übergeben und dieses Team dann einige Monate einfach vor sich hin arbeiten zu lassen. Diese Herangehensweise funktioniert nicht mehr. So kam agiles Management auf.

Die erste “Idee” hinter “agilem Management” war eher lose definiert. Nach einigen Jahren haben sich neue Schulen in diesen Bereich geformt die alle einen etwas anderen Zugang bieten. Was sie verbindet ist ein Ansatz, der stetig neue Priorisierung ermöglicht und viele kleine Evaluationsphasen durchläuft anstatt eine große am Ende des Projektes.

Die meisten Methoden nutzen Zyklen, in denen das Projekt auf iterative Art und Weise entwickelt wird. Zum Beispiele eine fixe 2-Wochen-Phase, für die die Arbeit portioniert und in der sie ausgeführt wird. Dann wird geprüft, ob sich die Anforderungen geändert haben und die neuen Entwicklungen diese erfüllen. Am Ende jedes Zyklus sollte das Projekt theoretisch bereit für einen “Launch” sein, auch wenn es eventuell noch nicht auf Hochglanz poliert wurde.

Nach jedem Zyklus wird das Produkt besser, etwas polierter und vor allem: es wird Feedback gesammelt, das direkt eingearbeitet werden kann.

Am Beginn jedes “Zyklus” kann die Organisation mit der Agentur zusammen bestimmen, was im nächsten Zyklus entwickelt wird. Haben sich die Prioritäten geändert? Was haben wir in der Zwischenzeit gelernt? Für wie viele Zyklen haben wir noch Budget?

Sollte das Budget ausgehen, ist trotzdem ein launchbares Produkt vorhanden. Das Risiko des Projektes verringert sich mit jedem erfolgreich abgeschlossenen Zyklus. Wenn etwas nicht zum gewünschten messbaren Ergebnis führt (z.B. anhand von Key Performance Indicators), kann es im nächsten Zyklus optimiert werden.

Nach jedem Zyklus gibt es einen guten “Reality-Check”, ob die gewünschte Wirkung eintritt oder nicht.

Man gewinnt auch etwas Planungssicherheit, weil der Aufwand im Detail nur für den kommenden Zyklus geschätzt wird. Dadurch erhält man präzisere Schätzungen und kann budgetär besser steuern.

Die Planung im “agile” Management erfolgt immer aus Sicht der End-Nutzer*innen (bei Software) bzw. aus Sicht der Zielgruppe (bei Kampagnen). Es werden sogenannte “User Stories” formuliert, die eine kurze Geschichte davon erzählen, was die Nutzer*innen erleben können, sobald die Arbeit abgeschlossen ist.

Damit ist das Endergebnis klar testbar, gleichzeitig ist der genaue Weg, wie es zu diesem Ergebnis kommt, nicht vorgegeben. Das Team kann unterschiedliche Ansätze ausprobieren und sich für einen Weg entscheiden.

Kurz zusammengefasst: Komplexe Projekte können dann am besten umgesetzt werden, wenn ein “agile” Management-Prozess zum Einsatz kommt. Das Ziel von diesem Prozess muss es sein, das bestmögliche Resultat zu erzielen, das innerhalb der Einschränkungen (Zeit, Budget) möglich ist.

Bei more onion nutzen wir eine Mischung aus verschiedenen “agile” Methoden (zum Beispiel Teile von SCRUM und Xtreme Programming) für die Entwicklung von Software, aber auch bei der Umsetzung diverser Projekte.

Die Grundlagen von Kanban

Methoden wie Kanban und “Lean Development” werden auch oft mit “agile” assoziiert, sie nutzen allerdings keine zeitlich fixen Zyklen (oder “Sprints”, wie diese Zyklen oft genannt werden). Kanban kommt ursprünglich aus der Industrie und wurde entwickelt, um Arbeitsabläufe und Lieferketten zu optimieren.

Im Zentrum von Kanban steht das Identifizieren von Bottlenecks in Arbeitsabläufen. Kanban regt das Team an viel zu kollaborieren, um Probleme, die den Arbeitsfluss beeinträchtigen, gemeinsam zu lösen.

Dafür werden üblicherweise Tafeln (“Kanban Boards”) genutzt, die den Arbeitsablauf visualisieren. Dazu gibt es regelmäßig informelle Treffen, um den Status gemeinsam zu besprechen. Durch die Transparenz, die das Kanban Board bietet, können sich Teammitglieder besser selbst organisieren, wenn es darum geht, größere Herausforderungen zu meistern.

Kanban setzt es sich zum Ziel, Arbeitsabläufe so zu standardisieren, dass die Zeit, die ein Arbeitspaket bis zur Fertigstellung braucht, möglichst wenig variiert. Dadurch wird der Arbeitsfluss etwas vorhersehbarer.

Mit Hilfe von “Work in Progress Limits” (also einer Limitierung des Volumens von Arbeit, die in einem Team gleichzeitig vonstatten gehen kann) wird zusätzlich die Kollaboration zwischen Teammitgliedern gefördert. Wenn immer nur eine überschaubare Anzahl von Arbeitspaketen gerade bearbeitet wird, führt das zu besserer Qualität und meist weniger Variation in der aufgewendeten Zeit.

Kanban setzt auf eine Strategie “in letzter Minute” fertig zu werden. So erfolgt die detaillierte Ausarbeitung von Features oder Kommunikationsmaßnahmen erst dann, wenn das Team kurz davor ist, diese auch umzusetzen. Um das große Ganze nicht aus den Augen zu verliegen werden Roadmaps und Prototypen entwickelt. Aber die Details müssen warten.

Dadurch wird verhindert, dass sehr viel Zeit investiert wird, um neue Arbeitspakete vorzubereiten - wovon einige dann doch nicht umgesetzt werden. Stattdessen steht mehr Zeit für die Arbeitspakete bereit, die auch wirklich jetzt umgesetzt werden sollen.

In Kanban wird das Board meist in regelmäßigen Abständen mit neuen Arbeitspaketen befüllt, dabei wird das Limit (siehe oben) beachtet. Meist sind Kund*innen in diesen Prozess mit eingebunden, sodass alle die Möglichkeit haben zu partizipieren, Fragen zu stellen und Probleme anzusprechen.

Kanban funktioniert also nicht in fixen Zyklen. Arbeitspakete können relativ frei in das Board fließen und abgearbeitet werden, bis das Limit erreicht ist. Daher nutzen wir Kanban bei more onion für Support-Arbeit und für bestimmte Phasen von Projekten, wo viel unvorhersehbare Arbeit auf uns zukommt, zum Beispiel während des Launches einer Kampagne.

User Experience Design, kreative Arbeit & design thinking

Im Kreativbereich und beim User Experience Design ist ein strikt iterativer Prozess (siehe oben) meist nicht sinnvoll. Für solche Projekte braucht es meist eine Zeit für die nötige Recherche, Interviews, User Testing, die Sammlung von Use Cases und die Entwicklung von Prototypen.

Die Prototypen können bereits sehr früh im Prozess genutzt werden, um zu testen. Durch diese Informationen kann entschieden werden, welche Prototypen weiter geführt werden.

Diese können dann im Rahmen von Zyklen (iterativ) zu launchbaren Produkten weiterentwickelt werden.

Durch User Testing, das Messen der wichtigsten Kennzahlen (z.B. Conversion Rate) und manchmal sogar durch Rollenspiele können Interaktionen von Nutzer*innen sehr früh im Prozess ausprobiert werden.

Bei Graphik Design nutzen wir den gleichen Prozess. Wir beginnen mit groben Ideensammlungen (“Mood Boards”), entwickeln einige mögliche Stoßrichtungen und geben diese für Feedback frei. Manchmal nutzen wir auch kleine Werbebudgets, um solche groben Entwürfe gegeneinander zu testen. Die besten Ideen werden dann weiterentwickelt.

Wenn Designs auch technisch umgesetzt werden, achten wir darauf, dass das Kreativteam sehr aktiv in die Entwicklung einbezogen ist. Damit stellen wir sicher, dass bei der “Übersetzung” nichts verloren geht und laufend gute Design-Entscheidungen getroffen werden.

Aus unserer Sicht sind Kreativkonzepte dann erfolgreich, wenn wir ihre Wirkung direkt messen können. Eine Online-Aktion ist dann “gut”, wenn viele Menschen überzeugt werden mit zu machen und dadurch eine politische Wirkung entsteht. Eine Spendenseite ist dann “schön”, wenn viele Menschen erfolgreich damit spenden.

Unsere Arbeit ist stark beeinflusst von “Design Thinking”: eine Methode, die ebenfalls Nutzer*innen bzw. die Zielgruppe in den Fokus der Arbeit stellt.

Design thinking nutzt folgende Phasen für Projekte:

1. Empathise: die Zielgruppe und das Problemfeld kennenlernen, Recherche, Interviews, etc.
2. Define: Entscheidung, wo der Fokus gelegt wird (“Was ist das genaue Problem, das es zu lösen gilt?”)
3. Ideation: viele mögliche Lösungen zum Problem finden
4. Prototype: einige der möglichen Lösungen grob ausarbeiten, um mehr zu lernen und sie testen zu können
5. Test: die Prototypen direkt ausprobieren, testen und daraus wertvolle Erkenntnisse sammeln

Bei more onion hängen wir nach dem Testen der Prototypen meist iterative Zyklen (siehe oben) an, um den Prototypen weiter zu entwickeln. Sobald der Prototyp die minimalen Anforderungen erfüllt, kann ein Test-Launch stattfinden. Dadurch haben wir möglichst früh ein “Minimal Viable Product” (MVP).

Das Konzept des MVP ("Minimal viable Product)

Das Konzept eines “Minimal Viable Product” (MVP) kommt aus der Methodik von “Lean”. Die Idee ist, möglichst früh zu einem Punkt zu kommen, wo das produzierte Produkt den zentralen Zweck erfüllt. Das kann zum Beispiel eine erste Version einer Website oder Landing Page sein, obwohl noch einige Feinheiten und Detailarbeit nicht fertig ist.

Oft verzichtet diese erste Version auf komplizierte Funktionen und setzt den gesamten Fokus auf die wichtigsten 1-2 “User stories” (Interaktionen). Zum Beispiel kann eine Online Petition bereits gelauncht werden, wenn es den ersten Text gibt, ein Formular (das die Daten speichert), Tracking und eine Danke-Seite mit Share-Buttons.

Erst in der nächsten Version könnte dann ein ausgefeiltes Kampagnen-Design, zusätzliche Elemente wie zum Beispiel ein “Zähler” oder einige vorbereitete Split-Tests ausgerollt werden.

Das MVP verzichtet auf alles, was nicht absolut nötig ist. Damit kann ein iterativer Prozess beginnen, bei dem schon sehr früh auch wirkliches Feedback gesammelt werden kann.

Was schließen wir aus all dem?

Bei more onion ist unser Ziel die größtmögliche Wirkung für eine Organisation mit vorhandenen Ressourcen zu erreichen. Die Prozesse und Methoden in diesem Dokument helfen uns, genau das zu erreichen.

Wenn du fragen hast, kannst du dich gerne bei uns melden!

Kontakt­iere uns