Konzeption

Kick-off

Das erste Gespräch, bei dem die Projektbeteiligten an einen Tisch kommen (heutzutage gerne und ohne »Verluste« auch in einem Videotelefonat). Wir lernen uns gegenseitig kennen und geben dem Projekt einen festen Rahmen. Zudem bestimmen wir die Aufgaben und Ziele mit den Kund:innen, um den gesamten Projektprozess klar vor Augen zu haben. Wir klären, wer die handelnden Personen sind und welche Ressourcen uns zur Verfügung stehen. Auf Basis der Ergebnisse können konkrete Aufgaben definiert und Aufträge/Angebote formuliert werden.

Das Thema Agilität wird schon lange nicht nur durch alle Agenturdörfer getrieben. Wir interpretieren es auch ein wenig freier, als bloß: schnellschnell. Flexibilität muss für uns nicht betont werden. Denn in jedem Moment eines Projektes verändert sich dieses naturgemäß. Die Kunst ist, das richtige Maß aus Freiheit und Strenge zu finden. Den Moment nicht zu verpassen, wo Anpassungsfähigkeit in Wahllosigkeit umschlägt. Von daher braucht auch agiles Denken und Handeln Rahmenbedingungen: Deadlines und Abstimmung, Entscheidungen und verlässliche Meilensteine – die Kund:innen übrigens genauso respektieren müssen, wie die Kreation. Immer auf der Suche nach besser, toller, schöner. Denn das wollen wir auch. Mindestens.

Anders gesagt: Insbesondere größere Website-Projekte sind komplexe Vorhaben, die sich vorab nicht komplett durchplanen lassen. Bedürfnisse können sich ändern, worauf im Projektverlauf gemeinsam reagiert werden muss. Deshalb gilt in unseren Projekten folgendes: 

• Wir arbeiten fortlaufend kooperativ mit dem Projektteam der Auftraggeberin zusammen. 
• An den wichtigsten Themen wird zuerst gearbeitet. 
• Die Umsetzung erfolgt in abgegrenzten Teil-Paketen. 
• Änderungen während des Projektablaufs fließen kurzfristig ein.
• Wir weisen immer möglichst weitsichtig auf alle möglichen Fallstricke hin.

... damit das Projekt fliegen kann. (Soviel Wortspiel muss erlaubt sein.)

Ziel ist es, einen möglichst tief gehenden Einblick in das Unternehmen, seine Kultur, die Arbeitszusammenhänge und in die Welt der Produkte, Lösungen und Leistungen zu gewinnen.

Die Anforderungen aus dem Briefing werden mit den eigenen Verständnis abgeglichen und schriftlich festgehalten. Das Dokument dient zur Abstimmung und ist verbindlich. Beide Seiten verständigen sich so auf die genaue Aufgabe und das Ergebnis des Projekts.

Ja, wir wissen, dass in nicht jedem Projekt ein solcher Anlauf möglich ist. Aber wir werden ja noch träumen können – und sprechen aus Erfahrung. 

User Stories beschreiben die Vielzahl von Anforderungen an ein (digitales) Produkt, indem sie die Frage nach dem WER, WAS und WARUM stellen. 

WER = Nutzer:in

Wenn der:die Nutzer:in im Mittelpunkt stehen soll, müssen wir so viel wie möglich über ihn:sie wissen. Wir entwickeln deshalb Personas, also idealtypische Nutzer:innenbeschreibungen. Wir tun dies allerdings nicht abstrakt, sondern stets bezogen auf das konkrete Produkt. D.h. wir interessieren uns für die Rolle, in der ein:e Nutzer:in z. B. eine Website besucht. 

WAS = Funktion

An dieser Stelle der User Story werden Annahmen darüber formuliert, welche Funktion/Feature Nutzer:innen erwarten.

WARUM = Wert

Hier fragen wir nach Zielen und Motivation der Nutzer:innen in der jeweiligen Situation. Diese Frage erlaubt uns den Kontext zu verstehen und auch Entscheidungen zu treffen, wie hoch die jeweilige Funktion zu priorisieren ist.

User Stories sind also ein hervorragendes Werkzeug, insbesondere in Fällen, wo eine große und diverse potentielle Nutzerschaft existiert und es dementsprechend viele Anforderungen gibt. Über User Stories lassen sich diese Anforderungen sehr einfach herunter brechen und in zu entwickelnde Funktionalitäten übersetzen. Dabei ist sichergestellt, dass nichts vergessen wird – von der übergeordneten Informationsarchitektur bis zur Barrierefreiheit. 

Um User Stories zu entwickeln machen wir kollaborative Workshops. Die Zusammensetzung kann immer wieder unterschiedlich sein, je nachdem, um welche Nutzergruppe es sich handelt. 

Um User Stories zu dokumentieren, nutzen wir gerne die Tools von Atlassian. Über das Ticketsystem »Jira« und das Kanban-Board »Trello« lassen sich die Aufgaben optimal verwalten und zwischen den beteiligten Gewerken (Konzept, Design, Programmierung) abstimmen. Siehe auch. 

Brainstorming

Zu Beginn des Konzeptionsprozesses muss ein ordentliches Brainstorming erlaubt sein.

Grundidee

Hier gilt es, die Idee eines Projektes für alle Beteiligten nachvollziehbar auf den Punkt zu bringen. Für wen ist die z. B. die Website gedacht, was leistet sie, was macht sie besonders? Beispiel: »uncubemagazine.com combines the ease of the internet with the sensibility of print.«

Basiskonzept

Sind die Inhalte und Funktionen festgelegt, beginnt die Arbeit am Basiskonzept.  Es bringt die Inhalte in eine Struktur und legt die Grundlagen für die Benutzerführung oder Kommunikationsaufgaben. Dargestellt wird das z. B. in Form einer Sitemap. 

Feinkonzept 

Im Feinkonzept werden alle Bestandteile und Inhalte/Funktionen ausführlich beschrieben. Wenn das Projekt dies erlaubt. Die Herausforderung dabei: Es muss so spezifisch formuliert sein, dass z. B. Designer, Redakteure und Programmierer genau wissen was zu tun ist – und bei der Umsetzung keine eigenen konzeptionellen Entscheidungen treffen müssen. Und es muss allgemeinverständlich sein, denn häufig ist das Feinkonzept Vertragsgrundlage und wird abgenommen.

Technisches Konzept 

Nehmen wir erneut den komplexen Fall einer Website an, ist ohne technisches Konzept kein Projekt möglich. Es beschreibt alle Anforderungen und Umsetzungsentscheidungen zu Serverarchitektur, Redaktionssystem, Datenstruktur, Verwaltung von Benutzerrechten, Browserkomaptibiltät und Barrierefreiheit. Bei einem Website-Relaunch wird zusätzlich das Vorgehen bei der Migration der Inhalte von der alten zur neuen Seite beschrieben. 

Redaktionskonzept 

Viele von uns bei Henkelhiedl haben einen redaktionellen Hintergrund und wissen: Über ein schlecht konfiguriertes Content Management System oder eine halbgare Kommunikationsstrategie kann man sich als Redakteur wahnsinnig ärgern – täglich und über viele Jahre. Deshalb bemühen wir uns in der Konzeption immer mit zu denken, wie die Inhalte im Backend so strukturiert werden können, dass die Webseite im späteren Einsatz leicht zu bedienen ist. Das spart Nerven, Zeit und Geld. 

Sprints 

Im (Design) Sprint geht es darum, schnell und pragmatisch einen Produkt-Prototypen zu erstellen und diesen mit Nutzern zu testen. Der Hintergedanke dabei ist, dass vorgelagerte Forschung und abstrakte Analysen wenig bringen, sondern dass Erkenntnisse darüber, was funktioniert und was nicht, erst anhand eines konkreten Produktes möglich sind. Dieses Vorgehen kann viel Zeit sparen, oft verstrickt man sich aber in Details, nur um dann festzustellen, dass das Endprodukt vom Benutzer nicht den eigenen Vorstellungen entsprechend angenommen wird. Design Sprints sind nicht in jedem Projekt geeignet. Wo es sinnvoll anwendbar ist, lässt sich u. a. hier ermitteln.  

Design Sprints bestehen im Allgemeinen aus fünf Phasen:

Tag 1: Verstehen

Am ersten Tag gilt es, das Problem beziehungsweise die Aufgabenstellung für alle Beteiligten möglichst klar aufzuzeigen. Hier kann ggf. auf Erkenntnisse aus der Strategiephase zurückgegriffen werden.

Tag 2: Lösungsansätze finden

Es werden viele verschiedene Ansätze für die Problemlösung gesucht. Dabei arbeiten zunächst alle für sich.

Tag 3: Entscheiden

Jetzt müssen durch ein Voting im Team die besten Ideen ermittelt und eine User-Story herausgearbeitet werden. 

Tag 4: Prototypen

Am vierten Tag entstehen Prototypen des Produktes, die später Benutzern vorgeführt werden können. Das bestgeeignete Tool hierfür ist Keynote.

Tag 5: Überprüfen

Am fünften Tag wird der Prototyp »echten« Nutzern vorgeführt, um herauszufinden, welche der Ideen tatsächlich funktionieren und welche nicht.

Wie im Bereich Strategie geschrieben gilt natürlich:

Werkzeuge, Mechaniken, Workshops, Interviews, ... die Liste der Dinge, die es braucht, um »sauber und ordentlich« zu guten Ideen aka Konzepten zu kommen, ist lang. Alle Bestandteile haben ihre Berechtigung und die Flughöhe des Projekts bestimmt oft den Anlauf. Bei allem Handwerk und gebotener Sachlichkeit können wir aber vor allem auch eins: aus dem Stand (ziemlich hoch) springen. 

»Hallo, was ist das Anliegen? (...) Alles klar, so wird's gemacht.«

Wer sich auf uns einlässt, lässt viele Wege zu, die am Ende aber immer nach Rom führen. (Wofür Rom steht, darauf weisen wir jetzt nicht gesondert hin.) Anders gesagt: Der Weg ist das Ziel und wir bestimmen den Weg gemeinsam mit unseren Kund:innen. 

Los geht's!