Was sind unsere Daten? Verbandsinhalte mit OOUX modellieren

TEIL 1: Link TEIL 3: Link

Im ersten Teil dieser Serie endete alles mit einer Frage: Was sind unsere Daten? Sie zu stellen ist einfach. Sie sauber zu beantworten ist die eigentliche Arbeit – und sie entscheidet später über Design und Technologie. Dafür gibt es eine Methode: OOUX.

OOUX (Object-Oriented UX) bedeutet, ein digitales Produkt von den Objekten her zu denken, die für die Nutzer zählen – nicht von Seiten oder Features. Der zugehörige Prozess heisst ORCA: Objects, Relationships, Calls-to-action, Attributes.

Warum bei Objekten beginnen, nicht bei Seiten

Die meisten Webseiten-Projekte für Verbände starten mit einer Sitemap, also mit einer Auswahl von Seiten. Für einfache Inhaltsstrukturen mag das auch hilfreich und sinnvoll sein. Bei komplexeren Datenstrukturen mit Veranstaltungen, Personen, Kurses und Ähnlichem ist dieses Vorgehen aber häufig nicht sinnvoll. Die User besuchen die Webseite nicht um eine “Seite” zu finden sondern suchen einen Kurse, eine Veranstlatung oder eine Person. In OOUX werden alle diese Inhalet als Objekte betrachtet und vor der ersten Sitemap entsprechend modelliert.

Die verschiedenen Objekte werden dokumentiert, die Verbindungen visualisiert und die Inhalte und Aktionen pro Objekt definiert. Die Objekte werden dann auf Seiten verteilt. Entweder jedes Art von Objekt auf eine Seite - häufig aber auch bun gemischt.

Diese Basis hilft uns als Umsetzder das Projekt zu verstehen und schafft eine Basis, die ein wahres Fundament bildet. Wie und wo unsere Objekte angezeigt werden bleibet anpassbar und wächst mit den Anforderungen mit - die Daten selber haben Bestand.

Schritt 1 – Die Objekte finden (Objects)

Wie finden wir nun die Objekte, welche abgebildet werden sollen? Der beste Weg ist noch immer durch Interviews mit Mitarbeiern des Verbands, Vorständen, Stakeholdern aber wenn möglich auch Nutzern. Aus all diesen Gesprächen sammeln wir dann “Nomen” die der Interviewpartner immer wieder verwendet - “Kurs”, “Veranstlatung”, “Vorstand”, “Sekretariat”, “Merkblätter” usw. Diese wiederkehrenden Begriffe bilden die Basis und werden als erste Version der Objekte dokumentiert. Durch Iteration mit den Projektmitarbeitern werden diese ersten Obejtek verdichtet, erweitert und in Verbindung zueinander gebracht.

Typische Objekte eines Schweizer Verbands:

Person – kann Mitglied, Referent/Ausbildner oder beides sein

Standort – wo etwas stattfindet

Bereich / Fachgruppe – die fachliche Gliederung

Veranstaltung / Events – Anlässe ausserhalb der Kurslogik

Kurs / Ausbildung – das inhaltliche Angebot

Daten / Durchführung – die konkrete, terminierte Instanz eines Kurses

Mitgliedschaft – verbindet Person und Verband”

Merkblatt / Dokument - Merkblätter, Reglemente, Downloads

Events werden in diesem Beispiel extra von Daten egtrennt. Der Event ist das beständige Objekt mit Informationen, Bildern, Speakern - die Durchführung die anpassbare Instanz davon mit Datum, Ort, Preis, Zeit usw. Dadurch bleibt das System skalierbar und die Datenpflege übersichtlich.

Schritt 2 – Die Beziehungen (Relationships)

Damit diese Modellierung der Daten möglich ist, benötigen wir Verbindungen zwischen den einzelnen Objekten. In diesem Fall hat ein Event eine oder mehrere Durchfürungen.

Die Beziehungen im Verbandsmodell:

Ein Kurs hat mehrere Durchführungen

Eine Durchführung findet an einem Ort statt, gehört zu einem Bereich , hat ein Datum – und wird von einer Person (Ausbildner) geleitet.

Eine Person kann mehrere Mitgliedschaften und mehrere geleitete Durchführungen haben.

Ein Bereich bündelt mehrere Kurse und Veranstaltungen

Sobald man alle Beziehungen aufgezeichnet und geprüft hat, wird erst richtig klar, wie komplex die Daten sind. Werden die gleichen Daten an mehreren Stellen eingesetzt? Müssen diese alle zentral gepflegt werden? Werden immer alle Daten verwendet? Durch die Verbindung wird das Modell der Objekte nochmals geprüft und verfeinert.

Schritt 3 – Die Aktionen (Calls-to-action)

Damit man nicht nur Objekte und Verbindungen hat, werden im Rahmen von OOUX auch “Call to Actions” pro Objekt definiert. Was soll der User mit den Daten machen?

Pro Objekt die zentralen Aktionen:

Durchführung: anmelden, auf Warteliste, in Kalender exportieren

Kurs: alle Durchführungen ansehen, als PDF speichern

Person: Profil ansehen, kontaktieren

Ressource: herunterladen

Schritt 4 – Die Attribute und Metainformationen (Attributes)

Erst wenn Objekte, Beziehungen und Aktionen stehen, ergeben Attribute Sinn. Sie sind die Daten, welche auf den jeweiligen Objekten leben. Dabei OFFEN

Beispielhafte Attribute:

Kurs: Titel, Kurzbeschreibung, Lernziele, Stufe, Dauer

Durchführung: Datum, Uhrzeit, Preis, freie Plätze, Status

Standort: Name, Adresse, Anfahrt, Karte

Person: Name, Rolle, Foto, Kurzbio

Jedes Attribut ist ein Feld, das jemand in der Redaktion pflegen muss. Daher ist die Modellierung der Daten nach OOUX nicht nur für UX und die INformations Architektur so wichtig. Es ergeben sich auch direkt Implikationan auf die Wahl der Technologie. Wie werden diese Daten gepflegt? Wer macht das und wie häufig muss das gemacht werden? Müssen Daten aus Drittsystemen importiert und genutzt werden? Je nach Use Case wird so durch die Anordnung der Daten auch mitbeineflusst, welches CMS für ein Projekt verwendet werden sollte.

Vom Objektmodell zur Technologieentscheidung

Das fertige Objektmodell ist also kein UX-Selbstzweck – es ist das Pflichtenheft für die Technologiewahl. Es beantwortet beide Entscheidungsachsen aus dem ersten Teil:

Datenkomplexität: Zähle die Objekte und ihre Beziehungen. Wenige, lose verbundene Objekte → WordPress reicht. Viele, stark verknüpfte Objekte → strukturierter oder Headless-Ansatz. (So wird die „rund fünf Inhaltstypen”-Faustregel aus Teil 1 konkret.)

Editor Experience: Jedes Objekt und jedes Attribut bedeutet Pflegeaufwand. Wer pflegt wie oft? Daraus folgt, welche Redaktionsoberfläche das CMS bieten muss.

Fazit

Ihre Daten und das Verständnis davon sind also nicht nur zentral für den Aufbau der Seite, der User Experience und des Designs sondern sie sind auch massgeblich verantwortlich für die Wahl der richtigen Technologie.

Was aber, wenn in einem Projekt die zwei Achsen NICHT in dieselbe Richtung zeigen? Die Daten sprachen für Headless, die Editor Experience für WordPress. Was gewinnt und welche Kompromisse kann man eingeben? Das wir im nächsten Blog thematisiert.

eoss begleitet Schweizer Verbände von der Inhaltsmodellierung bis zum Launch. Jetzt Projekt besprechen: https://eoss.ch/kontakt/