Wie man ein Artikelthema aus echten Nutzerbedürfnissen auswählt
Für die Redaktion einer unabhängigen Website beginnt ein nützliches Artikelthema bei Lesenden, die eine bestimmte Aufgabe lösen möchten – nicht bei einem allgemeinen Keyword oder einem vagen Themenbereich. Diese Methode wandelt beobachtete Fragen in eine klar definierte Nutzergruppe, eine zentrale Absicht und eine konkrete Seitenentscheidung um: einen neuen Artikel erstellen, einen bestehenden aktualisieren oder das Thema ablehnen. Mithilfe eines Evidenz-Protokolls werden wiederkehrende öffentliche Bedürfnisse von kontospezifischen Supportanfragen und doppelten Ideen getrennt.
Beginnen Sie mit der Aufgabe der Lesenden, nicht mit der Themenbezeichnung
Formulieren Sie das vorgeschlagene Bedürfnis in drei Teilen:
Als [spezifische Leserschaft] muss ich [etwas tun oder entscheiden], damit ich [ein nützliches Ergebnis erziele].
Diese Struktur ist an die User-Needs-Methode von GOV.UK angelehnt, die empfiehlt, den Nutzenden, die Handlung und den Grund für die Handlung zu benennen. Deren Leitfaden warnt Redaktionen zudem davor, vage Verben wie „verstehen“ zu verwenden, es sei denn, das Verstehen ist für eine definierte Aufgabe zwingend erforderlich (GOV.UK: Identify user needs).
Beispielsweise ist „Fotografie für Anfänger“ ein Themenbereich, aber noch keine Aufgabe für einen Artikel. Bessere Ansätze wären:
Die zweite Version ist präziser gefasst, da sie eine Zielgruppe, eine Handlung und eine Entscheidung benennt. Sie liefert Ihnen zudem ein Prüfkriterium für den Umfang: Informationen, die der lesenden Person nicht bei dieser Entscheidung helfen, gehören wahrscheinlich an eine andere Stelle.
Behalten Sie eine einzige Hauptabsicht pro Artikel bei. Eine Frage zur Auswahl eines Werkzeugs, eine Frage zu dessen Nutzung und eine Frage dazu, ob das Werkzeug überhaupt geeignet ist, mögen verwandt sein, erfordern jedoch unter Umständen unterschiedliche Voraussetzungen und führen zu anderen Ergebnissen. Werden sie zu früh zusammengeführt, entsteht eine Seite mit einem weit gefassten Titel, die jedoch für die einzelnen Aufgaben unvollständig bleibt.
Evidenz in einem Evidenz-Protokoll erfassen
Eine Frage ist ein Hinweis, aber nicht automatisch ein Thema. Halten Sie ausreichend Kontext fest, um beurteilen zu können, ob sie ein öffentliches Informationsbedürfnis darstellt. Eine einfache Tabellenkalkulation reicht völlig aus; GOV.UK empfiehlt ausdrücklich, unterstützende Belege neben den Nutzerbedürfnissen und Akzeptanzkriterien festzuhalten (GOV.UK: Identify user needs).
Verwenden Sie eine Zeile pro beobachteter Frage oder Gruppe eng miteinander verwandter Fragen:
Erhöhen Sie die Häufigkeit nicht künstlich, indem Sie dieselbe Frage zählen, die über mehrere Kanäle hinweg kopiert wurde. Erfassen Sie das zugrunde liegende Bedürfnis einmal und notieren Sie die Kanäle, auf denen es aufgetaucht ist. Verwerfen Sie umgekehrt ein Bedürfnis nicht bloß deshalb, weil es nur wenige Male aufgetreten ist, wenn jedes Beispiel dieselbe ungelöste Aufgabe zeigt und die Antwort einem breiteren öffentlichen Publikum dienen könnte.
Ein nützliches Protokoll unterscheidet zwischen Evidenz und Interpretation. „Vier Lesende fragten, ob eine erste Übung spezielle Ausrüstung erfordert“ ist ein Beleg. „Die Leserschaft wünscht sich einen kostengünstigen Leitfaden für Anfänger“ ist eine Interpretation. Behalten Sie beides bei, kennzeichnen Sie es jedoch getrennt.
Öffentliche Bedürfnisse von reinen Support-Fragen trennen
Die entscheidende redaktionelle Frage lautet nicht einfach: „Hat jemand danach gefragt?“ Sie lautet vielmehr: „Kann eine allgemeine Seite einer relevanten Gruppe von Lesenden helfen, dieselbe Aufgabe zu bewältigen?“ Der Leitfaden für einfache Sprache von Digital.gov geht von der Beobachtung aus, dass Menschen Websites besuchen, um ganz unterschiedliche Dinge zu tun, und empfiehlt, Inhalte an der Zielgruppe und ihren Zielen auszurichten (Digital.gov: Principles of plain language).
Klassifizieren Sie jeden Kandidaten im Protokoll:
Ein wiederkehrendes öffentliches Bedürfnis:
Erstellen oder aktualisieren Sie einen Artikel, wenn die Frage eine stabile, allgemeine Antwort hat und dieselbe Aufgabe bei verschiedenen Personen, Kanälen oder Situationen auftritt. Beispiele sind die Auswahl zwischen klar beschriebenen Optionen, die Vorbereitung auf einen gängigen Ablauf oder die Diagnose eines weithin beobachtbaren Problems. Der Artikel sollte seine Zielgruppe und Grenzen klar benennen, damit die Lesenden erkennen können, ob er auf sie zutrifft.
Ein reines Support-Bedürfnis:
Eine reine Support-Frage hängt von privaten Kontodaten, einer einzelnen Bestellung, einer persönlichen Konfiguration oder einer Handlung ab, die nur das Betriebspersonal durchführen kann. Sie rechtfertigt möglicherweise eine Support-Anleitung oder Kontaktmöglichkeiten, aber nicht zwingend einen allgemeinen redaktionellen Artikel. Machen Sie aus „Warum hat mein Konto diese Nachricht erhalten?“ keine universelle Erklärung, wenn die Antwort von Informationen abhängt, die anderen Lesenden nicht zur Verfügung stehen.
Sie können dennoch eine öffentliche Begleitseite veröffentlichen, wenn eine wiederholbare, allgemeine Aufgabe vorliegt – etwa zur Erklärung, was die Nachrichten-Kategorie bedeutet und welche Informationen gesammelt werden sollten, bevor man den Support kontaktiert. Die private Klärung des Falls gehört jedoch nicht in den Artikel.
Ein dupliziertes Bedürfnis:
Ein Duplikat ist eine echte Frage, die bereits von einer bestehenden Seite mit dem passenden Detaillierungsgrad und für dieselbe Zielgruppe beantwortet wird. Die richtige Maßnahme besteht möglicherweise darin, die Einleitung, die Beispiele, die Navigation oder eine fehlende Bedingung auf der bestehenden Seite zu verbessern. Eine neue URL würde die Aufmerksamkeit nur aufteilen, ohne eine eigenständige Aufgabe hinzuzufügen.
Ohne ein vollständiges Website-Inventar kann eine Redaktion nicht aufrichtig behaupten, dass kein Duplikat existiert. Die pragmatische Vorgehensweise besteht darin, die bekannten relevanten Seiten zu prüfen, den Inventar-Check bei Bedarf als unvollständig zu kennzeichnen und zu vermeiden, einen neuen Artikel als die einzige Antwort darzustellen.
Nutzen Sie eine Entscheidungsschranke vor der Titelvergabe
Lassen Sie den Kandidaten fünf Kontrollstufen durchlaufen. Ein „Nein“ bedeutet nicht zwingend das Aus für die Idee; es zeigt Ihnen, welche Art von Arbeit erforderlich ist.
Nutzen Sie das Ergebnis als redaktionelle Schranke:
Diese Schranke ist eine redaktionelle Schlussfolgerung, die auf zwei Prinzipien der Quellen aufbaut: Inhalte sollten einer definierten Zielgruppe und Aufgabe dienen, und der Herausgeber sollte Belege für den Bedarf vorhalten können. Sie ist eine Entscheidungshilfe, keine Formel für Suchmaschinen.
Das erfolgreiche Bedürfnis in ein nützliches Artikel-Briefing verwandeln
Sobald ein Thema die Schranke passiert hat, schreiben Sie das Briefing, bevor Sie an finalen Formulierungen feilen. Halten Sie Folgendes fest:
Für das Beispielthema könnte eine Akzeptanz-Checkliste so aussehen: Die lesende Person kann eine unbehandelte Frage in eine Nutzer-Aussage umwandeln; die zentrale Aufgabe identifizieren; die Evidenz als öffentlich, rein supportbezogen oder dupliziert klassifizieren; und zwischen Erstellen, Aktualisieren, Zurückstellen oder Ablehnen wählen. Dies folgt der Logik der Akzeptanzkriterien von GOV.UK, die beschreiben, was erfüllt sein muss, damit ein Nutzerbedürfnis als abgedeckt gilt (GOV.UK: Identify user needs).
Nutzen Sie das Briefing, um den Titel zu steuern. „Wie man ein Artikelthema aus echten Nutzerbedürfnissen auswählt“ eignet sich für Redaktionen, die eine wiederholbare Auswahlmethode benötigen. „Wie man die besten Content-Themen findet“ wäre zu weit gefasst und würde eine unbelegte Rangfolge oder ein Qualitätsurteil implizieren. Googles eigene Richtlinien hinterfragen, ob eine Website ein beabsichtigtes Publikum hat, ob Inhalte den Lesenden helfen, ihr Ziel zu erreichen, und ob die Inhalte für Menschen erstellt wurden und nicht primär, um Zugriffe über Suchmaschinen zu generieren (Google Search Central: Creating helpful, reliable, people-first content). Diese Fragen unterstreichen den Wert einer präzisen redaktionellen Aufgabe, garantieren jedoch weder Traffic noch Rankings.
Den Artikel beantwortbar, lesbar und pflegbar gestalten
Aus einem echten Bedürfnis kann dennoch eine schwache Seite entstehen, wenn der Entwurf die Lesenden dazu zwingt, sich die Antwort selbst zusammenzureimen. Platzieren Sie die direkte Antwort weit vorne und erläutern Sie anschließend die Bedingungen, die sie beeinflussen. Verwenden Sie die Begriffe der Leserschaft aus dem Protokoll, wo sie klar verständlich sind, definieren Sie jedoch interne redaktionelle Begriffe wie „reiner Support-Bedarf“ und „Duplikat“.
Strukturieren Sie den Artikel anhand von Entscheidungen und Handlungen statt entlang einer Liste lose zusammenhängender Keywords. Digital.gov empfiehlt, zielgruppenorientiert zu schreiben, Informationen zu strukturieren, kurze und einfache Sprache zu nutzen und unnötigen Fachjargon zu vermeiden (Digital.gov: Principles of plain language). Für eine redaktionelle Methode bedeutet dies, die Felder des Protokolls, die Entscheidungsschranke und mindestens ein durchgearbeitetes Beispiel zu zeigen – und nicht bloß den Ratschlag zu erteilen, Redaktionen sollten „ihre Zielgruppe verstehen“.
Prüfen Sie vor der Freigabe jede folgenreiche Aussage:
Wenn die Antwort auf die letzte Frage „Nein“ lautet, weil das Inventar unvollständig ist, halten Sie diese Einschränkung fest. Ein ehrlicher Hinweis wie „Überprüfung des Website-Inventars erforderlich“ ist nützlicher als die unbelegte Behauptung, das Thema sei neu.
