Eine Seite zeigt nicht die ganze Fähigkeit
Ein polierter Artikel zeigt, dass du polierten Text schreiben kannst. Er zeigt nicht, wie du fehlende Informationen gefunden, Zielgruppen definiert, Konflikte gelöst oder Instructions verifiziert hast.
Mache jede Probe zu einer kleinen Case Study.
Erkläre zuerst das Problem
Beschreibe, wer der Leser war, was er erreichen wollte und welche Constraints galten: unvollständiges Produktverhalten, mehrere Versionen, knapper Release-Termin, regulierte Terminologie oder Migration.
Zeige danach, was du geändert hast und warum. Ein Vorher/Nachher der Struktur kann informativer sein als ein finaler Screenshot.
Nutze unterschiedliche Evidenz
Eine Probe kann ein Procedure sein, eine API Reference, Informationsarchitektur oder Quality Automation. Proprietäre Arbeit lässt sich mit Open-Source-Software nachbilden oder sinnvoll anonymisieren.
Zeige Verification
Erkläre, wie Commands getestet, Examples validiert und Subject-Matter Experts einbezogen wurden. Behaupte keinen Business Impact ohne Evidenz.
Mache Review einfach
Drei starke Case Studies sind meist nützlicher als zwanzig unverbundene Links. Gib kurze Zusammenfassungen, direkten Zugang zum Artifact und prüfe Links, Bilder und Berechtigungen.
Das Portfolio soll beantworten: Welche Dokumentationsprobleme kann diese Person bei uns lösen?
Praxisbeispiel
Mach aus „Ein Technical-Writing-Portfolio sollte Entscheidungen zeigen, nicht nur Seiten“ eine kurze Übung mit beobachtbarem Ergebnis. Wähle ein Artefakt, das in ein oder zwei Sitzungen fertig wird: eine einseitige Prozedur, ein API-Beispiel, ein Vorher/Nachher-Edit, Terminologie-Bereinigung oder einen kleinen Portfolio-Fall. Definiere vorab, was „besser“ bedeutet.
Bewahre Belege des Prozesses auf:
- ursprüngliches Problem und Zielgruppe;
- Entscheidungen und verworfene Alternativen;
- Feedback eines Lesers, Reviewers oder Fachexperten;
- eine Änderung für den nächsten Versuch.
Das lehrt mehr als passives Sammeln von Kursen. Technisches Schreiben besteht aus wiederholten Entscheidungen unter Einschränkungen; eine kleine abgeschlossene Übung mit echtem Review ist wertvoller als ein theoretisches Großprojekt ohne Leser.
Kurzer Redaktionscheck
- Eine Seite zeigt nicht die ganze Fähigkeit. Ein polierter Artikel zeigt, dass du polierten Text schreiben kannst.
- Erkläre zuerst das Problem. Beschreibe, wer der Leser war, was er erreichen wollte und welche Constraints galten: unvollständiges Produktverhalten, mehrere Versionen, knapper Release-Termin, regulierte Terminologie oder Migration.
- Nutze unterschiedliche Evidenz. Eine Probe kann ein Procedure sein, eine API Reference, Informationsarchitektur oder Quality Automation.
- Zeige Verification. Erkläre, wie Commands getestet, Examples validiert und Subject-Matter Experts einbezogen wurden.
