Content Konzeption
Mid-Fi Wireframe
Erstellung der relevanten Contentpages // App Screens als klassische Mid-Fi Wireframes oder unter Verwendung der bestehenden visuellen Modul-Konzepte aus dem PatternLab-Projekt. Zusätzlich mit Beigelung der verwendeten Contentelemente und unter Verwendung von echtem oder realistischem Inhalt für eine belastbare inhaltliche und formale Beschreibung von Seiten für die technische Konzeption bzw. als Contentpflegevorlagen.
Beschreibung der Methode
Worum geht es?
Unter “Content Konzepte” verstehen wir visuelle Darstellungen von beispielhaften Contentseiten des geplanten Projekts (Webportal oder App). Dabei wird mit verschiedenen grafischen Mitteln der Inhalt und die Funktionsweise der zu erarbeitenden Contentpage dargestellt und mit dem Kunden und dem Projektteam abgestimmt.
Die Ausbaustufe “Mid-Fi” ist die in Projekten gängigste Methode um eine größere Anzahl an Seintenkonzepten bei vertretbarem Aufwand zu erstellen, hier werden entweder Standard-Wireframes von Modulen oder auch die bereits erstellten visuellen Konzepte zu geplanten Modulen kombiniert – was die Erstellung dieser Seitenkonzepte schnell aber dennoch formal und inhaltlich belastbar und konkret macht. Das Ergebnis sind klassische Wireframes bzw. anonymisierte Seiten unter Verwendung fertiger Modultemplates die auch hier in der Dokumentation mit Benennung der Module und einer inhaltlichen Beschreibung des einzupflegenden Content versehen werden können.
Worin liegt der Nutzen für das Projekt?
Das Ziel dieser Content Konzepte kann unterschiedlich sein, auch je nach dem ob diese schon in der Visionsphase zu Beginn erstellt werden (Klassisches Grundkonzept per Wireframing z.B. zur Identifizierung von sinnvollen Seiteninhalten) oder nach Entwicklung der Contentmodule zum Ende der Umsetzungsphase bzw. Beginn der Contentpflegephase unterstützend (Contentpflegevorlagen).
Achtung, in der Ausbaustufe “Mid-Fi Wireframes” ist es sinnvoll entweder in der Frühphase des Projekts auf unsere Modul-Standards zurückzugreifen oder in der späteren Phase im Projekt die erstellten visuellen Modulkonzepte zu nutzen.
Gibt es Abhängigkeiten?
Idealerweise werden je Seitentyp der zu konzipieren ist der Inhalt mit dem Kunden abgestimmt und dieser liefert die verfügbaren oder gewünschten Inhalte in grober Form vor.
Falls diese nicht vorliegen, kann je Ausbaustufe auch mit Platzhalterinhalten oder vorschlagenden Inhalten für eine stimmige Seitenstruktur und Didaktik für eine gute UX gearbeitet werden – der Kunde (oder Contententwickler) erhält so eine Vorlage für ggf. neu zu entwickelnde Pflegeinhalte.
Auch ist es sinnvoll, eine abgestimmte Informationsarchitektur zu haben und die Hauptanforderungen und Zielgruppeneinblicke mit in die Entwicklung von Seitenkonzepten einfließen zu lassen.
Zielbeschreibung
Was soll an Erkenntnis erarbeitet werden?
In der Ausbaustufe “Mid-Fi” wird in klassischer Wireframingform gearbeitet, um schnell belastbare Seiten, Module und Inhalte entwickeln zu können. Dabei soll aus Aufwandsgründen und unter Berücksichtigung unseres Standardisierungskonzepts für Module und Basics unser Standards-Set für Module genutzt werden.
Alternativ kann diese Konzeptphase erst spät im Projekt erfolgen, wenn die meisten Contentmodule für die technische Umsetzung bereits erstellt sind und als offene Grafikdateien verwendet werden können um Contentseiten zusammenzustellen.
Typischerweise wird hier immer der Desktop-MediaQuery genutzt (aus Kundensicht besser bewertbar), es kann aber auch durchaus Mobile-first gearbeitet werden. Eine Content Konzeption über mehrere Mediaqueries hinweg ist möglich und ggf sinnvoll, aber auch aufwändiger.
Kreative Klärung der für das Projekt sinnvollen Inhalte und Funktionen auf grober Inhalts- und Anforderungsbasis ohne Anspruch auf Design-Feinheiten → sind Inhalte vorhanden, wo fehlen die, die wichtig sind und woher können diese kommen?
Definition der auch technischen Funktionsweisen und Anforderungen an die entwickelten Seitenkomponenten (auch Pflegemechanik, Komplexitäten, Inhalte) → wie werden Module im CMS gepflegt? Wo redaktionell, wo automatisiert, wo kommen Schnittstellen zum Einsatz?
Klärung ob alle identifizierten Seitenkomponenten sinnvoll sind oder ob manche für einen schlanken MVP weggelassen werden können oder noch fehlen → werden alle gewünschten Features und Module wirklich gebraucht? Gibt es Einsparungspotenzial? Wie oft werden komplexe Unique Module wirklich gebraucht und lohnt sich der Entwicklungsaufwand oder kann auf Standards zurückgegriffen werden?
Zur Erstellung sinnvoller und didaktisch gut funktionierender (und convertierender) Contentpages als Contentpflegevorlage und unter Verwendung der im Projekt vorgesehenen Contentelemente (Pflegevorlagen), auch zur Vorgabe für die Entwicklung von Pflegecontent und -assets. → Support der Contentpfleger bei der Auswahl der richtigen Module für den zu pflegenden Inhalt, sinnvolle Strukturierung in Sections, Einbettung von Cross- und UpContents.
Wofür ist dies wichtig?
Vorgehensweise
Welche Vorarbeiten sind notwendig?
Idealerweise ist die Informationsarchitektur in einer ersten validen Form ausgearbeitet und kann als “Spielplan” für die Inhaltsentwicklung genutzt werden. Auch sind die Zielgruppen bekannt und es wurde auch schon über Bestandsinhalte, neue Inhalte und die Möglichkeiten hinsichtlich von Medienformaten gesprochen.
Auch sind anzubindende externe Inhalte oder Datenschnittstellen zumindest bekannt und können berücksichtigt werden.
Ein Einblick in die gegebenen und geplanten Inhalte ist vorhanden und kann auch mit den Standard-Modulen großteils abgeglichen werden. Ein Scope für Unique neue Module ist grob machbar und im MVP Rahmen abbildbar.
Für die Ausbaustufe “Mid-Fi” kann auf die Modul Standards zurückgegriffen werden, Unique neue Module wie auch Globals müssen als Wireframes neu skizziert werden. Dies ist sinnvoll, da diese sowieso hochgradig individuell sind und sich aus Informationsarchitektur bzw. Anforderungen neu ergeben.
Inspiration aus anderen Projekten ist hier ausdrücklich erwünscht.
Wie wird der Inhalt erarbeitet?
Mid-Fi Wireframes mit realistischem/echten Textelementen, aber ohne das fertige Corporate Design einer fertigen Seite. Es wird ein Eindruck über die inhaltliche Didaktik vermittelt, jedoch kein Look & Feel – der Fokus liegt rein auf Usability und Inhalt (Text).
Im Ticketshaping kann direkt auf die verwendeten Contentmodule, Headlines und Sections eingegangen werden und als konkrete Contentpflegevorlage genutzt werden (zu ergänzen um ECHTEN Inhalt durch den Kunden).
Ausnahme:Falls im Projekt bereits visuelle Umsetzungs-Konzepte für Module vorliegen, können diese natürlich anstelle “echter” Wireframes verwendet werden.
Module werden als Wireframes oder anonymisierte visuelle Konzepte eingebunden, auf Basis eines BRP. Positionierungen und Inhalte sind schon realistisch.
Module werden benannt und fließen in den Projektscope ein
Absprünge werden erwähnt
Inhalte können in der Dokumentation mitbeschrieben werden
Erstellbar im Grafiktool
Erweiterbar zum Klickdummy
Es entsteht ein guter Eindruck für echte Module, Inhalte und Funktionalitäten ohne auf Details wie Abstände und visuelles Design zu achten.
Das Mid-Fi Modell sollte realistischen Inhalt nehmen wo echter Inhalt nicht verfügbar ist und kann als Pflegevorlage dienen. Ein Anspruch auf die Entwicklung komplett echter Pflege-Inhalte (auch Bildmaterial) besteht hier nicht.
Wann macht ein Kundenworkshop Sinn?
In der Mid-Fi Variante können komplette Seitentypen in Workshops allenfalls grob anskizziert werden - das klappt durchaus schon mit einfachen “Handskizzen-Wireframes” je nach Zeichentalent der Teilnehmer. Es kann durchaus in einer gemeinsamen Session, z.B. auch zur Erarbeitung von User-Flows auf das gemeinsame Anskizzieren von Situationen zurückgegriffen werden, bedarf aber immer einer Aufarbeitung und Dokumentation im Nachgang. Ein Schulterblick oder eine Abstimmung mit dem Kunden kann gesammelt aber durchaus in Workshopform behandelt werden.
Ist diese Methode ein Pflichtinhalt für Projekt-Visionsphasen?
Eine der hier behandelten drei Ausbaustufen muß zumindest für die wichtigsten Seiten (aus technischer, didaktischer, conversions- oder kreativer Sicht) durchgeführt werden. Die Erfahrung zeigt, dass ein Grundstück schon in der frühen Konzeptphase (Visionsphase) geschehen sollte, um auch dem Dev-Team ein besseres Gefühl für die Anforderungen der im Backlog gesammelten Module und Seitenfunktionen zu liefern - nicht zuletzt auch um sinnvolle Akzeptanzkriterien für das Front- und Backend entwickeln zu können.
Auch kann eine umfängliche Vorkonzeption aller Seiten in visueller Form im Projektprozess bei der Priorisierung und Steuerung der Sprints helfen (Sprintplanung, Priorisierung von Tickets nach Contentpflegezielen oder technischen Anforderungen)