In den Anfängen der Implementierung von Web-Content-Management-Systemen (WCMS) war die Gestaltung der Benutzeroberfläche keine oberste Priorität. In der Vergangenheit wurde diese hauptsächlich von einem Entwickler erstellt, ohne dass dieser viel Rücksprache mit den eigentlichen Content-Autoren hielt. Content-Authoring wurde vielmehr als ein technischer Ablauf betrachtet, der in den meisten Fällen durch einen Webmaster mit technischem Hintergrund durchgeführt wurde. Das Ergebnis gestaltete sich in Form einer Benutzeroberfläche, der es für Autoren, wie z. B. Marketingexperten, an Benutzerfreundlichkeit fehlte.
Über die Jahre hinweg bot das WCM-System mehr und mehr Möglichkeiten, benutzerfreundliche Oberflächen zu erstellen. Der hauptsächliche Grund dafür liegt im Bearbeitungsprozess von Content an sich – er hat sich verändert. Heutzutage wird die Bearbeitung von Content nicht mehr von einem einzelnen, technisch versierten Webmaster abgewickelt. In den meisten Unternehmen findet man nun (dezentralisierte) Teams nichttechnischer Autoren, die in der Erstellung von Marketinginhalten spezialisiert sind und das System tagtäglich umfassend nutzen. Daher wird deutlich, dass das Nutzererlebnis des Authoring-Backend so optimal wie das Nutzererlebnis der Website selbst werden muss.
Heutzutage kann behauptet werden, dass der Erfolg eines WCMS-Projekts nicht rein vom Besuchererlebnis abhängt, sondern ebenso von der Autorenerfahrung des Content-Teams. Wir haben allerdings auch beobachten müssen, dass die Autorenerfahrung während der Projektplanungsphase einer Website nicht immer berücksichtigt wird. Der Grund dafür liegt in der falschen Annahme, dass die Verwendung eines bekannten WCMS wie Adobe Experience Manager (AEM) oder Drupal automatisch ein optimales einsatzfertiges Erlebnis liefert.
In Wahrheit ist das nicht zwangsläufig der Fall, da verschiedene Organisationen, Content-Teams und Website-Typen ganz unterschiedliche Anforderungen vorweisen. Zweifellos bieten diese WCMS eine standardmäßige Autorenoberfläche mit Authoring-Tools, um die Seiten einer Website zu organisieren und zu editieren, Assets zu verwalten, usw. Was aber die meisten Webteams eigentlich brauchen, ist eine besondere Entwicklung ihres WCMS, um die eigentlichen Inhalte zu verwalten, die auf den Webseiten dargestellt werden.
WCMS-Plattformen ermöglichen es Entwicklern, eben diese angepassten Oberflächen zu erstellen. Das geschieht durch einem Set an (technischen) Bausteinen verschiedener Flexibilitätsstufen. Welche dieser Bausteine zusammengefügt werden, ist allerdings nicht vordefiniert. Die Auswahlmöglichkeiten erscheinen auf den ersten Blick einfach, gestalten sich in Wahrheit aber als ziemlich kompliziert. Ist eine funktionale Komponente wie ein Video auf einer Webseite vordefiniert oder nicht? An welcher Stelle können die Eigenschaften der Komponente verwaltet werden? Und an welchen Teilen der Seite werden diese hinzugefügt?
Wie bei der öffentlichen Oberfläche der Website ist das auch der Grund, warum für besondere Aspekte der Autorenoberfläche des WCMS eine Definierung des Nutzererlebnisses nötig ist. Diese Phase auszulassen, führt mit hoher Wahrscheinlichkeit zu einer schlechten Autorenerfahrung und wird sich auch auf die Erwartungen der Besucher und den allgemeinen Erfolg der Website auswirken.
Bei ACOLAD halten wir im Rahmen unserer Analysephase fest an der Autorenerfahrung, da sie schlicht unerlässlich ist. Wenn die funktionalen Spezifikationen jeder einzelnen funktionalen Komponente einer Webseite definiert werden (z.B. Content-Banner), stellen wir immer sicher, dass diese aus verschiedenen Perspektiven betrachtet wird. Zum einen aus der Besucherperspektive – wir beschreiben im Detail, wie die Komponente präsentiert wird, wie diese sich verhalten wird und welche Interaktionen mit ihr möglich sein werden.
Zum anderen werfen wir ebenso einen Blick auf die Komponente aus der Autorenperspektive. Vor der Implementierung werden die Spezifikationen der Autorenoberfläche umfassend mit den Stakeholdern des Projekts besprochen. So wird garantiert, dass das Autorenteam Input und Feedback liefern kann. Falls sie relevant sind, werden ebenfalls Wireframes erstellt, um das Verhalten der WCMS-Oberfläche klar und deutlich zu veranschaulichen, wie bei den Webseiten. Typische Fragen, die während dieser Sitzungen besprochen werden, sind:
- Welche Eigenschaften einer funktionalen Komponente werden benötigt? Welche können durch einen Autor editiert werden, welche werden automatisch durch das System verwaltet?
- Wie und wo wird der Content-Autor die Eigenschaften einer Komponente verwalten können?
- Welcher Name kann für die Komponente eines Systems verwendet werden, damit nachvollzogen werden kann, wofür diese Komponente gedacht ist?
- Gibt es Komponententypen, denen wir Musterinhalte hinzufügen sollen, um die Arbeit der Content-Autoren zu erleichtern?
- Sind die Inhalte klar strukturiert, damit es für Webteams einfacher ist, ganze Contentbausteine wiederzuverwenden?
- Folgen die Webseiten einer strengen Struktur oder ermöglichen sie den Autoren mehr Freiheit? Wie viele verschiedene Webseitentypen werden benötigt? Normalerweise führen weniger Auswahlmöglichkeiten zu einheitlicheren Inhalten, was zu weniger Verwirrung führt.
Fazit
Teams von Webprojekten sind oft so sehr auf das Endergebnis einer Website und das Nutzererlebnis konzentriert, dass die Authoring-Erfahrung in den Hintergrund gerät. Tatsächlich ist einer der wesentlichen Erfolgsfaktoren einer Website die Anzahl der Besucher – und diese Zahl hängt wiederum vom Erfolg des WCMS ab.
Ein benutzerfreundliches WCMS, das einfach und schnell zu erlernen ist und es sogar nichttechnischen Profilen ermöglicht, effizient zu arbeiten. Im Gegenzug werden die Schulungskosten der Autoren reduziert, eine häufigere Aktualisierung der Inhalte ermöglicht und die langfristige Rentabilität des WCMS gewährleistet.
Updated