Der Kunde sagt, er brauche eine Website. Das klingt nach einer konkreten Anfrage, ist es aber nicht. Es ist noch nicht klar, warum die Website überhaupt benötigt wird, wem sie helfen soll, was sie im Unternehmen verändern soll oder woran wir erkennen werden, dass sie ihre Ziele erreicht hat. „Ich möchte eine Website“ ist der Beginn eines Gesprächs, keine Spezifikation.

Der Kunde muss kein Webentwickler sein. Er kennt sein Geschäft, seine Kunden und seine Probleme, aber er muss nicht die Zusammenhänge zwischen Inhalten, Benutzerfreundlichkeit, Barrierefreiheit, Performance, SEO, Infrastruktur und der späteren Wartung verstehen. Und er sollte auch nicht so tun. Die Aufgabe des Entwicklers ist nicht, jede Anfrage gedankenlos in Code umzusetzen. Es geht darum, das Geschäftsziel zu verstehen, es in Anforderungen zu übersetzen und dem Kunden die Konsequenzen der verschiedenen Optionen zu erläutern.

Daher ist das Vorgespräch zur Website-Erstellung keine reine Verkaufsformalität. Es ist der erste Schritt im Designprozess.

Der Kunde beschreibt die Lösung, aber Sie müssen das Problem herausfinden

Ich habe dieses Prinzip schon oft beobachtet: Der Kunde weiß noch nicht genau, was er will. Manchmal hat er nur eine vage Vorstellung. Manchmal zeigt er die Website eines Mitbewerbers und fragt nach einem ähnlichen Element. Manchmal stellt er aber auch eine sehr spezifische Anforderung, die sich als Anti-Pattern entpuppt – eine gängige oder bekannte Lösung, die ihren eigentlichen Zweck nicht erfüllt.

Das ist nicht die Schuld des Kunden. Niemand kann in den Kopf eines anderen schauen. Solange Erwartungen nicht formuliert sind, können sie nicht ehrlich erfüllt werden. Selbst eine geäußerte Erwartung muss mit der Frage verknüpft werden: „Was soll das für den Nutzer oder das Unternehmen bringen?“ Ausgereifte Methoden des Service-Designs trennen außerdem den Bedarf von der vorgeschlagenen Lösung und empfehlen, zunächst den gesamten Nutzerkontext zu verstehen (GOV.UK, „Learning about users and their needs“).

Ein Kunde könnte zum Beispiel sagen, er brauche einen Blog. Ein Blog ist jedoch lediglich ein Mechanismus zur Veröffentlichung von Inhalten. Er generiert nicht automatisch Markenexpertise, Traffic oder Umsatz. Dafür braucht es wertvolle Inhalte, systematische Arbeit und gezielte Ansprache der Zielgruppe. Google weist ausdrücklich darauf hin, dass selbst die Erfüllung technischer Anforderungen und Best Practices keine Garantie für die Indexierung oder Anzeige einer Seite in den Suchergebnissen darstellt (Google Search Essentials). Google empfiehlt außerdem, nützliche Inhalte für Nutzer zu erstellen und relevante Communities aktiv über die Website zu informieren (Google, „Creating helpful, reliable, people-first content“).

Ein Blog ist sinnvoll, wenn er potenziellen Kunden hilft, das Problem besser zu verstehen, die Kompetenzen des Unternehmens einzuschätzen und eine fundiertere Kaufentscheidung zu treffen. Wenn ein Unternehmen keine Inhalte erstellen oder bewerben möchte, sollte dies vor der Veröffentlichung eines Angebots klar kommuniziert werden, nicht erst Monate nach dem Start eines leeren „News“-Bereichs.

Ein einzelnes Interview reicht nicht aus, da die Website viele Ebenen hat.

Ich unterteile das Interview in mehrere Bereiche. Zunächst gilt es, die allgemeinen Bedürfnisse zu verstehen und die Art der Implementierung zu bestimmen: Benötigen Sie eine einfache Website, eine private Website, eine Unternehmenswebsite, einen Shop oder erfordert das Problem eine komplexere Anwendung? Gleichzeitig müssen Sie die digitale Landschaft des Kunden verstehen: Domain, Hosting, Datenbank, E-Mail, SSL-Zertifikat, CDN und die bestehenden Systeme, in die die Lösung integriert werden soll.

Die folgenden Ebenen behandeln Funktionalität, Design, Inhalte, Kosten und Zeitplan. Jede Ebene beantwortet eine andere Frage. Funktionalität beschreibt, was Benutzer und Administratoren tun können sollen. Design umfasst Benutzeroberfläche, Benutzererfahrung und Markenidentität. Inhalte beinhalten Texte, Fotos, Grafiken, Videos, Audio, Übersetzungen und die Verantwortung für deren Erstellung. Budget und Zeitplan zeigen, was jetzt umgesetzt werden kann, was reduziert werden muss und was bewusst in die nächste Phase verschoben werden sollte.

Das Konzept der „höchsten Standards“ muss in konkrete Anforderungen unterteilt werden. Das W3C entwickelt zahlreiche Webstandards, und die WCAG definiert testbare Zugänglichkeitskriterien der Stufen A, AA und AAA (W3C, „Accessibility Standards Overview“; W3C, „WCAG 2 Overview“). Ein Feld „W3C-konform“ reicht nicht aus. Die Spezifikation sollte angeben, welchen Standard wir verwenden, welche Konformitätsstufe wir anstreben und wie wir diese überprüfen. Responsivität, Performance, Sicherheit, Datensicherung, Datenschutz und Akzeptanzkriterien sollten ähnlich behandelt werden.

Ein Kunde ist sich möglicherweise nicht bewusst, dass ein Kontaktformular Datenverpflichtungen, Benachrichtigungen nach dem Absenden, Fehlerbehandlung und korrekte Fußzeilenlinks erfordert. Diese Abhängigkeiten sollten nicht erst nach der Implementierung entdeckt werden. Die Aufgabe des Prozesses besteht darin, die Kundeneingaben mit den Ergebnissen des Lösungsdesigns und dem vereinbarten Standard zu verknüpfen.

Nach jeder Ebene muss eine Entscheidung getroffen werden, nicht nur ein Protokoll.

Ein Gespräch ohne Zusammenfassung artet schnell in eine Ansammlung unzusammenhängender Erinnerungen aus. Der Kunde erinnert sich an das eine, der Auftragnehmer an das andere, und der KI-Agent interpretiert es möglicherweise ganz anders. Daher sollte für jeden Bereich ein kurzes Dokument erstellt werden: eine Beschreibung der Ergebnisse, Annahmen, offenen Entscheidungen und der Auswirkungen auf die Kosten und andere Projektteile.

Der Kunde erhält dieses Dokument, gibt Feedback und bestätigt, dass er das erwartete Ergebnis verstanden hat. Es geht nicht darum, ihm eine Reihe von Regeln zum Abarbeiten vorzugeben. Die Abnahme sollte ein gemeinsames Verständnis bestätigen: Was wird in dieser Phase getan, was nicht, welche Materialien muss der Kunde bereitstellen und wie erkennen beide Parteien das korrekte Ergebnis?

Eine frühzeitige Validierung beseitigt zwar nicht alle Fehler, ermöglicht es aber, sie zu entdecken, solange die Änderung noch relativ kostengünstig ist. Das NASA Systems Engineering Handbook empfiehlt, Erwartungen und Anforderungen so früh wie möglich und iterativ zu validieren, da die späte Erkennung einer falschen Lösung zu umfangreichen Nacharbeiten führt (NASA, „Systems Engineering Handbook“). Die Website eines kleinen Unternehmens ist zwar kein Raumschiff, aber der Fehlermechanismus ist bekannt: Je später wir feststellen, dass wir das Falsche entwickelt haben, desto mehr Arbeit muss verworfen oder wiederholt werden.

Die genehmigten Ebenen bilden die Ausführungsspezifikation. Diese Spezifikation dient der Schätzung von Aufwand, Zeit und Kosten und bildet den Rahmen für die Projektbeteiligten. Anstelle eines allgemeinen Auftrags wie „Erstelle die Website“ erhält der Auftragnehmer vereinbarte Ziele, Funktionen, Inhalte, das Erscheinungsbild, Einschränkungen, Standards und Abnahmekriterien.

Der Großteil der Arbeit lässt sich mit wenigen Klicks erledigen.

Die Budgetplanung ist eine schwierige Phase, da der Kunde nur das Endergebnis sieht. Manche denken vielleicht, eine Website entstünde aus vorgefertigten Bausteinen und wenigen Klicks. Doch selbst die Überschrift im ersten Abschnitt der Seite erfordert eine bewusste Entscheidung. Sie muss Vertrauen wecken, die richtige Zielgruppe ansprechen, den Wert des Angebots verdeutlichen und zum Gesamtdesign passen. Ein Satz wie „Wir sind großartig“ lässt sich zwar in einer Minute tippen, gibt dem Leser aber meist keinen Grund, weiterzulesen.

Es gibt Dutzende solcher scheinbar kleiner Elemente. Jedes einzelne kann andere Teile der Website beeinflussen. Daher basiert eine verlässliche Kostenschätzung nicht auf der Anzahl der Unterseiten oder Bausteine. Sie ergibt sich vielmehr aus dem Aufwand, der nötig ist, um das vereinbarte Ergebnis zu erreichen, unter Berücksichtigung von Abhängigkeiten und der Überprüfung der Funktionalität.

Eine gute Evaluation soll nicht sicherstellen, dass sich im Projekt nie etwas ändert. Sie soll vielmehr gewährleisten, dass Änderungen bewusst vorgenommen werden. Wenn der Kunde nach Beginn der Implementierung einen Shop zu einem zuvor geplanten Blog hinzufügen möchte, handelt es sich nicht um eine kleine Anpassung. Es handelt sich um eine neue Phase mit eigenen Merkmalen, Zahlungen, Bestellungen, Inhalten, Risiken, Kosten und einem eigenen Zeitplan. Sie sollten ein separates Gespräch führen, selbst wenn sie dieselbe Website nutzen und dieselbe Beziehung zum Kunden haben.

Einwände von Auftragnehmern können Teil einer guten Dienstleistung sein.

Manchmal widersprechen die Anforderungen eines Kunden seinen Zielen, seinem Budget oder seinen Ansprüchen. In solchen Fällen sollte sich ein Auftragnehmer nicht hinter der Floskel „Der Kunde ist König“ verstecken oder willkürlich seinen eigenen Geschmack aufzwingen. Ein Gespräch ist unerlässlich, in dem beide Seiten der Entscheidung beleuchtet werden: Was gewinnt der Kunde, worauf muss er verzichten, welche Risiken geht er ein und welche Alternative erfüllt seine Ziele am besten?

Dies ist auch eine Aufklärungsmaßnahme. Der Kunde muss die Fachsprache nicht beherrschen, sollte aber verstehen, wofür er bezahlt und warum das Angebot so präsentiert wird. Nur dann kann er eine Lösung bewusst annehmen oder die Konsequenzen einer anderen Entscheidung akzeptieren.

Allerdings lässt sich nicht jeder Konflikt lösen. Ich beginne lieber gar kein Projekt, als Geld für eine Website anzunehmen, von der ich im Voraus weiß, dass sie dem Kunden nicht nützt. Kurzfristig bedeutet das den Verlust des Auftrags. Langfristig schützt es beide Parteien vor Enttäuschung, Konflikten und einem Projekt, das ich nicht als mein eigenes präsentieren möchte.

Qualität schafft Vertrauen, Empfehlungen und Folgeaufträge, garantiert aber nichts automatisch. Markt, Sichtbarkeit, Angebot und die weitere Kundenaktivität sind weiterhin entscheidend. Deshalb möchte ich keine Website als Allheilmittel für die Kundengewinnung verkaufen. Ich kann ein gutes Tool entwickeln und dessen Anwendung ehrlich erklären. Ich kann jedoch kein Ergebnis versprechen, das unabhängig vom Gesamtunternehmen ist.

Spezifikation: Abschluss des Beratungsgesprächs und Beginn der Verantwortlichkeit

Das Ergebnis des Prozesses ist keine Datei mit den Antworten des Kunden. Es ist ein genehmigtes Implementierungshandbuch: eine Kombination aus Geschäftsziel, Bedürfnissen zukünftiger Nutzer, Kundenanforderungen, Expertise des Auftragnehmers, Standards, Budget, Zeitplan und Abnahmekriterien.

Darauf basierend können Aufgaben initiiert, Fortschrittsberichte erstellt, das Projekt durchgeführt, die Projektabnahme vorgenommen, der Kunde geschult und Support, Updates und Backups geplant werden. Ohne dieses Handbuch basiert die Implementierung auf Vermutungen. Damit kann es zwar immer noch eine Herausforderung sein, aber zumindest wissen wir, welches Problem wir lösen und wer die gewählte Methode zur Zielerreichung genehmigt hat.

Der Kunde sollte alles erhalten, was er konkret angefordert hat, sowie alle notwendigen Elemente, um den ordnungsgemäßen Betrieb des gesamten Systems gemäß den vereinbarten Standards zu gewährleisten. Es geht nicht darum, unnötige Funktionen hinzuzufügen. Vielmehr soll sichergestellt werden, dass der Kunde nach Fertigstellung nicht feststellt, dass er nur einen Teil des Systems erworben hat, ohne über die anderen Komponenten aufgeklärt zu werden.

Eine Website nur um ihrer selbst willen ist sinnlos. Ein Tool ist dann sinnvoll, wenn Zweck, Umfang und beabsichtigte Nutzung vor Beginn der Arbeiten gemeinsam festgelegt sind. ## Bibliographie

– NASA, „NASA Systems Engineering Handbook“, 2016, abgerufen am 2. September 2026.

– W3C Web Accessibility Initiative, „Accessibility Standards Overview“, abgerufen am 2. September 2026.

– W3C Web Accessibility Initiative, „WCAG 2 Overview“, abgerufen am 2. September 2026.

✦Systeme für mehr Autonomie bauen.