Dr. Ronald Hartwig, Matthias Müller-Prove, Maren Mäuselein, Christian Jansen

up07-uidsun ^{5 Seiten, 56K}

Abstract

Usability Engineering kommt in länger bestehenden und sehr großen Projekten nur dann zum Zuge, wenn man sich an die Gegebenheiten der Projekte in Bezug auf das gewählte Prozessmodell anpasst und die Möglichkeiten in Zusammenarbeit mit den beteiligten Entwicklern auslotet.

Dieser Beitrag beschreibt zwei sich ergänzende Projekte im Umfeld von OpenOffice.org und einer Inhouse-ERP-Software, deren Benutzungsschnittstellen in einem gemeinsamen Vorhaben optimiert werden sollen.

Keywords. Inhouse-Usability, Software-Ergonomie, Usability Engineering, Prozessoptimierung, Open Source, Standardsoftware

Einleitung

Inhouse-Usability-Projekte und Usability-Engineering für Standardsoftware haben mit unterschiedlichen Herausforderungen zu kämpfen. Beiden gemein sind unter Umständen knappe Zeitbudgets, unscharfe Anforderungen an das Projektziel, sowie Projektpläne, in denen Usability kein integraler Bestandteil ist. Usability-Engineering Methoden können unter diesen Bedingungen nicht direkt aus der Literatur umgesetzt werden.

Aspekte des Usability-Engineering sind teilweise spezifisch für Inhouse-Systeme, die im Sinne von (Kowallik et al. 2005) auch als Individualsoftware bezeichnet werden können. Auf der anderen Seite hat Standard-, bzw. Produktsoftware Schwierigkeiten, die bei der Entwicklung von Inhouse-Systemen nicht auftreten. Diese Problembereiche bieten nun das Potenzial sich gegenseitig zu neutralisieren: Indem man den Anwendungkontext der Inhouse-Systeme zur Feldforschung der Standardsoftware nutzt, bieten sich für die Requirements-Phase Möglichkeiten die heterogene Nutzer- und Aufgabensituation exemplarisch genau zu untersuchen. Für das Unternehmen, das die Kombination aus Inhouse- und Standardsoftware einsetzt, besteht die Aussicht auf professionelle Standardsoftware, die leichter auf die internen Arbeitsprozesse anzupassen ist und die einen geringeren Schulungsaufwand bedeutet.

Veranschaulicht wird dies anhand eines Praxisbeispiels aus dem Umfeld eines der mitgliederstärksten deutschen Unfallversicherungsträger, der sowohl eine eigene Enterprise Resource Planning-Software (ERP) als auch die Open Source Bürosoftware OpenOffice.org einsetzt. Das Projektteam besteht aus einer Inhouse-Usability Expertin und der Leitung des Bereiches Datenverarbeitung, Vertretern der OpenOffice.org User Experience Community von Sun Microsystems und Usability-Beratern von der Firma User Interface Design GmbH (UID).

Ausgangssituation

Um das gewählte Vorgehen verstehen zu können, sind zunächst die beteiligten und ihre Motive zu betrachten.

Motive des Auftraggebers

Um Usability-Engineering Projekte anzustoßen, bedarf es zunächst eines entsprechenden Problembewusstseins beim Auftraggeber. Im vorliegenden Fall hat der Auftraggeber als Unfallversicherungsträger unter anderem auch Aufgabe der Sicherstellung ergonomischer Bildschirmarbeitsplätze im Sinne der Bildschirmarbeitsverordnung (BildscharbV). Dadurch entsteht hier eine klare Erwartungshaltung, in diesem Bereich auch bei den im eigenen Hause genutzten Anwendungen ein Optimum zu erzielen.

Dabei sind zwei Systeme von zentraler Bedeutung für die tägliche Arbeit: das eigene ERP-System und OpenOffice.org. Beide Systeme laufen in einer Linux-Umgebung und sind seit mehreren Jahren erfolgreich im Einsatz.

OpenOffice.org

OpenOffice.org ist ein kostenloses, quelloffenes Office-Paket, das Module zur Textverarbeitung, Tabellenkalkulation und Präsentationserstellung enthält. Desweiteren gibt es eine Zeichen- und ein Datenbankanwendung.

Das OpenOffice.org User Experience Team verspricht sich Hinweise auf Potenziale (vgl. Abschnitt 3.2), die Verbesserungen im Bereich der Gebrauchstauglichkeit für den Consumer- sowie dem Enterprise-Markt bringen.

Usability-„Coach“ UID

Oft werden Usability- und Design-Dienstleister zu einem sehr späten Zeitpunkt in Projekten eingebunden, wenn bereits die zentralen Konzeptionellen Entscheidungen, meist ohne hinreichende Berücksichtigung von Gebrauchstauglichkeitserfordernissen, gefallen sind.

Um dies zu vermeiden wurde in enger Zusammenarbeit mit dem Auftraggeber in diesem Projekt explizit ein projektbegleitendes Coaching-Konzept vereinbart. Das Interesse von UID ist dabei die langfristige Zusammenarbeit. Insbesondere soll so vermieden werden, dass man als Dienstleister hauptsächlich als Überbringer schlechter Nachrichten zum Thema Usability in Erscheinung tritt, nachdem die eigentlichen Ursachen ohne sein Zutun bereits in viel früheren Phasen zu suchen sind.

Die Zusammenarbeit mit OpenOffice.org hat dabei zusätzlich auch einen positiven Multiplikatoreneffekt.

Die Produkte

Usability-Engineering-Prozesse wie die ISO 13407 gehen in der Regel implizit davon aus, dass man ein neues Produkt beginnt, wohingegen summative Prüfverfahren und Zertifizierungen zwar ein fertiges und im Einsatz befindliches Produkt erwarten, aber dann keine Unterstützung des weiteren Entwicklungsprozesses bieten.
Im vorliegenden Fall, und vermutlich auch in einem sehr großen Teil anderer real existierender Software-Projekte, ist beides nicht der Fall. Stattdessen befindet man sich in einem Stadium der kontinuierlichen Weiterentwicklung einer Software mit begrenzten Ressourcen.

Hier bedeutete dies, dass die ERP-Software über 1.000 verschiedene „Vorgänge“ (Teilaufgaben unterschiedlichster Komplexität) abbilden muss. Im Umfang steht dem OpenOffice.org in nichts nach, da das Projekt seit bereits 7 Jahren unter dem Open-Source Modell entwickelt wird und eine vollständige Alternative zu Microsoft Office darstellt.

Ziel des Vorhabens ist nun, die Gebrauchstauglichkeit beider Produkte signifikant zu verbessern. Erste Ergebnisse sollen bereits innerhalb eines Jahres realisiert werden. Weitere Vorschläge gehen in die längerfristige Weiterentwicklung der Produkte ein.

Zum Zeitpunkt der Projektplanung stand dazu auf Seiten des Auftraggebers ein Usability-Team bestehend aus einer Usability-Referentin und zwei externen Beratern der Firma UID zur Verfügung.

Pragmatische Anpassung des Vorgehens

Eine vollständige Analyse der bestehenden Software oder auch nur des gesamten Nutzungskontextes scheidet aufgrund der schieren Masse aus. Es würde selbst bei Zuhilfenahme weiterer externer Kräfte Jahre dauern, die Aufgaben und Nutzungskontexte komplett zu erheben.

Daraus entstanden grundlegende Entscheidungen für das weitere Vorgehen:

1. Das Usability-Engineering Know-How soll flächendeckend beim Auftraggeber etabliert werden, um so nachhaltig die Qualität der eigenen Inhouse-Entwicklung sicherzustellen.
2. Es werden zunächst Arbeitsschwerpunkte bestimmt, von denen ausgehend dann mittelfristig die gesamten Anwendungen betrachtet werden.
3. Für die Verbesserung von OpenOffice.org wird direkt mit den Teams bei Sun zusammengearbeitet, die maßgeblich die Entwicklung von OpenOffice.org betreuen.

Coaching als Know-How-Transfer ins Unternehmen

Zentraler Bestandteil der Überlegungen zur Nachhaltigkeit des gesamten Vorhabens zur Gebrauchstauglichkeit ist, dass nicht eine externe Beraterfirma einmalig ein Gutachten erstellt, das dann Punkt für Punkt abgearbeitet werden kann, sondern das in einem gemeinsamen Projekt die notwendigen Fertigkeiten aus dem Bereich des Usability-Engineering vermittelt werden.

Dabei werden klassische Schulungselemente durch eine mehrmonatige Praxisphase am konkreten Projekt ergänzt, die von den Beratern von UID begleitet werden.

Inhalte des Coachings sind die verwendeten Methoden:

• Contextual Inquiry zur Feststellung des Nutzungskontextes und zur Aufgabenanalyse
• Teilnehmende Beobachtungen als Usability-Testing vor Ort
• Requirementsentwicklung aus Potenzialkomplexen
• Claims-Analyse bei der Entscheidungsfindung zur weiteren Umsetzung
• Konzeption von Lösungen und Prototypen

Das Coaching wird mit einem Team aus derzeit 10 Personen durchgeführt:

• Leitung der Usability-Abteilung
• Projektleitern des BGS-Projektes
• Entwickler des Inhouse-Systems

Die Projektbegleitung erfolgt durch gemeinsame Interviews und Tests sowie durch ein sehr enges iteratives Reviewing der erzeugten Dokumente.

Potenzial-getriebener Prozess

Zentrales Problem bei der Planung des Projektes waren die Fragen „Wieviel können wir schaffen?“ und „Wo fangen wir an?“ Wie beschrieben kam eine vollständige Analyse des IST-Zustandes aus Zeitgründen nicht in Frage. Deshalb wurde ein zweistufiges Verfahren beschlossen, das die vorhandenen Ressourcen berücksichtigt, aber auch möglichst relevante Ansatzpunkte sicherstellt.

Zunächst wird klargestellt, dass statt nach Mängeln nach „Potenzialen“ gesucht wird. Es ist gar nicht der Anspruch eines solchen Vorhabens, alle Probleme zu identifizieren, sondern mit den wesentlichsten Schwerpunkten zu beginnen.

Um solche zentralen Punkte zu identifizieren wurden mehrere Verfahren parallel eingesetzt, die für sich genommen relativ wenig Aufwand bedeuten:

Statistische Analyse der Nutzungshäufigkeit

Für das ERP-System stehen Daten zur Verfügung, wie häufig bestimmte Vorgänge verwendet werden. Die Annahme, dass Potenziale dann schwerer wiegen, wenn sie häufiger zum Tragen kommen, liegt da nahe. Allerdings wurde zusätzlich darauf geachtet, dass auch die verschiedenen Unternehmensbereiche abgebildet wurden, so dass die Top 10 aus allen Bereichen zusammengefasst wurden.

Workshops mit Multiplikatoren (Fachlehrern)

Eine weitere wichtige Quelle für die Planung dieses Typs von Projekten ist das Wissen von Personen, die Nutzer im Umgang mit dem System schulen oder bei Problemen als Ansprechpartner benannt sind. Beim Auftraggeber sind das die so genannten Fachlehrer.

Besonders für die Bestimmung von zentralen Einsatzszenarien von OpenOffice.org wurden mit den Fachlehrern entsprechende Workshops abgehalten, in denen in einer offenen, aber moderierten Diskussionsrunde die verschiedenen Einsatzszenarien besprochen und bekannte Auffälligkeiten dokumentiert wurden.

Vor-Ort-Analyse

Entlang der im vorigen Schritt festgelegten zentralen Elemente wurden dann Text-Szenarien entwickelt, die vor Ort mit Nutzern betrachtet werden. Im konkreten Fall waren dies 40 zentrale Aufgaben des ERP-Systems und 10 aus dem Bereich OpenOffice.org.

Zu diesen Aufgabenszenarien wurden typische Nutzer zunächst interviewt, um so ein abstraktes Aufgabenverständnis zu dokumentieren und später eventuelle Potenziale daran bewerten zu können.

Dann wurden 4 bis 5 teilnehmende Beobachtungen pro Aufgabe durchgeführt, um Usability-Potenziale festzustellen. Dabei wird unterschieden zwischen zwei Arten von Potenzialen:

• Aufgabenübergreifende Potenziale: Diese Potenziale, z.B. der Umgang mit einer elektronischen Akte allgemein, können durch allgemeine Ansätze verbessert werden.
• Aufgabenspezifische Potenziale: Dabei ist die Abbildung von konkreten Lösungsstrategien im Werkzeug Software verbesserungswürdig.

Zur Bewertung der Potenziale wird dann die abstrakte Aufgabenbeschreibung herangezogen, um so die aktuelle Beeinträchtigung, aber auch die möglichen weiteren Nutzen zu finden.

Verdichtung zu Potenzialkomplexen

Insgesamt waren nach 5 Monaten ca. 240 Interviews und teilnehmende Beobachtungen durchgeführt worden. Daraus resultierten 750 einzelne Potenziale. Diese werden immer feiner gruppiert und strukturiert bis am Ende die jeweiligen Kernpotenziale als „Potenzialkomplexe“ zusammengefasst werden können.

Ein Potenzialkomplex beinhaltet sowohl die Beschreibung des zu lösenden Problems als auch die Referenzen auf die darauf hinleitenden Beobachtungen.

Diese Komplexe (man könnte sie auch Meta-Potenziale nennen) sind dann die Grundlage für die weitere Projektentwicklung.

Umsetzung der Ergebnisse

Zu den Komplexen werden Lösungsvorschläge entwickelt, wobei dann im Rahmen einer Claims-Analyse relativ leicht Kosten (geschätzt anhand des Lösungsvorschlages) und Nutzen (anhand der dokumentierten Potenziale, die damit optimiert werden) gegenübergestellt werden können.

Entscheidend für den Erfolg des Konzeptes ist, dass so die Nachvollziehbarkeit von Lösungen über den gesamten Prozess erhalten bleibt. Da jede Lösung sich auf einen Potenzialkomplex bezieht und wiederum jeder Komplex aus konkreten Feststellungen besteht, können zu jeder Zeit Überlegungen zum Nutzen einer Änderung nachvollzogen und ggf. nacherhoben werden.

Einbindung in den OpenOffice.org Prozess

Für das OpenOffice.org-Projekt besteht bereits eine User Experience Community, die die Verbesserungsvorschläge von Seiten der Nutzer und Entwickler bewertet und in konkrete Verbesserungen umsetzt (Müller-Prove 2007).

Die Ergebnisse aus der Zusammenarbeit mit dem Auftraggeber und dem Usability-Engineering Dienstleister UID können so in diesen Prozess direkt einfließen. Dabei dienen die Ergebnisse der Workshops mit den Fachlehrern, der Interviews und teilnehmenden Beobachtungen zunächst als Rohdaten, zu denen zunächst „Issues“ (im Inhouse-Projektteil „Potenzial“ genannt) abgeleitet bzw. vor Ort erhoben werden.

Diese werden dann in einem zweiten Schritt zu „Validated Issues“ verdichtet, was den „Problemkomplexen“ entspricht.

Diese werden dann gewichtet und in die Concept-Phase des Product Life Cycle als Requirements mit ggf. vorhandenen Lösungsvorschlägen eingebracht.

Ergebnisse aus der Anwendung dieses Prozesses

In nur fünf Monaten wurden die Beobachtungen durchgeführt, Potenziale dokumentiert und verdichtet sowie Lösungsstrategien und Vorschläge für nachhaltige Prozessverbesserungen erarbeitet.

Primäre Effekte

In 240 Interviews und teilnehmenden Beobachtungen wurden 750 Einzelpotenziale identifiziert. Diese wurden anschließend kategorisiert und zu ca. 150 Problemkomplexen verdichtet.

50 dieser Komplexe wurden dabei als grundlegend, d.h. als aufgabenübergreifend identifiziert, während ca. 100 Komplexe aufgabenspezifisch waren. Somit konnten einerseits übergreifende Lösungsansätze als auch konkrete Verbesserungsvorschläge für einzelne Aufgaben entwickelt werden.

Der Vorteil der stufenweisen Ableitung ist, dass alle Potenzialkomplexe mit validierten Szenarien hinterlegt sind und in realen Vor-Ort-Situationen überprüft werden.

Dadurch können sie eine belastbare Grundlage für weitere Folgeprojekte für die zielgerichtete strategische Weiterentwicklung der Produkte bilden.

Sekundäre Effekte

Durch die Besetzung der Usability-Engineering-Teams auch mit Projektleitern und Entwicklern konnten diese „ihre“ Software und ihre offenen Potenziale in den täglichen Arbeitsabläufen unter (nahezu) realen Bedingungen erleben. Diese direkte Erfahrung führte zu einem besseren Verständnis für die Bedürfnisse der Nutzer bei den Entwicklern und zu einem größeren Bewusstsein für softwareergonomische (und allgemeine) Probleme in der Handhabung der Anwendung.

Gleichzeitig fühlen die Nutzer sich besser an der Entwicklung beteiligt, da sie direkt in den Prozess involviert waren und somit den Eindruck gewonnen haben, dass ihre Bedürfnisse Berücksichtigung finden.
Der zentrale sekundäre Effekt ist also, dass alle Beteiligten, Nutzer als auch Entwickler gemeinsam für die Usability und die Qualität der Software aktiv tätig werden und somit auch die Verbesserungen gemeinsam tragen.

Vorteile für die Beteiligten

Auftraggeber

Der Auftraggeber profitiert vor allem von der nachhaltige Verankerung des Know-Hows im Berech Usability Engineering im eigenen Haus. Durch Schulung und die konkrete Projektdurchführung haben Vorhabensteam und Leitung nicht nur Bewusstsein sondern auch praktische Erfahrung in diesem Gebiet gewonnen.

Dadurch und durch die nachhaltige Verbesserung des Entwicklungsprozesses wird eine dauerhafte Verbesserung der Produktqualität erreicht.

Desweiteren wird er seiner Vorbildfunktion im Bereich Software-Ergonomie durch die Entwicklung eines Vorgehens zur Optimierung ihrer Software und dem Bestreben nach größtmöglicher Gebrauchstauglichkeit gerecht.

OpenOffice.org Projekt

Dem Problem, dass Standardsoftware für einen anonymen Kunden entwickelt wird, ist durch die Zusammenarbeit mit dem Auftraggeber als prototypischem Kunden und UID als zusätzliche Instanz mit Usability-Engineering-Wissen, erfolgreich begegnet worden. Für das OpenOffice.org Projekt sind dabei wertvolle Anforderungen aus echten Anwendungsfällen erhoben worden. Der direkte Kontakt zu Nutzern und die Kenntnis realer Anwendungskontexte ist dabei äußerst hilfreich die Prioritäten zwischen konkurrierenden Requirements zu bestimmen.

In diesem Sinne bedeutet die Zusammenarbeit auch einen wichtigen und neuen Beitrag zu einem Open Source Projekt, der der Verbesserung der Gebrauchstauglichkeit von OpenOffice.org dient.

Vorteile für UID als Usability-Dienstleister

Das partnerschaftliche Vorgehen sorgt für eine gemeinsame Vertrauensbasis und steigert die Zufriedenheit des Kunden nachhaltig.

Statt eines kurzzeitigen (und dabei meist eher terminlich zu engen als ausreichenden) Zeitraums, entsteht so eine im Sinne eines wirksamen Usability-Engineerings wünschenswerte langfristige Prozessbegleitung.

Ausblick

Aufgrund des für alle Seiten positiven Verlaufes wird das Projekt in den nächsten Jahren weiter fortgesetzt. Dabei sind sowohl weitere Teams im Fokus als auch weitere Produktbereiche.

Im Bereich OpenOffice.org sind weitere Iterationen und Workshops vorgesehen, die auch auf das Open Source Kalenderprojekt Mozilla Lightning ausgeweitet werden sollen. Im Bereich ERP soll das Gesamtthema „elektronische Akte“ eine zentrale Bedeutung bekommt.

Literaturverzeichnis

• Boehm, B.; Egyed, A.; Kwan, J.; Port, D.; Shah, A.; Madachy, R. (1998): Using the WinWin Spiral Model: A Case Study. IEEE Computer 31(7), 1998, S. 33-44.
• Dzida,W.; Hofmann,B.; Freitag, R.; Redtenbacher, W.; Baggen,R.; Geis,T.; Beimel, J.; Zurheiden, C.; Hampe-Neteler,W.; Hartwig, R.; Peters, H.: Gebrauchstauglichkeit von Software Ergo Norm: Ein Verfahren zur Konformitätsprüfung von Software auf der Grundlage von DIN EN ISO 9241 Teile 10 und 11. Bremerhaven: Verlag für neue Wissenschaft.
• Hartwig, R. (2005): Usability Standards, Gesetze und Entwicklungsprozesse. Information Management & Consulting 20(3), 2005, S. 64-67. www.im-c.de/im/pages/abstracts32005.htm
• Hartwig, R.; Darolti, C; Herczeg, M. (2003): Lightweight Usability Engineering Scaling Usability-Evaluation to a Minimum? In Jacko, J., Stephanidis, C. (Hrsg.): Human Computer Interaction - Theory and Practice (Part I). London: Lawrence Erlbaum Associates Publishers. S. 474-478. hci03.scalable_usability.final-mit_Pub-Hinweis.pdf
• ISO (Hrsg.) (1996): ISO 9241 - Ergonomic requirements for office work with visual display terminals. Internationaler Standard. Berlin: Beuth Verlag.
• ISO (Hrsg.) (1999): ISO 13407 - Benutzer- und aufgabenorientierte Herstellungsprozesse – 1999E. Internationaler Standard. Berlin: Beuth Verlag.
• Kowallik, P. ; Müller-Prove, M., Strauß, F. (2005): Requirements-Engineering im Spannungsfeld von Individual- und Produktsoftware. i-com (3)2005
• Müller-Prove, M. (2007): User Experience for OpenOffice.org. interfaces (71)