SEO Playbook · Element

Annotierte Screenshots: Regeln und Beispiele

Verwenden Sie einen annotierten Screenshot, um einen präzisen Interface-Bereich mit nummerierten Markierungen, zugänglicher Legende, Aufnahmestandards und Aktualitätskontrollen zu erklären.

15 min read

Ein annotierter Screenshot zeigt einen realen Interface-Zustand und identifiziert die genauen Bereiche, die ein Leser beachten muss. Das Bild trägt nummerierte Markierungen; die Seite trägt die passende Textlegende. Diese Trennung ist das Element: Weder ein unmarkiertes Produktbild noch in Pixel eingebackene Beschriftungen erfüllen den Vertrag.

Content-Freshness-Audit, gefiltert auf eine verfolgte URL.

  1. Verfolgte URL: Bestätigt, dass die Überprüfung für die beabsichtigte Seite gilt und nicht für die gesamte Domain.
  2. Statusfilter: Schränkt die Tabelle auf Seiten ein, die eine redaktionelle Entscheidung erfordern.
  3. Ergebnisdatum: Zeigt an, wann der zugrundeliegende Audit-Datensatz zuletzt aktualisiert wurde.

Die Aufnahme steht noch aus, daher ist der Kommentar eine Produktionsaufnahme-Spezifikation und keine defekte Bildreferenz. Sobald das Asset existiert, werden das Bild, die Bildunterschrift und die nummerierte Legende als eine semantische Abbildung dargestellt.

Warum dieses Element wichtig ist

Leser verwenden ein Produktbild, um eine räumliche Frage zu beantworten: „Welches Bedienelement, welchen Wert oder welchen Zustand meint diese Anweisung?“ Dichte Interfaces enthalten Navigation, Filter, Beschriftungen, Daten, Badges und Aktionen, die alle gleich wichtig erscheinen können. Ein nicht annotierter Screenshot verlangt vom Leser, die Aufmerksamkeit des Autors zurückzuverfolgen. Nummerierte Markierungen reduzieren diese Suche auf einen direkten Abgleich zwischen einer sichtbaren Position und einer kurzen Erklärung.

Das Element ersetzt auch fragile Koordinatenangaben. „Verwenden Sie das Bedienelement rechts“ wird falsch, wenn eine Symbolleiste umbricht; „wählen Sie den mit 2 markierten Statusfilter“ bleibt nutzbar, solange die Aufnahme aktuell ist.

Maschinelle Extraktion bedeutet, dass Software die nützliche Bedeutung einer Inhaltseinheit isolieren und wiederverwenden kann. Computer Vision erkennt möglicherweise Interface-Text, kann aber nicht zuverlässig ableiten, warum eines von zwanzig Bedienelementen für diesen Vorgang relevant ist. Eine sichtbare, geordnete Legende erzeugt explizite Markierungs-Erklärungs-Paare, die Suchsysteme, Übersetzungstools, Barrierefreiheitssoftware und Inhaltsaudits als Text verarbeiten können. Das Bild liefert räumliche Evidenz; die Legende liefert durchsuchbare Bedeutung. Dies folgt den übergreifenden Element-Schreibregeln : Inhalte bleiben typisiert und portabel, auch wenn ihr Renderer wechselt.

Backen Sie die Legende niemals in Pixel ein. Pixel-Text kann nicht übersetzt, durchsucht, ausgewählt oder korrigiert werden, ohne das Bild zu bearbeiten. Er ist auch für Screenreader unsichtbar – Software, die digitale Inhalte für Menschen ankündigt, die den Bildschirm nicht sehen können. Nur Markierungsnummern gehören in das Bild.

Wann es verwendet wird

Verwenden Sie einen annotierten Screenshot, wenn der Leser einen bestimmten Bereich in einem realen Interface identifizieren muss und Worte allein mehr als ein plausibles Ziel offenlassen. Er ist erforderlich, wenn zwei Bedienelemente ähnliche Namen haben, ein wichtiger Zustand subtil ist, ein Ergebnis in seinem umgebenden Kontext interpretiert werden muss oder eine visuelle Konfiguration nicht getreu in Prosa dargestellt werden kann. Er ist auch nützlich, wenn eine Produktseite eine konkrete Interface-Behauptung aufstellt, die das Bild beweisen kann.

Ein Screenshot ist optional, wenn die Anweisung bereits ein eindeutiges, sichtbares Bedienelement benennt und die Interaktion konventionell ist. „Wählen Sie Änderungen speichern“ braucht normalerweise kein Bild, wenn die Seite nur einen solchen Button enthält. Er wird erforderlich, wenn derselbe Bildschirm Entwurf speichern, Ansicht speichern und Änderungen speichern enthält und die falsche Wahl das Ergebnis verändert.

Ein Screenshot ist schädlich, wenn er Gewicht hinzufügt, ohne Unsicherheit zu beseitigen. Fügen Sie keinen zu Dekorationszwecken oder zur Wiederholung von Text hinzu, der in einer Tabelle klarer ist. Vierzehn Screenshots in einer vierzehnschrittigen Anleitung erzeugen vierzehn Unterbrechungen, mobile Zoomprobleme und veraltete Assets. Nehmen Sie die mehrdeutigen Schritte auf; lassen Sie präzise Verben die Routineaufgaben tragen.

Zu den Beinahe-Fehlern gehören:

  • Ein volles Dashboard zur Erklärung eines einzelnen Symbols: Beschneiden Sie auf die kleinste Region, die die Orientierung bewahrt. Eine Markierung, die in einem breiten Interface verloren geht, reduziert den Suchaufwand nicht.
  • Ein Screenshot als zahlenmäßiger Beleg: Wiederholen Sie den entscheidenden Wert in Text oder einer Tabelle. Pixel dürfen nicht die einzige zugängliche Kopie einer Behauptung sein.
  • Ein Screenshot eines Menüs vor dem Öffnen: Nehmen Sie den Zustand auf, den der Leser inspizieren muss. Der geschlossene Zustand beweist, dass das Produkt existiert, aber nicht, welche Wahl zu treffen ist.
  • Ein Screenshot mit Kundendaten: Ersetzen Sie diese vor der Aufnahme durch stabile Demodaten. Unschärfen werden leicht übersehen.
  • Ein als Screenshot getarntes Diagramm: Verwenden Sie ein Diagramm für abstrakte Beziehungen. Interface-Realismus hilft nur, wenn das Interface selbst relevant ist.

Wo es platziert wird

Platzieren Sie die Abbildung nach dem Absatz oder Schritt, der den Leser erstmals auffordert, das Interface zu inspizieren. In einer Anleitung setzen Sie sie nach der Aktion und vor dem Erfolgszustand oder der Fehlerbehebung, damit der Leser das Bedienelement findet, bevor er das Ergebnis überprüft.

Halten Sie Bild, Bildunterschrift und Legende zusammen. Eine Überschrift darf die Gruppe einleiten, aber ein weiterer Absatz, Hinweiskasten, Werbeanzeige oder Seitenumbruch darf die Aufnahme nicht von ihren nummerierten Erklärungen trennen. Eine Bildunterschrift identifiziert den gesamten Bildschirm und Kontext; sie enthält keine Anweisung, die in die Prosa gehört, und ersetzt nicht die Legende.

Platzieren Sie keine zwei vollbreiten Screenshots nebeneinander. Fügen Sie die Erklärung ein, die sie unterscheidet, oder erstellen Sie einen beschrifteten Vergleich, wenn beide Zustände gemeinsam bewertet werden müssen. Halten Sie Screenshots von unzusammenhängenden Handlungsaufforderungen, dichten Tabellen und Galerien fern.

Wiederholen Sie das Element nur, wenn jedes Vorkommen eine andere räumliche Frage beantwortet. Bevorzugen Sie eine fokussierte Abbildung; andernfalls geben Sie verschiedenen Ausschnitten eigene Dateinamen und Zwecke.

Anatomie

Die Anatomie-Aufnahme zeigt die sichtbaren und textuellen Teile eines vollständigen Elements. Erklärende Beschriftungen bleiben in der dargestellten Legende, anstatt Teil des Quellbilds zu werden.

Dargestellte Legende

  1. Kontextgrenze: Enthält genug umgebendes Interface, um die Seite und Position zu identifizieren, schließt aber unzusammenhängende Navigation und leeren Raum aus.
  2. Nummerierte Markierung: Verwendet einen kontrastreichen Kreis und eine ganze Zahl, nicht nur Farbe, um eine Region mit ihrem Legenden-Eintrag zu verbinden.
  3. Zielregion: Markiert das kleinste vollständige Bedienelement, den kleinsten Wert oder Zustand, der für die Erklärung benötigt wird; sie bedeckt niemals die Beschriftung des Ziels.
  4. Orientierungspunkt: Erhält eine stabile Überschrift, einen Tab oder eine Panel-Beschriftung, damit der Leser denselben Bereich im Live-Produkt wiederfinden kann.
  5. Bildunterschrift: Benennt den Bildschirm, Zustand und das Szenario in sichtbarem Text unter dem Bild.
  6. Legende: Verwendet eine geordnete Liste, deren Nummern exakt mit den Markierungen übereinstimmen und deren Einträge die Bedeutung erklären, nicht nur das Erscheinungsbild.

Markierungsnummern beginnen bei 1 und folgen der Legenden-Reihenfolge. Verwenden Sie zwei bis sechs pro Bild; eine Markierung eignet sich für ein schwieriges Ziel, während mehr als sechs meist auf eine zu großzügige Aufnahme hindeuten.

Gestaltungsbeispiele

Die unterstützten Varianten ändern Beschnitt und Viewport, nicht die Annotationsrichtlinie. Jede Variante verwendet Demodaten, nummerierte Bildmarkierungen, eine externe Textlegende und eine sichtbare Bildunterschrift.

Fokussiertes Bedienelement: Bevorzugt für eine einzelne mehrdeutige Aktion. Bewahren Sie ein Orientierungslabel, damit der Beschnitt kein anonymer Rechteck wird.

Workflow-Zustand: Verwenden Sie dies, wenn die Beziehung zwischen einer Eingabe, einem Status und einem Ergebnis wichtig ist. Halten Sie unzusammenhängende globale Navigation aus dem Bild.

URL im Kontext: Die einzige Standardvariante, die Browser-Chrome einschließt, also die eigenen Tabs, die Adressleiste und Bedienelemente des Browsers. Beziehen Sie nur die Adressleiste und die erforderliche Berechtigungs- oder Sicherheitsanzeige ein.

Mobiler Zustand: Nehmen Sie das tatsächliche schmale Layout auf, wenn sich die Interaktion bei mobiler Breite ändert. Verkleinern Sie keinen breiten Desktop-Bildschirm und nennen ihn ein mobiles Beispiel.

Parameter

Die Parameter bilden den portablen Inhaltsvertrag. Visuelle Werte wie Markierungsfarbe, Rahmenstärke und Schrifttypografie gehören zum Renderer und sind keine Autorenfelder.

NameTypErforderlichMin./Max.StandardQuelle
srcStammrelativer Asset-PfadJaEine vorhandene DateiKeineÜbergeordnetes Attribut
altEinfacher StringJa80–180 Zeichen Ziel; maximal 250KeinePassender Dateinamenschlüssel im alt.yaml des Ordners
captionEinfacher StringJa6–24 Wörter; maximal 160 ZeichenKeineErster Absatz im Direktivenkörper
markersGeordnete ElementsammlungJa1–6 Elemente; Ziel 2–4KeineGeordnete Liste im Direktivenkörper
marker.numberIntegerJaFortlaufende Sequenz ab 1Abgeleitet aus der Element-ReihenfolgePosition in der geordneten Liste
marker.labelEinfacher StringJa2–6 Wörter; maximal 50 ZeichenKeineErste Überschrift oder fette Beschriftung in jedem Element
marker.descriptionEinfacher TextJa8–35 WörterKeineElementkörper nach der Beschriftung
viewportPositive GanzzahlJa390 mobil oder 1440 Desktop CSS-Pixel1440Übergeordnetes Attribut und Aufnahmeprotokoll
densityEnumJaExakt 2x2xÜbergeordnetes Attribut und Aufnahmeprotokoll
screenIdStabile ZeichenketteJa3–60 Zeichen; Lowercase-Kebab-CaseKeineÜbergeordnetes Attribut; Produktbildschirm-Register
captureDateISO-DatumJaEin genaues DatumKeineÜbergeordnetes Attribut; Asset-Überprüfungsprotokoll
browserChromeBooleanNeintrue oder falsefalseÜbergeordnetes Attribut

Die screenId identifiziert die Produktoberfläche unabhängig von ihrem Dateinamen, sodass ein Release verschiedene Ausschnitte von content-freshness-audit finden kann. Die alt.yaml-Datei bleibt einfach: ein Dateiname gefolgt von einem gefalteten Alt-Text-String.

Syntax und Codebeispiele

Jede Notation bewahrt dieselben Metadaten, Bildunterschrift, Markierungen und die Lese-Reihenfolge Bild–Bildunterschrift–Legende.

Portable Markdown-Direktive

:::annotated-screenshot{src="/images/seo-playbook/elements/annotated-screenshot/workflow-state.webp" viewport=1440 density="2x" screenId="content-freshness-audit" captureDate="2026-08-27"}
Content freshness audit filtered to one tracked URL.

1. **Tracked URL:** Confirms which page the audit evaluates.
2. **Status filter:** Limits the results to pages awaiting review.
3. **Result date:** Shows when the audit data was refreshed.
:::

Der Adapter löst alt aus der alt.yaml des Ordners auf. Ein fehlender Dateinamenschlüssel ist ein Publikationsfehler, keine Erlaubnis, die Bildunterschrift zu kopieren.

Hugo-Shortcode-Mapping

{{< annotated-screenshot src="/images/seo-playbook/elements/annotated-screenshot/workflow-state.webp" viewport="1440" density="2x" screenId="content-freshness-audit" captureDate="2026-08-27" >}}
Content freshness audit filtered to one tracked URL.

1. **Tracked URL:** Confirms which page the audit evaluates.
2. **Status filter:** Limits the results to pages awaiting review.
3. **Result date:** Shows when the audit data was refreshed.
{{< /annotated-screenshot >}}

Dies ist ein Adaptervertrag, kein registrierter Shortcode. Bis ein genehmigter Renderer und Asset existieren, verwenden Sie die etablierte Semantic-Figure-Pipeline oder hinterlassen Sie den vorgeschriebenen Aufnahmekommentar. Ersetzen Sie keinen Renderer, der die Legende oder Aktualitätsfelder verwirft.

WordPress-Block oder -Shortcode

[annotated_screenshot src="workflow-state.webp" viewport="1440" density="2x" screen_id="content-freshness-audit" capture_date="2026-08-27"]
[caption]Content freshness audit filtered to one tracked URL.[/caption]
[marker number="1" label="Tracked URL"]Confirms which page the audit evaluates.[/marker]
[marker number="2" label="Status filter"]Limits the results to pages awaiting review.[/marker]
[marker number="3" label="Result date"]Shows when the audit data was refreshed.[/marker]
[/annotated_screenshot]

Ein WordPress-Block kann die Felder als Bedienelemente anzeigen, muss aber Markierungsbeschreibungen als Text speichern.

Beispiele

Gut: ein mehrdeutiger Zustand, drei nützliche Markierungen

Content-Freshness-Überprüfung für demo.example/pricing/.

  1. Verfolgte URL: Stellt sicher, dass das Ergebnis zur in der Anleitung ausgewählten Preisseite gehört.
  2. Needs review: Identifiziert den genauen Filter, der aktuelle Seiten aus der Arbeitswarteschlange entfernt.
  3. Zuletzt aktualisiert: Verhindert, dass der Redakteur ein altes Audit-Ergebnis als aktuelle Diagnose behandelt.

Dies funktioniert, weil jede Markierung eine Entscheidung beantwortet, der Beschnitt die Orientierung bewahrt und die Legende Konsequenzen erklärt, die in Pixeln nicht sichtbar sind. Die Demo-Domain ist eindeutig keine Kundendaten.

Schlecht: ein beschriftetes Produktposter

Die schlechte Version erklärt ein gesamtes Dashboard auf einmal. Acht Pfeile kreuzen sich, Beschriftungen verdecken Bedienelemente und eingebackene Werbung gibt keine Handlungsanweisung. Browser-Lesezeichen schaffen Datenschutzrisiken, Kundennamen machen die Freigabe unsicher, kein Bildschirmidentifikator unterstützt Aktualisierungen und mobile Skalierung macht Ziele unleserlich.

Reparieren Sie es, indem Sie eine Aufgabe auswählen, genehmigte Demodaten verwenden, auf das entsprechende Panel zuschneiden und nur notwendige Markierungen behalten. Verschieben Sie Erklärungen in eine Textlegende, fügen Sie kontextbezogenen Alt-Text hinzu und notieren Sie den Bildschirmidentifikator und das Datum.

Schema-Markup und Barrierefreiheit

Ein annotierter Screenshot hat keinen speziellen Schema.org-Typ. Er kann die image-Eigenschaft eines Article oder ein ImageObject mit korrekten Angaben zu contentUrl, Bildunterschrift, Breite und Höhe befüllen. Erfinden Sie keine Markierungs-Eigenschaften; halten Sie die Legende sichtbar.

Verwenden Sie native Figure-Semantik: ein <figure>-Element, das <img>, ein <figcaption> und die geordnete Legende enthält. Die Bildunterschrift benennt den gesamten Bildschirm und Zustand. Das alt-Attribut des Bildes beschreibt, was der Bildschirm in diesem Kontext zeigt; es sollte nicht mit „Screenshot von“ beginnen, da das Bildelement sich selbst bereits ankündigt. Die Legende liefert die detaillierten nummerierten Erklärungen, daher erzeugt die Wiederholung aller sechs Einträge im Alt-Text eine lange, doppelte Ansage.

Zielen Sie auf 80–180 Zeichen, mit 250 als Obergrenze. Nennen Sie den Produktbereich, Zustand und markierten Zweck: „Content-Freshness-Audit gefiltert auf eine verfolgte URL, mit Markierungen auf dem Statusfilter und dem Datum der letzten Aktualisierung.“ Transkribieren Sie nicht das Interface, stopfen Sie keine Keywords hinein und verwenden Sie nicht den Dateinamen. Dieses informative Bild benötigt normalerweise einen nicht-leeren Alt-Text.

Markierungsnummern müssen ohne Farbe lesbar sein. Verwenden Sie hohen Kontrast sowohl gegen helle als auch dunkle Interface-Bereiche, halten Sie ihre visuelle Größe konsistent und bedecken Sie keine Beschriftungen oder Werte. Die Legende verwendet eine geordnete Liste in normaler Dokumentenreihenfolge; vermeiden Sie ARIA-Rollen (Accessible Rich Internet Applications), die statische Inhalte in einen Alert oder ein interaktives Widget verwandeln. Eine aria-describedby-Beziehung ist nur optional, wenn Tests zeigen, dass sie die Navigation verbessert, ohne dass die sichtbare Legende zweimal angesagt wird.

Bei schmalen Breiten muss Responsive Design die Bedeutung bewahren. Skalieren Sie ein breites Bild nur, wenn Markierungen und Ziele lesbar bleiben; anderenfalls stellen Sie einen fokussierten Ausschnitt oder eine echte mobile Aufnahme bereit. Vermeiden Sie grundsätzlich horizontalen Scrollen auf Seitenebene oder erforderliches Zoomen. Bildunterschrift und Legende umbrechen darunter.

Inhalts- und Aufnahmeregeln

Konsistenz macht Screenshots vergleichbar und austauschbar. Nehmen Sie Desktop-Produktbildschirme bei einem festen Viewport von 1440 CSS-Pixeln und 2-facher Pixeldichte auf, oft als Retina-Dichte bezeichnet, die zwei Gerätepixel pro CSS-Pixel aufzeichnet. Nehmen Sie echte mobile Zustände bei 390 CSS-Pixeln und 2-facher Dichte auf. Verwenden Sie das genehmigte Produktthema innerhalb einer Anleitung konsistent; wechseln Sie nicht zwischen hellem und dunklem Modus, es sei denn, der Themenunterschied ist das Thema.

Verwenden Sie ausschließlich Demodaten: keine echten Namen, E-Mail-Adressen, Domains, Rechnungsdetails, Token, Prompts oder Ergebnisse. Überprüfen Sie Seitenleisten, aktuelle Elemente, Autofill, Benachrichtigungen und Avatare vor der Aufnahme.

Schließen Sie Browser-Chrome aus, es sei denn, eine URL, Berechtigung oder ein Browser-Bedienelement ist der Punkt. Blenden Sie Tabs, Lesezeichen, Erweiterungen, Downloads, Profile und Benachrichtigungen aus. Nehmen Sie nach dem Laden auf; schließen Sie irrelevante Tooltips und zeigen Sie einen Cursor nur an, wenn er notwendig ist.

Speichern Sie Quellaufnahmen unter cdn-assets/seo-playbook/elements/annotated-screenshot/. Verwenden Sie Lowercase-Kebab-Case-Namen basierend auf Bildschirm und Zustand, z. B. freshness-audit-needs-review.webp; verwenden Sie niemals final, new, v2, einen Personennamen oder ein Datum als Dateinamen. Der stabile Name ermöglicht den Austausch des Assets, ohne jede Seite neu schreiben zu müssen. Verwenden Sie WebP für die normale Auslieferung, vorzugsweise eine verlustfreie Einstellung, wenn kleiner Interface-Text scharf bleiben muss. Verwenden Sie PNG nur, wenn die Produktionspipeline zeigt, dass WebP Text oder Transparenz beeinträchtigt. Verwenden Sie kein JPEG für UI-Aufnahmen mit feinem Text und scharfen Kanten.

Rendern Sie mit maximal 1600 CSS-Pixeln Breite; eine 1440-Pixel-2x-Quelle kann 2880 physische Pixel haben. Bewahren Sie das Seitenverhältnis und die intrinsischen Abmessungen. Optimierung unterstützt Bild-SEO , aber die Komprimierung darf Text oder Markierungen nicht unscharf machen.

Jeder Asset-Ordner enthält alt.yaml mit einem Eintrag pro Dateiname:

freshness-audit-needs-review.webp: >-
  AmICited content freshness audit filtered to one tracked URL, with numbered markers on the review status and last-refreshed date.

Der Schlüssel stimmt exakt mit dem Dateinamen überein; der Wert ist Alt-Text, keine Bildunterschrift oder Legende. Platzhalter, Standard-Dashboards und nicht existierende Bildreferenzen sind verboten. Ausstehende Aufnahmen verwenden nur einen SCREENSHOT-Kommentar und screenshotsPending = true.

Aktualität und Neuaufnahme-Richtlinie

Screenshots altern still, wenn sich ein dargestelltes Bedienelement bewegt oder seinen Namen ändert. Behandeln Sie jede Aufnahme als Ansicht eines registrierten Bildschirms: screenId verbindet Produktänderungen mit Assets, während das Aufnahmedatum den aufgezeichneten Zustand identifiziert.

Eine UI-Änderung löst eine Neuaufnahme aus, wenn sie ein markiertes Ziel verschiebt oder umbenennt, einen Zustand ändert, den die Legende erklärt, den Navigationspfad zu dessen Erreichung verändert, einen erhaltenen Orientierungspunkt entfernt oder das alte Bild den Leser wahrscheinlich zum falschen Bedienelement führt. Nehmen Sie den vollständigen Figurensatz für diesen Bildschirm neu auf, einschließlich fokussierter und mobiler Varianten. Eine Farbtoken-Änderung, Abstandsanpassung oder das Hinzufügen einer unzusammenhängenden Seitenleiste erfordert keinen automatischen Ersatz, es sei denn, der Screenshot gerät nun sichtbar in Konflikt mit dem Live-Erlebnis oder dem Barrierefreiheitsstandard.

Wenn sich ein Bildschirm ändert, suchen Sie nach seiner screenId, dann nach seinem Ordner und Dateinamen, um veraltete Verwendungen zu finden. Ersetzen Sie stabile Dateien, überprüfen Sie alt.yaml und inspizieren Sie jede betroffene Legende. Benennen Sie Ersatzdateien nicht um und hinterlassen Sie keine älteren Referenzen.

Der Verantwortliche des Produktbildschirms signalisiert Änderungen; der Inhaltsverantwortliche akzeptiert Ersetzungen. Nehmen Sie mit derselben Demo-Umgebung, demselben Viewport, derselben Dichte und demselben Thema neu auf. Überprüfen Sie Screenshots bei jeder inhaltlichen Seitenaktualisierung.

Beitragstypen, die es verwenden

Das postTypes-Frontmatter ist die registrierte Verbindung. Jeder Typ verwendet denselben Elementvertrag, wendet aber eine andere Anforderungsschwelle an.

BeitragstypAnforderungBevorzugte PositionGrund
How-to-AnleitungNur für mehrdeutige Schritte erforderlichNach der Aktion, vor Erfolg und WiederherstellungDer Leser benötigt räumliche Orientierung im Moment der Interaktion, keine Galerie jedes Routine-Klicks.
ProduktseiteOptionaler NachweisNeben der Fähigkeitsbehauptung, die es verifiziertEin fokussierter echter Bildschirm kann beweisen, dass ein behaupteter Workflow existiert; ein dekoratives Dashboard kann das nicht.
Use-Case-SeiteOptionaler Workflow-NachweisNachdem der Use-Case-Workflow erklärt wurdeDie Aufnahme verbindet eine Benutzersituation mit dem genauen Produktzustand, der sie unterstützt.
FallstudieOptionaler Nachweis mit GenehmigungNeben der Intervention oder dem Ergebnis, das es dokumentiertDie Abbildung kann eine Veränderung überprüfbar machen, aber Demodaten dürfen nicht als Kundenbelege präsentiert werden.
Ultimativer LeitfadenSelten, selektive UnterstützungBeim ersten wirklich visuellen Verfahren oder Interface-KonzeptBreite Leitfäden werden unbrauchbar, wenn jeder Abschnitt ein großes Produktbild erhält.

Fallstudien erfordern eine zusätzliche Grenze: Entweder holen Sie die ausdrückliche Erlaubnis ein, echte Kundeninformationen zu zeigen, oder Sie bauen das Interface mit klar offengelegten Demodaten nach und behandeln es als Workflow-Illustration, nicht als Ergebnisbeleg. Schwärzung ist kein Ersatz für Zustimmung oder eine kontrollierte Umgebung.

QA-Checkliste

Ein Prüfer kontrolliert Kommunikations- und Wartungsrisiken vor der visuellen Nachbearbeitung.

  • Zweck: Die Abbildung löst eine räumliche Mehrdeutigkeit auf oder beweist eine sichtbare Interface-Behauptung.
  • Notwendigkeit: Routineschritte bleiben Text; die Seite weist nicht standardmäßig jedem Schritt einen Screenshot zu.
  • Echter Zustand: Die Aufnahme zeigt das exakt offene Menü, den ausgewählten Filter, das Ergebnis oder den Fehler, der im Text besprochen wird.
  • Demodaten: Keine Kunden-, Mitarbeiter-, Konto-, Browser-, Token-, Prompt- oder Abrechnungsinformationen sind sichtbar.
  • Aufnahmekonsistenz: Viewport, 2-fache Dichte, Thema, Interface-Zustand und Browser-Chrome-Regel entsprechen dem Standard.
  • Fokussierter Beschnitt: Genug Kontext für die Orientierung bleibt erhalten, aber unzusammenhängende Interface-Bereiche konkurrieren nicht mit dem Ziel.
  • Markierungen: Es gibt ein bis sechs fortlaufende Nummern, jede kontrastreich, lesbar und frei von Beschriftungen und Werten.
  • Externe Legende: Jede Markierung hat einen passenden Eintrag in einer geordneten Liste im Seitentext; keine Legendenformulierung ist in Pixel eingebacken.
  • Bildunterschrift: Die Abbildung hat eine prägnante sichtbare Bildunterschrift, die ihren Bildschirm, Zustand und ihr Szenario benennt.
  • Alt-Text: Die alt.yaml des Ordners enthält einen exakten Dateinamenschlüssel und eine kontextbezogene Beschreibung innerhalb des Ziellängenbereichs.
  • Mobiles Verhalten: Das Ziel und die Markierungen bleiben ohne horizontalen Scrollen auf Seitenebene oder erforderliches Zoomen lesbar; andernfalls existiert ein fokussierter Ausschnitt.
  • Dateivertrag: Pfad, Lowercase-Kebab-Case-Name, Format, Abmessungen und intrinsische Größe folgen dem Auslieferungsstandard.
  • Aktualität: screenId und Aufnahmedatum sind aufgezeichnet, das Live-UI stimmt noch überein und alle Referenzen sind per Textsuche auffindbar.
  • Portable Parität: Markdown-, Hugo- und WordPress-Darstellungen bewahren dasselbe Asset, dieselbe Bildunterschrift, Markierungsreihenfolge und Legendenformulierung.
  • Kein defektes Asset: Ein echter Bildpfad erscheint erst, nachdem die Datei existiert; ausstehende Aufnahmen bleiben Kommentare und behalten screenshotsPending = true.

FAQ

Die Academy-Vorlage rendert die fünf überprüften Fragen, die in diesem [[faq]]-Frontmatter der Seite gespeichert sind. Sie behandeln Screenshot-Häufigkeit, externe Legenden, Alt-Text-Länge, Neuaufnahme-Auslöser und die Browser-Chrome-Ausnahme.

← All SEO Playbook guides

Bereit, es in die Praxis umzusetzen?

Kostenlose Prüfung · 7 Tage testen · keine Kreditkarte