Was sollte ein Briefing für einen Website-Relaunch enthalten? Von den Zielen bis zur Übergabe

Ein Anforderungskatalog für den Relaunch einer Website sollte verbindlich und umsetzbar festhalten, warum die Website überarbeitet wird, in welchem Umfang dies geschieht und wie die Leistungen übergeben werden. Unabhängig davon, ob das Dokument als Anforderungskatalog für einen Website-Relaunch oder auf Französisch als cahier des charges refonte site internet bezeichnet wird: Alle Beteiligten sollten anhand derselben Unterlage den Umfang beurteilen, Angebote erstellen, den Zeitplan festlegen und die Abnahmeergebnisse prüfen können. Formulieren Sie zunächst die bestehenden Probleme und Ziele und legen Sie anschließend Seite für Seite die Zuständigkeiten für Seiten, Funktionen, Datenmigration und Veröffentlichung fest.

Ziele und Ist-Zustand klar beschreiben, statt nur eine „Neugestaltung“ zu fordern

Die Ziele des Relaunches sollten sich auf konkrete Geschäftsaktivitäten beziehen, zum Beispiel auf mehr qualifizierte Anfragen, die Veröffentlichung mehrsprachiger Inhalte oder weniger Hürden beim Ausfüllen von Formularen auf Mobilgeräten. Halten Sie für jedes Ziel den aktuellen Stand, die gewünschte Veränderung und die Messmethode fest: Bei Anfragen kann vereinbart werden, dass die nach dem Absenden eines Formulars eingehenden qualifizierten Leads gezählt werden; außerdem sind Regeln zum Ausschluss von Test- und Spam-Nachrichten festzulegen. Liegen keine verlässlichen historischen Daten vor, vereinbaren Sie zunächst, nach dem Launch eine Ausgangsbasis zu ermitteln und einen Beobachtungszeitraum festzulegen, statt unbelegte Wachstumsraten einzutragen.

Im Abschnitt zum Ist-Zustand sollten die aktuelle Website-Adresse, die technische Architektur, die Sprachversionen, die Anzahl der Seiten und die wichtigsten Probleme dokumentiert werden. Fügen Sie außerdem die vorhandene Sitemap, Zugriffsdaten und Screenshots typischer Seiten bei. Sinkende Seitenaufrufe und weniger Anfragen können beide einen Relaunch nahelegen, aber unterschiedliche Ursachen haben: Bei Ersterem sollten Indexierung und Traffic-Quellen geprüft werden; bei Letzterem sind zusätzlich Formulare, Produktinformationen und Nachfassprozesse zu untersuchen. Trennen Sie bestätigte Probleme von noch zu untersuchenden Punkten, damit der Anbieter Annahmen nicht als feststehende Anforderungen behandelt.

Den Umfang abgrenzen: Seiten, Inhalte und Funktionen getrennt aufführen

Führen Sie in einer Seitenliste Seiten wie Startseite, Produktkategorien, Produktdetails, Über uns und Kontakt auf und kennzeichnen Sie, ob sie beibehalten, überarbeitet, zusammengeführt oder entfernt werden. Bei Websites mit vielen Produkten sollten Sie angeben, welche Seiten dieselbe Vorlage verwenden und welche ein individuelles Design benötigen. Listen Sie außerdem die voraussichtlichen Inhaltstypen und -mengen für die Migration auf und legen Sie fest, welche Partei Bilder und Texte aufbereitet. Sind Inhalte noch nicht vollständig, halten Sie den Bereitstellungstermin und den Umgang mit möglichen Verzögerungen im Zeitplan fest.

Bei den Funktionsanforderungen sollten Auslöser und erwartete Ergebnisse beschrieben werden, statt lediglich „Anfragefunktion hinzufügen“ zu schreiben. Beispiel: Nachdem ein Besucher eine Produktanfrage abgeschickt hat, sendet das System eine Benachrichtigung an eine festgelegte E-Mail-Adresse, speichert den Eintrag im Backend und zeigt auf der Seite an, ob der Vorgang erfolgreich war oder fehlgeschlagen ist. Pflichtfelder, Einschränkungen für Anhänge, der Umgang mit Spam und die Benachrichtigungsempfänger müssen ebenfalls abgestimmt werden. Bei einer Anbindung an ein Kundenmanagementsystem sind zudem die Integrationsmethode, die Feldzuordnung, die Testumgebung und die Zuständigkeit für die Schnittstellenwartung festzulegen.

Bei einem mehrsprachigen Relaunch sind die Zielsprachen, der Seitenumfang je Sprache und die Herkunft der Übersetzungen einzeln anzugeben. Automatische Übersetzungen können als Entwurf dienen, doch Produktangaben, Fachbegriffe und Kontaktdaten müssen manuell geprüft werden. Auch ob verschiedene Sprachen dieselbe Produktdatenbank verwenden und Inhalte separat bearbeitet werden dürfen, sollte in den Anforderungen an die Backend-Berechtigungen festgehalten werden. Andernfalls kann die spätere Pflege der Inhalte trotz fertiggestellter Seiten zu Nacharbeiten führen.

Wenn ein SaaS-Website-Baukasten eingesetzt werden soll, sollte der Anforderungskatalog außerdem den Anpassungsumfang der Vorlagen, die Möglichkeiten zum Export von Inhalten, Kontoberechtigungen und den Umgang mit Daten nach Ablauf des Vertrags aufführen. Bei der Bewertung des Yiyingbao SaaS Smart Website Building and Marketing System können beispielsweise die mehrsprachige Bearbeitung, die mobile Optimierung und die Anforderungen an die Backend-Verwaltung einzeln abgeglichen werden. Der konkrete Leistungsumfang richtet sich nach der Projektvereinbarung.

Suchmaschinenmigration und Marketingdaten in den Lieferumfang aufnehmen

Bei einem Website-Relaunch ändern sich häufig URLs. Der Anforderungskatalog sollte daher eine Zuordnungstabelle alter und neuer URLs verlangen und Regeln für beizubehaltende, zusammenzuführende und zu löschende Seiten festlegen. Wo sinnvoll, sind permanente Weiterleitungen einzurichten. Gibt es für eine alte Seite eine passende neue Seite, sollte sie nicht pauschal auf die Startseite weiterleiten. Gibt es keinen Ersatzinhalt, ist die Vorgehensweise gesondert zu vereinbaren. Vor dem Launch müssen außerdem Seitentitel, Beschreibungen, Sitemap, kanonische URLs und Einstellungen für das Crawling durch Suchmaschinen geprüft werden, damit Beschränkungen der Testumgebung nicht auf die Live-Website übernommen werden.

Auch bestehende Analysetools, Conversion-Codes für Werbung und Verifizierungsinformationen für Suchmaschinenplattformen gehören in die Migrationsliste. Für Ereignisse wie erfolgreiche Formularübermittlungen oder Klicks auf Telefonnummern sind Auslösebedingungen und Abnahmemethoden festzulegen; Testdaten und Live-Daten müssen dabei unterschieden werden. Falls die alte Website keine vollständigen Tracking-Daten bereitstellt, sollten zunächst die Verwaltungsrechte für die bestehenden Konten geklärt und anschließend eine Prüfung geplant werden. Allein anhand des Erscheinungsbilds lässt sich nicht feststellen, ob das Conversion-Tracking ordnungsgemäß funktioniert.

Auch Leistungsanforderungen sollten konkrete Testbedingungen enthalten: Testseiten, Gerätetypen, Netzwerkumgebung, verwendete Tools und akzeptable Ergebnisse. Die Ladegeschwindigkeit der Startseite sagt nichts über die Leistung von Produktdetailseiten oder mehrsprachigen Seiten aus. Seiten mit vielen Bildern oder Videos sollten daher separat stichprobenartig geprüft werden. Bei globaler Erreichbarkeit sind außerdem Testregionen und Testzeitpunkte festzulegen; ein einzelnes Testergebnis reicht nicht aus, um die gesamte Nutzererfahrung zu beurteilen.

Zeitplan, Änderungen und Abnahme an konkrete Ergebnisse knüpfen

Der Zeitplan sollte in Phasen mit überprüfbaren Ergebnissen gegliedert sein, zum Beispiel Anforderungsbestätigung, Seitendesign, Entwicklung und Inhaltsmigration, Tests und Launch. Für jeden Meilenstein sind Liefergegenstände, zuständige Personen für die Bestätigung und Rückmeldefristen anzugeben. Werden nach der Freigabe der Entwürfe zusätzliche Seiten oder Änderungen an der Funktionslogik gewünscht, müssen die Änderungen dokumentiert sowie Zeitplan und Kosten neu bewertet werden. So lässt sich vermeiden, dass sich mündliche Änderungswünsche immer weiter summieren.

Die Abnahmekriterien müssen sich durch konkrete Bedienhandlungen überprüfen lassen. Vereinbaren Sie beispielsweise, das Seitenlayout in festgelegten Browsern und auf Mobilgeräten zu prüfen, ein Formular mit einer Test-E-Mail-Adresse abzusenden und den Eintrag im Backend zu kontrollieren sowie migrierte Seiten und Weiterleitungen stichprobenartig zu überprüfen. Fehler sollten nach ihren Auswirkungen erfasst werden: Probleme, die Anfragen verhindern oder Seiten unzugänglich machen, sind anders zu behandeln als Darstellungsprobleme wie Abstände bei Texten. Legen Sie auch fest, wie nach der Fehlerbehebung erneut getestet wird. Die Abnahme muss alle vereinbarten Sprachversionen umfassen und darf sich nicht auf die Startseite in der Hauptsprache beschränken.

Die Lieferliste sollte neben der Live-Website auch Berechtigungen für die Domain und zugehörige Konten, Unterlagen zur Backend-Bedienung, Seiten- und Funktionslisten, eine Weiterleitungstabelle, Testprotokolle und erforderliche Konfigurationsdokumente enthalten. Bei Systemen von Drittanbietern ist der tatsächliche Umfang der Übergabe von Quellcode oder Daten zu vereinbaren. Inhalte, die nicht bereitgestellt werden können, dürfen nicht ohne Weiteres als Liefergegenstände vorausgesetzt werden.

Den Launch so planen, dass ein Rollback möglich ist

Vor dem Launch sind DNS-Einstellungen, Zertifikate, Backups und das Veröffentlichungsfenster zu bestätigen. Für jeden Schritt muss feststehen, wer ihn ausführt und wer ihn bestätigt. Für das Backup der alten Website sind Speicherort, Wiederherstellungsverfahren und Verfügbarkeitsprüfung festzulegen. Falls nach dem Launch Formulare ausfallen oder wichtige Seiten nicht erreichbar sind, müssen die Auslöser für einen Veröffentlichungsstopp, eine Fehlerbehebung oder ein Rollback sowie die Kontaktpersonen vereinbart sein.

Planen Sie nach dem Launch einen Beobachtungszeitraum ein, um den Zugriff auf wichtige Seiten, Benachrichtigungen zu Anfragen, das Crawling durch Suchmaschinen und Conversion-Ereignisse zu prüfen. Die Wartungsbedingungen sollten die Behebung von Liefermängeln von nachträglich hinzukommenden Anforderungen abgrenzen und Kontaktwege, Bearbeitungsabläufe und Fristen festlegen. Nach der Bestätigung durch beide Parteien ist der Anforderungskatalog mit Versionshistorie aufzubewahren; spätere Änderungen richten sich nach der aktualisierten Vereinbarung.