Ich hatte das Vergnügen, letzte Woche einen ganzen Tag auf der Konferenz Mensch und Computer 2009 zu verbringen. Sie stand dieses Jahr unter dem Motto "Grenzenlos frei!?".
Aus dem dichtgedrängten Programm fielen mir drei Vorträge auf. Alle beschäftigten sich mit der Einbindung von Usability Spezialisten in IT-Projekte. Und alle berichteten von Problemen, die das Zusammenspiel verschiedener Disziplinen schwierig machen - aber auch von Lösungsansätzen. Nur ein Ansatz hat mir gefehlt.

Dr. Thomas Memmel sprach über "Integratives Usability Engineering – Benutzerorientierte Modellierung von Geschäftsprozessen und Softwareanforderungen".
Er gab einen groben Überblick über Werkzeuge und Methoden für Usability Engineering in frühen Projektphasen. Damit kann Usability-Expertise bereits in Requirement Engineering und Geschäftsprozessmodellierung eingebunden werden. Dies wäre wichtig, weil in diesen frühen Phasen bereits entscheidende Weichenstellungen für die Interface-Gestaltung getroffen werden.

Seiner Erfahrung nach ist die Wahl der Werkzeuge entscheidend, sie stellen gewissermaßen die gemeinsame Sprache im Entwicklungsteam dar. Und er empfiehlt Usability-Experten, sich in ihren Werkzeugen Entwicklern und Betriebswirtschaftlern anzupassen. So wäre es zum Beispiel hilfreich, Prozesse in UML zu notieren, um sich bei der Modellierung von Geschäftsprozessen schnell und effektiv zu verständigen.
(Abstract von Th. Memmel, Th. Büring & O. Lalive d‘Epinay)

Fazit 1:
Usability Experten müssen die Sprache der wichtigen Entscheider sprechen, um ihre Kompetenzen zur Wirkung zu bringen. Sie werden nur dann wirklich gehört, wenn klar ist, daß sie sich in Projekte und Teams mit etablierten Prozessen und Denkweisen integrieren können und wollen. Diese Beobachtung kann ich bestätigen.

Julia Maly und Henning Brau sprachen in ergänzenden Beiträgen über Usability Engineering mit Eclipse RCP.
Beide waren als Usability-Spezialisten an der Umstrukturierung der gesamten IT-Servicelandschaft eines Unternehmens beteiligt, die als SOA (Serviceorientierte Architektur) neu implementiert werden sollte. (Mehr zum Thema SOA)

Ihre Aufgabe war es, zunächst Arbeitsprozesse im Unternehmen zu analysieren und verbessern. Und im zweiten Schritt aus diesen Erkenntnissen Usability-Richtlinien und Standards zu erarbeiten.

Als Plattform und Entwicklungsumgebung wurde Eclipse RCP gewählt. Nun besitzt Eclipse RCP einige Eigenschaften, die in der Benutzungslogik stark von herkömmlichen Software-Interfaces abweichen. Eclipse RCP wurde aus technologischen Gesichtspunkten gewählt, und erzeugte (durch seine Flexibilität!) auf der Seite der Interfaces erhebliche Schwierigkeiten. Im Ergebnis bedeutete das, daß die Usability Experten ihre Zeit nicht mit der ursprünglich geplanten Aufgabe verbrachten, sondern mit Machbarkeitsstudien: Ist unser Interface-Konzept auf Eclipse RCP anwendbar? Den eigentlich angestrebten Erkenntnisgewinn (Usability Optimierung) konnten sie aus Ihrer Sicht nicht einbringen. (Abstract von Julia Maly, Henning Brau, B. Watzal)

Fazit 2:
Henning Brau sprach in seiner Schlußfolgerung unter anderem davon, daß Teambuilding-Aspekte hier entscheidend für Gelingen oder Scheitern sein können. Ich denke, es fehlte eine Schnittstelle, die die Diskrepanz zwischen gewählter Technologie und Benutzungslogik hätte aufdecken können und den Nachweis von Machbarkeit nicht den Usability-Experten überläßt.

Der ganze Nachmittag hinterließ bei mir die Frage: Wieso wird die Kommunikationsrolle bzw. Vermittlerrolle in derartigen Projekten nicht stärker ausgebaut?

Es ist nicht die Ausnahme, sondern die Regel, daß an IT-Projekten mehrere Fachdisziplinen beteiligt sind. Normal sind Informatik plus Betriebswirtschaft, Marketing, Design, Usability. Oft sind aber auch Fächer beteiligt, die spätere Anwender repräsentieren, man denke an Pädagogen und Erzieher (E-Learning), Mediziner (Medizintechnik) oder Ingenieure (Maschinenbau, Elektrotechnik usw.).
Ihr Beitrag fällt in der Praxis oft nicht so gewinnbringend aus, wie erhofft. Ich beobachte drei häufige Reaktionsweisen:

Interdisziplinäre Zusammenarbeit wird zwar gelobt, in der Praxis aber weitgehend vermieden. Entsprechende Versuche werden schnell verworfen, weil sie als Risiko an sich erscheinen.

Man versucht, Teams ausschließlich mit Personen zu besetzen, die IT-Kenntnisse besitzen. So werden grundsätzlich Kandidaten bevorzugt, die "irgendwas mit Programmierung" gemacht haben. Und das eigentlich gesuchte, zusätzliche Fachwissen rückt in den Hintergrund. Mittelmäßige Allrounder haben folglich bessere Chancen als wirklich exzellente Spezialisten, die einen Fremdkörper im Team darstellen könnten.

Kommen Projekte an kritische Punkte, so wird häufig zu der Lösung mit dem "kleinsten technischen Risiko" tendiert. Und zu solchen Lösungen, bei denen die Machbarkeit im Moment des Vorschlags bereits abzusehen ist. Dabei sollte es normal sein, daß Vorschläge Fachfremder noch nicht in den Dimensionen von Programmierung gedacht sind. Und deshalb auf Anhieb nicht sehr realistisch klingen. Eine interessante Anregung sollte eine zweite Runde wert sein - nur, wer nimmt sich eines scheinbar "irrwitzigen" Vorschlags an, wenn nicht ein Projektleiter, der das Potenzial dieses Vorschlagsverstehen kann.

Bei allen Versuchen, mit der Problematik umzugehen, vermisse ich eine Position, die anerkennt, daß es explizit einer Kommunikationsleistung bedarf, um interdisziplinäre IT-Projekte zum Erfolg zu führen. Das Problem liegt in der Integration, nicht in der Tatsache, daß es verschiedene Disziplinen, Kompetenzen und Denkweisen gibt.

Ich frage mich, ob nicht bereits bei der Ausbildung angesetzt werden müsste: Wie wäre es, die Kommunikatoren für interdisziplinäre IT-Projekte tatsächlich auszubilden? Dies würde bedeuten, daß man Fähigkeiten, auf die es ankommt, nicht weiterhin unter der Rubrik "wünschenswerte Soft-Skills" ablegt. Informatiknahe Studiengänge würden womöglich für einen ganz neuen Typus von Studenten attraktiv (Kommunizieren!).

IT ist kein Tisch, an dem alleine Tischler arbeiten. IT ist eine Baustelle, an der die verschiedensten Gewerke beteiligt sind. Laßt uns die Spezialisten. Und gebt uns Leute, deren einzige Aufgabe es ist, Beiträge aus verschiedenen Blickwinkeln zu einem Ziel zu führen.

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.

HKG1 hat in den letzten Monaten für eQMB mehrere Online-Applikationen mitentwickelt. eQMB ist eine Plattform für Mediziner, die Anwendungen für Qualitätssicherung und Qualitätsmanagement anbietet (mehr dazu unter Projekte > eqmb).
Eine dieser Anwendungen ist ein Online-Qulitätsmanagement-Handbuch. In diesem Handbuch soll es einen Flowchart-Editor geben, der einfache Funktionen zur Erstellung von Flußdiagrammen bereitstellt.

Die Entwicklungsschritte des Interfaces für den eQMB Flowchart-Editor zeigen beispielhaft, wie unsere Arbeit aussieht und abläuft.

Requirements:
z.B. Technische Anforderungen und Vorgaben
Da der Flowchart-Editor Bestandteil einer größeren Anwendung ist, müssen wir bestimmte Voraussetzungen berücksichtigen. So steht uns z.B. für das Interface nur ein bestimmter Screenausschnitt zu Verfügung. Auch ist die Verwendung bestimmter Technologie bereits festgelegt.
Meist recherchieren wir zudem bestehende, vergleichbare Editoren und lassen uns ggf. von den beteiligten Entwicklern Möglichkeiten (und Unmöglichkeiten) erläutern. So erhalten wir am Ende ein genaues Bild davon, welche technischen Vorgaben eingehalten werden müssen.

Usability Anforderungen
In der nächsten Phase gleichen wir die bestehenden Skizzen mit Usability-Erfordernissen ab. Das kann bedeuten, das wir Schritte der Bedienung in einem Prototyp durchführen und Inkonsitenzen aufdecken und verbessern. Das kann aber auch bedeuten, daß wir direkt mit Nutzern den Prozess an sich erforschen, und daraus Vorgaben für ein verbessertes Interface ableiten.
Hier Auschnitte aus der Weiterentwicklung. Wir simulieren an sogenannten Wireframes, also Skizzen von späteren Bildschirmansichten, die Funktionen und Abläufe, bewerten sie und verbessern sie Schritt für Schritt.

Interface Design
Im letzten Schritt folgt das Interface Design. Aus allen Anforderungen, die bisher gesammelt wurden und zusätzlich aus Vorgaben, z.B. aus einer Corporate Identity oder einem Style Guide, wird ein stimmiges Interface destilliert. Manchmal widersprechen sich Anforderungen aus Schritt 1 und 2. So kann sich ein Interface in Prototypen bestens bewähren, daß aus Platzgründen (siehe "Technische Anforderungen") schlecht umsetzbar ist. Dann sind Entscheidungen gefragt. Wir versuchen die Lösung zu finden, die den Charakter und das Gefühl beim Interagieren (User Experience) am besten transportieren.
(Diese Floskel benutzen viele Interaction-Designer. Hier dürfen sie ihre wahre Qualiät beweisen. Wir würden sagen: In dieser Phase und mit diesen Entscheidungen wird eine Applikation ein echter Renner - oder ein Rohrkrepierer!).
Rechts ist die Erstellung eines Diagramms im fertigen Flußdiagramm-Editor zu sehen.

For starters and without going too much into the details, WordPress gives you the opportunity to add what it calls Custom Fields. Basically, these can be used on a WP-driven site for almost anything that isn't a built-in functionality and therefore give you a great deal of flexibility. They consist of a Name (Key) to address the field later on, and the fields content (Value/Wert) to be processed.

Portion of WPs admin-interface to set up custom fields

So when setting up this site (and being the structured worker that I am), I wanted to define some of the custom fields I was going to need first, and fill them with values later on. So I entered a name for the field, left Value blank for later, and hit Add/Create Custom Field.

Enter a key name, leave value blank...

But all I got was a nicely styled alert that told me that an unidentified error had occured (At least in the right place – the context where the error had occured). So I began to wonder what I had done wrong, if it was a WordPress bug, if I really wanted to wait for the next version to hopefully have it fixed and thereby postpone our site going live until a date unknown, or just switch to a different product immediately.

...and get a rather unspecific error message!

As you do, I started browsing and searching the WP support forums. As it goes, not to much avail. What WP didn't tell me was that you need to enter both key and value at ONCE, otherwise WP wouldn't create the required Custom Field. Which is perfectly fine - as long as you know about it.
And yes, by one of those twists of fate, I entered something for Value too and hit the button...

Enter something for Value too...

...et voilá, WP created the field (with a nice yellow glow effect that's worth creating Custom Fields alone)!

... and WP creates your Custom Field!

So apparently – from a technical point of view – everything is fine here: We have two fields and a proper validation. But dang, the user is led to believe something's just not working, he did something wrong and ends up overall frustrated, in doubt of either his own intellectual capabilites or the system itself.
Why is that? Simply because the system doesn't give him the information that he needs: Fill in BOTH fields, please.

As far as I can see, this would be easy to implement: There's two fields, a validation for both, so it shouldn't be too hard to validate what fields content is missing and tell the user in the most polite, informative and specific way what has happened and what to do now. He'll be comfortable, happy and love the system. Just as much we love WP - apart from that little flaw described here...
Thank you.

Specific message for happy users!

Konsistenz in Namen und Begriffen
Jede Website, jede Software, besitzt einen eigenen Informationsraum. Die offensichtlichste Prägung dieses Informationsraums geschieht über Namen und Begriffe. Jeder Nutzer von Microsoft Office Word weiß, was sich hinter dem Begriff "Formatvorlagen" verbirgt. Vielleicht können sich auch manche noch an den Tag erinnern, an dem Sie versucht haben, Ihren Text dauerhaft in einer bestimmten Schrift zu setzen. An dem Tag, an dem sie es geschafft haben, haben sie gelernt, was dieser Begriff in Word bedeutet.

Eine Google-Eingabe von "Word"+"Formatvorlage" erzielt 203.000 Treffer. Daran lässt sich ablesen, wie sehr dieser Begriff zur Konvention geworden ist. Microsoft würde sich keinen Gefallen tun, diese Funktionsgruppe in MS Word ab morgen "Schrift-Vorlagen" zu nennen. Obwohl der Ausdruck sprachlich ebenso möglich wäre. Die Umstellung und Neudefinition würde Ihnen und vielen anderen Nutzern die Arbeit zunächst einmal erschweren.

Das Prinzip ist einleuchtend: Was "Formatvorlage" heißt, betrifft auch die Funktion "Formatvorlage". Dieses Prinzip läßt sich auf jeden Namen und jeden Begriff, der in einer Software, auf einer Website geprägt wird, übertragen. Nur was gleich heißt, ist für den Benutzer auch das gleiche. Und das darf man getrost buchstäblich nehmen. Es betrifft Details wie Groß- und Kleinschreibung und Satzzeichen.

Konsistenz im Aussehen
Die Wirksamkeit von konsistenten Namen und Begriffen läßt sich steigern: Als Interface-Designer können wir gleichen Begriffen zusätzlich ein gleiches Aussehen geben, idealerweise ein prägnantes Aussehen, wenn es um zentrale Begriffe geht.

Ich benutze hier ein Beispiel aus einem Interface, daß wir für die Reiseplattform www.room-gallery.de entwickelt haben. Die Kennzeichnung für eine Buchung, die abgeschlossen und bestätigt ist, besitzt nicht nur die Bezeichnung "ok", sondern auch ein bestimmtes Aussehen ("der runde Knopf"). Überall, wo der Nutzer diesen Knopf sieht, weiß er zusätzlich: es geht hier um eine Buchung, und diese Buchung ist bestätigt.

Könnte man im Einzelfall auch nur den Begriff "ok" verwenden?
Nun, es besteht kein Zweifel, daß der Begriff grundsätzlich das gleiche meint. Für den Benutzer wäre es aber sicher schwieriger, den Zusammenhang zu erkennen. Wir würden also sagen: Nein - der Begriff alleine ist nicht das gleiche! Besitzt ein Symbol nur noch einen Teil der ursprünglichen Eigenschaften, ist es für den Benutzer auch nicht mehr das gleiche - und vermittelt nicht auf Anhieb die gleichen Informationen.

Gelerntes wiederaufnehmen – über verschiedene Medien hinweg
Noch einen Schritt weiter geht das Verweis-System der Wochenzeitung Der Freitag (nicht von uns entwickelt). Es benutzt das Prinzip "Gleiches Aussehen meint das Gleiche" auf andere Art. Jeder Artikel der Printausgabe wird abgeschlossen durch die Nennung des Verfassers und evtl. Hinweisen zu verwandten Themen. Dann folgt eine kleine Grafik, versehen mit einem Code. Es gibt ansonsten keine Erklärung dazu.
Die simple Abbildung eines Eingabefeldes, das Internet-Nutzer von Websites kennen, legt allerdings nahe, diesen Code im Internet zu benutzen. Und richtig: Bei Eingabe des Codes in das Suchfeld auf der Website gelangt man ohne Umwege zum gleichen Artikel online.
Hätte man unter den Artikeln alleine den Code notiert, und ihn nicht mithilfe der Grafik näher "beschrieben", wäre es sehr viel schwieriger, zu erkennen, was dieser Code bedeuten soll und wo er verwendet werden soll. Die Lösung über die Abbildung des Eingabefeldes ist ein eleganter Weg, einen Hinweis zu geben, ohne eine Darstellung zu überfrachten.

So kann Konsistenz auch umgekehrt wirken: Wenn einmal Elemente geprägt sind, also die Bedeutung vom Benutzer erlernt wurde, lassen sie sich sogar aus dem Zusammenhang gelöst benutzen. Das ist ein wertvoller Hebel, der uns auch in anderer Form tagtäglich begegnet: in Form von Logos!