7.3 Detailschritte des Verfahren
7.3.1 Die Aktivitäten
Mit dem Einsatz des im DATech 2007 empfohlenen ErgoNorm-Benutzerfragebogen werden Indika-toren der subjektiven Zufriedenheit der Nutzer mit der Software anhand der Dialogkriterien aus der Norm zur Dialoggestaltung (DIN EN ISO 9241-110, 2006) ermittelt. Der Fragebogen kann als Initialverfahren gewählt werden, allerdings nur in Bezug zu einer konkreten Arbeitsaufgabe, die im Voraus bekannt sein muss. Für die Auswertung ist es von Bedeutung zu erfassen, welche Fragen häufig kommentiert wurden und wie hoch der Prozentsatz der Nutzer ist, die die beanstandeten Mängel als sehr störend empfinden. Anhand der Kommentare zu diesen Punkten kann man abschätzen, wie erheblich die Nutzungsprobleme sind und welchen Bereichen sie (vermutlich) zuzuordnen sind. Sprachliche Mängel der Software könnten sich in negativen Werten hinsichtlich der Selbstbeschreibungsfähigkeit ausdrücken. Eingesetzt werden sollte der Fragebogen nur bei Nutzern, die schon längere Zeit mit der Software arbeiten.
Ergebnis
Die Auswertung der Fragebögen liefert prozentuale Angaben über die subjektive Zufriedenheit der Nutzer. Die Ergebnisse sind kategorisiert anhand der Dialogkriterien: Aufgabenangemessenheit, Steuerbarkeit, Selbstbeschreibungsfähigkeit, Erwartungskonformität, Fehlerrobustheit, Erlernbarkeit und Individualisierbarkeit. Es können Indizien für sprachliche Mängel festgestellt werden.
7.3.1.2 Dokumentenanalyse
Dokumente der fachlichen Modellierung, also textuelle Beschreibungen oder grafische Darstellungen von Geschäftsprozessen, Geschäftsobjekten, Klassenmodelle. werden sprachkritisch analysiert. Auch Präsentationsmaterial ist eine ergiebige Quelle. Ebenfalls werden vertraglich relevante Dokumente wie Lasten- oder Pflichtenhefte, Systembeschreibungen und Benutzungsanleitungen hinsichtlich der Verwendung arbeitsablaufrelevanter Substantive, Verben und Adjektive und deren Gruppierung untersucht. Des Weiteren kann Material von Konkurrenzprodukten herangezogen werden. In jedem Fall ist eine Liste aller sprachlichen Elemente einer ggf. bereits vorhandenen Applikation von der Entwicklungsabteilung anzufordern bzw. zu erstellen. Sprachliche Elemente sind zu finden als Menüoptionen, Feldbezeichner, Benennungen von Schaltflächen, Registern, Listen, Pfadangaben, Bezeichnungen in Verzeichnisstrukturen usw., aber auch Texte von Fehlermeldungen sollten vollständig dokumentiert sein. Bei einer Überprüfung dieser Auflistung stellt sich häufig heraus, dass zwei unterschiedliche Feldbezeichner für den gleichen Inhalt existieren oder unterschiedliche Benennungen auf Schaltflächen für die gleiche Funktion verwendet werden.
Darüber hinaus ist zu recherchieren, ob ein Corporate Wording vorhanden ist und ob dieses berücksichtigt werden soll. In größeren Unternehmen gibt das Marketing bestimmte Begrifflichkeiten vor, die etwa im Kundenkontakt (am Telefon) verwendet werden sollen.
Ergebnis
Der Entwurf einer tabellarischen Aufstellung arbeitsablaufrelevanter Begriffe in Form von Fach-terminologie liegt vor. Offene Fragen hinsichtlich Inkonsistenzen, Granularität, Widersprüchen u.ä.
sind formuliert. Zusätzlich steht eine Liste aller in der Applikation aktuell verwendeten sprachlichen Elemente zur Verfügung.
7.3.1.3 Terminologisch-linguistische Experteninspektion
Im Rahmen nutzungszentrierter Softwareentwicklung stehen primär die Nutzer als Informationsquelle zu den Arbeitsabläufen im Mittelpunkt. Ergänzend dazu wird auf das Wissen eines Usability-Experten zurückgegriffen. Dieser erkennt z.B., ob ein GUI-Element, etwa ein Kontrollkästchen, styleguidekonform eingesetzt ist, d.h. er ist Experte für das User Interface hinsichtlich der Infor-mationspräsentation, aber nicht für die Arbeitsabläufe. Grundlage für eine Inspektion der vorhan-denen Software hinsichtlich sprachlicher und anderer software-ergonomischer Mängel sind Heuris-tiken, also Faustregeln, die Experten selbst aus langjährigen Erfahrungen aufgestellt haben. Diese liegen oft in Form von Checklisten vor. Grundregeln zur Bildung von Bezeichnern findet man z.B. in der DIN EN ISO 9241-14. Als Entwurf einer Checkliste siehe Anhang B. Weitere Kriterien sind syntaktischer, semantischer und pragmatischer Art (vgl. Duda 2007, S.51). Ein syntaktisches Kriterium kann lauten: Passen mehrere Benennungen und ihre Positionierung innerhalb einer Maske inhaltlich zusammen? Eine semantische Regel lautet: Sind die verwendeten Benennungen ver-ständlich, eindeutig und aussagekräftig? Eine pragmatische Regel zielt darauf ab, herauszufinden, ob die Beziehung der Benennung zum Arbeitskontext der Nutzer passt? Werden die Benennungen so gebraucht, dass der Nutzer weiß, was er tun muss bzw. was ihn erwartet?
Im Unterschied zu einem auf Vollständigkeit zielenden Review wird in einer Inspektion nur ein Aspekt, hier die Qualität sprachlicher Elemente, untersucht (vgl. ISO/IEC 9126, 1992 und DATech 2007, S.122). Es wird empfohlen, dass der Experte dennoch andere Mängel notiert. Die Inspektion setzt voraus, dass ein (Alt-)System vorhanden ist. In diesem Fall ist eine Experteninspektion eine effektive Maßnahme zur Feststellung erster Indizien für mangelnde Nutzungsqualität aufgrund mangelhafter Benennungen. Festgestellte Mängel werden in einer Liste dokumentiert und gewichtet und ggf. später mit einer Aufwandsschätzung versehen.
Da der Experte weder mit der Aufgabe noch mit der Softwarenutzung vertraut ist, kann ein Nutzer die Aufgabenbearbeitung am System vorführen und kommentieren. Hier geht die Inspektion in die teilnehmende Beobachtung über. Im Rahmen der teilnehmenden Beobachtung (vgl. ISO TR 16982 2002) wird der Nutzer in seinem Arbeitshandeln betrachtet. Dabei wird zugehört, wie er telefoniert
oder mit Kollegen kommuniziert; es wird notiert wie Ordner beschriftet sind, wie der Desktop bzw.
die Dateien des Nutzers benannt und organisiert sind. Der Experte kann hierbei bereits sinnvoll oder auffallend erscheinende Bezeichnungen oder deren Kombination notieren. Dies können auch Explorer-Strukturen oder Informationen von Spickzetteln am Arbeitsplatz des Nutzers sein. Auch das gesprochene Wort der Nutzer kann auszugsweise hinsichtlich arbeitsablaufrelevanter Begriffe notiert werden.
Ergebnis
Das Ergebnis ist eine tabellarische Aufstellung von gängigen software-ergonomischen Mängeln und sprachlichen Auffälligkeiten. Nach Expertenmeinung falsch oder inkonsistent verwendete Benennun-gen im Interface werden benannt. Daneben sind Begriffshierarchien erfasst, die dem Experten für spätere Entscheidungsfindungen hilfreich erscheinen. Gegebenenfalls sind in dem Dokument bereits konstruktive Verbesserungsvorschläge notiert. Optional kann der Experte eine Concept Map vom Nutzer erstellen lassen, in der sein Verständnis der Anwendung visualisiert ist.
Es ist sinnvoll, die Liste mit dem Management abzustimmen, um eine Einigung darüber zu erzielen, welche der Mängel echte Nutzungsprobleme darstellen. Es ist denkbar, dass ein gravierendes Nutzungsproblem mit wenig Aufwand behoben werden kann. Es ist aber auch denkbar, dass die Beseitigung eines Nutzungsproblems weitreichende Designentscheidungen erfordert.
7.3.1.4 Analyse, Validierung und Dokumentation des Nutzungskontextes und der Nutzer-gruppen
Der Nutzungskontext beinhaltet Faktoren, die die Gebrauchstauglichkeit eines Produkts grundlegend bestimmen, also Merkmale des Arbeitsinhalts (z.B. eine notwendige zeitkritische Bearbeitung), der Arbeitsplanung (vorhersehbare oder unvorhersehbare Tätigkeiten) und der Arbeitsteilung sowie Faktoren der physischen und sozialen Umgebung (vgl. DIN EN ISO 9241-11, 2000). Es geht also darum, unter welchen Umständen die Applikation genutzt wird. Anwender, also Auftraggeber ver-zichten oft auf eine Beschreibung des Nutzungskontextes. Ebenso wird auf eine qualitative und quantitative Nutzergruppenanalyse verzichtet. Dies hat zur Folge, dass Implementierungen, die die Nutzungsqualität der Software verbessern sollen dann eher nach dem Zufallsprinzip vorgenommen werden. Dies kann zur Folge haben, dass sich die Nutzungsqualität für die eine Nutzergruppe ver-bessert, für eine andere aber verschlechtert.
Für die Analyse der Nutzergruppen werden die Nutzer in ihrer Gesamtheit betrachtet und es wird ermittelt, ob und wenn ja, wie sie sich verschiedenen Gruppen zuordnen lassen. Eine Unterteilung wäre z.B. die in Nutzer, die eher organisatorische Aufgaben haben (z.B. Buchen von Räumen), und Nutzer, die eher fachliche Tätigkeiten mit der Software lösen (Kundenaufträge bearbeiten). In der Praxis stellt sich oft heraus, dass die letztgenannte Gruppe sich in weitere Untergruppen unterteilt. Es kann jedoch auch sein, dass organisatorische und fachliche Aufgaben von einer Person geleistet
werden. Eine Nutzergruppe können natürlich auch Personen sein, die Leitungs- und Manage-mentfunktionen haben. Die ermittelten Gruppen sind zu quantifizieren und mit dem Auftraggeber zu validieren. Die Analyse der Nutzergruppen und deren Verifizierung ist von hoher Bedeutung, da auf dieser Grundlage entschieden wird, für welche der jeweiligen Gruppen die Anwendung optimiert werden soll und dementsprechend Entscheidungen u.a. hinsichtlich der Benennungen im User Interface getroffen werden. Möglich ist, dass die quantitativ am stärksten vertretene Nutzergruppe nicht unbedingt auch die Nutzergruppe ist, für die die Anwendung primär optimiert werden soll. Das Management kann unter Umständen entscheiden, einer Nutzergruppe eine höhere Priorität einzu-räumen, da für diese Gruppe höhere Lohnkosten anfallen, obwohl die Gruppe quantitativ in der Minderheit ist. Dies ist zwar aus arbeitswissenschaftlichen Gründen fragwürdig, dennoch ist es bes-ser, die Benennungen in einem User Interface entsprechen einer Linie als keinem Konzept. Außerdem ist dies eine bessere Basis für die Pflege und Weiterentwicklung der Anwendung. Im Kontext von Websites werden Nutzergruppen eher nach Marketingaspekten als sogenannte Personas beschrieben (vgl. Calabria 2004, Cooper 2003, Gebauer/Thormaehlen 2003). Für unternehmensorientierte Anwendungen ist die Bezeichnung Stakeholder verbreitet (vgl. Rupp 2007, S.92).
Nutzergruppen dürfen nicht mit Rollen verwechselt werden. Komplexen Softwareprodukten liegt oft ein Rollenkonzept zugrunde, das der Zugriffssteuerung dient. Jeder Nutzer bekommt dabei eine oder – in der Praxis durchaus üblich – mehrere Rollen zugewiesen. Wenn in einem E-Procurment-System, das insgesamt 10000 Nutzer hat, 8000 Nutzer die Rolle des „Anforderers“ und 2000 Nutzer die Rolle des „Genehmigers“ haben, ist anzunehmen, dass sich die Menge von 8000 Nutzern mit der Rolle „Anforderer“ weiter in Nutzergruppen wie Sekretariat, Marketing, Projektleiter differenzieren lässt. Die Arbeitsabläufe der priorisierten Nutzergruppen werden in einem nächsten Schritt mit Hilfe von Nutzungsszenarien recherchiert und dokumentiert.
Ergebnis
Die quantitativen und qualitativen Angaben über Nutzergruppen und andere wichtige Hintergrund-informationen für spätere Designentscheidungen liegen vor. Dokumentiert wird dies als ein Abschnitt des Nutzungskonzeptes.
Analyse, Validierung und Dokumentation der Nutzungsszenarien
Nutzungsszenarien sind im „Leitfaden Usability“ definiert als eine Beschreibung von Navigations- und Dialogschritten gemäß einem vorgegebenem Aufgabenmodell und einer vorgegebenen Nutzungs-anforderung (vgl. DATech 2007, S.204). Im ursprünglichen Prüfhandbuch wurde noch der Begriff Use-Szenarien verwendet, definiert als „eine episodische Beschreibung von Arbeitstätigkeiten, die ein Benutzer zur Erledigung einer Kernaufgabe am interaktiven System erledigt.“ (DATech 2006a). Die Bezeichnung wurde geändert, da es immer wieder zu Diskussionen hinsichtlich der Unterscheidung
zwischen Use Case und Use Szenario kam; auch die Bezeichnung „Geschäftsprozesses“ kam ins Spiel. Eine Gegenüberstellung der Definitionen findet sich in Tabelle 8.
Geschäftsprozess/
Business Case
Use Case
Anwendungsfall Use Szenario Nutzungsszenario Begriff aus der
(Re-)Organisation UML-Bezeichnung
Begriff aus dem User Centered Design
bis 2006
„Leitfaden Usability“
2008
„… eine Folge (oder Vorgangskette) von logisch zusammen-gehörigen Aktivitäten (oder Geschäftsvor-gängen), die für das Unternehmen einen Beitrag zur Wert-schöpfung leisten und sich in der Regel am Kunden orientiert, d.h.
auch für den Kunden einen Wert schafft.“
(Stahlknecht/
Hasenkamp 2005, S. 206)
„… beschreibt eine Menge von Aktivitäten eines Systems aus der Sicht seiner Akteure, die für die Akteure zu einem wahrnehmbaren Ergebnis führen.
Ein Anwendungsfall wird stets durch einen Akteur initiiert. Ein Anwendungsfall ist ansonsten eine kom-plette unteilbare Beschreibung“
(Oestereich 1999).
Anmerkung: Akteur ist dabei nicht zwingend ein Mensch, sondern kann im Sinne der Objektorientierung eine Klasse sein.
„Eine episodische Beschrei-bung von Arbeitstätigkeiten, die ein Benutzer zur Erledi-gung einer Kernaufgabe am interaktiven System erledigt.
Die Konstruktion des Use-Szenarios dient der Umset-zung der aus dem NutUmset-zungs- Nutzungs-kontext abgeleiteten Nut-zungsanforderungen für eine Kernaufgabe. Ferner dient das Use-Szenario der Umsetzung des Interak-tionsentwurfs in einen Prototyp (DATech 2006a S. 39).
„Eine Beschrei-bung von Naviga-tions- und Dialog-schritten gemäß vorgegebenem Aufgabenmodell und vorgegebener Nutzungsanforder ung“ (DATech 2007).
Tabelle 8: Unterschiedliche Notationen für Aufgaben
Im Rahmen des hier vorgestellten Verfahrens wird die Bezeichnung Nutzungsszenario verwendet.
Der besondere Fokus liegt jedoch auf der Ermittlung des Wortschatzes der Nutzer. Dazu dient eine episodische Beschreibung der Arbeitstätigkeit, bei der das gesprochene Wort, dort wo es sinnvoll erscheint „im O-Ton“ übernommen wird. Nur eine Sprache, die die Ausdrucksintention trifft, ist hier angemessen. Diesen Text bekommt der Nutzer zur Validierung. Im niedergeschriebenen Fließtext werden alle arbeitsablaufrelevanten Substantive, Verben und Adjektive gekennzeichnet. Wenn ein Nutzer formuliert, dass er eine Übersicht über offene Aufgaben benötigt, sollte dementsprechend
„offene Aufgaben“ im Text markiert werden. Denkbar ist, dass später dafür ein Register im User Interface existiert und so benannt wird. Würde man die Benennung dafür dem Zufall oder den Entwicklern allein überlassen, ist vorstellbar, dass auf dem Register die Bezeichnung Übersicht oder Aufgaben gewählt wird. Dies kann zu Irritationen bei der Nutzung führen.
Um außerdem das Fachvokabular zu ermitteln, sind Beschreibungen der Aufgabenmodelle (Tab.8, rechte Spalte) hilfreich. Diese weichen vom Vokabular her erfahrungsgemäß vom Wortschatz der Nutzer ab. Sie dienen primär der Ableitung von Nutzungsanforderungen, sind hier aber auch Quelle für Fachvokabular. Nutzungsanforderungen sind allerdings noch keine System- bzw. Produktmerk-male, denn eine Nutzungsanforderung sagt nichts darüber aus, wie Informationen im Interface dargestellt werden sollen. Diese Beschreibung von Vorgängen und Objekten des abzubildenden Be-reichs unabhängig von der software-technischen Lösung soll eine Immunisierung verhindern. Bereits die Recherche und Bezeichnung der Nutzungsszenarien erfordert sprachliche Sensibilität. Ziel muss es sein, dass alle Nutzungsszenarien die gleiche Granularität aufweisen und die Titel aller Szenarien semantisch-syntaktisch zueinander passen.
Aus den erarbeiteten Nutzungsszenarien können im Rahmen konstruktiver Qualitätssicherungsmaß-nahmen zu einem sehr frühen Zeitpunkt der Entwicklung Testfälle und Testdaten abgeleitet werden.
Ergebnis
Es ist eine Menge von Nutzungsszenarien beschrieben, die einen gleichen Granularitätsgrad besitzen.
Dafür sind mehrer Iterationen notwendig. Es sind arbeitsablaufbezogene Begrifflichkeiten der verschiedenen Nutzergruppen vorhanden. Diese entsprechen dem Wortschatz der Beschäftigten bei ihrer täglichen Arbeit. Die Begriffe werden für den Entwurf der Informationsarchitektur dokumentiert bzw. als Input für den Workshop benötigt. Dies sind in den Szenarien vorkommende Nutzungs-objekte, aber auch Verben. Die erhobenen Nutzungsszenarien mit dem dort verwendeten Fach-vokabular werden als Bestandteil des Nutzungskonzeptes dokumentiert. Aus den Nutzungsszenarien können Nutzungsanforderungen abgeleitet werden, diese sind nicht identisch mit Produktmerkmalen.
7.3.1.6 Extraktion aus vorliegenden Dokumenten
Die Terminologieextraktion erfolgt aus allen vorliegenden und neu erhobenen Materialien.
Dokumente, die im Zusammenhang mit der Software stehen, werden gesichtet und das Vokabular und dessen Hierarchien (fachlich relevante Substantive, Verben, Klassifizierungen, Definitionen, Gliede-rungen usw.) werden extrahiert. Dokumente können sein: Geschäftsprozessbeschreibungen, Be-nutzungsanleitungen, Schulungsunterlagen, Fachkonzepte, Systemarchitekturbeschreibung, Lasten- und Pflichtenhefte, Protokolle von Besprechungen, Klassenmodelle, Screenshots der derzeitigen Anwendung, Marketingmaterial usw. Neu erhobene Dokumente sind der Entwurf des Nutzungs-konzeptes, der aus validiertem Material der Analyse besteht, und das Ergebnis der terminologischen Experteninspektion. Es kann auch hilfreich sein, entsprechendes Material von Konkurrenzprodukten zu sichten.
Ergebnis
Die extrahierte Terminologie und das Vokabular ist in einer alphabetisch sortierten Tabelle aufgelistet. Die Tabelle enthält fachlich relevante Substantive, Verben, Adjektive und andere sprachliche Elemente, aber auch Klassifizierungen wie Status, Definitionen, Gliederungen usw.
Darüber hinaus können hier nutzergruppenspezifische Unterschiede im Vokabular oder auch optio-nale Begriffskonstellationen dokumentiert werden.
7.3.1.7 Konsolidierung und Bereinigung
Das erfasste Vokabular wird vom Experten eventuell in Zusammenarbeit mit Vertretern der Nutzer gesichtet und nach
fachlichen
syntaktischen
semantischen
pragmatischen und
prozessualen
Kriterien kritisch überprüft und bereinigt (siehe Anhang B). Es werden dabei jedoch nur in Ausnahmefällen Bezeichnungen verworfen. Die auftretenden Inkonsistenzen und Fragen werden im Rahmen der Workshops mit Vertretern der jeweils davon betroffenen Nutzergruppen diskutiert und ggf. in Benennungen für das User Interface transformiert.
Ergebnis
Es liegt eine konsolidierte und bereinigte Version von Bezeichnungen und ihren ggf. hierarchischen Anordnungen vor, die in den Workshops als Diskussionsgrundlage dienen. Ggf. liegen bereits Vor-schläge für Benennungen vor, aber auch offene Punkte zur Klärung in den Workshops.
Workshops zur Begriffsklärung und Benennungsfindung
Unter Workshop wird hier ein zeitlich eng begrenztes Treffen von jeweils relevanten Personen unter Moderation eines Experten verstanden. Es ist sinnvoll, wenn dies der Experte ist, der auch die terminologische Inspektion durchgeführt hat. Die Workshops dienen dazu, das vorstrukturierte Vokabular dahingehend zu bearbeiten, das subjektive Verzerrungen aufgedeckt oder Widersprüche identifiziert werden. Es gehört zum Wesen ergonomischer Regeln, Widersprüche zu erzeugen. Mit diesem Vokabular können dazu von verschiedenen Nutzergruppen Concept Maps erstellt werden. Der moderierende Experte hat ebenfalls die Möglichkeit, einen eigenen Entwurf einer Concept Map vorzulegen. Alternativ können auch Artefakt-Modelle skizziert werden. Aus den erarbeiteten Dar-stellungen wird ein für alle Beteiligten akzeptierbares Nutzer-Objekt-Modell entwickelt. Dies entsteht also in zwei Schritten. In einem ersten Schritt werden die mentalen Modelle der einzelnen Nutzer expliziert, unterstützt durch die Erhebung ihres Wortschatzes. Danach wird das spezifische Vokabular
der verschiedenen Nutzergruppen recherchiert. Das Modell beschreibt die Objekte und Aktionen des Arbeitshandels, die Sichten und Zustände die auf diese Objekte vorhanden sind sowie die Interaktionen die Nutzer mit diesen Objekten haben. Entscheidend ist, dass die verschiedenen Sichten der Nutzergruppen hier sprachlich zusammengeführt werden. Es handelt sich also nicht um die Explizierung der mentalen Modelle einzelner Nutzer, sondern um das Modell der (im Nutzungs-konzept priorisierten) Nutzergruppen. Das Modell besteht aus Begriffen mit denen Gegenstände oder Sachverhalte bezeichnet werden und ist damit Basis für grundlegende Entscheidungen der User-Interface-Gestaltung, d.h. der Gliederung der Anwendung in Menüs, Dialoge und Ansichten, bzw.
der Sitestruktur, Verwendung der GUI-Elemente und der Wahl der passenden Metapher. Es handelt sich um eine grafische Darstellung, wobei die einzelnen Elemente mit Benennungen versehen sind, die übergreifend oder nutzergruppenspezifisch sein können. Wenn Bezeichnungen unabhängig von Inhalten sein sollen, muss man in der Ermittlung buttom-up vorgehen, d.h. zuerst die Unterbe-zeichnungen herausfinden und dann die Top-Level-BeUnterbe-zeichnungen wählen. Es können mehrere Workshops notwendig sein, weil offene fachliche Fragen geklärt werden müssen.
Ergebnis
Fachliche Fragen sind geklärt und validierte Informationsarchitektur (Begriffshierarchien, Katego-rien) sowie Vorschläge für abzuleitende Benennungen (Label) liegen vor.
Concept Maps
Die Idee der Verwendung von Concept Maps (vgl. Nückles 2004) besteht in Bezug auf das Verfahren darin, die existierenden Arbeitszusammenhänge bzw. deren Abbildung in der Software von Nutzern visualisieren zu lassen. Es wird davon ausgegangen, dass bei der Visualisierung mentale Modelle der Nutzer bzw. Begriffe und deren Zusammenhänge hervortreten. Diese Zusammenhänge sind dann als Grundlage für die Anforderungsermittlung zu verwenden. In Concept Maps werden Begriffe und ihre Beziehungen zueinander zweidimensional, wie Orte und Wege auf einer Landkarte, repräsentiert. Auf diese Weise kann grafisch dargestellt werden, in welchen Beziehungen die Begriffe zueinander stehen. Im Unterschied zu einer Mind Map werden die Beziehungen zwischen den Begriffen benannt.
Bei Concept Maps muss nicht ein einziger Zentralbegriff existieren, wie dies bei Mind Maps üblich ist. Außerdem ist es nicht notwendig, die Arten der Beziehungen (wie „ist Teil von“) streng formal festzulegen. Ausgehend davon, dass die visuelle Darstellung der Nutzer in Form einer Concept Map gleichbedeutend mit der Absicht zur Kommunikation ist, werden von dieser Ausdrucksform zusätz-liche Impulse für die nutzungszentrierte Anforderungsermittlung erwartet.
Die Aufgabenstellung lautet: „Erstellen Sie eine Begriffslandkarte52 für die Aufgabe xy. Zeichnen Sie mit wenigen Kästchen, Kreisen und Strichen Ihre Sicht der Aufgabe, die durch die in Rede stehende Software unterstützt werden soll und benennen Sie diese Elemente“. Es kann auch sinnvoll sein,
52 Es wird hier der Nutzern besser verständliche Terminus Begriff(-slandkarte) verwendet.
Nutzer darum zu bitten, eine Concept Map der Software zu erstellen. Das Ergebnis wird naturgemäß von Benennungen des vorhandenen User Interface dominiert sein. Umso interessanter sind dann Abweichungen.
Die Auswertung der erstellten Concept Maps erfolgt auf Grundlage der Gestaltgesetze (vgl.
Wertheimer 1921). Die Gestaltgesetze beziehen sich nicht auf Inhalte, sondern auf abstrakte Muster, Zusammenhänge, Eigenschaften und Verhältnisse. Hintergrund ist die Erkenntnis, dass sich in der menschlichen Wahrnehmung immer eine Gliederung durchsetzt, die von den sogenannten
„Ganzheitseigenschaften“ bestimmt ist. Dies bedeutet Einfachheit, Regelmäßigkeit, Symmetrie und inneres Gleichgewicht der Darstellung. Durch die Gestaltung von Informationen nach diesen Kriterien spart sich der Mensch das zeitaufwändige Punkt-für-Punkt-Abtasten einer Gestalt. Er erkennt die Information anhand ihrer äußeren Gestalt schnell wieder. Bei der Interfacegestaltung werden diese Erkenntnisse zum Layout von Bildschirmmasken oder Webseiten herangezogen. Im Zusammenhang mit der Anforderungsermittlung sind die Gestaltgesetze bisher nur unter dem Kon-zept der Strukturgeometrie von Mletzkos angewandt worden (vgl. Mletzkos 1999). Hier sollen sie wie folgt der Interpretation der Concept Maps dienen:
Gesetz der Nähe
In einer Menge gleichartiger Elemente schließen sich in unserer Wahrnehmung die räumlich nahe beieinander liegenden zusammen, auch wenn sie sich in Form, Größe, Farbe unter-scheiden. Das heißt, dass Nutzer für sie logisch zusammengehörige Informationen auch örtlich zusammen gruppieren werden. Unterschiede in der Hierarchie könnten durch räum-liche Trennung dargestellt werden. Zusammengehöriges wird stets nahe beieinander gezeichnet.
Gesetz der Gleichartigkeit
Bei Darbietung verschiedener Elemente werden gleiche oder gleichartige Elemente in einer Gruppe zusammengefasst wahrgenommen. Dies bedeutet, dass z.B. bei gleichen Umrissen von Elementen (Dreieck, Kreis) anzunehmen ist, dass ein Zusammenhang zwischen diesen Elementen besteht.
Gesetz der guten Fortsetzung
Die menschliche Wahrnehmung neigt dazu, z.B. beim Betrachten von einer kurz unter-brochenen Kreislinie eine gute Fortsetzung, nämlich einen kompletten Kreis, wahrzunehmen.
Bei einer Visualisierung von Zusammenhängen kann dies so interpretiert werden, dass räum-lich stark abgesetzten Informationen oder Objekten eine abweichende Bedeutung zugemessen wird.
Gesetz der Symmetrie
Der Mensch bevorzugt in seiner Wahrnehmung gute, d.h. symmetrische Gestalten. Dies ist
so anzuwenden, dass eine Information im Mittelpunkt des Bildbereichs das Hauptaugenmerk auf sich lenkt und damit als Mittelpunkt der darzustellenden Informationen gewertet wird.
Ergebnis
Es liegt ein in grafischer Form visualisiertes Modell des Arbeitskontextes vor. Dies dient der Expli-zierung der mentalen Modelle der Nutzer über ihren Arbeitskontext.
Artefakt-Modell
Alternativ zu den o.g. Concept Maps können Artefakt-Modelle entwickelt werden. Die Idee des Artefakt-Modells stammt aus dem Contextual Design von Beyer und Holtzblatt (vgl. Beyer/ Holtz-blatt 1998), einem umfassenden Ansatz innerhalb der partizipativen Systementwicklung. Es ist eines von fünf verschiedenen Modellen, die dort verwendet werden. Diese Arbeitsmodelle dienen dazu, aus den zuvor stattgefundenen Interviews mit Nutzern Muster, Regelmäßigkeiten und Strukturen heraus-zuarbeiten. Diese Modelle werden dann in Diagrammen abgebildet und so die konkreten Arbeits-abläufe für den folgenden Designprozess in Kategorien anschaulich dargestellt. Im Artefakt-Modell werden von Nutzern verwendete Artefakte, d.h. Arbeitsmittel aller Art, in ihrer Funktionsweise dargestellt. Wie die Arbeit von den Betroffenen organisiert und strukturiert wird, kann beispielsweise anhand der Gestaltung eines Terminkalenders mit Strukturen, Abläufen und Ähnlichem gezeigt werden. Hier soll die Darstellung, die zusammen mit mehreren Nutzern in einem Workshop erarbeitet wird, dazu dienen, Begriffe und Abläufe zu explizieren.
Ergebnis
Visualisierung des Arbeitskontextes mit Hilfe eines Artefaktes, das stellvertretend für die Anwendung steht. Dies dient außerdem der Explizierung der mentalen Modelle der Nutzer über ihren Arbeits-kontext.
Screenshot-Übermalung
Wenn ein Altsystem vorhanden ist, kann die Screenshot-Übermalung durch Nutzer ein effektives Instrument sein, Impulse für die Informationsarchitektur zu bekommen. Hierzu werden von den Hauptmasken bzw. Webseiten Screenshots erstellt; die darauf befindlichen sprachlichen Elemente werden geschwärzt. In einem Workshop, an dem jeweils zwei bis drei Vertreter der Nutzergruppen teilnehmen, werden die Teilnehmer gruppenweise aufgefordert, den jeweiligen Screenshots Überschriften zu geben und sprachliche Elemente einzutragen, die ihnen richtig erscheinen. Im An-schluss daran werden Gemeinsamkeiten und Unterschiede der Varianten im Plenum herausgearbeitet;
es wird ggf. versucht, eine gemeinsame Version zu finden.
Ergebnis
Herausfinden von Begrifflichkeiten und Erwartungen der Nutzer. Auch diese Aktivität dient der Explizierung der mentalen Modelle der Nutzer über ihren Arbeitskontext.