scieee Science in your language
[en] (orig)
Universität Ulm | 89069 Ulm | Germany
Fakultät für
Ingenieurwissenschaften
und Informatik
Institut für Datenbanken und
Informationssysteme
CONCEPTION, DESIGN AND EVALUATION OF A
GRAPHICAL USER-INTERFACE FOR A CLOUD-PLAT-
FORM FOR BUSINESS PROCESS MANAGEMENT
MASTERARBEIT
Vorgelegt von:
Britta Meyer
britta.ju[email protected]
Gutachter:
Prof. Dr. Manfred Reichert
Prof. Dr. Peter Dadam
Betreuer:
Jens Kolb
2014
II
Fassung 18. September 2014
© 2014 Britta Meyer
III
ZUSAMMENFASSUNG
Due to the high complexity of Business Process Management (BPM) software, in-
tensive training periods for users are necessary. Therefore, a lightweight Business
Process Management System (BPMS) is designed, in order to reduce the complex-
ity of BPMS functionality to a minimum. The aim of this work is to develop a graph-
ical user interface for a BPM cloud platform. Particularly, the administration, mod-
eling, and execution of process models are combined in one system. Further, it is
well-suited for collaborative purposes, such as sharing of process models and col-
laborative process modeling and execution. Consequently, the user’s acceptance
can be increased. In addition, usability aspects like a consistent interaction are con-
sidered. A modern and simple visual design helps to increase the improvement of
the BPMS’ usability and leads to ensure the user’s acceptance. During develop-
ment, the BPMS’ usability is evaluated by a usability test involving end-users. Par-
ticularly, the usability test ensures to identify weaknesses with regard to the BPMS’
usability. Besides the aspect of usability, the emotional factor of the visual design
is considered in order to optimize the user experience. This includes innovative
solutions, increasing the user’s enthusiasm through satisfying the user’s needs.
Therefore, the developed BPMS offers innovative solutions including process filters
to reduce process model’s complexity, a store concept with preconfigured pro-
cesses, a timeline functionality and the translation of a BPMN process model to a
more compact representation.
IV
VORBEMERKUNG ZUM SPRACHGEBRAUCH
Alle Personen- und Funktionsbezeichnungen in dieser Arbeit gelten für Frauen und
Männer in gleicher Weise. Bei Bezeichnungen von Personen und Personengruppen
wird auf die Darstellung der weiblichen Schreibweise verzichtet, um eine bessere
Lesbarkeit zu gewähren. Mit der männlichen Form wie z.B. Benutzer sind stets auch
alle weiblichen Personen angesprochen.
V
INHALT
1 Einleitung ..................................................................................................................................... 1
Motivation .......................................................................................................................... 1
Problemstellung ............................................................................................................... 2
Beitrag dieser Arbeit ....................................................................................................... 3
Aufbau der Arbeit ............................................................................................................ 4
2 Grundlagen ................................................................................................................................. 7
Business Process Management .................................................................................. 7
Prozessmodellierung............................................................................................. 7
Modellierungssprache .......................................................................................... 8
Rollen in Workflows ........................................................................................... 11
Usability-Engineering .................................................................................................. 12
Usability .................................................................................................................. 12
Joy-of-Use .............................................................................................................. 13
UI-Design................................................................................................................ 13
Vorgehensweise ................................................................................................... 14
Psychologische Grundlagen der Systementwicklung ..................................... 18
Visuelle Wahrnehmung ..................................................................................... 18
Wirkung von Farbe ............................................................................................. 20
Bewertung von Arbeitstätigkeit ..................................................................... 23
Usability-Guidelines und Style-Guides ................................................................. 24
Gesetzliche Verordnungen .............................................................................. 24
Normen ................................................................................................................... 25
Regelsammlungen .............................................................................................. 26
Hersteller- oder plattformabhängige Style-Guides................................ 30
User Expierence .................................................................................................... 30
VI
3 Wissenschaftliche Methodik .............................................................................................. 33
Anforderungsanalyse .................................................................................................. 33
Evaluationen und Tests .............................................................................................. 36
4 Anforderungsanalyse ........................................................................................................... 39
Geschäfts- und Einsatzziele ...................................................................................... 40
Analyse Ist-Stand .......................................................................................................... 40
Effektif ...................................................................................................................... 41
Ravencloud ............................................................................................................ 42
Benutzerprofilanalyse ................................................................................................. 44
Aufgabenanalyse .......................................................................................................... 44
Umgebungsbedingungen ......................................................................................... 68
Hardware- und Software-Randbedingungen .................................................... 69
Generelle Entwurfsprinzipien ................................................................................... 69
Usability-Ziele ................................................................................................................ 69
Zusammenfassung ....................................................................................................... 72
5 UI-Entwurf ................................................................................................................................ 73
Konzeptuelles UI-Modell und UI-Mockups ........................................................ 74
Interaktionsstil ...................................................................................................... 74
Interaktionsdesign .............................................................................................. 75
Navigationskonzept ......................................................................................... 108
Iterative UI-Walkthroughs ....................................................................................... 112
Elektronische UI-Prototypen .................................................................................. 112
Iterative Usability-Tests ............................................................................................ 113
UI-Styleguide ............................................................................................................... 113
Farbkonzept......................................................................................................... 113
Affordance von Interaktionselementen .................................................... 120
VII
Typographie ........................................................................................................ 121
Icon-Design ......................................................................................................... 122
Detailentwurf ................................................................................................................ 128
Anmeldung an das BPMS ............................................................................... 128
Ordnerübersicht ................................................................................................. 129
Prozessmodellübersicht .................................................................................. 132
Prozessmodellansicht ...................................................................................... 138
Store ....................................................................................................................... 146
Profileinstellung ................................................................................................. 147
Timeline mit Historie von Prozessmodellen ............................................ 148
Einstellungen ....................................................................................................... 151
Detailentwurf an Hand von Use-Cases ..................................................... 156
Zusammenfassung ..................................................................................................... 157
6 Evaluationen und Test........................................................................................................ 159
Vorbereitungsphase des Usability-Tests ........................................................... 160
Probanden für die Evaluierung des BPMS ............................................... 161
Selektion von Testleiter und Beobachter ................................................. 161
Beschreibung des Usability-Labors und des Prototyps ...................... 162
Interaktionsszenarien ....................................................................................... 162
Fragebögen für Bewertung des BPMS ...................................................... 164
Messtechnik ......................................................................................................... 167
Testdurchlauf des Usability-Tests ......................................................................... 167
Durchführungsphase des Usability-Tests .......................................................... 167
Vorbereitung des Usability-Tests ................................................................ 167
Ablauf des Usability-Tests .............................................................................. 169
Datenauswertung ....................................................................................................... 169
VIII
Kontextinformationen zu den Probanden ............................................... 170
Ergebnisse des ASQ .......................................................................................... 170
Ergebnisse des Iso-Norm 9241/110-S ...................................................... 171
Ergebnisse des UEQ.......................................................................................... 174
Entwurfsoptimierungen............................................................................................ 175
Zusammenfassung ..................................................................................................... 186
7 Zusammenfassung .............................................................................................................. 189
A Iso-Norm 9241/110-S ........................................................................................................... IX
B UEQ ............................................................................................................................................ XV
C Kontextinformationen ........................................................................................................ XIX
D Einverständniserklärung .................................................................................................... XXI
E Beobachtertabelle ............................................................................................................. XXIII
F Leitfaden für die Testleitung .......................................................................................... XXV
G Szenarien ............................................................................................................................ XXVII
H Detailentwurf ....................................................................................................................... XXIX
I Datenauswertung ........................................................................................................... XXXIII
1
1 EINLEITUNG
MOTIVATION
Aufgrund der Globalisierung und Technologisierung der Märkte werden neue Ge-
schäftsmodelle geschaffen und es tun sich neue Wettbewerbsverhältnisse auf [1].
Die Bildung neuer Geschäftsmodelle und Wettbewerbsverhältnisse führen zu einer
sich stetig ändernden Prozesslandschaft im Unternehmen. Da Produkte und Leis-
tungen in ihrer Komplexität und Individualität steigen, erhöht sich die Komplexität
der Geschäftsprozesse. Die Modellierung von Geschäftsprozessen stellt dabei keinen
einmaligen Vorgang dar, da sich Anforderungen, aufgrund sich stetig ändernden
Abläufe in einem Unternehmen zunehmend wandeln. Aufgrund der sich kontinu-
ierlichen verändernden Prozesslandschaft stellt die Prozessoptimierung, -änderung
und -anpassung ein zentraler Aspekt im Unternehmen dar. Der Trend im Unter-
nehmen geht folglich zur Nutzung von Cloud-Services, da Fachabteilungen eine
bessere Unterstützung in ihren Geschäftsabläufen sehen:
Unternehmen müssen in einem globalen, wettbewerbsintensiven und
höchst dynamischen Wirtschaftsumfeld in der Lage sein, ihre Ge-
schäftsprozesse jederzeit agil anzupassen. Mit der herkömmlichen,
oftmals veralteten und deshalb wartungsintensiven sowie heteroge-
nen IT- und Applikationslandschaft lassen sich diese Anforderungen
nicht mehr erfüllen. Cloud-Services hingegen unterstützen dynami-
sche Geschäftsabläufe und mobiles Arbeiten [2].
Dabei ist das wichtigste Unternehmensziel durch den Einsatz von Cloud-Services,
Geschäftsprozesse zu optimieren (siehe Abbildung 1).
Die zweitwichtigste Maßnahme für IT-Abteilungen stellt dabei die Integration von
Cloud-Services und Unternehmensanwendungen dar. Dazu gehören Datenbanken
und andere Anwendungen, wie z.B. Enterprise-Resource-Planning (ERP) mit Content
-Relationship-Management (CRM). Durch die Nutzung von Cloud-Services werden
Fachabteilungen besser unterstützt. Gründe, welche für die Nutzung von Cloud-
Services sprechen, sind dabei vielschichtig. Dieser Aspekt wird im folgenden Kapitel
genauer erläutert.
1 Einleitung
2
ABBILDUNG 1: UNTERNEHMENSZIELE DURCH DEN EINSATZ VON CLOUD-SERVICES
PROBLEMSTELLUNG
Das Management und die IT im Unternehmen werden klassischerweise von großen
Datenbankmanagementsystemen getrieben, wie SAP und Oracle [2]. Da keine oder
nur im unzureichendem Maße eine technische Integration von Datenbankmanage-
mentsystemen geschaffen wird, entsteht folglich eine Abneigung gegenüber Pro-
zessmanagementsystemen. Resultierend daraus werden Geschäftsprozesse nicht
aus der Fachabteilung erfasst, da die Mitarbeiter der Fachabteilung im Unterneh-
men nicht ausreichend an die Prozessmodellierung herangeführt werden. Die enge
Zusammenarbeit zwischen IT- und Fachbereichen stellt aufgrund mangelnden ge-
genseitigen Verständnisses eine Herausforderung dar [2]. Fachbereiche verfügen
über zu wenig technisches Verständnis und umgedreht werden die Anforderungen
der Fachbereiche von der IT nicht ausreichend verstanden. Diese Barriere führt
dazu, dass Fachbereiche ohne die Einbeziehung der IT, im Alleingang Cloud-Ser-
vices nutzen.
Dadurch steigt die Gefahr einer sogenannten Schatten-IT [3]. Als Schatten-IT wer-
den dabei IT-Lösungen bezeichnet, welche eine geschäftsprozessunterstützende
Funktion übernehmen und von Fachabteilungen eingesetzt werden, ohne dass die
IT davon informiert wird. Cloud-Services erleichtert somit „[...] diesen Einsatz durch
eine ausgeprägte Prozessorientierung und den vereinfachten Zugang zu IT-Lösungen
“ [3]. Folglich breitet sich die Schatten-IT zunehmend aus und stellt somit die IT-
Abteilung vor neue Herausforderungen z.B. Kontroll- und Transparenzverlust. In
1.3 Beitrag dieser Arbeit
3
Abbildung 2 wird diese steigende Kluft verdeutlicht: Im Jahr 2013 nutzen bereits
32 Prozent der Fachabteilungen teilweise Cloud-Services, davon sogar 12 Prozent
sehr umfangreich [2].
ABBILDUNG 2: CLOUD-SERVICE-NUTZUNG OHNE IT-ABTEILUNG
Trotz der Risiken, welche durch die Schatten-IT entstehen, besitzt diese einen ho-
hen Innovationscharakter. Die wichtigsten Motive für den Einsatz von Cloud-Ser-
vices sind dabei schnelle und flexible Geschäftsabläufe und die kurzfristige Imple-
mentierung von Geschäftsprozessen [2] . Ein weiterer Grund liegt darin, dass die
Fachabteilungen die Business Process Management (BPM) Software ablehnen [4].
In der Studie BPMN-Report 2012 geht bereits hervor, dass Unternehmen mit ihrer
BPM Software unzufrieden sind. Demnach sind über die Hälfte der Unternehmen
mit ihrer BPM Software nur bedingt zufrieden und ein weiteres Drittel gar nicht
zufrieden. Gründe liegen vor allem in den großen Verständnisproblemen zwischen
Fach- und IT-Abteilung. Weiter kritisieren die Benutzer die Komplexität des BPMS.
Zudem werden die Anforderungen der Benutzer z.B. Kosten sparen und Prozesse
eigenständig gestalten zu können, unzureichend bis gar nicht erfüllt. Durch die
mangelnde Akzeptanz der Benutzer, was auf das Nichterfüllen der Anforderungen
beruht, wird das Scheitern von BPMN-Projekte begründet [4].
BEITRAG DIESER ARBEIT
Beitrag dieser Arbeit ist es ein Graphical-User-Interface (GUI) für einen Cloud-Ser-
vice für BPM zu entwickeln. Dabei handelt es sich um ein „leichtgewichtiges“ BPMS.
1 Einleitung
4
Die Besonderheit liegt darin, dass die harte Trennung zwischen Prozessmodellie-
rung und -ausführung aufgeweicht wird und als kompakte Lösung im BPMS mitei-
nander verschmolzen wird. Dieser hybride Ansatz soll auch nicht technischen Be-
nutzern in Unternehmen die Prozessmodellierung und -ausführung ermöglichen.
Ohne technische Vorkenntnisse kann der Benutzer so schnell ein Prozessmodell
erzeugen. Zudem kann der Benutzer bereits kleine Prozessmodelle in der Gruppe
entwickeln und mit der IT kommunizieren. Dadurch wird die Zusammenarbeit zwi-
schen IT- und der Fachabteilung transparenter. Zudem werden die Anforderungen
der Benutzer erfüllt, welche Prozessmodelle eigenständig gestalten möchten [4].
Auch ein unternehmensübergreifender Ansatz ist gegeben, da BPM auf einer
Cloud-Platform angeboten wird.
Des Weiteren soll die Anforderung nach einer problemlosen Bedienung gegeben
sein [4]. Daher wird versucht die Komplexität des Interaktionskonzepts so minimal
wie möglich zu halten, um einen schnellen Einstieg zu ermöglichen. Durch ein In-
teraktionsmuster, in der konstante Interaktionselemente verwendet werden, wird
eine intuitive Bedienung aufrechterhalten und auch nicht-technische Benutzer mit-
einbezogen. Des Weiteren wird die Akzeptanz des Benutzers gegenüber des BPMS
durch ein zeitgemäßes visuelles Design verstärkt. Folglich wird dem Eigenleben in
Fachabteilungen entgegengewirkt (Schatten-IT) und die generelle Abneigung ge-
genüber BPMS gesenkt und das Scheitern von BPMS-Projekten minimiert [4].
AUFBAU DER ARBEIT
Das Grundlagenkapitel dieser Arbeit stellt Kapitel 2 dar, in der eine Einführung von
BPM, sowie von Usability-Engineering gegeben wird. Dabei werden Begrifflichkei-
ten, welche im Zusammenhang zu Usability-Engineering stehen, genauer erläutert.
Anschließend werden die psychologischen Grundlagen für die Systementwicklung,
sowie Usability-Guidelines und Style-Guides wiedergegeben, welche bei der Ge-
staltung des BPMS berücksichtigt werden. Abschließend wird in Kapitel 2 die User
Experience genauer erläutert. Die wissenschaftliche Methodik ist in Kapitel 3 auf-
gezeigt, welche die Vorgehensweise dieser Arbeit erklärt. Die Basis des UI-Entwurfs
bildet dabei Kapitel 4, in der die Anforderungen vorgestellt werden, welche das
BPMS erfüllen sollte. Nachdem die Anforderungen festgelegt sind, wird in Kapitel
1.4 Aufbau der Arbeit
5
5 neben dem Interaktionsdesign, das Navigationskonzept und das visuelle Design
aufgezeigt. Abschließend wird die fertige GUI des UI-Entwurfs präsentiert. Dieser
wird durch einen Usability-Test evaluiert (siehe Kapitel 6). Eine Zusammenfassung
und Ausblick in Kapitel 7 rundet die Arbeit ab. In Abbildung 3 wird der grundle-
gende Aufbau dieser Arbeit ersichtlich.
ABBILDUNG 3: AUFBAU DIESER ARBEIT
1 Einleitung
6
7
2 GRUNDLAGEN
BUSINESS PROCESS MANAGEMENT
Die Beherrschung von komplexen Geschäftsprozessen wird Business Process Ma-
nagement (BPM) zugeschrieben. Geschäftsprozesse werden im organisatorischen
Bereich von BPM als betriebliche Abläufe interpretiert, in deren Mittelpunkt der
Benutzer steht. Dabei sollte für den Benutzer die Modellierung und Ausführung
von Prozessmodellen so ausgerichtet sein, dass diese für ihn leicht verständlich
sind [5].
In [6] wird BPM als ein Kreislauf dargestellt, welcher sich von der strategischen Aus-
richtung, Erhebung, Analyse und Sollkonzeption, organisatorische und IT-technische
Implementierung bis hin zum kontinuierlichen Monitoring und periodischen Report-
ing der Prozessmodelle erstreckt. BPM führt dabei die IT- und organisatorischen
Perspektive zusammen [1] (siehe Abbildung 4).
ABBILDUNG 4: BUSINESS PROCESS MANAGEMENT
PROZESSMODELLIERUNG
Arbeitsaufgaben (z.B. ein Benutzer beantragt einen Reiseantrag), welche durchgän-
gig den gleichen Arbeitsablauf zur Folge haben, können durch ein Prozessmodell
beschrieben werden. Dieser stellt einen Ablauf von Bearbeitungsschritten dar. Im
2 Grundlagen
8
Gegensatz zu einem Projekt (i.d.R. nur einmalig wiederholbar), ist der Ablauf eines
Prozessmodells wiederholbar. Aus diesem Wissen heraus, können für die Bewälti-
gung von Arbeitsaufgaben immer die gleichen organisatorischen Mittel verwendet
werden. Die Prozessmodellbeschreibung stellt dabei ein Regelwerk dar, welches
veranschaulicht, wie ein Prozess aufgebaut ist [1].
MODELLIERUNGSSPRACHE
Um Geschäftsprozesse in Prozessmodellen zu beschreiben, wird eine Modellie-
rungssprache verwendet. Viele Tools verwenden eine eigene spezielle Prozessbe-
schreibungssprache, aber zunehmend haben sich die folgenden durchgesetzt: er-
eignisgesteuerte Prozessketten (EPK), Acitivity Diagrams (UML) und Business Process
Modelling and Notation (BPMN). In Abbildung 5 sind die Kernelemente von BPMN
aufgeführt.
ABBILDUNG 5: KERNELEMENTE DER BPMN
Flussobjekte
Zu den Flussobjekten gehören Aktivitäten, Ereignisse und Gateways [1].
Aktivität: Aus dem Gesichtspunkt der Informationsverarbeitung werden drei
verschiedenen Typen von Aktivitäten betrachtet:
2.1 Business Process Management
9
o Manuelle Aktivität: Die manuelle Aktivität wird vom Benutzer
ausgeführt wie z.B. Verhandlungen oder Telefonate, ohne eine
technische Unterstützung.
o IT-unterstützte Aktivität: Diese Aktivität wird mit Hilfe eines IT-
Systems erledigt, wie z.B. eine Auftragserfassung oder
Internetrecherche
o Automatische Aktivität: Die Ausführung dieser Aktivität erfolgt
automatisch durch das IT-System ohne menschliche Unterstützung,
wie z.B. eine Zinsberechnung oder einen automatischen Versand.
Ereignisse: Ein Prozessmodell beginnt und endet mit einem Ereignis.
Gateways: Innerhalb von Prozessmodellen können Gateways auftreten, d.h.
Prozessabläufe unterteilen sich.
o XOR-Gateway: Kann in einem Gateway nur ein alternativer Weg
gewählt werden, so liegt ein XOR-Gateway vor.
o AND-Gateway: In einem AND-Gateway werden alle alternativen
Wege durchlaufen, wie z.B. bei einem Bestelleingang. Hier muss
neben der Prüfung der Ware und der Kundenbedingung, auch die
Bonität kontrolliert werden.
Verbindende Objekte
Verbindende Objekte können die Kommunikation mit Partnern veranschaulichen
(Nachrichtenflüsse) oder Artefakte miteinander verknüpfen (Assoziationen). Mit
Hilfe von verbindenden Objekten können zudem Flussobjekte miteinander ver-
knüpft werden (Sequenzfluss). Flussobjekte unterliegen immer einer logischen
Reihe und folglich einer zeitlichen Abfolge. Mit Hilfe von Datenkanten wird diese
zeitliche Abfolge visualisiert. Wie in Abbildung 6 gezeigt, kann Aktivität 2 erst star-
ten, nachdem Aktivität 1 abgeschlossen ist.
ABBILDUNG 6: SEQUENZFLUSS
2 Grundlagen
10
Artefakte
Artefakte reichern das Prozessmodell durch Daten an, welche erzeugt oder verwen-
det werden, wie z.B. das Empfangen und Versenden einer Nachricht.
BPMN-Prozessmodelle lassen sich gut automatisieren und in Workflows umsetzen.
Dann tritt die organisatorische Sicht weitestgehend in den Hintergrund und die
technische Sicht wird stärker ausgebildet. Dies hat zur Folge dass sie für nicht tech-
nikaffine Benutzer schwerer verständlich sind als für technikaffine Benutzer.
Swimlanes
Swimlanes dienen zur Zuordnung von Prozesselementen zu bestimmten Systemen,
Rollen, etc. Wie in Abbildung 7 kann die Rolle des Kunden und des Versandhauses
deutlicher gemacht werden, da die Prozesselemente innerhalb der Swimlanes po-
sitioniert werden können. In dieser Abbildung werden alle Kernelemente der BPMN
nochmals aufgezeigt.
Ereignis Datenobjekt Sequenzfluss Aktivität
ABBILDUNG 7 KERNELEMENTE DER BPMN
Nachrichtenfluss
XOR-Gateway
AND-Gateway
Assoziation
2.1 Business Process Management
11
ROLLEN IN WORKFLOWS
Das Rollenkonzept ist eine zentrale Komponente des Human Workflow Manage-
ments. Dabei werden, den am Prozess beteiligten Benutzern ihre Aufgaben zuge-
wiesen.
Beziehungen zwischen Prozessbeteiligten
Die Beziehungen zwischen Prozessbeteiligten werden im Folgenden an Hand eines
Szenarios Urlaubsantrag verdeutlicht [1]. Ein Mitarbeiter beantragt seinen Urlaub.
Bevor der Urlaub genehmigt wird, muss das Vorgangsobjekt Urlaubsantrag dem
Mitarbeiter zugeordnet werden, welcher gegenüber dem Antragsteller die Rolle
des Abteilungsleiters einnimmt.
Folglich findet eine Rollenauswertung statt, um den Urlaubsantrag dem korrekten
Abteilungsleiter zuzuweisen. Nach der Genehmigung, wird der Antragssteller in-
formiert und gleichzeitig ein zweiter Mitarbeiter involviert, welcher die Rolle Sach-
bearbeiter zugeschrieben ist. Dem Sachbearbeiter wird der Urlaubsantrag in seine
Aufgabenliste gelegt, damit diese bearbeitet wird. Hier gilt ein weiteres Rollenkon-
zept der Aufgabenzuordnung: Einer Rolle kann unterschiedliche Aktivitäten zuge-
ordnet werden, aber eine Aktivität kann nur von einer bestimmten Rolle durchge-
führt werden (1:N-Beziehung). D.h. es wird nicht nur einem bestimmten Mitarbeiter
den Urlaubsantrag zugewiesen, sondern alle Mitarbeiter, welche die Rolle Sachbe-
arbeiter bekleiden. Der nächste freie Mitarbeiter z.B. ein Sachbearbeiter in der Per-
sonalabteilung nimmt sich die Aufgabe zur Bearbeitung an. Wichtig ist auch das
Vertreterregelungen vorliegen, wenn bei Abwesenheit einer Person die Aufgaben
von einem geeigneten Vertreter übernommen werden.
Im Folgenden werden die Begriffe Gruppe, Rolle und Benutzer einer Organisations-
einheit nochmals detaillierter beschrieben (siehe Tabelle 1).
2 Grundlagen
12
Bestandteile einer
Organisations-
einheit
Gruppe
Rolle
Benutzer
TABELLE 1: BESTANDTEILE EINER ORGANISATIONEINHEIT
USABILITY-ENGINEERING
Im Folgenden werden zentrale Begriffe des Usability-Engineerings (siehe Kapitel
2.2.3 bis Kapitel 2.2.2 ) näher erläutert, sowie eingesetzte Mittel und Techniken, um
das angestrebte Ziel einer guten Usability für ein zu entwickelnde System zu errei-
chen. Die Vorgehensweise des Usability-Engineerings wird in Kapitel 2.2.4 genauer
vorgestellt, in der auch die Benutzerpartizipation im Entwicklungsprozess mitbe-
rücksichtigt wird.
USABILITY
Für den Begriff Usability gibt es unterschiedliche Begriffe. Eason (1984) definierte
als einer der ersten Usability wie folgt:
2.2 Usability-Engineering
13
Usability is presented as a concept, which can limit the degree to
which a user can realize the potential utility of a computer BPMS [7].
Eason versteht unter diesem Begriff die Differenz zwischen der Nützlichkeit eines
Systems und dem Grad der Fähigkeit und Willens des Benutzers, dieses zu nutzen.
Dabei wird das System als soziotechnisches System verstanden, welches aus den
Komponenten Hardware, Software und menschlichen Unterstützern besteht [8]. Da-
bei hat die Internationale Organisation für Standards (ISO) definiert, was unter dem
Begriff Usability zu verstehen ist. In der Norm DIN EN ISO 9241 wird seit 1997 die
Usability definiert. Usability wird dargelegt, als ein Ausmaß in dem ein technisches
System durch bestimmte Benutzer in einem bestimmten Nutzungskontext verwen-
det werden kann, um Ziele effektiv, effizient und zufriedenstellend zu verwirklichen.
JOY-OF-USE
Als Erweiterung von Usability hat sich das Konzept Joy-of-Use oder Fun-of-Use be-
hauptet [8]. Allerdings können sich diese zwei Konzepte auch ausschließen, da eine
gute Bedienung ein einfach gestaltetes System voraussetzt [9]. Resultierend daraus
wird die Freude durch zu wenig Abwechslungsreichtum gemindert. Obwohl gute
Usability für die Produktqualität einen zentraler Aspekt darstellt, sollte der Faktor
Freude nicht außer Acht gelassen werden [8]. In [10] wird darauf hingewiesen, dass
der Faktor Freude bei der Beurteilung eines Systems erst eine Rolle spielt, wenn
das System bereits ein gewisses Maß an Nutzungskontext erreicht hat. Dies zeigt
sich am Beispiel von Computerspielen. Sind diese motivierend, leicht zu bedienen
und machen Spaß, so können sie sich schneller am Markt durchsetzen [8].
UI-DESIGN
Die Gestaltung einer funktionalen Benutzerschnittstelle anhand von definierten An-
forderungen, stellt das User-Interface-Design (UI-Design) dar [11]. Das UI-Design
ist dabei eng mit Usability-Engineering und dem Interaktionsdesign verbunden. Das
Interaktionsdesign beinhaltet alle Steuerungen eines Systems, welche für den Be-
nutzer zur Verfügung stehen, sowie dessen Verhalten und Rückmeldungen an den
Benutzer [11]. Dabei wird darauf geachtet, dass bei der Gestaltung des UI eine
möglichst gute Usability erreicht wird [12].
2 Grundlagen
14
VORGEHENSWEISE
Das Usability-Engineering wird an Hand einer entsprechenden Vorgehensweise
durchgeführt. Im Folgenden werden die einzelnen Schritte des Usability-Enginee-
rings aufgezeigt, welche begleitend in die Entwicklung eines Systems einfließen
können [8]:
1. Analyse der Arbeit und dessen Umfeld
2. Analyse der Benutzer
3. Festlegung von Anforderungen
4. Vereinbarungen über Funktionalität und Ableiten eines Bedienkonzeptes
5. Evaluation und Systemverbesserung
6. Einführung und Schulung
7. Weiterentwicklung
Obwohl starke Argumente für Usability-Engineering sprechen, werden aus Zeit-
und Kostengründen nicht alle Schritte des Usability-Engineering umgesetzt. Oft
findet vor Abschluss des Projekts nur eine Evaluation statt. Für ein gründliches Vor-
gehen müssen zeitliche und finanzielle Ressourcen bereitliegen [8]. Zudem müssen
alle Personen, welche bei der Entwicklung des Systems beteiligt sind, zusammen-
spielen, um eine gute Usability zu erreichen.
Usability-Engineering wird parallel zur Softwareentwicklung angewendet. Im Ideal-
fall werden diese zwei getrennten Abläufe, als ein gemeinsamer Prozess durchge-
führt [8]. Zudem spielt die Integration der Benutzer in den Softwareentwicklungs-
prozess eine wichtige Rolle. Speziell müssen deren Anforderungen und die Aufga-
ben, sowie die Schwierigkeiten während des Nutzens berücksichtigt werden.
Referenzmodell der Daimler AG
Im folgenden Kapitel wird das Referenzmodell der Daimler AG genauer erläutert, an
Hand die Vorgehensweise dieser Masterarbeit verdeutlich wird. Der Vorteil des Re-
ferenzmodells liegt darin, dass es während der Systementwicklung ergonomische
Aspekte mit einbezieht und zudem hohen Wert auf eine kontinuierliche Benutzer-
partizipation legt. Dadurch ist ein Endprodukt mit hoher ergonomischer Güte rea-
lisierbar. Zudem ist positiv hervorzuheben, dass die Anforderungsanalyse als Ent-
2.2 Usability-Engineering
15
wicklungsphase betont wird, in welche ein Großteil der Aktivitäten einfließen müs-
sen. Nachteilig kann genannt werden, dass hingegen die Überleitung in die Nut-
zung ein sehr kleiner Anteil am Gesamtprojekt nur einnimmt. Das Referenzmodell
der Daimler AG besteht aus fünf wesentlichen Entwicklungsphasen (siehe Abbil-
dung 8), nämlich der Projektvorbereitung, Anforderungsanalyse, UI-Entwurf, Evalu-
ation und Test, Überleitung in die Nutzung sowie Nutzung und Pflege [8, 13]. Diese
Entwicklungsphasen sind in Abbildung 8 dargestellt.
ABBILDUNG 8: REFERENZMODELL DER DAIMLER AG
Die einzelnen Phasen werden als logische Phasen verstanden, d.h., dass die Phasen
für das zu entwickelnde System nicht strikt nacheinander durchlaufen werden müs-
sen. Die Phasen des Referenzmodells können iterativ für Teilsysteme verwendet
werden, dabei ist aber von Bedeutung, dass die Reihenfolge innerhalb der Prozess-
schritte eingehalten wird. Durch Tailoring kann das Referenzmodell auf den Fokus
dieser Arbeit zugeschnitten werden, was ein weiterer Vorteil dieses Referenzmo-
dells darstellt. Im Folgenden werden die sechs Entwicklungsphasen kurz erläutert:
1. Projektvorbereitung: Diese Phase beinhaltet sechs Prozessschritte. Dazu ge-
hören eine Kosten-Nutzen-Analyse, eine Angebotserstellung sowie organi-
satorische Aspekte. Des Weiteren ist die Rollenverteilung, die Planung der
Arbeitspakete und Benutzerbeteiligung mitinbegriffen. Die Projektvorberei-
tung beinhaltet vom Gesamtaufwand des Modells etwa zehn Prozent. Ziel
2 Grundlagen
16
dieser Phase ist es, alle erforderlichen Maßnahmen zu treffen, welche für
das Usability Engineering sinnvoll sind.
2. Anforderungsanalyse: Mit 40 Prozent stellt die Anforderungsanalyse den
größten Teil dar. Dabei werden bereits vorhandene Systeme und Benutzer-
profile analysiert und der Kontext des Systems erfasst. Dies bildet die Grund-
lage für die ausgewählte Hard- und Software. Zuletzt werden generelle Ent-
wurfsprinzipien und Usability-Ziele festgelegt. Das Ziel der Anforderungs-
analyse ist es, von jedem Dialogsystem alle Grundanforderungen zu erhal-
ten. Dadurch können Dialogsysteme benutzer- und aufgabenangemessen
gestaltet werden [13].
3. UI-Entwurf: Diese Phase beinhaltet 30 Prozent des Entwicklungsprozesses.
Auf Basis eines konzeptuellen Usability-Modells werden einfache Entwürfe
bis hin zu elektronische UI-Prototypen erstellt, welche anschließend im ite-
rativen UI-Walktrough und Usability-Test überprüft werden. Resultierend
wird daraus ein Style-Guide entwickelt und der Detailentwurf ausgearbeitet.
Ziel dieser Phase ist es einen aufgabenangemessenen UI-Entwurf zu ent-
werfen [13].
4. Evaluation und Test: Die vorletzte Phase mit nur zehn Prozent des Gesamt-
aufwandes, beinhaltet die Evaluation des Systems. Hier werden die UI-Ent-
würfe nochmals optimiert, um festzustellen, ob alle Entwurfsentscheidun-
gen 1:1 übernommen werden können [13].
5. Überleitung in die Nutzung: Die letzten zehn Prozent beinhalten die Einfüh-
rung in das System, was vom Kunden abgenommen wird. Mittels Bedie-
nungsanleitungen und Schulungen wird das System dem Endbenutzer näher
gebracht. In dieser Phase wird das System für die Nutzung vorbereitet [13].
6. Nutzung und Pflege: Hier werden Rückmeldungen der Benutzer eingeholt.
Die Ergebnisse werden dann für Weiterentwicklungen genutzt. In dieser
Phase werden vor allem für zukünftige Versionen weitere Erkenntnisse für
die Verbesserung des Systems gewonnen [13].
2.2 Usability-Engineering
17
Benutzerbeteiligung
Know about your user – you are not your user [14].
Eine Vielzahl von Veröffentlichungen begründen, dass das Einbinden des Benutzers
in die Systemgestaltung zu positiven Effekten führen kann [8]. Auch Gottschalch
wies auf die Wichtigkeit des Nutzers hin:
Da die Prozeduren in primär kognitiv zu charakterisierender Tätigkeit
heute sehr komplex geworden sind, können die Arbeitsprozesse nicht
mehr mit tayloristischen Methoden der Verhaltensbeobachtung und -
Analyse standardisiert und maschinisiert werden; man ist auf die in-
teressierte Beteiligung der künftigen Benutzer angewiesen, (…) man
beteiligt also, weil man muss(…) [15]
Auch die DIN EN ISO 9241-210 fordert eine Benutzerpartizipation im Entwicklungs-
prozess [16]. Abbildung 9 zeigt Prozessschritte, die bei der mensch-zentrierten Ge-
staltung durchlaufen werden [8]:
ABBILDUNG 9: PROZESSCHRITTE IN DER MENSCH-ZENTRIERTEN GESTALTUNG
Dabei werden Forderungen an die Qualität der Benutzerzufriedenheit in Bezug des
zu entwickelnden Systems erfüllt [17]. Der Nutzungskontext umfasst dabei, den Be-
nutzer selbst, seine Arbeitsaufgaben und Arbeitsmittel, sowie die physische und
2 Grundlagen
18
soziale Umgebung. Wie in Abbildung 9 gezeigt, werden dabei iterativ folgende vier
Schritte durchlaufen:
1. Beschreibung des Nutzungskontexts
2. Beschreibung der Erfordernisse, welche im Nutzungskontext anfallen
3. Spezifikation der Anforderungen im Nutzungskontext
4. Spezifikation der Interaktion zwischen Anwender und System
PSYCHOLOGISCHE GRUNDLAGEN DER SYSTEMENTWICKLUNG
Neben der Partizipation des Benutzers, sollte eine Vielzahl von psychologischen Er-
kenntnissen und Methoden berücksichtigt werden, um die Belange des Benutzers
in die Entwicklung des Systems zu berücksichtigen [8]. Dabei werden Aspekte der
kognitiven Psychologie berücksichtigt, welche von der menschlichen Wahrnehmung
über den Denkprozess bis hin zu Gesichtspunkten des Lernens [8] reichen. Dazu ge-
hört z.B. die maximale Tiefe eines Menüs dazu oder ein konsistent, aufgebautes
Menüs [12].
VISUELLE WAHRNEHMUNG
Die visuelle Wahrnehmung, stellt neben den taktilen und akustischen Reizen, die
Basis für die Interaktion mit der Benutzerschnittstelle dar [12]. Wahrgenommene
Reize des Gehirns werden dabei verarbeitet und Teile zu einem Ganzen konstruiert.
Währen dieser Konstruktion laufen Organisationsprozesse ab, welche als Gestalt-
gesetze beschrieben werden. Diese erklären, wie die räumliche und zeitliche Anord-
nung auf den Benutzer wirken. [18]. Im Folgenden werden die Gestaltgesetze auf-
geführt und erläutert [12].
Figur-Grund-Trennung
Ein Bild wird in Figur und Hintergrund getrennt, dabei er-
hält die Figur mehr Aufmerksamkeit. Eine Figur wird wahr-
genommen, wenn sie die Eigenschaft eines kleinen, ge-
schlossenen Bereichs mit symmetrischer oder konvexer
Form erfüllt. Daher sollte im Design sollte ein Kontrast
zwischen Figur und Hintergrund eingehalten werden.
2.3 Psychologische Grundlagen der Systementwicklung
19
Gesetz der Symmetrie
Die Aufmerksamkeit kann durch das Gesetz der Symmetrie
gelenkt werden. Dabei wird Elementen, welche symmet-
risch zueinander geordnet sind, mehr Aufmerksamkeit ge-
schenkt wie zufällig angeordneten Elementen.
Gesetz der Einfachheit (gute Form)
Ist eine Figur auf mehrere Arten interpretierbar, so kommt
das Gesetz der Einfachheit zum Zuge. Dabei wählt das Auge
die einfachste Form. Können zusammengesetzte Elemente
nicht als Ganzes interpretiert werden, werden sie in be-
kannte Formen zerlegt.
Gesetz der Nähe
Elemente, welche räumlich nahe beieinander liegen, wer-
den als Gruppe wahrgenommen. Wird dieses Gesetz einge-
halten, so kann auf Trennlinien und Rahmen im visuellen
Design verzichtet werden.
Gesetz der guten Fortsetzung
Das Auge folgt stets einem Richtungsimpuls. Ein Text ist
beispielsweise leichter lesbar, wenn dieser an einer Linie
ausgerichtet ist.
Gesetz der Prägnanz
Elemente, welche sich aus einer Vielzahl von Objekten
durch ein oder mehrere Merkmale abheben, werden als
Erste wahrgenommen. Dieses Gesetz kann genutzt werden,
um gezielt wichtige Informationen hervorzuheben.
Gesetz der Verbundenheit
Elemente werden als Einheit gesehen, wenn diese mitei-
nander verbunden sind. Dieses Gesetz ist stärker als das
Gesetz der Nähe und der Ähnlichkeit.
2 Grundlagen
20
Gesetz der Ähnlichkeit
Elemente sind ähnlich, wenn sie in Bezug auf Form, Farbe,
Textur, Größe oder Bewegungsrichtung gleich sind. Diese
werden vom Auge gruppiert. Beispielsweise kann in einer
Legende so Daten in eine Einheit gesetzt werden.
Gesetz der Geschlossenheit
Das Gesetz der Geschlossenheit wird oft als Stilmittel für Lo-
gos eingesetzt. Figuren, werden trotz fehlender Teile richtig
interpretiert, da sie komplettiert werden.
Gesetz des gemeinsamen Schicksals
Die Zusammengehörigkeit von Elementen kann durch die
Positionierung in die gleiche Richtung, erzeugt werden.
WIRKUNG VON FARBE
Farben haben auf den Menschen eine psychologische Wirkung. Grün hat einen be-
ruhigenden, Rot einen erregenden Effekt [12]. Diese Erkenntnis spielt beim visuel-
len Design eines Systems (siehe Kapitel 5.5) eine wichtige Rolle. Farben geben ei-
nem System eine visuelle Identität und unterstreichen dessen Charakter. Ein har-
monisches Farbkonzept wirkt sich positiv beim Betrachter aus. Ein Farbkonzept
setzt sich dabei aus einer Reihe von Farben zusammen, welches vorgibt, welche
Farben eingesetzt und zu welchem Zwecke sie verwendet werden. Wird z.B. der
Farbton, welcher durch Sättigung und Helligkeit der Farbe variiert, bildet sich eine
Reihe von harmonischen Farben. Diese werden auch als Farbklang bezeichnet.
Jeder Farbklang hat dabei eine unterschiedliche Wirkung: belebend, natürlich, pro-
fessionell, fröhlich oder düster. Daher ist die Farbwahl für das visuelle Design und
für die User Experience eins Systems ein entscheidender Faktor. Nachfolgend wer-
den einer der bekanntesten Farbklänge mit Hilfe des Farbkreises (siehe Abbildung
10) vorgestellt und kurz erläutert [12].
2.3 Psychologische Grundlagen der Systementwicklung
21
ABBILDUNG 10: FARBKREIS
Monochromatisch
Ein monochromatischer Farbklang wird aus zwei gleichen
Farbtönen, die sich in Helligkeit oder Sättigung unterschei-
den können, erzeugt. Dadurch wird ein dezentes und ruhi-
ges Farbbild geschaffen.
Analog
Dieser Farbklang enthält Farben, welche im Farbton im glei-
chen Wert variieren, was ein ansprechendes Farbbild
schafft.
Komplementär
Farbtöne, welche im Farbkreis gegenüber liegen, erzeugen
ein komplementäres Farbbild. Bei diesem intensiven Farb-
bild, sollte auf weitere Farben verzichtet werden.
Teilkomplementär
Dies ist eine abgeschwächte Form des komplementären
Farbklangs, welcher aus zwei benachbarten Farbtönen be-
steht. Dieses Farbbild wirkt harmonischer als das Komple-
mentäre.
Triadisch
Wie der Namen bereits verrät, werden drei Farben verwen-
det. Da dieser Farbklang sehr kontrastreich ist, wird eine
Farbe mit weniger Sättigung dargestellt.
2 Grundlagen
22
Tetradisch
Ein hoher Kontrast mit harmonischer Wirkung wird aus zwei
Paaren von komplementären Farben erzeugt. Dabei wird
eine Farbe oft als Hauptfarbe verwendet. Die anderen Far-
ben werden passend zur Farbe gesättigt oder aufgehellt
dargestellt.
Wirkung von Farbe
Durch das gezielte Einsetzen von Farben, kann eine bestimmte Botschaft gesen-
det werden. Daher ist es wichtig, die Wirkung von Farben zu verstehen, welche
sich aufgrund kulturellen und fachlichen Hintergründen der Benutzer unterschei-
den [12] .In Tabelle 2 sind Farben und ihre Bedeutung bzw. Wirkung aufzeigt.
Farbe
Bedeutung
Rot
Die Farbe Rot steht für Glut, Hitze, Blut, Leidenschaft, Liebe
etc. und besitzt von allen Farben die stärkste Signalwirkung.
Folglich wird sie in der fachspezifischen Assoziation für
Stopp, Fehler und Gefahr eingesetzt.
Orange
Orange wird in Zusammenhang mit Abendsonne und Feuer
gebracht und ist auffälliger als Gelb. Sie wird als Warnfarbe
verwendet. Des Weiteren symbolisiert sie in der natürlichen
Assoziation Wärme und Freude.
Gelb
Licht und Sonne werden mit der Farbe Gelb in Verbindung
gebracht. Weswegen diese auch als Warnfarbe verwendet
wird. In der natürlichen Assoziation symbolisiert sie Kraft,
Optimismus und Frische.
Blau
Kühle, Ruhe, Ernsthaftigkeit und Seriosität werden durch die
Farbe Blau beim Menschen als natürliche Assoziation aus-
gelöst. Diese Farbe findet ihren Einsatz häufig als Informa-
tionsfarbe.
Violett
Die Farbe Violett steht für Spiritualität, Religion, Macht und
Mystik.
2.3 Psychologische Grundlagen der Systementwicklung
23
Schwarz
Neben Asche, Dunkelheit und Tod besitzt die Farbe Schwarz
die Symbolik für Exklusivität und Seriosität. Daher sind pro-
fessionelle Produkte oft in schwarz gehalten.
TABELLE 2: FARBEN UND IHRE BEDEUTUNG
Beim Einsatz von Farbe sollte generell darauf geachtet werden, dass man sich auf
wenige Farben beschränkt und die Farbwahl auf die Zielgruppe angepasst wird. Bei
großen Flächen sind schwache gesättigte Farben von Vorteil. Eine gute Lesbarkeit
kann durch einen hohen Kontrast erzeugt werden [12]. Neben der richtigen Farb-
wahl im System, spielt auch das Umfeld, in welcher der Benutzer das System aus-
führt eine Rolle bei der Gestaltung des Systems.
BEWERTUNG VON ARBEITSTÄTIGKEIT
Die Art und Weise wie Menschen denken, ist individuell unterschiedlich. Des Wei-
teren werden sie beeinflusst durch Müdigkeit, Ängste oder Motivation. Daher ist es
wichtig bei einer Evaluation Faktoren wie Kenntnisse des sozialen und betrieblichen
Umfeldes des Systems zu berücksichtigen. Die Arbeitsaufgabe und das Umfeld, in
der die Arbeit getätigt wird, prägen daher auch die Gestaltung des Systems. Somit
ist die Berücksichtigung von arbeitspsychologischen Aspekten unabdingbar [8].
Hinweise auf eine optimale Arbeitsgestaltung und deren Bewertung von Arbeitstä-
tigkeiten, findet sich in [19] und werden in Tabelle 3 erläutert.
Arbeitstätigkeiten
Beschreibung
Ganzheitlichkeit
Aufgaben sollten neben planenden und ausführenden Ele-
menten auch kontrollierende beinhalten. Aus der Tätigkeit
der Rückmeldung wird der Benutzer über seinen Arbeits-
fortschritt informiert.
Anforderungsviel-
falt
Eine einseitige Beanspruchung kann durch unterschiedliche
Anforderungen an Körperfunktionen und Sinnesorgane ver-
mieden werden. So werden individuelle Fähigkeiten, Fertig-
keiten und Kenntnisse genutzt.
Möglichkeiten der
sozialen Interak-
tion
Aufgaben sollten kooperativ dem Benutzer nahegelegt wer-
den. Auftretende Schwierigkeiten können in Kooperation
gemeinsam gelöst werden.
2 Grundlagen
24
Autonomie
Entscheidungsmöglichkeiten in Aufgaben fördern das Be-
wusstsein des Mitarbeiters, Verantwortung zu übernehmen
und ein Gefühl des Einflusses wird gestärkt.
Lern- und Ent-
wicklungsmög-
lichkeiten
Die geistige Flexibilität wird erhöht, in dem Qualifikationen
bei der Aufgabenbewältigung eingesetzt bzw. erweitert o-
der erlernt werden müssen.
Zeitelastizität
Ein zeitlicher Rahmen für die Aufgabenbewältigung geben
den Benutzer den nötigen Spielraum und lassen Freiraum
für freies Nachdenken.
Sinnhaftigkeit
Um eine Identifikation mit dem Produkt zu schaffen, sollte
das herzustellende Produkt gesellschaftlich sinnvoll sein.
TABELLE 3: BEWERTUNG VON ARBEITSÄTIGKEITEN
USABILITY-GUIDELINES UND STYLE-GUIDES
Der Ursprung der Usability-Evaluation bilden dabei Usability-Guidelines. Diese zei-
gen ein breites Spektrum von Gestaltungsvorgaben auf, welche bei der Gestaltung
eines UI berücksichtigt werden sollen. Diese können wie folgt unterschieden wer-
den [11]:
Richtlinien
G(UI)-Guidelines
Style-Guides
TABELLE 4: GESTALTUNGSVORGABEN
Im Folgenden wird eine Unterteilung von Guidelines vorgestellt, was eine Erleich-
terung der Einordnung von Gestaltungsvorgaben im Usability-Bereich schafft [11].
Dabei wird nach [11] eine Unterteilung von Usability-Guidelines an Hand ihres Ver-
wendungszweckes vorgenommen und im Folgenden genauer erläutert.
GESETZLICHE VERORDNUNGEN
Gesetzliche Verordnungen beinhalten gesundheitliche Aspekte, wie beispielsweise
den Gesundheitsschutz des Arbeitsnehmers im Umgang mit technischen Geräten.
2.4 Usability-Guidelines und Style-Guides
25
Im EU-Raum gelten Vorschriften, welche Mindestanforderungen einer Mensch-
Maschinen-Schnittstelle festsetzen [20]
NORMEN
Die Standardisierung des Systems durch Gestaltungsvorgaben ist das Ziel nationa-
ler und internationaler Normen. Bei den folgenden vorgestellten Normen, handelt
es sich um Normen der internationalen Standardisierungsorganisation (ISO). In Ta-
belle 5 wird der Teil 110, welcher sich auf die Grundsätze der Dialoggestaltung be-
zieht, genauer erläutert [8, 21]:
Grundsätze
Aufgabenange-
messenheit
Selbstbeschrei-
bungsfähigkeit
Steuerbarkeit
Individualisierbar-
keit
Lernförderlichkeit
Fehlertoleranz
TABELLE 5: GRUNDSÄTZE DER DIALOGGESTALTUNG
2 Grundlagen
26
REGELSAMMLUNGEN
Regelsammlungen stellen frei verfügbare Sammlungen dar, welche begleitend zum
Entwicklungsprozess von UIs eingesetzt werden, um diese zu optimieren. Dazu ge-
hören allgemeine Usability Prinzipien, wie die Usability-Heuristics [22], die Design-
prinzipien von Google [23] oder das Windows 8-Style UI [24]. Im Folgenden werden
in Tabelle 6 die zehn Usability-Heuristiken vorgestellt [22, 25] genauer betrachtet.
Allgemeine Usability-Heuristiken
Richtlinie
Sichtbarkeit des
Systemstatus
Übereinstimmung
zwischen System
und realer Welt
Kontrolle und
Freiheit
Konsistenz und
Standards
Lernförderlichkeit
Erkennen statt
Erinnern
Flexibel und
Effizienz
2.4 Usability-Guidelines und Style-Guides
27
Ästhetik und
Minimalismus
Unterstützung bei
Fehlern
Hilfe und
Dokumentation
TABELLE 6: ALLGEMEINE USABILITY-HEURISTIKEN
Designprinzipien von Google
Regelmäßig werden die Designprinzipien von Google überprüft, um sie aktuell zu
halten [23]. In Tabelle 7 sind diese beschrieben.
Designprinzipien
Der Benutzer steht
an erster Stelle,
alles Weitere folgt
von selbst
Es ist am besten,
eine Sache so
richtig gut zu ma-
chen
Schnell ist besser
als langsam
Demokratie im In-
ternet funktio-
niert
2 Grundlagen
28
Man sitzt nicht
immer am
Schreibtisch, wenn
man eine Antwort
benötigt
Geld verdienen,
ohne Jemanden
damit zu schaden
Irgendwo gibt es
immer noch mehr
Informationen
Informationen
werden über alle
Grenzen hinweg
benötigt
Seriös sein, ohne
einen Anzug zu
tragen
Gut ist nicht gut
genug
TABELLE 7: DESIGNPRINZIPIEN VON GOOGLE
Designprinzipien von Microsoft für das Windows 8-Style UI
In Tabelle 8 werde die fünf Designprinzipien von Microsoft vorgestellt [26]. Diese
Prinzipien sind Vorgaben für das Designen von Apps, wie sie in Abbildung 11 zu
sehen sind [27].
2.4 Usability-Guidelines und Style-Guides
29
ABBILDUNG 11: WINDOWS 8-STYLE UI
Designprinzipien
Stolz auf Hand-
werkskunst
Schnell und
Fließend
Authentisch
Digital
Erreiche mehr
durch Weniger
Win-as-One
Irgendwo gibt es
immer noch mehr
Informationen
2 Grundlagen
30
Informationen
werden über alle
Grenzen hinweg
benötigt
TABELLE 8: DESIGNPRINZIPIEN VON MICROSOFT
HERSTELLER- ODER PLATTFORMABHÄNGIGE STYLE-GUIDES
Diese beschreiben das Look&Feel eines Systems von einem bestimmten Betriebs-
system [11]. Hierzu zählen die Apple Human Interface Guidelines und die Windows
Benutzer Experience Interaction Guidelines. In Tabelle 9 werden drei Unternehmens-
Style-Guides und Projekt-Style-Guides vorgestellt und kurz beschrieben.
Style-Guides
Unternehmens-
Style-Guides
Projekt-Style-Gui-
des
TABELLE 9: ARTEN VON STYLE-GUIDES
USER EXPIERENCE
Vertreter von User Experience bemängeln, dass sich Usability zu stark auf die funk-
tionalen Aspekte eines Systems bezieht. User Experience hingegen setzt sich mit
der Gestaltung des Systems, verbunden mit der Kommunikation des Benutzers,
auseinander [11]. Tritt der Benutzer in Kontakt mit einem System, erfährt er ein
bestimmtes Erlebnis und hat bestimmte Erwartungen. Der technische Fortschritt
begünstigt diese Erwartungshaltung. Denn was heute interessant ist, kann morgen
schon als Standardfunktionalität vorausgesetzt werden. Übersteigt das Produkt die
Erwartungen, so hat der Benutzer ein positives Erlebnis. Positive Erlebnisse lösen
Glücksgefühle aus, was wieder dazu führt, dass diese wiederholt werden möchten
2.4 Usability-Guidelines und Style-Guides
31
[12]. Der Kern von User Experience-Design ist es diese positive Erlebnisse zu stär-
ken. In [28]. Ist ein Produkt nach Basis-, Leistungs- und Begeisterungsmerkmalen
unterteilt.
Merkmale
Basismerkmale
Leistungsmerk-
male
Durch Leistungsmerkmale können Produkte verglichen wer-
den und in Leistungsklassen eingeteilt werden. Sie werden
verwendet für Verkaufsargumente und helfen dem Benutzer
Produkte zu vergleichen.
Begeisterungs-
merkmale
TABELLE 10: PRODUKTMERKMALE
In Abbildung 12 wird die Unterteilung dieser Produktmerkmale nochmals veran-
schaulicht. Die User Experience hat das Ziel das Gesamterlebnis der Nutzung ei-
nes System zu optimieren [11]. Das Gesamterlebnis ist dabei abhängig von den
Erwartungen des Benutzers. Neben der Berücksichtigung der Erwartungen der Be-
nutzer ist es wichtig, Informationen über den Benutzer zu sammeln. Des Weiteren
ist die Berücksichtigung der Systemumgebung unumgänglich. Auch die Berück-
sichtigung der aktuellen Marktsituation, Trends und Mitbewerber muss betrachtet
werden. Auf dieser Basis kann das UI-Design des Systems festgesetzt werden. Der
Funktionsumfang wird passend zu den Zielen der Nutzer abgesteckt, die Informa-
tionsarchitektur zur Denkweise verständlich dargelegt, zum Vorgehen ein passen-
des Interaktionsdesign (siehe Kapitel 5.1.2) zur Verfügung gestellt und für den ge-
2 Grundlagen
32
wählten Stil ein ästhetisches visuelles Design (siehe Kapitel 5.5) angefertigt. Wer-
den diese Aspekte berücksichtigt, kann das System die Erwartungen auf verschie-
denen Ebenen erfüllen und für ein positives Erlebnis sorgen
ABBILDUNG 12: PRODUKTMERKMALE
. Abbildung 13 veranschaulicht die Berührungspunkte, in der Eigenschaften des Be-
nutzers auf die Merkmale des Systems treffen.
ABBILDUNG 13: BERÜHRUNGSPUNKTE DES BENUTZERS
33
3 WISSENSCHAFTLICHE METHODIK
Die Vorgehensweise dieser Arbeit orientiert sich an dem Referenzmodells der Daim-
ler AG. Das Referenzmodell wurde bereits in Kapitel 2.2.4 vorgestellt. Durch Tailo-
ring kann das Referenzmodell auf den Fokus dieser Arbeit zugeschnitten werden
(siehe Abbildung 14). Der Fokus liegt dabei auf den Phasen: Anforderungsanalyse,
UI-Entwurf und Evaluation und Tests.
ABBILDUNG 14: VORGEHENSWEISE DIESER ARBEIT
Die Ergebnisse aus den Phasen werden im Folgenden erläutert und einzelne Teil-
bereiche daraus in Kapitel 4, Kapitel 5 und Kapitel 6 detailliert.
ANFORDERUNGSANALYSE
In dieser Phase erfolgen Basisarbeiten, welche die Grundlage für den späteren UI-
Entwurf des zu entwickelnde Systems in dieser Arbeit bildet [13]. Das zu entwi-
ckelnde System wird in dieser Arbeit als Business Process Management System
(BPMS) bezeichnet. Das Ziel ist es alle Grundanforderungen jedes Dialoges im
3 Wissenschaftliche Methodik
34
BPMS zu ermitteln. Dazu werden relevante Informationen zu den Benutzern und
ihren Aufgaben im Arbeitskontext zusammengetragen.
Geschäfts- und Einsatzziele
Für das Design des BPMS stellen Geschäfts- und Einsatzziele harte Randbedingun-
gen dar. Aus diesen Zielen lassen sich grundlegende Designziele bzgl. der Aufga-
bengemessenheit und Handbarkeit des BPMS ableiten. Diese müssen so früh wie
möglich definiert werden.
Analyse Ist-Stand
Diese Phase beinhaltet die Analyse von Alt- und Konkurrenzsystemen. Dabei wer-
den sowohl negative, als auch positive Aspekte der BPMSs festgehalten. Durch die
Analyse von Konkurrenzsystemen können weitere Ideen und Lösungen generiert
werden, um das BPMS zu verbessern.
Kontextanalyse
Die Kontextanalyse zielt auf die Analyse des Kontextes, in welches das BPMS später
eingesetzt werden soll, ab. Die Kontextanalyse dient dabei als Oberbegriff, der in
die Bereiche Benutzerprofil-, Aufgabenanalyse und Umgebungsbedingungen unter-
teilt werden kann [13].
Generelle Entwurfsprinzipien
Bereits vor der Entwicklung des BPMS liegen sogenannte allgemeine Regeln vor,
welche als generelle Entwurfsprinzipien bezeichnet werden [13] . Diese dienen als
Grundlage für den UI-Entwurf des zu entwickelten BPMS (siehe Kapitel 5). Dazu
gehören Usability-Guidelines und Style-Guides, welche in Kapitel 2.4 aufgeführt
sind.
Usability-Ziele
Usability-Ziele basieren auf den Ergebnissen der Geschäftsziele, Benutzer- und Auf-
gabenanalyse. Daraus folgend wird festgehalten, welchen Beitrag die Oberfläche
des BPMSs dabei leisten soll. Des Weiteren stellen sie auch Akzeptanzkriterien dar,
welche für den Usability-Test (siehe Kapitel 6) erfüllt werden sollten [13]. UI-Entwurf
3.1 Anforderungsanalyse
35
Auf Basis der Anforderungsanalyse findet der UI-Entwurf statt, in welchem sicht-
bare Entwürfe für das BPMS und seine Dialoge gestaltet werden. Die Aufgaben der
Benutzer und die festgelegten Usability-Ziele werden während des gesamten Ge-
staltungsprozess fortlaufend gegenübergestellt und evaluiert. Hauptziel des UI-
Entwurfs ist es, dass alle ermittelten Anforderungen im UI-Entwurf des BPMS zu
berücksichtigen [13].
Workflow Reengineering
Der Startpunkt des UI-Entwurfs stellt das Workflow Reengineering dar. In diesem
Prozessschritt werden die Arbeitsabläufe der Benutzer analysiert und entschieden,
wie weit diese Arbeitsabläufe geändert werden sollen. Das Workflow Reenginee-
ring wurde in dieser Arbeit nicht berücksichtigt, da noch keine konkreten Endbe-
nutzer existieren.
Konzeptuelles UI-Modell und UI-Mockups
Bei der Erstellung eins konzeptuellen UI-Modells wir ein einheitliches Fundament
geschaffen, welches die Basis für den weiteren Gestaltungsprozess bildet. Dabei
werden Entscheidungen bzgl. des konzeptuellen UI-Modells auf abstrakter Ebene
getroffen. Diese Entscheidungen werden mit Hilfe von UI-Mockups sichtbar ge-
macht. Daher ist dieser Prozessschritt eng mit dem folgenden Prozessschritt UI-
Mockups verzahnt. Das konzeptuelle UI-Modell wird mittels UI-Mockups, welche
auch Wireframes genannt werden, umgesetzt. Des Weiteren können mit Hilfe von
UI-Mockups Evaluationen des BPMS durchgeführt werden. So kann früh festge-
stellt werden, ob das grundsätzliche Interaktionskonzept zur Erledigung der Aufga-
ben der Benutzer, geeignet ist. UI-Mockups repräsentieren Grundfunktionen und
kleine Teile von Dialogfunktionalitäten sowie die Navigation. Dabei werden ver-
schiedene Varianten entwickelt, miteinander verglichen und Stärken und Schwä-
chen der Varianten ermittelt. Dies fördert die Bildung von neuen Ideen und trägt
dazu bei weitere Anforderungen sicherzustellen [13, 29].
3 Wissenschaftliche Methodik
36
Elektronische UI-Prototypen
Nach dem iterativen UI-Walkthroughs und Festlegung des Interaktionskonzepts
liegt bereits ein relativ stabiler UI-Entwurf vor. Mit Hilfe von elektronischen UI-Pro-
totypen wird dieser UI-Entwurf verfeinert. Dabei werden wesentliche Interaktions-
elemente des Systems und der Navigationsplan (Navigation zwischen Fenstern) be-
reits umgesetzt. Durch die Entwicklung eines elektronischen UI-Prototyps für das
BPMS kann das Look&Feel des BPMS ermittelt werden. Der elektronische UI-Pro-
totyp wird auch später für die Evaluationen und Test des BPMS verwendet.
Iterative Usability-Tests
Analog zum iterativen UI-Walkthroughs werden iterative Usability-Tests durchge-
führt. Dabei ist das Ziel des Usability-Tests Entwurfsoptimierungen des elektroni-
schen Prototyps mit Hilfe von echten Benutzern zu generieren. Da der UI-Entwurf
des BPMS evaluiert werden soll, findet anstelle des iterativen Usability-Tests ein
Expertentest statt. In der Phase Evaluationen und Tests findet die eigentliche Eva-
luation mit Endbenutzern statt. Dadurch kann der UI-Entwurf des BPMS evaluiert
werden, da ein Großteil der Style-Guides im visuellen Design bereits umgesetzt ist
und so realitätsnahe Aufgaben generiert werden können [12]
UI-Style-Guide
Das UI-Style-Guide enthält die Gestaltungsregeln für den UI-Entwurf und sorgt für
eine einheitliche und konsistente Gestaltung aller Dialoge. Dabei werden system-
spezifische Style-Guide-Regeln aufgezeigt, wie z.B. Prozessinstanzen, welche in den
Farben Grün, Orange und Rot angezeigt werden sollen.
Detailentwurf
In dieser Phase liegt der UI-Entwurf im Detail vor, das Interaktionsdesign ist detail-
liert ausgearbeitet und liegt als Style-Guide für die Implementierung bereit [29].
Fehlende Details des UI-Entwurfs, welche im UI-Style-Guide nicht berücksichtigt
wurden, werden im Detailentwurf ergänzt.
EVALUATIONEN UND TESTS
In dieser Phase setzen die UI-Entwickler das BPMS an Hand den festgelegten Style-
Guides um [30, 31, 32]. Währenddessen findet durch ein Usability-Test eine weitere
3.2 Evaluationen und Tests
37
Evaluation statt. Resultierend daraus können Entwurfsoptimierungen generiert
werden [13].
Usability-Test
Mit Hilfe des Usability-Tests werden Entwurfsentscheidungen des BPMS befürwor-
tet oder verworfen. Der Ansatz in dieser Arbeit ist es, einen Usability-Test möglichst
realitätstreu an Hand von Szenarien umzusetzen. Der Usability-Test findet gegen
Ende der Software-Entwicklung statt, in der überprüft wird, ob die festgelegten
Usability-Ziele erreicht sind. Aus diesem Grund findet erst nach Fertigstellung des
UI-Style-Guides und des Detailenentwurfs die eigentliche Evaluation mit „echten“
Benutzern statt.
Für den Usability-Test wird ein sogenannter Click-Prototyp eingesetzt, weil der
funktionale Prototyp noch nicht ausgereift genug ist, um ihn für den Usability-Test
nutzen zu können. Bei dem Click-Prototypen handelt es sich um Screenshots des
UI-Entwurfs, welche mit der Plattform inVision miteinander verlinkt werden. InVi-
sion stellt dabei eine Plattform dar, welche für Prototypen, Kollaborationen und
Workflows genutzt werden können [33]. Mit Hilfe eines Click-Prototyps wird eine
vorgegebene Interaktion mit dem BPMS durch ein kontrolliertes Szenario realisiert.
Dadurch erhalten die Benutzer einen Einblick in die Funktionalität, das Interakti-
onsdesign, sowie dem visuellen Design. Allerdings handelt es sich hierbei, um einen
reinen „dummen“ UI-Prototypen. Er kann zwar von den Benutzern bedient werden,
aber es ist keine darunter liegende Systemfunktionalität implementiert.
Entwurfsoptimierung
Nach Abschluss des Usability-Tests, werden Gestaltungsänderungen vorgenom-
men. Diese werden in das Ergebnis des UI-Entwurfs eingebunden.
Unterstützung der Entwicklung
Während der Entwicklung wird der UI-Entwurf regelmäßig auf Konsistenz über-
prüft, da ansonsten die Gefahr besteht, dass Teile des Dialogs unterschiedlich im-
plementiert werden.
3 Wissenschaftliche Methodik
38
39
4 ANFORDERUNGSANALYSE
In diesem Kapitel werden die Anforderungen an das BPMS bestimmt. Dabei werden
die Arbeitsaufgaben und Bedürfnisse der späteren Benutzer erhoben und definiert
[8]. Generell können Anforderungen in funktionale und nicht-funktionale Anforde-
rungen unterteilt werden. Unter funktionalen Anforderungen wird verstanden, was
das BPMS können muss, wie z.B. das Ausführen eines Prozessmodells. Während
nicht-funktionale Anforderungen definieren, in welcher Qualität die funktionalen
Anforderungen umgesetzt werden müssen, wie z.B. ein einfaches Korrigieren an
Hand weniger Klicks. Die Anforderungen an das BPMS werden in diesem Kapitel im
Detail beschrieben (siehe Abbildung 15).
ABBILDUNG 15: ANFORDERUNGSANALYSE
In Kapitel 4.1 werden die Geschäfts- und Einsatzziele des BPMS kurz beschrieben.
Die Analyse von zwei Konkurrenzsystemen erfolgt in Kapitel 4.2 die Analyse Ist-
Stand und Kapitel 4.3 beinhaltet die Benutzerprofilanalyse. In Kapitel 4.4 werden
4 Anforderungsanalyse
40
die Arbeitsaufgaben der Benutzer an Hand von Use Cases beschrieben. Diese Use
Cases beschreiben funktionalen Anforderungen, welche durch nicht funktionale
Anforderungen ergänzt werden. Use Cases stellen eine Sequenz von Interaktionen
dar, in welcher Anforderungen, zwischen dem Benutzer und dem BPMS stattfinden.
Jeder Use Case stellt dabei eine Handlung dar. Dieser liefert ein sichtbares Resultat
wie z.B. das Hinzufügen einer Aktivität zu einem Prozessmodell. Mittels Use Case-
Diagramme wird zusätzlich auf einer einfachen und übersichtlichen Weise aufge-
zeigt, was das BPMS leisten muss. Dabei werden Use Cases in Beziehung gestellt
und einige wichtige Funktionen aufgezeigt, welche der Benutzer ausführen. Zudem
wird in Kapitel 4.5 die Umgebungsbedingungen des BPMS aufgezeigt, sowie in Ka-
pitel 4.6 Hardware- und Software-Randbedingungen bestimmt. Abschließend sind
in Kapitel 4.7 und 4.8 die generellen Entwurfsprinzipien aufgezeigt und die Usabi-
lity-Ziele des BPMS erläutert.
GESCHÄFTS- UND EINSATZZIELE
Die Vorgabe ist, ein „leichtgewichtiges“ BPMS zu entwickeln. Dabei ist es wichtig
nur Funktionalitäten für den Benutzer darzustellen, welche im Kontext auch benö-
tigt werden. Eine wesentliche Aufgabe stellt dar, die Funktionalität des BPMS für
den Benutzer zu minimieren. Durch ein schlichtes, visuelles Design des BPMS soll
dies zudem gestützt werden (siehe Kapitel 2.4.3). Daraus ergibt sich die erste An-
forderung an das BPMS (siehe Anforderung ANF-1).
Anforderung ANF-1 („leichtgewichtiges“ BPMS)
Ein leichtgewichtiges BPMS muss durch die Reduzierung der Funktionalität auf
das Wesentliche erreicht werden. Des Weiteren muss dies durch ein schlichtes,
konsistentes, visuelles Design gefestigt.
ANALYSE IST-STAND
Im Folgenden werden zwei BPMSs vorgestellt, welche analog zum entwickelnden
BPMS als Cloud-Platform betrieben werden. Dabei werden negative, als auch posi-
tive Aspekte des Interaktionsdesign im Analyse Ist-Stand aufgezeigt.
4.2 Analyse Ist-Stand
41
EFFEKTIF
Effektif ist ein BPMS, welches als Cloud-Platform betrieben wird. Das Einsatzgebiet
stellt die Abteilungsebene dar, um administrative Geschäftsprozesse zu unterstüt-
zen [34]. Effektif zielt dabei auf den Einsatz in Abteilungsebene. Daher steht es auch
nicht in Konkurrenz zu großen BPMSs. Das Bedienkonzept hat den Anspruch einen
schnellen Einstieg in Effektif zu geben. Ohne technische Vorkenntnisse soll der Be-
nutzer möglichst einfach ein Prozessmodell erstellen können. Abbildung 16 zeigt
die Startansicht, in der sich der Aufgabenbereich des Benutzers befindet.
ABBILDUNG 16: AUFGABENBEREICH VON EFFEKTIF
Aufgaben des Benutzers werden dabei in Tasks unterteilt, welche nach Erledigung
abgehakt werden können. Des Weiteren können Tasks durch Beschreibungen oder
Internet-Links angereichert werden, welche zu anderen Benutzern zugewiesen wer-
den können. Mittels Kommentaren ist es möglich über eine Aufgabe zu diskutieren.
Die Abwicklung einfacher Geschäftsprozesse kann durch Prozess-Schablonen rea-
lisiert werden, welche wiederum aus Tasks bestehen. Dieser Geschäftsprozess kann
beliebig oft gestartet werden. Dialoge mit Textfeldern, Drop-down-Listen etc. kann
zudem für jeden Task definiert werden. Neben Benutzer-Tasks werden auch Skript-
4 Anforderungsanalyse
42
Tasks angeboten, um eine Systemlogik in JavaScript zu hinterlegen. Für komplexe
Aufgaben können Tasks in die BPMN überführt werden (siehe Abbildung 17).
ABBILDUNG 17: GESCHÄFTSPROZESSE BEARBEITEN IN EFFEKTIF
Effektif steht noch am Anfang der Entwicklung und soll durch weitere Funktionali-
täten wie Administrations- und Analysefunktionen, Anbindung von Directory Ser-
vern, Integration von Drittsystemen angereichert werden.
RAVENCLOUD
Prozessmodelle im Cloud-Service Ravencloud können ausschließlich über eine tex-
tuelle Sprache beschrieben werden [34]. Aus dieser textuellen Sprache wird an-
schließend automatisch ein grafisches Prozessmodell generiert. Die Darstellung ist
dabei an die BPMN-Darstellung angelehnt. Einzelne BPMN-Elemente oder ein gan-
zes BPMN-Prozessmodell sind aber nicht selbst modellierbar, d.h. es können nicht
einzelne Prozesselemente auf das Prozessmodell gezogen werden.
Generell werden wenige Möglichkeiten angeboten das Prozessmodell nachträglich
zu bearbeiten. Zudem wird das Prozessmodell selbst nicht gespeichert, sondern
4.2 Analyse Ist-Stand
43
nur der Text, welcher das Prozessmodell beschreibt. Nachträgliche Überarbeitun-
gen werden folglich also nicht gespeichert und müssen beim erneuten Öffnen wie-
der editiert werden. Da Konventionen bei der Formulierung der Sprache bestehen,
erfordert Ravencloud vor der Nutzung zusätzliche Einarbeitungszeit. Die Idee mit-
tels Texteingabe zu arbeiten, erweist sich dennoch als sinnvoll, da das Tippen von
Text schneller erfolgt als grafisches Modellieren. Dennoch besitzt der Cloud-Service
kaum Freiheiten in der Bedienung. Das visuelle Design von Ravencloud ist reduziert
gestaltet, dies stellt aber keine große Herausforderung dar, da außer der Generie-
rung eines Prozessmodells keine weiteren Funktionalitäten vorhanden sind. So ver-
fügt Ravencloud über keine Prozessausführung. Abbildung 18 zeigt das Interface
von Ravencloud.
ABBILDUNG 18: RAVENCLOUD
Aus der Analyse, der in diesem Kapitel beschriebenen Konkurrenzsysteme ergibt
sich Anforderung ANF-2.
Anforderung ANF-2 (Prozessmodellierung mit Prozessausführung)
Die Prozessmodellierung muss mit der Prozessausführung in einem zentralen
System zusammengeführt werden, um einen Kontextwechsel zu vermeiden.
4 Anforderungsanalyse
44
BENUTZERPROFILANALYSE
Bei der Benutzerprofilanalyse werden die Eigenschaften der Benutzer untersucht.
Das BPMS richtet sich an Benutzer, welche administrative Aufgaben erledigen. Da-
bei muss es sich nicht um einen Expertenarbeitsplatz handeln, da auch Benutzer
ohne Vorkenntnisse das BPMS später bedienen sollen. Daher soll das BPMS beson-
ders einfach und selbsterklärend gestaltet werden, um Benutzer beim Einstieg nicht
zu überfordern. Auch die Unterteilung in erfahrene und unerfahrene Benutzer, so-
wie sporadische bzw. ständige Nutzung des BPMS kann nicht festgelegt werden.
Sowohl Benutzer ohne Vorkenntnisse, welche eher sporadisch das BPMS nutzen,
sowie der computeraffine Experte sind daher als zukünftige Benutzer mit einge-
schlossen (siehe Anforderung ANF-3).
Anforderung ANF-3 (Erfahrene und unerfahrene Benutzer)
Durch ein intuitives, leichtes Bedienkonzept, muss das BPMS sowohl für Laien
ohne Vorwissen als auch für Experten gleichermaßen ausgelegt sein.
AUFGABENANALYSE
In der Aufgabenanalyse werden alle Aufgaben, welche der Benutzer mit Hilfe des
BPMS zu erledigen hat, erfasst und strukturiert. Dabei werden zunächst die Haupt-
aufgaben der Benutzer bestimmt. Die Zerlegung der Anforderungen in Arbeitspa-
kete stellt die Basis für eine schrittweise Entwicklung des UI-Entwurfs dar [13] . Die
Ergebnisse der Aufgabenanalyse werden im Detail eingeführt.
Anmeldung
Das Anmelden erfolgt dabei generell über die E-Mail-Adresse und ein Passwort. Ist
noch kein Account angelegt, muss neben der E-Mail-Adresse und dem Passwort,
der Name des Benutzers eingegeben werden (siehe Abbildung 19). Die Anmeldung
an das BPMS soll persönlich gestaltet sein. Daher muss ein Profilbild bei Anmel-
dung an das BPMS wiedergegeben werden (siehe Anforderung ANF-4).
4.4 Aufgabenanalyse
45
Anforderung ANF-4 (Anmeldung)
Die Anmeldung muss generell über E-Mail-Adresse und Passwort erfolgen.
Wird ein Account angelegt, muss zusätzlich noch der Name des Benutzers ab-
gefragt werden. Ein Profilbild gestaltet die Anmeldung persönlicher.
ABBILDUNG 19: ANMELDUNG
Der in Abbildung 19 vorgestellte Use Case UC-2 (Anmelden) ist in Tabelle 11 detail-
lierter beschreiben.
Begriff
Beschreibung
Akteur
Benutzer
Vorbedingung
Keine
Auslöser
Der Benutzer meldet sich am BPMS an.
Normaler Ablauf
1. Der Benutzer gibt seine E-Mail-Adresse und Passwort in
die entsprechende Formularfelder ein.
2. Der Benutzer bestätigt seine Eingaben.
Alternativer
Ablauf
Der Benutzer hat noch keinen Account angelegt.
1. Der Benutzer gibt Name, E-Mail-Adresse und Passwort
in die entsprechende Formularfelder ein.
2. Der Benutzer bestätigt seine Eingaben.
UC-1 (Account erstellen)
UC-2 (Anmelden)
«system»
Anmeldung
4 Anforderungsanalyse
46
Nachbedingung
Erfolg
Das BPMS zeigt die Prozessmodellübersicht an.
Nachbedingung
Fehler
Das BPMS zeigt nicht die Prozessmodellübersicht an.
Fehlerablauf
Das BPMS zeigt eine Fehlermeldung an.
TABELLE 11: USE CASE UC-2 (ANMELDEN)
Prozessmodellübersicht
Auf der Prozessmodellübersicht müssen dem Benutzer alle existierenden Prozess-
modelle zur Verfügung gestellt werden, um schnelle Einstiegspunkte in das BPMS
sicherzustellen. Um einen besseren Überblick über alle Prozessmodelle zu ermög-
lichen, sollten diese sinnvoll gruppiert werden. Eine Gruppierung enthält dabei Pro-
zessmodelle, sowie Dashboards oder Tabellen mit Laufzeitinformationen. Zudem
muss die Prozessmodellübersicht so visualisiert und dargestellt werden, wie sie der
Benutzer bereits aus anderen Anwendungen wie z.B. den Explorer unter Windows
kennt. Dies fördert eine gute Orientierung im BPMS. Ein gutes Beispiel stellt das
Windows 8-style UI von Microsoft (siehe Abbildung 11) dar, welches alle Apps als
Kacheldesign auf einer Startseite darstellt. Weiter müssen Filtermöglichkeiten vor-
handen sein, um die Komplexität der Prozessmodellübersicht minimieren zu kön-
nen.
Des Weiteren sollten Editierungsmöglichkeiten und die Ausführung von Prozess-
modellen an Hand weniger Klicks bereits auf der Prozessmodellübersicht möglich
gemacht werden (siehe Anforderung ANF-5). Dazu gehört das Erstellen, Löschen,
Kopieren, Teilen sowie das Editieren von Eigenschaften eines oder mehrerer Pro-
zessmodelle (siehe Abbildung 20).
Anforderung ANF-5 (Prozessmodellübersicht)
Auf der Startseite des BPMS muss ein Überblick aller existierenden Prozess-
modelle gegeben sein. Eine sinnvolle Gruppierung wie z.B. durch Ordner und
Filtermöglichkeiten für eine schnelle Suche müssen auf der Startseite bereit-
gestellt werden. Des Weiteren müssen die Eigenschaften von Prozessen be-
reits auf der Startseite editierbar sein.
4.4 Aufgabenanalyse
47
ABBILDUNG 20: PROZESSMODELLÜBERSICHT
Durch diese alternativen Bedienungsmöglichkeiten ist eine schnellere Bedienung
im BPMS gewährleistet (siehe Kapitel 2.4.3).
Der in Abbildung 20 vorgestellte Use Cases UC-9 (Prozessmodell öffnen) und UC-
10 (neues Prozessmodell erstellen) sind in Tabelle 12 und Tabelle 13 detaillierter
beschrieben.
Begriff
Beschreibung
Akteur
Benutzer
Vorbedingung
Erfolgreiches Anmelden an das BPMS.
Auslöser
Der Benutzer wählt ein Prozessmodell aus.
Normaler Ablauf
1. Auswahl einer Gruppierung von Prozessmodellen.
2. Auswahl eines Prozessmodells .
Alternativer
Ablauf
Keiner
UC-3 (Ein oder mehrere
Prozessmodelle editieren)
UC-8 (Prozessmodell
ausführen)
«system»
Prozessmodellübersicht
UC-9 (Prozessmodell
öffnen)
UC-4 (Prozessmodell
löschen)
«includes»
UC-5 (Prozessmodelll
kopieren)
UC-6 (Prozessmodell
teilen)
UC-7 (Eigenschaf-
ten editieren)
«includes»
«includes»
«includes»
UC-10 (Neues Prozess-
modell erstellen)
4 Anforderungsanalyse
48
Nachbedingung
Erfolg
Das Prozessmodell wird in der Prozessmodellübersicht
angezeigt.
Nachbedingung
Fehler
Keiner
Fehlerablauf
Keiner
TABELLE 12: USE CASE UC-9 (PROZESSMODELL ÖFFNEN)
Begriff
Beschreibung
Akteur
Benutzer
Vorbedingung
Auswahl eines Prozessmodells.
Auslöser
Der Benutzer erstellt ein neues Prozessmodell.
Normaler Ablauf
1. Der Benutzer wählt die Funktion Neues
Prozessmodell erstellen aus.
2. Der Benutzer vergibt einen Name für das
Prozessmodell und bestätigt die Texteingabe.
3. Das BPMS zeigt das neu erstellte Prozessmodell in der
Prozessmodellübersicht an.
Alternativer
Ablauf
Es wird ein Prozessmodell aus dem Store gekauft.
1. Der Benutzer wählt die Funktion Neues Prozessmodell
erstellen aus.
2. Der Benutzer kauft einen vorgefertigtes Prozessmodell
aus dem Store.
3. Das BPMs zeigt das neu gekaufte Prozessmodell
in der Prozessmodellübersicht an.
Nachbedingung
Erfolg
Das Prozessmodell wird in der Prozessmodellübersicht
angezeigt.
Nachbedingung
Fehler
Ungültiger Name für Prozessmodell vergeben.
Fehlerablauf
Die Texteingabe wird vom Benutzer abgebrochen.
TABELLE 13: USE CASE UC-10 (NEUES PROZESSMODELL ERSTELLEN)
Generell werden Prozessmodelle im BPMS in der BPMN angezeigt. Ein Grund dafür
ist, dass sich die BPMN als Prozessbeschreibungssprache im BPM durchgesetzt hat
(siehe Kapitel 2.4.2).
4.4 Aufgabenanalyse
49
Prozessmodelldarstellung
Ein Prozessmodell kann sehr komplex sein, was sich durch die qualitative als auch
durch die quantitative Komplexität äußern kann [35]. Daher muss neben der BPMN
noch eine zweite Prozessmodelldarstellung angeboten werden, welche die quanti-
tative Komplexität von Prozessmodellen reduziert, um auch nicht BPMN-affine Be-
nutzer anzusprechen (siehe Kapitel 2.4.3). An Hand von Control-Elements sollte die
Darstellung des Prozessmodells individuell nach den Bedürfnissen des Benutzers
anpassbar sein (siehe Kapitel 2.4.2). Dabei sollen folgende Control-Elements im
BPMS eingesetzt werden (siehe Tabelle 14).
Control-Elements
Beschreibung
Zooming
Durch das Zooming kann der Benutzer die Wunschgröße
des Prozessmodells selbst festlegen. Dabei kann die Ansicht
des Prozessmodells verkleinert oder vergrößert dargestellt
werden.
Fit-to-Page
Das Prozessmodell wird an der Seitengröße des Content-
Bereichs, in welcher das Prozessmodell dargestellt wird, so
ausgerichtet, dass alle Bereiche des Prozessmodells kom-
plett für den Benutzer sichtbar sind.
Navigation
Um an eine relevante Stelle im Prozessmodell schnell sprin-
gen zu können, muss dem Benutzer eine schnellere Naviga-
tionsmöglichkeit gegeben sein (siehe Kapitel 2.4.3).
Dadurch muss der Benutzer nicht aufwendig durch das Pro-
zessmodell scrollen, um einen bestimmten Bereich errei-
chen zu können.
TABELLE 14: CONTROL-ELEMENTS
Prozessmodellfilter
Für alle Benutzer sind nicht alle Prozesselemente gleich relevant, da der Benutzer
beispielsweise nur Prozesselemente sehen möchte, in die er involviert ist. Daher
müssen vordefinierte Prozessmodellfilter im BPMS bereitgestellt werden, welche die
quantitative Komplexität von Prozessmodellen reduziert (siehe Kapitel 2.4.2). Dem
Benutzer wird so die Möglichkeit gegeben, nach verschiedenen Kriterien das Pro-
4 Anforderungsanalyse
50
zessmodell zu filtern, wie z.B. das Filtern nach technischen Schritten. Dadurch wer-
den die Bedürfnisse der Endnutzer individuell berücksichtigt, da alle automatisier-
ten Prozesselemente gefiltert werden können, wie z.B. Datenbankzugriffe. Ist ein
Filter gesetzt, wird das Prozessmodell verändert angezeigt. Dadurch kann der Be-
nutzer das Prozessmodell auf seinen Arbeitskontext zuschneiden. Daraus ergibt
sich zusammenfassend folgende Anforderung (siehe Anforderung ANF-6).
Anforderung ANF-6 (Prozessmodellvisualisierung)
Die Darstellung des Prozessmodells muss durch geeignete Prozessmodellfilter
abstrahiert und einer weiteren, einfacheren Darstellungsart geändert werden
können. Zudem muss die Darstellung des Prozessmodells durch Control-Ele-
ments gegeben sein.
ABBILDUNG 21: PROZESSMODELLVISUALISIERUNG
UC-11 (Visualisierungs-
Controlls anwenden)
UC-15 (Prozessfilter
anwenden)
«system»
Prozessmodellvisualisierung
UC-16 (Prozessdarstel-
lung ändern)
UC-12 (Zooming)
«includes»
UC-13 (Fit-to-Page)
UC-14 (Navigation)
UC-18 (Alternative
Darstellungsart)
«includes»
«includes»
«includes»
UC-17 (BPMN)
«includes»
4.4 Aufgabenanalyse
51
Abbildung 21 gibt einen Überblick über Use Cases im Kontext der Prozessmodell-
visualisierung. Der in Abbildung 21 vorgestellte Use Case UC-18 (Alternative Dar-
stellungsart) ist in Tabelle 15 detaillierter beschreiben.
Begriff
Beschreibung
Akteur
Benutzer
Vorbedingung
Das Prozessmodell wird in BPMN angezeigt.
Auslöser
Der Benutzer wählt die Funktion Umschalten auf die
Prozessmodelldarstellung aus.
Normaler Ablauf
1. Das BPMS stellt das Prozessmodell in BPMN dar.
2. Der Benutzer wählt die Funktion Umschalten auf die
Prozessmodelldarstellung aus.
3. Das BPMS stellt das Prozessmodell in anderen
Prozessmodelldarstellung dar.
Alternativer
Ablauf
Keiner
Nachbedingung
Erfolg
Das Prozessmodell wird in anderen Prozessmodell-
darstellung dargestellt.
Nachbedingung
Fehler
Keiner
Fehlerablauf
Keiner
TABELLE 15: USE CASE UC-18 (ZWEITE DARSTELLUNGSART)
Prozessmodellierung
Unspezifische Prozesselemente stellen dabei die Kernelemente des Prozessmodells
dar und müssen daher in der Prozessmodellierung aufgeführt sein (siehe Abbil-
dung 22). Zu den vorkonfigurierten Prozesselementen gehören beispielsweise eine
Mailing-oder Dateiablage auf Dropbox. Unspezifische Prozesselemente beinhalten
dabei nicht vorkonfigurierte Prozesselemente. Dazu gehören: Aktivität, XOR-Gate-
way, AND-Gateway, ein leerer Zweig und eine Schleife. Daraus ergibt sich folgende
Anforderung für die Prozessmodellierung (siehe Anforderung ANF-7).
4 Anforderungsanalyse
52
Anforderung ANF-7 (Prozessmodellierung)
Für die Prozessmodellierung muss eine Liste von unspezifischen und vorkon-
figurierten Prozesselementen bereitgestellt werden. Zudem müssen Prozes-
selemente einfach aus dem Prozessmodell wieder entfernt werden können.
ABBILDUNG 22: PROZESSMODELLIERUNG
Der in Abbildung 22 vorgestellte Use Case UC-19 (Prozesselemente einfügen) ist in
Tabelle 16 detaillierter beschrieben, in der in das Prozessmodell eine Aktivität ein-
gefügt wird.
Begriff
Beschreibung
Akteur
Benutzer
Vorbedingung
Auswahl eines Prozessmodells
Auslöser
Der Benutzer wählt die Funktion Prozesselemente einfügen
aus.
Normaler Ablauf
1. Das BPMS stellt eine Liste von unspezifischen und
spezifischen Prozesselementen bereit.
2. Der Benutzer wählt aus der Liste von unspezifischen
Prozesselementen eine Aktivität aus.
3. Im Prozessmodell wird die Aktivität dargestellt.
Alternativer
Ablauf
Keiner
UC-19 (Prozesselemente
einfügen)
UC-22 (Prozessele-
mente löschen)
«system»
Prozessmodellierung
UC-20 (Unspezifische
Prozesselemente)
«includes»
UC-21 (Vorkonfigurierte
Prozesselemente)
«includes»
4.4 Aufgabenanalyse
53
Nachbedingung
Erfolg
Das Prozessmodell wird mit einer neuen Aktivität
angezeigt.
Nachbedingung
Fehler
Es wurde das falsche Prozesselement ausgewählt.
Fehlerablauf
Der Benutzer entfernt das Prozesselement aus dem Prozess-
modell.
TABELLE 16: USE CASE UC-19 (AKTIVITÄT EINFÜGEN)
Um Prozessmodelle klassifizieren und charakterisieren zu können, werden folgende
Eigenschaften eines Prozessmodells gespeichert.
Prozessmodellbeschreibung
Eine Prozessmodellbeschreibung ermöglicht eine genauere Erläuterung des Pro-
zessmodells, da allein die Vergabe des Prozessnamens nicht ausreichend ist. Diese
kann vom Benutzer hinterlegt werden.
Vorschauanzeige
Neben der textuellen Spezifikation durch den Prozessmodellnamen sollte ein Pro-
zessmodell sich auch visuell durch eine Vorschauanzeige von den anderen Prozess-
modellen differenzieren können. Daher müssen Prozessmodelle in der Prozessmo-
dellübersicht neben deren Name, auch durch einen Bildausschnitt des Prozessmo-
dells präsentiert werden. Dadurch wird der Wiedererkennungswert erhöht und zu-
gleich der Gedächtnisspeicher des Benutzers entlastet (siehe Kapitel 2.4.3). Eine al-
ternative Vorschauanzeige stellen Icons dar, welche für das Prozessmodell hinter-
legt werden können.
Anhänge
Auch Anhänge (engl.: Attachments), wie beispielsweise Textdokumente und For-
mulare, welche im Kontext des Prozessmodells benötigt werden, müssen angefügt
werden können.
Benutzerrechte
Die Vergabe von Benutzerrechten (engl.: Access Rights) für ein Prozessmodell ist
essentiell, da dadurch ein Rollenkonzept realisiert werden kann, in welcher nur aus-
4 Anforderungsanalyse
54
gewählte Benutzer auf Prozessmodelle zugreifen können. Für das BPMS muss da-
her ein vollständiges Berechtigungskonzept vorliegen. Beispielsweise kann der Ab-
teilungsleiter alle Prozessmodelle der Mitarbeiter sehen; der Mitarbeiter jedoch nur
seine zugehörigen Prozessmodelle (siehe Tabelle 17).
Benutzerrechte
Beschreibung
Ansicht
(engl.: View)
Der Benutzer hat nur Rechte zur Ansicht des
Prozessmodells und keine Editier- und Ausführungsrechte.
Editieren
(engl.: Edit)
Neben dem Recht zur Ansicht kann der Benutzer das
Prozessmodell auch bearbeiten.
Ausführen
(engl.: Run)
Hierbei verfügt der Benutzer über drei Rechte. Neben dem
Ansichts- und Editier-Recht, hat er auch das Recht einen
Prozessmodell auszuführen.
TABELLE 17: ABSTUFUNG DER BENUTZERRECHTE
Daraus ergibt sich Anforderung ANF-8 für die Editierung von Prozessmodellen.
Anforderung ANF-8 (Prozessmodelleditierung)
Eigenschaften von Prozessmodellen müssen aus einem Prozessmodellname,
einer Prozessmodellbeschreibung, ein Icon für die Vorschauanzeige, Anhän-
gen und Benutzerrechten bestehen. Benutzerrechte werden dabei in Ansicht,
Editieren und Ausführen unterteilt.
Prozesselemente editieren
Neben der Festlegung von Eigenschaften, welche das Prozessmodell als Ganzes
beschreibt, sollten auch Eigenschaften einzelner Prozesselementen bestimmbar
sein. Dazu gehört neben dem Namen des Prozesselements (engl.: Label) und dem
Prozesselementtyp, eine Prozesselementbeschreibung, sowie das Hinterlegen von
Daten und Anhängen, welche z.B. eine Arbeits- oder Prozesselementbeschreibung
sein kann. Auch Formulare, welche der Benutzer noch nicht automatisiert hat, aber
für die Ausführung gebraucht werden, müssen hinterlegbar sein (siehe Anforde-
rung ANF-9). Des Weiteren muss auch die Vergabe von Benutzerrechten für eine
4.4 Aufgabenanalyse
55
einzelne Aktivität gewährleistet sein. Benutzer, welche für die Erledigung einer be-
stimmten Aktivität zuständig sind, werden im BPMS als Assigned Users bezeichnet.
Anforderung ANF-9 (Prozesselemente editieren)
Eigenschaften einzelner Prozesselemente müssen neben dem Namen, dem
auch eine Beschreibung besitzen. Hinterlegte Daten und der Aktivitätstyp
müssen zusätzlich in der Aktivität aufgeführt sein. Zudem müssen Anhänge
und Benutzerrechte für eine Aktivität hinterlegbar sein.
Assigned Users können das Benutzerrecht zum Editieren und Ausführen beinhal-
ten. Ist der Personalabteilung beispielsweise das Benutzerrecht zugewiesen wor-
den, so liegt es in ihrem Zuständigkeitsbereich die zugewiesene Aktivität zu erledi-
gen. Zudem müssen generelle Prozesselement gelöscht werden können.
ABBILDUNG 23: PROZESSMODELLEDITIERUNG
UC-23 (Prozessmodell-
beschreibung editieren)
UC-24 (Icon hinzufügen)
«system»
Prozessmodelleditierung
UC-26 (Benutzerrechte
vergeben)
UC-27 (Ansicht)
UC-28 (Editieren)
UC-29 (Ausführen)
«includes»
«includes»
«includes»
UC-25 (Anhänge einfügen)
UC-30 (Prozesselemente
editieren)
4 Anforderungsanalyse
56
Hinterlegte Daten, welche als Outputs und Inputs gruppiert werden, müssen
ebenso löschbar sein. In Abbildung 23 ist ein Überblick zu allen Funktionalitäten
der Editierung von Prozesselemente gegeben.
Der in Abbildung 23 vorgestellte Use Case UC-28 (Editieren), ist in Tabelle 18 de-
taillierter beschreiben.
Begriff
Beschreibung
Akteur
Benutzer
Vorbedingung
Benutzer darf anderen Benutzern Editierrechte zuweisen.
Auslöser
Der Benutzer wählt die Funktion Benutzerrechte hinzufügen
aus.
Normaler Ablauf
1. Das BPMS stellt eine Liste von allen Benutzern zur
Verfügung.
2. Der Benutzer wählt aus der Liste von Benutzern einen
aus und fügt diesen hinzu.
3. Dem Benutzer werden Editierrechte vergeben.
4. Das BPMS zeigt die Editierrechte des Benutzers an.
Alternativer
Ablauf
Benutzer hat bereits Benutzerrechte.
1. Editierrechte werden dem Benutzer vergeben.
2. Das BPMS zeigt Editierrechte des Benutzers an.
Nachbedingung
Erfolg
Der ausgewählte Benutzer hat Editierrechte.
Nachbedingung
Fehler
Keiner
Fehlerablauf
Keiner
TABELLE 18: USE CASE UC-28 (EDITIEREN)
Prozessausführung
Bei der Prozessausführung muss dem Benutzer ein Überblick bereits existierender
Instanzen, d.h. laufender und abgeschlossener Instanzen, gegeben werden. Neben
dem Prozessmodell- und Instanzname, muss auch der Fortschritt des Prozessmodells
angezeigt werden, d.h. „wie weit“ das Prozessmodell bereits ausgeführt wurde. Die
Anzeige des Fortschrittes gibt dem Benutzer Rückmeldung auf seinen Arbeitsfort-
schritt, was ihn bei der Erledigung seiner Aufgaben unterstützt (siehe Kapitel 2.3.3).
Weiter sollte zu jeder ausgeführten Aktivität der Name des Benutzers mit Datum
4.4 Aufgabenanalyse
57
dargestellt werden. Dies gibt Benutzern Rückschluss darauf, wann und von wem
ein Prozesselement ausgeführt wurde. Die essentiellste Zusatzinformation stellt das
Fertigstellungsdatum dar, d.h. bis wann eine Aktivität spätestens erledigt sein soll.
Ein zeitlicher Rahmen für die Aufgabenbewältigung muss zu jeder Instanz aufge-
führt sein (siehe Kapitel 2.3.3). Alle laufenden Instanzen müssen zu jedem Zeitpunkt
abbrechbar sein. Dem Benutzer muss zudem die Möglichkeit gegeben sein, eine
fehlerhafte Bedienung durch versehentlichen Start einer Prozessausführung korri-
gieren zu können (siehe Kapitel 2.4.3).
Neben dem Überblick über laufende und abgeschlossene Instanzen, muss das Er-
stellen einer neuen Instanz möglich sein. Da auch Prozessmodelle vorliegen kön-
nen, welche noch keine Programmierlogik besitzen, müssen diese ebenfalls aus-
führbar sein, um eine konsistente Bedienung für den Benutzer zu gewährleisten.
Folglich soll ein initiales Prozessmodell als eine Art Checkliste ausführbar sein.
Dadurch kann sich der Benutzer Feedback zum Fortschritt einholen. Auch Prozess-
modelle, welche bereits hinterlegte Datenelemente besitzen, müssen ausführbar
sein. Diese hinterlegten Datenelemente sind während der Ausführung für den Be-
nutzer editierbar, wie z.B. ein Formular mit Reisedaten, was vom Benutzer ausgefüllt
werden muss. Aktivitäten, welche nicht im Tätigkeitsbereich des Benutzers liegen,
müssen dem Benutzer kenntlich gemacht werden. Jede Aktivität muss Zusatzinfor-
mationen bei der Ausführung für den Benutzer bereitstellen. Auch hier muss zu
jeder ausgeführten Aktivität der Name des Benutzers und das Datum sichtbar ge-
macht werden.
Die Möglichkeit der Kommunikation zu einer Aktivität muss zudem gegeben sein,
um Bemerkungen, Anregungen oder auftretende Schwierigkeiten mit Benutzern
diskutieren zu können (siehe Kapitel 2.3.3). Zudem muss das Hinzufügen von An-
hängen gegeben sein. Daraus ergibt sich Anforderung ANF-10.
4 Anforderungsanalyse
58
Anforderung ANF-10 (Prozessausführung)
In der Prozessausführung müssen laufende und abgeschlossene Instanzen
dargestellt werden. Prozessmodell- und Instanznamen, sowie der Fortschritt
müssen aufgeführt sein. Generell müssen neue Instanzen erzeugbar und lau-
fende Instanzen abbrechbar sein. Abgeschlossene Aktivitäten werden mit Na-
men und Datum des Benutzers präsentiert, nicht abgeschlossene Aktivitäten
mit dem Fertigstellungsdatum. Eine Kommentarfunktion muss für einen sozi-
alen Austausch zwischen den Benutzern gegeben sein.
Abbildung 24 gibt einen Überblick über alle Funktionalitäten der Prozessausfüh-
rung, welche das BPMS erfüllen muss.
ABBILDUNG 24: PROZESSAUSFÜHRUNG
Der in Abbildung 24 vorgestellte Use Case UC-31 (Prozessmodell ausführen) ist in
Tabelle 19 detailliert dargestellt.
UC-31 (Prozessmodell
ausführen)
UC-34 (Instanz
abbrechen)
«system»
Prozessausführung
UC-36 (Prozesselemen-
teigenschaften anzeigen)
UC-32 (Neue In-
stanz erstellen)
«includes»
UC-35 (Prozessmodellei-
genschaften anzeigen)
UC-37 (Kommentar er-
stellen)
UC-33 (Bereits lau-
fende Instanz)
«includes»
4.4 Aufgabenanalyse
59
Begriff
Beschreibung
Akteur
Benutzer
Vorbedingung
Auswahl eines Prozessmodells
Auslöser
Der Benutzer wählt die Funktion Prozessmodell ausführen
aus.
Normaler Ablauf
1. Der Benutzer startet die Prozessausführung.
2. Das BPMS erzeugt eine neue Instanz aug Basis des
Prozessmodells.
Alternativer
Ablauf
Der Benutzer hat bereits Benutzerrechte.
Nachbedingung
Erfolg
Keiner
Nachbedingung
Fehler
Ausgeführte Instanz des Prozessmodells wird angezeigt.
Fehlerablauf
Der Benutzer stoppt die Prozessausführung.
1. Das BPMS bricht die Prozessausführung der Instanz ab
und ordnet diese bei den abgeschlossenen Instanzen
ein.
TABELLE 19: USE CASE UC-31 (PROZESSMODELL AUSFÜHREN)
Datenelemente
Datenelemente können im Prozessmodell sowohl als einfache Datentypen, als auch
aus komplexen Datentypen, sogenannte Datenobjekte hinterlegt werden. Daten-
elemente, welche im Prozessmodell bereits hinterlegt sind, müssen für den Benut-
zer sichtbar gemacht werden. Dadurch weiß der Benutzer, welche Datenelemente
bereits hinterlegt wurden (siehe Kapitel 2.4.3). Neben der Darstellung von bereits
verwendeten Datenelementen, müssen neue Datenelemente im Prozessmodell
hinterlegbar sein (siehe Abbildung 25). Datenelemente müssen sowohl geschrieben
als auch gelesen werden können. Zudem muss für das Anlegen von neuen Daten-
elementen ein Set von vordefinierten Datenelementen und Datenobjekte, bereit-
gestellt werden, wie z.B. Reisedaten für eine Reisekostenabrechnung. In die einzel-
nen Parameter eines Datenelements muss eingesehen werden können, um den Be-
4 Anforderungsanalyse
60
nutzer Feedback über den Inhalt des Datenelements zu geben. So beinhaltet bei-
spielsweise das Datenobjekts Reisedaten, neben dem Vor- und Nachname, den
Grund der Reise, den Zielort und eine Telefonnummer.
Anforderung ANF-11 (Datenelemente)
Eine Übersicht bereits hinterlegter Datenelemente muss für den Benutzer
sichtbar gemacht werden. Das Schreiben bzw. Lesen von Datenelementen
muss gegeben sein, sowie das Einsehen von Parametern in das Datenelement.
Abbildung 25 zeigt das Use Case-Diagramm mit Use Cases im Kontext von Daten-
elementen, in der eine Übersicht über alle Funktionalitäten gegeben wird.
ABBILDUNG 25: DATENELEMENTE
Der in Abbildung 25 vorgestellte UC40 Datenelement schreiben ist in Tabelle 20
detailliert ausgeführt.
UC-38 (Datenelement
hinzufügen)
UC-41 (Datenelement lö-
schen)
«system»
Datenelemente
UC-39 (Datenelement
lesen)
«includes»
UC-42 (Parameter von
Datenobjekt anzeigen)
UC-40 (Datenelement
schreiben)
«includes»
UC-43 (Hinterlegtes Da-
tenelement ansehen)
4.4 Aufgabenanalyse
61
Begriff
Beschreibung
Akteur
Benutzer
Vorbedingung
Auswahl eines Prozessmodells.
Auslöser
Der Benutzer wählt die Funktion Datenelement einfügen
aus.
Normaler Ablauf
1. Das BPMS stellt eine Liste von Datenelementen bereit.
2. Der Benutzer wählt ein Datenelement aus.
3. Das BPMS zeigt das Datenelement mit den bereits
hinterlegten Datenelementen an.
4. Das BPMS zeigt die Funktionalität Datenelement lesen
oder schreiben an.
4. Der Benutzer wählt die Funktion Datenelement
schreiben aus.
5. Das BPMS stellt das geschriebene Datenelement dar.
Alternativer
Ablauf
Keiner
Nachbedingung
Erfolg
Schreibendes Datenelement ist im Prozessmodell
hinterlegt.
Nachbedingung
Fehler
Falsches Datenelement zum Schreiben verwendet.
Fehlerablauf
Der Benutzer wählt die Funktion geschriebenes Datenele-
ment löschen aus.
1. Der Benutzer löscht das geschrieben Datenelement.
2. Das BPMS entfernt das geschriebene Datenelement aus
dem Prozessmodell.
TABELLE 20: USE CASE UC-40 (DATENELEMENT SCHREIBEN)
Store mit automatisierten Prozessmodellen
Die Möglichkeit bestimmte Prozessmodelle an Hand von vordefinierten Prozess-
modellen zu automatisieren, beschleunigt Arbeitsabläufe im BPMS. Daher muss im
BPMS ein Store vorhanden sein, in dem vorkonfigurierte Prozessmodelle gekauft
werden können (siehe Abbildung 26). Dabei sollten automatisierte Prozessmodelle
im Store analog zur Prozessmodellübersicht dargestellt, um eine konsistente Ge-
staltung des BPMS zu bewahren (siehe Kapitel 2.4.2). Dabei muss eine Bewertung
und Anzahl an Downloads zu den einzelnen Prozessmodellen vorliegen. Dadurch
4 Anforderungsanalyse
62
kann der Benutzer schnell erfassen, welche Prozessmodelle im Store eine gute Kos-
ten-Nutzen-Bilanz besitzen (siehe Abbildung 26). Zudem kann der Benutzer zum
Prozessmodell selbst eine Bewertung vornehmen. Die Möglichkeit, Kritik oder An-
regungen zu einem Prozessmodell zu verfassen, muss durch eine Kommentarfunk-
tion gegeben sein. Nach Kauf kann das automatisierte Prozessmodell genutzt und
nach den Bedürfnissen des Benutzers weiter bearbeiten werden. Daraus ergibt sich
Anforderung ANF-13.
Anforderung ANF-12 (Store)
Automatisierte Prozessmodelle müssen für den Benutzer in einem Store zu-
gänglich gemacht werden. Diese müssen an Hand von einer Bewertung, An-
zahl an Downloads und einer Kommentarfunktion selektierbar sein.
ABBILDUNG 26: STORE
Der in Tabelle 21 vorgestellte Use Case UC-44 (Prozessmodell kaufen) ist in Tabelle
21 detailliert beschrieben.
Begriff
Beschreibung
Akteur
Benutzer
Vorbedingung
Keine
Auslöser
Der Benutzer wählt die Funktion Prozessmodell aus Store
kaufen aus.
UC-44 (Prozessmodell
kaufen)
UC-45 (Prozessmodell
bewerten)
«system»
Store
UC-46 (Kommentar
erstellen)
4.4 Aufgabenanalyse
63
Normaler Ablauf
1. Das BPMS stellt vorkonfigurierte Prozessmodelle bereit.
2. Der Benutzer wählt ein Prozessmodell aus.
3. Der Benutzer bestätigt den Kauf des Prozessmodells.
4. Das BPMS zeigt das gekaufte Prozessmodell in der
Prozessmodellübersicht an.
Alternativer
Ablauf
Keiner
Nachbedingung
Erfolg
Gekaufter Prozessmodell wird zu den bereits bestehenden
Prozessmodellen hinzugefügt.
Nachbedingung
Fehler
Falsches Prozessmodell gekauft.
Fehlerablauf
Der Benutzer löscht das Prozessmodell aus dem BPMS
TABELLE 21: USE CASE UC-44 (PROZESSMODELL KAUFEN)
Timeline
Die Rückmeldung des Ausführungsfortschritts von Prozessmodellen ist wichtig für
den Benutzer (siehe Kapitel 2.3.3). Daher sollte der zeitliche Verlauf einer Instanz
eines Prozessmodells in einer Timeline präsentiert werden. Der Ablauf kann bei-
spielsweise den Kauf eines Prozessmodells, verschiedene Modellierungsänderun-
gen bis hin zu allen Instanzen enthalten. Die Historie des Prozessmodells muss da-
her in der Timeline des BPMS aufgezeigt werden (siehe Abbildung 27). Auch pro-
zessmodellübergreifende Vergleiche müssen zudem im BPMS enthalten sein. Da
die Darstellung von Historien sehr komplex sein kann, müssen bestimmte Filter an-
geboten werden, um die Anzahl an Informationen zu reduzieren. Dazu gehört bei-
spielsweise die Filterung nach laufenden bzw. abgeschlossenen Instanzen, aktivier-
ten bzw. nicht aktivierten Aktivitäten, sowie Benutzerrechten. Neben der Historie
müssen dem Benutzer auch Deadlines von Prozessmodelle angezeigt werden. Dies
stützt den Benutzer bei der Bearbeitung von seinen dringlichen Aufgaben, welche
zeitnah bearbeitet werden müssen. Ähnlich einer To-do-Liste ist dem Benutzer so
schnell ersichtlich, welche Prozessmodelle, welche Priorität haben. Daraus ergibt
sich die Anforderung ANF-13.
4 Anforderungsanalyse
64
Anforderung ANF-13 (Timeline)
Eine Historie für Prozessmodelle muss den zeitlichen Verlauf für den Benutzer
sichtbar machen. Durch Filtern muss die Anzeige der Historie reduzierbar sein.
Zudem müssen dem Benutzer Prozessmodelle, welche in naher Zukunft bear-
beitet werden sollten, gesondert angezeigt werden.
ABBILDUNG 27: TIMELINE
Der in Abbildung 27 vorgestellte Use Case UC-47 (Historie von Prozessmodell an-
sehen), ist in Tabelle 22 detaillierter beschreiben.
Begriff
Beschreibung
Akteur
Benutzer
Vorbedingung
Prozessmodell existiert im BPMS.
Auslöser
Der Benutzer wählt die Funktion Timeline anzeigen aus.
Normaler Ablauf
1. Der Das BPMS zeigt die Historie des Prozessmodells in der Ti-
meline an.
Alternativer
Ablauf
Keiner
Nachbedingung
Erfolg
Timeline mit Prozessmodell wird angezeigt.
UC-47 (Historie von Pro-
zessmodell ansehen)
UC-48 (Nach Eigenschaf-
ten von Prozessmodellen
filtern)
«system»
Timeline
4.4 Aufgabenanalyse
65
Nachbedingung
Fehler
Keiner
Fehlerablauf
Keiner
TABELLE 22: USE CASE UC-47 (HISTORIE VON PROZESSMODELLEN ANSEHEN)
Nachrichtensystem
Die Möglichkeit über Aufgaben und auftretende Schwierigkeiten zu diskutieren
und sich mit anderen Benutzern auszutauschen, ist bereits als Bestandteil in der
Bewertung von Arbeitstätigkeit in Kapitel 2.3.3 aufgeführt. Über ein Nachrichten-
system muss dem Benutzer die Möglichkeit gegeben sein, Informationen mit an-
deren Benutzern auszutauschen (siehe Abbildung 28). Dabei müssen Nachrichten
zu einem konkreten Prozessmodell oder allgemeine Nachrichten hinterlegbar sein,
wie z.B. die Änderung einer bestimmten Aktivität. Nachrichten müssen generell die
Diskussion unter den Mitarbeitern für die Editierung einzelner Aktivitäten unter-
stützen (siehe Abbildung 28). Dadurch kann die Arbeit effektiver und effizienter
gestaltet werden, in dem Diskussionen über ein komplettes Prozessmodell, sowie
Instanzen oder einzelne Aktivitäten möglich sind (siehe Anforderung ANF-14).
Anforderung ANF-14 (Nachrichtensystem)
Der soziale Austausch mit Hilfe von Nachrichten für Prozessmodelle, Prozess-
instanzen oder Aktivitäten muss gewährleistet sein.
Um den zeitlichen Rahmen dieser Arbeit nicht zu sprengen, wurde das Nachrich-
tensystem im UI-Entwurf nicht weiter verfolgt.
4 Anforderungsanalyse
66
ABBILDUNG 28: NACHRICHTENSYSTEM
Profileinstellung
Einstellungen zum Profil des Benutzers im BPMS müssen im BPMS editierbar sein.
Dazu gehören der Vorname, Nachname und die E-Mail-Adresse. Des Weiteren ist
auch die Änderung der verwendeten Landessprache im BPMS für den Benutzer ge-
geben. Auch das Profilbild des Benutzers muss man nachträglich ändern können
(siehe Abbildung 29). Durch das Bereitstellen einer Profileinstellung, kann der Be-
nutzer Einstellungen individuell nach seinen Gegebenheiten und Wünschen anpas-
sen (siehe Kapitel 2.4.2). Daraus ergibt sich Anforderung ANF-15.
Anforderung ANF-15 (Profileinstellung)
Einstellungen zum Benutzer müssen nachträglich editierbar sein. Dazu gehö-
ren der Vorname, Nachname, E-Mail-Adresse, die Landessprache sowie das
Profilbild.
UC-49 (Nachricht erstellen)
UC-53 Nachricht löschen
«system»
Nachrichtensystem
UC-50 (Für ein Pro-
zessmodell)
«includes»
UC-51(Für eine In-
stanz)
UC-52 (Für eine Aktivität)
«includes»
«includes»
4.4 Aufgabenanalyse
67
ABBILDUNG 29: PROFILEINSTELLUNG
Der in Abbildung 29 vorgestellte Use Case UC-57 (Profilbild hochladen) ist in Ta-
belle 23 detailliert beschrieben.
Begriff
Beschreibung
Akteur
Benutzer
Vorbedingung
Keine
Auslöser
Der Benutzer lädt sein Profilbild hoch.
Normaler Ablauf
1. Der 1. Benutzer wählt die Funktion Profilbild hochladen in
Profileinstellung aus.
2. Der Benutzer bestimmt ein Profilbild, welches hochgela-
den werden soll.
3. Der Benutzer bestätigt seine Auswahl.
Alternativer
Ablauf
Der Benutzer hat bereits ein Profilbild hochgeladen.
1. Der Benutzer wählt die Funktion Profilbild ändern aus.
2. Der Benutzer bestimmt ein Profilbild, welches hochgela-
UC-54 (Benutzername
editieren)
UC-55 (E-Mail-Adresse
editieren)
«system»
Profileinstellung
UC-56 (Landessprache
ändern)
UC-57 (Profilbild hochla-
den)
4 Anforderungsanalyse
68
den werden soll.
3. Der Benutzer bestätigt seine Auswahl.
Nachbedingung
Erfolg
Das BPMS zeigt das hochgeladene Profilbild an.
Nachbedingung
Fehler
Es wird kein hochgeladenes Profilbild angezeigt.
Fehlerablauf
Das Hochladen des Profilbildes schlägt fehl. Das BPMS
zeigt eine Fehlermeldung an.
TABELLE 23: USE CASE UC-57 (PROFILBILD HOCHLADEN)
UMGEBUNGSBEDINGUNGEN
Die Analyse der physikalischen Arbeitsumgebung des BPMS wird genauer unter-
sucht [13]. Beim BPMS beläuft sich die Arbeitsumgebung auf ein Büro oder ein
ähnliches Umfeld. D.h. Schutzmaßnahmen gegen Vandalismus oder ähnliches muss
nicht berücksichtigt werden. Generell müssen aber Arbeitsplätze, in der das BPMS
ausgeführt werden soll, spezielle Anforderungen erfüllen, wie z.B. die DIN 9241-
Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten definiert
[36]. Die Vorgabe eines hellen, freundlichen Arbeitsplatzes ist beispielsweise darin
aufgeführt. Folglich bietet es sich an das BPMS ebenfalls hell zu gestalten, um et-
waige Spiegelungen der Oberfläche entgegenzuwirken (siehe Anforderung ANF-
16).
Anforderung ANF-16 (Freundliches Design)
Das visuelle Design ist hell und freundlich zu gestalten. Ein harmonisches Farb-
konzept soll dabei die Ästhetik des Designs unterstreichen.
Eine weitere Anforderung der Bildschirmarbeitsverordnung ist zudem:
[..] die auf dem Bildschirm dargestellten Zeichen müssen scharf,
deutlich und ausreichend groß sein sowie einen angemessenen
Zeichen- und Zeilenabstand haben
[36]
.
4.6 Hardware- und Software-Randbedingungen
69
Aus dieser Vorgabe wird die Anforderung abgeleitet, dass die verwendete Schrift-
größe groß genug gewählt werden muss, so dass der Einsatz einer geeigneten
Schriftart und Satzform den Lesefluss begünstigen (siehe Anforderung ANF-18).
Anforderung ANF-17 (ausreichende Schriftgröße)
Die Schrift sollte groß genug sein, um eine gute Lesbarkeit zu gewährleisten.
Die Lesbarkeit soll zudem durch eine geeignete Schriftart manifestiert werden.
HARDWARE- UND SOFTWARE-RANDBEDINGUNGEN
Die Entwicklung des UI-Entwurfs wird auch von Hardware- und Software-Randbe-
dingungen beeinflusst. Eine Bildschirmauflösung von mindestens 1024x768 Pixel
sollte gegeben sein [37]. Des Weiteren ist eine Browser- und Plattformunabhän-
gigkeit wünschenswert, so dass alle Benutzer auf das BPMS zugreifen können. Da
die Arbeit sich nicht tiefer mit der Implementierung beschäftigt, wird dieser Ge-
sichtspunkt auch nicht detaillierter diskutiert.
Anforderung ANF-18 (SW- und HW-Randbedingungen)
Eine gute Bildschirmauflösung, Browser- und Plattformunabhängigkeit muss
gewährleistet sein.
GENERELLE ENTWURFSPRINZIPIEN
Diese Arbeit orientiert sich an den generellen Entwurfsprinzipien (siehe Kapitel 2.4),
als auch den psychologischen Grundlagen für die Systementwicklung (siehe Kapitel
2.3 ).Während der UI-Entwurfsphase werden auch systemspezifische Gestaltungsre-
geln definiert, die sogenannten UI-Style-Guides. Diese werden in Kapitel 5 detailliert
vorgestellt.
USABILITY-ZIELE
Eine verständliche Informationsarchitektur im BPMS soll gewährleistet sein. Daher
sollen Informationen, welche für den Benutzer bereitgestellt werden, leicht ver-
ständlich und strukturiert aufbereitet sein (siehe Anforderung ANF-19).Dadurch
können Informationen intuitiv vom Benutzer gefunden werden [12].
4 Anforderungsanalyse
70
Anforderung ANF-19 (Verständliche Informationsarchitektur)
Es sollen nur Informationen angezeigt werden, welche im aktuellen Kontext
vom Benutzer benötigt werden. Generell muss eine Informationsfilterung und
–verdichtung, sowie eine geeignete Informationsaufbereitung ermöglicht wer-
den. Der Benutzer soll beispielsweise seine Prozessmodelle nach bestimmten
Eigenschaften sortieren bzw. filtern können.
Aber auch die Navigation spielt eine entscheidende Rolle (siehe Anforderung ANF-
20). Der Benutzer sollte sich unabhängig davon, an welchem Punkt er sich gerade
im BPMS befindet, im Klaren sein, wo er sich gerade befindet und wie er weiter
oder zurück navigieren kann. Dadurch kann der Benutzer die gewünschten Infor-
mationen finden und auf Seiten des BPMS navigieren, ohne zusätzliche Denkarbeit
zu leisten [12].
Anforderung ANF-20 (Verständliches Navigationskonzept)
Der Benutzer sollte durch eine gute Navigation sich im BPMS zurecht finden
können. Breadcrumbs, welche die aktuelle Hierarchieebene des BPMS darstel-
len, sollen ihn dabei zusätzlich unterstützen.
Interaktionselemente des BPMS sollten immer nach einem wiederholten Muster
dargestellt werden, d.h. nach einem einheitlichen Interaktionsmuster. Dabei gibt es
bereits etablierte Standardlösungen, wie beispielsweise Buttons, Checkboxen oder
Menüs. Diese Interaktionsmuster können je nach Problemstellung miteinander
kombiniert werden und den Einstieg durch bereits bekannte Interaktionsmuster zu
vereinfachen (siehe Anforderung ANF-21). Das generelle Designprinzip für eine
einfache Interaktion heißt keep it simple and stupid (KISS) [38].
Anforderung ANF-21 (Einfache Interaktion)
Das Interaktionsmuster sollte intuitiv sein und eine einfache Interaktion ge-
währleisten.
4.8 Usability-Ziele
71
Das BPMS sollte dem Benutzer stets über den aktuellen Systemstatus informieren.
Daher ist es wichtig, dass jede Aktion des Benutzers ein Feedback liefert. Klare und
konsistente Feedbacks geben Aufschluss darüber, ob eine Aktion erfolgreich aus-
geführt wurde oder nicht. Anfänger sollten in ihrem Arbeitsfluss gestützt werden
und benötigen zudem eine stärkere Unterstützung. Durch das Ergänzen von Be-
nutzerhilfen, werden einzelne Funktionen des BPMSs für den Benutzer verständlich
erklärt (siehe Anforderung ANF-22).
Anforderung ANF-22 (Benutzerhilfen)
Unabhängig von dem Erfahrungswert des Benutzers, sollte dieser bei Bedarf
Informationen einholen können bzw. Feedback auf seine Aktionen erhalten.
Dies soll durch den Einsatz von Dialogen, Tool-Tips, Wasserzeichen oder Such-
funktionen ermöglicht werden.
Da Anfänger eine steile Lernkurve haben, sollte für fortgeschrittene Benutzer das
BPMS durch Expertenfunktionen (siehe Anforderung ANF-23) optimiert werden, wie
z.B. das Verwenden von regulären Ausdrücken in der Suchfunktion, Verwenden von
Tastenkürzeln, etc. Durch das Anbieten von solchen Expertenfunktionen, kann die
Arbeitszeit weiter minimiert werden.
Anforderung ANF-23 (Expertenfunktionen)
Benutzer, welche häufig das BPMS verwenden, sollen in ihrer Arbeit effizient
unterstützt werden. Tastenkürzel und Kontextmenüs sollen beispielsweise für
den Experten zur Verfügung stehen.
Unabhängig davon ob es sich um einen Anfänger oder einen Experten handelt,
liegt es in der menschlichen Natur, dass Fehler gemacht werden. Durch ein ent-
sprechendes Design kann Abhilfe geschaffen werden, um das Auftreten von Feh-
lern zu vermindern. Dazu werden beispielsweise unzulässige Aktionen deaktiviert
oder ausgeblendet. Tritt ein Fehler dennoch auf, sollte durch eine klare Sprache
eine Fehlermeldung erfolgen. Des Weiteren sollte durch die Fehleranzeige ersicht-
lich sein, wie der Fehler behoben werden kann (siehe Anforderung ANF-24).
4 Anforderungsanalyse
72
Anforderung ANF-24 (Fehlermeldungen)
Das BPMS sollte generell unzulässige Aktionen sperren, um Fehler zu vermei-
den. Fehlermeldungen sollten deutlich kenntlich gemacht werden und in einer
verständlichen Sprache formuliert sein.
Diese qualitativen Usability-Ziele gelten dabei als Vorgabe für den UI-Entwurf des
BPMS (siehe Kapitel 5).
ZUSAMMENFASSUNG
In diesem Kapitel wird das BPMS seitens der Anforderungen des Benutzers unter-
sucht, d.h. wie er welche Aufgaben im Arbeitsablauf durchführt [39]. Die ermittelten
Anforderungen wirken sich direkt auf die Funktionsblöcke im Interaktionsdesign aus.
Daher ist diese Phase essentiell, da sie den UI-Entwurf maßgeblich beeinflusst. Da-
bei werden noch keine konkreten Lösungen aufgezeigt, sondern nur zugrundelie-
gende Anforderungen, welche das BPMS erfüllen muss. Use Case-Diagramme die-
nen dabei als Übersicht, in welcher alle Funktionen aufgezeigt werden, was das
BPMS zukünftig leisten muss. Durch Use Cases werden einige Funktionen im Detail
beschrieben und der Standardablauf des BPMS, sowie mögliche Alternativ- und
Fehlerabläufe dargestellt. Die Bestimmung von Anforderungen stellen sowohl die
Grundlage für den UI-Entwurf, als auch die Basis für eine gute User Experience dar
(siehe Kapitel 2.4.5).
73
5 UI-ENTWURF
Der Benutzer möchte seine Zeile möglichst schnell, effektiv und zufriedenstellend
erreichen. Daher ist die Entwicklung eines guten Interaktionsdesigns elementar
wichtig. Aus diesem Grund sollten die zu gestalteten Dialoge für das BPMS, mög-
lichst wenig Interaktionen benötigen d.h. effizient sein, nützliche Optionen und Be-
fehle bereitstellen d.h. effektiv sein und den Benutzer im Ergebnis zufriedenstellen
[40]. Diese drei Aspekte werden unter dem Begriff Usability zusammengefasst
(siehe Kapitel 2.2.1), was bei der Entwicklung des UI-Entwurfs berücksichtigt wird.
Der Fokus in diesem Kapitel bezieht sich dabei auf die Funktionalität des BPMS und
nicht auf das visuelle Design. In Kapitel 5.1 wird das Interaktionsdesign sowie das
Navigationskonzept des BPMS vorgestellt (siehe Abbildung 30). Das Interaktions-
design wird mit Hilfe von Wireframes verdeutlicht. Anschließend wird in Kapitel 5.2
die Wireframes evaluiert und neue Lösungsansätze entwickelt.
ABBILDUNG 30 UI-ENTWURF
5 UI-Entwurf
74
Die Wireframes werden in Kapitel 5.3 als Mockup-Screens ausgearbeitet und im
folgenden Kapitel 5.4 nochmals evaluiert. Das fertige visuelle Design des BPMS
(siehe Kapitel 5.5) und der fertige UI-Entwurf (siehe Kapitel 5.6) runden dieses Ka-
pitel ab.
KONZEPTUELLES UI-MODELL UND UI-MOCKUPS
Die Entwicklung eines Interaktionsdesigns für das BPMS stellt ein iterativer Prozess
dar, welcher schrittweise aufgebaut ist [40]. Zunächst wird ein Interaktionsstil fest-
gelegt, was in Kapitel 5.1.1 beschrieben wird. Anschließend werden an Hand den
definierten Anforderungen und Use Cases zusammengehörige Funktionsblöcke de-
finiert und auf die passenden Dialoge verteilt (siehe Kapitel 5.1.2). Dadurch werden
die Funktionsblöcke in eine richtige Reihenfolge gebracht und eine sinnvolle Plat-
zierung innerhalb des Fensters definiert. Dies stellt die Basis für ein erstes Naviga-
tionskonzept (siehe Kapitel 5.1.3) dar, welches aber auch parallel dazu entwickelt
werden kann. Liegt ein Großteil der Funktionsblöcke vor, können diese weiter durch
Interaktionselemente und Daten ausgearbeitet werden. Um eine konsistente Ge-
staltung der Funktionsblöcke zu gewährleisten, werden Interaktionselemente wie-
derkehrend verwendet, um einem konsistenten Interaktionsmuster zu folgen (siehe
Kapitel 2.4.2). Während der Entwicklung des Interaktionsdesigns werden zudem
Grundregeln zur Dialoggestaltung berücksichtigt (siehe Kapitel 2.4.2).
INTERAKTIONSSTIL
Die Umsetzung einer Interaktion kann generell auf verschiedene Weise realisiert
werden [12]. Beispielsweise kann die Interaktion durch Drücken einer Taste oder
durch einen Mausklick ausgeführt werden. Die Tastatur und Maus stellen dabei die
Standard-Eingabemedien des BPMSs dar. Diese Art der Umsetzung einer Interak-
tion wird dabei als Interaktionstechnik bezeichnet. Die Sprachsteuerung, die Formu-
lareingabe, die Menüauswahl, sowie die direkte Manipulation stellen generell die
vier wichtigsten Interaktionsstile dar.
Für den Interaktionsstil des BPMS sind sowohl die Formulareingabe, die Menüaus-
wahl als auch die direkte Manipulation von Bedeutung. Die Formulareingabe wird
beispielsweise für die Anmeldung an das BPMS benötigt. Die Menüauswahl ist für
das Kopieren, Löschen oder Erstellen eines Ordners oder Prozessmodells sinnvoll.
5.1 Konzeptuelles UI-Modell und UI-Mockups
75
An Hand einer vorgegebenen Liste von Befehlen kann der Benutzer einen ge-
wünschten Befehl ausführen. Für die Prozessmodellierung, in der Aktivitäten hin-
zugefügt oder gelöscht werden können, wird zudem eine direkte Manipulation be-
nötigt. Dadurch können einzelne Aktivitäten oder das komplette Prozessmodell
manipuliert werden. Durch einen einfachen Mausklick auf eine Aktivität wird diese
selektiert. Durch Drücken und Schieben der Maustaste kann eine Drag-Aktion rea-
lisiert werden, welche beim Loslassen zu einer Drop-Aktion führt. Der Rechtsklick
der Maustaste ist dabei für das Kontextmenü im BPMS belegt. Das Aussehen des
Mauszeigers ändert sich zudem innerhalb einer speziellen Funktion. Wird der
Mauszeiger z.B. innerhalb eines Textfeldes platziert wird sie als Cursor angezeigt.
INTERAKTIONSDESIGN
Im Folgenden werden die Funktionsblöcke des BPMS identifiziert, gruppiert und
betitelt und auf die einzelnen Bildschirminhalte (Screens) des BPMS verteilt. An-
schließend erfolgt die Ausarbeitung der Funktionsblöcke durch passende Interak-
tionselemente. Diese werden durch Wireframes dargestellt, welche das grundle-
gende Layout der wichtigsten Interaktionselemente bildet. Zuerst werden grobe
Regionen angefertigt. Diese werden durch Interaktionselemente detaillierter aus-
gearbeitet. Ergänzend dazu wird eine Inhalts- oder Interaktionsbeschreibung, De-
tails zur Darstellung oder Fehlerbehandlung zusätzlich erläutert. Im Folgenden wer-
den statische Wireframes dargestellt. Dabei stellt ein Wireframe jeweils ein Haupt-
fenster bzw. den Bildschirm dar.
Anmeldung
Der Benutzer gibt bei der Erstellung seines Accounts seinen Vor- und Nachname,
seine E-Mail-Adresse und sein Passwort (siehe Anforderung ANF-4). Für die Eingabe
von Text wie z.B. den Vorname wird als Interaktionselement eine Text-Box verwen-
det. Die Eingabe wird durch einen Button bestätigt. Ein Rahmen fasst alle Interakti-
onselemente zusammen, welche zum Erstellen eines Account benötigt werden. Ist
bereits ein Account vorhanden, wird durch einen Mausklick auf den Link Keinen
Account? Anmelden der Benutzer direkt auf die Seite für die Anmeldung verwiesen
(siehe Abbildung 31).
5 UI-Entwurf
76
ABBILDUNG 31: WIREFRAME DES DIALOGS ACCOUNT ERSTELLEN
Die Anmeldung erfolgt mittels E-Mail-Adresse und Passwort. Auch hier befinden
sich konsistenter Weise die Links, wie bei Erstellung eines Accounts, unterhalb des
Rahmens (siehe Abbildung 32). Bei einer fehlerhaften Texteingabe wird die ent-
sprechende Text-Box visuell hervorgehoben, um die Aufmerksamkeit des Benut-
zers direkt auf die fehlerhafte Eingabe zu lenken. Zusätzlich wird eine möglichst
exakte Fehlerbeschreibung angezeigt (siehe Kapitel 2.4.2).
5.1 Konzeptuelles UI-Modell und UI-Mockups
77
ABBILDUNG 32: WIREFRAME DES DIALOGS ANMELDEN
Darstellung der Ordner in der Ordnerübersicht
Die Anordnung der verwendeten Funktionsblöcke werden ähnlich wie man sie be-
reits aus anderen Systemen (SkyDrive, Dropbox,…)kennt, angeordnet [12]. Diese
Konvention ist für das BPMS eingehalten, um den Benutzer einen vertrauten An-
blick zu schaffen und die Einstiegshürde des Benutzers in das BPMS und den zu-
gehörigen Lernaufwand gering zu halten. Folglich befindet sich das Logo des BPMS
oben links und der Titel in der Mitte, der die aktuelle Hierarchieebene beschreibt.
Resultierend sind die Breadcrumbs, welche die aktuelle Hierarchieebene des BPMS
beschreiben, neben dem Titel aufgeführt, da dort auf eine beliebige, übergeord-
nete Hierarchieebene navigiert werden kann. Die globale Navigation zu prozess-
übergreifenden Themen wie Nachrichten, Store und Einstellungen befinden sich
5 UI-Entwurf
78
oben rechts am Fenster. Funktionen, welche den Benutzer betreffen, wie beispiels-
weise die Profileinstellung, sind in unmittelbarer Nähe als Drop-down-Menü links
neben dem Profilbild aufzufinden. Die Platzierung des Profilbildes ist wie bereits
aus anderen sozialen Netzwerken (z.B. facebook, google+) bekannt, präsentiert.
Neben dem Profilbild wird der Vor- und Nachname des Benutzers zusätzlich dar-
gestellt (siehe Abbildung 33).
ABBILDUNG 33: WIREFRAME DES DIALOGS ORDNERÜBERSICHT
Der Content-Bereich befindet sich in der Mitte des Fensters. Dort erhält der Benut-
zer einen Überblick über seine privaten und geteilten Ordner. Das Scrollen durch
Breadcrumbs Menübar
Breadcrumbs
Content-Bereich
5.1 Konzeptuelles UI-Modell und UI-Mockups
79
die Ordnerübersicht erfolgt horizontal. Ein Ordner stellt dabei eine Zusammenfas-
sung von bereits konfigurierten Prozessmodellen, Dashboards oder Tabellen mit
Laufzeitinformationen dar. Neben der Art der Gruppe, wird zu jedem Ordner die
Anzahl der Kommentare und die Anzahl an laufenden Instanzen dargestellt. Diese
werden als Links zur Verfügung gestellt, um schnelle Einstiegspunkte in das BPMS
zu ermöglichen. Die Menübar, welche sich oben links im Fenster befindet, besteht
aus den drei Menüpunkten Neu, Edit und Run. Ein Mausklick auf einen Menüpunkt
löst das Öffnen einer Sidebar zum angewählten Menüpunkt aus. Durch erneuten
Mausklick auf den Menüpunkt kann die Sidebar wieder geschlossen werden. Die
Menübar agiert dabei ähnlich einem Akkordeon, in dem Inhalte zum Menüpunkt
sichtbar gemacht oder wieder eingefahren werden können. Die Sidebar wird auf
der linken Seite des Fensters, unterhalb der Menübar angezeigt. Dabei befindet
sich die Sidebar aus folgenden Gründen auf der linken Seite des Fensters:
Unterstützung des Leseflusses von links nach rechts.
Kontextinformationen/Kontextmenü wird standardmäßig am linken Fenster
dargestellt, wie z.B. in Microsoft Word und PowerPoint.
Inhalte von Seiten werden auf der linken Seite stärker wahrgenommen als
auf der rechten Seite.
Der Vorteil der Verwendung einer Sidebar besteht darin, dass viele Kontextinfor-
mationen und Funktionalitäten dargestellt werden können. Zudem würde ein
Menü, welches durchgehend sichtbar ist, viel Platz in Anspruch nehmen. Kontex-
tinformationen, welche im Kontext nicht benötigt werden, können somit wegge-
lassen werden. Dadurch kann der Benutzer sich auf seine Aufgaben konzentrieren
und wird nicht durch ein lokales Menü abgelenkt. Durch eine Sidebar können alle
Kontextinformationen auf einmal angezeigt werden. Dadurch muss sich der Benut-
zer nicht an alle Kontextinformationen erinnern und kann diese direkt vergleichen.
Visualisierungs-Controlls werden in einer sogenannten Display-Bar unten rechts im
Fenster zusammengefasst dargestellt. Die Display-Bar ist dabei direkt am unteren
Bildschirmrand positioniert, um diese schneller erreichbar zu machen [41]. Die Dis-
play-Bar befindet sich dabei bewusst rechts im Fenster, damit sie nicht von der
Sidebar überblendet wird. Die Display-Bar bietet eine Sortierung nach bestimmten
5 UI-Entwurf
80
Kriterien. Dazu gehören private und geteilte Ordner, eine alphabetische Sortierung,
Zuletzt geändert und offenstehenden Aufgaben an (siehe Anforderung ANF-6).
Diese werden als Drop-up-Menü in der Display-Bar angezeigt (siehe Abbildung 34).
ABBILDUNG 34: WIREFRAME DER DISPLAY-BAR
Eine Auto-complete-Suche unterstützt den Benutzer darin, konkrete Prozessmo-
delle schnell zu finden. Durch das Zooming ist eine Skalierung gegeben, in welcher
der Bildschirminhalt gleichermaßen vergrößert bzw. verkleinert wird. Der Bildschir-
minhalt wird vollständig sichtbar gemacht durch den Fit-to-Page-Button. Dadurch
erhält der Benutzer einen schnellen Überblick über alle Inhalte. Eine direkte Navi-
gation auf die Timeline, ist durch den Button Timeline realisiert. Dadurch kann der
Benutzer direkt zu der Timeline navigieren. Die einzelnen Menüpunkte der Men-
übar zur Ordnerübersicht werden im Folgenden kurz erläutert. Durch den Menü-
punkt Neu, kann ein neuer Ordner angelegt werden. Für die Erstellung eines neuen
Ordners wird ein Textfeld für den Ordnername angezeigt. Anschließend kann die
Texteingabe bestätigt oder abgebrochen werden (siehe Abbildung 35).
Durch einen Mausklick wird ein Ordner selektiert und die Sidebar Edit öffnet sich.
Der Sidbar Edit beinhaltet Eigenschafen des selektierten Ordners, welche durch auf-
klappbare Untermenüs gruppiert sind (siehe Anforderung ANF-8). Dabei werden
die Interaktionselemente so angeordnet, dass sie den natürlichen Lesefluss unter-
stützen, d.h. der Lesefluss beginnt oben links und endet unten rechts. Dadurch wird
die Übersichtlichkeit bewahrt und es ist kein langes Scrollen durch Inhalte von Nö-
ten. Durch Einrücken von Menüpunkten werden Eigenschaften des selektierten
Ordners zudem hierarchisiert. Die Einteilung eines Ordners in privat oder geteilt
erfolgt durch die Eigenschaft Benutzerrechte. Benutzerrechte und weitere Inhalte
der einzelnen Untermenüs werden später beim Vorstellen der Prozessansicht ge-
nauer erläutert. Des Weiteren kann ein Ordner oder mehrere Ordner geteilt und
gelöscht werden (siehe Abbildung 36).
5.1 Konzeptuelles UI-Modell und UI-Mockups
81
ABBILDUNG 35: WIREFRAME DES DIALOGS ORDNER ERSTELLEN
ABBILDUNG 36: WIREFRAME DES DIALOGS ORDNER EDITIEREN
5 UI-Entwurf
82
Der Menüpunkt Run enthält aufklappbaren Untermenüs, die laufende Instanzen
und abgeschlossenen Instanzen gruppieren.
ABBILDUNG 37: WIREFRAME DES DIALOGS INSTANZEN
Zwei Drop-down-Menüs befinden sich oberhalb der beiden Untermenüs, um In-
stanzen zu filtern. (siehe Abbildung 37).
Darstellung von Prozessmodellen, Dashboards und Tabellen in der Prozess-
modellübersicht
Nachdem Öffnen eines Ordners (durch Doppelklick) werden in der Prozessmodell-
übersicht verschiedene Prozessmodelle oder auch Dashboards bzw. Tabellen mit
Ausführungsinformationen sichtbar gemacht. Der Benutzer erhält so einen schnel-
len Überblick über alle Prozessmodelle, da jedes Prozessmodell mit einem Vor-
schaubild oder einem Icon präsentiert wird (siehe Anforderung ANF-5). Dadurch
wird der Wiedererkennungswert des Prozessmodells erhöht (siehe Abbildung 38).
Die Display-Bar der Prozessmodellübersicht ist analog zu der in der Ordnerüber-
sicht aufgebaut. Jedoch ist eine Filterung nach privaten bzw. geteilten Ordnern
nicht mehr möglich. Darüber hinaus ist auch die Menübar gleich strukturiert. Da
die Sidebar ihren Inhalt entsprechend der Hierarchieebene ändert, beinhaltet die
Sidebar zum Menüpunkt Neu folgenden Inhalt (siehe Tabelle 24).
5.1 Konzeptuelles UI-Modell und UI-Mockups
83
ABBILDUNG 38: WIREFRAME DES DIALOGS DER PROZESSMODELLÜBERSICHT
Sidebar zu Menü-
punkt Neu
Anlegen eines
neuen Prozessmo-
dells
Prozessmodell aus
Store kaufen
TABELLE 24: SIDEBAR ZU MENÜPUNKT NEU IN PROZESSMODELLÜBERSICHT
Durch das Anbieten einer direkten Navigation zum Store in der Sidebar ist eine
alternative Bedienmöglichkeit geschaffen (siehe Kapitel 2.4.2). Prozessmodelle im
Store werden ebenfalls mit einem Vorschaubild und dem Prozessmodellname an-
gezeigt (siehe Anforderung ANF-12), um einer konsistente Darstellung eines Pro-
zessmodells zu bewahren (siehe Abbildung 39).
5 UI-Entwurf
84
ABBILDUNG 39:WIREFRAME DES DIALOGS PROZESSMODELLÜBERSICHT NEU
ABBILDUNG 40: WIREFRAME DES DIALOGS PROZESSMODELLÜBERSICHT EDIT
5.1 Konzeptuelles UI-Modell und UI-Mockups
85
Im Menüpunkt Run werden alle enthaltenen Instanzen des Ordners aufgeführt
(siehe Abbildung 41). Dabei findet eine Unterteilung in laufende und abgeschlos-
sene Instanzen statt. Auch die Filterung über Drop-down-Menüs ist gegeben. Dies
realisiert beispielsweise eine Anzeige von allen existierenden Instanzen. Das Erzeu-
gen einer neuen Instanz bzw. das Ausführen eines Prozessmodells ist direkt über
den Button Run gegeben und ermöglicht dem Benutzer einen schnellen Einstiegs-
punkt in die Prozessausführung (siehe Kapitel 2.4.3).
ABBILDUNG 41: WIREFRAME DES DIALOGS PROZESSMODLELÜBERSICHT RUN
Möchte der Benutzer mehrere Prozessmodelle gleichzeitig bearbeiten, markiert der
Benutzer über einen Selektionsbereich mehrere Prozessmodelle. Alternativ ist dies
auch über den linken Mausklick und gleichzeitiges Drücken der Shift-Taste reali-
sierbar (siehe Abbildung 42). Dadurch können mehrere Prozessmodelle geteilt, ko-
piert oder gelöscht werden. Die Namen der selektierten Prozessmodelle wird ober-
halb der Eigenschaften in der Sidebar angezeigt, um den Benutzer darauf hinzu-
weisen, welche Eigenschaften aktuell editierbar sind.
5 UI-Entwurf
86
ABBILDUNG 42: WIREFRAME DES DIALOGS MEHRERE PROZESSMODELLE EDITIEREN
Darstellung des Prozessmodells in der Prozessmodellansicht
Ein Prozessmodell in der Prozessmodellübersicht wird analog zu einem Ordner
durch Doppelklick geöffnet. In der Prozessmodellansicht wird das Prozessmodell
in der Prozessdarstellung BPMN angezeigt (siehe Abbildung 43). Dadurch erhält
der Benutzer ein Gefühl von Vertrautheit, da der Benutzer die BPMN bereits aus
der BPM kennt.
Neben der BPMN ist die Änderung der Prozessdarstellung auf eine zweite Darstel-
lungsart möglich (siehe Anforderung ANF-6). Diese Entwicklung einer zweiten Art
der Prozessdarstellung (sogenannte Transit-Map) ist ebenfalls Resultat dieser Ar-
beit, welche vorgestellt wird.
5.1 Konzeptuelles UI-Modell und UI-Mockups
87
ABBILDUNG 43: WIREFRAME DES DIALOGS DER PROZESSMODELLANSICHT
Transit-Map
Eine kompakte Darstellungsart von Prozessmodellen ermöglicht die Transit-Map.
Dort wird der Name nicht in der Aktivität, sondern neben der Aktivität dargestellt.
Folglich können Aktivitäten kleiner dargestellt werden. Dadurch kann die Größe
des Prozessmodells reduziert werden, was die Übersichtlichkeit erhöht. Die Transit-
Map enthält dennoch die gleichen Prozesselemente, wie die Prozessdarstellung
BPMN (siehe Kapitel 2.1.2). Darüber hinaus adressiert die Transit-Map die Leserich-
tung von Texten: stellt das Lesen von links nach rechts und von oben nach [35].
Folglich visualisiert die Transit-Map Prozessmodelle. Verzweigungen, wie XOR- o-
der AND-Gateways, werden dabei von links nach rechts aufgebaut (siehe Abbil-
dung 44). Durch diese Darstellungsart ähnelt ein Prozessmodell einer Checkliste.
5 UI-Entwurf
88
ABBILDUNG 44: TRANSIT-MAP
Die Transit-Map wird zudem ohne Datenkanten an den Pfaden dargestellt, da im
Fokus eine einfache, kompakte Darstellungsart gewährleistet sein soll. Alleinig eine
Schleife besitzt eine Pfeilspitze.
Die Änderung der Prozessdarstellung erfolgt über das linke Drop-up-Menü auf der
Display-Bar (siehe Abbildung 45). Über das danebenliegende Drop-up-Menü All-
gemeine Sicht kann das Prozessmodell nach verschiedenen Kriterien gefiltert wer-
den. Dadurch wird die Darstellung des Prozessmodells geändert, was einen positi-
ven Aspekt auf die quantitative und qualitative Komplexität des Prozessmodells
hat. Bei komplexen Prozessmodellen, in welcher nicht alle Bereiche des Prozess-
modells sichtbar sind, ist die Verwendung der Navigation sinnvoll. Dadurch können
konkrete Bereiche des Prozessmodells schneller sichtbar bzw. zugänglich gemacht
5.1 Konzeptuelles UI-Modell und UI-Mockups
89
werden, in den der Selektionsbereich im Vorschaubereich der Navigation verscho-
ben wird. Dadurch kann ein langes Scrollen durch das Prozessmodell vermieden
werden (siehe Kapitel 2.4.3).
ABBILDUNG 45: WIREFRAME DER DISPLAY-BAR IN DER PROZESSMODELLANSICHT
Prozessmodellierung mit unspezifischen und vorkonfigurierten Prozessele-
menten
Über die Sidebar des Menüpunkt Elemente können unspezifische und vorkonfigu-
rierte Elementen zum Prozessmodell hinzugefügt werden. Dabei werden Aktivitä-
ten über eine Drag-& Drop-Aktion an die gewünschte Stelle im Prozessmodell ein-
gefügt (siehe Abbildung 46). Durch Doppelklick auf den Namen des Prozessele-
ments kann der Name inline editiert werden. Ein einfacher Mausklick ermöglicht
das Editieren des Namens über die Sidebar des Menüpunktes Edit.
Das Einfügen von neuen Prozesselementen kann aber auch über ein Menü-on-De-
mand erfolgen. Bei Mouse-Over über eine Prozessmodellkante wird dieses geöffnet
(siehe Abbildung 47). Das Menü-on-Demand beinhaltet ausschließlich unspezifi-
sche Prozesselemente, welche eingefügt werden können. Durch diese alternative
Lösungsmöglichkeit kann der Benutzer schnell und gezielt ein Prozesselement an
die gewünschte Stelle des Prozessmodells einfügen.
5 UI-Entwurf
90
ABBILDUNG 46: WIREFRAME DER SIDEBAR DER PROZESSMODELLIERUNG
ABBILDUNG 47: WIREFRAME DES MENÜ-ON-DEMAND
Eigenschaften des Prozessmodells editieren
Allgemeine Eigenschaften, welche das Prozessmodell als Ganzes beschreiben, wer-
den für den Benutzer in der Sidebar zugänglich gemacht (siehe Anforderung ANF-
8). Diese sind als Untermenüs aufklappbar. Das Teilen, Kopieren oder Löschen eines
Prozessmodells ist unterhalb der Untermenüs möglich (siehe Abbildung 48).
5.1 Konzeptuelles UI-Modell und UI-Mockups
91
ABBILDUNG 48: WIREFRAME DER SIDEBAR EDIT
In Abbildung 50 werden die Eigenschaften der Sidebar Edit im Detail dargestellt
und in Tabelle 25 detailliert beschrieben.
Sidebar Edit
Prozessmodell-
name
Icon
Beschreibung
Anhänge (engl.:
Attachments)
5 UI-Entwurf
92
Zeit (engl.: Time)
Benutzerrechte
(engl.: Access
Rights)
TABELLE 25: SIDEBAR EDIT IN PROZESSMODELLANSICHT
Des Weiteren können Eigenschaften einzelner Prozesselemente gesetzt werden.
Über einen Mausklick auf ein Prozesselement, werden entsprechende Eigenschaf-
ten in der Sidebar Edit sichtbar gemacht (siehe Abbildung 50).
5.1 Konzeptuelles UI-Modell und UI-Mockups
93
ABBILDUNG 49 WIREFRAME DER SIDEBAR EDIT IM DETAIL
Im Untermenü Plug-in kann die Art des Plug-ins bestimmt werden. Initial ist das
Plug-in auf User Task gesetzt, d.h. die Aktivität wird vom Benutzer ausgeführt. Unter
dem Menüpunkt Assigned Users wird festgelegt, wer für die Ausführung der Akti-
vität zuständig ist. Das Untermenü ist in der Platzierung und der Anordnung der
Interaktionselemente analog zu den Benutzerrechten für Prozessmodelle gestaltet.
Durch die Verwendung von Interaktionsmustern, wird dem Benutzer die Bedienung
so erleichtert (siehe Kapitel 2.4.2).
Im letzten Untermenü Datenobjekte werden dem Benutzer Datenelemente ange-
zeigt, welche er bereits im Prozesselement hinterlegt hat. Diese Datenelemente
können gelesen oder geschrieben werden. Ein Prozessmodellpfad kann durch ein
Textfeld beschrieben werden. Geschriebene oder gelesene Parameter sind eben-
falls ein bzw. ausklappbar, um die Übersichtlichkeit in der Sidebar beizubehalten.
5 UI-Entwurf
94
ABBILDUNG 50: WIREFRAME DER SIDEBAR FÜR AKTVITÄT
Neben Eigenschaften einer Aktivität können auch Eigenschaften von Gateways o-
der des Startknotens festgelegt werden (siehe Abbildung 51).
ABBILDUNG 51: WIREFRAME DER SIDEBAR FÜR GATEWAY UND STARTKNOTEN
Verzweigungen von Gateways sind im Untermenü Branches einstellbar nach ma-
nuell, automatisch und variabel. Dadurch können Fragen formuliert oder mathema-
tische Funktionen für Verzweigungsbedingungen gesetzt werden. Im Startknoten
5.1 Konzeptuelles UI-Modell und UI-Mockups
95
kann der Start einer Prozessausführung zudem durch die Vergabe eines Triggers
im Untermenü Branches bestimmt werden.
Prozessausführung
In der Sidebar Run (siehe Abbildung 52) erhält der Benutzer einen Überblick über
laufende und bereits abgeschlossene Instanzen (siehe Anforderung ANF-10).
ABBILDUNG 52: WIREFRAME DES DIALOG DER PROZESSAUSFÜHRUNG
Durch Aufklappen eines der beiden Untermenüs in Abbildung 53, werden dem Be-
nutzer die jeweiligen Instanzen angezeigt. Abbildung 53 zeigt detailliert das Unter-
menü laufender Instanzen, sowie die Sidebar für eine selektierte, einzelne Aktivität
während der Prozessausführung. Eine laufende Instanz wird dabei durch den In-
stanznamen, Prozessnamen, Datum und Name des Benutzers sowie dem Fertigstel-
lungsdatum beschrieben (siehe Anforderung ANF-10). Zudem wird dem Benutzer
Aufschluss darüber gegeben, wie weit das Prozessmodell bereits ausgeführt wurde.
Dies erfolgt über die Anzeige des Fortschritts. Über den Button Information erhält
der Benutzer Einsicht von bereits hinterlegten Kommentaren und Anhängen.
Generell muss dem Benutzer die Möglichkeit gegeben werden, Instanzen abbre-
chen zu können. Dazu wird der Button Instanz abbrechen bereitgestellt (siehe An-
forderung ANF-10). Die Sidebar einer selektierten Aktivität unterscheidet sich dabei
nicht wesentlich von einer selektierten Aktivität während der Prozessausführung.
Der Unterschied ist lediglich, dass Kommentare während der Prozessausführung
hinterlegt werden können.
5 UI-Entwurf
96
ABBILDUNG 53: WIREFRAME DER SIDEBAR FÜR PROZESSAUSFÜHRUNG
Das Erstellen einer Instanz kann auf zwei Arten erfolgen: über die Sidebar sowie den
Startknoten im Prozessmodell. In der Sidebar wird durch Mausklick auf den Button
Run oder durch die Vergabe eines Instanznamen und anschließender Bestätigung
des Buttons Erstellen eine neue Instanz erzeugt (siehe Abbildung 54).
ABBILDUNG 54: WIREFRAME VON INSTANZ ERSTELLEN
5.1 Konzeptuelles UI-Modell und UI-Mockups
97
Bei Mouse-Over über den Startknoten des Prozessmodells erscheint ein Button
Run. Der Benutzer kann über diesen Button das Prozessmodell direkt starten, ohne
in die Sidebar gehen zu müssen (siehe Abbildung 55).
ABBILDUNG 55: WIREFRAME VON INSTANZ ERSTELLEN ÜBER DEN STARTKNOTEN
Ist die Instanz gestartet, kann der Benutzer durch Mausklick auf das entsprechende
Prozesselement das Prozessmodell ausführen. Das aktuelle ausgeführte Prozes-
selement wird dabei farblich hervorgehoben, um zu verdeutlichen, wo er die Pro-
zessausführung befindet (siehe Abbildung 56). Die Anzeige des Fortschritts zum
Prozessmodell in der Sidebar passt sich zudem der Prozessausführung an. Die Pro-
zessausführung kann über den Button Ausführungsansicht schließen geschlossen
werden.
ABBILDUNG 56: WIREFRAME VON INSTANZ AUSFÜHREN
5 UI-Entwurf
98
Trifft der Benutzer bei der Prozessausführung auf ein XOR-Gateway, erscheint dem
Benutzer oberhalb des Gateways ein Pop-up-Menü (siehe Abbildung 57). Hier kann
durch Radio-Buttons entscheiden, welcher der nachfolgenden Pfade ausgeführt
werden soll.
ABBILDUNG 57: WIREFRAME VON XOR-GATEWAY
Eine ausgeführte Aktivität wird mit dem Benutzernamen, dem Datum und der An-
zahl an Kommentaren im Prozessmodell, beschrieben. Zudem werden hinterlegte,
vorkonfigurierte Elemente als kleine Symbole direkt in der Aktivität angezeigt.
Dadurch kann nachvollzogen werden wann, von wem und wie eine Aktivität aus-
geführt wurde.
ABBILDUNG 58: WIREFRAME DER TRANSIT-MAP IN PROZESSAUSFÜHRUNG
Abbildung 58 zeigt die Transit-Map in der Prozessausführung an. Eine ausgeführte
Aktivität wird mit den gleichen Eigenschaften wie bei der Aktivität in der BPMN
beschrieben.
Datenelemente in Prozessmodell hinterlegen
Eine Liste von bereits hinterlegten Datenelementen gibt dem Benutzer Feedback,
welche Datenelemente bereits hinterlegt sind (siehe Anforderung ANF-10). Diese
werden durch den Namen und Datentyp beschrieben. Bei einem Mouse-Over über
ein Datenobjekt erhält der Benutzer Feedback, welche Datenelemente bereits im
Prozessmodell hinterlegt sind (siehe Abbildung 59).
5.1 Konzeptuelles UI-Modell und UI-Mockups
99
ABBILDUNG 59: WIREFRAME DER SIDEBAR DATENELEMENTE
Das Hinterlegen von weiteren lesenden (d.h. Output) und schreibenden (d.h. Input)
Datenelementen, wird über eine Drag-&-Drop-Aktion realisiert. Beispielsweise wird
ein schreibendes Datenelement, indem der Benutzer den Button Input auf das ge-
wünschte Prozesselement im Prozessmodell zieht, erstellt. Zusätzlich wird ein ein-
gehender Pfeil im schreibenden Datenelement dargestellt, welche die Datenkante
darstellt.
Einzelne Parameter müssen dabei eingesehen werden können, um den Benutzer
Feedback zu geben, welche Daten später bei der Prozessausführung benötigt wer-
den (siehe Anforderung ANF-11).
Informationen zum Inhalt eines Datenelements erhält der Benutzer über den Button
Information. Das Datenelement vergrößert sich dabei auf die volle Breite der Side-
bar (siehe Abbildung 60). Parameter werden durch einen Namen und Angabe des
Datentyps detaillierter beschrieben. Zudem kann ein ganzes Datenelement, sowie
gesetzte lesende und schreibende Datenelemente entfernt werden (d.h. über den
Button Löschen).
5 UI-Entwurf
100
ABBILDUNG 60: WIREFRAME DER SIDEBAR DATENELEMENTE IM DETAIL
Über den Button Datenelement hinzufügen, erhält der Benutzer ein Set von vorde-
finierten Datenelementen, welche durch eine Suche und einen Filter reduziert wer-
den können (siehe Abbildung 61).
ABBILDUNG 61: WIREFRAME ZU DATEN HINZUFÜGEN
5.1 Konzeptuelles UI-Modell und UI-Mockups
101
Store
Prozessmodelle werden über einen Store für den Benutzer zugänglich gemacht.
Dabei legt sich das Fenster des Stores vollständig über den zuletzt dargestellten
Dialog. Im Store sind vorkonfigurierte Prozessmodelle analog zur Prozessmodell-
übersicht präsentiert (siehe
Abbildung 62). Darüber hinaus werden deren Bewertung und Preis angezeigt (siehe
Anforderung ANF-12).
ABBILDUNG 62: WIREFRAME DES DIALOGS STORE
Die Display-Bar enthält neben den bereits bekannten Visualisierungs-Controlls ei-
nen Prozessmodellfilter. Dadurch können Prozessmodelle nach verschiedenen Kri-
terien gefiltert werden (z.B. Kostenlose Prozessmodelle). Über den Button Informa-
tion, kann sich der Benutzer Informationen zum Prozessmodell in der Sidebar an-
zeigen lassen. Dazu gehört eine Bewertung, die Anzahl an Downloads, Informatio-
nen zum Prozessmodell, sowie eine Kommentarfunktion. Neben einer Beschreibung
des Prozessmodells, kann der Benutzer diesen auch kaufen. Dies erfolgt über den
Button Kaufen (siehe Abbildung 63).
5 UI-Entwurf
102
ABBILDUNG 63: WIREFRAME DER SIDEBAR STORE
Der Store kann über den Button Schließen (rechts oben im Fenster) wieder ge-
schlossen werden und der vorherige Dialog wird wieder angezeigt. Folglich ist kein
Kontextwechsel gegeben und der Benutzer kann schnell wieder in seine vorherige
Arbeit einsteigen.
Timeline
Die Timeline legt sich analog wie der Store vollständig über den aktuell dargestell-
ten Dialog. Über den Button Schließen, welcher sich rechts oben im Fenster befin-
det, kann die Timeline wieder geschlossen werden. Dadurch ist ein schneller Rück-
sprung in den zuvor angezeigten Bildschirminhalt möglich. In der Timeline wird die
Historie des Prozessmodells wiedergegeben, d.h. was über eine bestimmte Zeit mit
dem Prozessmodell geschehen ist (siehe Anforderung ANF-13). Der zeitliche Ver-
lauf eines Prozessmodells beschreibt beispielsweise einen Ablauf vom Modellieren,
Editieren bis hin zur Prozessausführung. Dabei können auch prozessmodellüber-
greifende Vergleiche vorgenommen werden, da die Historie von mehrere Prozess-
modelle und ihre zugehörigen Instanzen gleichzeitig miteinander betrachtet wer-
den können (siehe Abbildung 64). Generell werden Prozessmodelle als Grundlinie
5.1 Konzeptuelles UI-Modell und UI-Mockups
103
unterhalb der präsentierten Instanzen dargestellt. Die Zeiten und Informationen
(was über die Zeit hinweg mit dem Prozessmodell passiert ist) werden dabei dar-
gestellt.
ABBILDUNG 64: WIREFRAME DES DIALOGS TIMELINE
Ein Symbol, welches den Fortschritt angibt und eine dazugehörige Beschreibung,
erhöhen die Nachvollziehbarkeit, wie weit ein Prozessmodell bzw. eine Instanz be-
reits ausgeführt worden ist. Weitere Informationen werden als Tool-Tip bei Mouse-
Over über ein Symbol dargestellt wie z.B. der Name von einem Benutzer und wel-
cher Änderungen dieser vorgenommen hat. Die vertikale Linie auf der Timeline
stellt dabei den aktuellen Zustand der Prozessmodelle und Instanzen dar. Ähnlich
einer To-do-Liste kann der Benutzer daraus Informationen ziehen, was für Aufga-
ben er heute bearbeiten muss. Zudem werden auch Deadlines und Instanzen an-
gezeigt. Dadurch erhält der Benutzer einen Überblick über Instanzen, welche er
bearbeiten muss.
Dabei kann zwischen einer linearen Darstellungsart und einer Darstellungsart als
Höhenprofil gewechselt werden. Dies erfolgt über das Drop-up-Menü der Display-
5 UI-Entwurf
104
Bar, welche sich konsistenter Weise unten rechts im Fenster befindet. Das Höhen-
profil stellt eine kompaktere Darstellungsart dar, da Instanzen als Gruppe an einem
Tag zusammengefasst werden. Zudem beinhaltet die Display-Bar eine Suche und
Filtermöglichkeiten nach Kommentaren und laufenden Instanzen. Initial werden auf
der Timeline alle Prozessmodelle mit Instanzen dargestellt. Da die Ansicht sehr
komplex werden kann, muss eine Reduzierung der Ansicht angeboten werden. Dies
ist über die Festlegung der Zeitspanne, was den zeitlichen Rahmen festlegt, gege-
ben. Zudem können oberhalb der Timeline Kategorien angelegt werden, welche als
Filter fungieren. Dabei handelt es sich um Gruppierungen von Prozessmodellen
bzw. Instanzen mit bestimmten Eigenschaften (siehe Abbildung 65).
ABBILDUNG 65: WIREFRAME ZU FILTER ERSTELLEN
Der Benutzer kann so bestimmte Prozessmodelle und Instanzen festlegen. Durch
die Vergabe von bestimmten Keywords wie laufende bzw. abgeschlossene Instan-
zen, aktivierten bzw. nicht aktivierten Aktivitäten, sowie Benutzerrechten kann der
Filter verfeinert werden. Ein Mausklick auf die Checkbox einer angelegten Katego-
rie, hat zur Folge, dass die Kategorie in der Timeline als Filter berücksichtigt wird.
Profileinstellung
Durch Mausklick auf das Profilbild bzw. den kleinen Pfeil in der globalen Navigation
klappt ein Drop-down-Menü auf (siehe Abbildung 66).
ABBILDUNG 66: WIREFRAME DES DROP-DOWN-MENÜS
5.1 Konzeptuelles UI-Modell und UI-Mockups
105
Neben dem Menüpunkt Abmelden am BPMS über Logout, kann der Benutzer auch
Einstellungen zum Profil über den Menüpunkt Profileinstellung vornehmen. Unter
Profileinstellung, kann der Benutzer neben seinem Vor- und Nachnamen, seine E-
Mail-Adresse und sein Profilbild ändern (siehe Anforderung ANF-15). Zudem kann
der Benutzer eine für sich geeigneten Sprache auswählen (siehe Kapitel 2.4.3).
ABBILDUNG 67: WIREFRAME DES DAILOGS PROFILEINSTELLUNG
Auch die Ansicht der Profileinstellung kann über den Button Schließen wieder ge-
schlossen werden kann (siehe Abbildung 67).
Einstellungen
Neben der Profileinstellung, können auch allgemeine Einstellungen gesetzt werden.
Über den Menüpunkt Einstellungen können vier verschiedene Einstellungen vorge-
nommen werden, welche Organisationseinheiten, Plug-ins, Datenelemente und
Prozessmodellfilter betreffen. Diese sind über die Menübar zugänglich sind.
Abbildung 68 zeigt Organisationseinheiten in der Sidebar. Dadurch können Benut-
zer verwaltet werden, d.h. umbenannt, gelöscht oder Rollen zugeordnet werden. Ein
Benutzer wird durch den Vor- und Nachnamen, sowie einem Profilbild kenntlich
5 UI-Entwurf
106
gemacht. Durch Mausklick auf eine Organisationseinheit, kann diese editiert wer-
den. Neben der Vergabe des Namens der Organisationseinheit, sowie einem pas-
senden Icon, können weitere Rechte vergeben werden.
Unter Group Rights ist die Möglichkeit gegeben Ordner hinzuzufügen, welche
durch die Benutzerrechte Ansehen und Edit klassifiziert werden. Im Menüpunkt Mo-
del Rights können durch Hinzufügen von Prozessmodellen, ebenfalls Benutzer-
rechte vergeben werden. Dazu gehört neben View- und Editrecht, das Ausführungs-
recht. Zudem ist es sinnvoll, Vertreter zu bestimmen. Durch die Zuweisung von Auf-
gaben an Vertreter, werden Mitarbeiter entlastet. Des Weiteren wird die Aufga-
benerledigung gewährleistet (siehe Kapitel 2.1.3).
ABBILDUNG 68: WIREFRAME DES DIALOGS ORGANISATION
Im Untermenü Vertreter, sind alle Vertreter des BPMs aufgeführt. Diese sind mit
einem Profilbild, sowie dem Vor- und Nachnamen präsentiert. Über den Button
Hinzufügen kann ein neuer Vertreter angelegt werden. Zum Anlegen eines neuen
Vertreters werden Vor- und der Nachname, die E-Mail-Adresse, sowie das Passwort
eingegeben.
5.1 Konzeptuelles UI-Modell und UI-Mockups
107
Über den Button Schließen, welcher oben rechts im Fenster platziert ist, werden die
Einstellungen wieder geschlossen und der Benutzer befindet sich wieder auf der
zuletzt geöffneten Ansicht. Somit ist kein Kontextwechsel gegeben und der Benut-
zer kann schnell wieder an seine vorherige Arbeit anknüpfen.
Neben der Bearbeitung von Organisationseinheiten, können bereits bestehende
Plug-ins bearbeitet oder neue hinzugefügt werden (siehe Abbildung 69).
ABBILDUNG 69: WIREFRAME DES DIALOGS PLUG-INS
Ein Plug-in wird dabei durch einen Namen und ein Icon in der Sidebar kenntlich
gemacht. Unter dem Menüpunkt Details sind verschiedene Einstellungsmöglich-
keiten zu den schreibenden und lesenden Parametern möglich. Neben dem Anle-
gen von Plug-ins, können neue Datenelemente generiert werden. Neben einfachen
Datentypen, Upload-Typen und Enum-Typen, können auch Datenobjekte angelegt
werden. Dies erfolgt über den Menüpunkt Datenelemente in der Menübar (siehe
Abbildung 70).
Des Weiteren kann der Name und Icon zu einem Datenelement nachträglich geän-
dert werden. Auch kann die Farbe, welches das Datenelement beschreibt, bestimmt
werden. Neben der Vergabe von Details, ist es möglich ein Datenelement zu erwei-
tern. Dies erfolgt über den Button Datenelement erweitern.
5 UI-Entwurf
108
ABBILDUNG 70: WIREFRAME DES DIALOGS DATENELEMENTE
Der letzte Menüpunkt ist der Filter, der es erlaubt neue Prozessmodellfilter zu er-
stellen. Über die Vergabe des Namens und einer PQL-Query können Filter editiert
bzw. ein neuer angelegt werden [31] (siehe Abbildung 71). Durch das Setzen von
Filtern kann der Benutzer das Prozessmodell individuell nach seinen Vorlieben an-
passen (siehe Kapitel 2.4.2).
ABBILDUNG 71: WIREFRAME DES DAILOGS FILTER
NAVIGATIONSKONZEPT
Im Folgenden wird das Navigationskonzept des BPMs vorgestellt, in welcher der
Navigationsplan und die Elemente der Navigation des BPMS beschrieben werden.
Navigationsplan
Durch einen Navigationsplan werden Navigationspfade und Zusammenhänge von
einzelnen Dialogen auf einfache und verständliche Weise visualisiert [12]. Zuerst
5.1 Konzeptuelles UI-Modell und UI-Mockups
109
wird die Einstiegsseite dargestellt, welche das Anmelden an das BPMS darstellt
(siehe Abbildung 72). Anschließend wird die Hauptnavigation vorgestellt.
An Hand eines Navigationsplans können die Zusammenhänge einzelner inhaltli-
cher Seiten erklärt werden. Die Hauptnavigation des BPMS beschränkt sich im We-
sentlichen auf drei Hauptseiten (siehe Abbildung 72): Ordnerübersicht, Prozessmo-
dellübersicht und Prozessmodellansicht. Dadurch kann sich der Benutzer besser im
BPMS zurechtfinden, da er nicht durch lange Navigationspfade navigieren muss
(siehe Anforderung ANF-20), um schnell zu den gewünschten Informationen und
Funktionen zu gelangen.
ABBILDUNG 72: NAVIGATIONSPLAN DES BPMS
Nach erfolgreichem Anmelden kommt der Benutzer auf die Ordnerübersicht, in der
alle Ordner dargestellt werden, auf die der Benutzer Zugriff hat. Durch Öffnen eines
Ordners, gelangt der Benutzer auf die Prozessmodellübersicht, in der entspre-
chende Prozessmodelle, Dashboards und Tabellen dargestellt werden. Die letzte
Hauptseite ist die Prozessmodellansicht, welche beim Öffnen eines Prozessmodells
geladen wird. In der Prozessmodellansicht ist das Prozessmodell dargestellt und
Funktionalitäten, wie die Prozessmodellierung und Prozessausführung werden zur
Verfügung gestellt. Um die Basis für ein übersichtliches BPMS zu schaffen (siehe
Anforderung ANF-19), werden drei Grundregeln bei der Entwicklung eines Naviga-
tionskonzeptes eingehalten:
5 UI-Entwurf
110
Dialoge werden so reduziert wie möglich gehalten. Der Leitgedanke dabei
ist: Weniger ist mehr.
Inhalte werden untereinander stark verlinkt.
Es werden nur Navigationselemente bereitgestellt, welche im Kontext be-
nötigt werden.
Abbildung 73 stellt das Navigationskonzept der drei Hauptseiten mit der globa-
len Navigation und der Sidebar dar.
ABBILDUNG 73: NAVIGATIONPLAN VON DEN DREI HAUPSEITEN
5.1 Konzeptuelles UI-Modell und UI-Mockups
111
Daraus ist ersichtlich, dass von allen drei Hauptseiten aus, auf Nachrichten, den
Store, Einstellungen, Profileinstellung und Abmelden navigiert werden kann. Zudem
wird zu jeder Hauptseite die Menübar mit Sidebar dargestellt.
Elemente einer Navigation
In Abbildung 74 sind die Elemente der Navigation des BPMS dargestellt. Das Logo
befindet sich in der oberen linken Ecke des BPMS. Dieses stellt zugleich der Link
zur Ordnerübersicht dar.
ABBILDUNG 74: ELEMENTE EINER NAVIGATION
Die aktuelle Position innerhalb der Navigationshierarchie wird an Hand von
Breadcrumbs ersichtlich. Der Benutzer sieht dadurch, auf welcher Hierarchieebene
er sich aktuell befindet. Breadcrumbs befinden sich rechts neben dem Logo des
BPMS. Die Platzierung ist auf Höhe des Logos, da dies das Navigieren zwischen den
Hauptseiten, ähnlich einer globalen Navigation ermöglicht. Allein durch die Dar-
stellung eines Zurück-Pfeils kann auf den Navigationspfad nur schwer geschlossen
werden.
Link zur Ordnerübersicht
Breadcrumb
Lokale Navigation Link
Direkte Navigation
Globale Navigation
Funktionale Navigation
5 UI-Entwurf
112
Die globale Navigation befindet sich rechts oben im BPMS und ermöglicht den
Zugang zu prozessmodellübergreifenden Themen, wie Nachrichten, Store und Time-
line von Prozessmodellen. Die globale Navigation ist im BPMS durchwegs sichtbar.
Die funktionale Navigation befindet sich oben rechts in der globalen Navigation
und führt den Benutzer auf funktionale Seiten, wie Abmelden, Profileinstellungen
etc. Eine direkte Navigation ist über Buttons oder Links gewährleistet. Dadurch kann
beispielsweise von der Prozessmodellübersicht direkt auf die Prozessausführung in
der Prozessmodellansicht gesprungen werden. Zudem werden zu jedem Ordner
bzw. Prozessmodell Links zu Kommentaren und laufenden Instanzen präsentiert.
Somit kann der Benutzer schnell zu Inhalten vordringen, welche tiefer in der Hie-
rarchierungsebene verankert sind. Dies gewährleistet eine schnelle Navigation zwi-
schen Hierarchierungsebenen.
Die lokale Navigation besteht aus der Menübar mit zugehöriger Sidebar. Dabei
wird darauf geachtet, dass kein Informationsoverload vorliegt, durch zu eine hohe
Informationsstruktur [12].
ITERATIVE UI-WALKTHROUGHS
Da noch keine konkreten Endbenutzer vorliegen, werden mit Hilfe eines Usability-
Experten der iterative UI-Walkthroughs durchgeführt. Voraussetzung für einen
Usability-Experten ist, dass er über die Arbeitsabläufe und Informationsbedürfnisse
der Benutzer Bescheid weiß. Dazu versetzt er sich in die Rolle der Benutzer. Wirefra-
mes werden evaluiert, Probleme aufgedeckt und Lösungsansätze entwickelt, wie
z.B. aufwändige Interaktionsschritte oder ein unpassendes Bedienelement. Da die-
ser Prozessschritt sich nach wie vor in der Entwicklungsphase befindet, können be-
stehende Anforderungen geändert werden oder neue entwickelt werden [13].
ELEKTRONISCHE UI-PROTOTYPEN
Die Bedienelemente des UI-Entwurfs werden als Mockup-Screens umgesetzt. Dabei
fand keine Implementierung statt. Die Umsetzung erfolgt mit Hilfe des Bildbear-
beitungsprogramms Adobe Illustrator CS6. Die Mockup-Screens dienen als Vorlage
für die iterativen Usability-Tests.
5.4 Iterative Usability-Tests
113
ITERATIVE USABILITY-TESTS
In dieser Phase wird der Expertentest als Ersatz für den iterativen Usability-Test
durchgeführt. Dabei werden noch keine echten Benutzer für die Bewertung von
Entwurfsentscheidungen mit einbezogen. Die Durchführung des Usability-Tests mit
einem Usability-Experten wird dabei als Expertentest bezeichnet. Der Vorteil liegt
darin, dass der Expertentest besonders schnell und effizient ist. Dabei werden ein-
zelne Handlungsschritte der Benutzer durchlaufen. Zudem werden die Kenntnisse
und Fähigkeiten der Benutzer mitberücksichtigt [8]. Folglich können kritische
Handlungsabfolgen verbessert bzw. gebräuchliche Handlungsabfolgen freigege-
ben werden. Ob die identifizierten Punkte tatsächlich Usability-Probleme sind, ist
dabei nicht sicher feststellbar. Daher sollte der Expertentest nicht als Ersatz für den
Usability-Test gelten, sondern während der Entwicklungsphase ergänzend zum
Einsatz kommen.
UI-STYLEGUIDE
Die Ausarbeitung eines visuellen Designs (d.h. Farbkonzept, Typografie, etc…) er-
folgt schrittweise, da Aspekte wie Anforderungen, technische Einschränkungen und
Beeinflussung durch Benutzer die Komplexität erhöhen [12]. Bei der Ausarbeitung
eines passenden visuellen Designs werden Varianten erzeugt, gegenübergestellt
und das beste visuelle Design weiter ausgearbeitet.
FARBKONZEPT
Farben haben für das visuelle Design Auswirkungrn auf die Ästhetik des BPMSs.
Daher ist die Entwicklung eines guten Farbkonzepts wichtig, um die Identität des
BPMSs zu unterstreichen. Die Definition von geeigneten Farben und die Abstim-
mung von Farbnuancen ist eine grundlegende Aufgabe. Zudem spielt neben der
Farbwahl, die Anzahl von Farben und deren Verwendungszweck eine wichtige Rolle.
Für das zu entwickelnde BPMS liegen keine Vorgaben eines Corporate Designs zu
Grunde. Das Farbkonzept ist während der Entwicklung des UI-Entwurfs entstanden,
was im Folgenden beschrieben wird.
5 UI-Entwurf
114
Validation der Farbwahl
Folgende Aspekte sind bei der Entwicklung des Farbkonzepts für das BPMS be-
rücksichtigt worden, um ein schlichtes Design für ein „leichtgewichtiges BPMS“ zu
gewährleisten (siehe Anforderung ANF-1) [12]:
Beschränkung auf eine Hauptfarbe. Der Einsatz von anderen Farben ist li-
mitiert.
Für große Flächen, wie beispielsweise den Content-Bereich der Prozessaus-
führung, wird eine schwach gesättigte Farbe verwendet.
Ein hoher Kontrast bildet die Grundlage für gute Lesbarkeit.
Für jede Farbe existiert ein Verwendungszweck.
Die Farben werden nach Schrift, Hintergrund und Auszeichnungen unter-
gliedert.
Farbharmonien und Farbwahl
Das Farbbild des BPMSs soll ein freundliches und schlichtes Farbbild transportieren
(siehe Anforderung ANF-16). Aus diesem Grund kommt alleinig eine Hauptfarbe
für das BPMS zum Einsatz (siehe Abbildung 75). Die Hauptfarbe bildet die Farbe
Hellblau. Diese Farbe vermittelt Ruhe und Gelassenheit, was durch ein schlichtes
Design unterstrichen wird (siehe Kapitel 2.3.2).
ABBILDUNG 75: HAUPTFARBE, HINTERGRUNDFARBE UND FLÄCHENFARBEN
Zudem steht die Farbe Hellblau für Sympathie, Freundlichkeit und Harmonie, was
die Akzeptanz des Benutzers erhöhen soll [42]. Da das BPMS eine Cloud-Lösung
darstellt, ist die Farbe Hellblau auch als Farbe des Himmels gut geeignet. Sowohl
die Startseite für die Anmeldung, als auch die globale Navigation ist in dieser
Hauptfarbe eingefärbt. Abbildung 76 zeigt die Startseite, in der ein Teil des Hinter-
grunds in der Hauptfarbe dargestellt ist.
5.5 UI-Styleguide
115
ABBILDUNG 76: FARBWAHL AUF DER STARTSEITE
In Abbildung 77 sind die Farben der Prozessmodellansicht wiedergeben. Die glo-
bale Navigation ist alleinig in der Hauptfarbe dargestellt. Die Sidebar ist Weiß ge-
halten, da sie nicht vom Content-Bereich ablenken soll. Die Hintergrundfläche der
Menübar und der Display-Bar ist Hellgrau. Dies stellt eine gedämpfte und schwache
Farbe dar, was eine gute Farbkombination mit dem kräftigen Hellblau bildet.
ABBILDUNG 77: FARBWAHL DER PROZZMODELLANSICHT
5 UI-Entwurf
116
Eine positive Zustimmung des Benutzers durch einen Button wie z.B. Bestätigung,
Öffnen oder Speichern wird ebenfalls in der Hauptfarbe dargestellt (siehe Abbil-
dung 78).
ABBILDUNG 78: BUTTONFARBE
Dadurch wird der Benutzer in seinem Handeln bekräftigt. Folglich ist der Abbre-
chen-Button zurückhaltend, in der Farbe Weiß dargestellt. Die Analogie, Buttons
nach ihrer Funktion visuell zu untermalen, verwenden bereits andere Software
(siehe Abbildung 79).
ABBILDUNG 79: BUTTONS VON OFFICE 365 UND CLOUDDRIVE VON MICROSOFT
Für den Content-Bereich der Prozessausführung wird ein monochromatischer Farb-
klang verwendet (siehe Kapitel 2.3.2), der aus dem Hauptton der Hauptfarbe und
deren Minderung von Sättigung und Helligkeit entsteht. Abbildung 80 zeigt die
Hintergrundfarbe des Content-Bereichs in der Ausführungsansicht. Durch den Farb-
wechsel des Content-Bereichs von der Farbe Weiß auf Hellblau, wird dem Benutzer
verdeutlicht, dass er sich gerade in der Ausführungsansicht befindet. Wird die Aus-
führungsansicht geschlossen, ist der Content-Bereich wieder in der Farbe Weiß dar-
gestellt.
Die Farbe Hellblau wird auch als Selektionsfarbe und für Mouse-Over-Aktionen
verwendet, allerdings mit geringerer Sättigung (siehe Abbildung 81).
5.5 UI-Styleguide
117
ABBILDUNG 80: FARBEN DER AUSFÜHRUNGSANSICHT
ABBILDUNG 81: SELEKTIONSFARBE
Neben dem Aspekt eines freundlichen und schlichten Farbbildes zielt das BPMS,
aber auch auf den Faktor joy-of-Use (siehe Kapitel 2.2.2). Ein gutes Beispiel stellt
dabei das Windows 8-Style UI von Microsoft dar, in der bunte Farben verwendet
werden, um das System lebendiger zu gestalten. Abbildung 82 zeigt drei Farben,
welche im BPMS eingesetzt werden.
ABBILDUNG 82: SIGNALFARBEN
5 UI-Entwurf
118
Die Farbe Grün gibt Aufschluss von noch laufenden Instanzen. Sie signalisiert, dass
eine Aktivität positiv ausgeführt wurde und alles in Ordnung ist (siehe Abbildung
80). Die Farben Grün und Rot bilden mit der Farbe Blau einen triadischen Farbkreis
(siehe Kapitel 2.3.2). Orange bildet dabei die Komplementärfarbe zu Blau. Daher
werden diese Farben auch nur dezent eingesetzt. Für abgeschlossene Instanzen
wird die Farbe Rot verwendet. Prozesselemente, welche nicht im Aufgabenbereich
des Benutzers liegen, werden in der Farbe Orange eingefärbt. Sie geben dem Be-
nutzer den Hinweis, dass das Prozesselement gerade von einem anderen Benutzer
oder mehreren Benutzern bearbeitet wird.
Da die Farbe Rot die stärkste Signalwirkung beim Benutzer hervorruft, wird sie zu-
dem für fehlerhafte Eingaben oder Aktionen verwendet. Zudem kommen die Farbe
Türkis und Gelb im BPMS zum Einsatz. Diese tauchen eher sporadisch an bestimm-
ten Stellen im BPMS auf (siehe Abbildung 83).
ABBILDUNG 83: BENUTZERRECHTE UND BEWERTUNG IM STORE
Die Farbe Türkis wird ausschließlich für das Hervorheben von Benutzerrechten ein-
gesetzt, wohingegen die Farbe Gelb für die Bewertung von vorkonfigurierten Pro-
zessmodellen im Store verwendet wird (siehe Abbildung 84).
ABBILDUNG 84: FARBEN FÜR BENUTZERRECHTE UND BEWERTUNG IM STORE
Für den Fließtext wird die Farbe Schwarz verwendet. Während hingegen Texte in
Menüs in Grau dargestellt sind (siehe Abbildung 85). Zudem wird Text, welcher
5.5 UI-Styleguide
119
editierbar ist, in der Hauptfarbe (also Hellblau) dargestellt. Dadurch ist für den Be-
nutzer sofort ersichtlich, wo er Editierungsmöglichkeiten vornehmen kann.
ABBILDUNG 85: TEXTFARBEN
Neben dem Einsatz von Farben für Flächen und Texte, werden auch bestimmte
Grautöne für Icons verwendet. Dabei wird farblich zwischen aktiven und inaktiven
Icons unterschieden (siehe Abbildung 86).
ABBILDUNG 86: ICONFARBEN
Aktive Icons enthalten dabei eine kräftigere Farbe als inaktive Icons, da diese einen
aktiven Zustand suggerieren sollen. Inaktive Icons hingegen werden in einer zu-
rückhaltenden Farbe dargestellt. Des Weiteren wird das Setzen eines Prozessmo-
dellfilters in der Display-Bar optisch hervorgehoben, da dieser das Prozessmodell
in der Darstellung grundlegend ändert. Dadurch kann der Benutzer schnell erken-
nen, ob bereits in Filter gesetzt wurde oder nicht (siehe Kapitel 2.4.3). Abbildung
87 zeigt den gesetzten Prozessmodellfilter Meine Aufgaben an.
ABBILDUNG 87: FILTERFARBE UND AUSSCHNITT AUS DISPLAY-BAR
5 UI-Entwurf
120
AFFORDANCE VON INTERAKTIONSELEMENTEN
Hinweise, welche Aufschluss auf die Nutzung von Interaktionselementen geben,
werden als Affordance bezeichnet. Interaktionselemente sollen dem Benutzer auf
den ersten Blick suggerieren, wie sie zu bedienen sind. Aus diesem Grund finden
sich im visuellen Design der Einsatz von Tiefenwirkung, sowie die Angabe einer Be-
wegungsrichtung durch die richtige Formgebung wieder. Da die Affordance Aussa-
gen zur Bedienung eines Interaktionselements gibt, ist sie für die Erreichung einer
guten Usability (siehe Kapitel 2.2.1) entscheidend. Dieser Aspekt wird zudem in der
Norm Selbstbeschreibungsfähigkeit festgehalten (siehe Kapitel 2.4.2).
Eine Tiefenwirkung wird durch Licht und Schatten erzeugt. Da für gewöhnlich das
Licht von oben kommt, wie z.B. bei der Sonne, wird Helligkeit als ein Vorsprung
wahrgenommen. Hingegen hat die Dunkelheit einen Vertiefungseffekt. Dieser As-
pekt wird auch bei den Interaktionselementen des BPMSs angewendet. Folglich ist
ein angewählter Button in einem dunkleren Grau dargestellt, um den Benutzer zu
verdeutlichen, dass dieser selektiert wurde. Zudem wird sich dem Gesetz der Präg-
nanz zu Eigen gemacht, da Elemente, welche sich von anderen optisch abheben,
zuerst wahrgenommen werden (siehe Kapitel 2.3.1). Dadurch ist es für den Benutzer
schnell ersichtlich, welchen Button er bereits angewählt hat. Der angewählte Me-
nüpunkt in der Display-Bar für die Prozessausführung wird, wie in Abbildung 88,
visuell mit Hilfe der Tiefenwirkung untermalt. Das heißt, die Buttonfläche wird in
Grau und das Icon in Schwarz dargestellt.
ABBILDUNG 88: TIEFENWIRKUNG VON BUTTONS
Der Rahmen der Sidebar zu einem angewählten Menüpunkt wirft einen Schatten,
was bedeutet [12], dass er hervorsteht bzw. über dem Content-Bereich liegt.
Die richtige Formgebung gibt ebenfalls einen Hinweis, wie Interaktionselemente
genutzt werden können. Eine eckige Schaltfläche suggeriert drücken. Folglich sind
Buttons im BPMS als Rechtecke dargestellt. Anzeigeelemente, wie beispielsweise
ein Textfeld sind ebenfalls rechteckig aufgebaut. Zusätzlich werden Textfelder mit
5.5 UI-Styleguide
121
Wasserzeichen dargestellt, was den Benutzer als Anleitung für die Eingabe und Art
von Text unterstützt.
Der Zoom besitzt einen Kreis als Regler, welcher an einer Bahn zwischen minimalen
und maximalen Zoom verschoben werden kann [12] (siehe Abbildung 89).
ABBILDUNG 89: ZOOM-REGLER
Die Schieberegler in der Timeline, welche die Zeitspanne der Anzeige der Historie
von Prozessmodellen und Instanzen bestimmt, suggerieren durch ihre äußere Form
und Gestaltung ihre Funktionalität [43]. Die Schieberegler sind durch vertikale Li-
nien, welche eine raue Oberfläche darstellen sollen, gestaltet. Dem Benutzer ist
dadurch ersichtlich, dass Schieberegler hin-und her bewegt werden können (siehe
Abbildung 90).
ABBILDUNG 90: SCHIEBEREGLER DER TIMELINE
TYPOGRAPHIE
Bei der Entwicklung eines typographischen Konzepts für das BPMS wird darauf ge-
achtet, dass Schriften konsistent eingesetzt werden.
Die Schriftart bildet die Grundlage der Typographie. Generell unterscheidet sich
diese durch die Weite und Lage der einzelnen Zeichen, sowie durch ihre Stärke [12].
Des Weiteren ist sie meist durch Schriftschnitte, wie kursiv, fett und schmal ange-
reichert. Diese bilden zusammen die Schriftfamilie. Da die Schriftart auf Bildschir-
men eingesetzt wird, muss sie dazu auch ausgelegt sein. Aus diesem Grund wird
für das BPMS die Schriftart Arial verwendet, da sie serifenlos ist [44] und auch in
kleiner Schriftgröße gut lesbar ist. Einen weiteren Aspekt bildet die Schriftgröße für
5 UI-Entwurf
122
eine gute Lesbarkeit. Je nach Einsatzgebiet im BPMS der Schriftart, findet eine an-
dere Schriftgröße Verwendung. Überschriften und Titel werden im BPMS mit deut-
lich über 12 Punkt, genauer gesagt mit 22 Punkt dargestellt. Hingegen wird der
Mengentext in der normalen Lesegröße von 12 Punkt gesetzt. Anmerkungen wie
z.B. das Ausführungsdatum und Benutzername einer Instanz, werden gelegentlich
in 11 Punkt dargestellt.
Um die Sidebar für den Benutzer leichter erfassbar zu machen, werden einzelne
Untermenüs als Überschriften definiert, welche überwiegend aufgeklappt werden
können. Diese sind nach ihrer Funktionalität gegliedert. In der Sidebar der Prozess-
ausführung werden beispielsweise laufende und abgeschlossene Instanzen unter-
gliedert. Um einzelne Wörter hervorzuheben, werden verschiedene Schriftschnitte
verwendet. So ist beispielsweise der Name einer Instanz und das Ausführungsda-
tum mit dem Schriftschnitt fett dargestellt, um diese stärker hervorzuheben.
ICON-DESIGN
Icons vermitteln in einer einfachen Darstellung Informationen, z.B. Hinweise oder
Instruktionen, benötigen weniger Platz und sind zudem sprachneutral (siehe Ab-
bildung 91) [12]. Daher werden sie für die Menübar verwendet, da Begriffe wie
Prozessausführung oder Prozessmodelleditierung zu lang wären.
ABBILDUNG 91: ICONS VON MENÜBAR
Die Icons der Menübar erhöhen durch ihre einprägsame Form zudem den Wieder-
erkennungswert. Jedes Icon hat dabei seine feste Bedeutung. Daher ist es auch
wichtig, dass in einem Usability-Test überprüft wird, ob jedes Icon richtig interpre-
tiert wird (siehe Kapitel 6).
Im BPMS werden einige suggestive Icons, verwendet, welche eine bestimme Aktion
empfehlen, wie z.B. ein Icon für Schließen, um die Prozessausführung zu beenden
(siehe Abbildung 92).
5.5 UI-Styleguide
123
ABBILDUNG 92: ALLGEMEINE ICONS
Indikative Icons, welche einen Indiz vermitteln, werden für die Fortschrittanzeige
von Prozessmodellen verwendet. Ein halbgefüllter Kreis in der Prozessausführung
weist darauf hin, dass das Prozessmodell bereits zur Hälfte ausgeführt wurde (siehe
Abbildung 93).
ABBILDUNG 93: FORTSCHRITTANZEIGE VON PROZESSMODELLEN
Zudem werden im BPMS auch imperatives Icons verwendet, welche ein bestimmtes
Verhalten vorschreiben. So wird das Fertigstellungsdatum von Prozessmodellen im
BPMS mit einer Deadline von einer Woche mit einem Warnsymbol versehen.
Dadurch soll der Benutzer aufgefordert werden, dass dieses Prozessmodell abge-
arbeitet werden sollte (siehe Abbildung 94).
ABBILDUNG 94: ICONS FÜR FERTIGSTELLUNGSDATUM
Generell wird bei der Gestaltung von Icons für das BPMS darauf geachtet, dass sie
möglichst einfach und prägnant gestaltet sind. Folglich bauen sie auf einfachen,
geometrischen Grundformen auf. Auf Effekte wie Glanz oder Schatten wird verzich-
tet, um ein zurückhaltendes, minimalistisches Design gewährleisten zu können
(siehe Anforderung ANF-1). Dieser Ansatz wird als Flat-Design bezeichnet, d.h. es
wird der Ansatz weniger ist mehr verfolgt. Demzufolge wird auf eine realistische
Darstellung verzichtet, welche beispielsweise durch den Einsatz von Texturen und
Verzierungen realisiert wird. Im Fokus steht die Gestaltung zu reduzieren und sich
5 UI-Entwurf
124
auf das Wesentliche zu beschränken [45]. Abbildung 95 zeigt Icons des BPMS, wel-
che für die globale Navigation eingesetzt werden.
ABBILDUNG 95: ICONS VON GLOBALER NAVIGATION
Das Icon für den Store, stellt dabei eine Einkaufstasche dar, welche mit dem BPMS-
Logo versehen ist. Durch die Kombination mit dem Logo, wird dem Benutzer ver-
deutlicht, dass diese vorkonfigurierten Prozessmodelle für das BPMS eingesetzt
werden können.
In der Ordnerübersicht werden Ordner mit einem kleinen Icon links unten im Eck
des Ordners versehen. Dadurch ist dem Benutzer ersichtlich, ob es sich um private
oder geteilte Ordner handelt. Das Icon Private bildet einen einzelnen Benutzer ab
und das Icon Geteilt folglich mehrere Benutzer (siehe Abbildung 96). Dabei wurde
für das Icon Teile das Icon Private mehrmals wieder verwendet und unterschiedlich
skaliert. In der Ordner- und Prozessmodellübersicht werden zum Ordner bzw. zum
Prozessmodell jeweils rechts unten im Eck zusätzlich ein Icon für Kommentare mit
Anzahl angezeigt.
ABBILDUNG 96: ORDNER- UND PROZESSMODELLINFORMATION
Die gleiche Analogie wird auch für das Icon Ordner bzw. das Icon Prozess für die
Ordner- bzw. Prozessmodellübersicht, genutzt. Das Icon Ordner besteht aus drei
Icons Prozess, welche in Anordnung und Größe variieren (siehe Abbildung 97).
ABBILDUNG 97: VORSCHAU-ICONS
5.5 UI-Styleguide
125
Das Icon Privat und Icon Geteilt schließen dabei horizontal ab, damit sie mit der
Ordner- und Prozessmodellvorschau bündig an einer Linie platziert werden können
(siehe Abbildung 98).
ABBILDUNG 98: ORDNER MIT ORDNER-, PRIVAT- UND KOMMENTARICON
Da bereits Icons für die Transit-Map und die BPMN bereits bestehen (siehe Abbil-
dung 99), ist es nicht einfach ein Vorschauicon für Ordner bzw. ein Prozessmodell
zu erstellen. Da die Transit-Map generell vertikal verläuft, also von oben nach unten
und die BPMN horizontal, von links nach rechts, verbindet das Icon für einen Ord-
ner bzw. Prozess beide Ansätze miteinander.
ABBILDUNG 99: ICONS DER DISPLAY-BAR
Bei der Vergabe von Benutzerrechten, kann eine Auswahl getroffen werden zwi-
schen View, Edit und Run (siehe Abbildung 100). Dabei stellen diese Icons, nicht nur
einen Platzhalter dar, welche Informationen vermitteln, sondern sind analog zu Ra-
dio-Buttons anwählbar.
ABBILDUNG 100: ICONS FÜR BENUTZERRECHTE
Durch Mausklick auf ein Icon für Benutzerrechte, wird dieses ausgefüllt dargestellt
und verdeutlicht dem Benutzer, welches Benutzerrecht aktuell gesetzt ist.
Neben dem Auslösen von Aktionen, können Icons auch als Prozesselemente für
das Prozessmodell ihren Einsatz finden. Abbildung 101 und Abbildung 102 zeigen
5 UI-Entwurf
126
dabei unspezifische und vorkonfigurierte Prozesselemente, welche durch eine
Drag-&-Drop-Aktion bewegt und in das Prozessmodell eingefügt werden können.
ABBILDUNG 101: UNSPEZIFISCHE PROZESSELEMENTE
Die Strichstärke der unspezifischen Prozesselemente ist stets konstant. Auch die
Pfeilspitze des leeren Zweigs und der Schleife sind in ihrer Darstellung und Größe
identisch. Dadurch wird ein ruhiges Erscheinungsbild des Prozessmodells gewähr-
leistet.
ABBILDUNG 102: VORKONFIGURIERTE PROZESSELEMENTE
Für das Hinzufügen von Benutzerrechten für ein Prozessmodell (d.h. Access-Rights)
bzw. eine Aktivität (d.h. Assigned Users) stehen verschiedene Arten von Benutzern
bereit. Dazu gehört ein einzelner Benutzer, ein Gruppe, ein Benutzer, welche eine
Rolle einnehmen kann und eine Organisation (siehe Abbildung 103).
ABBILDUNG 103: ARTEN VON BENUTZERN
Bei der Gestaltung von Icons, welche die Arten von Benutzern beschreiben, findet
das Icon für einen einzelnen Benutzer, sich in den anderen Icons wieder. Dadurch
weiß der Benutzer, dass es sich im Kontext generell um Benutzer handelt. Bei der
Darstellung des Icons für eine Gruppe befinden sind alle abgebildeten Benutzer na-
hezu auf einer horizontalen Linie abgebildet, da hier keine hierarchische Beziehung
besteht. Dieser Ansatz findet sich im Organisations-Icon wieder. Eine Rolle wird
5.5 UI-Styleguide
127
durch den Buchstaben R repräsentiert, abgeleitet vom englischen Wort Role. Dieses
Analogie findet sich auch in dem Icon einer Aktivität (siehe Abbildung 101) wieder.
Für Einstellungen werden ebenfalls Icons benötigt, welche komplexe Datentypen,
ein Plug-in oder Typen von Selektor repräsentieren. In Abbildung 104 besteht das
Icon für den komplexen Typ aus mehreren Ellipsen, um zu verdeutlichen, dass dieser
aus mehreren Parametern zusammengesetzt ist und das Sinnbild der Komplexität
verdeutlicht wird.
ABBILDUNG 104: KOMPLEXE TYPEN
Da ein Plug-in, bereits im Namen das Verb Plug-in beinhaltet, was übersetzt an-
schließen bedeutet, wird das Plug-in-Icon als Puzzleteil dargestellt. Dies versinn-
bildlicht, dass das Plug-in in das BPMS eingebunden werden kann.
Standard-Icons, welche in anderen Systemen häufig verwendet werden und vom
Benutzer folglich wiedererkannt werden, finden auch ihren Einsatz im BPMS wieder.
Dazu gehört das Datum-Icon, welches einen Kalender repräsentiert (siehe Abbil-
dung 105). Dieses Icon findet sich in anderen Systemen in unterschiedlicher Aus-
führung ebenso wieder.
ABBILDUNG 105: STANDARD-ICONS
Neben Icons, welche durchgehend im BPMS aufgeführt sind, finden sich auch Icons
wieder, welche nur On-Demand, durch Auslösen einer bestimmten Aktion ange-
zeigt werden. Möchte der Benutzer ein Prozesselement im Prozessmodell durch ein
anderes ersetzen, erscheint ein Icon, welches das Ersetzen andeutet (siehe Abbil-
dung 106). Dadurch ist dem Benutzer ersichtlich, dass das Prozesselement bei der
Drag-Aktion das darunterliegende Prozesselement ersetzt.
5 UI-Entwurf
128
ABBILDUNG 106: ICON FÜR ERSETZEN EINER AKTIVITÄT
In der Display-Bar befindet sich das Zoom-Steuerelement (siehe Abbildung 107),
welches aus einem kreisförmigen Schieberegler und zwei Icons, nämlich dem Ver-
kleinern-Icon und dem Vergrößern-Icon bestehen. Dabei bestehen das Verkleinern-
Icon und das Vergrößern-Icon beide aus vier Vierecken, welche sich lediglich in der
Größe unterscheiden (siehe Abbildung 107).
ABBILDUNG 107: VERKLEINERN-ICON UND VERGRÖßERN-ICON DES ZOOM-REGLERS
Da Ordner und Prozessmodelle in der Ordner- bzw. Prozessmodellübersicht aus
Rechtecken und das Prozessmodell u. A. aus viereckigen Aktivitäten besteht, wird
durch den Zoom sinnbildlich die Größe der Rechtecke verändert. Aus diesem Grund
finden sich im Zoom für das Verkleinern-Icon und das Vergrößern-Icon Vierecke
als geometrische Figur wieder.
DETAILENTWURF
Im Folgenden wird die fertige Ausarbeitung des UI-Entwurfs vorgestellt, in welche
die Entwurfsoptimierungen des Usability-Test (siehe Kapitel 6.5) bereits berück-
sichtigt sind. Das Ergebnis des UI-Entwurfs wird an Hand von Screens vorgestellt,
welche je ein Hauptfenster darstellen. Dabei wird jeder Screen kurz erläutert und
Design-Entscheidungen diskutiert.
ANMELDUNG AN DAS BPMS
Das Erscheindungsbild des UI-Entwurfs ist flach, d.h. im sogenannten Flat -Design
umgesetzt [46].
5.6 Detailentwurf
129
ABBILDUNG 108: ANMELDEN
Dabei ist auf den Skeuomorphimus komplett verzichtet, was bedeutet, dass
Funktionsweisen oder Formen einer Benutzeroberfläche ähnlich wie in der Realität
gestaltet werden. Im Gegensatz dazu wird im UI-Entwurf des BPMSs auf ein
schlichtes und übersichtliches Design (siehe Anforderung ANF-1) wertgelegt.
Folglich wird der Anmelde-Screen in einer großen, einfachen Farbfläche, nämlich
der Hauptfarbe des BPMSs, dargestellt. Abbildung 108 zeigt den Screen bei
Anmeldung an das BPMS.
ORDNERÜBERSICHT
Das visuelle Design ist generell hell und einfach gehalten. Dies zeigt Abbildung 109,
in der die Ordner in der Ordnerübersicht auf weißem Hintergrund präsentiert sind.
Farben hingegen werden vereinzelt und intensiv verwendet.
5 UI-Entwurf
130
ABBILDUNG 109: ORDNERÜBERSICHT
Die globale Navigation ist beispielsweise in der Hauptfarbe Hellblau gestaltet.
Durch den gezielten Einsatz von Farben, ist die Aufmerksamkeit des Benutzers ge-
lenkt werden. Folglich ist die Anzahl an laufenden Instanzen zu den jeweiligen Ord-
nern in einem satten Grün dargestellt.
Ein Ordner beinhaltet mehrere Prozessmodelle bzw. Dashboards oder Tabellen mit
Laufzeitinformationen. Dieser Aspekt ist visuell durch das Andeuten von mehreren
Prozessmodellen verdeutlicht (siehe Abbildung 110). Zudem werden für den Rah-
men des Ordners bzw. des Prozessmodells klare, einfache Linien verwendet.
ABBILDUNG 110: ORDNER- UND PROZESSMODELLVORSCHAU
5.6 Detailentwurf
131
Der Rahmen der Sidebar ist ebenfalls durch klare Linien eingefasst. Zudem besitzt
dieser eine Schattierung, um zu verdeutlichen, dass er über den Content-Bereich
liegt. Des Weiteren ist dadurch eine genaue Abgrenzung zwischen Content-Bereich
und Sidebar gegeben. Die Zugehörigkeit der Sidebar zur Menübar wird durch das
Gesetzt der Nähe verstärkt (siehe Kapitel 2.3.1), da die Sidebar direkt unterhalb der
Menübar positioniert ist. Zudem ist durch einen Hinweispfeil der Sidebar die Zuge-
hörigkeit zum angewählten Menüpunkt deutlich (siehe Abbildung 111).
Da Buttons im BPMS ohne Schattierung bzw. Abhebung dargestellt sind, müssen
sie dem Benutzer trotzdem suggerieren, dass sie anklickbar sind. Folglich sind But-
tons im BPMS visuell durch Farben hervorgehoben. Buttons, wie beispielsweise für
Öffnen, Speichern oder Kaufen, sind farbig gestaltet. Buttons, welche eine Aktion
abbrechen, sind alleinig durch einen Rahmen eingefasst. Die Sidebar Editieren und
Prozessausführung in der Ordnerübersicht ist nahezu analog zur Prozessmodell-
übersicht aufgebaut und wird daher im folgenden Kapitel 5.6.3 vorgestellt.
ABBILDUNG 111: ORDNERÜBERSICHT MIT SIDEBAR
5 UI-Entwurf
132
PROZESSMODELLÜBERSICHT
Nachdem Öffnen eines Ordners, werden dem Benutzer alle Inhalte wie Prozessmo-
delle, Dashboards und Tabellen dem Benutzer offengelegt (siehe Abbildung 112).
Die Prozessmodellübersicht ist analog zur Ordnerübersicht aufgebaut (siehe Anfor-
derung ANF-5). Durch diesen konsistenten Aufbau muss sich der Benutzer nicht
neu orientieren, da alle Funktionalitäten, wie die Menübar und die Display-Bar, an
der gleichen Stelle aufzufinden sind Dies gewährleistet eine gute Erwartungskon-
formität (siehe Kapitel 2.4.2).
Die Menübar zeigt alleinig Icons an. Da die Menübar aus maximal vier Menüpunk-
ten besteht, kann der Benutzer diese gut auseinanderhalten. Jedes Icon symboli-
siert dabei die Funktionalität, welche die Sidebar bereitstellt.
ABBILDUNG 112: PROZESSMODELLÜBERSICHT
Ist die Bedeutung des Icons erlernt, erleichtert ein Menü nur mit Icons eine Inter-
pretation ohne zusätzliches Lesen von Menüpunktbeschriftung. Dadurch ist eine
5.6 Detailentwurf
133
leichte Wiedererkennung gegeben [47]. Des Weiteren wird der Gedächtnisspeicher
entlastet (siehe Kapitel 2.4.3). Beim Erstellen eines neuen Prozessmodells hat der
Benutzer die Auswahl, ob er ein neues Prozessmodell erstellen möchte oder bereits
ein vorkonfiguriertes Prozessmodell kaufen möchte (siehe Abbildung 113).
Dadurch wird dem Benutzer die Entscheidung gelassen, was das Gefühl des Ein-
flusses und der Verantwortung zu übernehmen stärkt (siehe Kapitel 2.3.3).
ABBILDUNG 113: PROZESSMODELL ANLEGEN IN DER PROZESSMODELLÜBERSICHT
Prozessmodelle in der Prozessmodellübersicht können individuell nach den Bedürf-
nissen des Benutzers angepasst werden. Abbildung 114 stellt die Sidebar zum Edi-
tieren von Eigenschaften eines Prozessmodells in der Prozessmodellübersicht dar.
Durch das Bilden von Hierarchien, wird die Sidebar strukturiert. Eigenschaften stel-
len dabei die oberste Hierarchiestufe dar, in welcher Inhalte als klappbare Unter-
menüs zugänglich gemacht werden.
5 UI-Entwurf
134
Ein selektiertes Prozessmodell wird in der Sidebar unterhalb von Eigenschaften
nochmals dargestellt, um dem Benutzer visuell zu verdeutlichen, welches Prozess-
modell aktuell bearbeitet werden kann. Ein Prozessmodell wird durch ein Icon vi-
suell von anderen differenzierbar gemacht und eine Prozessmodellbeschreibung
gibt weitere Aufschlüsse zum Prozessmodell (siehe Anforderung ANF-8).
ABBILDUNG 114: PROZESSMODELL EDITIEREN IN PROZESSMODELLÜBERSICHT
Durch das Ausblenden von bestimmten Funktionen, wird der Fokus auf den rele-
vanten Teil der Funktionen gelenkt. Funktionen, wie z.B. das Löschen oder die An-
zeige von Zusatzinformationen, werden daher erst bei Mouse-Over angezeigt. In
Abbildung 115 werden Benutzerrechte zum Prozessmodell Reiseantrag dargestellt.
Bei Mouse-Over werden alle Benutzerrechte, welche durch Mausklick gesetzt wer-
den können, eingeblendet. Zudem können Benutzerrechte gelöscht werden.
5.6 Detailentwurf
135
ABBILDUNG 115: ACCESS-RIGHTS LÖSCHEN VON PROZESSMODELL
ABBILDUNG: 116 ACCESS-RIGHTS HINZUFÜGEN
Beim Hinzufügen von Benutzerrechten wird dem Benutzer ein Untermenü ange-
zeigt, in dem Zugriffs-Rechte an neue Benutzer vergeben werden können. Das Un-
termenü wird als Pop-up-Menü unterhalb des Hinzufügen-Buttons innerhalb der
5 UI-Entwurf
136
Sidebar angezeigt (siehe Abbildung: 116). Da ein Mouse-Over oder eine Selektion
durch eine Maus generell durch einen hellblauen Selektionsbereich unterstrichen
wird, wird ein ausgewählter Benutzer ebenfalls durch einen Selektionsbereich her-
vorgehoben.
In Abbildung 117 wird bei der Selektion eines Prozessmodells in der Prozessmo-
dellübersicht, ein Öffnen-Button und ein Run-Button auf dem Prozessmodell dar-
gestellt.
ABBILDUNG 117: SIDEBAR RUN IN PROZESSMODELLÜBERSICHT
Diese dienen als direkte Navigation auf die Prozessmodellansicht bzw. die Prozess-
ausführung. Der Run-Button ist in der gleichen Farbe wie die Anzahl an laufenden
Instanzen eingefärbt, um den Benutzer zu verdeutlichen, dass durch einen Maus-
klick auf den Run-Button die Prozessausführung gestartet werden kann. Elemente,
welche die gleiche Farbe besitzen, werden vom Auge als zusammengehörig gese-
hen (siehe Kapitel 2.3.1).
5.6 Detailentwurf
137
Drop-down-Menüs, welche in der Sidebar der Prozessausführung als Filter für In-
stanzen dienen, werden als Rechtecke ohne Füllfarbe dargestellt. Die Ausrichtung
des Pfeils nach oben bzw. unten, deutet daraufhin, ob es sich um ein Drop-up-Menü
oder ein Drop-down-Menü handelt.
Das gleichzeitige Löschen bzw. Teilen von mehreren Prozessmodellen ermöglicht
dem Benutzer eine schnellere Bedienung, da er nicht jedes Prozessmodell einzeln
selektieren und bearbeiten muss (siehe Kapitel 2.4.3).
ABBILDUNG 118: MEHRFACHSELEKTION VON PROZESSMODELLEN
In der Sidebar wird oberhalb der angezeigten Eigenschaften jeweils der Name des
Prozessmodells aufgeführt, sowie wird die Anzahl an ausgewählten Prozessmodel-
len, damit der Benutzer nachv0llziehen kann, wie viel Prozessmodelle aktuell selek-
tiert sind.
5 UI-Entwurf
138
PROZESSMODELLANSICHT
In der Prozessmodellansicht ist das Prozessmodell initial in der Darstellungsart
BPMN angezeigt. Die Sidebar zur Menübar ist dabei standardmäßig eingeklappt,
dadurch wird der Fokus auf den Content-Bereich mit dem Prozessmodell gelegt.
Prozesselemente
Für die Prozessmodellierung sind in der Sidebar Prozesselemente aufgeführt.
ABBILDUNG 119: PROZESSELEMENTE IN DER PROZESSMODELLANSICHT
Vorkonfigurierte Prozesselemente (Task Templates) sind unterhalb der unspezifi-
schen Prozesselemente dargestellt, da diese weniger oft genutzt werden. Prozes-
selemente können aus der Sidebar heraus, durch eine Drag-&-Drop-Aktion ins Pro-
zessmodell gezogen werden. Alternativ wird dem Benutzer bei Mouse-Over über
einen Zweig im Prozessmodell ein Plus-Icon dargestellt. Durch Mausklick auf das
Plus-Icon erscheint ein Pop-up-Menü mit unspezifischen Prozesselementen darge-
5.6 Detailentwurf
139
stellt (siehe Abbildung 120). Dabei werden nur unspezifische Prozesselemente an-
gezeigt, um eine überschaubare Anzahl an Prozesselementen im Pop-up-Menü ge-
währleisten zu können. Nach Auswahl eines Prozesselements, wird es an die Stelle,
wo das Plus-Icon sich befindet, eingefügt.
ABBILDUNG 120: POP-UP-MENÜ MIT UNSPEZIFISCHEN PROZESSELEMENTEN
Editieren eines Prozessmodells
Eigenschaften einzelner Prozesselemente umfassen das Hinterlegen von Beschrei-
bungen, Anhängen und Benutzerrechten (siehe Anforderung ANF-9). Zudem erhält
der Benutzer Feedback, welche Datenelemente (sogenannte Business Objects) be-
reits in der Aktivität hinterlegt sind (siehe Abbildung 121).
ABBILDUNG 121: SELEKTION EINER AKTIVITÄT
5 UI-Entwurf
140
Der Aufbau der Sidebar ist dabei analog zur Sidebar für die Editierung eines ganzen
Prozessmodells aufgebaut (siehe Anhang H). Das selektierte Prozesselement wird
zusätzlich in der Sidebar unterhalb von Eigenschaften angezeigt, damit der Benut-
zer weiß, welches Prozesselement bearbeitet wird. Zusätzlich ist es in der Farbe
Hellblau umrahmt.
Prozessausführung
In der Sidebar zur Prozessausführung kann über Filter die Anzeige von laufenden
und abgeschlossenen Instanzen reduziert werden (siehe Anforderung ANF-10). Der
Anzeigebereich kann von allen laufenden Instanzen auf einen Ordner bis zum Pro-
zessmodell heruntergebrochen werden (siehe Abbildung 122).
ABBILDUNG 122: SIDEBAR DER PROZESSAUSFÜHRUNG
Neben einer detaillierten Beschreibung der Instanz (d.h. Datum und Name des Be-
nutzers), wird ein Icon für den Fortschritt angezeigt. Aktuell laufende Instanzen
5.6 Detailentwurf
141
werden mit einer grünen Anzeige des Fortschritts angezeigt. Eine Anzeige des Fort-
schritts in Orange signalisiert, dass die Bearbeitung der Instanz aktuell nicht im
Aufgabenbereich des Benutzers liegt. Abgeschlossene Instanzen werden mit einer
roten Fortschrittsanzeige dargestellt. Das Fertigstellungsdatum wird mit einem ro-
ten Warnsymbol dargestellt, wenn die Frist von einer Woche gegeben ist. Ansons-
ten wird das Fertigstellungsdatum initial mit einem Icon als Uhr dargestellt. Bei
Mouse-Over über den Bereich Neue Instanz erstellen, wird dem Benutzer ein Text-
feld für den Instanznamen angezeigt. Durch Vergabe eines Instanznamen oder
durch Mausklick auf den Button, welcher ein grüner Kreis mit Play-Symbol darstellt,
wird eine neue Instanz erstellt.
Des Weiteren kann eine Instanz direkt über den Startknoten des Prozessmodells
gestartet werden. Bei Mouse-Over über den Startknoten im Prozessmodell wird
dem Benutzer der gleiche Button (grüner Kreis mit Playsymbol) wie bereits in der
Sidebar zur Prozessausführung sichtbar gemacht (siehe Abbildung 123). Durch
Mausklick auf den Run-Button, kann eine Instanz des Prozessmodells erstellt. Durch
die Verwendung von gleichen Buttons und einem zusätzlichen Tool-Tip, welcher
den Benutzer über die Funktionalität informiert, wird dem Benutzer die Funktiona-
lität schnell ersichtlich. Nach dem Erstellen einer Instanz wird die gestartete Instanz
zu den bereits laufenden Instanzen eingeordnet.
ABBILDUNG 123: INSTANZ ÜBER PLAY-BUTTON ERSTELLEN
Der Content-Bereich ist in Hellblau dargestellt, um zu verdeutlichen dass sich der
Benutzer sich gerade in der Ausführungsansicht befindet (siehe Abbildung 124).
Abgearbeitete Prozesselemente werden mit der Farbe Grün dargestellt. Zudem
5 UI-Entwurf
142
sind Prozesselemente, welche nicht im Aufgabenbereich des Benutzers liegen, mit
der Farbe Orange eingerahmt und können vom Benutzer nicht bearbeitet werden.
ABBILDUNG 124: INSTANZ IN AUSFÜHRUNGSANSICHT
Mittels Mausklick auf das Prozesselement, kann der Benutzer die Ausführung des
Prozessmodells schrittweise vornehmen. Analog dazu passt sich die Anzeige des
Fortschritts an. Durch die Sichtbarkeit des Fortschritts bekommt der Benutzer un-
mittelbar Feedback, wie weit er bereits mit der Ausführung fortgeschritten ist (siehe
Kapitel 2.4.3).
Trifft der Benutzer auf ein XOR-Gateway, wird die Auswahl des auszuführenden
Pfads über ein Pop-up-Menü mit Buttons realisiert (siehe Abbildung 124). Die Aus-
führungsansicht wird über den Button „x“, welcher sich rechts oben im Selektions-
bereich der Instanz in der Sidebar befindet, geschlossen.
Weitere Eigenschaften zu einer Instanz können über den Button „i“, welcher für
Information steht, abgefragt werden (siehe Abbildung 125). Wählt der Benutzer
5.6 Detailentwurf
143
diesen an, wir ein Untermenü für Kommentare und Anhänge sichtbar. Zudem ist ein
roter Button mit der Aufschrift cancel Instanz präsentiert. Über diesen Button kann
eine laufende Instanz abgebrochen werden, welche anschließend zu den abge-
schlossenen Instanzen eingeordnet wird.
ABBILDUNG 125: INFORMATIONEN ZUR INSTANZ
Datenelemente
Datenelemente werden als Rechtecke mit Name in der Sidebar dargestellt. Ähnlich
dem Windows 8-style UI von Microsoft, in der Apps als farbige Kacheln dargestellt
sind, werden die Datenelemente ebenfalls farbig hervorgehoben (siehe Abbildung
126). Bei Mouse-Over über ein bereits hinterlegtes Datenelement, werden einge-
hende bzw. ausgehende Datenkanten präsentiert. Der Benutzer kann dadurch ex-
plorativ erkunden, wo er bereits Datenelemente hinterlegt hat. Datenkanten sym-
bolisieren dabei den Datenfluss, welcher zwischen den Prozesselementen und den
Datenelementen stattfinden. Generell können Datenelemente gelesen und ge-
schrieben werden (siehe Anforderung ANF-11). Datenkanten, welche zu Prozessele-
mente führen, stellen dabei lesende Datenelemente dar. Datenkanten, welche zu
den Datenelementen wegführen, repräsentieren schreibende Datenelemente. Ak-
tivitäten, welche keine eingehenden oder ausgehenden Datenkanten enthalten,
werden im Prozessmodell ausgegraut dargestellt. Dadurch wird der Fokus auf Pro-
zesselemente gelegt, in der ein Datenfluss stattfindet.
5 UI-Entwurf
144
ABBILDUNG 126: SIDEBAR ZU DATEN
Das Setzen einer schreibenden oder lesenden Datenkante, erfolgt über eine Drag-
& Drop-Aktion der kleinen, kreisrunden „Anfassern“, welche sich an den aus-bzw.
eingehenden Datenkanten befinden.
Bei Mouse-Over über ein Datenelement werden zwei Buttons angezeigt. Durch
Mausklick des Buttons „i“, werden Informationen zum Datenelement angezeigt. Das
Datenelement vergrößert sich auf die Breite der Sidebar (siehe Abbildung 127).
Über Textfelder können bereits Standardwerte gesetzt werden. Das Löschen des
Datenelements bzw. das Schließen ist über die Buttons rechts oben im Datenele-
ment realisierbar.
ABBILDUNG 127: INFORMATIONEN ZUM DATENELEMENT
Über den Löschen-Button, werden dem Benutzer alle Eingabe- und Ausgabepara-
meter dargestellt, welche jeweils gelöscht werden können (siehe Abbildung 128).
5.6 Detailentwurf
145
ABBILDUNG 128: DATENELEMENT LÖSCHEN
Können bei der Vergabe einer lesenden bzw. schreibenden Datenkante mehrere
Parameter vergeben werden, wird ein Pop-up-Menü mit Buttons zu den jeweiligen
Parametern angezeigt, in welcher der Benutzer eine Auswahl treffen kann (siehe
Abbildung 129).
Unterhalb der bereits hinterlegten Datenelemente befindet sich ein Hinzufügen-
Button. Über einen Mausklick auf den Hinzufügen-Button, wird eine Liste von Da-
tenelementen als Pop-up-Menü dargestellt (siehe Abbildung 130).
ABBILDUNG 129: DATENKANTE SETZEN
Mittels Vergabe des Namens des Datenelements und Auswahl eines Datenele-
ments durch Selektion, wird ein neues Datenelement angelegt. Das ausgewählte
Datenelement wird unterhalb der bereits hinterlegten Datenelemente angezeigt.
5 UI-Entwurf
146
ABBILDUNG 130: DATENELEMENT HINZUFÜGEN
STORE
Der Store kann sowohl über die Sidebar als auch die globale Navigation erreicht
werden. Wird auf das Store-Icon geklickt, legt sich der Dialog des Stores global
über den zuletzt geöffneten Dialog. Zudem wird ein Hinweispfeil zum selektierten
Store-Icon dargestellt (analog zur Sidebar). Der Store kann über den Button „x“,
geschlossen werden und der Benutzer befindet sich wieder auf der zuletzt geöff-
neten Ansicht. Eine Bewertung mittels einer fünf-stufigen -Skala und die Anzeige
des Preises beschreiben das Prozessmodell detaillierter (siehe Anforderung ANF-
12). Möchte der Benutzer ein Prozessmodell kaufen oder sich weitere Informatio-
nen zum Prozessmodell einholen, selektiert er mit einem einfachen Mausklick das
Prozessmodell (siehe Abbildung 131). In der aufgeklappten Sidebar werden die Ei-
genschaften des Prozessmodells (Prozessmodellbeschreibung, Bewertung, Anzahl
an Downloads), sowie die Anzeige von bereits hinterlegten Kommentaren darge-
stellt. Der Benutzer kann selbst Kommentare hinterlegen. Die Sidebar ist konsisten-
ter Weise analog zur Sidebar Edit gestaltet. Über den Button Kaufen, kann der Be-
nutzer den Kauf des Prozessmodells tätigen. Der Button ist dabei bewusst Grün
gestaltet, um den Benutzer zum Kauf zu animieren.
5.6 Detailentwurf
147
ABBILDUNG 131: SIDEBAR DES STORES
PROFILEINSTELLUNG
Einstellungen zum Benutzerprofil sind über das Drop-down-Menü zugänglich, wel-
ches sich bei Mausklick auf den nach unten zeigenden Pfeil mit Profilbild und Be-
nutzername, öffnet. Neben dem Zugang zur Benutzereinstellung, kann sich der Be-
nutzer über den Menüpunkt Logout vom BPMS abmelden (siehe Abbildung 132).
ABBILDUNG 132: BENUTZERPROFIL UND LOGOUT
Der Dialog der Profileinstellung legt sich ebenfalls global über den zuletzt geöff-
nete Dialog, welche ebenfalls über den Button „x“ wieder verlassen werden kann.
5 UI-Entwurf
148
ABBILDUNG 133: PROFILEINSTELLUNG
Die Benutzereinstellung ist in Anlehnung an die Ansicht Anmeldung bzw. Account
erstellen angelehnt, da hier Profilkategorien vom Benutzer bestimmt werden kön-
nen (siehe Abbildung 133). Der Vor- und Nachname, sowie die E-Mail-Adresse
kann nachträglich editiert werden (siehe Anforderung ANF-15). Initial wird ein Pro-
filbild eingesetzt. Ein Profilbild des Benutzers kann hinterlegt werden und verwen-
dete Sprache des BPMSs ist zudem einstellbar.
TIMELINE MIT HISTORIE VON PROZESSMODELLEN
Im Dialog der Timeline wird die Historie von Prozessmodellen präsentiert. Eine ver-
tikale Linie (sogenannte Heute-Linie) innerhalb der Timeline beschreibt, welche
Aufgaben vom Benutzer erledigt werden müssen (siehe Anforderung ANF-13).
Ähnlich einer To-Do-Liste erhält der Benutzer einen Überblick zu anstehenden Auf-
gaben. Neben der Anzeige des Fortschritts in der Farbe Grün, wird ein Teil des
Kreises, welcher sich auf der Heute-Linie befindet, in Hellblau dargestellt. Der hell-
blaue Anteil beschreibt, wie weit die Instanz ausgeführt werden muss.
5.6 Detailentwurf
149
Rechts von der Heute-Linie, ist der Bereich der kommenden Woche hellrot einge-
färbt. Instanzen, welche sich in diesem Bereich befinden, sollten innerhalb dieser
Woche erledigt werden. Links von der Heute-Linie befinden sich Prozessmodelle
und laufende und abgeschlossene Instanzen, welche bereits in der Vergangenheit
liegen.
Initial werden Prozessmodelle zu Beginn mit einem Prozessmodell-Icon dargestellt.
Wurde über die Zeit das Prozessmodell bearbeitet (z.B. neue Prozesselemente oder
Datenelemente hinterlegt), wird dies in der Timeline durch entsprechende Icons
dargestellt. Dabei werden die gleichen Icons (Elemente, Edit, Run und Daten), wel-
che bereits in der Menübar verwendet werden, genutzt. Zu den einzelnen Kreisen
kann sich der Benutzer durch Mouse-Over weitere Informationen einholen.
Abbildung 134 zeigt den Mouse-Over eines Edit-Icons, das ein Pop-up-Menü mit
Informationen anzeigt. Zudem wird der Name des Benutzers, das Datum und ein
Link zur Editierung von Prozessmodellen zu Verfügung gestellt. Links sind in Hell-
blau gestaltet. Dadurch weiß der Benutzer, dass es sich um einen Link handelt. Lau-
fende Instanzen sind in der Farbe Grün eingefärbt, welche als Startpunkt das Run-
Icon beinhalten. Das Run-Icon assoziiert der Benutzer mit dem Erstellen einer In-
stanz, d.h. die Wiedererkennung des Icons ist gegeben. Durch die farbliche Hervor-
hebung von laufenden Instanzen, können Prozessmodelle und Instanzen differen-
ziert werden. Der zeitliche Verlauf von Instanzen wird oberhalb der zugehörigen
Prozessmodelle angezeigt, da Instanzen eine Ausführungsinstanz von Prozessmo-
dellen darstellen. Die Skala des zeitlichen Verlaufs eines Prozessmodells wird als
Grundlinie unterhalb des zeitlichen Verlaufs der Prozessinstanzen dargestellt. Da
von einem Prozessmodell mehrere Instanzen erstellt werden können, stellt das Pro-
zessmodell das Fundament der später erstellten Prozessinstanzen dar.
Durch horizontales Scrollen kann durch die entsprechende Timeline navigiert wer-
den und über zwei Schieberegler, die Zeitspanne bestimmt werden. Die Miniatur-
vorschau der Timeline mit Schiebereglern kann über den Button, welcher sich rechts
unten im Fenster befindet, eingeklappt werden. Oberhalb der Miniaturvorschau be-
findet sich die Display-Bar. In dieser kann von einer linearen Sicht der Timeline auf
eine kompaktere Darstellung als Höhenprofil umgeschaltet werden. Zudem ist die
5 UI-Entwurf
150
Anzeige von Nachrichten und laufenden Instanzen über die Display-Bar ein- bzw.
ausblendbar.
ABBILDUNG 134: TIMELINE MIT HISTORIE ZU PROZESSMODELLEN
Oberhalb der Timeline befinden sich Kreise, welche als Filter fungieren. Initial ist
der bunte Kreis, welcher aus den Farben Grün, Orange und Rot besteht, dargestellt.
Dieser gibt die Sicht auf alle Prozessmodelle und Instanzen frei, auf welcher der
Benutzer das Recht hat, diese anzusehen. Über den Kreis mit Plus-Icon, können
weitere Filter gesetzt werden.
In Abbildung 135 ist das Pop-up-Menü für das Anlegen eines neuen Filters, als
auch der neu erstellte Kreis in Grau dargestellt. Dadurch wird die Zusammengehö-
rigkeit beider Interaktionselemente hervorgehoben (siehe Kapitel 2.3.1).
5.6 Detailentwurf
151
ABBILDUNG 135: TIMELINE ZU FILTER SETZEN
Ein angelegter Kreis ist vollständig wieder löschbar. Durch Mouse-Over über einen
Kreis, wird ein Icon für das Löschen des Kreises, dargestellt. Zudem wird der Benut-
zer über einen Tool-Tip darauf hingewiesen, dass er über das Icon den angelegten
Kreis löschen kann (siehe Abbildung 136).
ABBILDUNG 136: FILTER LÖSCHEN IN TIMELINE
Die Farben der Kreise symbolisieren dabei die Art des Filters. Ein grüner Kreis sym-
bolisiert laufende Instanzen, ein oranger Kreis stellen Instanzen dar, welche nicht
im Aufgabenbereich des Benutzers liegen und abgeschlossene Instanzen werden
durch einen roten Kreis dargestellt. Diese Farbanalogie kennt der Benutzer bereits
aus der Prozessausführung. Die Timeline kann über den Timeline-Button in der Dis-
play-Bar, geschlossen werden. Des Weiteren ist dies auch über den Button X, wel-
cher sich oben rechts im Fenster befindet, möglich. Dieser Button wird zusätzlich
für das Schließen der Timeline angeboten, da der Benutzer diesen Schließen-But-
ton bereits aus dem Store und Benutzereinstellung kennt.
EINSTELLUNGEN
In der globalen Navigation ist ein Einstellungen-Icon dargestellt. Über einen Maus-
klick auf das Einstellungen-Icon erreicht der Benutzer die Einstellungen-Ansicht.
5 UI-Entwurf
152
Über die Menü-Bar können Einstellungen zu Organisationseinheiten, Plug-ins, Da-
tenelemente und Prozessmodellfilter vorgenommen werden. Die Menü-Punkte in
der Menü-Bar werden textuell beschrieben, da der Benutzer den Dialog Einstellun-
gen eher sporadisch nutzt (siehe Kapitel 2.4.3.). Folglich wird die Menü-Bar nicht
mit Icons dargestellt.
In der initialen Ansicht werden über eine Sidebar zum Menüpunkt OrgModel, Or-
ganisationseinheiten präsentiert, welche sich aus Rollen und Gruppen von Benut-
zern zusammensetzen. Menüpunke sind generell mit Icon und Name beschriftet. Je
nach Auswahl eines Menüpunktes können spezielle Einstellungen vorgenommen
werden.
Organisationseinheit
Einer Organisationseinheit können Gruppen und Rollen zugewiesen werden. Grup-
pen und Rollen bestehen aus mehreren, einzelnen Benutzern. Diese Hierarchisie-
rung ist durch eine Baum-Navigation in der Sidebar realisiert.
Neben der Namensvergabe und dem Hochladen eines Icons, welche die Organisa-
tionseinheit repräsentiert, können Gruppen- und Prozessmodellrechte gesetzt wer-
den. Zudem können neue Vertreter, Rollen und Gruppen hinzugefügt werden (siehe
Abbildung 137). Ein gleichbleibendes Interaktionsmuster mit der Verwendung von
gleichen bzw. ähnlichen Interaktionselementen ist dabei gewährleistet. Die Menüs
für Gruppen- und Prozessmodellrechte ist beispielsweise an das Menü der Benut-
zerrechte angelehnt. Sowohl das visuelle Design als auch die Verwendung der In-
teraktionselemente ist dabei gleichgeblieben.
Bereits angelegte Benutzer werden in der Sidebar unterhalb der Organisationsein-
heiten aufgeführt. Zudem können weitere Vertreter über den Button Hinzufügen
angelegt werden. Dies erfolgt über die Vergabe des Vor- und Nachnamen, der E-
Mail-Adresse sowie dem Passwort.
5.6 Detailentwurf
153
ABBILDUNG 137: EINSTELLUNGEN VON ORGANISATIONSEINHEITEN
Plug-ins
In der Sidebar des Menüpunkts Plug-ins werden bereits angelegte Plug-ins mit Na-
men und zugehörigem Icon präsentiert. Zu jedem Plug-in kann nachträglich der
Name, das Icon, sowie die lesenden oder schreibenden Parameter eines Datenele-
ments editiert und gelöscht werden. Auch hier kann über den Hinzufügen-Button
einem neues Plug-in erstellt werden. Da mehrere lesende bzw. schreibende Para-
meter vorliegen können, sind diese als Untermenüs aus- bzw. einklappbar (siehe
Abbildung 138). Dadurch wird eine übersichtliche Darstellung gewährleistet.
5 UI-Entwurf
154
ABBILDUNG 138: EINSTELLUNGEN VON PLUG-INS
Datenelemente
Wie bereits in der Sidebar der Organisationseinheiten, wird auch hier eine Baum-
Navigation verwendet, da Datenelemente aus mehreren Datentypen aufgebaut
sein können. Im BPMS werden Datenelemente als farbige Rechtecke präsentiert.
Die Farbe jedes Datenelements kann dabei auf Wunsch verändert werden (siehe
Abbildung 139). Unter Details können abhängig des ausgewählten Datenelements
weitere Einstellungen vorgenommen werden.
5.6 Detailentwurf
155
ABBILDUNG 139: EINSTELLLUNGEN VON DATENELEMENTEN
Prozessmodellfilter
Standardmäßig werden die Prozessmodellfilter Meine Aktivitäten, Organisatorische
Aktivitäten, Technische Aktivitäten und Benutzer-Aktivitäten angeboten. Diese sind
auch in der Sidebar zum Menüpunkt Filter aufgelistet, welche nachträglich durch
den Namen und die PQL-Query editiert werden können.
Zudem kann der Benutzer über den Button Hinzufügen selbst einen neuen Filter
anlegen (siehe Abbildung 140).
5 UI-Entwurf
156
ABBILDUNG 140: EINSTELLUNGEN VON FILTERN
DETAILENTWURF AN HAND VON USE-CASES
Im Folgenden wird der Detailentwurf des BPMS an Hand dem Use Case Aktivität
einfügen (siehe Tabelle 16) nochmals verdeutlicht (siehe Abbildung 141). Dieser Use
Case veranschaulicht dabei das Interaktionsdesign des BPMS. Die Schritte 1-5 wer-
den dabei vom Benutzer durchgeführt, wenn er eine neue Aktivität in das Prozess-
modell einfügen möchte.
5.7 Zusammenfassung
157
ABBILDUNG 141 DETAILENTWURF ZU AKTIVÄT EINFÜGEN
ZUSAMMENFASSUNG
Alle Designentscheidungen bzgl. Interaktionsdesign, Navigationskonzept sowie
dem visuellen Design sind im fertigen UI-Entwurf zusammengeführt. Bei der Ent-
wicklung eines Interaktionsdesigns, wird zunächst der Interaktionsstil des BPMS,
welcher sich aus der Formulareingabe, der Menüauswahl und der direkte Manipu-
lation zusammensetzt, bestimmt [12]. Funktionsblöcke, welche aus den Anforde-
rungen (siehe Kapitel 4) und Use Cases abgeleitet werden können, werden durch
Interaktionselemente detaillierter ausgearbeitet. Mit Hilfe von Wireframes wird das
Interaktionskonzept erstellt. Dabei wird darauf geachtet, dass der Benutzer mög-
lichst effektiv, effizient und zufriedenstellend seine Ziele erreichen kann. Zudem
wird darauf geachtet, dass durch die Verwendung von gleichen Interaktionsele-
menten ein Interaktionsmuster gegeben ist. Analog dazu erfolgt die Erarbeitung
eines Navigationskonzeptes, in welcher der Navigationsplan und die Elemente einer
Navigation vorgestellt sind. Das visuelle Design befasst sich mit der grafischen Aus-
gestaltung der Wireframes des Interaktionsdesigns. Im visuellen Design wird das
Farbkonzept, die Affordance, die Typografie, sowie Icons, welche im BPMS ihren Ein-
satz finden, bestimmt.
5 UI-Entwurf
158
Im Anschluss wird der fertige Interface-Entwurf des BPMSs präsentiert, in welcher
alle Anforderungen (siehe Kapitel 4) berücksichtigt wurden (siehe Abbildung 142).
ABBILDUNG 142 ANFORDERUNGEN FÜR DEN UI-ENTWURF
Dabei werden die erarbeiten Screens des UI-Entwurfs präsentiert. Für die Imple-
mentierung des UI-Entwurfs sind [32, 30] zuständig. Der UI-Entwurf wurde im Flat-
Design umgesetzt. Daher wurde auf die Stilrichtung des Skeuomorphismus im UI-
Entwurf verzichtet. Im Fokus des UI-Entwurfs steht ein schlichtes und übersichtli-
ches Design, daher ist die Informationsarchitektur gering gehalten. Gründe für ge-
troffene Designentscheidungen, werden durch Usability-Guidelines und Style-Gui-
des begründet.
159
6 EVALUATIONEN UND TEST
Der Usability-Test stellt einer der bekanntesten Methoden der Evaluation der Ge-
brauchstauglichkeit dar. Dabei simuliert der Usability-Test einen Praxisfall mit typi-
sche Anwendungen des BPMSs, welche bearbeitet und anschließend bewertet wer-
den [48]. Ziel des Usability-Tests ist es dabei, weitestgehend alle Usability-Probleme
aufzudecken. Der Usability-Test erfolgt an Hand von Probanden, welche später
auch die zukünftigen Benutzer des BPMSs darstellen. Dabei wird beobachtet, wie
gut diese mit den Prototypen Interaktionsszenarien lösen können [12]. Da es sich
beim Prototyp des BPMS, um einen klickbaren Prototypen handelt, können keine
quantitativen Aspekte z.B. die Zeit zum Lösen einer Aufgabe bewertet werden. Folg-
lich kann das Antwortzeitverhalten, wie z.B. die Zeit, zum Lösen einer Aufgabe ge-
messen werden [8].
ABBILDUNG 143 EVALUATIONEN UND TESTS
Der Ablauf eines Usability-Tests umfasst eine Reihe von Schritten. Daher ist eine
ordentliche Planung zwingend notwendig, um die einzelnen Schritte von der Vor-
bereitungsphase bis hin zur Auswertung des Usability-Tests sauber durchführen zu
können [12]. In der Vorbereitungsphase (siehe Kapitel 6.1) werden die am Usability-
6 Evaluationen und Test
160
Test beteiligten Probanden vorgestellt, sowie das Usability-Labor und der Prototyp,
welcher für den Usability-Test zum Einsatz kommt (siehe Abbildung 143). Zudem
werden die eingesetzten Interaktionsszenarien und Fragebögen, sowie die Mess-
technik genauer erläutert. In Kapitel 6.2 und Kapitel 6.3 wird der Testdurchlauf und
die Durchführung des Usability-Tests vorgestellt, die Ergebnisse der Datenauswer-
tung in Kapitel 6.4 präsentiert und Entwurfsoptimierungen aus den Ergebnissen ab-
geleitet (siehe Kapitel 6.5.).
VORBEREITUNGSPHASE DES USABILITY-TESTS
In der Vorbereitungsphase werden passende Aufgaben formuliert, welche die zu
prüfenden Teile des BPMSs vollständig abdecken. Diese werden in einzelne Inter-
aktionsszenarien unterteilt [12]. Des Weiteren wird eine Auswahl an Fragebögen
getroffen, welche zum Einsatz kommen. An Hand von Fragebögen können Proban-
den subjektive Eindrücke über den Prototypen des BPMS mitteilen. Diese werden
in Kapitel 6.1.5 vorgestellt. In Tabelle 26 ist zusammenfassend dargestellt, welche
Entscheidungen in der Vorbereitungsphase getroffen wurden.
Entscheidung
Beschreibung
Ziel der Untersu-
chung
Das BPMS wird auf seine Gebrauchstauglichkeit überprüft.
Methodik
Es findet eine summative Evaluation statt, welche gegen
Ende der Entwicklung des BPMSs stattfindet. Als Methode
kommt ein Usability-Test zum Einsatz. Für den Ablauf wer-
den fünf Interaktionsszenarien genutzt.
Prototyp
Als Prototyp kommt ein klickbarer Prototyp zum Einsatz. Da-
bei werden Screenshots verwendet, welche miteinander ver-
linkt werden, um ein interaktives Storyboard generieren zu
können. Für die Erstellung des klickbaren Prototyps wird in-
Vision eingesetzt [33].
Probanden
Bei den Probanden handelt es sich um eine heterogene Zu-
sammensetzung von sechs Probanden, welche die Ziel-
gruppe des BPMSs darstellen.
6.1 Vorbereitungsphase des Usability-Tests
161
Zeitraum der Un-
tersuchung
Der Usability-Test findet in der zweiten Februarwoche 2014
statt. Die Ergebnisse des Usability-Tests werden anschlie-
ßend im Entwicklungsteam besprochen. Verbesserungen
werden nachträglich in das BPMS aufgenommen.
TABELLE 26: PLANUNG DES USABILITY-TESTS
PROBANDEN FÜR DIE EVALUIERUNG DES BPMS
Stellen Sie sich vor, Sie wären ein Ladenbesitzer. Gerade haben Sie
beobachtet, wie eine ältere Dame im Eingangsbereich über eine her-
vorstehende Türschwelle stolpert. Kurz darauf geschieht einem jun-
gen Mann dasselbe. Würden Sie die Schwelle ersetzen oder warten,
bis weitere Personen straucheln? [11]
Dieses Zitat beschreibt eine Problematik aus dem Alltag und kann auf den Usabi-
lity-Test übertragen werden. Folglich werden für das BPMS Stolpersteine zu identi-
fiziert. Um ein Usability-Problem zu erkennen, ist es nicht notwendig, eine hohe
Anzahl an Probanden beim Usability-Test zu beobachten. Es genügen qualitative
Aussagen, d.h. eine quantitative Methode mit vielen Probanden ist nicht notwendig
[11]. Um 80% der Usability-Probleme des BPMS aufdecken zu können, reichen fünf
Probanden aus [49]. Für die Evaluierung des BPMSs werden folglich fünf Probanden
ausgewählt. Da das BPMS sowohl für Experten, als auch für Novizen ausgelegt ist
(siehe Anforderung ANF-3), besteht die Auswahl der Gruppe von Probanden aus
einer heterogenen Zusammensetzung, d.h. Faktoren wie die Computererfahrung, Al-
ter, Geschlecht, Ausbildung und Beruf sind dabei verschiedenartig.
SELEKTION VON TESTLEITER UND BEOBACHTER
Neben den Probanden, müssen ein Testleiter und ein Beobachter bestimmt werden.
Der Testleiter dient dabei als Ansprechpartner für den Probanden und muss im
Stande sein alle Fragen beantworten zu können. Des Weiteren sind Fähigkeiten wie
soziale Kompetenz und Interviewerfahrungen unabdingbar. Ein Leitfaden für den
Testleiter steht ihm dabei als Orientierungshilfe zur Verfügung (siehe Anhang F).
Aufgabe des Testleiters ist es, den Proband durch den Usability-Test zu führen.
Dazu stellt sich Jens Kolb zur Verfügung, da er die nötige Fachkompetenz im Kon-
text von BPMS verfügt. Zudem stellt er eine unbefangene, neutrale Person dar, da
er nicht für die Entwicklung des BPMS zuständig ist. Für die Rolle des Beobachters,
6 Evaluationen und Test
162
wird eine Person zugeordnet, welche zugleich auch für das Konzept und Design
des BPMSs zuständig ist, da diese das Bedienkonzept des BPMSs gut kennt. Auf-
gabe des Beobachters ist es, alle Auffälligkeiten des Probanden in einer Be-
obachtertabelle festzuhalten (siehe Anhang E).
BESCHREIBUNG DES USABILITY-LABORS UND DES PROTOTYPS
Der Usability-Test ist für eine mobile Lösung konzipiert, d.h. der Usability-Test fin-
det nicht stationär in einem festen Usability-Labor statt. Dadurch kann eine realis-
tische Arbeitsumgebung geschaffen werden. Der Prototyp besitzt die Bandbreite
der Funktionalitäten des BPMS, um den Probanden einen Gesamteindruck des
BPMS vermitteln zu können. Weiter können einzelne Teile des BPMSs, also Syste-
maspekte, realistisch erprobt werden. Das Interface des BPMS ist nahezu vollstän-
dig ausgearbeitet, jedoch verbirgt sich noch keine Funktionalität dahinter. Der Pro-
totyp ist als Storyboard realisiert, d.h. einzelne Screenshots des BPMS werden an
Hand einer festen Handlungskette gezeigt [8]. Die einzelnen Screenshots werden
mit Hilfe von inVision in einem klickbaren Prototyp fürs Web übergeführt. InVision
stellt dabei eine Plattform für Prototypen, Kollaborationen und Workflows dar [33].
Die Screenshots werden auf die Plattform hochgeladen und miteinander so ver-
linkt, dass Interaktionsszenarien realisiert werden können. Dabei kann der Proband
ausschließlich mittels Mouse-Over oder Mausklick durch den Prototypen navigie-
ren. Bereiche, welche nicht durch Mouse-Over oder Mausklick hinterlegt sind, kön-
nen nicht ausgeführt werden bzw. reagieren nicht auf Maus-Aktionen. Da nicht alle
möglichen Bedienungswege für die Probanden offen stehen bzw. nicht alle Berei-
che von Screenshots interaktiv bedienbar sind, kann es zu Misserfolgen bei der
Bedienung kommen. Dies stellt eine grundsätzliche Kritik dar, da die Sichtbarkeit
des Systemstatus nicht konsistent verfolgt wird (siehe Kapitel 2.4.3).
INTERAKTIONSSZENARIEN
An Hand von Interaktionsszenarien erhalten die Probanden einen Einblick in die
Bedienung und der Funktionalität des BPMSs. Insgesamt stehen fünf Interaktions-
szenarien zur Verfügung, welche unterschiedliche Teilaspekte des BPMSs prüfen
(siehe Tabelle 27).
6.1 Vorbereitungsphase des Usability-Tests
163
Interaktionssze-
narien
Beschreibung
Szenario 1
Im Szenario 1 meldet sich der Proband am BPMS an. Das
Prozessmodell Reiseantrag wird in der Prozessmodellüber-
sicht editiert (d.h. Benutzerrechte löschen) und der vorkon-
figurierte Reisekostenabrechnungsprozess wird aus dem
Store gekauft.
Szenario 2
In Szenario 2 wird das Prozessmodell Reisekostenabrech-
nung in der Prozessmodellansicht in der Prozessmodelldar-
stellung BPMN betrachtet und ausgeführt.
Szenario 3
Die Prozessmodelldarstellung wird auf die Transit-Map ge-
ändert und ein neue Aktivität eingefügt und editiert (Name
und Benutzerrechte)
Szenario 4
Die Prozessmodellansicht wird durch das Setzen des Pro-
zessmodellfilters meine Aufgaben geändert und ein neues
Datenelement mit Datenkante hinterlegt. Die Änderung
wird in der Prozessausführung angesehen.
Szenario 5
Die Historie des Prozessmodells mit einzelnen Events des
Prozessmodells wird mittels Mouse-Over in der Timeline
untersucht und eine Nachricht geöffnet.
TABELLE 27: ÜBERBLICK DER INTERAKTIONSSZENARIEN
In Anhang G sind die einzelnen Interaktionsszenarien im Detail beschrieben. Die
einzelnen Szenarien für die Probanden sind dabei so gestaltet, dass sie gut be-
schrieben sind, aber nicht zu trivial zu lösen sind. Vielmehr sollen die einzelnen
Teilaspekte des BPMSs verwendet werden, um anschließend Aussagen dazu treffen
zu können. Die Kernaufgaben des BPMS stellen die Prozessmodellierung und Pro-
zessausführung dar, was sich in den Interaktionsszenarien widerspiegelt. Folglich
kann dadurch überprüft werden, ob die Verschmelzung der Modellierungs- mit der
Ausführungsebene in ein BPMS wünschenswert und verständlich umgesetzt ist
(siehe Anforderung ANF-2).
6 Evaluationen und Test
164
FRAGEBÖGEN FÜR BEWERTUNG DES BPMS
Der Vorteil eines Fragebogens liegt darin, dass es sich um eine erlebnisnahe Be-
wertung handelt. Je nach Ausprägung des Fragebogens, können unterschiedliche
Aspekte evaluiert werden. Generell ist ein Fragebogen aus einer Reihe von Fragen
zusammengefasst, welche als Items bezeichnet werden. Das Antwortformat der
Items kann dabei von Antwortoptionen bis hin zu Freitext variieren. Die Konstruk-
tion eines Fragebogens, welche die Hauptgütekriterien wie Objektivität, Reliabilität
und Validität erfüllen, ist immens aufwendig [12]. Es werden standardisierte Frage-
bögen für die Evaluation des BPMS eingesetzt. Diese beziehen sich auf generelle
Aspekte, welche zur Beurteilung des BPMSs beitragen.
Für die Usability-Evaluation des BPMS wird auf drei standardisierte Fragebögen zu-
rückgegriffen, in denen bereits die Reihenfolge, die Formulierung und das Antwort-
format fest vorgegeben sind [8]. Neben diesen eingesetzten Fragenbögen, werden
unterstützend Kontextinformationen über die Probanden eingeholt, wie beispiels-
weise das Alter und Geschlecht. Dadurch können Ergebnisse differenzierter be-
trachtet werden [12].
ASQ
Der After Scenario Questionnaire Fragebogen (ASQ) wird jeweils nach Szenario 1-5
eingesetzt [50]. Folglich wird jedes Szenario nach Abschluss durch den Probanden
bewertet. Die Bewertung erfolgt an Hand von drei Items, welche sich auf die hypo-
thetischen Bestandteile von Usability beziehen. Item 1 beinhaltet den Aspekt zur
Effektivität, d.h. wie leicht die Aufgabe zu erledigen ist. Die Effizienz wird durch Item
2 ermittelt, d.h. die Zufriedenheit mit dem zu interagierenden Prototypen. Item 3
bezieht sich auf den Aspekt der Unterstützung bzw. Hilfe bei der Aufgabenerledi-
gung (siehe Abbildung 144). Das Antwortformat besteht aus einer siebenstufige
Skala, in der eine Bewertung von sehr positiv (1) bis zu sehr negativ (7) vorgenom-
men werden kann.
6.1 Vorbereitungsphase des Usability-Tests
165
ABBILDUNG 144: AFTER SCENARIO QUESTIONNAIRE
ISO-NORM 9241/110-S
Der ISO-NORM 9241/110-S Fragebogen deckt Usability-Probleme auf, welche im
BPMS vorliegen [8]. Die Bewertung erfolgt an Hand von 21 Items, welche auf den
sieben Grundsätze der Dialoggestaltung des ISO-NORM 9241/110-S basieren (siehe
Kapitel 2.4). Das Antwortformat beinhaltet eine siebenstufige Skala, in der eine Be-
wertung von sehr negativ (7) bis zu sehr positiv (1) vorgenommen werden kann. Ein
Auszug zu der Gestaltungsanforderung Aufgabenangemessenheit wird in Abbil-
dung 145 gezeigt.
Die Skala des ISO-NORM 9241/110-S ist bipolar aufgebaut. Jeder Gegenpol ist da-
bei einzeln beschriftet. Im Anhang A ist der vollständige Fragebogen ISO-NORM
9241/110-S aufgeführt.
1 2 3 4 5 6 7
Insgesamt bin ich damit
zufrieden, wie leicht die
Aufgaben in diesem Szenario zu
lösen sind.
Insgesamt bin ich damit
zufrieden, wie viel Zeit ich für die
Lösung der Aufgaben
aufwenden musste.
Insgesamt bin ich mit den
unterstützenden Informationen
bei der Bearbeitung des
Szenarios zufrieden.
F1
F2
F3
6 Evaluationen und Test
166
ABBILDUNG 145: AUSZUG AUS DEM FRAGEBOGEN ISO-NORM 9241/110-S
User Experience Questionnaire
Für die Beurteilung der User Experience (siehe Kapitel 2.4.5) steht der standardi-
sierte Fragebogen User Experience Questionnaire (UEQ) zur Verfügung [51]. Ein Ge-
samteindruck der Probanden bzgl. des Prototyps kann mittels 26 bipolaren Items
erhoben werden (siehe Anhang B). Ein Beispiel ist attraktiv versus unattraktiv, wie
in Abbildung 146 dargestellt. Diese sind in Gruppen mittels den Skalen Effektivität,
Durchschaubarkeit, Vorhersagbarkeit, Stimulation, Originalität und Attraktivität zu-
sammengefasst [8].
ABBILDUNG 146: AUSZUG AUS DEM USER EXPERIENCE QUESTIONNAIRE FRAGEBOGEN
Fragebogen mit Kontextinformationen
Kontextinformationen über Probanden sind eine wichtige Quelle, um die Ergeb-
nisse aus dem Usability-Test differenziert betrachten zu können. Daher sind für
den Usability-Test des BPMSs folgende Kontextinformationen relevant: Erfahrung
hinsichtlich BPM, die Nutzungshäufigkeit des Computers, Alter, Geschlecht, Beruf
und Bildungsgrad der Probanden. Nachdem Ausfüllen der Kontextinformationen
6.2 Testdurchlauf des Usability-Tests
167
kann der Proband abschließend seine Meinung, Wünsche oder Kritik zum BPMS
äußern. Um dem Probanden hinsichtlich seiner abschließenden Meinungsäuße-
rung genügend Freiheiten zu lassen, stellt das Antwortformat ein leeres Feld für
Freitext dar. Ein Gesamtbild des Fragebogens mit Kontextinformationen findet
sich in wieder.
MESSTECHNIK
Der Prototyp läuft auf einem Laptop, dabei handelt es sich um ein Apple MacBook.
Die Bewegung des Mauszeigers wird während des Usability-Tests mittels Screen-
Capturing eingefangen. Mit der Software Quicktime wird der Screencast aufzeich-
net. Neben Screen-Casts wird der Gesprächsinhalt während des Usability-Tests als
Audio aufgenommen, um eine qualitative Auswertung durchführen zu können.
TESTDURCHLAUF DES USABILITY-TESTS
Um einen reibungslosen Usability-Test realisieren zu können, ist ein Testdurchlauf
notwendig. Mit Hilfe des Probanden erfolgt ein Testdurchlauf. Dazu wird der zeitli-
che Rahmen, die Stabilität der Interaktionsszenarien am Prototypen, sowie die In-
teraktionsszenarien auf Verständlichkeit geprüft. Dadurch wird getestet, ob alle
notwendigen Informationen zur Verfügung stehen und alle Interaktionen mit dem
Prototyp durchführbar sind. Des Weiteren können Mängel wie z.B. Unklarheiten in
der Formulierung von Interaktionsszenarien identifiziert werden [8].
DURCHFÜHRUNGSPHASE DES USABILITY-TESTS
Bevor mit der Durchführungsphase des Usability-Tests begonnen werden kann,
müssen einige Vorbereitungen getroffen werden. Dazu gehört, dass der Prototyp
auf dem Laptop auf seine Funktionalität geprüft wird [12].
VORBEREITUNG DES USABILITY-TESTS
Vor Beginn des Usability-Tests wird der Prototyp auf dem Laptop eingerichtet. Um
einen reibungslosen Usability-Test zu gewährleisten, wird der Prototyp geprüft, be-
vor die Probanden daran arbeiten. Die Voreinstellung für die Messtechnik mittels
Screen-Capturing und Audio muss zusätzlich gestartet werden. Alle eingesetzten
Fragebögen werden zudem auf Vollständigkeit und Korrektheit untersucht. Darüber
hinaus muss eine angenehme Atmosphäre geschaffen (z.B. Getränk anbieten oder
über Anreise erkundigen) werden.
6 Evaluationen und Test
168
Es ist wichtig, dass die Vorgehensweise des Usability-tests dem Probanden erläu-
tert wird, da es für viele Probanden das erste Mal ist, dass sie bei einem Usability-
Test teilnehmen. Daher wird der Proband in die Zielsetzung des Usability-Tests ein-
geführt, sowie der Ablauf und beteiligte Personen erläutert. Des Weiteren ist das
Aufzeichnen mittels Screen-Capturing und Audio sowie die anonymisierte Daten-
auswertung zu benennen. Folgende Instruktionspunkte werden berücksichtigt:
Ziel des Usability-Tests ist es das BPMS zu testen und nicht die Probanden.
Probanden sind für die Optimierung des BPMS eine wichtige Hilfe.
Der Test wird mittels Screen Capturing und Audio aufgezeichnet, was aus-
schließlich zur Auswertung der Testresultate dient. Die Resultate des Usabi-
lity-Tests werden ausschließlich anonymisiert weiterverwendet. Mittels ei-
ner Einverständniserklärung wird die Zustimmung des Probanden eingeholt
(siehe Anhang D).
Um die Weitergabe von Information des BPMSs zu verhindern, bestätigt
der Proband mittels einer Geheimhaltungserklärung, Informationen an
Dritte nicht weiterzureichen.
Zu den Mitwirkenden des Usability-Tests gehören der Testleiter und der
Beobachter. Der Testleiter steht für Anmerkungen und Hilfeleistungen zum
BPMS zur Verfügung. Der Beobachter macht sich während des Lösens der
Interaktionsszenarien Notizen zum Ablauf wie z.B. Zögern in der Bedienung
oder ein fehlerhafter Mausklick.
Das Abbrechen eines Interaktionsszenarios oder des Usability-Tests ist je-
derzeit möglich. Insgesamt stehen fünf Interaktionsszenarien zur Verfü-
gung, welche der Reihe nach abgearbeitet werden.
Gedanken des Probanden können, aber müssen nicht laut geäußert werden.
Die Einführungsphase in die Funktionalität des BPMSs ist kurz gehalten, da
der Proband explorativ und unbedarft den Prototypen testen soll. Zudem
wird dem Probanden Platz für weitere Fragen eingeräumt.
6.4 Datenauswertung
169
ABLAUF DES USABILITY-TESTS
Nach der Vorbereitung kann der Proband mit dem Usability-Test beginnen. Der
Testleiter besitzt einen Leitfaden für den Ablauf des Usability-Tests, in dem noch-
mals die wichtigsten Aufgaben des Testleiters aufgeführt sind ( siehe Anhang F).
Die Aufgabenstellung an den Probanden erfolgt durch Vorlesen der Interaktions-
szenarien durch den Testleiter. Das Aufgabenblatt mit allen Interaktionsszenarien
liegt zusätzlich schriftlich für den Proband vor. So kann der Proband beim Vorlesen
dem Testleiter folgen. Unklarheiten während dem Lösen von Interaktionsszenarien
können mit dem Testleiter geklärt werden. Daher sitzt dieser in unmittelbarer Nähe
zum Probanden. Der Beobachter sitzt als stiller Beobachter weiter weg, um den
Proband nicht abzulenken. In einer Beobachtertabelle werden Anmerkungen stich-
punktartig als Kommentar zu jeder Aufgabe festgehalten (siehe Anhang E).
Des Weiteren erkundigt sich der Testleiter über Stolpersteine und Verbesserungs-
vorschläge. Nachdem Beenden aller Interaktionsszenarien erfolgt eine kurze Nach-
besprechung. Der Testleiter erkundigt sich über mögliche Verbesserungspunkte o-
der vermissten Funktionalitäten des Prototyps. Zuletzt wird in Erfahrung gebracht,
ob er das BPMS auch selbst nutzen würde bzw. welche Funktionalitäten er für be-
sonders sinnvoll erachtet. Die Auflistung aller Fragen, welche für die Nachbespre-
chung eingesetzt sind, sind in Anhang F aufgeführt. Zum Abschluss bedankt sich
der Testleiter für die Teilnahme des Probanden an dem Usability-Test.
DATENAUSWERTUNG
Nach der Durchführungsphase des Usability-Tests können die gesammelten Daten
ausgewertet werden (siehe Anhang I). Weiter können je nach Eigenschaften der Be-
nutzergruppen Korrelationen zwischen einzelnen Fragen untersucht werden [12].
Generell wird berücksichtigt, dass es zu gewissen Urteilsfehlern (siehe Tabelle 28)
kommen kann [11].
Urteilsfehler
Beschreibung
Halo Effekt
Der Halo-Effekt wird ausgelöst, wenn die Probanden nicht
zwischen den einzelnen Kriterien unterscheiden, sondern
sich vom Gesamteindruck des Prototypen leiten lassen.
6 Evaluationen und Test
170
Milde Härtefehler
Vorlieben bzw. Ablehnung von Probanden können die Be-
urteilung maßgeblich beeinflussen, in dem die Beurteilung
zu hoch bzw. zu niedrig ausfällt.
Zentrale Tendenz
Ein Indiz für eine mangelnde Kenntnis über das BPMS kann
vorliegen, wenn tendenziell der mittlere Bereich der Skala
eingestuft wird.
TABELLE 28: ÜBERSICHT ÜBER URTEILSFEHLER
Im Folgenden findet eine Auswertung aller Fragebögen statt.
KONTEXTINFORMATIONEN ZU DEN PROBANDEN
Abbildung 147 zeigt die Mediane mit Standardabweichung der generellen Erfah-
rungswerte zu Prozessmodellen der Probanden, sowie die Beherrschung dieses
Prototyps.
ABBILDUNG 147: KONTEXTINFORMATIONEN ZU DEN PROBANDEN
Aus dem Medianen wird ersichtlich, dass es sich bei den Probanden um erfahrene
Benutzer handelt, da die Erfahrung mit Prozessmodellen und BPMN als positiv be-
wertet wurde.
ERGEBNISSE DES ASQ
Abbildung 148 zeigt die Mediane des Fragebogens ASQ als „schwarze Balken“ an.
Die Mediane ergeben sich aus dem Median der Bewertungen der Szenarien 1-5
6.4 Datenauswertung
171
des jeweiligen Items. Aus diesen Medianen der drei Items wird der Median über
alle fünf Probanden gebildet.
ABBILDUNG 148: BOXPLOTS DES FRAGEBOGEN ASQ
Die Bewertung der einzelnen Szenarien fällt durchwegs positiv aus (siehe Abbil-
dung 140). Dabei ist der Median zu Item 1, welche den Aspekt der Effektivität be-
inhaltet, mit „++“ bewertet. Folglich bewerteten die Probanden, wie leicht die Sze-
narien zu lösen waren durchwegs positiv. Die zweite Frage, welche die Zufriedenheit
repräsentiert, besitzt einen Median von „++“. Daraus kann geschlossen werden
dass die Probanden mit dem zu interagierenden Prototypen zufrieden waren. Das
letzte Item beinhaltet den Aspekt der Unterstützung des Prototypen während der
Erledigung der Szenarien, was mit einem Median von „++“bewertet wurde. Die Er-
gebnisse dieser Auswertung zeigen keine deutlichen Usability-Probleme auf, daher
konnten keine spezifischen Probleme identifiziert werden.
ERGEBNISSE DES ISO-NORM 9241/110-S
Abbildung 144 stellt die Kategorien des Fragebogens ISO-Norm 9241/110-S dar.
Die Mediane bilden sich aus den Medianen der Items der Kategorien. Aus diesen
Medianen der Kategorien wird der Median über alle fünf Probanden gebildet.
Insgesamt ist der Fragebogen ISO-Norm 9241/110-S gut bewertet worden. Am
besten schneidet die Lernförderlichkeit mit einem Median von „+++“.
6 Evaluationen und Test
172
ABBILDUNG 149: BOXPLOTS DES FRAGEBOGEN ISO-NORM 9241/110-S
Bei der Bewertung der Kategorie Individualisierbarkeit taten sich die Probanden
schwer, da nicht alle präsentierten Funktionalitäten des Prototypen ausprobiert
werden konnten. Obwohl es sich um einen rein klickbaren Prototypen handelt und
auf die Grenzen des Prototypen vor dem Usability-Test darauf hingewiesen wur-
den, hinderte es die Probanden nicht daran, trotzdem alle Interaktionselemente
auszuprobieren.
Wie in Abbildung 149 zu sehen, schlägt die Standardabweichung der Selbstbe-
schreibungsfähigkeit am Weitesten aus, was einen Hinweis darauf gibt, dieses ge-
nauer zu untersuchen. Die Kategorie Selbstbeschreibungsfähigkeit zielt auf den
Aspekt, ob der Prototyp genügend Erläuterungen bietet und in ausreichendem
Maße verständlich ist. Da die Probanden das erste Mal den Prototyp bedienen, ist
zunächst eine Orientierung über alle Funktionalitäten notwendig. Einige Funktio-
nalitäten sind den Probanden dabei schwer gefallen. Einige Beispiele aus der Audi-
oaufnahme sind dabei im Folgenden aufgeführt:
Also ich tu mir noch ein bisschen schwer mit dem Grundverständnis
an manchen Stellen, wie ihr merkt.
Wenn ich weiß, wo ich hin klicken muss, dann bin ich sehr schnell
und effektiv, glaub ich mit dem Werkzeug erst mal. Das erste Mal,
6.4 Datenauswertung
173
wenn ich es verwende, habe ich zu wenig Hilfe, dass ich weiß wo
ich hin muss. Das ist so mein Gedanke.
Als ich gestartet habe, wusste ich jetzt nicht was ich tun könnte. Was
ich erwartet hab, aber nicht passiert ist. Wenn ich einen Prozess
laufen lass, dann muss ich ja was tun. Als Endbenutzer im Detail zu
wissen, wo ich bin, ist gar nicht so wichtig. Wichtig ist, ich muss jetzt
wissen, welche Schritte muss ich durchführen und ich will informiert
werden, wenn ich fertig bin, was passiert dann damit.
Beispielsweise beschriften, dass man sich gerade in der Ausfüh-
rungsansicht befindet und die Tasks per Klick abgehakt werden kön-
nen. Kleine Hilfestellungen unterstützen so den Benutzer was er ge-
rade tun kann.
Die Bedienung des Prototyps setzt ein generelles Grundverständnis für BPM vo-
raus. Das Verständnis für bestimmte Begrifflichkeiten ist meist nicht gegeben, was
zur Folge hatte, dass es bei der Lösung von Interaktionsszenarien zu Missverständ-
nissen kam. Für das BPMS ist eine Reihe von Tool-Tips vorgesehen, welche das
Verständnis von Begriffen stärken soll. Im Prototyp ist nur eine geringe Anzahl an
Tool-Tips umgesetzt. Daher konnten sich die Probanden an Stellen, wo sie sich Er-
läuterungen durch Tool-Tips gewünscht hätten, diese nicht einholen. Dies könnte
ein Grund sein, wieso die Selbstbeschreibungsfähigkeit etwas schlechter bewertet
wurde. Die Anforderung ANF-2 fordert, dass sowohl für erfahrene als auch uner-
fahrene Benutzer das BPMS ausgerichtet ist. Daher ist es wichtig, das BPMS mit
mehr Erläuterungen anzureichern, um den Erstkontakt mit dem BPMS zu erleich-
tern und folglich ein positives Benutzererlebnis zu schaffen.
Generell ist die Einarbeitung in den Prototypen für die Probanden mit Aufwand
verbunden. Die Anmerkung eines Probanden beschreibt diesen Aspekt wie folgt:
Mir hat die Funktionalität gefehlt, was ich tun kann, bis auf die Sze-
narien durchspielen musste, wo dann relativ klar war, was zu tun ist.
Schon relativ verständlich, wenn man den Hintergrund verstanden
hat und sich eingearbeitet hat. Ich würde sagen, initial schwer zu
erlernen, aber man kommt sehr schnell rein, also wenn man es er-
klärt bekommen hat oder an Hand einem Szenario erklärt bekommen
hat, ist es dann wieder leichter, aber initial schwer.
6 Evaluationen und Test
174
Dennoch ist die Bewertung der Kategorie Lernförderlichkeit am besten bewertet.
Ein Grund dafür kann die unterstützende Wirkung des Testleiters sein. Des Weite-
ren stärken die Interaktionsszenarien das Grundverständnis des BPMS.
ERGEBNISSE DES UEQ
Abbildung 150 zeigt die Mediane des UEQ Fragebogen. Diese bilden sich aus den
Medianen der Dimensionen. Auch der UEQ ist durchwegs positiv bewertet worden.
Dabei sind die Dimensionen Attraktivität, Stimulation, Effizienz, Durschaubarkeit
und Verlässlichkeit mit einem Median von „++“ bewertet. Mit einem sehr guten
Ergebnis schnitt die Dimension Neuartigkeit ab, welche mit einem Median von
„+++“ bewertet ist.
ABBILDUNG 150: BOXPLOTS DES FRAGEBOGEN UEQ
Da die Dimensionen des UEQ wenig Aufschluss auf Verbesserungen geben, werden
nochmals die einzelnen Items untersucht. Daraus kann geschlossen werden, dass
sich der Median aller Items genau zwischen „++“ und „+++“ bewegt.
Ein Grund warum das Item einfach 1,8 nicht mit „+++“ bewertet wurde, könnte
aufgrund teils langer Ladezeiten zwischen den Verlinkungen der einzelnen Screens
im Prototyp zurückzuführen sein. Die Rückmeldung des Systemstatus des Proto-
typs verzögerte sich, was auf Grund einer schlechten Internetverbindung zurück-
zuführen war. Eine Anmerkung des Probanden stärkt diese Vermutung wie folgt:
6.5 Entwurfsoptimierungen
175
Manche Klicks haben nicht reagiert, aber sonst relativ schnell.
Ein Aspekt, wieso das Item sicher nicht mit „+++“ bewertet wurde, liegt darin, dass
die Probanden zum ersten Mal mit dem Prototyp in Kontakt traten. Sie fühlten sich
noch etwas unsicher im Umgang mit dem Prototypen. Die Probanden wünschen
sich folglich mehr Hilfestellung oder Informationen zu einzelnen Themen:
Wenig Zeit zum erlernen? Sie (Anm.: BPMS) erfordert definitiv Zeit,
um die Funktionalität zu verstehen. Sie ist durch die Tool-Tips und
nach der Funktionalität gestalteten Icons in Ordnung zu bedienen. Es
braucht aber ein bisschen Zeit, bis man es verstanden hat!
Positiv hervorzuheben sind die Items originell, neuartig, angenehm, aufgeräumt
und innovativ, welche mit sehr positiv (+++) bewertet sind. Diese positive Bewer-
tung zeigt, dass das BPMS den Aspekt joy of Use mitberücksichtigt (siehe Kapitel
2.2.2). Folglich ist die Anforderung ANF-16, welches ein freundliches Design fordert,
gewährleistet.
ENTWURFSOPTIMIERUNGEN
Aus den Ergebnissen der Datenauswertung der Fragebögen und der Auswertung
der Audioaufnahme können Entwurfsoptimierungen für das BPMS abgeleitet wer-
den. Weiter gibt die Analyse des Screen-Capturing und der Beobachtertabelle Auf-
schluss auf das Verhalten der Probanden während des Usability-Tests. Aus Verbes-
serungsvorschlägen, Kritiken und Wünschen der Probanden können zudem weitere
Entwurfsoptimierungen für das BPMS erstellt werden, welche in den UI-Entwurf
(siehe Kapitel 5.6) einfließen.
Sprache des BPMS
Die eingesetzte Sprache des Prototyps verwendet sowohl deutsche, als auch eng-
lische Begrifflichkeiten, wie z.B. Business Objects und Run. Folgende Anmerkung
stützt diese Behauptung:
Da habt ihr jetzt immer alles auf Englisch vorgesehen, diese Tool-
Tips, dieses Elements […]. Ganz schwierig find ich Misch Masch.
Die Selbstbeschreibungsfähigkeit (siehe Kapitel 2.4.3) fordert eine für den Benutzer
vertraute Sprache. Daher sollte die Sprache des BPMSs einfacher und einheitlicher
6 Evaluationen und Test
176
gestaltet werden. Begrifflichkeiten, wie Access-Rights, welche als gemeingültiger
Begriff im BPM verstanden werden, könnten weiter in Englisch beibehalten werden.
Einzelne Begriffe, wie z.B. Assigned Users oder Business Objects sind für die Proban-
den nicht leicht verständlich. Obwohl die Bezeichnungen passend nach ihrer Funk-
tionalität sind, werden diese Begriffe nur nach Erklärung durch den Testleiter er-
sichtlich. Insbesondere der Begriff Business Objects sorgt für Unverständlichkeit.
Was sind Business Objects? Also eine Art Record?
Also mir ist jetzt klar, dass n Prozess Aktivitäten hat und das es
Daten gibt, die da reingehen und rausfließen, aber ein Endbenutzer
fängt mit Business Objects nichts an. Das ist mein Gefühl generell.
Ob sich nicht-vorbelastete Benutzer zurechtfinden bzw. die Denk-
weise.
Um eine konsistente und einfache Sprache des Benutzer gewährleisten zu können,
wird der Begriff Business Objects durch den allgemeineren Begriff, Daten(elemente)
abgelöst.
Icons
Einige Icons im BPMS werden in ihrer Bedeutung nicht richtig interpretiert. Das Icon
für den Store ist zwar leicht für die Proband zu erkennen, wird aber nicht mit dem
Store in Verbindung gebracht.
Ich weiß nicht, ob ich es intuitiv find, dass ein Warenkorb ein Store
ist, wo ich was kaufen kann. Warenkorb ist für mich ein Warenkorb,
ich hab es schon auf der Merkliste und jetzt will ich es voll abschlie-
ßen.
Ich hätte jetzt erwartet, dass auf der Startseite irgendwo ein Store
ist, weil das Icon ist für mich eine Shopping-Card.
Einkaufwagen ist jetzt nicht schlecht, aber streng genommen, ist es
einen Schritt zu weit. Oder einfach ein Access-Symbol mit einem
Plus oder so.
Daher wird das Icon für den Store neu gestaltet. Das neugestaltete Icon enthält
eine Einkauftasche mit Logo des BPMSs (siehe Abbildung 151).
6.5 Entwurfsoptimierungen
177
ABBILDUNG 151: NEUGESTALTUNG DES STORE-ICON
In der Display-Bar ist das Icon für die Timeline als Uhr dargestellt. Für den Proban-
den ist die Bedeutung nicht ersichtlich.
Ne Uhr? Ja, weiß ich nicht. Also mit dem Uhrzeitsymbol und der
Timeline. Das war das einzige, wo ich sag. Aber ob ich mit ner Uhr-
zeit, ne Historie verbinde, weiß ich auch net. Ist schwierig. Vielleicht
schon das beste Symbol.
Um den Benutzer zu suggerieren, dass der zeitliche Verlauf von Prozessmodellen
in der Timeline angezeigt wird, ist das Icon mit einer zusätzlichen Pfeilspitze verse-
hen (siehe Abbildung 152). Da auch die restlichen Icons prägnant und einfach ge-
staltet sind, bleibt das Timeline-Icon ebenfalls in seiner Abbildung vereinfacht. Zu-
dem erhält es zusätzlich die Beschriftung Timeline. Dadurch ist eine konsistente
Darstellung aller Icons gegeben (siehe Kapitel 2.4.2).
ABBILDUNG 152: NEUGESTALTUNG DES TIMELINE-ICONS
Tool-Tips
Einzelne Menüpunkte und Icons im BPMS werden mit Hilfe von Tool-Tips beschrie-
ben. Bleibt der Benutzer für einige Senkungen mit der Maus z.B. über einem Menü-
punkt stehen, erscheint dieser kurze Hilfetext. Dieser gibt einen Hinweis zur Funk-
tionalität. Für den Prototypen sind nur kurze Hinweise mittels einem einzelnen Be-
griff dargestellt. Im Usability-Test sind folglich die Hinweise für die Probanden zu
kurz gehalten und sie wünschen sich ausführliche Tool-Tips.
Die Tool-Tips helfen. Mir war inhaltlich nicht immer klar, was ich in
dem Moment jetzt alles tun kann, weil ich ja immer nur eine Aufgabe
bekommen habe, aber mit den Tool-Tips kann man schauen, welche
Möglichkeiten es gibt.
6 Evaluationen und Test
178
Dass du dann nochmal so Ballon-Informationen darüber legst, für die
Leute die nicht so technikaffin sind. Was bedeutet jetzt Edit? In wel-
chem Kontext steht das Edit? Zum Beispiel Edit und dann Bearbeiten
sie die Eigenschaften dieses Antrags oder dieses Szenarios
Zudem stellt die auffällige schwarze Farbe des Tool-Tips ein Kritikpunkt dar, da es
für einige Probanden einen klickbaren Bereich suggeriert.
Zum einen find ich den Tool-Tip verwirrend, weil der so kräftig ist.
Das suggeriert so ein Submenü finde ich. Des ist so reingeschossen
in einer kräftigen Farbe, wo ich das Gefühl hatte, ich muss jetzt dahin
klicken. So eine Signalwirkung.
Folglich werden die Tool-Tips nicht mehr in schwarz angezeigt, sondern in einer
schlichten Farbe Weiß. Weiter werden die Tool-Tips mit mehr Information angerei-
chert, um die Bedienung optimal zu unterstützen (siehe Abbildung 153).
ABBILDUNG 153: VERBESSERUNG VON TOOL-TIPS
Tool-Tips, welche Prozessmodelle und Instanzen in der Timeline beschreiben, soll-
ten demnach auch mit detaillierte Informationen unterstützt. Zudem wollen die
Probanden, dass im Tool-Tip zusätzlich ein Link angeboten wird.
Ich seh zwar ein Tool-Tip, dass ich Access Rights bearbeitet habe,
aber wann und nicht was, d.h. wenn ich draufklicken könnt, würd ich
im Detail sehen, was ich gemacht habe und wer.
Von da aus müsste ich dann auch noch in mehr Details reingehen
können (Tool-Tips).
Display-Bar
Generell ist das Schließen der Sidebar über die Menüpunkte in der Display-Bar für
den Probanden auf den ersten Blick nicht ersichtlich. Das Öffnen der Sidebar durch
Mausklick auf einen Menüpunkt wird intuitiv genutzt. Hingegen ist das Schließen
6.5 Entwurfsoptimierungen
179
durch erneuten Mausklick auf den Menüpunkt für den Probanden nicht immer
nachvollziehbar.
Das mit dem Toggeln hab ich mir schon vorher gemerkt, aber das
find ich irgendwie mit dem Menü toggeln irritierend a bissle. Aber ich
glaub, da gewöhnt man sich brutal schnell dran, wenn man einmal
verstanden hat, wie das System zu bedienen ist, aber es ist glaub
nicht gängig. Man ist ruck-zuck drin in der Art und Weise, glaub ich,
aber man kennt es so nicht.
Aus dem Screen-Capturing wird ersichtlich, dass die Probanden das Schließen eines
Menüpunktes über die Breadcrumbs oder den Zurück-Pfeil versuchten, was im Pro-
totyp aber (noch) nicht möglich war. Folglich werden die Buttons der Menüpunkte
optisch besser als Akkordeon hervorgehoben, indem die Tiefenwirkung durch Licht
und Schatten verstärkt wird (siehe Kapitel 5.5.2). Durch diesen visuellen Hinweis
wird das Hervorstehen bzw. Eindrücken von Buttons ersichtlicher [12].
Datenelemente
Alleinig die Pfeilspitze der Datenelemente für Drag-&Drop-Aktionen ist nicht aus-
reichend groß für eine Bedienung mit der Maus ausgelegt. Diese Behauptung stützt
die Aussage eines Probanden:
Ich würde, wenn das ganze Teil (Reisedaten Datentyp) hier reinbie-
gen, weil ich denke der Pfeil ist zu klein. Oder du hast einen kom-
pletten Button, der dann auch abgegrenzt ist als Button. Eingehender
Pfeil und ausgehender Pfeil und den dann ziehen.
Daher werden ergänzend an die ein- und ausgehenden Pfeilspitzen der Datenele-
mente Anfasser, in Form von kleinen Kreisen angefügt. Die Anfasser geben dem
Benutzer den Hinweis, dass die aus- und eingehenden Datenkanten bearbeitet
werden können (siehe Abbildung 154).
6 Evaluationen und Test
180
ABBILDUNG 154: ANFASSER FÜR DATENELEMENTE
Navigation
Im Prototyp erfolgt das Anlegen eines neuen Ordners oder Prozessmodells über
einen leeren Ordner oder Prozessmodell, welches ohne Inhalt dargestellt wird
(siehe Abbildung 155).
ABBILDUNG 155: ANLEGEN EINES NEUEN ORDNERS
Die Darstellung eines leeren Ordners bzw. Prozessmodells, empfindet ein Proband
sogar als störend, weil sich dieser optisch zu wenig von den anderen Ordnern bzw.
Prozessmodellen abhebt.
Den neuen Prozess anlegen, das muss man anders darstellen, sieht
zu sehr ähnlich aus, wie die anderen Prozesse.
Und das Kästchen finde ich am wenigsten ansprechend, weil der
einfach nur leer und grau und Mini-icon ist.
Die grafische Darstellung eines leeren Prozessmodells durch einen unausgefüllten
Rahmen erzeugt zudem keine positive Annahme.
Ich hab auch diesen Rahmen und ich hab ein riesiges leeres Feld,
was gar nichts bringt, weil das ist weiß, genauso weiß wie die ande-
ren. Wenn da jetzt drin stehen würde New ganz groß oder so, würde
ich schneller erfassen können. Da leg ich einen neuen Prozess an
6.5 Entwurfsoptimierungen
181
oder da ist blau hinterlegt oder mit einem Sternchen oder irgendwas,
dass ich was erkennen kann, hier kann ich was Neues machen.
Folglich wird das Erstellen eines neuen Ordners bzw. eines neuen Prozessmodells
über die Sidebar ermöglicht. In der Ordner- und Prozessmodellübersicht wird kein
leerer Ordner bzw. kein leeres Prozessmodell mehr angezeigt.
Zudem möchten die Probanden in der Sidebar die Möglichkeit haben auf der Pro-
zessmodellübersicht beim Erstellen eines neuen Prozessmodells, zwischen einem
leeren oder vorkonfigurierten Prozessmodell aus dem Store auswählen zu können.
Dies wird zusätzlich über die Sidebar angeboten.
Öffnen eines Ordners bzw. Prozessmodells
Das Öffnen eines Ordners bzw. Prozessmodells wird nicht mehr, wie es im Prototyp
vorgesehen war, mit einem einfachen Mausklick realisiert. Gründe dafür sind, dass
das Öffnen eines Ordners bzw. Prozessmodells eine bewusste Aktion sein sollte.
Daher wird das Öffnen eines Prozessmodells bzw. Ordners über einen Doppelklick
realisiert. Zudem ist dadurch das Selektieren bzw. Gruppieren von mehreren Ord-
nern oder Prozessmodellen über einen einfachen Mausklick gewährleistet.
Timeline
Im Prototyp ist das Timeline-Icon oben rechts in der globalen Navigation platziert.
Dies stößt nicht auf positive Akzeptanz der Probanden, weil sie dort den Zugang
zur Timeline nicht erwarten. Die Probanden verstehen unter der Timeline eine zu-
sätzliche Visualisierungsansicht. Aus dem Screen-Capturing wird ersichtlich, dass
die Timeline in der Display-Bar erwartet wird.
Ich würde es jetzt vermuten, dass es hier unten irgendwo sein muss,
weil es um Visualisierung geht. Richtig?
Weiß jetzt nicht auf Anhieb wie. (Öffnen der Timeline)
Hier muss ich sagen, dass die Timeline hier oben ist, das passt jetzt
nicht. Ich finde es super, dass der Supermarkt und die Nachrichten
hier sind. Aber ich finde die Timeline passt hier nicht rein.
Folglich wird die Timeline, zusammen mit den anderen Menüpunkten, in der Dis-
play-Bar angezeigt.
6 Evaluationen und Test
182
In der Timeline kann mittels bestimmten Filtern die Ansicht der Historie von Pro-
zessmodellen angepasst werden. Da die Probanden die Menübar oben links und
die Display-Bar unten rechts erwarten, möchten sie diese konsistente Platzierung
in der Timeline fortgeführt haben. Daher ist eine Zusammenführung aller Menü-
punkte in einem festen Menü oben links nicht optimal, was sich in den Audioauf-
nahmen wiederspiegelt.
Die Visualisierung ist ja jetzt lustig. Jetzt sind plötzlich alle Symbole
hier oben zusammen. Ich würde erwarten, dass die Visualisierungs-
symbole wieder hier unten sind und wenn ich hier noch ne Kontrolle
hab, im Sinne dass ich ne Ausführung mit dieser Schnittstelle hier
machen könnte, was wahrscheinlich nicht der Fall ist, obwohl ich
diesen Run-Button hier oben sehe. Das wäre bei mir hier oben. Ich
hätte erwartet, dass er genauso platziert ist wie vorher.
Neben ausführlicheren Tool-Tips, welche die Prozessmodelle und die Instanzen be-
schreiben, erwarten die Probanden noch zusätzliche Funktionalitäten. Dazu gehört
eine Anzeige von aktuell laufenden Prozessinstanzen. Diese werden nun auf dem
vertikalen Strich, welcher das aktuelle Datum angibt, angezeigt. Dadurch erhält der
Benutzer eine Übersicht, wie viel laufende Instanzen gerade vorliegen. Dies unter-
stützt den Benutzer bei seinen Aufgabenerledigungen. Des Weiteren möchten die
Probanden auch informiert werden, welche Deadlines aktuell vorliegen, d.h. welche
Aktivitäten bzw. Instanzen beispielsweise Priorität in ihrer Aufgabenerledigung ha-
ben. Ein Proband äußert sich dazu wie folgt:
Oder ich zeig jetzt die Deadlines in der Zukunft an, wo ich sag, da
muss jetzt das erledigt sein und da das usw. In den Dashboards ist
es dann wichtig zu sehen, was brennt, wo habe ich gerade Eng-
pässe.
Eine alternative Visualisierungsansicht, welche eine kompaktere Darstellung vieler
Instanzen schafft, ist zudem zielführend. Dies kann durch das Zusammenfassen von
Entscheidungspunkten von Instanzen, in sogenannte Meilensteine, realisiert wer-
den. Diese spiegeln in einer kompakten Darstellung den Verlauf eines Prozessmo-
dells wider.
6.5 Entwurfsoptimierungen
183
Dadurch wird die Ästhetik und das minimalistische Design (siehe Anforderung
ANF-1), welche sich konstant durch das ganze BPMS zieht, aufrechterhalten. Infor-
mationen, welche nicht relevant sind, werden folglich ausgeblendet und erhöhen
dadurch die Sichtbarkeit von Dialogen (siehe Kapitel 2.4.3). Ein Proband äußert sich
zur dieser Thematik wie folgt:
Dann könnte ich mir noch vorstellen, dass ich noch alternative Visu-
alisierungen bekomme. Dass ich zum Beispiel sage, ich hab jetzt hier
vier abstrakte Zustände meiner Reisekostenabrechnung und es ist
ne Reise aber noch kein Reisekostenantrag da.
Der Wunsch nach einer kompakteren und individuelleren Darstellung von Prozess-
modellen in der Timeline ist zudem gegeben.
Da würde ich jetzt auch so Reduces reinmachen. Ich will jetzt nur die
Reisekosten oder die Reisebuchungsprozesse oder die Travel-Ex-
panse-Prozesse, dass man dann das reduzieren kann und filtern
kann auf bestimmte Prozesse.
Reduces wir durch granulare Filtermöglichkeiten, mit Hilfe von Kreisen, organisiert.
Ein Kreis stellt eine Zusammenstellung von ausgewählten Filtern, also Kategorien,
dar. Durch An- und Auswählen, Löschen bzw. Hinzufügen von neuen Kreisen ist
eine flexible Darstellung, welche individuell auf den Benutzer zugeschnitten werden
kann, realisiert (siehe Kapitel 5.6.7).
Fertigstellungsdatum bzw. Zeitspanne
Durch Anwählen einer Aktivität im Prozessmodell, können Informationen über die
Aktivität eingeholt bzw. editiert werden. Dabei ist die Anzeige des Datums, bis
wann die Aktivität bearbeitet sein soll, nicht berücksichtigt worden. Diese Informa-
tion ist für den Benutzer elementar wichtig, da er so einen Hinweis erhält, wie viel
Zeit ihm noch zur Erledigung einer Aktivät zur Verfügung steht. Probanden ver-
missten die Anzeige des Datums:
Das ist nur ein Zeitfeld, wo man vielleicht noch wählen kann, ist das
ein definiertes Datum, dass es am 18. Dezember abgeschlossen
werden muss oder ist das ein Zeitraum von taskfähigem, also zwei
Tage nachdem der Task zugewiesen wurde.
6 Evaluationen und Test
184
Aus diesem Grund wird zu jedem Prozessmodell und Aktivität das Fertigstellungs-
datum bzw. eine Zeitspanne dargestellt.
Prozessausführung
Aus dem Screen Capturing wird deutlich, dass drei von fünf Probanden das Aus-
führen eines Prozessmodells direkt über den Startknoten im Prozessmodell erwar-
teten. Um den Benutzer optimal bei seiner Aufgabenerfüllung zu unterstützen, wird
dieser alternative Weg über den Startknoten bereitgestellt (siehe Kapitel 2.4.2).
Des Weiteren wünschen sich die Probanden in der Prozessausführung eine Rück-
setzungsmöglichkeit, wenn bereits eine Aktivität versehentlich selektiert wurde.
Und das mit Anklicken, den Prozess damit Abschließen den Schritt.
Ich weiß nicht ob das vorgesehen ist, wenn du fälschlicherweise
klickst, dass dann doch nochmal klick den Prozess zurücksetzen
kannst, weil durch diesen einfachen Klick denk ich für den Average-
Benutzer wenn der draufklickt, wird der Prozessschritt abgehackt ob-
wohl das gar nicht vorgesehen war.
Mittels minimalen Korrekturaufwand sollte die fehlerhafte Bedienung leicht zurück-
gesetzt oder korrigiert werden (siehe Kapitel 2.4.3). Mit einem Doppelklick auf eine
Aktivität kann eine unerwünschte Bestätigung zurückgesetzt werden. Beim Erzeu-
gen einer neuen Instanz muss im Prototyp zuerst der Name des Prozessmodells
vergeben werden und anschließend durch Mausklick des Start-Buttons, kann die
Prozessausführung gestartet werden. Das Anwählen des Play-Buttons ist für einen
Probanden nicht intuitiv, da die Namensvergebung bereits das Erzeugen einer
neuen Instanz darstellt.
Aber für mich ist es schon eine Instanz, wenn ich sozusagen einen
neuen Namen erzeuge. Für mich heißt den Namen eingeben, ich
Erzeuge eine Instanz und starte sie noch nicht!
Resultierend aus dieser Erkenntnis wird das Erzeugen einer Instanz auf zwei Arten
angeboten. Sowohl auf direktem Weg über die Namensgebung einer Instanz, als
auch ohne Namensgebung durch Starten der Instanz über den Play-Button.
6.5 Entwurfsoptimierungen
185
Transit-Map
Bei der Transit-Map handelt es sich um eine neue Visualisierungsart, mit welcher
die Probanden vorher noch nicht gearbeitet haben. Trotzdem hatten sie keinerlei
Probleme mit der Transit-Map zu arbeiten, wie neue Aktivität einfügen. Die Akzep-
tanz der Transit-Map findet durchwegs positiven Zuspruch. Einziger Kritikpunkt
stellt die Liniendicke der Kante dar.
Also, als Tipp, ich würde die Linie dicker machen.
Folglich werden Pfade der Transit-Map nicht mehr mit einem Pixel, sondern mit
zwei Pixel dargestellt. Zudem möchte ein Proband, die Prozessdarstellung der Tran-
sit-Map noch kompakter darstellbar zu machen.
Also was für mich als Idee da reinkommt, ist zu sagen, man müsste
das Modell zusätzlich vereinfachen, d.h. die Entscheidung hier viel-
leicht rauszunehmen und untereinander darzustellen oder wenn es
eine Entscheidung gibt, dann einfach einzurücken oder so was. Ich
würde mich darauf konzentrieren Wege zu finden, wo ich dann wirk-
lich straight lesen kann und dann nicht Verzweigen muss, wenn ich
Verzweigungen hab. Was definitiv fehlt in den meisten Prozessmo-
dellierungstools ist genau diese Vereinfachung und diese Übersicht
über komplexe Modelle zu schaffen.
Eine Lösungsmöglichkeit stellt dabei dar, Gateways ein- bzw. ausklappbar zu ma-
chen. Dadurch ist die Möglichkeit gegeben, dass ein Prozessmodell in einer reinen
Top-Down-Ansicht ohne Verzweigungspunkte anzuzeigen. Zudem wird dadurch
der Lesefluss nicht mehr unterbrochen.
Benutzerhilfen durch Video-Tutorial
Da die Probanden zum ersten Mal mit dem Prototyp im Kontakt kamen, fühlten sie
sich noch etwas unsicher in der Bedienung.
Am Anfang hab ich mich unsicher gefühlt, aber je länger ich es be-
dient habe, desto sicherer war ich.
Der Erstkontakt mit dem BPMS kann durch ein Video-Tutorial erleichtert werden.
An Hand eines Fallbeispiels soll dadurch die Funktion des BPMSs näher gebracht
und Novizen eine optimale Anleitung bei der Bedienung des BPMSs geben (siehe
6 Evaluationen und Test
186
Kapitel 2.4.3). Das Video-Tutorial wird auf der Startseite des BPMSs angezeigt. Un-
terstützend zum Bildschirminhalt, wird ein erklärender Text gesprochen. Dadurch
wird für Novizen ein leichter Einstieg in das BPMS geschaffen. Ähnlich wie in
Windows 8.1 können die Benutzer so auf Entdeckungstour gehen [52]. Abbildung
156 zeigt ein Bild eines Videos, welches die Vorteile von Windows 8.1 aufzeigt.
ABBILDUNG 156: WINDOWS 8.1
Zudem sollte auch der Wiedereinstieg in das BPMS erleichtert werden. Mittels einer
Einstiegsseite, werden die letzten Schritte des Benutzers festgehalten. Dazu gehö-
ren zuletzt geöffnete Dateien, Aufgaben oder zuletzt angeschaute Prozessmodelle
und Instanzen. In der Sidebar werden dem Benutzer die zuletzt getätigten Aktionen
aufgeführt, welche mittels einem Link einen schnellen Wiedereinstieg ermöglichen.
Die Einstiegsseite wird in der globalen Navigation neben den anderen Menüpunk-
ten platziert und solange angezeigt, bis ein Prozessmodell geöffnet wird. So wie in
Microsoft Word ist ein direkter Zugriff auf zuletzt verwendete Inhalte möglich.
ZUSAMMENFASSUNG
Gegen Ende des UI-Entwurfs, wird das BPMS mittels einem Usability-Test evaluiert.
Ziel des Usability-Tests ist es, die Usability-Probleme des BPMS aufzudecken. Die
Anzahl der Probanden beschränkt sich dabei auf fünf. Diese Anzahl reicht, um die
wichtigsten Interaktionsszenarien des BPMSs zu prüfen und Verbesserungen ablei-
ten zu können [11].
Die Erarbeitung von Interaktionsszenarien, welcher aus der Benutzersicht realisti-
sche Aufgaben darstellen, wird mit größter Sorgfalt durchgeführt. Zudem wird ein
klickbarer Prototyp entwickelt, mit Hilfe die Probanden die Interaktionsszenarien
6.6 Zusammenfassung
187
lösen können. Da nicht alle Bereiche von Screens interaktiv bedienbar sind, sind
einige mögliche Bedienungswege eingeschränkt.
In der Durchführungsphase wird beobachtet, wie gut die Probanden die Interakti-
onsszenarien mit dem Prototyp lösen. Für die Usability-Evaluation des BPMSs wer-
den zudem die drei standardisierte Fragebögen ASQ, ISO-NORM 9241/110-S und
UEQ verwendet, welche auf unterschiedliche Aspekte der Usability zielen.
Nach Abschluss des Usability-Tests werden die Ergebnisse aller Fragebögen aus-
gewertet. Auf Basis der Datenauswertung, können neue Anforderungen (z.B. ein-
heitliche Sprache des BPMS) und Gestaltungsänderungen (Neugestaltung von
Icons) des BPMS ermittelt werden, welche im Entwicklungsteam besprochen wer-
den und in den UI-Entwurf einfließen.
6 Evaluationen und Test
188
189
7 ZUSAMMENFASSUNG
Die Mehrheit von Unternehmen in Deutschland ist mir ihrem BPMS unzufrieden.
Dabei sind die Hälfte nur bedingt zufrieden und ein Drittel überhaupt nicht zufrie-
den. Folglich will über die Hälfte der Unternehmen den BPM-Anbieter wechseln
[53]. Einen grundlegenden Aspekt stellt dabei die hohe Komplexität von BPMSs dar,
was zu hohen Einarbeitungszeiten führt. Gegenstand dieser Arbeit ist es diese Kom-
plexität zu verringern. Zudem werden Usability-Aspekte wie z.B. konsistente Inter-
aktionselemente berücksichtigt, um einen geringen Einarbeitungsaufwand zu ge-
währleisten. Die Nachvollziehbarkeit von Prozessmodellen wird zudem erhöht, da
sowohl in und nach der Ausführung, Prozessmodelle durch eine Timeline einsehbar
sind. Ein modernes und schlichtes visuelles Design trägt dazu bei, die Akzeptanz
der Benutzer zu steigern und eine gute Usability zu gewährleisten. Die Usability des
BPMSs wird anschließend mit einem Usability-Test durch mögliche Benutzer über-
prüft. Ein klickbarer Prototyp mit realistischen Aufgaben wird dazu entwickelt. Der
Usability-Test trägt dabei wesentlich zur Optimierung von Interaktionselementen
und des visuellen Designs bei.
Neben dem Aspekt der Usability, wird auch der emotionale Faktor des visuellen
Designs berücksichtigt, um das Gesamterlebnis zu optimieren. Dazu gehören Be-
geisterungsmerkmale und innovative Lösungen, wie z.B. ein Storekonzept. Im Rah-
men dieser Masterarbeit ist die erarbeitete GUI in sich konsistent und abgeschlos-
sen. Ob sich die GUI in der Realität bewehrt, kann folglich erst nach einer fertigen
Implementierung gezeigt werden. Durch eine moderne und intuitive GUI, in der die
Anforderungen der Benutzer berücksichtigt werden, wird die Akzeptanz gesteigert.
Ist die Akzeptanz der Mitarbeiter im Unternehmen nicht gegeben, so ist die Inves-
tition in ein BPM unnötig. Dadurch kann das Ziel, was eine Optimierung von Ge-
schäftsprozessen darstellt, nicht realisiert werden und ein BPM-Projekt ist zum
Scheitern verurteilt. Daher ist der Aspekt der Usability essentiell:
Damit ein Produkt zum Erfolg wird, muss es beim Kunden positive
Emotionen wecken – denn sie schaffen die nötige Motivation, um
das Produkt mit Freude zu nutzen und aktiv weiterzuempfehlen
[12].
7 Zusammenfassung
190
IX
A ISO-NORM 9241/110-S
ABBILDUNG 157: SEITE 1 DES ISO-NORM 9241/110-S
Aufgabenangemessenheit
Unterstützt die Software die Erledigung Ihrer Arbeitsaufgaben, ohne Sie als Benutzer/ -in
unnötig zu belasten?
Die Software…
--- -- - -/+ + ++ +++
Die Software…
ist kompliziert
zu bedienen.
ist unkompliziert
zu bedienen.
bietet nicht alle
Funktionen, um
die anfallenden
Aufgaben effizient
zu bewältigen.
bietet alle
Funktionen, um
die anfallenden
Aufgaben effizient
zu bewältigen.
bietet schlechte
Möglichkeiten, sich
häufig wiederholende
Bearbeitungsvorgänge
zu automatisieren.
bietet gute
Möglichkeiten, sich
häufig wiederholende
Bearbeitungsvorgänge
zu automatisieren.
ist schlecht auf die
Anforderungen der
Arbeit zugeschnitten.
ist gut auf die
Anforderungen der
Arbeit zugeschnitten.
F1
F2
F3
F4
X
ABBILDUNG 158: SEITE 2 DES ISO-NORM 9241/110-S
Selbstbeschreibungsfähigkeit
Gibt Ihnen die Software genügend Erläuterungen und ist sie in ausreichendem Maße
verständlich?
Die Software…
--- -- - -/+ + ++ +++
Die Software…
bietet einen
schlechten Überblick
über ihr Funk-
tionsangebot.
bietet einen
guten Überblick
über ihr
Funktionsangebot.
verwendet schlecht
verständliche
Begriffe,
Bezeichnungen,
Abkürzungen oder
Symbole in Masken
oder Menüs.
verwendet gut
verständliche
Begriffe,
Bezeichnungen,
Abkürzungen oder
Symbole in Masken
oder Menüs.
bietet auf Verlangen
keine situations-
spezifische
Erklärungen, die
konkret
weiterhelfen.
bietet auf Verlangen
situationsspezifische
Erklärungen, die
konkret
weiterhelfen.
bietet von sich aus
keine situations-
spezifische
Erklärungen, die
konkret
weiterhelfen.
bietet von sich aus
situationsspezifische
Erklärungen, die
konkret
weiterhelfen.
F5
F6
F7
F8
XI
ABBILDUNG 159: SEITE 3 DES ISO-NORM 9241/110-S
Steuerbarkeit
Können Sie als Benutzer/-in die Art und Weise, wie Sie mit der Software arbeiten,
beeinflussen?
Die Software…
--- -- - -/+ + ++ +++
Die Software…
bietet keine
Möglichkeit, die
Arbeit an jedem
Punkt zu
unterbrechen und
später problemlos
wieder einzusteigen.
bietet die
Möglichkeit, die
Arbeit an jedem
Punkt zu
unterbrechen und
später problemlos
wieder einzusteigen.
erzwingt eine
unnötige starre
Einhaltung von
Bearbeitungsschritten.
erzwingt keine
unnötige starre
Einhaltung von
Bearbeitungsschritten.
ermöglicht keinen
leichten Wechsel
zwischen einzelnen
Menüs und Masken.
ermöglicht einen
leichten Wechsel
zwischen einzelnen
Menüs und Masken.
ist so gestaltet, dass
der Benutzer/-in nicht
beeinflussen kann,
wie und welche
Informationen wie am
Bildschirm
dargeboten werden.
ist so gestaltet, dass
der Benutzer/-in
beeinflussen kann,
wie und welche
Informationen wie am
Bildschirm
dargeboten werden.
erzwingt unnötige
Unterbrechungen der
Arbeit.
erzwingt keine
unnötige Unter-
brechungen der
Arbeit.
F9
F10
F11
F12
F13
XII
ABBILDUNG 160: SEITE 4 DES ISO-NORM 9241/110-S
Erwartungskonformität
Kommt die Software durch eine einheitliche und verständliche Gestaltung Ihren
Erwartungen und Gewohnheiten entgegen?
Die Software…
--- -- - -/+ + ++ +++
Die Software…
erschwert die
Orientierung durch
eine uneinheitliche
Gestaltung.
erleichtert die
Orientierung durch
eine einheitliche
Gestaltung.
informiert in
unzureichendem
Maße über das,
was sie gerade
macht.
informiert in
ausreichendem
Maße über das, was
sie gerade macht.
reagiert mit schwer
vorhersehbaren
Bearbeitungszeiten.
reagiert mit gut
vorhersehbaren
Bearbeitungszeiten.
lässt sich nicht
durchgehend nach
einem einheitlichen
Prinzip bedienen.
lässt sich
durchgehend nach
einem einheitlichen
Prinzip bedienen.
F14
F15
F16
F17
XIII
ABBILDUNG 161: SEITE 5 DES ISO-NORM 9241/110-S
Individualisierbarkeit
Können Sie als Benutzer/-in die Software ohne großen Aufwand auf ihre individuellen
Bedürfnisse und Anforderungen anpassen?
Die Software…
--- -- - -/+ + ++ +++
Die Software…
lässt sich von dem/
der Benutzer/-in
schwer erweitern,
wenn für ihn/sie
neue Aufgaben
entstehen.
lässt sich von dem/
der Benutzer/-in
leicht erweitern,
wenn für ihn/sie
neue Aufgaben
entstehen.
lässt sich von dem/
der Benutzer/-in
schlecht an
seine/ihre
persönliche,
individuelle Art der
Arbeitserledigung
anpassen.
lässt sich von dem/
der Benutzer/-in an
seine/ihre
persönliche,
individuelle Art der
Arbeitserledigung
anpassen.
eignet sich für
Anfänger und
Experten nicht
gleichermaßen.
eignet sich für
Anfänger und
Experten
gleichermaßen.
lässt sich schlecht
für unterschiedliche
Aufgaben passend
einrichten.
lässt sich gut für
unterschiedliche
Aufgaben passend
einrichten.
ist so gestaltet, dass
die Bildschirm-
darstellung schlecht
an individuelle
Bedürfnisse
angepasst werden
kann.
ist so gestaltet, dass
die Bildschirm-
darstellung gut an
individuelle
Bedürfnisse
angepasst werden
kann.
F18
F19
F20
F21
F22
XIV
ABBILDUNG 162: SEITE 6 DES ISO-NORM 9241/110-S
Lernförderlichkeit
Ist die Software so gestaltet, dass Sie sich ohne großen Aufwand in sie ei narbeiten
konnten und bietet sie auch dann Unterstützung, wenn Sie neue Funktionen lernen
möchten?
Die Software…
--- -- - -/+ + ++ +++
Die Software…
erfordert viel Zeit
zum Erlernen.
erfordert wenig Zeit
zum Erlernen.
ermutigt nicht dazu,
auch neue
Funktionen
auszuprobieren.
ermutigt dazu, auch
neue Funktionen
auszuprobieren.
erfordert, dass man
sich viele Details
merken muss.
erfordert nicht, dass
man sich viele
Details merken
muss.
ist so gestaltet, dass
sich einmal
Gelerntes schlecht
einprägt.
ist so gestaltet, dass
sich einmal
Gelerntes gut
einprägt.
ist schlecht ohne
fremde Hilfe oder
Handbuch erlernbar.
ist gut ohne fremde
Hilfe oder
Handbuch erlernbar.
F23
F24
F25
F26
F27
XV
B UEQ
ABBILDUNG 163: SEITE 1 DES UEQ
Fragebogen -Teil 2
Bitte geben Sie Ihre Beurteilung ab.
Analog zum Fragebogen zuvor füllen Sie bitte den folgenden Fragebogen aus. Er besteht aus
Gegensatzpaaren von Eigenschaften, die das Produkt haben kann. Abstufungen zwischen den
Gegensätzen sind durch Vierecke dargestellt. Durch Ankreuzen eines dieser Vierecke können
Sie Ihre Zustimmung zu einem Begriff äußern.
Beispiel:
Die Software ist…
1 2 3 4 5 6 7
Die Software ist…
attraktiv
unattraktiv
Mit dieser Beurteilung sagen Sie aus, dass Sie das Produkt eher attraktiv als unattraktiv
einschätzen.
Entscheiden Sie möglichst spontan. Es ist wichtig, dass Sie nicht lange über die Begriffe
nachdenken, damit Ihre unmittelbare Einschätzung zum Tragen kommt.
XVI
B UEQ
ABBILDUNG 164: SEITE 2 DES UEQ
Die Software ist…
1 2 3 4 5 6 7
Die Software ist…
unerfreulich
erfreulich
unverständlich
verständlich
kreativ
phantasielos
leicht zu lernen
schwer zu lernen
wertvoll
minderwertig
langweilig
spannend
uninteressant
interessant
unberechenbar
voraussagbar
schnell
langsam
originell
konventionell
behindernd
unterstützend
gut
schlecht
kompliziert
einfach
abstoßend
anziehend
herkömmlich
neuartig
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
XVII
ABBILDUNG 165: SEITE 3 DES UEQ
unangenehm
angenehm
sicher
unsicher
aktivierend
einschläfernd
erwartungskonform
nicht
erwartungskonform
ineffizient
effizient
übersichtlich
verwirrend
unpragmatisch
pragmatisch
aufgeräumt
überladen
attraktiv
unattraktiv
sympathisch
unsympathisch
konservativ
innovativ
F16
F17
F18
F19
F20
F21
F22
F23
F24
F25
F26
XVIII
XIX
C KONTEXTINFORMATIONEN
ABBILDUNG 166: SEITE 1 VON KONTEXTINFORMATIONEN
Fragebogen -Teil 3
Zum Schluss bitten wir Sie, noch folgende Fragen zu beantworten:
Ich…
--- -- - -/+ + ++ +++
Ich…
analysiere nicht
regelmäßig
Prozessmodelle.
analysiere
regelmäßig
Prozessmodelle.
modelliere nicht
regelmäßig
Prozessmodelle.
Modelliere
regelmäßig
Prozessmodelle.
kenne mich nicht
gut mit BPMN aus.
kenne mich gut mit
BPMN aus.
beherrsche nicht gut
die beurteilte
Software.
beherrsche gut die
beurteilte Software.
An wie vielen Tagen in der Woche nutzen Sie
den Computer (Smartphones ausgeschlossen)
nicht?
0 Tage
1-2 Tage
2-5 Tage
5 und mehr Tage
An den Tagen, an denen Sie den Computer
nutzen: Wie lange sind Sie durchschnittlich am
Computer?
weniger als eine Stunde
1-5 Stunden
5-10 Stunden
10 und mehr Stunden
F1
F2
F3
F5
F6
F7
F8
XX
ABBILDUNG 167: SEITE 2 VON KONTEXTINFORMATIONEN
Ihr Alter?
0-20
21-30
31-40
41-50
51-60
> 61
Ihr Geschlecht?
männlich weiblich
Ihr Beruf/Tätigkeit?
Ihr höchster Bildungsabschluss?
Hauptschule
Realschule
Abitur
Hochschule
Sonstige:
Vielen Dank für ihre aktive Hilfe. Das letzte Wort haben Sie:
F9
F10
F11
F12
XXI
D EINVERSTÄNDNISERKLÄRUNG
ABBILDUNG 168: EINVERSTÄNDNISERKLÄRUNG
Einverständniserklärung
Name: _______________________________
Sehr geehrter Teilnehmer,
vielen Dank für Ihre Bereitschaft an dem von der Universität Ulm durchgeführten Usability-
Test teilzunehmen. Der Usability-Test dient der Überprüfung des Konzepts und der
Benutzerfreundlichkeit des BPMs. Vor Beginn des Usability-Tests möchten wir Sie über die
Verwendung der Daten zu informieren.
Weiterverwendung der Daten aus dem Usability-Test
Die Daten, die Sie bei diesem Usability-Test angeben, werden von uns anonymisiert und nur
im Kontext der Masterarbeit von Britta Meyer ausgewertet. Ihre Angaben sind für diese Arbeit
von großer Bedeutung und deshalb äußerst wertvoll.
Um eine optimale Auswertung des Usability-Tests zu gewährleisten, wird die Sitzung mittels
Screen Capturing und Ton dokumentiert.
Ich bin damit einverstanden, dass meine Daten wie oben beschrieben aufgezeichnet und
verwendet werden. Zudem versichere ich hiermit, mit niemandem über die Inhalte und den
Zweck der getesteten Anwendung zu sprechen und keine Informationen darüber
weiterzugeben, solange sie nicht der Öffentlichkeit frei zugänglich ist.
____________________________________________ ________________________________________________
(Ort, Datum) (Unterschrift des Teilnehmers)
XXII
XXIII
E BEOBACHTERTABELLE
ABBILDUNG 169: BEOBACHTERTABELLE
XXIV
XXV
F LEITFADEN FÜR DIE TESTLEITUNG
ABBILDUNG 170: SEITE 1 DES LEITFADENS FÜR DIE TESTLEITUNG
Leitfaden für die Testleitung
Vor dem Usability-Test
Eine freundliche Begrüßung einen Dank an den Probanden, dass er seine Zeit zur
Verfügung stellt und die Versicherung, dass die Mithilfe sehr geschätzt wird.
Beispiel eines Begrüßungstextes:
Vielen Dank, dass Sie sich Zeit nehmen an diesem Usability-Test teilzunehmen. Bitte
beachten Sie: Es geht in diesem Test nicht darum Ihre Kompetenzen, Fähigkeiten oder
Sie selbst zu testen, sondern vielmehr darum, das BPMS zu testen. Wir möchten
herausfinden wie Benutzer mit dem BPMS zurechtkommen, um sie eventuell verbessern
zu können.
Nach Befinden fragen, Anreise…
Kaffee anbieten oder etwas zum Trinken
Über Prototyp etwas erzählen
Erläuterungen zu der Funktion des Testleiters und des Beobachters. Die Spielregeln
der Testperson erklären und was sie erwartet. Zum Ablauf gehört die Zeit des
Usability-Tests und dass man jederzeit eine Pause machen oder abbrechen kann. Des
Weiteren den generellen Testablauf d.h. Szenarien durchspielen mit jeweils danach
ASQ und zum Schluss den Fragebogen, welcher aus Teil 1-Teil 3 besteht.
Überblick über Technik, Geräte und Aufzeichnung
Die Frage, ob die Testperson einer Tonaufnahme und dem Screen Capturing zustimmt
und die Versicherung, dass die Aufnahme anonym ist und nach ihrer Auswertung
gelöscht wird.
Einverständniserklärung unterschreiben lassen.
XXVI
ABBILDUNG 171: SEITE 2 DES LEITFADENS FÜR DIE TESTLEITUNG
In der Testphase
Führen Sie den Teilnehmer anhand ihres Leitfadens in Funktion und Aufgabe
ein. Haben Sie noch irgendwelche Fragen? Dann würden wir mit Szenario
1beginnen. Ich lese Ihnen die Aufgaben jeweils vor, gleichzeitig können Sie
alles auf ihrem Bogen mitlesen.
Sagen Sie dem Proband, dass er jederzeit das Szenario abbrechen kann, falls er
nicht weiterkommt.
Der Proband führt nun die Aufgabe durch. Dabei sitzen Sie als Testleiter neben
der Person und der Beobachter etwas entfernter.
Erlaubte Fragen des Testleiters sind z.B.:
"Was erwarten Sie, wenn Sie hier klicken?"
"Ist das, was Sie jetzt sehen, das, was Sie erwartet haben?"
"Warum glaubten Sie, dass dieser Link Sie weiter bringt?"
Helfen Sie dem Proband nicht. Halten Sie Umwege und Irrtümer aus, ohne
Kommentare abzugeben. So erfahren Sie am meisten über Missverständnisse.
Danken Sie dem Probanden für seine Geduld und versichern Sie ihm, dass
seine Hilfe wertvoll war.
Nach jedem Szenario
Nach jedem Szenario Stolpersteine und Verbesserungsvorschläge des Probanden einholen
und ihm den Fragebogen ASQ vorlegen.
Fragen nach dem Usability-Test
Welche Funktionalität der Anwendung würden Sie nutzen?
Wie viel würden Sie dafür zahlen?
Würden Sie die Anwendung nutzen wollen?
Falls nicht, warum?
Haben Sie Informationen oder Funktionen vermisst? Wenn ja, welche?
XXVII
G SZENARIEN
ABBILDUNG 172: SEITE 1 DER SZENARIEN
Szenarien
1. Szenario 1: Anmelden, Ordner editieren und Prozess kaufen
1.1. „Melde dich als bereits registrierter Benutzer in der Anwendung an.“
1.2. Du befindest dich in der Startansicht und siehst eine Auswahl an Ordnern, für die
du eine Berechtigung besitzt. Neuerdings bist du zuständig für die Reisekosten im
Unternehmen.
„Öffne dazu den Ordner Reisekosten“.
1.3. Du siehst nun eine Auflistung von Prozessmodellen und Dashboards, die die
Geschäftsreisen betreffen. Der Mitarbeiter Jens Kolb hat den Zuständigkeitsbereich
gewechselt und keine Rechte das Prozessmodell Reiseantrag zu bearbeiten.
„Editiere dazu das Prozessmodell und entziehe Jens Kolb alle Zugriffsrechte“.
1.4. „Schließe den Reiter Edit anschließend“.
1.5. Um deine tägliche Arbeit weiter zu erleichtern, beschließt du nun die Abrechnung
der Reisekosten auch durch die Anwendung zu automatisieren.
„Kaufe dazu im Store das vordefinierte Prozessmodell Reisekostenabrechnungs-
Prozess“. Du hast jetzt das Reisekostenabrechnungs-Prozessmodell gekauft. Dieses
steht nun zur Verwendung bereit.
2. Szenario 2: Prozess öffnen und ausführen
2.1. Du willst dir einen Einblick über den Ablauf des gekauften
Reisekostenabrechnungs- Prozessmodell verschaffen.
„Öffne dazu das Prozessmodell“.
2.2. Nun siehst du den Ablauf der Reisekostenabrechnung in der Darstellungsart
BPMN. Da du bisher noch keine Programmbausteine hinterlegt hast, besitzt das
Prozessmodell noch keine Logik. Er kann jedoch bereits als eine Art Checkliste
bzw. To-do-Liste verwendet und daher einfach durchgeklickt werden. Dies bietet
sich an, um den Fortschritt von Geschäftsfällen zu dokumentieren.
„Starte dazu das Prozessmodell, um die Reisekosten der Dienstreise vom letzten
Montag nach Berlin abzurechnen“.
„Öffne den Reiter Run und fülle den Ausführungsnamen aus. Anschließend starte
das Prozessmodell durch Klick auf den Button Run.
2.3. Da du das Formular für die Reisekostenabrechnung schon ausgefüllt hast, kannst
du diese Aktivität bereits abhacken. Belege sind für diese Reise keine anzufügen.
„Klicke deshalb auf den entsprechenden Pfad im Prozessmodell“.
2.4. Die Aktivität Reisekosten prüfen liegt im Aufgabenbereich der Personalabteilung.
Somit sind deine Tätigkeiten für diese Reisekostenabrechnung erfüllt.
„Schließe die Ausführungsansicht und klappe anschließend den Reiter zu“.
XXVIII
ABBILDUNG 173: SEITE 2 DER SZENARIEN
1. Szenario 3: Darstellungsart ändern und Prozessmodell editieren
1.1. Die Anwendung unterstützt eine weitere Visualisierung für Prozessmodelle.
„Wechsel in die Ansicht TransitMap, um diese zu sehen“.
1.2. Dir fällt auf, dass das Prozessmodell noch nicht vollständig ist. Es fehlt eine
Aktivität zur Archivierung der Unterlagen.
„Füge nach der Aktivität Überweisung durchführen eine neue, leere Aktivität ein.
Dies erfolgt über den Reiter Elements.
1.3. Benenne die neue Aktivität Unterlagen archivieren.
„Gehe dazu in den Reiter Edit“.
1.4. Die Archivierung soll ebenfalls von der Personalabteilung durchgeführt werden.
„Füge deshalb die Personalabteilung zu den Benutzerrechten hinzu“.
2. Szenario 4: Verwendung der View und Datenelements
2.1. In der Anwendung besteht die Möglichkeit spezielle Filter auf Prozessmodelle
anzuwenden, die das Prozessverständnis unterstützen. Der Reiter View bietet dazu
eine Übersicht der verschiedenen Filter. „Klicke auf den Filter meine Aufgaben“.
Nun werden nur noch die Aktivitäten angezeigt, bei denen du involviert bist.
2.2. Im nächsten Schritt willst du Datenelemente definieren, die im Prozess verarbeitet
werden sollen. „Gehe dazu in den Reiter Datenelements“.
2.3. Im Prozessmodell ist bereits das Datenelement Dateiliste hinterlegt. Mittels
Mouse-Over erfährst du, wo dieses verwendet wird.
2.4. Nun möchtest du die Daten des Reisenden erfassen. Daher möchtest du ein
neues, vordefiniertes Datenelement vom Datentyp Reisedaten hinzufügen.
„Klicke dazu auf das +-Symbol und wähle das Datenelement Reisedaten aus“.
2.5. Um zu sehen, welche Daten das neu hinzugefügte Datenelement erfasst, klicke auf
das Augen-Symbol. „Schließe danach diese Detailansicht wieder“.
2.6. „Klicke auf den eingehenden Pfeil des Reisedaten Datenelements, um den
schreibenden Zugriff durch die Aktivität Reisedaten eingeben zu definieren.“
Anmerkung: Dieser Schritt wird in der späteren Anwendung mittels Drag & Drop
durchgeführt.
2.7. Nun schaue dir die Änderungen, die du gemacht hast in der Ausführung an.
„Gehe dazu auf Run und starte eine neue Instanz für die Reise nach Stuttgart“.
2.8. „Klicke nun auf die Aktivität Reisedaten eingeben.
Als Resultat siehst du das generierte Formular für das Datenelement Reisedaten.
Führe nun das Prozessmodell weiter aus.
3. Szenario 5: Timeline und Nachricht anschauen
3.1. „Schau dir nun die Historie des Prozessmodells Reiseabrechung an. „Klicke auf das
Timeline-Symbol“. Hier erhältst du eine Übersicht aller Ereignisse rund um das
Prozessmodell.
3.2. „Schaue dir die einzelnen Events durch Mouse-Over an“.
XXIX
H DETAILENTWURF
ABBILDUNG 174: ACCOUNT ERSTELLEN
XXX
ABBILDUNG 175: PROZESSMODELLÜBERSICHT DER SIDEBAR EDIT
ABBILDUNG 176: PROZESSMODELLANSICHT DER SIDEBAR EDIT
XXXI
ABBILDUNG 177: GRUPPENRECHTE
ABBILDUNG 178: VERTRETER
XXXII
XXXIII
I DATENAUSWERTUNG
Proband
1
2
3
4
5
F1
2
2
2
3
0
F2
2
3
2
2
-1
F3
3
3
0
0
1
F4
3
3
1
3
0
F5
2
2
1
2
2
F6
3
2
0
2
-2
F7
1
2
0
2
-2
F8
1
2
0
2
-2
F9
0
3
2
3
2
F10
2
3
2
2
3
F11
2
2
3
2
2
F12
3
2
0
2
3
F13
2
2
2
2
0
F14
3
3
3
1
3
F15
1
3
0
2
2
F16
2
3
2
1
0
F17
3
3
3
3
1
F18
2
2
3
2
2
F19
1
2
3
2
0
F20
2
2
0
3
2
F21
1
2
3
2
1
F22
2
1
2
2
0
F23
3
3
2
3
1
F24
3
3
3
3
3
F25
3
2
2
3
2
F26
3
3
3
3
2
F27
2
2
2
2
-1
-3≙--- -2≙-- -1≙- 0≙+/- 1≙+ 2≙++ 3≙+++
TABELLE 29: ISO-NORM 9241/110-S
XXXIV
Proband
1
2
3
4
5
F1
6
7
6
7
6
F2
7
6
5
7
6
F3
2
2
6
1
F4
2
2
2
1
5
F5
2
2
3
1
1
F6
6
6
5
7
6
F7
6
7
6
7
6
F8
6
6
6
6
7
F9
3
2
2
3
F10
1
1
3
1
2
F11
6
7
6
7
5
F12
2
2
3
1
3
F13
7
6
6
7
3
F14
7
7
5
7
5
F15
7
7
5
7
6
F16
7
7
6
7
6
F17
4
2
4
1
2
F18
2
2
2
1
3
F19
2
2
3
1
2
F20
6
6
6
7
6
F21
1
2
2
1
3
F22
6
6
5
7
6
F23
2
1
1
1
1
F24
2
1
2
1
2
F25
2
2
2
1
1
F26
7
7
6
7
7
TABELLE 30: UEQ
XXXV
Proband
1
2
3
4
5
ASQ - Szenario 1
F1
2
2
3
1
2
F2
1
3
1
1
1
F3
1
3
4
2
3
ASQ - Szenario 2
F1
3
2
2
1
2
F2
2
2
1
1
2
F3
2
1
2
2
4
ASQ - Szenario 3
F1
2
2
1
1
4
F2
1
3
1
1
3
F3
1
2
1
2
3
ASQ - Szenario 4
F1
1
2
2
1
2
F2
1
3
1
1
2
F3
1
2
2
2
3
ASQ - Szenario 5
F1
2
3
1
2
3
F2
2
3
1
1
3
F3
2
2
1
2
4
TABELLE 31: ASQ
Proband
1
2
3
4
5
F1
3
2
2
-3
1
F2
2
1
1
-3
2
F3
3
-2
2
0
2
F4
2
-2
-2
0
2
F5
1-2 Tage
5 und mehr
Tage
0 Tage
0 Tage
5 und mehr
Tage
F6
1-5
Stunden
5-10
Stunden
5-10
Stunden
5-10
Stunden
5-10
Stunden
F7
41-50 Jahre
51-60 Jahre
31-40 Jahre
31-40 Jahre
21-30 Jahre
F8
männlich
männlich
männlich
männlich
männlich
F9
Professor
Informatik
Dip. Verw.
Wiss.
Software-
Architekt
Student
F10
Hochschule
Hochschule
Hochschule
Promotion
Hochschule
TABELLE 32: KONTEXTINFORMATIONEN ZU PROBANDEN
XXXVI
XXXVII
ABKÜRZUNGSVERZEICHNIS
ASQ
After Scenario Questionnaire
BPM
Business-Process-Model
BPMN
Business-Process-Modeling and Notation
BPMS
CRM
ERP
Business Process Management-System
Customer-Relationship-Management
Enterprise-Resource-Planning
GUI
Graphical-User-Interface
UC
Use Case
UE
Usability-Engineering
UEQ
User Experience Questionnaire
UI
User-Interface
XXXVIII
XXXIX
ABBILDUNGSVERZEICHNIS
Abbildung 1: Unternehmensziele durch den Einsatz von Cloud-Services ................... 2
Abbildung 2: Cloud-Service-Nutzung ohne IT-Abteilung .................................................. 3
Abbildung 3: Aufbau dieser ARbeit ............................................................................................ 5
Abbildung 4: Business Process Management ......................................................................... 7
Abbildung 5: Kernelemente der BPMN ..................................................................................... 8
Abbildung 6: Sequenzfluss ............................................................................................................. 9
Abbildung 7 Kernelemente der BPMN ................................................................................... 10
Abbildung 8: Referenzmodell der Daimler AG .................................................................... 15
Abbildung 9: Prozesschritte in der mensch-zentrierten Gestaltung ........................... 17
Abbildung 10: Farbkreis ............................................................................................................... 21
Abbildung 11: Windows 8-style UI........................................................................................... 29
Abbildung 12: Produktmerkmale .............................................................................................. 32
Abbildung 13: Berührungspunkte des Benutzers ............................................................... 32
Abbildung 14: Vorgehensweise dieser Arbeit ...................................................................... 33
Abbildung 15: Anforderungsanalyse ....................................................................................... 39
Abbildung 16: Aufgabenbereich von Effektif ....................................................................... 41
Abbildung 17: Geschäftsprozesse bearbeiten in Effektif ................................................. 42
Abbildung 18: Ravencloud .......................................................................................................... 43
Abbildung 19: Anmeldung .......................................................................................................... 45
Abbildung 20: Prozessmodellübersicht .................................................................................. 47
Abbildung 21: Prozessmodellvisualisierung ......................................................................... 50
Abbildung 22: Prozessmodellierung ....................................................................................... 52
Abbildung 23: Prozessmodelleditierung ................................................................................ 55
Abbildung 24: Prozessausführung ........................................................................................... 58
Abbildung 25: Datenelemente ................................................................................................... 60
Abbildung 26: Store ....................................................................................................................... 62
Abbildung 27: Timeline................................................................................................................. 64
Abbildung 28: Nachrichtensystem ........................................................................................... 66
Abbildung 29: Profileinstellung ................................................................................................. 67
Abbildung 30 UI-Entwurf ............................................................................................................. 73
Abbildung 31: Wireframe des Dialogs Account erstellen ................................................ 76
XL
Abbildung 32: Wireframe des Dialogs Anmelden .............................................................. 77
Abbildung 33: Wireframe des Dialogs Ordnerübersicht .................................................. 78
Abbildung 34: Wireframe der Display-Bar ............................................................................ 80
Abbildung 35: Wireframe des Dialogs Ordner erstellen .................................................. 81
Abbildung 36: Wireframe des Dialogs Ordner Editieren ................................................. 81
Abbildung 37: Wireframe des Dialogs Instanzen ............................................................... 82
Abbildung 38: Wireframe des Dialogs der Prozessmodellübersicht ........................... 83
Abbildung 39:Wireframe des Dialogs Prozessmodellübersicht Neu .......................... 84
Abbildung 40: Wireframe des Dialogs Prozessmodellübersicht Edit .......................... 84
Abbildung 41: Wireframe des Dialogs Prozessmodlelübersicht Run .......................... 85
Abbildung 42: Wireframe des Dialogs mehrere Prozessmodelle editieren .............. 86
Abbildung 43: Wireframe des Dialogs der Prozessmodellansicht ............................... 87
Abbildung 44: Transit-Map ......................................................................................................... 88
Abbildung 45: Wireframe der Display-Bar in der Prozessmodellansicht ................... 89
Abbildung 46: Wireframe der Sidebar der Prozessmodellierung ................................. 90
Abbildung 47: Wireframe des Menü-on-Demand ............................................................. 90
Abbildung 48: Wireframe der Sidebar Edit ........................................................................... 91
Abbildung 49 Wireframe der Sidebar Edit im Detail ......................................................... 93
Abbildung 50: Wireframe der Sidebar für Aktvität ............................................................ 94
Abbildung 51: Wireframe der Sidebar für Gateway und Startknoten ......................... 94
Abbildung 52: Wireframe des Dialog der Prozessausführung ...................................... 95
Abbildung 53: Wireframe der Sidebar für Prozessausführung ...................................... 96
Abbildung 54: Wireframe von Instanz erstellen .................................................................. 96
Abbildung 55: Wireframe von Instanz erstellen über den Startknoten...................... 97
Abbildung 56: Wireframe von Instanz ausführen ............................................................... 97
Abbildung 57: Wireframe von XOR-Gateway ...................................................................... 98
Abbildung 58: Wireframe der Transit-Map in Prozessausführung .............................. 98
Abbildung 59: Wireframe der Sidebar Datenelemente .................................................... 99
Abbildung 60: Wireframe der Sidebar DAtenelemente im Detail .............................. 100
Abbildung 61: Wireframe zu Daten hinzufügen ............................................................... 100
Abbildung 62: Wireframe des Dialogs Store ...................................................................... 101
Abbildung 63: Wireframe der Sidebar Store ...................................................................... 102
XLI
Abbildung 64: Wireframe des Dialogs Timeline................................................................ 103
Abbildung 65: Wireframe zu Filter erstellen ....................................................................... 104
Abbildung 66: Wireframe des Drop-down-Menüs .......................................................... 104
Abbildung 67: Wireframe des Dailogs Profileinstellung ................................................ 105
Abbildung 68: Wireframe des Dialogs Organisation ....................................................... 106
Abbildung 69: Wireframe des Dialogs Plug-ins ................................................................ 107
Abbildung 70: Wireframe des Dialogs Datenelemente .................................................. 108
Abbildung 71: Wireframe des Dailogs Filter ....................................................................... 108
Abbildung 72: Navigationsplan des BPMS .......................................................................... 109
Abbildung 73: Navigationplan von den drei Haupseiten .............................................. 110
Abbildung 74: Elemente einer Navigation .......................................................................... 111
Abbildung 75: Hauptfarbe, Hintergrundfarbe und Flächenfarben ............................ 114
Abbildung 76: Farbwahl auf der Startseite .......................................................................... 115
Abbildung 77: Farbwahl der Prozzmodellansicht ............................................................. 115
Abbildung 78: Buttonfarbe........................................................................................................ 116
Abbildung 79: Buttons von Office 365 und CloudDrive von Microsoft ................... 116
Abbildung 80: Farben der Ausführungsansicht ................................................................. 117
Abbildung 81: Selektionsfarbe ................................................................................................. 117
Abbildung 82: Signalfarben ...................................................................................................... 117
Abbildung 83: Benutzerrechte und Bewertung im Store ............................................... 118
Abbildung 84: Farben für Benutzerrechte und Bewertung im Store ......................... 118
Abbildung 85: Textfarben .......................................................................................................... 119
Abbildung 86: Iconfarben .......................................................................................................... 119
Abbildung 87: Filterfarbe und Ausschnitt aus Display-Bar ........................................... 119
Abbildung 88: Tiefenwirkung von Buttons ......................................................................... 120
Abbildung 89: Zoom-Regler ..................................................................................................... 121
Abbildung 90: Schieberegler der Timeline .......................................................................... 121
Abbildung 91: Icons von Menübar ......................................................................................... 122
Abbildung 92: Allgemeine Icons ............................................................................................. 123
Abbildung 93: Fortschrittanzeige von Prozessmodellen ............................................... 123
Abbildung 94: Icons für Fertigstellungsdatum .................................................................. 123
Abbildung 95: Icons von globaler Navigation ................................................................... 124
XLII
Abbildung 96: Ordner- und Prozessmodellinformation ................................................ 124
Abbildung 97: Vorschau-Icons ................................................................................................ 124
Abbildung 98: Ordner mit Ordner-, Privat- und Kommentaricon .............................. 125
Abbildung 99: Icons der Display-Bar ..................................................................................... 125
Abbildung 100: Icons für Benutzerrechte ............................................................................ 125
Abbildung 101: Unspezifische Prozesselemente .............................................................. 126
Abbildung 102: Vorkonfigurierte Prozesselemente ......................................................... 126
Abbildung 103: Arten von Benutzern .................................................................................... 126
Abbildung 104: Komplexe Typen ............................................................................................ 127
Abbildung 105: Standard-Icons .............................................................................................. 127
Abbildung 106: Icon für Ersetzen einer Aktivität .............................................................. 128
Abbildung 107: Verkleinern-Icon und Vergrößern-Icon des Zoom-Reglers .......... 128
Abbildung 108: Anmelden ........................................................................................................ 129
Abbildung 109: Ordnerübersicht ............................................................................................ 130
Abbildung 110: Ordner- und Prozessmodellvorschau ................................................... 130
Abbildung 111: Ordnerübersicht mit Sidebar .................................................................... 131
Abbildung 112: Prozessmodellübersicht ............................................................................. 132
Abbildung 113: Prozessmodell anlegen in der Prozessmodellübersicht ................. 133
Abbildung 114: Prozessmodell editieren in Prozessmodellübersicht ....................... 134
Abbildung 115: Access-Rights löschen von Prozessmodell ......................................... 135
Abbildung: 116 Access-Rights hinzufügen ......................................................................... 135
Abbildung 117: Sidebar Run in Prozessmodellübersicht ............................................... 136
Abbildung 118: Mehrfachselektion von Prozessmodellen ............................................ 137
Abbildung 119: Prozesselemente in der Prozessmodellansicht.................................. 138
Abbildung 120: Pop-up-Menü mit unspezifischen Prozesselementen .................... 139
Abbildung 121: Selektion einer Aktivität ............................................................................. 139
Abbildung 122: Sidebar der Prozessausführung .............................................................. 140
Abbildung 123: Instanz über Play-Button erstellen ......................................................... 141
Abbildung 124: Instanz in Ausführungsansicht ................................................................. 142
Abbildung 125: Informationen zur Instanz ......................................................................... 143
Abbildung 126: Sidebar zu Daten ........................................................................................... 144
Abbildung 127: Informationen zum Datenelement ......................................................... 144
XLIII
Abbildung 128: Datenelement löschen ................................................................................ 145
Abbildung 129: Datenkante setzen ........................................................................................ 145
Abbildung 130: Datenelement hinzufügen ......................................................................... 146
Abbildung 131: Sidebar des Stores ........................................................................................ 147
Abbildung 132: Benutzerprofil und Logout ........................................................................ 147
Abbildung 133: Profileinstellung............................................................................................. 148
Abbildung 134: Timeline mit Historie zu Prozessmodellen .......................................... 150
Abbildung 135: Timeline zu Filter setzen ............................................................................. 151
Abbildung 136: Filter löschen in Timeline ........................................................................... 151
Abbildung 137: Einstellungen von Organisationseinheiten ......................................... 153
Abbildung 138: Einstellungen von Plug-ins ........................................................................ 154
Abbildung 139: Einstelllungen von Datenelementen...................................................... 155
Abbildung 140: Einstellungen von Filtern............................................................................ 156
Abbildung 141 Detailentwurf zu Aktivät einfügen ........................................................... 157
Abbildung 142 Anforderungen für den UI-Entwurf......................................................... 158
Abbildung 143 Evaluationen und Tests ................................................................................ 159
Abbildung 144: After Scenario Questionnaire ................................................................... 165
Abbildung 145: Auszug aus dem Fragebogen Iso-Norm 9241/110-S ..................... 166
Abbildung 146: Auszug aus dem User Experience Questionnaire Fragebogen ... 166
Abbildung 147: Kontextinformationen zu den Probanden ........................................... 170
Abbildung 148: Boxplots des Fragebogen ASQ ................................................................ 171
Abbildung 149: Boxplots des Fragebogen Iso-Norm 9241/110-S ............................. 172
Abbildung 150: Boxplots des Fragebogen UEQ ................................................................ 174
Abbildung 151: Neugestaltung des Store-Icon................................................................. 177
Abbildung 152: Neugestaltung des Timeline-Icons ........................................................ 177
Abbildung 153: Verbesserung von Tool-Tips..................................................................... 178
Abbildung 154: Anfasser für Datenelemente ..................................................................... 180
Abbildung 155: Anlegen eines neuen Ordners ................................................................. 180
Abbildung 156: Windows 8.1 ................................................................................................... 186
Abbildung 157: Seite 1 des Iso-Norm 9241/110-S ............................................................. IX
Abbildung 158: Seite 2 des Iso-Norm 9241/110-S .............................................................. X
Abbildung 159: Seite 3 des Iso-Norm 9241/110-S ............................................................. XI
XLIV
Abbildung 160: Seite 4 des Iso-Norm 9241/110-S ............................................................ XII
Abbildung 161: Seite 5 des Iso-Norm 9241/110-S ........................................................... XIII
Abbildung 162: Seite 6 des Iso-Norm 9241/110-S .......................................................... XIV
Abbildung 163: Seite 1 des UEQ .............................................................................................. XV
Abbildung 164: Seite 2 des UEQ ............................................................................................. XVI
Abbildung 165: Seite 3 des UEQ ............................................................................................ XVII
Abbildung 166: Seite 1 von Kontextinformationen ......................................................... XIX
Abbildung 167: Seite 2 von Kontextinformationen ........................................................... XX
Abbildung 168: Einverständniserklärung ............................................................................. XXI
Abbildung 169: Beobachtertabelle....................................................................................... XXIII
Abbildung 170: Seite 1 des Leitfadens für die Testleitung .......................................... XXV
Abbildung 171: Seite 2 des Leitfadens für die Testleitung ......................................... XXVI
Abbildung 172: Seite 1 der Szenarien ............................................................................... XXVII
Abbildung 173: Seite 2 der Szenarien .............................................................................. XXVIII
Abbildung 174: Account erstellen ........................................................................................ XXIX
Abbildung 175: Prozessmodellübersicht der Sidebar Edit ........................................... XXX
Abbildung 176: Prozessmodellansicht der Sidebar Edit ............................................... XXX
Abbildung 177: Gruppenrechte ............................................................................................. XXXI
Abbildung 178: Vertreter ......................................................................................................... XXXI
XLV
LITERATURVERZEICHNIS
[1]
J. Freund und K. Götzer, Vom Geschäftsprozess zum Workflow, München: Carl
Hanser Verlag München, 2008.
[2]
IDC, IDC-Studie: Deutsche Unternehmen wollen mit Cloud Services
Geschäftsprozesse optimieren, 26 Juli 2013. [Online]. Available:
http://idc.de/de/ueber-idc/press-center/54895-idc-studie-deutsche-
unternehmen-wollen-mit-cloud-services-geschaftsprozesse-optimieren.
[Zugriff am 11 Juni 2014].
[3]
S. Zimmermann und C. Rentrop, Schatten-IT, in Mobile Security, HMD-Praxis
der Wirtschaftsinformatik, 2012, S. 60-61.
[4]
J. Hackmann, Anwender mögen ihre BPMN-Tools nicht, 2012 August 2012.
[Online]. Available: http://www.computerwoche.de/a/anwender-moegen-
ihre-bpm-tools-nicht,2510899. [Zugriff am 23 Juni 2014].
[5]
H. Kindermann, Metasonic AG, Geschäftsprozesse - Ziel und Quelle von
Information, 2014. [Online]. Available: http://www.dokmagazin.de/themen13-
02_geschaftsprozesse-ziel-und-quelle-von-information. [Zugriff am 11 Juni
2014].
[6]
T. Allweyer, Geschäftsprozessmanagement, Witten: W3L, 2005.
[7]
E. K.D., Towards the Experimental Study of Usability, in Behavior&Information
Technology, 1984, S. 133-143.
[8]
F. Sarodnick und H. Brau, Methoden der Usability Evaluationen, Bern: Verlag
Hans Huber, 2011.
[9]
J. M. Carroll und J. C. Thomas, Fun, in SIGCHI Bull., S. 21-24, New York, NY,
USA, 1988.
XLVI
[10]
F. D. Davis, R. P. Bagozzi und P. R. Warshaw, Extrinsic and Intrinsic Motivation
to Use Computers in the Workplace, in Journal of Applied Social Psychology,
Vol. 22, Num. 14, S. 1111-1132 , 1992.
[11]
M. Richter und M. D. Flückiger, Usability Engineering kompakt, Schlieren,
Schweiz: Srpinger-Verlag Berlin Heidelberg, 2013.
[12]
C. Moser, User Experience Design: Mit erlebniszentrierter
Softwareentiwcklung zu Produkten, die begeistern, Zürich: Springer Vieweg,
2012.
[13]
M. Offergeld, Vorlesungsskript Usability Engineering, Universität Ulm, 2011.
[14]
F. Janice, KDE Usability, 23 August 2003. [Online]. Available:
http://www.mzourek.org/files/kdeusabilitytalk.pdf. [Zugriff am 3 September
2014].
[15]
Gottschalch. H., Methoden der Beteilgung künftiger Benuzter an der
Gestaltung eins Planungs- und Steuerungsprogramms für die Werkstatt,
Seattle,WA: Fachbuchverlag Leipzig, 115-136, 1994.
[16]
ISO, ISO 9241-210:2010 Ergonomics of Human-System-Interaction - Part 210:
Human-Centred Design for Interactive Systems, 2010. [Online]. Available:
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnu
mber=52075. [Zugriff am 5 Juni 2014].
[17]
M. T. Thielsch und T. Brandenburg, Praxis der Wirtschaftspsycholgie II,
Verlagshaus Monsenstein und Vannerdat OHG Münster, 2012.
[18]
M. Wertheimer, Drei Abhandlungen von Gestalttheorie, Erlangen: Verlag der
Philosophischen Akademie, 1925.
[19]
E. Ulich, Arbeitspsychologie, Stuttgart: Schäffer-Poeschel, 2001.
XLVII
[20]
Rat der europäischen Gemeinschaften, http://eur-
lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:1990:156:0014:0018:DE:PDF
, 1990.
[21]
ISO, ISO 9241-171:2008 Ergonomics of Human-System-Interaction-Part 171:
Guidance on Software Accessibility, 2008. [Online]. Available:
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnu
mber=39080. [Zugriff am 5 Juni 2014].
[22]
J. Nielsen, Enhanding the Explanatory Power of Usability Heuristics, in
Proceeding Proceedings of the SIGCHI Conference on Human Factors in
Computing Systems (CHI '94) S. 152-158, Boston, USA, 1994.
[23]
Google, Unsere zehn Grundsätze, [Online]. Available:
http://www.google.com/about/company/philosophy/. [Zugriff am 24 Juni
2014].
[24]
Ars technica, Microsoft:Metro out, Windows 8-style UI in, amid rumors of a
trademark dispute| Ars Technica, 2 August 2012. [Online]. Available:
http://arstechnica.com/information-technology/2012/08/microsoft-metro-
out-windows-8-style-ui-in-amid-rumors-of-a-trademark-dispute/. [Zugriff
am 13 August 2014].
[25]
J. Nielsen, 10 Usability Heuristics for User Interface Design, Nielsen Norman
Group, 2005. [Online]. Available: http://www.nngroup.com/articles/ten-
usability-heuristics/. [Zugriff am 25 Juni 2014].
[26]
Microsoft, Microsoft Design Principles, [Online]. Available:
http://msdn.microsoft.com/en-us/library/windows/apps/hh781237.aspx.
[Zugriff am 24 Juni 2014].
[27]
Mircosoft, Live-Kacheln, 24 Juni 2014. [Online]. Available:
http://msdn.microsoft.com/de-de/library/windows/apps/dn468032.aspx.
XLVIII
[28]
P. D. n. Kano, Attractive Quality and Must-be Quality, Journal of the Japanese
Society for Quality Control, S. 39-48, 1984.
[29]
N. Wagner, Entwicklung eines Usability-Konzepts für die
Modellierungsumgebung eines datenorientierten Prozess-Management-
Systems, Universität Ulm, 2010.
[30]
S. Büringer, Develoment of a Cloud Platform for Business Process
Administration, Modeling and Execution, in Master Thesis, Universität Ulm,
2014.
[31]
K. Kammerer, Enabling Personalized Business Object Design and Instantiation
Framwork für BPM Systems: The Clavii BPM Platform, in Master Thesis,
Universität Ulm, 2014.
[32]
K. Andrews, Design and Development of a Runtime Object Design and
Instantiation Framework für BPM Systems, in Master Thesis, Universität Ulm,
2014.
[33]
invision, Design better Experiences for Web & Mobile, inVision, 2014. [Online].
Available: http://www.invisionapp.com/. [Zugriff am 7 Juli 2014].
[34]
T. Allweyer, Kurze Prozesse, 31 Januar 2014. [Online]. Available:
http://www.kurze-prozesse.de/2014/01/31/effektif-von-der-to-do-liste-
zum-workflow/. [Zugriff am 24 Juni 2014].
[35]
K. Amann und A. Fleischmann, Bewertung der Verständlichkeit graphischer
Modelle, GI-Konferenz Modellierung, S. 281-284, Garching bei München,
Deutschland, 2006.
[36]
DIN EN ISO 9241-11:1999-01, Ergonomische Anforderungen für
Bürotätigkeiten mit Bildschirmgeräten, 1999. [Online]. Available:
http://www.beuth.de/de/norm/din-en-iso-9241-11/5160339. [Zugriff am 15
September 2014].
XLIX
[37]
B. David, Welche Interfacedesignentscheidungen tragen zur Verbesserung
der Software-Usability allgemein und projektbezogen auf "mki-Web 3.0" bei?,
2014. [Online]. Available: http://mw.informatik-
reutlingen.de/uploads/media/Interfaceentscheidungen_zur_Verbesserung_d
er_Software-Usability_des_mki-Web_30.pdf. [Zugriff am 4 September 2014].
[38]
R. B. Misra, Global IT Outsourcing: Metrics for Success of All Parties, in Journal
of Information Technology Cases and Applications S.21, 2004.
[39]
M. Lessiak, Interaktionsdesign in Webappliaktionen, 2007. [Online]. Available:
http://schubs.at/AC05034592.pdf. [Zugriff am 29 August 2014].
[40]
C. Moser und Heiner Suter, Interaktion gestalten, 2013. [Online]. Available:
http://www.zuehlke.com/uploads/tx_zepublications/263_dnp_Interaktion_ge
stalten_moc_hsu.pdf. [Zugriff am 15 September 2014].
[41]
M. Halbrügge und K.-C. Hamborg, Fitts` Gesetz an den Bildschirmrändern und
seine Bedeutung für die Positionierung von Applikationsmenüs, 2005.
[Online]. Available: http://subs.emis.de/LNI/Proceedings/Proceedings82/GI-
Proceedings-82-24.pdf?origin=publication_detail. [Zugriff am 29 August
2014].
[42]
P. Gutheim, Der Webdesign-Praxisguide, Springer Berlin Heidelberg, 2008.
[43]
P. Bernhard und R. Dachselt, Die Interaktion mit Alltagsgeräten, Springer
Verlag, 2010.
[44]
M. Ebner und S. Schön, Lehrbuch für Lernen und Lehren mit Technologien,
Berlin: epubli GmbH, 2013.
[45]
Wikipedia, Flat Design, 17 Juli 2014. [Online]. Available:
http://de.wikipedia.org/w/index.php?title=Flat_Design&oldid=132227207.
[Zugriff am 10 August 2014].
[46]
R. Ridder, Gender Design im Web, Norderstedt: BoD-Books on Demand, 2014.
L
[47]
M. Heide, Semm, Arlett und Seyfarth, Menü-Arten für mobile Anwendungen,
2008. [Online]. Available: http://www.ai.fh-erfurt.de/blog_skswe/wp-
content/uploads/2009/01/semm-heide-seyfarth-menuarten-fur-mobile-
anwendungen.pdf. [Zugriff am 15 September 2014].
[48]
S. Stoessel, Methoden des Testings im Usability Engineering, Springer Verlag,
2002.
[49]
C. Barnum, N. Bevan, G. Cockton, J. Nielsen, J. Spool und D. Wixon, The Magic
Number 5: Is It Enough for Web Testing?, in Proceedings of CHI '03 Extended
Abstracts on Human Factors in Computing Systems, Ft. Lauderdale, Florida,
USA, 2003.
[50]
J. Lewis, An After-Szenario Questionnaire for Usability Studies, in
Psachometric Evaluation Over Three Trials S. 79, 1991.
[51]
B. Laugwitz, Held, T. und Schrepp, M., Construction and evaluation of a user
experience questionnaire, S.63-76,USA, 2008.
[52]
Microsoft, Windows 8.1 - Microsoft Windows, Microsoft, 2014. [Online].
Available: http://windows.microsoft.com/de-de/windows-8/meet. [Zugriff am
18 Juli 2014].
[53]
Metasonic AG, STUDIE: UNTERNEHMEN MIT BPM-SOFTWARE
MEHRHEITLICH UNZUFRIEDEN, Köln/Pfaffenhofen, 2012.
[54]
S. Maaß, Benutzer- und aufgabenorientierte Systemgestaltung,“ Universität
Hamburg, 1993.
[55]
BGB, Verordnung über Sicherheit und Gesundheitsschutz bei der Arbeit an
Bildschirmgeräten, 1996.
[56]
U. Schlatter, D. Kykalova, O. Schladitz, M. Clemente und T. Keller, BPM-
Lösungen aus der Cloud: Potenziale, Anforderungen und Erfolgsfaktoren,
v/dlf.
LI
[57]
Windows, Windows Store-Logos und Geräte-Chassis – Downloads, 2014.
[Online]. Available: http://msdn.microsoft.com/de-
de/library/windows/apps/jj670536.aspx. [Zugriff am 2014 August 10].
[58]
Visualpharm, Calendar icon for Windows 8/Metro - Icons8, [Online]. Available:
http://icons8.com/icons/#!/22/calendar. [Zugriff am 10 August 2014].
[59]
W. Jens, Software-Ergonomie, Berlin: de Gruyter, 1993.
[60]
H. Fischer, Integration von Usability Engineering und Software Engineering:
Evaluation und Optimierung eines ganzheitlichen Modells anhand von
Konformitäts- und Rahmenanforderungen, in Master Thesis, Fachhochschule
Köln, 2010.
LII
LIII
Name: Britta Meyer Matrikelnummer: 675729
ERKLÄRUNG
Ich erkläre, dass ich die Arbeit selbständig verfasst und keine anderen als die an-
gegebenen Quellen und Hilfsmittel verwendet habe.
Ulm, den …………………………………………………………………………………………………………………
Britta Meyer