Arbeiten mit dem AW Design Framework
In diesem Beitrag erkläre ich das AW Design Framework (AW steht für App bis Web). Ich zeige auch, wie man damit arbeitet.
App bis Web arbeitet mit einem Team aus Freelancern. Diese können auch in anderen Ländern sitzen, z. B. in Schweden oder Argentinien. Damit alle eingebundenen Dienstleister auf dasselbe Ziel und dieselbe Qualität hinarbeiten, wurde das AW Design Framework entwickelt.
Das ursprüngliche Ziel war klar: schnell eine Landingpage entwickeln. Sie soll möglichst schnell Leads generieren. Das Framework lässt sich aber auch für andere Software- und Marketingprojekte nutzen.
Es definiert und formalisiert unsere Arbeitsweise. So wird es zum Werkzeug für bessere Zusammenarbeit. Wir liefern bessere Ergebnisse, indem wir:
- Als Team vereinbaren, wie wir arbeiten.
- Uns mit anderen Teams bei AW abstimmen (Produkt, Technik und Marketing).
- Das Missverständnis auflösen, dass Design eine „magische Blackbox“ ist, die nur „Kreativen“ zugänglich ist.
Vorüberlegungen
Wie die meisten größeren Projekte besteht ein typisches Team aus vielen Rollen. Es geht um Strategie. Es geht um Umsetzung. Und es geht um Kommunikation.
Dazu gehören Kommunikationsstrategen, Konzepter, UX & UI-Designer, Webentwickler, Content-Strategen und SEO-Experten.
Die Erfahrung zeigt: Der Prozess ist oft ähnlich. Die Ergebnisse sind es nicht. Die Arbeit ist häufig eine Mischung aus Produkt und Marketing. Das führt zu unterschiedlichen Erwartungen an das Endergebnis.
Genau hier wird es problematisch. Erwartungen des Auftraggebers und Vorstellungen der Dienstleister müssen synchronisiert werden. Das AW Design Framework wurde so konzipiert, dass es zu Zielen und Mission passt. Es passt auch zur Art, wie wir Projekte umsetzen. Außerdem kann es als Vorlage für interne Marketing-Projekte dienen.
Reflexion
Für den Erfolg des Frameworks ist Reflexion entscheidend. Wir müssen regelmäßig über Fortschritte nachdenken. Sonst verlieren wir schnell den Kurs.
Im Alltag geht Reflexion aber leicht unter. Freelancer sind oft Generalisten. Neben dem Projekt laufen viele weitere Aufgaben.
Im Alltag mit harten Terminen und Produktfreigaben sind Designer oft sehr lieferorientiert. Dann wird schnell vergessen zu hinterfragen, ob man noch richtig liegt. Bewusstes Innehalten am Ende jeder Phase hilft. So machen wir nicht in die falsche Richtung weiter.
Phase 1: Verstehen
Zu Beginn eines Projekts erhalten wir Hintergrundinformationen. Dazu kommt eine Reihe von Annahmen. In dieser Phase dringen wir tiefer in den Problembereich ein. Wir validieren Annahmen oder widerlegen sie. Ergebnisse bringen wenig, wenn wir das Problem nicht zuerst ganzheitlich verstehen.
Mögliche Methoden in dieser Phase:
- Quantitative Recherche mit internen Tools (z. B. Google Analytics)
- Qualitative Forschung (Nutzerbefragungen, Interviews, Wettbewerbsanalyse)
- Projektstart mit Team und Stakeholdern, damit alles Wissen auf dem Tisch liegt
Am Ende dieser Phase sollte klar sein:
- Welches Problem gelöst werden soll
- Für wen das Problem gelöst wird (am besten: konkrete Persona)
- Wie Erfolg aussieht
- Welche Daten Annahmen stützen oder widerlegen
- Welche Daten noch fehlen
- Wer die wichtigsten Stakeholder sind
Phase 2: Entdecken
Jetzt haben wir ein besseres Verständnis des Problems. Nun erforschen wir die Lösung. Es geht nicht um das Endergebnis. Es geht um die Breite möglicher Ansätze. Dazu gehören Skizzen auf Papier. Dazu gehört auch das Testen von Annahmen mit schlanken UX-Praktiken.
Mögliche Methoden in dieser Phase:
- Ideen-Workshops mit Stakeholdern
- Skizzen mit Stift und Papier
- Papier-/Lo-Fi-Prototypen
- Frühe Nutzertests von Prototypen und Design
- A/B-Tests
- Schlanke UX-Tests
Am Ende dieser Phase sollte klar sein:
- Welche Ideen und Annahmen nicht gültig sind
- In welche Designrichtung es gehen soll
Phase 3: Verfeinern
Nun ist klar, in welche Richtung es geht. Wir wissen, was funktioniert. Und wir wissen, was nicht funktioniert. Jetzt verfeinern wir die Lösung. Designs werden mehrfach überarbeitet. Dabei hinterfragen wir kontinuierlich unser Denken.
Mögliche Methoden in dieser Phase:
- Mid-/Hi-Fi-Prototypen und Designs
- Iterative Nutzertests
- Feedback-Workshops und Stakeholder-Buy-in
Am Ende dieser Phase muss klar sein:
- Welche Szenarien bzw. welche Customer Journey umgesetzt wird
- Welcher Detailgrad für weitere Validierung nötig ist
- Dass die Dienstleister die Lösungsvorschläge umsetzen können
Phase 4: Umsetzung
Ein großer Teil der Arbeit besteht darin, Entwickler bei der Umsetzung zu begleiten. Während der Entwicklung tauchen neue Fragen auf. Es gibt unvorhergesehene technische Einschränkungen. Oder es entstehen neue Szenarien. Das kann das Ergebnis verschieben.
Die Aufgabe des Designers ist Zusammenarbeit. Gemeinsam mit den Entwicklern finden wir die bestmögliche Lösung innerhalb der Grenzen.
Oft haben auch Entwickler gute Designideen. Diese sollten berücksichtigt und überprüft werden.
Am Ende zählt die Wirkung. Wir lösen ein Problem. Und wir wollen sicherstellen, dass es wirklich gelöst wurde.
Mögliche Methoden in dieser Phase:
- Monitoring der wichtigsten KPIs nach Veröffentlichung
- Nutzertests mit dem finalen Ergebnis
- Befragungen
Am Ende dieser Phase ist klar:
- Ob das Ergebnis erfolgreich war (und warum)
- Wann der nächste Entwicklungsschritt nötig ist
Die Bedeutung der Reflexion
In jeder Phase gibt es viel zu tun. Manches geht schnell. Anderes dauert Wochen oder Monate. Darum ist eine Reflexionsphase am Ende jeder Phase wichtig.
Fragen für die Reflexion:
- Passt die Lösung zu den Unternehmenswerten?
- Passt sie zur Unternehmensvision?
- Passt sie zur Unternehmensstrategie?
- Wurde das richtige Problem gelöst?
- Entspricht der Output den Erwartungen?
Manchmal merkt man erst nach einer Phase: Die Lösung passt nicht zur Vision. Dann muss die Gruppe entscheiden. Entweder weitermachen. Oder pivotieren. Frühes Pivotieren reduziert Verschwendung.
Die Flexibilität, vorwärts und rückwärts zu gehen und zu wiederholen
Das AW Framework ist nicht linear. Phasen können je nach Projekt wiederholt oder übersprungen werden. Wenn eine Phase endet und das Verständnis nicht wächst, lohnt sich eine Wiederholung. Eine Phase kann einen halben Tag dauern. Oder einige Wochen, wenn man tiefer graben muss.
So lässt sich das Framework an kleine und große Projekte anpassen. In agilen Umgebungen wiederholt es sich oft über den gesamten Projektverlauf. Reflexionspunkte dienen dabei als Orientierung. Sie helfen beim Pausieren oder Pivotieren.
Fazit
Wichtig ist, dass alle Beteiligten das Framework verstehen und unterstützen. Es muss zur Arbeitsweise passen. Es geht nicht um einen dogmatischen Prozess, an den sich alle Teams halten müssen. Es geht um ein designorientiertes Framework in einem agilen Projekt. Ziele und Mission dürfen dabei nicht verloren gehen.
Darum muss das Framework über Zeit optimiert werden können. Wie bei jedem Design wird es weiterentwickelt. Auch agiles und designorientiertes Arbeiten entwickelt sich laufend weiter.