<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title><![CDATA[Forum von Schübeler Consulting - 📚 Struktur & Verständlichkeit ]]></title>
		<link>https://forum.schuebeler-consulting.de/</link>
		<description><![CDATA[Forum von Schübeler Consulting - https://forum.schuebeler-consulting.de]]></description>
		<pubDate>Tue, 21 Jul 2026 18:20:03 +0000</pubDate>
		<generator>MyBB</generator>
		<item>
			<title><![CDATA[Information Mapping ist kein Wundermittel, aber ein guter Hebel]]></title>
			<link>https://forum.schuebeler-consulting.de/thread-50.html</link>
			<pubDate>Thu, 21 May 2026 20:12:04 +0200</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.schuebeler-consulting.de/member.php?action=profile&uid=2">Johann Jörgen Schübeler</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.schuebeler-consulting.de/thread-50.html</guid>
			<description><![CDATA[Information Mapping wird immer mal wieder als das eine große Strukturkonzept verkauft. Manchmal von Beratern, die genau diese Methode lizenziert verkaufen. Ich halte nichts von Zaubermitteln. Aber ich halte sehr viel von dem Grundgedanken dahinter.<br />
<br />
Der Kern ist simpel: Jeder Informationsblock hat genau eine Aufgabe. Eine Definition, eine Anleitung, eine Begründung, eine Tabelle. Alles in einem Absatz zu vermischen, schadet. Wenn Sie diese Trennung konsequent durchhalten, werden Ihre Texte automatisch besser, auch ohne dass Sie die volle Methode kaufen.<br />
<br />
Was Sie davon mitnehmen können, auch ohne Lizenz:<br />
<ul class="mycode_list"><li>Aussagekräftige Zwischenüberschriften, die den Inhalt vorwegnehmen.<br />
</li>
<li>Kurze Blöcke statt Bleiwüste. Drei bis sieben Zeilen sind eine gute Hausnummer.<br />
</li>
<li>Listen für Aufzählungen. Tabellen für Vergleiche. Fließtext für Zusammenhänge. Setzen Sie das passende Format ein, statt alles als Fließtext zu schreiben, weil es schnell geht.</li>
</ul>
<br />
Das klingt banal. Wenn ich Bestandsdokumente analysiere, finde ich diese Disziplin trotzdem fast nie. Stattdessen lange Absätze, in denen Definition, Anweisung und Warnhinweis ineinanderfließen. Der Leser muss dann selber heraussortieren, was gerade dran ist. Das ist Ihre Aufgabe, nicht seine.<br />
<br />
Welchen Strukturansatz nutzen Sie in Ihrer Redaktion?]]></description>
			<content:encoded><![CDATA[Information Mapping wird immer mal wieder als das eine große Strukturkonzept verkauft. Manchmal von Beratern, die genau diese Methode lizenziert verkaufen. Ich halte nichts von Zaubermitteln. Aber ich halte sehr viel von dem Grundgedanken dahinter.<br />
<br />
Der Kern ist simpel: Jeder Informationsblock hat genau eine Aufgabe. Eine Definition, eine Anleitung, eine Begründung, eine Tabelle. Alles in einem Absatz zu vermischen, schadet. Wenn Sie diese Trennung konsequent durchhalten, werden Ihre Texte automatisch besser, auch ohne dass Sie die volle Methode kaufen.<br />
<br />
Was Sie davon mitnehmen können, auch ohne Lizenz:<br />
<ul class="mycode_list"><li>Aussagekräftige Zwischenüberschriften, die den Inhalt vorwegnehmen.<br />
</li>
<li>Kurze Blöcke statt Bleiwüste. Drei bis sieben Zeilen sind eine gute Hausnummer.<br />
</li>
<li>Listen für Aufzählungen. Tabellen für Vergleiche. Fließtext für Zusammenhänge. Setzen Sie das passende Format ein, statt alles als Fließtext zu schreiben, weil es schnell geht.</li>
</ul>
<br />
Das klingt banal. Wenn ich Bestandsdokumente analysiere, finde ich diese Disziplin trotzdem fast nie. Stattdessen lange Absätze, in denen Definition, Anweisung und Warnhinweis ineinanderfließen. Der Leser muss dann selber heraussortieren, was gerade dran ist. Das ist Ihre Aufgabe, nicht seine.<br />
<br />
Welchen Strukturansatz nutzen Sie in Ihrer Redaktion?]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Handlungsanweisungen: ein Schritt pro Satz, ein Verb pro Schritt]]></title>
			<link>https://forum.schuebeler-consulting.de/thread-77.html</link>
			<pubDate>Wed, 21 Jan 2026 21:23:37 +0100</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.schuebeler-consulting.de/member.php?action=profile&uid=2">Johann Jörgen Schübeler</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.schuebeler-consulting.de/thread-77.html</guid>
			<description><![CDATA[Ich sehe in Anleitungen immer wieder denselben Fehler: Ein Schritt enthält drei Handlungen, einen Hinweis und eine Bedingung. Das liest niemand mehr als Schritt, das liest man als Absatz.<br />
<br />
Mein Vorgehen ist stur und langweilig. Es funktioniert trotzdem:<br />
<ul class="mycode_list"><li>Pro Schritt genau eine Handlung. Wenn Sie zwei Verben brauchen, sind es zwei Schritte.<br />
</li>
<li>Imperativ am Satzanfang. "Klicken Sie", "Drücken Sie", "Prüfen Sie". Kein "Es wird nun" und kein "Sie könnten".<br />
</li>
<li>Bedingungen vor die Handlung. "Wenn die LED rot blinkt, drücken Sie Reset." Und nicht umgekehrt: "Drücken Sie Reset, falls die LED rot blinkt."<br />
</li>
<li>Ergebnis am Ende, aber nur, wenn es nicht offensichtlich ist. "Das Gerät startet neu" ist Fülltext, wenn man den Neustart hört.<br />
</li>
</ul>
<br />
Diese Form ist auch für die Übersetzung freundlich. Kurze Sätze, klare Verben, keine Schachtelei. Was im Deutschen liest, liest sich auch in einer romanischen Sprache halbwegs ohne Schmerzen.<br />
<br />
Wo ich noch zögere: Nummerierung bei reinen Bedienschritten ja, bei Wartungs-Routinen mit Schleifen eher nein. Da arbeite ich mit Phasen-Überschriften und nummeriere nur innerhalb der Phase.<br />
<br />
Wie halten Sie das? Streng durchnummeriert oder mit Phasen?]]></description>
			<content:encoded><![CDATA[Ich sehe in Anleitungen immer wieder denselben Fehler: Ein Schritt enthält drei Handlungen, einen Hinweis und eine Bedingung. Das liest niemand mehr als Schritt, das liest man als Absatz.<br />
<br />
Mein Vorgehen ist stur und langweilig. Es funktioniert trotzdem:<br />
<ul class="mycode_list"><li>Pro Schritt genau eine Handlung. Wenn Sie zwei Verben brauchen, sind es zwei Schritte.<br />
</li>
<li>Imperativ am Satzanfang. "Klicken Sie", "Drücken Sie", "Prüfen Sie". Kein "Es wird nun" und kein "Sie könnten".<br />
</li>
<li>Bedingungen vor die Handlung. "Wenn die LED rot blinkt, drücken Sie Reset." Und nicht umgekehrt: "Drücken Sie Reset, falls die LED rot blinkt."<br />
</li>
<li>Ergebnis am Ende, aber nur, wenn es nicht offensichtlich ist. "Das Gerät startet neu" ist Fülltext, wenn man den Neustart hört.<br />
</li>
</ul>
<br />
Diese Form ist auch für die Übersetzung freundlich. Kurze Sätze, klare Verben, keine Schachtelei. Was im Deutschen liest, liest sich auch in einer romanischen Sprache halbwegs ohne Schmerzen.<br />
<br />
Wo ich noch zögere: Nummerierung bei reinen Bedienschritten ja, bei Wartungs-Routinen mit Schleifen eher nein. Da arbeite ich mit Phasen-Überschriften und nummeriere nur innerhalb der Phase.<br />
<br />
Wie halten Sie das? Streng durchnummeriert oder mit Phasen?]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Zielgruppe ehrlich definieren, oder Sie schreiben für sich selbst]]></title>
			<link>https://forum.schuebeler-consulting.de/thread-73.html</link>
			<pubDate>Thu, 08 Jan 2026 20:21:21 +0100</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.schuebeler-consulting.de/member.php?action=profile&uid=2">Johann Jörgen Schübeler</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.schuebeler-consulting.de/thread-73.html</guid>
			<description><![CDATA[In jedem zweiten Projekt frage ich am Anfang: Für wen schreiben Sie das eigentlich? Antwort: "Für den Endanwender." Auf Nachfrage stellt sich heraus, dass damit alles gemeint ist, vom Servicetechniker bis zur Einkäuferin.<br />
<br />
Wenn die Zielgruppe nicht greifbar ist, schreibt der Autor unbewusst für den Menschen, den er am besten kennt: sich selbst. Das Ergebnis sind Texte, die der Entwickler super findet und die Werkstatt nicht versteht.<br />
<br />
Mein pragmatischer Weg, ohne große Persona-Workshops:<br />
<ul class="mycode_list"><li>Drei reale Personen benennen, die das Dokument nutzen werden. Mit Funktion, Vorwissen, Sprache, Gerät.<br />
</li>
<li>Für jede dieser Personen einen Satz festhalten, was bei ihr <span style="font-weight: bold;" class="mycode_b">nicht</span> vorausgesetzt werden darf.<br />
</li>
<li>Den fertigen Text gegen genau diese drei Profile prüfen, nicht gegen "den Anwender".<br />
</li>
</ul>
<br />
Das dauert eine halbe Stunde und verändert die Texte mehr als jedes Stilhandbuch.<br />
<br />
Was mir noch hilft: ein verbotener Wortschatz. Begriffe, die in der Entwicklungsabteilung normal sind, im Anwenderdokument aber nichts verloren haben. Den pflege ich pro Kunde in einer kleinen Liste, nicht in einem großen Terminologie-System. Klein anfangen, sonst fangen Sie nie an.<br />
<br />
Haben Sie tatsächlich definierte Zielgruppen pro Dokument, oder steht da auch "Endanwender"?]]></description>
			<content:encoded><![CDATA[In jedem zweiten Projekt frage ich am Anfang: Für wen schreiben Sie das eigentlich? Antwort: "Für den Endanwender." Auf Nachfrage stellt sich heraus, dass damit alles gemeint ist, vom Servicetechniker bis zur Einkäuferin.<br />
<br />
Wenn die Zielgruppe nicht greifbar ist, schreibt der Autor unbewusst für den Menschen, den er am besten kennt: sich selbst. Das Ergebnis sind Texte, die der Entwickler super findet und die Werkstatt nicht versteht.<br />
<br />
Mein pragmatischer Weg, ohne große Persona-Workshops:<br />
<ul class="mycode_list"><li>Drei reale Personen benennen, die das Dokument nutzen werden. Mit Funktion, Vorwissen, Sprache, Gerät.<br />
</li>
<li>Für jede dieser Personen einen Satz festhalten, was bei ihr <span style="font-weight: bold;" class="mycode_b">nicht</span> vorausgesetzt werden darf.<br />
</li>
<li>Den fertigen Text gegen genau diese drei Profile prüfen, nicht gegen "den Anwender".<br />
</li>
</ul>
<br />
Das dauert eine halbe Stunde und verändert die Texte mehr als jedes Stilhandbuch.<br />
<br />
Was mir noch hilft: ein verbotener Wortschatz. Begriffe, die in der Entwicklungsabteilung normal sind, im Anwenderdokument aber nichts verloren haben. Den pflege ich pro Kunde in einer kleinen Liste, nicht in einem großen Terminologie-System. Klein anfangen, sonst fangen Sie nie an.<br />
<br />
Haben Sie tatsächlich definierte Zielgruppen pro Dokument, oder steht da auch "Endanwender"?]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Verständlichkeit messen, nicht nur fühlen]]></title>
			<link>https://forum.schuebeler-consulting.de/thread-19.html</link>
			<pubDate>Mon, 03 Nov 2025 13:26:34 +0100</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.schuebeler-consulting.de/member.php?action=profile&uid=2">Johann Jörgen Schübeler</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.schuebeler-consulting.de/thread-19.html</guid>
			<description><![CDATA[Wenn ich Redaktionsleiter frage, wie verständlich ihre Anleitungen sind, ist die Antwort fast immer: Gut bis sehr gut. Wenn ich dann frage, woher sie das wissen, wird es leiser.<br />
<br />
Verständlichkeit ist eine Eigenschaft, die Sie messen können, wenn Sie wollen. Drei Wege, die ich in Projekten oft einsetze:<br />
<br />
Erstens: Lassen Sie eine echte Zielperson eine reale Aufgabe nach Ihrer Anleitung durchführen. Beobachten Sie, wo sie stockt, zurückblättert, rät. Drei solche Sitzungen mit drei verschiedenen Personen liefern Ihnen mehr Erkenntnisse als ein Jahr interner Reviews.<br />
<br />
Zweitens: Lesbarkeitsindizes wie der Hohenheimer Index oder LIX sind nicht perfekt, aber sie geben einen schnellen Hinweis, wo ein Text sprachlich zu komplex ist. Nicht jeder hohe Wert ist ein Problem. Jeder hohe Wert ist aber eine Frage wert.<br />
<br />
Drittens: Lassen Sie Ihren Support gezielt nachhalten, welche Stellen in der Anleitung zu Rückfragen führen. Diese Rückfragen sind kostenloses Feedback, das viele Redaktionen einfach nicht abrufen. Ein 30-Minuten-Termin pro Quartal mit dem Support-Leiter ist eine der billigsten Qualitätsmaßnahmen überhaupt.<br />
<br />
Welche dieser drei Quellen nutzen Sie heute schon, welche nicht?]]></description>
			<content:encoded><![CDATA[Wenn ich Redaktionsleiter frage, wie verständlich ihre Anleitungen sind, ist die Antwort fast immer: Gut bis sehr gut. Wenn ich dann frage, woher sie das wissen, wird es leiser.<br />
<br />
Verständlichkeit ist eine Eigenschaft, die Sie messen können, wenn Sie wollen. Drei Wege, die ich in Projekten oft einsetze:<br />
<br />
Erstens: Lassen Sie eine echte Zielperson eine reale Aufgabe nach Ihrer Anleitung durchführen. Beobachten Sie, wo sie stockt, zurückblättert, rät. Drei solche Sitzungen mit drei verschiedenen Personen liefern Ihnen mehr Erkenntnisse als ein Jahr interner Reviews.<br />
<br />
Zweitens: Lesbarkeitsindizes wie der Hohenheimer Index oder LIX sind nicht perfekt, aber sie geben einen schnellen Hinweis, wo ein Text sprachlich zu komplex ist. Nicht jeder hohe Wert ist ein Problem. Jeder hohe Wert ist aber eine Frage wert.<br />
<br />
Drittens: Lassen Sie Ihren Support gezielt nachhalten, welche Stellen in der Anleitung zu Rückfragen führen. Diese Rückfragen sind kostenloses Feedback, das viele Redaktionen einfach nicht abrufen. Ein 30-Minuten-Termin pro Quartal mit dem Support-Leiter ist eine der billigsten Qualitätsmaßnahmen überhaupt.<br />
<br />
Welche dieser drei Quellen nutzen Sie heute schon, welche nicht?]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Warum Ihre Warnhinweise niemand liest (und was hilft)]]></title>
			<link>https://forum.schuebeler-consulting.de/thread-18.html</link>
			<pubDate>Fri, 17 Oct 2025 16:07:31 +0200</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.schuebeler-consulting.de/member.php?action=profile&uid=2">Johann Jörgen Schübeler</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.schuebeler-consulting.de/thread-18.html</guid>
			<description><![CDATA[Wenn ich Anleitungen prüfe, ist eines der häufigsten Probleme die Warnhinweis-Inflation. Auf jeder zweiten Seite ein Achtung, ein Vorsicht, ein Gefahr. Manchmal acht Warnhinweise hintereinander, bevor der eigentliche Handlungsschritt kommt.<br />
<br />
Das Ergebnis ist immer dasselbe: Der Leser überspringt sie. Komplett. Auch die, die wirklich wichtig wären.<br />
<br />
Ich arbeite mit Redaktionen gerne mit einer einfachen Regel. Pro Handlungsabschnitt maximal zwei Warnhinweise, und die stehen direkt vor dem Schritt, auf den sie sich beziehen. Auf Seite 3 im allgemeinen Sicherheitskapitel werden sie ohnehin übersprungen. Wenn ein dritter Hinweis nötig wäre, ist das ein Zeichen, dass der Handlungsschritt selbst schlecht konstruiert ist und neu gedacht werden sollte.<br />
<br />
Dazu kommt: Prüfen Sie die Hinweise auf tatsächliches Risiko. Viele Warnhinweise stehen drin, weil sie vor 15 Jahren mal aus einem ähnlichen Produkt übernommen wurden. Niemand hat seither hinterfragt, ob das Risiko überhaupt noch besteht. Löschen tut sich aber niemand, aus Angst vor der Haftungsfrage.<br />
<br />
Diese Angst ist verständlich. Sie macht Ihre Dokumentation aber schlechter. Reden Sie mit Ihrer Rechtsabteilung darüber, was wirklich nötig ist. Sie werden überrascht sein.<br />
<br />
Wie handhaben Sie das? Haben Sie eine Regel für die maximale Dichte von Warnhinweisen?]]></description>
			<content:encoded><![CDATA[Wenn ich Anleitungen prüfe, ist eines der häufigsten Probleme die Warnhinweis-Inflation. Auf jeder zweiten Seite ein Achtung, ein Vorsicht, ein Gefahr. Manchmal acht Warnhinweise hintereinander, bevor der eigentliche Handlungsschritt kommt.<br />
<br />
Das Ergebnis ist immer dasselbe: Der Leser überspringt sie. Komplett. Auch die, die wirklich wichtig wären.<br />
<br />
Ich arbeite mit Redaktionen gerne mit einer einfachen Regel. Pro Handlungsabschnitt maximal zwei Warnhinweise, und die stehen direkt vor dem Schritt, auf den sie sich beziehen. Auf Seite 3 im allgemeinen Sicherheitskapitel werden sie ohnehin übersprungen. Wenn ein dritter Hinweis nötig wäre, ist das ein Zeichen, dass der Handlungsschritt selbst schlecht konstruiert ist und neu gedacht werden sollte.<br />
<br />
Dazu kommt: Prüfen Sie die Hinweise auf tatsächliches Risiko. Viele Warnhinweise stehen drin, weil sie vor 15 Jahren mal aus einem ähnlichen Produkt übernommen wurden. Niemand hat seither hinterfragt, ob das Risiko überhaupt noch besteht. Löschen tut sich aber niemand, aus Angst vor der Haftungsfrage.<br />
<br />
Diese Angst ist verständlich. Sie macht Ihre Dokumentation aber schlechter. Reden Sie mit Ihrer Rechtsabteilung darüber, was wirklich nötig ist. Sie werden überrascht sein.<br />
<br />
Wie handhaben Sie das? Haben Sie eine Regel für die maximale Dichte von Warnhinweisen?]]></content:encoded>
		</item>
	</channel>
</rss>