Strukturen lernen und leben – Informationsarchitektur in der Praxis (2)

Home/Allgemein/Strukturen lernen und leben – Informationsarchitektur in der Praxis (2)

Strukturen lernen und leben – Informationsarchitektur in der Praxis (2)

Teil II – Strukturen leben – Informationsarchitekturen zum Leben erwecken

Die Umsetzung einer neuen Informationsarchitektur in einem Unternehmen ist schon eine Herausforderung für sich – dass sie aber auch gelebt, gepflegt und langfristig weiterentwickelt wird, eine noch größere.

Sobald ein Intranet oder eine Kollaborationsumgebung in den laufenden Betrieb übergehen, können die zuvor entwickelten Ideen und Strukturen schnell in Vergessenheit geraten. Im Kollaborations-Umfeld kämpfen wir mit einer fehlenden Kontrollinstanz und Metadaten und Strukturen unterliegen subjektiven Assoziationen, was häufig Wildwuchs bedeutet. Aber auch im klassischen Intranet-Publishing kann es dazu kommen, dass sich Verantwortlichkeiten verschieben, Konzepte nicht eingehalten werden, die alte Organisationsstruktur wieder Einzug hält oder schlicht Konzern-Entscheidungen dazu führen, dass die Konsistenz einer Navigationsstruktur nicht mehr eingehalten wird.

Um dies zu vermeiden, hängt vieles von der Präsenz und dem Einfluss, den man auch nach Go-Live noch hat, ab. Ein „Über den Zaun werfen und fertig“ funktioniert in der Regel nie. Im Bestfall sollten bereits zu Projektbeginn drei Faktoren langfristig angepeilt werden:

1. Maintenance anbieten

Die Maintenance einer produktiven Plattform, sowohl im Publishing, als auch im kollaborativen Umfeld, ist die wichtigste Komponente, die umgesetzte Informationsarchitektur am Leben zu erhalten. Hier werden die umgesetzten Metadaten und Navigationsstrukturen im „real life“ beobachtet und optimiert. Auch die Usability kann hier auf Herz und Nieren geprüft werden. Häufig bietet sich an, nach ca. 3-6 Monaten zum einen eine Nutzungsanalyse, wie auch eine Bedürfnisabfrage durchzuführen. Anhand objektiver Statistiken wird überprüft, wie die neuen Inhalte heute genutzt werden, oder es „schwarze Löcher“ gibt. Wenn ja, woran könnte das liegen? Gleichzeitig sollte über eine Bedürfnisabfrage oder eine Eye-Tracking-Analyse nachgehakt werden, wo die Nutzer noch Probleme haben, wo sie das neue System nicht verstehen oder wo sich im Betrieb gezeigt hat, dass die neue Struktur nicht dem eigentlichen Arbeitsalltag entspricht.
Beides sollte nach einer ausreichenden Zeit der „Eingewöhnung“ stattfinden, zwei Wochen nach Live-Gang ist dies nicht zielführend, da grundsätzlich Beschwerden eingehen oder vieles noch gar nicht genutzt oder gebraucht wurde. Um nach Go-Live „direktes und ungefiltertes“ Feedback zu erhalten, empfiehlt sich daher eher die Integration eines „Feedback-Postfachs“.

2. Leitplanken geben

Ist eine Maintenance-Phase nicht möglich (sei es aus budgetären oder sonstigen Gründen), ist es umso wichtiger, den Editoren und Mitarbeitern klare Handlungsanweisungen und –Empfehlungen mitzugeben, was sie wann, wo und wie ablegen oder publizieren sollen. Das Wichtigste dabei:

Beschreiben Sie hier niemals, dass eine Richtlinie zur „Beauftragung externer Dienstleister“ immer unter einem bestimmten Menü-Punkt abgelegt werden muss, immer bestimmte Metadaten haben muss oder zwingend bestimmte Berechtigungen enthalten muss. Der „unbedarfte Nutzer“ steigt aus und kann dies nur in den wenigsten Fällen auf sein konkretes ToDo anwenden. Vor allem kann sich alles ändern – Metadaten werden neu vergeben, Menü-Punkte ändern ihre Bezeichnung und wir kennen die Vorkenntnis des Anwenders in diesem Fall nicht immer.

Appellieren Sie vielmehr an den gesunden Menschenverstand. Versuchen Sie, einen Katalog zusammenzustellen, der dem Nutzer Fragen vor Augen führt, die er sich selbst beantworten muss:

Handelt es sich um ein Dokument, das für jeden sichtbar sein soll?
Handelt es sich um eine interne Richtlinie, die nur für mein Team wichtig ist?
Welches Thema beschreibt das Dokument am besten?

3. Eine Governance schaffen

Für den Fall, dass die Maintenance nicht umgesetzt werden kann, sorgen Sie für jemanden, der Ihre Ideen, Leitlinien, Rahmenbedingungen fortführt. Das heißt, wir sollten immer dafür sorgen, dass intern eine Art Governance existiert, um die entwickelten Ansätze weiter zu verfolgen. Dies sollte ein Mitarbeiter sein, der die Geschichte eines Projektes kennt und als federführende Instanz einen Ansprechpartner für o.g. Fragen darstellt.

Ungeachtet der Positionen und Instanzen, die in einer Maintenance Phase etabliert werden sollten, geht es in der Governance darum, die Vogelperspektive zu gewährleisten. Sie benötigen einen Verbündeten – dies kann selbstverständlich jemand aus dem Projekt sein, kann aber ebenso gut ein Mitarbeiter , der sich dieses Themas annimmt. Es sollte – und das auch aus der Führungsebene heraus – als Schnittstelle gesehen werden. Kommen Anforderungen, Optimierungen oder Änderungswünsche an einem bestehenden System, sollten diese immer über den Tisch der Governance gehen. Nur diese Instanz kann beurteilen, ob eine Änderung Einfluss auf die Gesamt-Architektur hat.

Hat eine Abteilung beispielsweise den Wunsch eine neue Seite mit internen Stellenanzeigen zu schalten, sollte sich die Frage stellen, wo sie im Gesamtkontext verortet werden soll. Auch wenn es sich um Stellenanzeigen aus einer bestimmten Abteilung handelt, kann es dennoch sein, dass sie in einem anderen Kontext wesentlich besser passen. Das können News sein, das können allgemeine Karriere oder auch Weiterbildungsseiten sein, je nach angestrebter Informationsarchitektur. Fragen und Hinweise dieser Art kann nur stellen und geben, wer die Leitidee kennt. Und nur so lässt sich das Konzept langfristig erfolgreich umsetzen.

Fazit

Die Erfahrung zeigt, die Rolle des Informationsarchitekten besteht nicht nur in der Arbeit an Metadaten, Taxonomien und Navigationsstrukturen. Sie ist einem Requirements Engineer sehr nahe, wobei die persönliche Note eine sehr große Rolle spielt. Das was wir am Ende liefern, ist die kleinste Komponente, die in einem Intranet oder Kollaborationssystem zu finden ist – und damit die Basis, auf der eine gute Startseite, eine gute User Experience und vielleicht auch ein gutes Design aufbauen. Jedes System ist nur so gut, wie seine Struktur.

Gleichzeitig ist der Informationsarchitekt ein wichtiges Kommunikationsinstrument. Im besten Fall kennt keiner außer den Mitarbeitern, den Arbeitsablauf und Alltag der Mitarbeiter besser. Er versteht die Notwendigkeiten und Prozesse und kann Kompromisse finden.

Kümmern wir uns im Projektverlauf frühzeitig um eine offene Kommunikation, schaffen es, Bedenken und Sorgen auszuräumen und treffen die Vorkehrungen für eine langfristige Pflege des Systems aus Sicht der Strukturen und Inhalte, bleibt uns die Frustration und Resignation erspart.
Und wir können zufrieden sein, mit dem Erarbeiteten.

By | 2017-02-08T15:34:55+00:00 August 13th, 2015|Allgemein|0 Comments

About the Author:

Marketing Managerin, Expertin für: Marketing

Kommentar verfassen

%d Bloggern gefällt das: