In frühen Stadien der Entwicklung von Software geht es darum, Prozesse und Funktionen grundlegend zu modellieren.

Nehmen wir das Beispiel eines Kaufprozesses: Die einzelnen Arbeitsschritte des Nutzers müssen festgelegt werden, es wird überlegt, welche Zusatzinformationen der Nutzer wünschen könnte, und welche Varianten des Prozesses es geben muß. So kann aus einem einfachen Prozess ein komplexes Netzwerk an Schritten entstehen, die im Rahmen einer Interaktions-Architektur festgehalten und gemeinsam mit dem gesamten Entwicklungsteam bearbeitet werden muß.

Dabei steht immer wieder die Frage im Raum, wie die Kommunikation darüber mit allen Beteiligten möglichst gut gestaltet wird. Für unsere Projekte sind das in der Regel Auftraggeber, Projektmanagement, Designer, Software-Entwickler und außerdem User und Fach-Experten.

Wie könnte eine "gemeinsame Sprache" aussehen, die Prozesse ausreichend genau abbilden kann und von allen Projektbeteiligten benutzt wird.
Wie kann man dem unterschiedlichen Stand an Vorkenntnissen bei den verschiedenen Beteiligten gerecht zu werden?

Eine Übersicht über bestehende Mittel zur Modellierung von Interaktions-Prozessen:
Text (z.b. als Lastenheft):
(+) "normaler Weg", für alle Beteiligten benutzbar, weitgehend verständlich
(-) linear, Zusammenhänge schlecht darstellbar, sprachliche Formulierung für Laien oft schwierig, großer Sprung von Text zu Wireframes
Diagramme (z.B. Aktivitätsdiagramm, Bausteine aus UML):
(+) modular, gute Übersicht, gut erweiterbar, präzise
(-) ohne Übung schwer lesbar, sehr abstrakt
Wireframes:
(+) sehr anschaulich, detailiert
(-) für unsere Zwecke bereits zu weit fortgeschritten, zu sehr in Screens gedacht, schwierig in Fällen, in den Use Cases erst grundlegend umrissen werden müssen.
Prototypen (z.B. Papier/Klickdummies)
siehe Wireframes

Nach unseren Abwägungen boten Diagramme die besten Möglichkeiten. Wir mußten nur sehen, wie wir das Vokabular so abändern, daß es - auch für Laien- besser benutzbar war.

Es gibt bereits Entwürfe zu Diagrammsprachen für Interaction Designer. Jesse James Garrett etwa hat vor Jahren ein Vokabular vorgelegt (A visual vocabulary for describing information architecture and interaction design). Er reduziert den Zeichenschatz sehr stark, schafft dadurch ein sehr handhabbares und allgemein anwendbares System. Rechts ist ein Beispieldiagramm zu sehen.

Unser System folgt einem ähnlichen Grundgedanken, es gibt aber einen wichtigen Unterschied:
Garretts Vorschlag, UML und verwandte Diagrammsprachen sind als universelles Vokabular entwickelt. Der Zeichenwortschatz soll alle denkbaren Fälle und Prozesse abbildbar machen. Dafür müssen die verwendeten Zeichen sehr abstrakt sein.

Wir wollen ein System, das möglichst auf Anhieb eine Vorstellung vermittelt. Dazu müssen wir anders mit Zeichen umgehen. Das geschieht in unserem Ansatz wie folgt: Mithilfe von Abbildungen (Zeichen) wird der Prozess umrissen. Diese erste Ebene des Diagramms nennen wir Aktivitätsebene. Das heißt, wir verwenden möglichst aussagekräftige Zeichen, die weniger abstrahiert sind. Die zweite Ebene beschreibt Bedingungen, Funktionen, logische Verknüpfungen. Wir nennen sie Funktionsebene. Hier vereinfachen wir das Vokabular (verglichen mit z.B. UML) stark. Wir beschreiben nötige Funktionen und Verknüpfungen und verwenden Text anstelle von Symbolen, die erst gelernt werden müssen.

Dieser Ansatz entstand aus folgender Beobachtung:
Oft waren während Gesprächen Skizzen entstanden, von Designern und auch von Usern selbst.
Sie hatten eine wichtige Gemeinsamkeit: sie enthielten Abbildungen, und zwar auf der Ebene der Akteure, für die benutzte Technik/Hardware oder für Dokumente oder gelieferte Endprodukte.
Sie enthielten dagegen keine Abbildungen (Symbole) für logische Verknüpfungen, Bedingungen oder ähnliches. Diese waren als Text formuliert.

Das Prinzip läßt auch an Comics denken, auch hier begegnen uns Bild und Text - aber nur solche Dinge sind abgebildet, die auch als Bild verständlich sind. Alles andere wird sprachlich vermittelt.

Aus diesen Beobachtungen entwickelten wir unser Diagramm-Vokabular. Am Ende ergaben sich folgende Grundbestandteile:

Für die Aktivitätsebene:
Akteure:
flexibles Vokabular/projektbezogen. Denkbar sind Abbildungen, Stellvertreter und Symbole aus verschiedenen Ebenen der Projektentwicklung, denkbar wäre sogar die Einbeziehung von Personas.
Interfaces:
Stellvertreter, Miniaturen von Screens, in weiteren Schritten verlinkt mit Wireframes
Verknüpfungen:
Pfeile, Verbindungslinien, kleine Bandbreite an Symbolen (z.b. Link oder Aktion)

Für die Funktionsebene:
Bedingungen, Funktionen, logische Verknüpfungen:
als Text, Beschreibung

Die daraus entstandenen Diagramme bringen gute Ergebnisse. Wir benutzen die Diagramme wann immer möglich bereits zur allerersten Skizzierung der Prozesse - im Dialog mit den späteren Anwendern. Wir können aus den Diagrammen die nötigen Interfaces/Wireframes einfach ableiten. Sie sind so weit entwickelt, daß sie als Grundlage zu UML-Diagrammen dienen und leisten gute Dienste um z.B. einen präzisen Überblick über alle benötigten Funktionen zu gewinnen und diese zu planen.

Für die Erstellung der Diagramme bieten sich z. B. MS Visio oder Omnigraffle an, die jeweils mit einer projektbezogenen Shape-Bibliothek bestückt werden können. Mit Einschränkungen was die Weiterverwendung betrifft, kann man jedes Diagramm aber auch auf Papier zeichnen! ;-).
Die wirklich ideale Software ist aber (nach unserem Kenntnisstand) leider noch nicht erfunden: "Visio-Online", also ein Online-Tool, mit dem verschiedenste Nutzer selbständig Diagramme bearbeiten und kommentieren können - und ohne das leidige Problem der Austausch-Formate.