<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"><channel><title>TechWriters — DE</title><link>https://techwriters.org/de/</link><description>TechWriters localized technical-writing feed.</description><item><title>Barrierefreie Codebeispiele und Tabellen in der technischen Dokumentation</title><link>https://techwriters.org/de/articles/accessible-code-examples-and-tables/</link><guid>https://techwriters.org/de/articles/accessible-code-examples-and-tables/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Barrierefreiheit in der Dokumentation endet nicht bei Navigation und Kontrast. Auch Codebeispiele, JSON-Antworten und Referenztabellen müssen ohne reine Farbcodierung verständlich und nutzbar bleiben.</description></item><item><title>KI als Redakteur nutzen, nicht als Orakel</title><link>https://techwriters.org/de/articles/ai-as-editor-not-oracle/</link><guid>https://techwriters.org/de/articles/ai-as-editor-not-oracle/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „KI als Redakteur nutzen, nicht als Orakel“, der langfristig wartbare Dokumentation unterstützt. „KI als Redakteur nutzen, nicht als Orakel“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>AI-gestützte Dokumentation prüfen, bevor flüssige Fehler live gehen</title><link>https://techwriters.org/de/articles/ai-fact-checking-for-docs/</link><guid>https://techwriters.org/de/articles/ai-fact-checking-for-docs/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Generativer Text kann vollständig klingen und dabei Defaults, Garantien oder Quellen erfinden. Baue Verifikation um autoritative Quellen, ausführbare Beispiele und sichtbare Unsicherheit. Der gefährliche AI-Fehler in Dokumentation ist selten schlechte Grammatik.</description></item><item><title>KI kann Dokumentation schreiben. Was soll ein Technical Writer jetzt tun?</title><link>https://techwriters.org/de/articles/ai-learned-to-write-documentation/</link><guid>https://techwriters.org/de/articles/ai-learned-to-write-documentation/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>In drei Jahren hat generative KI den ersten Entwurf von einem teuren Ergebnis zu einer billigen Operation gemacht. Entscheidend ist heute, wer Fakten, Struktur, Review, Aktualisierung und Qualität verantwortet.</description></item><item><title>API-Beispiele sollten einen Workflow lehren, nicht die Reference dekorieren</title><link>https://techwriters.org/de/articles/api-examples-that-teach/</link><guid>https://techwriters.org/de/articles/api-examples-that-teach/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein technisch gültiger Request ist noch kein gutes Beispiel. Verwende realistische Werte und Sequenzen, die das mentale Modell der API zeigen und den nächsten Schritt vorhersehbar machen. Ein aus dem Schema erzeugtes Beispiel kann syntaktisch korrekt und didaktisch wertlos sein.</description></item><item><title>Authentifizierungsdokumentation, die Support-Tickets verhindert</title><link>https://techwriters.org/de/articles/authentication-docs-that-prevent-support-tickets/</link><guid>https://techwriters.org/de/articles/authentication-docs-that-prevent-support-tickets/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Authentifizierungsdokumentation, die Support-Tickets verhindert“, der langfristig wartbare Dokumentation unterstützt. „Authentifizierungsdokumentation, die Support-Tickets verhindert“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Was Technical Writer 2026 lesen sollten: lebende Guides und Bücher, die noch tragen</title><link>https://techwriters.org/de/articles/books-and-guides-for-technical-writers/</link><guid>https://techwriters.org/de/articles/books-and-guides-for-technical-writers/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Eine nützliche Leseliste ist heute keine Sammlung von Klassikern. Vergleichen Sie aktuelle Leitfäden von Microsoft, Google, GitHub und IBM, prüfen Sie Strukturen mit Diátaxis und machen Sie aus jeder Lektüre eine konkrete Dokumentationsübung.</description></item><item><title>Einen Dokumentationsgenerator wählen, ohne eine Religion zu wählen</title><link>https://techwriters.org/de/articles/choosing-a-docs-generator/</link><guid>https://techwriters.org/de/articles/choosing-a-docs-generator/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Sphinx, MkDocs, Astro und andere Generatoren optimieren unterschiedliche Content Models und Teams. Entscheide nach Authoring Workflow, Erweiterbarkeit, Lokalisierung und Wartungskosten statt nach einer schönen Demo. Eine beeindruckende Demo kann für deine Dokumentation trotzdem falsch sein.</description></item><item><title>Suche für Dokumentation wählen: bei Fehlerszenarien beginnen</title><link>https://techwriters.org/de/articles/choosing-search-for-docs/</link><guid>https://techwriters.org/de/articles/choosing-search-for-docs/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Suche für Dokumentation wählen: bei Fehlerszenarien beginnen“, der langfristig wartbare Dokumentation unterstützt. „Suche für Dokumentation wählen: bei Fehlerszenarien beginnen“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Gezieltes Üben für Technical Writer: die Arbeit trainieren, nicht Buzzwords</title><link>https://techwriters.org/de/articles/deliberate-practice-for-docs/</link><guid>https://techwriters.org/de/articles/deliberate-practice-for-docs/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Über Dokumentation zu lesen hilft, aber Fähigkeiten wachsen schneller durch wiederholte kleine Übungen zu Recherche, Struktur, Editing und Verification mit klarem Feedback. „Besser im Technical Writing werden“ ist zu breit.</description></item><item><title>Diagramme als Code: wann sie helfen und wann nicht</title><link>https://techwriters.org/de/articles/diagrams-as-code-in-documentation/</link><guid>https://techwriters.org/de/articles/diagrams-as-code-in-documentation/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Diagramme als Code: wann sie helfen und wann nicht“, der langfristig wartbare Dokumentation unterstützt. „Diagramme als Code: wann sie helfen und wann nicht“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Docs-as-Code ohne Fanatismus</title><link>https://techwriters.org/de/articles/docs-as-code-without-fanaticism/</link><guid>https://techwriters.org/de/articles/docs-as-code-without-fanaticism/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Docs-as-Code bedeutet nicht, alle Schreibenden in eine IDE zu zwingen. Entscheidend sind versionierte Quellen, einfache Browser-Bearbeitung, nützliche automatische Checks, sinnvolles Review und eine messbar bessere Veröffentlichung.</description></item><item><title>Dokumentationswerkzeuge damals und heute: Was sich wirklich geändert hat</title><link>https://techwriters.org/de/articles/docs-tools-then-and-now/</link><guid>https://techwriters.org/de/articles/docs-tools-then-and-now/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Formate und Publishing Pipelines haben sich stark verändert, die langlebigen Probleme sind vertraut: Source Control, Reuse, Navigation, Review und Synchronisierung mit dem Produkt. Lange bevor Docs-as-Code ein Begriff war, kämpften Teams mit mehreren Source Files, wiederverwendeten Fragmenten, Versionen und der Frage, welche Kopie aktuell ist.</description></item><item><title>Dokumentationsschulden: Was Nutzern wirklich schadet</title><link>https://techwriters.org/de/articles/documentation-debt-triage/</link><guid>https://techwriters.org/de/articles/documentation-debt-triage/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Dokumentationsschulden: Was Nutzern wirklich schadet“, der langfristig wartbare Dokumentation unterstützt. „Dokumentationsschulden: Was Nutzern wirklich schadet“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Dokumentation in CI/CD</title><link>https://techwriters.org/de/articles/documentation-in-ci-cd/</link><guid>https://techwriters.org/de/articles/documentation-in-ci-cd/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Dokumentation als Build-Artefakt behandeln: Struktur, Links, Beispiele und Publikationsregeln vor der Veröffentlichung prüfen. CI kann nicht beurteilen, ob eine Erklärung nützlich ist, aber vorhersehbare Defekte vor dem menschlichen Review abfangen.</description></item><item><title>Dokumentation führen, ohne Bürokratie aufzubauen</title><link>https://techwriters.org/de/articles/documentation-lead-without-bureaucracy/</link><guid>https://techwriters.org/de/articles/documentation-lead-without-bureaucracy/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein Documentation Lead sollte Unsicherheit reduzieren statt eine zusätzliche Freigabestufe zu schaffen. Definiere Ownership, Standards und Eskalation, während Routine-Publishing schnell und nah am Produkt bleibt. Sobald Dokumentation über mehrere Teams verteilt ist, entsteht der Wunsch nach zentraler Kontrolle.</description></item><item><title>Dokumentationsmetriken, die mehr aussagen als Seitenaufrufe</title><link>https://techwriters.org/de/articles/documentation-metrics-that-matter/</link><guid>https://techwriters.org/de/articles/documentation-metrics-that-matter/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Dokumentationsmetriken, die mehr aussagen als Seitenaufrufe“, der langfristig wartbare Dokumentation unterstützt. „Dokumentationsmetriken, die mehr aussagen als Seitenaufrufe“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Eine Ownership-Karte für Dokumentation ohne Bürokratie</title><link>https://techwriters.org/de/articles/documentation-ownership-map/</link><guid>https://techwriters.org/de/articles/documentation-ownership-map/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Eine Ownership-Karte für Dokumentation ohne Bürokratie“, der langfristig wartbare Dokumentation unterstützt. „Eine Ownership-Karte für Dokumentation ohne Bürokratie“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Dokumentations-Reviews organisieren</title><link>https://techwriters.org/de/articles/documentation-review-workflow/</link><guid>https://techwriters.org/de/articles/documentation-review-workflow/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein guter Review-Prozess macht Verantwortung sichtbar, verkürzt Wartezeiten und trennt fachliche, redaktionelle und produktseitige Prüfung. Autor, fachlichen Reviewer, Redaktion und finalen Owner definieren.</description></item><item><title>API-Fehler so dokumentieren, dass Entwickler reagieren können</title><link>https://techwriters.org/de/articles/documenting-api-errors/</link><guid>https://techwriters.org/de/articles/documenting-api-errors/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „API-Fehler so dokumentieren, dass Entwickler reagieren können“, der langfristig wartbare Dokumentation unterstützt. „API-Fehler so dokumentieren, dass Entwickler reagieren können“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>REST API richtig dokumentieren</title><link>https://techwriters.org/de/articles/documenting-rest-api/</link><guid>https://techwriters.org/de/articles/documenting-rest-api/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Gute API-Dokumentation verbindet maschinenlesbare Verträge mit Erklärungen, ausführbaren Beispielen und klar beschriebenem Fehlerverhalten. REST-API-Dokumentation hat zwei Zielgruppen: Maschinen und Menschen.</description></item><item><title>Redaktionsübungen, die technisches Schreiben schneller verbessern</title><link>https://techwriters.org/de/articles/editing-drills-for-technical-writers/</link><guid>https://techwriters.org/de/articles/editing-drills-for-technical-writers/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Redaktionsübungen, die technisches Schreiben schneller verbessern“, der langfristig wartbare Dokumentation unterstützt. „Redaktionsübungen, die technisches Schreiben schneller verbessern“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Wie man 2026 in Technical Writing einsteigt</title><link>https://techwriters.org/de/articles/entering-technical-writing/</link><guid>https://techwriters.org/de/articles/entering-technical-writing/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Vor drei Jahren konnten klare Sprache, einige Werkzeuge und ein Portfolio für den Einstieg reichen. 2026 ist die Hürde höher: KI erzeugt Entwürfe, Teams sind kleiner und von Technical Writers werden Faktenprüfung, API-Verständnis, Git und Verantwortung für das Dokumentationssystem erwartet.</description></item><item><title>Die ersten 90 Tage in einem Dokumentationsteam</title><link>https://techwriters.org/de/articles/first-90-days-in-documentation-team/</link><guid>https://techwriters.org/de/articles/first-90-days-in-documentation-team/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Die ersten 90 Tage in einem Dokumentationsteam“, der langfristig wartbare Dokumentation unterstützt. „Die ersten 90 Tage in einem Dokumentationsteam“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Alte Dokumentationsfragen, die erstaunlich gut gealtert sind</title><link>https://techwriters.org/de/articles/forum-questions-that-aged-well/</link><guid>https://techwriters.org/de/articles/forum-questions-that-aged-well/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Tool-Namen ändern sich schneller als redaktionelle Probleme. Ownership, Terminologie, Screenshots, Reuse und Review tauchen immer wieder auf, weil sie tiefere Systementscheidungen widerspiegeln. Die technische Antwort wechselte von Shared Folders zu Repositories und Ownership Rules.</description></item><item><title>Begriffe und Definitionen: ein Terminologiesystem aufbauen</title><link>https://techwriters.org/de/articles/glossaries-and-terminology/</link><guid>https://techwriters.org/de/articles/glossaries-and-terminology/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein Glossar wird nützlich, wenn es Entscheidungen in Produkt, Interface und Dokumentation steuert statt nur Wörter zu sammeln. Ein guter Eintrag enthält bevorzugten Begriff, Definition, verbotene oder veraltete Varianten, Kontext und Owner.</description></item><item><title>Technische Redakteure ohne Tricktests einstellen</title><link>https://techwriters.org/de/articles/hiring-technical-writers-without-trick-tests/</link><guid>https://techwriters.org/de/articles/hiring-technical-writers-without-trick-tests/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Technische Redakteure ohne Tricktests einstellen“, der langfristig wartbare Dokumentation unterstützt. „Technische Redakteure ohne Tricktests einstellen“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Hypertext vor modernen Dokumentationsportalen</title><link>https://techwriters.org/de/articles/hypertext-before-modern-docs-portals/</link><guid>https://techwriters.org/de/articles/hypertext-before-modern-docs-portals/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Hypertext vor modernen Dokumentationsportalen“, der langfristig wartbare Dokumentation unterstützt. „Hypertext vor modernen Dokumentationsportalen“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Informationsarchitektur für Dokumentation, die weiter wächst</title><link>https://techwriters.org/de/articles/information-architecture-for-growing-docs/</link><guid>https://techwriters.org/de/articles/information-architecture-for-growing-docs/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Eine Struktur, die bei fünfzig Seiten funktioniert, kann bei fünfhundert scheitern. Navigation sollte sich an Nutzeraufgaben, Inhaltstypen und stabilen Konzepten orientieren — nicht am Organigramm. Kleine Dokumentationsbestände überleben fast jede Navigation.</description></item><item><title>API-Dokumentation mit einer kleinen eigenen API lernen</title><link>https://techwriters.org/de/articles/learn-api-docs-by-building-a-small-api/</link><guid>https://techwriters.org/de/articles/learn-api-docs-by-building-a-small-api/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „API-Dokumentation mit einer kleinen eigenen API lernen“, der langfristig wartbare Dokumentation unterstützt. „API-Dokumentation mit einer kleinen eigenen API lernen“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Guardrails für eine LLM-Content-Pipeline, die technische Dokumentation publiziert</title><link>https://techwriters.org/de/articles/llm-content-pipeline-guardrails/</link><guid>https://techwriters.org/de/articles/llm-content-pipeline-guardrails/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Wenn ein Modell Content in großem Maßstab erstellt oder ändert, muss Validation mitskalieren. Begrenze Inputs, bewahre Provenance, validiere Struktur und trenne Generation von privilegiertem Publishing. Eine gute Architektur nimmt an, dass das Modell manchmal falsch liegt.</description></item><item><title>Markdown im großen Maßstab: Regeln gegen Repository-Chaos</title><link>https://techwriters.org/de/articles/markdown-at-scale/</link><guid>https://techwriters.org/de/articles/markdown-at-scale/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Markdown im großen Maßstab: Regeln gegen Repository-Chaos“, der langfristig wartbare Dokumentation unterstützt. „Markdown im großen Maßstab: Regeln gegen Repository-Chaos“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>OpenAPI ist eine Wahrheitsquelle, aber nicht die gesamte API-Dokumentation</title><link>https://techwriters.org/de/articles/openapi-as-source-not-documentation/</link><guid>https://techwriters.org/de/articles/openapi-as-source-not-documentation/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Eine OpenAPI-Beschreibung kann eine präzise Reference erzeugen. Developers brauchen zusätzlich Konzepte, Task Flows, Authentifizierung, Beispiele und Recovery, die ein Schema allein nicht erklärt. OpenAPI beschreibt Operations, Parameter, Request- und Response-Strukturen, Status Codes und wiederverwendbare Schemas sehr gut.</description></item><item><title>Ein Technical-Writing-Portfolio sollte Entscheidungen zeigen, nicht nur Seiten</title><link>https://techwriters.org/de/articles/portfolio-for-technical-writer/</link><guid>https://techwriters.org/de/articles/portfolio-for-technical-writer/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Hiring Teams brauchen Evidenz dafür, wie du recherchierst, strukturierst und verifizierst. Ein starkes Portfolio erklärt Problem, Constraints, Prozess und Ergebnis statt nur polierte Screenshots zu zeigen. Ein polierter Artikel zeigt, dass du polierten Text schreiben kannst.</description></item><item><title>Release Notes, aus denen Nutzer konkrete Schritte ableiten können</title><link>https://techwriters.org/de/articles/release-notes-users-can-act-on/</link><guid>https://techwriters.org/de/articles/release-notes-users-can-act-on/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Release Notes, aus denen Nutzer konkrete Schritte ableiten können“, der langfristig wartbare Dokumentation unterstützt. „Release Notes, aus denen Nutzer konkrete Schritte ableiten können“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Strukturierte Schreibregeln, die bei Hunderten Mitwirkenden funktionieren</title><link>https://techwriters.org/de/articles/structured-writing-rules-that-scale/</link><guid>https://techwriters.org/de/articles/structured-writing-rules-that-scale/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Konsistenz im großen Maßstab entsteht durch Content Models, Terminologie und wiederverwendbare Patterns — nicht dadurch, dass alle einen riesigen Style Guide auswendig lernen. Wichtige Regeln gehören in Schemas und Components. Ein kleines Team kann auf gemeinsame Gewohnheiten und direktes Editing vertrauen.</description></item><item><title>Ein Styleguide, den Menschen tatsächlich benutzen</title><link>https://techwriters.org/de/articles/style-guide-people-use/</link><guid>https://techwriters.org/de/articles/style-guide-people-use/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Ein Styleguide, den Menschen tatsächlich benutzen“, der langfristig wartbare Dokumentation unterstützt. „Ein Styleguide, den Menschen tatsächlich benutzen“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Synthetische Beispiele: nützlicher Entwurf, gefährlicher Beleg</title><link>https://techwriters.org/de/articles/synthetic-examples-and-hallucinations/</link><guid>https://techwriters.org/de/articles/synthetic-examples-and-hallucinations/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Synthetische Beispiele: nützlicher Entwurf, gefährlicher Beleg“, der langfristig wartbare Dokumentation unterstützt. „Synthetische Beispiele: nützlicher Entwurf, gefährlicher Beleg“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Was ist vom technischen Redakteur von 2006 geblieben?</title><link>https://techwriters.org/de/articles/technical-writer-2006/</link><guid>https://techwriters.org/de/articles/technical-writer-2006/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Die Werkzeuge haben sich radikal verändert, doch der Kern bleibt erstaunlich vertraut: Zielgruppe, Belege, Struktur, Terminologie und Verantwortung. 2006 waren Desktop-Publishing, Office-Formate und manuell gepflegte Hilfesysteme wesentlich verbreiteter.</description></item><item><title>Eine Kompetenzmatrix für Technical Writer, die echte Arbeit misst</title><link>https://techwriters.org/de/articles/technical-writer-skills-matrix/</link><guid>https://techwriters.org/de/articles/technical-writer-skills-matrix/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Eine gute Matrix unterstützt Entwicklung und Hiring. Eine schlechte macht aus vagen Eigenschaften scheinpräzise Zahlen. Bewerte beobachtbare Fähigkeiten und die Komplexität der Dokumentationsprobleme, die jemand übernehmen kann. Teams bauen Kompetenzmatrizen oft dann, wenn Hiring inkonsistent oder Beförderungen subjektiv werden.</description></item><item><title>Vale als Quality Gate statt als Zeichensetzungspolizei</title><link>https://techwriters.org/de/articles/vale-style-linting/</link><guid>https://techwriters.org/de/articles/vale-style-linting/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Style Linting ist wertvoll, wenn es Terminologiedrift, riskante Formulierungen und wiederholbare redaktionelle Fehler findet. Halte Regeln klein, erklärbar und so leise, dass ein Fehlschlag ernst genommen wird. Ein Linter kann Tausende Sätze in Sekunden prüfen, deshalb ist die Versuchung groß, jede Stilpräferenz zu kodieren.</description></item><item><title>WCAG 2.2 für Dokumentationsteams: praktische Einstiegspunkte</title><link>https://techwriters.org/de/articles/wcag-22-for-documentation/</link><guid>https://techwriters.org/de/articles/wcag-22-for-documentation/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Accessibility ist nicht nur Frontend-Arbeit. Autoren bestimmen Heading-Struktur, Linkzweck, Alt Text, Tabellen, Anweisungen und die Semantik, auf die assistive Technologien angewiesen sind. Ein Theme kann guten Kontrast und Keyboard-Verhalten liefern, aber Autoren entscheiden weiterhin über Verständlichkeit.</description></item><item><title>Als Handbücher noch auf CD ausgeliefert wurden</title><link>https://techwriters.org/de/articles/when-manuals-shipped-on-cd/</link><guid>https://techwriters.org/de/articles/when-manuals-shipped-on-cd/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Als Handbücher noch auf CD ausgeliefert wurden“, der langfristig wartbare Dokumentation unterstützt. „Als Handbücher noch auf CD ausgeliefert wurden“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item><item><title>Mit Fachexperten arbeiten, ohne jedes Review zum Meeting zu machen</title><link>https://techwriters.org/de/articles/working-with-subject-matter-experts/</link><guid>https://techwriters.org/de/articles/working-with-subject-matter-experts/</guid><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><description>Ein praktischer und prüfbarer Ansatz für „Mit Fachexperten arbeiten, ohne jedes Review zum Meeting zu machen“, der langfristig wartbare Dokumentation unterstützt. „Mit Fachexperten arbeiten, ohne jedes Review zum Meeting zu machen“ mit einem praktischen, prüfbaren und wartbaren Ansatz für technische Dokumentation.</description></item></channel></rss>