Relaunch: Konzepte, Erfahrungen und was wir daraus gemacht haben

Technisch gesehen darf eine moderne Website sicherlich ziemlich vieles leisten und noch viel mehr muss sie unbedingt können — zumindest wenn man seine Stakeholder darum bittet, kurz zu notieren, was sie sich für ihre neue Website gerne wünschen. Und wer sich allzu naiv auf ein Wunschkonzert einlässt, wird auch genau das bekommen.

Die Notwendigkeit kennt keine Gründe.

— Ernst Curtius

 

Natürlich geht das alles auch professioneller, zum Beispiel indem man damit anfängt, nicht nur die Anforderungen an eine Website aufzunehmen, sondern gleich auch den Nutzen der einzelnen Feature mit dokumentiert und idealerweise eine Auflistung nach Aufwand und eben Geschäftswert aufsetzt, die einem beim Priorisieren hilft.

Da wir just unsere eigene Website (mayflower.de) neu aufgesetzt haben — und das intern sogar mehrfach neu, aber dazu später mehr — möchten wir ein paar unserer Ideen und Konzepte hinter dem Relaunch teilen. Schließlich ist kein Kunde so hart wie das eigene Team, und wenn unsere Erfahrungen dabei helfen, künftig vergleichbare Projekte einen Tick effizienter zu gestalten, dann wäre das doch sehr schön. Dazu möchte ich auf mögliche Seitenkonzepte eingehen, erklären, welche Funktionen wir für ein erstes Release zusammengestellt haben — und weshalb überhaupt so ein „erstes Release“ — und welche Plattformentscheidungen mit in das Projekt eingeflossen sind.

Seitenkonzepte

Was ist denn das, was eine moderne Website wirklich können muss? Ein paar grundlegende Kategorien zur Einordnung:

Legal & Standards

Die Art von Seiten, um die man nicht herumkommt, wie Startseite, Impressum und Geschäftsbedingungen.

Stars & No-Brainer

Diejenigen Seiten, die die Leser bisher im Wesentlichen aufsuchen. Ein Blick in die Nutzerstatistiken hilft, diese Seiten zu identifizieren. Dabei sollte man sich die Zeit nehmen zu bewerten, ob es auch tatsächlich einen Nutzen bringt, die entsprechenden Inhalte auch auf der neu zu entwickelnden Seite weiter anzubieten. In unserem Fall waren das Beispielsweise unsere Stellenanzeigen, Seiten für Posterbestellungen (unsere kostenfreien Symfony2– und Zend-Framework-Poster und der aktuelle Teamkalender). Auch unsere Webinare werden wir wieder anbieten, technisch bedingt sind die derzeit noch zurückgestellt.

MUST HAVE

Darunter fällt dann alles, was für den geschäftlichen Nutzen der Seite wesentlich ist. Beispielsweise bieten wir bei Mayflower unseren Kunden agile Softwareentwicklung an, benötigen also Detailseiten für eben diese Services.

Letztlich sind wir für eine minimale Website auf einen Bedarf von etwa 14 Seitentypen gekommen, für die wir Design & Layout, Entwicklung und Inhaltserstellung einplanen mussten.

Konzeptionelles

Zugegeben, die bis hier beschriebenen Schritte sind der einfache Teil und im Grunde genommen die Fleißarbeit. Da kann man sich durcharbeiten und am Ende hat man halt eine Website, die irgendwie auch online gehen kann. Nur erwarten wir uns natürlich mehr. Intern muss die Seite (und auch das ganze CMS hintendran) leicht wartbar sein.

Technisch benötigen wir hier eine einfache Architektur, die sich mit möglichst wenig Entwickleraufwand administrieren, erweitern und pflegen lässt. Weil Entwickler als Ressource teuer sind. Für die Seiteninhalte muss ein leicht zugängliches Interface zur Verfügung stehen — weniger, um die Einarbeitungszeit für die Redakteure zu minimieren, vielmehr um Fehler beim Jonglieren mit den zahlreichen Inhaltstypen und Content-Einstellungen zu reduzieren.

Und konzeptionell müssen wir ebenfalls ein paar Überlegungen anstellen. Ja, die Sache mit den Personas (dabei werden Annahmen und gesammelte Erkenntnisse zur Zielgruppe formal aufbereitet; nette Ressourcen für die Durchführung gibt es u.a. unter tactiledesignkit.com) ist wichtig, damit das Team versteht, für wen es seine Seiten entwickelt und auf welche Interessen es dabei Rücksicht nehmen muss. Am Ende zählt aber auch die ganz banale Realität, und der erste Schritt muss es sein, den Leser auf seine Seite zu bekommen. Und das sind nun einmal Inhalte. Und zwar aktuelle.

Beispielsweise hatten wir in der Vergangenheit durchaus viele solcher Inhalte auf unserer Website zu bieten. Da hatte praktisch jedes für die Softwareentwicklung relevantes Thema seine eigene Seite. Statisch und höchst offiziell mit allen relevanten Stakeholdern abgestimmt, und mit einer Reihe von Nachteilen: Es hat Tage gedauert, bis ein Themenvorschlag durchgewunken wurde, Wochen, bis alle Inhalte zusammengetragen und feingeschliffen wurden und mit Seiten als Ergebnis, die bei Erscheinen schlichtweg am aktuellen Tagesbedarf vorbeigeplant waren. Die dann auch kein Leser mehr gesucht hat — weder bei Google, noch in unseren überbordenden Menüs on Site.

Die besten Inhalte nützen also nichts, wenn wir sie nicht auch verwerten können. Inhalte schaffen erst dann einen Wert (und damit ein gutes Preis-Leistungsverhältnis was ihre Erstellung angeht), wenn sie auch gelesen werden. Und dazu braucht es aktuelle Texte, die sich aktuellen Themen annehmen, die unsere Zielgruppe beschäftigen. Es braucht aber auch eine Infrastruktur, die diese regelmäßigen Artikel ermöglicht, ohne unsere Menüs (oder sonstige Übersichtsseiten) zu überfrachten. Zum Glück gibt es auch dafür eine einfache Antwort — sie nennt sich Blog.

Unternehmensblog

Ja, ein Corporate Blogging muss her. Nicht etwa, weil die Marketingstrategen sagen, dass wir hier die bessere Kontrolle über unsere Inhalte haben. Sondern ganz einfach, weil wir nur so an relevante Leser kommen (das sind die, die sich zum einen für unsere Aufgabenfelder interessieren und zum anderen auch diejenigen, die feststellen, dass unsere Dienstleistungen zufällig genau ihren ganz aktuellen Bedarf erfüllen).

Was in der Theorie sehr einleuchtend klingt, muss in der Praxis dann aber noch weitere Klippen umschiffen. „Aber wir haben doch schon ein Blog. Warum denn jetzt noch eines?“ Ich möchte das erklären. Ja, es trifft zu, dass unsere Kolleginnen und Kollegen fleißig bloggen. Und damit mehr Leser im Monat begeistern, als unsere Firmenseite im ganzen Jahr. Nur ist hier halt zwar sehr guter, aber eben auch sehr technischer Content zusammengetragen, der oft weit in die Details geht und, nun, Entscheidern ein hohes Maß an Zeit abverlangt, sich einzulesen. Oder anders gesagt: Die Angestellten unserer Kunden finden sich super in unserem Blog zurecht, für die Entscheider fehlen aber an anderer Stelle — nämlich unserer Unternehmensseite — die relevanten Inhalte.

Und hier wird es jetzt etwas kompliziert. Denn natürlich …

• möchten wir unserem bestehenden Blog keine Konkurrenz machen.
• finden wir es super, dass unsere Fachkollegen auch weiterhin technisch anspruchsvolles Know-how in der nötigen Tiefe vermitteln.
• wollen wir sicherstellen, die Inhalte für unsere neue Website auch liefern zu können.

Gerade der letzte Punkt ist kritisch, denn schließlich sind wir kein Fachverlag, der Artikel mal eben aus dem Ärmel schüttelt, sondern IT-Dienstleister, der sich in erster Linie auf seine Kundenprojekte konzentriert. Wir können daher nicht garantieren, in jedem Fall zeitnah die Ressourcen zu haben, zusätzlich noch auf einem weiteren Kanal zu bloggen. Hier gegenzusteuern muss ein wichtiges Ziel in unserer Content-Strategie sein. Und dazu benötigen wir technisch eine Plattform, die allen Beitragenden möglichst wenige Hindernisse in den Weg stellt — womit sich dann auch der Kreis hin zu unserer technischen Plattform der neuen Seite schließt.

Drupal, WordPress, ganz etwas anderes?

Nur eine Seite die läuft, bringt auch einen Nutzen.

— Ich.

 

Über die Plattformentscheidung mag man jetzt streiten. Oder wird es sogar in jedem Fall tun; wir haben in der Hinsicht einiges durchmachen dürfen;-) Ich will mich hier nicht für das eine System aussprechen, aber vielleicht einige der Kriterien nennen, die letztlich für unsere individuelle Entscheidung maßgebend waren. Für uns ausschlaggebend:

• die zur Verfügung stehenden Entwicklerressourcen
• die Wartbarkeit des Systems
• seine Zukunftssicherheit und vor allem seine leichte Erweiterbarkeit
• die Zugänglichkeit des Systems für Redakteure/Content-Lieferanten

Anfangs wollten wir mit Drupal arbeiten. Es ist eines der größeren Systeme, mit dem unsere Entwickler viel Erfahrung haben und bei dem uns daher in der Theorie ausreichend Ressourcen zur Verfügung standen. In der Praxis wird das System jedoch vom Marketing betreut und zu der Zeit war unsere Ressource genau ein Entwickler (der aber auch für viele weitere vitale Systeme in unserem Ressort zuständig war). Ressourcen schieden als Argument daher aus.

Wartbarkeit. Nun, als Entwickler kann man sich in Drupal austoben, das System ist wartbar und konfigurierbar — und in der Praxis derart mit vorzukonfigurierenden Einstellmöglichkeiten überfrachtet, dass es ab einer gewissen Projektgröße einfach keinen Spaß mehr macht, weil man sich fast zwangsweise Abhängigkeiten einhandelt, die technisch zwar zu bewältigen sind, uns im Team aber massiv Einbußen an der Flexibilität abverlangt haben. Wenn man die nicht benötigt, weil man ein bestehendes System mit definierten Aufgaben pflegen möchte, geht das in Ordnung. Wenn man sich aber vom Scratch erst über verschiedene Optionen an eine erste Lösung herantasten will, wird es schmerzhaft.

Und was die Zugänglichkeit für Redakteure betrifft — nun, auch für Drupal lassen sich geeignete Benutzerschnittstellen entwickeln. Das muss man dann allerdings auch einkalkulieren, per Default hat Drupal ein sehr nacktes Backend. Hier sind Entwicklerressourcen erforderlich, die wir eigentlich lieber in die Anpassung des Templates gesteckt hätten.

Aus ganz praktischen Erwägungen haben wir uns daher entschieden, die laufende Entwicklung an Drupal einzustellen und auf WordPress zu wechseln. Ja, es gab einen Aufschrei unter den Development-Kollegen, das System sei doch nicht sicher. Und skaliert bestimmt gar nicht. Das mag in der Theorie auch alles stimmen, in der Praxis hatten wir jedoch ein Drupal über Jahre fast ungepatcht im Einsatz, weil wir vor lauter Abhängigkeiten und knapper Ressourcen und Business-Value-Erwägungen schlichtweg nie zum Testing & Deployment neuer Updates kamen. WordPress hat wie jede Software auch ihre Schwachstellen und der Code ist unschön und vielleicht (warum hält sich das Gerücht eigentlich so hartnäckig?) skaliert es nicht. Aber bis dieser theoretische Fall eintritt, bekomme ich zügige Updates, die ich ohne Bauchschmerzen einspielen kann und vor allem: das System läuft. Wer ihm das erlaubt hat, ist mir selbst dann gar nicht mehr so wichtig. ;-)

Ergebnis

Harte Plattformentscheidungen wurden getroffen. Hürden für die Content-Ersteller wurden abgebaut und die Leser werden nicht mehr mit einem Bauchladen veralteter Themen überfrachtet. Unsere Seite ist nicht fertig, aber wir sind in der Lage, sie kontinuierlich und mit nur wenigen Personalressourcen weiterzuentwickeln. Sicher ist die Seite nicht perfekt, aber sie ermöglicht es uns, weiter nach Perfektion zu streben. Und zwar nicht nur akademisch auf dem Reißbrett, sondern eben im laufenden Betrieb. Was unserer agilen Vorgehensweise übrigens sehr entgegenkommt: Wir bringen ein erstes Produkt auf den Markt, das auch bereits Nutzen bringt; schauen dann, was funktioniert und was verbessert werden kann und entwickeln das System mehr oder weniger nebenbei iterativ weiter. Die Kennzahlen deuten bereits nach zwei Monaten darauf hin, dass unsere Leser das Konzept auch annehmen.