https://glossar.hs-augsburg.de/w/api.php?action=feedcontributions&feedformat=atom&user=Borchert 2026-07-17T14:16:05Z Benutzerbeiträge MediaWiki 1.43.3 https://glossar.hs-augsburg.de/w/index.php?title=Gebrauchstauglichkeit&diff=11972 2008-07-06T14:09:39Z

<p>Borchert: /* Definition gemäß ISO/IEC 9126 */</p> <hr /> <div>=Definition gemäß DIN EN ISO 9241=<br /> <br /> „Gebrauchstauglichkeit oder Usability bezeichnet die Eignung eines Produktes bei der Nutzung durch bestimmte [[Benutzer]] in einem bestimmten [[Benutzungskontext]] die vorgegebenen Ziele effektiv, effizient und zufriedenstellend zu erreichen. Der Nutzungskontext besteht aus den Benutzern, Arbeitsaufgaben, Arbeitsmitteln ([[Hardware]], [[Software]] und Materialien) sowie der physischen und sozialen Umgebung, in der das Produkt eingesetzt wird.<br /> Die [[DIN EN ISO 9241]] -Teil 11, und [[DIN 55350-11]], 1995-08, Nr. 4 benutzen diese Definition.<br /> Die Gebrauchstauglichkeit beruht unter anderem auf [[Gebrauchseigenschaften]] und den Bedürfnissen des Nutzers; somit gibt es neben einer objektiven Beurteilung auch eine subjektive Beurteilung, die von Individuum zu Individuum sehr unterschiedlich ausfallen kann.“<br /> <br /> =Definition gemäß ISO/IEC 9126=<br /> Der ISO/IEC 9126 Standard enthält Definitionen für wesentliche Begriffe aus dem Bereich der Software-Qualität. Das darin definierte Qualitätsmodell lässt sich zur Messung dieser anwenden und umfasst folgende sechs Kategorien: <br /> <br /> *Funktionalität <br /> *Zuverlässigkeit <br /> *Benutzbarkeit <br /> *Effizienz <br /> *Wartbarkeit <br /> *Übertragbarkeit <br /> <br /> Insbesondere wird auch noch zwischen externer und interner Qualität sowie Nutzungsqualität von Software unterschieden. Darüber hinaus werden auch deren Zusammenhänge aufgezeigt.<br /> <br /> [[Medium:ISO 9126.jpg|Zusammenhang zwischen externer, interner Qualität sowie Nutzungsqualität bei Software nach ISO/IEC 9126.]]<br /> <br /> ==Interne Qualität==<br /> '''Interne Qualität''' einer Software bezeichnet hierbei die Gesamtheit statischer Qualitätsaspekte der Software (z.B. Quellcode, Entwurfsdokumente). Typische Qualitätsmerkmale sind etwa die Wartbarkeit, leichte Übertragbarkeit und hohe Effizienz. Typischerweise sind Software-Entwickler an solchen Eigenschaften interessiert. <br /> <br /> ==Externe Qualität== <br /> Die '''externe Qualität''' einer Software bezieht sich dagegen auf die Ausführung derselben. Diese Sichtweise entspricht der des generellen Endbenutzers auf ein Endprodukt. <br /> Sie ist Ausdruck dafür, inwieweit das Produkt in der Lage ist, explizite und implizite Anforderungen des Users zu erfüllen. Kriterien umfassen hierbei z.B. die Benutzbarkeit des <br /> Produkts, inwieweit es konsistent zu anderen Produkten ist oder ob es selbsterklärend ist. <br /> <br /> ==Nutzungsqualität== <br /> Der Begriff der '''Nutzungsqualität''' reflektiert die Sicht eines Users auf die Software in einer bestimmten Nutzungsumgebung und beurteilt das Produkt hinsichtlich der Fähigkeit, ihn bei der Lösung seiner Aufgaben zu unterstützen. Der Unterschied zur externen Qualität besteht darin, dass auf einen bestimmten Nutzungskontext mit ganz spezifischen Aufgabenstellungen Bezug genommen wird.<br /> <br /> =Quellen=<br /> *[[DIN Deutsches Institut für Normung e.V. (2004): DIN-Taschenbuch 354 ‒ Software-Ergonomie]]<br /> *Bevan, Nigel (1999): Quality in Use: Meeting User Needs for Quality, in Journal of System and Software 1999 S.1 – 14 <br /> <br /> =Siehe auch=<br /> *[[Shneiderman, Ben (1998): Designing the User Interface ‒ Strategies for Effective Human-Computer-Interaction]]<br /> *[[Nielsen, Jakob (2001): Designing Web Usability]]<br /> *[http://www.useit.com/papers/heuristic/heuristic_list.html Heuristics for User Interface Design]<br /> *[http://www.usabilitynet.org/papers/qiuse.pdf Quality in Use: Meeting User Needs for Quality]<br /> <br /> <br /> <br /> [[Kategorie:HCI]]<br /> [[Kategorie:Glossar]]<br /> <br /> {{{{SITENAME}}-konformer Artikel}}</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Gebrauchstauglichkeit&diff=11971 2008-07-06T14:07:18Z

<p>Borchert: </p> <hr /> <div>=Definition gemäß DIN EN ISO 9241=<br /> <br /> „Gebrauchstauglichkeit oder Usability bezeichnet die Eignung eines Produktes bei der Nutzung durch bestimmte [[Benutzer]] in einem bestimmten [[Benutzungskontext]] die vorgegebenen Ziele effektiv, effizient und zufriedenstellend zu erreichen. Der Nutzungskontext besteht aus den Benutzern, Arbeitsaufgaben, Arbeitsmitteln ([[Hardware]], [[Software]] und Materialien) sowie der physischen und sozialen Umgebung, in der das Produkt eingesetzt wird.<br /> Die [[DIN EN ISO 9241]] -Teil 11, und [[DIN 55350-11]], 1995-08, Nr. 4 benutzen diese Definition.<br /> Die Gebrauchstauglichkeit beruht unter anderem auf [[Gebrauchseigenschaften]] und den Bedürfnissen des Nutzers; somit gibt es neben einer objektiven Beurteilung auch eine subjektive Beurteilung, die von Individuum zu Individuum sehr unterschiedlich ausfallen kann.“<br /> <br /> =Definition gemäß ISO/IEC 9126=<br /> Der ISO/IEC 9126 Standard enthält Definitionen für wesentliche Begriffe aus dem Bereich der Software-Qualität. Das darin definierte Qualitätsmodell lässt sich zur Messung dieser anwenden und umfasst folgende sechs Kategorien: <br /> <br /> *Funktionalität <br /> *Zuverlässigkeit <br /> *Benutzbarkeit <br /> *Effizienz <br /> *Wartbarkeit <br /> *Übertragbarkeit <br /> <br /> Insbesondere wird auch noch zwischen externer und interner Qualität sowie Nutzungsqualität von Software unterschieden. Darüber hinaus werden auch deren Zusammenhänge aufgezeigt.<br /> <br /> [[Medium:ISO 9126.jpg]]<br /> <br /> ==Interne Qualität==<br /> '''Interne Qualität''' einer Software bezeichnet hierbei die Gesamtheit statischer Qualitätsaspekte der Software (z.B. Quellcode, Entwurfsdokumente). Typische Qualitätsmerkmale sind etwa die Wartbarkeit, leichte Übertragbarkeit und hohe Effizienz. Typischerweise sind Software-Entwickler an solchen Eigenschaften interessiert. <br /> <br /> ==Externe Qualität== <br /> Die '''externe Qualität''' einer Software bezieht sich dagegen auf die Ausführung derselben. Diese Sichtweise entspricht der des generellen Endbenutzers auf ein Endprodukt. <br /> Sie ist Ausdruck dafür, inwieweit das Produkt in der Lage ist, explizite und implizite Anforderungen des Users zu erfüllen. Kriterien umfassen hierbei z.B. die Benutzbarkeit des <br /> Produkts, inwieweit es konsistent zu anderen Produkten ist oder ob es selbsterklärend ist. <br /> <br /> ==Nutzungsqualität== <br /> Der Begriff der '''Nutzungsqualität''' reflektiert die Sicht eines Users auf die Software in einer bestimmten Nutzungsumgebung und beurteilt das Produkt hinsichtlich der Fähigkeit, ihn bei der Lösung seiner Aufgaben zu unterstützen. Der Unterschied zur externen Qualität besteht darin, dass auf einen bestimmten Nutzungskontext mit ganz spezifischen Aufgabenstellungen Bezug genommen wird. <br /> <br /> <br /> =Quellen=<br /> *[[DIN Deutsches Institut für Normung e.V. (2004): DIN-Taschenbuch 354 ‒ Software-Ergonomie]]<br /> *Bevan, Nigel (1999): Quality in Use: Meeting User Needs for Quality, in Journal of System and Software 1999 S.1 – 14 <br /> <br /> =Siehe auch=<br /> *[[Shneiderman, Ben (1998): Designing the User Interface ‒ Strategies for Effective Human-Computer-Interaction]]<br /> *[[Nielsen, Jakob (2001): Designing Web Usability]]<br /> *[http://www.useit.com/papers/heuristic/heuristic_list.html Heuristics for User Interface Design]<br /> *[http://www.usabilitynet.org/papers/qiuse.pdf Quality in Use: Meeting User Needs for Quality]<br /> <br /> <br /> <br /> [[Kategorie:HCI]]<br /> [[Kategorie:Glossar]]<br /> <br /> {{{{SITENAME}}-konformer Artikel}}</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Datei:ISO_9126.jpg&diff=11970 2008-07-06T13:57:02Z

<p>Borchert: Zusammenhang zwischen externer, interner Qualität sowie Nutzungsqualität bei Software nach ISO/IEC 9126.</p> <hr /> <div>Zusammenhang zwischen externer, interner Qualität sowie Nutzungsqualität bei Software nach ISO/IEC 9126.</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Nielsen_J.;_Mack,_R._(1994):_Usability_Inspection_Methods&diff=11933 2008-07-05T10:23:46Z

<p>Borchert: </p> <hr /> <div>{{Quelle:Buch <br /> | key = Nielsen et al. (1994)<br /> | authors = Jakob Nielsen, Robert L. Mack <br /> | title = Usability Inspection Methods<br /> | year = 1994<br /> | publisher = John Wiley &amp; Sons, Inc.<br /> | isbn = 0471018775<br /> }}</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Heuristische_Evaluation&diff=11932 2008-07-05T09:09:58Z

<p>Borchert: /* Quellen */</p> <hr /> <div>=Definition=<br /> Bei der '''heuristischen Evaluation''' handelt es sich um eine systematische Usability-Inspektionsmethode um Usability-Probleme in einem User-Interface Design zu finden. <br /> Zur heuristischen Evaluation gehört immer eine kleine Gruppe von (Usability-)Experten die die Gebrauchsfähigkeit bzw. Konformität des Interfaces begutachtet und anhand von allgemeinen und einfachen Kriterien - den Heuristiken - beurteilt.<br /> <br /> =Evaluatoren=<br /> Da ein Evaluator nur rund 35% der Usability-Probleme eine Interfaces findet ist es sinnvoll mit mehreren Evaluatoren zu arbeiten. Nielsen und Molich schlagen in ihren Arbeiten für eine Evaluation drei bis fünf Evaluatoren vor, da kaum noch zusätzliche Informationen durch eine größere Zahl von Evaluatoren gewonnen wird.<br /> Bei der Auswahl der Evaluatoren sollte berücksichtig werden, dass sich die Auswahl verschiedener Evaluatoren positiv auf das Finden von Problemen auswirkt,was auch Studienergebnisse von Nielsen und Molich belegen. So sollten unter den Evaluatoren zwar hauptsächlich Experten sein die sich mit Usability beschäftigen, aber wenn es möglich ist auch ein End-User bzw. ein Experte der sich mit dem Anwendungsgebiet für das das System gedacht ist auskennt um eventuelle, spezielle Usability-Probleme zu finden.<br /> <br /> Die exakte Zahl der Evaluatoren die tatsächlich für eine heuristische Evaluation herangezogen werden hängt allerdings auch sehr stark von der Kosten-Nutzen-Analyse ab, die für jedes System anderes ausfällt und somit neu berechnet wird. Sie errechnet sich aus Fixkosten und variablen Kosten. Die Fixkosten ergeben sich aus dem Preis der benötigten Materialien, der Planungszeit und dem Schreiben des Reportes. Sie betragen meist zwischen $3,700 und $4,800. Dazu kommen die variablen Kosten, wie der Lohn pro Evaluator, die Analyse der einzelnen Reporte, die Kosten der Hilfsmittel u.a. Diese Kosten bewegen sich zwischen $410 und $900 pro Evaluator<br /> <br /> =Heuristiken=<br /> Die Heuristiken dienen bzw. helfen den Evaluatoren bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist.Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden.<br /> <br /> Als Beispiel für allgemeine Heuristiken diente die folgende 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt , aber 1994 nochmals von Nielsen, nach mehreren Studien, verfeinert wurde. <br /> <br /> *''Sichtbarkeit des Systemstatus'' - Das System sollte dem User mit angebrachten Infos fortwährende mitteilen was geschieht <br /> <br /> *''Anpassung zwischen System und reeller Welt'' - Das System sollte in Wort und Phrase die Sprache der Anwender sprechen und nicht zu systemorientiert sein<br /> <br /> *''Benutzerkontrolle und –freiheit'' - Da User öfter mal Fehler machen sollte das System hierfür „Emergency Exits“ haben, sowie Undo- und Redo-Funktionen<br /> <br /> *''Konsistenz und Standards'' - Das System sollte Konsistent sein und bestimmten Standards folgen, damit sich der User immer zurechtfindet<br /> <br /> *''Fehler vermeiden'' - Besser als jede gute Fehlermeldung ist die Vermeidung von Fehlern<br /> <br /> *''Wiedererkennen statt sich erinnern'' - Die Bedienung sollte soweit es geht selbsterklärend sein ohne das sich der User groß erinnern muss. Auch sollte er sich nicht Informationen von einem Dialog für einen anderen merken müssen.<br /> <br /> *''Flexibilität und Effizienz'' - Für erfahrene User sollte es Abkürzungen geben die das Arbeiten mit dem System beschleunigen. Die „Shortcuts“ sollten allerdings Anfänger nicht verwirren. User sollten sich auch von ihnen häufig verwendete Funktionen speziell zurechtlegen können.<br /> <br /> *''Ästhetik und minimalistisches Design'' - Dialoge sollten notwendige Informationen enthalten. Jede zusätzliche Information lenkt nur von den Fakten ab und hält den Benutzer auf.<br /> <br /> *''Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern'' - Fehlermeldungen sollten in verständlicher Sprache sein, das Problem genau beschreiben und Lösung vorschlagen<br /> <br /> *''Hilfe und Dokumentation'' - Selbst wenn der User für die Nutzung des System keinerlei Unterstützung bedarf, sollte es doch, gerade bei komplexen Interfaces, gute Dokumentation geben die in die Struktur integriert sind. Eine Hilfe an entsprechender Stelle sollte sowohl kontextabhängig als auch verständlich verfasst sein und konstruktive Lösungsansätze bieten.<br /> <br /> =Durchführung=<br /> Bei der Evaluation selbst geht jeder Experte das Interface mehrmals durch und begutachtet die verschiedenen Dialogelemente und vergleicht diese dabei mit allgemeinen und/oder speziellen Heuristiken bzw. Usability-Prinzipien. Die Evaluatoren entscheiden selbst wie sie das Interface durchgehen, meistens zweimal. Beim ersten Durchlauf um ein Gefühl für das Interface und den allgemeinen Anwendungsbereich des Systems zu bekommen. Beim Zweiten achten sie dann auf spezielle Interface-Elemente und wie diese ins Gesamtbild passen.<br /> <br /> Erst nachdem alle Evaluationen abgeschlossen sind dürfen sich die Experten untereinander austauschen und ihre Ergebnisse zusammenführen. Dieses Verfahren ist Notwendig um sicherzustellen, dass die Evaluationen der einzelnen Personen unabhängig und vorurteilsfrei sind. Eine Evaluation eines Experten sollte durchschnittliche 1 bis 2 Stunden dauern. Sollte es durch die Komplexität des Produkts notwendig sein eine längere Evaluation abzuhalten, so ist es sinnvoll diese in mehrere kleinere aufzuspalten, welche sich dann jeweils nur mit einem bestimmten Aspekt beschäftigen. <br /> <br /> Die Erfassung der Evaluationen kann auf verschiedene Weiser geschehen. Zum einen als geschriebener Bericht des Evaluatoren selbst, was den Aufwand für den Evaluator selbst erhöht da er sich nicht ausschließlich auf das Interface konzentrieren kann, dafür erhält man aber einen formalen Bericht.<br /> Zum anderen eine Erfassung durch einen Beobachter, dem der Evaluator während er das Interface begutachtet seine Ergebnisse sagt und dieser sie schriftlich festhält. Hierbei sollten die Evaluatoren dem Beobachter allerdings alle von ihnen gefundenen Verstöße gegen die Heuristiken einzeln mitteilen, was in der Praxis nicht immer so problemlos klappt, da sie mehr mit dem Finden von Fehlern als der Mitteilung dieser beschäftigt sind. Der Beobachter darf darüber hinaus die Ergebnisse und Kommentare nur erfassen, sie aber nicht selber bewerten wie beim zum User-Testing. <br /> Trotzdem bringt diese Form der Erfassung viele Vorteile mit sich. Sie reduziert zum einen die Arbeitslast für den Evaluator, zum anderen braucht der Beobachter nur ein Set von Notizen zu bearbeiten, das er dazu noch selbst geschrieben hat. Ein Ergebnis der gesamten Evaluation steht dadurch auch schneller zu Verfügung. <br /> <br /> Eine Evaluation mit Beobachter hat auch noch den Vorteil, dass der Beobachter Fragen während der Evaluation beantworten kann und auch soll, aber nur solche die das Anwendungsgebiet des Interfaces betreffen. Dies hat vor allem Vorteile für Evaluatoren die keine Experten auf diesem Gebiet sind. Zum anderen kann der Beobachter auch Hinweise zum Gebrauch des Interfaces geben, falls es zu Problemen bei der Nutzung kommt. Dadurch wird auch teure und kostbare Evaluationszeit gespart. Allerdings muss noch erwähnt werden, dass der Beobachter den Evaluatoren von sich selbst aus erst Hilfe geben darf, wenn sie in richtigen Schwierigkeiten sind und sie sich zu dem aufgetretenen Usability-Problem geäußert haben. Um dies alles zu Garantieren muss der für die Evaluation gewählte Beobachten eine Experte auf diesem Gebiet sein und sich natürlich auch mit dem Interface sehr gut auskennen.<br /> <br /> =Ergebnis=<br /> Das Ergebnis einer Heuristischen Evaluation ist eine Liste der gefundenen Usability-Probleme. Da diese Liste die einzelnen Meinungen der Evaluatoren wieder spiegelt, müssen diese, in Verbindung mit den Heuristiken oder anderen Usability-Ergebnissen, erklären warum sie etwas nicht mochten oder was ihnen nicht gefiel. Allerdings zeigt diese Methode keinen gezielten Ansatz zur Lösung der gefundenen Probleme auf <br /> <br /> =Erweiterung=<br /> Als Erweiterung der einfachen Liste von Usability-Problemen eines Interfaces, die man als Ergebnis aus der Heuristischen Evaluation erhält gibt es die Möglichkeit die schwere der einzelnen Probleme zu gewichten, das so genannte [http://glossar.fh-augsburg.de/Severity_Ranking Severity Ranking]. <br /> <br /> =Quellen=<br /> *[http://glossar.fh-augsburg.de/Nielsen%2C_Jakob_(1993):_Usability_Engineering Nielsen, Jakob (1993): Usability Engineering]<br /> *[http://glossar.fh-augsburg.de/Nielsen_et_al._(1994):_Usability_Inspection_Methods Nielsen et al. (1994): Usability Inspection Methods]<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516<br /> <br /> =Links=<br /> *[http://www.useit.com/papers/heuristic/heuristic_evaluation.html Nielsen, J.: Heuristic Evaluation]<br /> *[http://www.useit.com/papers/heuristic/heuristic_list.html Heuristics for User Interface Design]<br /> *[http://www.fit-fuer-usability.de/1x1/messen/heuristik.html Über den Daumen: Heuristische Evaluation]<br /> <br /> [[Kategorie:HCI]]<br /> [[Kategorie:Content-Management-System]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Nielsen_J.;_Mack,_R._(1994):_Usability_Inspection_Methods&diff=11931 2008-07-05T09:08:42Z

<p>Borchert: </p> <hr /> <div>{{Quelle:Buch <br /> | key = Nielsen et al. (1994): Usability Inspection Methods<br /> | authors = Jakob Nielsen, Robert L. Mack <br /> | title = Usability Inspection Methods<br /> | year = 1994<br /> | publisher = John Wiley &amp; Sons, Inc.<br /> | isbn = 0471018775<br /> }}</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Heuristische_Evaluation&diff=11930 2008-07-05T08:55:50Z

<p>Borchert: /* Quellen */</p> <hr /> <div>=Definition=<br /> Bei der '''heuristischen Evaluation''' handelt es sich um eine systematische Usability-Inspektionsmethode um Usability-Probleme in einem User-Interface Design zu finden. <br /> Zur heuristischen Evaluation gehört immer eine kleine Gruppe von (Usability-)Experten die die Gebrauchsfähigkeit bzw. Konformität des Interfaces begutachtet und anhand von allgemeinen und einfachen Kriterien - den Heuristiken - beurteilt.<br /> <br /> =Evaluatoren=<br /> Da ein Evaluator nur rund 35% der Usability-Probleme eine Interfaces findet ist es sinnvoll mit mehreren Evaluatoren zu arbeiten. Nielsen und Molich schlagen in ihren Arbeiten für eine Evaluation drei bis fünf Evaluatoren vor, da kaum noch zusätzliche Informationen durch eine größere Zahl von Evaluatoren gewonnen wird.<br /> Bei der Auswahl der Evaluatoren sollte berücksichtig werden, dass sich die Auswahl verschiedener Evaluatoren positiv auf das Finden von Problemen auswirkt,was auch Studienergebnisse von Nielsen und Molich belegen. So sollten unter den Evaluatoren zwar hauptsächlich Experten sein die sich mit Usability beschäftigen, aber wenn es möglich ist auch ein End-User bzw. ein Experte der sich mit dem Anwendungsgebiet für das das System gedacht ist auskennt um eventuelle, spezielle Usability-Probleme zu finden.<br /> <br /> Die exakte Zahl der Evaluatoren die tatsächlich für eine heuristische Evaluation herangezogen werden hängt allerdings auch sehr stark von der Kosten-Nutzen-Analyse ab, die für jedes System anderes ausfällt und somit neu berechnet wird. Sie errechnet sich aus Fixkosten und variablen Kosten. Die Fixkosten ergeben sich aus dem Preis der benötigten Materialien, der Planungszeit und dem Schreiben des Reportes. Sie betragen meist zwischen $3,700 und $4,800. Dazu kommen die variablen Kosten, wie der Lohn pro Evaluator, die Analyse der einzelnen Reporte, die Kosten der Hilfsmittel u.a. Diese Kosten bewegen sich zwischen $410 und $900 pro Evaluator<br /> <br /> =Heuristiken=<br /> Die Heuristiken dienen bzw. helfen den Evaluatoren bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist.Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden.<br /> <br /> Als Beispiel für allgemeine Heuristiken diente die folgende 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt , aber 1994 nochmals von Nielsen, nach mehreren Studien, verfeinert wurde. <br /> <br /> *''Sichtbarkeit des Systemstatus'' - Das System sollte dem User mit angebrachten Infos fortwährende mitteilen was geschieht <br /> <br /> *''Anpassung zwischen System und reeller Welt'' - Das System sollte in Wort und Phrase die Sprache der Anwender sprechen und nicht zu systemorientiert sein<br /> <br /> *''Benutzerkontrolle und –freiheit'' - Da User öfter mal Fehler machen sollte das System hierfür „Emergency Exits“ haben, sowie Undo- und Redo-Funktionen<br /> <br /> *''Konsistenz und Standards'' - Das System sollte Konsistent sein und bestimmten Standards folgen, damit sich der User immer zurechtfindet<br /> <br /> *''Fehler vermeiden'' - Besser als jede gute Fehlermeldung ist die Vermeidung von Fehlern<br /> <br /> *''Wiedererkennen statt sich erinnern'' - Die Bedienung sollte soweit es geht selbsterklärend sein ohne das sich der User groß erinnern muss. Auch sollte er sich nicht Informationen von einem Dialog für einen anderen merken müssen.<br /> <br /> *''Flexibilität und Effizienz'' - Für erfahrene User sollte es Abkürzungen geben die das Arbeiten mit dem System beschleunigen. Die „Shortcuts“ sollten allerdings Anfänger nicht verwirren. User sollten sich auch von ihnen häufig verwendete Funktionen speziell zurechtlegen können.<br /> <br /> *''Ästhetik und minimalistisches Design'' - Dialoge sollten notwendige Informationen enthalten. Jede zusätzliche Information lenkt nur von den Fakten ab und hält den Benutzer auf.<br /> <br /> *''Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern'' - Fehlermeldungen sollten in verständlicher Sprache sein, das Problem genau beschreiben und Lösung vorschlagen<br /> <br /> *''Hilfe und Dokumentation'' - Selbst wenn der User für die Nutzung des System keinerlei Unterstützung bedarf, sollte es doch, gerade bei komplexen Interfaces, gute Dokumentation geben die in die Struktur integriert sind. Eine Hilfe an entsprechender Stelle sollte sowohl kontextabhängig als auch verständlich verfasst sein und konstruktive Lösungsansätze bieten.<br /> <br /> =Durchführung=<br /> Bei der Evaluation selbst geht jeder Experte das Interface mehrmals durch und begutachtet die verschiedenen Dialogelemente und vergleicht diese dabei mit allgemeinen und/oder speziellen Heuristiken bzw. Usability-Prinzipien. Die Evaluatoren entscheiden selbst wie sie das Interface durchgehen, meistens zweimal. Beim ersten Durchlauf um ein Gefühl für das Interface und den allgemeinen Anwendungsbereich des Systems zu bekommen. Beim Zweiten achten sie dann auf spezielle Interface-Elemente und wie diese ins Gesamtbild passen.<br /> <br /> Erst nachdem alle Evaluationen abgeschlossen sind dürfen sich die Experten untereinander austauschen und ihre Ergebnisse zusammenführen. Dieses Verfahren ist Notwendig um sicherzustellen, dass die Evaluationen der einzelnen Personen unabhängig und vorurteilsfrei sind. Eine Evaluation eines Experten sollte durchschnittliche 1 bis 2 Stunden dauern. Sollte es durch die Komplexität des Produkts notwendig sein eine längere Evaluation abzuhalten, so ist es sinnvoll diese in mehrere kleinere aufzuspalten, welche sich dann jeweils nur mit einem bestimmten Aspekt beschäftigen. <br /> <br /> Die Erfassung der Evaluationen kann auf verschiedene Weiser geschehen. Zum einen als geschriebener Bericht des Evaluatoren selbst, was den Aufwand für den Evaluator selbst erhöht da er sich nicht ausschließlich auf das Interface konzentrieren kann, dafür erhält man aber einen formalen Bericht.<br /> Zum anderen eine Erfassung durch einen Beobachter, dem der Evaluator während er das Interface begutachtet seine Ergebnisse sagt und dieser sie schriftlich festhält. Hierbei sollten die Evaluatoren dem Beobachter allerdings alle von ihnen gefundenen Verstöße gegen die Heuristiken einzeln mitteilen, was in der Praxis nicht immer so problemlos klappt, da sie mehr mit dem Finden von Fehlern als der Mitteilung dieser beschäftigt sind. Der Beobachter darf darüber hinaus die Ergebnisse und Kommentare nur erfassen, sie aber nicht selber bewerten wie beim zum User-Testing. <br /> Trotzdem bringt diese Form der Erfassung viele Vorteile mit sich. Sie reduziert zum einen die Arbeitslast für den Evaluator, zum anderen braucht der Beobachter nur ein Set von Notizen zu bearbeiten, das er dazu noch selbst geschrieben hat. Ein Ergebnis der gesamten Evaluation steht dadurch auch schneller zu Verfügung. <br /> <br /> Eine Evaluation mit Beobachter hat auch noch den Vorteil, dass der Beobachter Fragen während der Evaluation beantworten kann und auch soll, aber nur solche die das Anwendungsgebiet des Interfaces betreffen. Dies hat vor allem Vorteile für Evaluatoren die keine Experten auf diesem Gebiet sind. Zum anderen kann der Beobachter auch Hinweise zum Gebrauch des Interfaces geben, falls es zu Problemen bei der Nutzung kommt. Dadurch wird auch teure und kostbare Evaluationszeit gespart. Allerdings muss noch erwähnt werden, dass der Beobachter den Evaluatoren von sich selbst aus erst Hilfe geben darf, wenn sie in richtigen Schwierigkeiten sind und sie sich zu dem aufgetretenen Usability-Problem geäußert haben. Um dies alles zu Garantieren muss der für die Evaluation gewählte Beobachten eine Experte auf diesem Gebiet sein und sich natürlich auch mit dem Interface sehr gut auskennen.<br /> <br /> =Ergebnis=<br /> Das Ergebnis einer Heuristischen Evaluation ist eine Liste der gefundenen Usability-Probleme. Da diese Liste die einzelnen Meinungen der Evaluatoren wieder spiegelt, müssen diese, in Verbindung mit den Heuristiken oder anderen Usability-Ergebnissen, erklären warum sie etwas nicht mochten oder was ihnen nicht gefiel. Allerdings zeigt diese Methode keinen gezielten Ansatz zur Lösung der gefundenen Probleme auf <br /> <br /> =Erweiterung=<br /> Als Erweiterung der einfachen Liste von Usability-Problemen eines Interfaces, die man als Ergebnis aus der Heuristischen Evaluation erhält gibt es die Möglichkeit die schwere der einzelnen Probleme zu gewichten, das so genannte [http://glossar.fh-augsburg.de/Severity_Ranking Severity Ranking]. <br /> <br /> =Quellen=<br /> *[http://glossar.fh-augsburg.de/Nielsen%2C_Jakob_(1993):_Usability_Engineering Nielsen, Jakob (1993): Usability Engineering]<br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516<br /> <br /> =Links=<br /> *[http://www.useit.com/papers/heuristic/heuristic_evaluation.html Nielsen, J.: Heuristic Evaluation]<br /> *[http://www.useit.com/papers/heuristic/heuristic_list.html Heuristics for User Interface Design]<br /> *[http://www.fit-fuer-usability.de/1x1/messen/heuristik.html Über den Daumen: Heuristische Evaluation]<br /> <br /> [[Kategorie:HCI]]<br /> [[Kategorie:Content-Management-System]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Nielsen,_Jakob_(1993)&diff=11929 2008-07-05T08:55:01Z

<p>Borchert: hat Nielsen, Jakob (1993) nach Nielsen, Jakob (1993): Usability Engineering verschoben: Titel vergessen</p> <hr /> <div>#REDIRECT [[Nielsen, Jakob (1993): Usability Engineering]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Nielsen,_Jakob_(1993):_Usability_Engineering&diff=11928 2008-07-05T08:55:01Z

<p>Borchert: hat Nielsen, Jakob (1993) nach Nielsen, Jakob (1993): Usability Engineering verschoben: Titel vergessen</p> <hr /> <div>{{Quelle:Buch <br /> | key = Nielsen, Jakob (1993)<br /> | authors = Nielsen, Jakob<br /> | title = Usability Engineering<br /> | year = 1993<br /> | publisher = Academic Press Inc. <br /> | address = London<br /> | isbn = 0125184069<br /> | url = [http://www.useit.com Jakob Nielsen's Website]<br /> <br /> }}</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Nielsen,_Jakob_(1993):_Usability_Engineering&diff=11927 2008-07-05T08:53:32Z

<p>Borchert: </p> <hr /> <div>{{Quelle:Buch <br /> | key = Nielsen, Jakob (1993)<br /> | authors = Nielsen, Jakob<br /> | title = Usability Engineering<br /> | year = 1993<br /> | publisher = Academic Press Inc. <br /> | address = London<br /> | isbn = 0125184069<br /> | url = [http://www.useit.com Jakob Nielsen's Website]<br /> <br /> }}</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Heuristische_Evaluation&diff=11926 2008-07-05T08:47:34Z

<p>Borchert: </p> <hr /> <div>=Definition=<br /> Bei der '''heuristischen Evaluation''' handelt es sich um eine systematische Usability-Inspektionsmethode um Usability-Probleme in einem User-Interface Design zu finden. <br /> Zur heuristischen Evaluation gehört immer eine kleine Gruppe von (Usability-)Experten die die Gebrauchsfähigkeit bzw. Konformität des Interfaces begutachtet und anhand von allgemeinen und einfachen Kriterien - den Heuristiken - beurteilt.<br /> <br /> =Evaluatoren=<br /> Da ein Evaluator nur rund 35% der Usability-Probleme eine Interfaces findet ist es sinnvoll mit mehreren Evaluatoren zu arbeiten. Nielsen und Molich schlagen in ihren Arbeiten für eine Evaluation drei bis fünf Evaluatoren vor, da kaum noch zusätzliche Informationen durch eine größere Zahl von Evaluatoren gewonnen wird.<br /> Bei der Auswahl der Evaluatoren sollte berücksichtig werden, dass sich die Auswahl verschiedener Evaluatoren positiv auf das Finden von Problemen auswirkt,was auch Studienergebnisse von Nielsen und Molich belegen. So sollten unter den Evaluatoren zwar hauptsächlich Experten sein die sich mit Usability beschäftigen, aber wenn es möglich ist auch ein End-User bzw. ein Experte der sich mit dem Anwendungsgebiet für das das System gedacht ist auskennt um eventuelle, spezielle Usability-Probleme zu finden.<br /> <br /> Die exakte Zahl der Evaluatoren die tatsächlich für eine heuristische Evaluation herangezogen werden hängt allerdings auch sehr stark von der Kosten-Nutzen-Analyse ab, die für jedes System anderes ausfällt und somit neu berechnet wird. Sie errechnet sich aus Fixkosten und variablen Kosten. Die Fixkosten ergeben sich aus dem Preis der benötigten Materialien, der Planungszeit und dem Schreiben des Reportes. Sie betragen meist zwischen $3,700 und $4,800. Dazu kommen die variablen Kosten, wie der Lohn pro Evaluator, die Analyse der einzelnen Reporte, die Kosten der Hilfsmittel u.a. Diese Kosten bewegen sich zwischen $410 und $900 pro Evaluator<br /> <br /> =Heuristiken=<br /> Die Heuristiken dienen bzw. helfen den Evaluatoren bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist.Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden.<br /> <br /> Als Beispiel für allgemeine Heuristiken diente die folgende 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt , aber 1994 nochmals von Nielsen, nach mehreren Studien, verfeinert wurde. <br /> <br /> *''Sichtbarkeit des Systemstatus'' - Das System sollte dem User mit angebrachten Infos fortwährende mitteilen was geschieht <br /> <br /> *''Anpassung zwischen System und reeller Welt'' - Das System sollte in Wort und Phrase die Sprache der Anwender sprechen und nicht zu systemorientiert sein<br /> <br /> *''Benutzerkontrolle und –freiheit'' - Da User öfter mal Fehler machen sollte das System hierfür „Emergency Exits“ haben, sowie Undo- und Redo-Funktionen<br /> <br /> *''Konsistenz und Standards'' - Das System sollte Konsistent sein und bestimmten Standards folgen, damit sich der User immer zurechtfindet<br /> <br /> *''Fehler vermeiden'' - Besser als jede gute Fehlermeldung ist die Vermeidung von Fehlern<br /> <br /> *''Wiedererkennen statt sich erinnern'' - Die Bedienung sollte soweit es geht selbsterklärend sein ohne das sich der User groß erinnern muss. Auch sollte er sich nicht Informationen von einem Dialog für einen anderen merken müssen.<br /> <br /> *''Flexibilität und Effizienz'' - Für erfahrene User sollte es Abkürzungen geben die das Arbeiten mit dem System beschleunigen. Die „Shortcuts“ sollten allerdings Anfänger nicht verwirren. User sollten sich auch von ihnen häufig verwendete Funktionen speziell zurechtlegen können.<br /> <br /> *''Ästhetik und minimalistisches Design'' - Dialoge sollten notwendige Informationen enthalten. Jede zusätzliche Information lenkt nur von den Fakten ab und hält den Benutzer auf.<br /> <br /> *''Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern'' - Fehlermeldungen sollten in verständlicher Sprache sein, das Problem genau beschreiben und Lösung vorschlagen<br /> <br /> *''Hilfe und Dokumentation'' - Selbst wenn der User für die Nutzung des System keinerlei Unterstützung bedarf, sollte es doch, gerade bei komplexen Interfaces, gute Dokumentation geben die in die Struktur integriert sind. Eine Hilfe an entsprechender Stelle sollte sowohl kontextabhängig als auch verständlich verfasst sein und konstruktive Lösungsansätze bieten.<br /> <br /> =Durchführung=<br /> Bei der Evaluation selbst geht jeder Experte das Interface mehrmals durch und begutachtet die verschiedenen Dialogelemente und vergleicht diese dabei mit allgemeinen und/oder speziellen Heuristiken bzw. Usability-Prinzipien. Die Evaluatoren entscheiden selbst wie sie das Interface durchgehen, meistens zweimal. Beim ersten Durchlauf um ein Gefühl für das Interface und den allgemeinen Anwendungsbereich des Systems zu bekommen. Beim Zweiten achten sie dann auf spezielle Interface-Elemente und wie diese ins Gesamtbild passen.<br /> <br /> Erst nachdem alle Evaluationen abgeschlossen sind dürfen sich die Experten untereinander austauschen und ihre Ergebnisse zusammenführen. Dieses Verfahren ist Notwendig um sicherzustellen, dass die Evaluationen der einzelnen Personen unabhängig und vorurteilsfrei sind. Eine Evaluation eines Experten sollte durchschnittliche 1 bis 2 Stunden dauern. Sollte es durch die Komplexität des Produkts notwendig sein eine längere Evaluation abzuhalten, so ist es sinnvoll diese in mehrere kleinere aufzuspalten, welche sich dann jeweils nur mit einem bestimmten Aspekt beschäftigen. <br /> <br /> Die Erfassung der Evaluationen kann auf verschiedene Weiser geschehen. Zum einen als geschriebener Bericht des Evaluatoren selbst, was den Aufwand für den Evaluator selbst erhöht da er sich nicht ausschließlich auf das Interface konzentrieren kann, dafür erhält man aber einen formalen Bericht.<br /> Zum anderen eine Erfassung durch einen Beobachter, dem der Evaluator während er das Interface begutachtet seine Ergebnisse sagt und dieser sie schriftlich festhält. Hierbei sollten die Evaluatoren dem Beobachter allerdings alle von ihnen gefundenen Verstöße gegen die Heuristiken einzeln mitteilen, was in der Praxis nicht immer so problemlos klappt, da sie mehr mit dem Finden von Fehlern als der Mitteilung dieser beschäftigt sind. Der Beobachter darf darüber hinaus die Ergebnisse und Kommentare nur erfassen, sie aber nicht selber bewerten wie beim zum User-Testing. <br /> Trotzdem bringt diese Form der Erfassung viele Vorteile mit sich. Sie reduziert zum einen die Arbeitslast für den Evaluator, zum anderen braucht der Beobachter nur ein Set von Notizen zu bearbeiten, das er dazu noch selbst geschrieben hat. Ein Ergebnis der gesamten Evaluation steht dadurch auch schneller zu Verfügung. <br /> <br /> Eine Evaluation mit Beobachter hat auch noch den Vorteil, dass der Beobachter Fragen während der Evaluation beantworten kann und auch soll, aber nur solche die das Anwendungsgebiet des Interfaces betreffen. Dies hat vor allem Vorteile für Evaluatoren die keine Experten auf diesem Gebiet sind. Zum anderen kann der Beobachter auch Hinweise zum Gebrauch des Interfaces geben, falls es zu Problemen bei der Nutzung kommt. Dadurch wird auch teure und kostbare Evaluationszeit gespart. Allerdings muss noch erwähnt werden, dass der Beobachter den Evaluatoren von sich selbst aus erst Hilfe geben darf, wenn sie in richtigen Schwierigkeiten sind und sie sich zu dem aufgetretenen Usability-Problem geäußert haben. Um dies alles zu Garantieren muss der für die Evaluation gewählte Beobachten eine Experte auf diesem Gebiet sein und sich natürlich auch mit dem Interface sehr gut auskennen.<br /> <br /> =Ergebnis=<br /> Das Ergebnis einer Heuristischen Evaluation ist eine Liste der gefundenen Usability-Probleme. Da diese Liste die einzelnen Meinungen der Evaluatoren wieder spiegelt, müssen diese, in Verbindung mit den Heuristiken oder anderen Usability-Ergebnissen, erklären warum sie etwas nicht mochten oder was ihnen nicht gefiel. Allerdings zeigt diese Methode keinen gezielten Ansatz zur Lösung der gefundenen Probleme auf <br /> <br /> =Erweiterung=<br /> Als Erweiterung der einfachen Liste von Usability-Problemen eines Interfaces, die man als Ergebnis aus der Heuristischen Evaluation erhält gibt es die Möglichkeit die schwere der einzelnen Probleme zu gewichten, das so genannte [http://glossar.fh-augsburg.de/Severity_Ranking Severity Ranking]. <br /> <br /> =Quellen=<br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc. <br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516 <br /> <br /> =Links=<br /> *[http://www.useit.com/papers/heuristic/heuristic_evaluation.html Nielsen, J.: Heuristic Evaluation]<br /> *[http://www.useit.com/papers/heuristic/heuristic_list.html Heuristics for User Interface Design]<br /> *[http://www.fit-fuer-usability.de/1x1/messen/heuristik.html Über den Daumen: Heuristische Evaluation]<br /> <br /> [[Kategorie:HCI]]<br /> [[Kategorie:Content-Management-System]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Heuristische_Evaluation&diff=11925 2008-07-05T08:41:08Z

<p>Borchert: /* Heuristiken */</p> <hr /> <div>=Definition=<br /> Bei der '''heuristischen Evaluation''' handelt es sich um eine systematische Usability-Inspektionsmethode um Usability-Probleme in einem User-Interface Design zu finden. <br /> Zur heuristischen Evaluation gehört immer eine kleine Gruppe von (Usability-)Experten die die Gebrauchsfähigkeit bzw. Konformität des Interfaces begutachtet und anhand von allgemeinen und einfachen Kriterien - den Heuristiken - beurteilt.<br /> <br /> =Evaluatoren=<br /> Da ein Evaluator nur rund 35% der Usability-Probleme eine Interfaces findet ist es sinnvoll mit mehreren Evaluatoren zu arbeiten. Nielsen und Molich schlagen in ihren Arbeiten für eine Evaluation drei bis fünf Evaluatoren vor, da kaum noch zusätzliche Informationen durch eine größere Zahl von Evaluatoren gewonnen wird.<br /> Bei der Auswahl der Evaluatoren sollte berücksichtig werden, dass sich die Auswahl verschiedener Evaluatoren positiv auf das Finden von Problemen auswirkt,was auch Studienergebnisse von Nielsen und Molich belegen. So sollten unter den Evaluatoren zwar hauptsächlich Experten sein die sich mit Usability beschäftigen, aber wenn es möglich ist auch ein End-User bzw. ein Experte der sich mit dem Anwendungsgebiet für das das System gedacht ist auskennt um eventuelle, spezielle Usability-Probleme zu finden.<br /> <br /> Die exakte Zahl der Evaluatoren die tatsächlich für eine heuristische Evaluation herangezogen werden hängt allerdings auch sehr stark von der Kosten-Nutzen-Analyse ab, die für jedes System anderes ausfällt und somit neu berechnet wird. Sie errechnet sich aus Fixkosten und variablen Kosten. Die Fixkosten ergeben sich aus dem Preis der benötigten Materialien, der Planungszeit und dem Schreiben des Reportes. Sie betragen meist zwischen $3,700 und $4,800. Dazu kommen die variablen Kosten, wie der Lohn pro Evaluator, die Analyse der einzelnen Reporte, die Kosten der Hilfsmittel u.a. Diese Kosten bewegen sich zwischen $410 und $900 pro Evaluator<br /> <br /> =Heuristiken=<br /> Die Heuristiken dienen bzw. helfen den Evaluatoren bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist.Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden.<br /> <br /> Als Beispiel für allgemeine Heuristiken diente die folgende 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt , aber 1994 nochmals von Nielsen, nach mehreren Studien, verfeinert wurde. <br /> <br /> *''Sichtbarkeit des Systemstatus'' - Das System sollte dem User mit angebrachten Infos fortwährende mitteilen was geschieht <br /> <br /> *''Anpassung zwischen System und reeller Welt'' - Das System sollte in Wort und Phrase die Sprache der Anwender sprechen und nicht zu systemorientiert sein<br /> <br /> *''Benutzerkontrolle und –freiheit'' - Da User öfter mal Fehler machen sollte das System hierfür „Emergency Exits“ haben, sowie Undo- und Redo-Funktionen<br /> <br /> *''Konsistenz und Standards'' - Das System sollte Konsistent sein und bestimmten Standards folgen, damit sich der User immer zurechtfindet<br /> <br /> *''Fehler vermeiden'' - Besser als jede gute Fehlermeldung ist die Vermeidung von Fehlern<br /> <br /> *''Wiedererkennen statt sich erinnern'' - Die Bedienung sollte soweit es geht selbsterklärend sein ohne das sich der User groß erinnern muss. Auch sollte er sich nicht Informationen von einem Dialog für einen anderen merken müssen.<br /> <br /> *''Flexibilität und Effizienz'' - Für erfahrene User sollte es Abkürzungen geben die das Arbeiten mit dem System beschleunigen. Die „Shortcuts“ sollten allerdings Anfänger nicht verwirren. User sollten sich auch von ihnen häufig verwendete Funktionen speziell zurechtlegen können.<br /> <br /> *''Ästhetik und minimalistisches Design'' - Dialoge sollten notwendige Informationen enthalten. Jede zusätzliche Information lenkt nur von den Fakten ab und hält den Benutzer auf.<br /> <br /> *''Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern'' - Fehlermeldungen sollten in verständlicher Sprache sein, das Problem genau beschreiben und Lösung vorschlagen<br /> <br /> *''Hilfe und Dokumentation'' - Selbst wenn der User für die Nutzung des System keinerlei Unterstützung bedarf, sollte es doch, gerade bei komplexen Interfaces, gute Dokumentation geben die in die Struktur integriert sind. Eine Hilfe an entsprechender Stelle sollte sowohl kontextabhängig als auch verständlich verfasst sein und konstruktive Lösungsansätze bieten.<br /> <br /> =Durchführung=<br /> Bei der Evaluation selbst geht jeder Experte das Interface mehrmals durch und begutachtet die verschiedenen Dialogelemente und vergleicht diese dabei mit allgemeinen und/oder speziellen Heuristiken bzw. Usability-Prinzipien. Die Evaluatoren entscheiden selbst wie sie das Interface durchgehen, meistens zweimal. Beim ersten Durchlauf um ein Gefühl für das Interface und den allgemeinen Anwendungsbereich des Systems zu bekommen. Beim Zweiten achten sie dann auf spezielle Interface-Elemente und wie diese ins Gesamtbild passen.<br /> <br /> Erst nachdem alle Evaluationen abgeschlossen sind dürfen sich die Experten untereinander austauschen und ihre Ergebnisse zusammenführen. Dieses Verfahren ist Notwendig um sicherzustellen, dass die Evaluationen der einzelnen Personen unabhängig und vorurteilsfrei sind. Eine Evaluation eines Experten sollte durchschnittliche 1 bis 2 Stunden dauern. Sollte es durch die Komplexität des Produkts notwendig sein eine längere Evaluation abzuhalten, so ist es sinnvoll diese in mehrere kleinere aufzuspalten, welche sich dann jeweils nur mit einem bestimmten Aspekt beschäftigen. <br /> <br /> Die Erfassung der Evaluationen kann auf verschiedene Weiser geschehen. Zum einen als geschriebener Bericht des Evaluatoren selbst, was den Aufwand für den Evaluator selbst erhöht da er sich nicht ausschließlich auf das Interface konzentrieren kann, dafür erhält man aber einen formalen Bericht.<br /> Zum anderen eine Erfassung durch einen Beobachter, dem der Evaluator während er das Interface begutachtet seine Ergebnisse sagt und dieser sie schriftlich festhält. Hierbei sollten die Evaluatoren dem Beobachter allerdings alle von ihnen gefundenen Verstöße gegen die Heuristiken einzeln mitteilen, was in der Praxis nicht immer so problemlos klappt, da sie mehr mit dem Finden von Fehlern als der Mitteilung dieser beschäftigt sind. Der Beobachter darf darüber hinaus die Ergebnisse und Kommentare nur erfassen, sie aber nicht selber bewerten wie beim zum User-Testing. <br /> Trotzdem bringt diese Form der Erfassung viele Vorteile mit sich. Sie reduziert zum einen die Arbeitslast für den Evaluator, zum anderen braucht der Beobachter nur ein Set von Notizen zu bearbeiten, das er dazu noch selbst geschrieben hat. Ein Ergebnis der gesamten Evaluation steht dadurch auch schneller zu Verfügung. <br /> <br /> Eine Evaluation mit Beobachter hat auch noch den Vorteil, dass der Beobachter Fragen während der Evaluation beantworten kann und auch soll, aber nur solche die das Anwendungsgebiet des Interfaces betreffen. Dies hat vor allem Vorteile für Evaluatoren die keine Experten auf diesem Gebiet sind. Zum anderen kann der Beobachter auch Hinweise zum Gebrauch des Interfaces geben, falls es zu Problemen bei der Nutzung kommt. Dadurch wird auch teure und kostbare Evaluationszeit gespart. Allerdings muss noch erwähnt werden, dass der Beobachter den Evaluatoren von sich selbst aus erst Hilfe geben darf, wenn sie in richtigen Schwierigkeiten sind und sie sich zu dem aufgetretenen Usability-Problem geäußert haben. Um dies alles zu Garantieren muss der für die Evaluation gewählte Beobachten eine Experte auf diesem Gebiet sein und sich natürlich auch mit dem Interface sehr gut auskennen.<br /> <br /> =Ergebnis=<br /> Das Ergebnis einer Heuristischen Evaluation ist eine Liste der gefundenen Usability-Probleme. Da diese Liste die einzelnen Meinungen der Evaluatoren wieder spiegelt, müssen diese, in Verbindung mit den Heuristiken oder anderen Usability-Ergebnissen, erklären warum sie etwas nicht mochten oder was ihnen nicht gefiel. Allerdings zeigt diese Methode keinen gezielten Ansatz zur Lösung der gefundenen Probleme auf <br /> <br /> =Erweiterung=<br /> Als Erweiterung der einfachen Liste von Usability-Problemen eines Interfaces, die man als Ergebnis aus der Heuristischen Evaluation erhält gibt es die Möglichkeit die schwere der einzelnen Probleme zu gewichten, das so genannte [http://glossar.fh-augsburg.de/Severity_Ranking Severity Ranking]. <br /> <br /> =Quellen=<br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc. <br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516 <br /> <br /> =Links=<br /> *[http://www.useit.com/papers/heuristic/heuristic_evaluation.html Nielsen, J.: Heuristic Evaluation]<br /> *[http://www.fit-fuer-usability.de/1x1/messen/heuristik.html Über den Daumen: Heuristische Evaluation]<br /> <br /> [[Kategorie:HCI]]<br /> [[Kategorie:Content-Management-System]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Heuristische_evaluation&diff=11921 2008-07-04T16:13:02Z

<p>Borchert: hat Heuristische evaluation nach Heuristische Evaluation verschoben: Falsch geschrieben</p> <hr /> <div>#REDIRECT [[Heuristische Evaluation]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Heuristische_Evaluation&diff=11920 2008-07-04T16:13:02Z

<p>Borchert: hat Heuristische evaluation nach Heuristische Evaluation verschoben: Falsch geschrieben</p> <hr /> <div>=Definition=<br /> Bei der '''heuristischen Evaluation''' handelt es sich um eine systematische Usability-Inspektionsmethode um Usability-Probleme in einem User-Interface Design zu finden. <br /> Zur heuristischen Evaluation gehört immer eine kleine Gruppe von (Usability-)Experten die die Gebrauchsfähigkeit bzw. Konformität des Interfaces begutachtet und anhand von allgemeinen und einfachen Kriterien - den Heuristiken - beurteilt.<br /> <br /> =Evaluatoren=<br /> Da ein Evaluator nur rund 35% der Usability-Probleme eine Interfaces findet ist es sinnvoll mit mehreren Evaluatoren zu arbeiten. Nielsen und Molich schlagen in ihren Arbeiten für eine Evaluation drei bis fünf Evaluatoren vor, da kaum noch zusätzliche Informationen durch eine größere Zahl von Evaluatoren gewonnen wird.<br /> Bei der Auswahl der Evaluatoren sollte berücksichtig werden, dass sich die Auswahl verschiedener Evaluatoren positiv auf das Finden von Problemen auswirkt,was auch Studienergebnisse von Nielsen und Molich belegen. So sollten unter den Evaluatoren zwar hauptsächlich Experten sein die sich mit Usability beschäftigen, aber wenn es möglich ist auch ein End-User bzw. ein Experte der sich mit dem Anwendungsgebiet für das das System gedacht ist auskennt um eventuelle, spezielle Usability-Probleme zu finden.<br /> <br /> Die exakte Zahl der Evaluatoren die tatsächlich für eine heuristische Evaluation herangezogen werden hängt allerdings auch sehr stark von der Kosten-Nutzen-Analyse ab, die für jedes System anderes ausfällt und somit neu berechnet wird. Sie errechnet sich aus Fixkosten und variablen Kosten. Die Fixkosten ergeben sich aus dem Preis der benötigten Materialien, der Planungszeit und dem Schreiben des Reportes. Sie betragen meist zwischen $3,700 und $4,800. Dazu kommen die variablen Kosten, wie der Lohn pro Evaluator, die Analyse der einzelnen Reporte, die Kosten der Hilfsmittel u.a. Diese Kosten bewegen sich zwischen $410 und $900 pro Evaluator<br /> <br /> =Heuristiken=<br /> Die Heuristiken dienen bzw. helfen den Evaluatoren bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist.Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden.<br /> <br /> Als Beispiel für allgemeine Heuristiken diente die folgende 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt , aber 1994 nochmals von Nielsen, nach mehreren Studien, verfeinert wurde. <br /> <br /> Die Heuristiken oder Leitfäden dienen bzw. helfen den Evaluatoren, wie in der Einleitung erwähnt, bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist. Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden [1].<br /> Als Beispiel für allgemeine Heuristiken eine 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt, aber 1994 nochmals von Nielsen nach mehreren Studien verfeinert wurde.<br /> <br /> *''Sichtbarkeit des Systemstatus'' - Das System sollte dem User mit angebrachten Infos fortwährende mitteilen was geschieht <br /> <br /> *''Anpassung zwischen System und reeller Welt'' - Das System sollte in Wort und Phrase die Sprache der Anwender sprechen und nicht zu systemorientiert sein<br /> <br /> *''Benutzerkontrolle und –freiheit'' - Da User öfter mal Fehler machen sollte das System hierfür „Emergency Exits“ haben, sowie Undo- und Redo-Funktionen<br /> <br /> *''Konsistenz und Standards'' - Das System sollte Konsistent sein und bestimmten Standards folgen, damit sich der User immer zurechtfindet<br /> <br /> *''Fehler vermeiden'' - Besser als jede gute Fehlermeldung ist die Vermeidung von Fehlern<br /> <br /> *''Wiedererkennen statt sich erinnern'' - Die Bedienung sollte soweit es geht selbsterklärend sein ohne das sich der User groß erinnern muss. Auch sollte er sich nicht Informationen von einem Dialog für einen anderen merken müssen.<br /> <br /> *''Flexibilität und Effizienz'' - Für erfahrene User sollte es Abkürzungen geben die das Arbeiten mit dem System beschleunigen. Die „Shortcuts“ sollten allerdings Anfänger nicht verwirren. User sollten sich auch von ihnen häufig verwendete Funktionen speziell zurechtlegen können.<br /> <br /> *''Ästhetik und minimalistisches Design'' - Dialoge sollten notwendige Informationen enthalten. Jede zusätzliche Information lenkt nur von den Fakten ab und hält den Benutzer auf.<br /> <br /> *''Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern'' - Fehlermeldungen sollten in verständlicher Sprache sein, das Problem genau beschreiben und Lösung vorschlagen<br /> <br /> *''Hilfe und Dokumentation'' - Selbst wenn der User für die Nutzung des System keinerlei Unterstützung bedarf, sollte es doch, gerade bei komplexen Interfaces, gute Dokumentation geben die in die Struktur integriert sind. Eine Hilfe an entsprechender Stelle sollte sowohl kontextabhängig als auch verständlich verfasst sein und konstruktive Lösungsansätze bieten.<br /> <br /> =Durchführung=<br /> Bei der Evaluation selbst geht jeder Experte das Interface mehrmals durch und begutachtet die verschiedenen Dialogelemente und vergleicht diese dabei mit allgemeinen und/oder speziellen Heuristiken bzw. Usability-Prinzipien. Die Evaluatoren entscheiden selbst wie sie das Interface durchgehen, meistens zweimal. Beim ersten Durchlauf um ein Gefühl für das Interface und den allgemeinen Anwendungsbereich des Systems zu bekommen. Beim Zweiten achten sie dann auf spezielle Interface-Elemente und wie diese ins Gesamtbild passen.<br /> <br /> Erst nachdem alle Evaluationen abgeschlossen sind dürfen sich die Experten untereinander austauschen und ihre Ergebnisse zusammenführen. Dieses Verfahren ist Notwendig um sicherzustellen, dass die Evaluationen der einzelnen Personen unabhängig und vorurteilsfrei sind. Eine Evaluation eines Experten sollte durchschnittliche 1 bis 2 Stunden dauern. Sollte es durch die Komplexität des Produkts notwendig sein eine längere Evaluation abzuhalten, so ist es sinnvoll diese in mehrere kleinere aufzuspalten, welche sich dann jeweils nur mit einem bestimmten Aspekt beschäftigen. <br /> <br /> Die Erfassung der Evaluationen kann auf verschiedene Weiser geschehen. Zum einen als geschriebener Bericht des Evaluatoren selbst, was den Aufwand für den Evaluator selbst erhöht da er sich nicht ausschließlich auf das Interface konzentrieren kann, dafür erhält man aber einen formalen Bericht.<br /> Zum anderen eine Erfassung durch einen Beobachter, dem der Evaluator während er das Interface begutachtet seine Ergebnisse sagt und dieser sie schriftlich festhält. Hierbei sollten die Evaluatoren dem Beobachter allerdings alle von ihnen gefundenen Verstöße gegen die Heuristiken einzeln mitteilen, was in der Praxis nicht immer so problemlos klappt, da sie mehr mit dem Finden von Fehlern als der Mitteilung dieser beschäftigt sind. Der Beobachter darf darüber hinaus die Ergebnisse und Kommentare nur erfassen, sie aber nicht selber bewerten wie beim zum User-Testing. <br /> Trotzdem bringt diese Form der Erfassung viele Vorteile mit sich. Sie reduziert zum einen die Arbeitslast für den Evaluator, zum anderen braucht der Beobachter nur ein Set von Notizen zu bearbeiten, das er dazu noch selbst geschrieben hat. Ein Ergebnis der gesamten Evaluation steht dadurch auch schneller zu Verfügung. <br /> <br /> Eine Evaluation mit Beobachter hat auch noch den Vorteil, dass der Beobachter Fragen während der Evaluation beantworten kann und auch soll, aber nur solche die das Anwendungsgebiet des Interfaces betreffen. Dies hat vor allem Vorteile für Evaluatoren die keine Experten auf diesem Gebiet sind. Zum anderen kann der Beobachter auch Hinweise zum Gebrauch des Interfaces geben, falls es zu Problemen bei der Nutzung kommt. Dadurch wird auch teure und kostbare Evaluationszeit gespart. Allerdings muss noch erwähnt werden, dass der Beobachter den Evaluatoren von sich selbst aus erst Hilfe geben darf, wenn sie in richtigen Schwierigkeiten sind und sie sich zu dem aufgetretenen Usability-Problem geäußert haben. Um dies alles zu Garantieren muss der für die Evaluation gewählte Beobachten eine Experte auf diesem Gebiet sein und sich natürlich auch mit dem Interface sehr gut auskennen.<br /> <br /> =Ergebnis=<br /> Das Ergebnis einer Heuristischen Evaluation ist eine Liste der gefundenen Usability-Probleme. Da diese Liste die einzelnen Meinungen der Evaluatoren wieder spiegelt, müssen diese, in Verbindung mit den Heuristiken oder anderen Usability-Ergebnissen, erklären warum sie etwas nicht mochten oder was ihnen nicht gefiel. Allerdings zeigt diese Methode keinen gezielten Ansatz zur Lösung der gefundenen Probleme auf <br /> <br /> =Erweiterung=<br /> Als Erweiterung der einfachen Liste von Usability-Problemen eines Interfaces, die man als Ergebnis aus der Heuristischen Evaluation erhält gibt es die Möglichkeit die schwere der einzelnen Probleme zu gewichten, das so genannte [http://glossar.fh-augsburg.de/Severity_Ranking Severity Ranking]. <br /> <br /> =Quellen=<br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc. <br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516 <br /> <br /> =Links=<br /> *[http://www.useit.com/papers/heuristic/heuristic_evaluation.html Nielsen, J.: Heuristic Evaluation]<br /> *[http://www.fit-fuer-usability.de/1x1/messen/heuristik.html Über den Daumen: Heuristische Evaluation]<br /> <br /> [[Kategorie:HCI]]<br /> [[Kategorie:Content-Management-System]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Think-Aloud-Protokoll&diff=11919 2008-07-04T14:38:56Z

<p>Borchert: /* Durchführung */</p> <hr /> <div>=Definition=<br /> Das '''Think-Aloud-Protokoll''' (dt. Methode des lauten Denkens) gehört zu den am meisten angewendeten Usability-Testmethoden. Bei dieser beobachtet ein Usability-Experte die Benutzer, wie diese mit dem zu untersuchenden System arbeiten. Ziel ist es dadurch mögliche Usability-Probleme zu erkennen.<br /> Die Methode des &quot;lauten Denkens&quot; kommt aus der empirischen Sozialwissenschaft und liefert qualitativ hochwertige Daten. <br /> <br /> =Beschreibung=<br /> Ein Benutzertest mit den eigentlichen Benutzern gehört zu den elementarsten Usability-Methoden und ist in gewisser Weise unersetzbar. Er liefert unmittelbar Informationen darüber, wie Personen Computer benutzen und was deren genaue Probleme mit dem getesteten Programm sind. Darüber hinaus ist er mit einem geringen personellen Aufwand machbar, denn in der Regel werden für einen Test nur ein Experte sowie mindestens vier Testnutzer benötigt. Allerdings gibt es etliche methodologische Fallen und wie bei allen Arten von Tests muss man besonders auf die Aspekte Beständigkeit und Gültigkeit acht geben. <br /> *Mit ''Beständigkeit'' ist gemeint, ob man die-selben Ergebnisse erhalten würde, falls der Test wiederholt würde. <br /> *Mit ''Gültigkeit'' ist wiederum gemeint, ob die Ergebnisse tatsächlich die Belange widerspiegeln die getestet werden sollten .<br /> <br /> <br /> Ein späterer Endnutzer denkt „laut“, während er mit dem Programm arbeitet. Er sollte alle seine Gedanken, Gefühle, Meinungen und Erwartungen die sich aus der Nutzung des Programms ergeben laut äußern. Ein Fachmann zeichnet alle Anmerkungen auf, um später daraus Schlüsse zu ziehen. Meistens wird der Nutzer zusätzlich, für die spätere Auswertung, auch per Video und Ton aufgezeichnet sowie ein ScreenCapture seiner Arbeit am Computer.<br /> <br /> Durch die Art und Weise dieser Methode erhält man Information darüber, wie das System gesehen wird und was evtl. nicht so verstanden wird, wie es ursprünglich gedacht war. Sie ist ebenfalls sehr gut dazu geeignet, subjektive Einschätzungen über den Benutzer und dessen Vorgehen zu erhalten und man bekommt eine direkte Rückkopplung, wie einzelne Dinge verstanden werden. Darüber hinaus erhält man durch die Nutzer sehr gute qualitative Aussagen aber kaum Aufschlüsse bezüglich quantitativer Maße. Die Äußerungen der Nutzer können aber verfälscht werden, wenn diese im Vorfeld nicht darüber aufgeklärt wurden, dass sie keine bestimmte Erwartung zu erfüllen haben. Durch die Think-Aloud-Methode kann man die Effektivität und Zufriedenstellung der Benutzer messen, nicht aber die Effizienz.<br /> <br /> =Durchführung=<br /> Für die Abhaltung dieses User-Tests ist es Notwendig im Vorfeld ein Testszenario zu erstellen, dass dann die Nutzer beim eigentlichen Test soweit wie möglich erledigen sollen. Das Szenario sollte dabei möglichst reale Aufgaben und Ziele enthalten. <br /> Vor Beginn eines Tests wird der jeweilige Testnutzer noch (kurz) in das System sowie in die Aufgaben eingewiesen. <br /> <br /> Während des Tests sollte der Fachmann so wenig wie möglich Einfluß auf den Test-User nehmen. Er kann aber durchaus Hilfestellungen geben, wenn dies erforderlich ist, diese sollte aber nur zur Testprozedur selbst sein und nicht zum Inhalt. Wenn der Tester Einfluß nimmt, dann sollte dies immer in Form von offenen Fragen geschehen, um den User zum Weitersprechen zu animieren. Der Experte sollte nie versuchen, Lösungen zu präsentieren.<br /> <br /> Im Anschluss an den Test wird der Nutzer noch zu seinen Erfahrungen und zu seinen Eindrücken befragt. Dies liefert erneut wichtige Erkenntnisse, aus denen konkrete Optimierungspotentiale abgeleitet werden können.<br /> <br /> =Ergebnis=<br /> Im Anschluss an die Tests wird das aufgezeichnete Video- und Tonmaterial ausgewertet. Die Ergebnisse werden mit den Eindrücken, Kommentaren der Probanden und den Befragungen verglichen, anschließend diskutiert und dann zu einm Gesamtbild zusammengefasst.<br /> <br /> =Quellen=<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516 <br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc.<br /> *[http://www.fit-fuer-usability.de/1x1/messen/thinking.html Bitte laut denken: &quot;Thinking Aloud&quot;]<br /> <br /> =Links=<br /> *[http://www.usabilityhome.com/ThinkAlo.htm Thinking-aloud Protocol]<br /> *[http://www.usability.gov/refine/learnusa.html Learn about Usability Testing]<br /> <br /> [[Kategorie:HCI]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Severity_Ranking&diff=11918 2008-07-04T14:35:32Z

<p>Borchert: /* Klassifikation der Probleme */</p> <hr /> <div>=Definition=<br /> Das '''Severity Ranking''' ist eine Zusatzmethode zum Bewerten der Ergebnisse der [http://glossar.fh-augsburg.de/Heuristische_evaluation heuristischen Evaluation].<br /> <br /> =Beschreibung=<br /> Die [http://glossar.fh-augsburg.de/Heuristische_evaluation heuristische Evaluation] liefert als Ergebnis nur eine einfache Liste aller gefundenen Usability-Probleme. Das Severity Ranikng (dt. etwa Ernsthaftigkeits-Rangliste) bietet die Möglichkeit die Schwere der einzelnen Probleme zu gewichten, <br /> <br /> Da es schwer bzw. so gut wie unmöglich ist dies direkt während der Evaluation zu tun, geschieht dies mit Hilfe eines Fragebogens, der für die Evaluatoren nach dem Test erstellt wird. Er stellt die Probleme aller Tester kurz dar. Es kann dadurch festgestellt werden, ob ein Problem nur von kosmetischer Natur ist oder eine wahre Usability-Katastrophe. Für die Bestimmung der Schwere eines Usability-Problems gibt es folgende drei Faktoren:<br /> <br /> *Die ''Häufigkeit'' des Problems<br /> *Die ''Härte'' des Problems<br /> *Die ''Beständigkeit'' des Problems – Ist es ein einmaliges Problem, das der User bewältigen kann nachdem er einmal davon weiß oder wird es ihn permanent stören? <br /> <br /> Neben den drei genannten Faktoren sollte auch abgeschätzen werden, welche (Markt-)Auswirkungen ein Problem hat. Bestimmte Usability-Probleme können einen verheerenden Effekt auf die Popularität eines Produkts haben, selbst wenn der Fehler einfach zu beheben ist.<br /> <br /> Der Fragebogen sollte von mindestens drei der Evaluatoren, die die heuristische Evaluation durchgführt haben, beantwortet werden. <br /> <br /> =Klassifikation der Probleme=<br /> Die gefundenen Probleme werden im Fragebogen meistens anhand der folgender 5-Punkte Skala eingeordnet:<br /> <br /> {| class=&quot;prettytable&quot;<br /> |- class=&quot;hintergrundfarbe5&quot;<br /> |0 || Ich stimme nicht zu, dass das überhaupt ein Usability-Problem ist<br /> |-<br /> |1 || Kosmetisches Problem – Braucht nicht gemacht zu werden außer es ist Zeit dafür vorhanden<br /> |-<br /> |2 || Kleines Usability-Problem – Niedrige Priorität bei Bearbeitung<br /> |-<br /> |3 || Großes Usabilty-Problem – Hohe Priorität, wichtig bei Bearbeitung<br /> |-<br /> |4 || Usability-Katastrophe – Muss zwingend gemacht werden <br /> |}<br /> <br /> Als Abschluß werden die Ergebnisse der Evaluatoren zu einer Gesamtbewertung zusammengefasst, die die Probleme der Gesamtgewichtung nach deutlich aufzeigt.<br /> <br /> =Quellen=<br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc. <br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.<br /> <br /> [[Kategorie:HCI]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Think-Aloud-Protokoll&diff=11917 2008-07-04T11:49:02Z

<p>Borchert: </p> <hr /> <div>=Definition=<br /> Das '''Think-Aloud-Protokoll''' (dt. Methode des lauten Denkens) gehört zu den am meisten angewendeten Usability-Testmethoden. Bei dieser beobachtet ein Usability-Experte die Benutzer, wie diese mit dem zu untersuchenden System arbeiten. Ziel ist es dadurch mögliche Usability-Probleme zu erkennen.<br /> Die Methode des &quot;lauten Denkens&quot; kommt aus der empirischen Sozialwissenschaft und liefert qualitativ hochwertige Daten. <br /> <br /> =Beschreibung=<br /> Ein Benutzertest mit den eigentlichen Benutzern gehört zu den elementarsten Usability-Methoden und ist in gewisser Weise unersetzbar. Er liefert unmittelbar Informationen darüber, wie Personen Computer benutzen und was deren genaue Probleme mit dem getesteten Programm sind. Darüber hinaus ist er mit einem geringen personellen Aufwand machbar, denn in der Regel werden für einen Test nur ein Experte sowie mindestens vier Testnutzer benötigt. Allerdings gibt es etliche methodologische Fallen und wie bei allen Arten von Tests muss man besonders auf die Aspekte Beständigkeit und Gültigkeit acht geben. <br /> *Mit ''Beständigkeit'' ist gemeint, ob man die-selben Ergebnisse erhalten würde, falls der Test wiederholt würde. <br /> *Mit ''Gültigkeit'' ist wiederum gemeint, ob die Ergebnisse tatsächlich die Belange widerspiegeln die getestet werden sollten .<br /> <br /> <br /> Ein späterer Endnutzer denkt „laut“, während er mit dem Programm arbeitet. Er sollte alle seine Gedanken, Gefühle, Meinungen und Erwartungen die sich aus der Nutzung des Programms ergeben laut äußern. Ein Fachmann zeichnet alle Anmerkungen auf, um später daraus Schlüsse zu ziehen. Meistens wird der Nutzer zusätzlich, für die spätere Auswertung, auch per Video und Ton aufgezeichnet sowie ein ScreenCapture seiner Arbeit am Computer.<br /> <br /> Durch die Art und Weise dieser Methode erhält man Information darüber, wie das System gesehen wird und was evtl. nicht so verstanden wird, wie es ursprünglich gedacht war. Sie ist ebenfalls sehr gut dazu geeignet, subjektive Einschätzungen über den Benutzer und dessen Vorgehen zu erhalten und man bekommt eine direkte Rückkopplung, wie einzelne Dinge verstanden werden. Darüber hinaus erhält man durch die Nutzer sehr gute qualitative Aussagen aber kaum Aufschlüsse bezüglich quantitativer Maße. Die Äußerungen der Nutzer können aber verfälscht werden, wenn diese im Vorfeld nicht darüber aufgeklärt wurden, dass sie keine bestimmte Erwartung zu erfüllen haben. Durch die Think-Aloud-Methode kann man die Effektivität und Zufriedenstellung der Benutzer messen, nicht aber die Effizienz.<br /> <br /> =Durchführung=<br /> Für die Abhaltung dieses User-Tests ist es Notwendig im Vorfeld ein Testszenario zu erstellen, dass dann die Nutzer beim eigentlichen Test soweit wie möglich erledigen sollen. Das Szenario sollte dabei möglichst reale Aufgaben und Ziele enthalten. <br /> Vor Beginn eines Tests wird der jeweilige Testnutzer noch (kurz) in das System sowie in die Aufgaben eingewiesen. <br /> <br /> Während des Tests sollte der Fachmann so wenig wie möglich Einfluß auf den Test-User nehmen. Er kann aber durchaus Hilfestellungen geben, wenn dies erforderlich ist, diese sollte aber nur zur Testprozedur selbst sein und nicht zum Inhalt. Wenn der Tester Einfluß nimmt, dann sollte dies immer in Form von offenen Fragen geschehen, um den User zum Weitersprechen zu animieren. Der Experte sollte nie versuchen, Lösungen zu präsentieren.<br /> Im Anschluss an den Test wird der Nutzer noch zu seinen Erfahrungen und zu seinen Eindrücken befragt. Dies liefert erneut wichtige Erkenntnisse, aus denen konkrete Optimierungspotentiale abgeleitet werden können. <br /> <br /> =Ergebnis=<br /> Im Anschluss an die Tests wird das aufgezeichnete Video- und Tonmaterial ausgewertet. Die Ergebnisse werden mit den Eindrücken, Kommentaren der Probanden und den Befragungen verglichen, anschließend diskutiert und dann zu einm Gesamtbild zusammengefasst.<br /> <br /> =Quellen=<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516 <br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc.<br /> *[http://www.fit-fuer-usability.de/1x1/messen/thinking.html Bitte laut denken: &quot;Thinking Aloud&quot;]<br /> <br /> =Links=<br /> *[http://www.usabilityhome.com/ThinkAlo.htm Thinking-aloud Protocol]<br /> *[http://www.usability.gov/refine/learnusa.html Learn about Usability Testing]<br /> <br /> [[Kategorie:HCI]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Think-Aloud-Protokoll&diff=11916 2008-07-04T11:48:15Z

<p>Borchert: </p> <hr /> <div>=Definition=<br /> Das '''Think-Aloud-Protokoll''' (dt. Methode des lauten Denkens) gehört zu den am meisten angewendeten Usability-Testmethoden. Bei dieser beobachtet ein Usability-Experte die Benutzer, wie diese mit dem zu untersuchenden System arbeiten. Ziel ist es dadurch mögliche Usability-Probleme zu erkennen.<br /> Die Methode des &quot;lauten Denkens&quot; kommt aus der empirischen Sozialwissenschaft und liefert qualitativ hochwertige Daten. <br /> <br /> =Beschreibung=<br /> Ein Benutzertest mit den eigentlichen Benutzern gehört zu den elementarsten Usability-Methoden und ist in gewisser Weise unersetzbar. Er liefert unmittelbar Informationen darüber, wie Personen Computer benutzen und was deren genaue Probleme mit dem getesteten Programm sind. Darüber hinaus ist er mit einem geringen personellen Aufwand machbar, denn in der Regel werden für einen Test nur ein Experte sowie mindestens vier Testnutzer benötigt. Allerdings gibt es etliche methodologische Fallen und wie bei allen Arten von Tests muss man besonders auf die Aspekte Beständigkeit und Gültigkeit acht geben. <br /> *Mit ''Beständigkeit'' ist gemeint, ob man die-selben Ergebnisse erhalten würde, falls der Test wiederholt würde. <br /> *Mit ''Gültigkeit'' ist wiederum gemeint, ob die Ergebnisse tatsächlich die Belange widerspiegeln die getestet werden sollten .<br /> <br /> <br /> Ein späterer Endnutzer denkt „laut“, während er mit dem Programm arbeitet. Er sollte alle seine Gedanken, Gefühle, Meinungen und Erwartungen die sich aus der Nutzung des Programms ergeben laut äußern. Ein Fachmann zeichnet alle Anmerkungen auf, um später daraus Schlüsse zu ziehen. Meistens wird der Nutzer zusätzlich, für die spätere Auswertung, auch per Video und Ton aufgezeichnet sowie ein ScreenCapture seiner Arbeit am Computer.<br /> <br /> Durch die Art und Weise dieser Methode erhält man Information darüber, wie das System gesehen wird und was evtl. nicht so verstanden wird, wie es ursprünglich gedacht war. Sie ist ebenfalls sehr gut dazu geeignet, subjektive Einschätzungen über den Benutzer und dessen Vorgehen zu erhalten und man bekommt eine direkte Rückkopplung, wie einzelne Dinge verstanden werden. Darüber hinaus erhält man durch die Nutzer sehr gute qualitative Aussagen aber kaum Aufschlüsse bezüglich quantitativer Maße. Die Äußerungen der Nutzer können aber verfälscht werden, wenn diese im Vorfeld nicht darüber aufgeklärt wurden, dass sie keine bestimmte Erwartung zu erfüllen haben. Durch die Think-Aloud-Methode kann man die Effektivität und Zufriedenstellung der Benutzer messen, nicht aber die Effizienz.<br /> <br /> =Durchführung=<br /> Für die Abhaltung dieses User-Tests ist es Notwendig im Vorfeld ein Testszenario zu erstellen, dass dann die Nutzer beim eigentlichen Test soweit wie möglich erledigen sollen. Das Szenario sollte dabei möglichst reale Aufgaben und Ziele enthalten. <br /> Vor Beginn eines Tests wird der jeweilige Testnutzer noch (kurz) in das System sowie in die Aufgaben eingewiesen. <br /> <br /> Während des Tests sollte der Fachmann so wenig wie möglich Einfluß auf den Test-User nehmen. Er kann aber durchaus Hilfestellungen geben, wenn dies erforderlich ist, diese sollte aber nur zur Testprozedur selbst sein und nicht zum Inhalt. Wenn der Tester Einfluß nimmt, dann sollte dies immer in Form von offenen Fragen geschehen, um den User zum Weitersprechen zu animieren. Der Experte sollte nie versuchen, Lösungen zu präsentieren.<br /> Im Anschluss an den Test wird der Nutzer noch zu seinen Erfahrungen und zu seinen Eindrücken befragt. Dies liefert erneut wichtige Erkenntnisse, aus denen konkrete Optimierungspotentiale abgeleitet werden können. <br /> <br /> =Ergebnis=<br /> Im Anschluss an die Tests wird das aufgezeichnete Video- und Tonmaterial ausgewertet. Die Ergebnisse werden mit den Eindrücken, Kommentaren der Probanden und den Befragungen verglichen, anschließend diskutiert und dann zu einm Gesamtbild zusammengefasst.<br /> <br /> =Quellen=<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516 <br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc.<br /> *[http://www.fit-fuer-usability.de/1x1/messen/thinking.html Bitte laut denken: &quot;Thinking Aloud&quot;]<br /> <br /> =Links=<br /> *[http://www.usabilityhome.com/ThinkAlo.htm Think Aloud Protocol]<br /> *[http://www.usability.gov/refine/learnusa.html Learn about Usability Testing]<br /> <br /> [[Kategorie:HCI]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Think-Aloud-Protokoll&diff=11915 2008-07-04T11:43:39Z

<p>Borchert: </p> <hr /> <div>=Definition=<br /> Das '''Think-Aloud-Protokoll''' (dt. Methode des lauten Denkens) gehört zu den am meisten angewendeten Usability-Testmethoden. Bei dieser beobachtet ein Usability-Experte die Benutzer, wie diese mit dem zu untersuchenden System arbeiten. Ziel ist es dadurch mögliche Usability-Probleme zu erkennen.<br /> Die Methode des &quot;lauten Denkens&quot; kommt aus der empirischen Sozialwissenschaft und liefert qualitativ hochwertige Daten. <br /> <br /> =Beschreibung=<br /> Ein Benutzertest mit den eigentlichen Benutzern gehört zu den elementarsten Usability-Methoden und ist in gewisser Weise unersetzbar. Er liefert unmittelbar Informationen darüber, wie Personen Computer benutzen und was deren genaue Probleme mit dem getesteten Programm sind. Darüber hinaus ist er mit einem geringen personellen Aufwand machbar, denn in der Regel werden für einen Test nur ein Experte sowie mindestens vier Testnutzer benötigt. Allerdings gibt es etliche methodologische Fallen und wie bei allen Arten von Tests muss man besonders auf die Aspekte Beständigkeit und Gültigkeit acht geben. <br /> *Mit ''Beständigkeit'' ist gemeint, ob man die-selben Ergebnisse erhalten würde, falls der Test wiederholt würde. <br /> *Mit ''Gültigkeit'' ist wiederum gemeint, ob die Ergebnisse tatsächlich die Belange widerspiegeln die getestet werden sollten .<br /> <br /> <br /> Ein späterer Endnutzer denkt „laut“, während er mit dem Programm arbeitet. Er sollte alle seine Gedanken, Gefühle, Meinungen und Erwartungen die sich aus der Nutzung des Programms ergeben laut äußern. Ein Fachmann zeichnet alle Anmerkungen auf, um später daraus Schlüsse zu ziehen. Meistens wird der Nutzer zusätzlich, für die spätere Auswertung, auch per Video und Ton aufgezeichnet sowie ein ScreenCapture seiner Arbeit am Computer.<br /> <br /> Durch die Art und Weise dieser Methode erhält man Information darüber, wie das System gesehen wird und was evtl. nicht so verstanden wird, wie es ursprünglich gedacht war. Sie ist ebenfalls sehr gut dazu geeignet, subjektive Einschätzungen über den Benutzer und dessen Vorgehen zu erhalten und man bekommt eine direkte Rückkopplung, wie einzelne Dinge verstanden werden. Darüber hinaus erhält man durch die Nutzer sehr gute qualitative Aussagen aber kaum Aufschlüsse bezüglich quantitativer Maße. Die Äußerungen der Nutzer können aber verfälscht werden, wenn diese im Vorfeld nicht darüber aufgeklärt wurden, dass sie keine bestimmte Erwartung zu erfüllen haben. Durch die Think-Aloud-Methode kann man die Effektivität und Zufriedenstellung der Benutzer messen, nicht aber die Effizienz.<br /> <br /> =Durchführung=<br /> Für die Abhaltung dieses User-Tests ist es Notwendig im Vorfeld ein Testszenario zu erstellen, dass dann die Nutzer beim eigentlichen Test soweit wie möglich erledigen sollen. Das Szenario sollte dabei möglichst reale Aufgaben und Ziele enthalten. <br /> Vor Beginn eines Tests wird der jeweilige Testnutzer noch (kurz) in das System sowie in die Aufgaben eingewiesen. <br /> <br /> Während des Tests sollte der Fachmann so wenig wie möglich Einfluß auf den Test-User nehmen. Er kann aber durchaus Hilfestellungen geben, wenn dies erforderlich ist, diese sollte aber nur zur Testprozedur selbst sein und nicht zum Inhalt. Wenn der Tester Einfluß nimmt, dann sollte dies immer in Form von offenen Fragen geschehen, um den User zum Weitersprechen zu animieren. Der Experte sollte nie versuchen, Lösungen zu präsentieren.<br /> Im Anschluss an den Test wird der Nutzer noch zu seinen Erfahrungen und zu seinen Eindrücken befragt. Dies liefert erneut wichtige Erkenntnisse, aus denen konkrete Optimierungspotentiale abgeleitet werden können. <br /> <br /> =Ergebnis=<br /> Im Anschluss an die Tests wird das aufgezeichnete Video- und Tonmaterial ausgewertet. Die Ergebnisse werden mit den Eindrücken, Kommentaren der Probanden und den Befragungen verglichen, anschließend diskutiert und dann zu einm Gesamtbild zusammengefasst.<br /> <br /> =Quellen=<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516 <br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc.<br /> *[http://www.fit-fuer-usability.de/1x1/messen/thinking.html Bitte laut denken: &quot;Thinking Aloud&quot;]<br /> <br /> =Links=<br /> *[http://www.usabilityhome.com/ThinkAlo.htm Think Aloud Protocol]<br /> *[http://www.usability.gov/refine/learnusa.html Learn about Usability Testing]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Severity_Ranking&diff=11914 2008-07-04T10:20:46Z

<p>Borchert: </p> <hr /> <div>=Definition=<br /> Das '''Severity Ranking''' ist eine Zusatzmethode zum Bewerten der Ergebnisse der [http://glossar.fh-augsburg.de/Heuristische_evaluation heuristischen Evaluation].<br /> <br /> =Beschreibung=<br /> Die [http://glossar.fh-augsburg.de/Heuristische_evaluation heuristische Evaluation] liefert als Ergebnis nur eine einfache Liste aller gefundenen Usability-Probleme. Das Severity Ranikng (dt. etwa Ernsthaftigkeits-Rangliste) bietet die Möglichkeit die Schwere der einzelnen Probleme zu gewichten, <br /> <br /> Da es schwer bzw. so gut wie unmöglich ist dies direkt während der Evaluation zu tun, geschieht dies mit Hilfe eines Fragebogens, der für die Evaluatoren nach dem Test erstellt wird. Er stellt die Probleme aller Tester kurz dar. Es kann dadurch festgestellt werden, ob ein Problem nur von kosmetischer Natur ist oder eine wahre Usability-Katastrophe. Für die Bestimmung der Schwere eines Usability-Problems gibt es folgende drei Faktoren:<br /> <br /> *Die ''Häufigkeit'' des Problems<br /> *Die ''Härte'' des Problems<br /> *Die ''Beständigkeit'' des Problems – Ist es ein einmaliges Problem, das der User bewältigen kann nachdem er einmal davon weiß oder wird es ihn permanent stören? <br /> <br /> Neben den drei genannten Faktoren sollte auch abgeschätzen werden, welche (Markt-)Auswirkungen ein Problem hat. Bestimmte Usability-Probleme können einen verheerenden Effekt auf die Popularität eines Produkts haben, selbst wenn der Fehler einfach zu beheben ist.<br /> <br /> Der Fragebogen sollte von mindestens drei der Evaluatoren, die die heuristische Evaluation durchgführt haben, beantwortet werden. <br /> <br /> =Klassifikation der Probleme=<br /> Die gefundenen Probleme werden meistens anhand der folgender 5-Punkte Skala eingeordnet:<br /> <br /> {| class=&quot;prettytable&quot;<br /> |- class=&quot;hintergrundfarbe5&quot;<br /> |0 || Ich stimme nicht zu, dass das überhaupt ein Usability-Problem ist<br /> |-<br /> |1 || Kosmetisches Problem – Braucht nicht gemacht zu werden außer es ist Zeit dafür vorhanden<br /> |-<br /> |2 || Kleines Usability-Problem – Niedrige Priorität bei Bearbeitung<br /> |-<br /> |3 || Großes Usabilty-Problem – Hohe Priorität, wichtig bei Bearbeitung<br /> |-<br /> |4 || Usability-Katastrophe – Muss zwingend gemacht werden <br /> |}<br /> <br /> Als Abschluß werden die Ergebnisse der Evaluatoren zu einer Gesamtbewertung zusammengefasst, die die Probleme der Gesamtgewichtung nach deutlich aufzeigt.<br /> <br /> =Quellen=<br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc. <br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.<br /> <br /> [[Kategorie:HCI]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Heuristische_Evaluation&diff=11913 2008-07-04T10:19:58Z

<p>Borchert: </p> <hr /> <div>=Definition=<br /> Bei der '''heuristischen Evaluation''' handelt es sich um eine systematische Usability-Inspektionsmethode um Usability-Probleme in einem User-Interface Design zu finden. <br /> Zur heuristischen Evaluation gehört immer eine kleine Gruppe von (Usability-)Experten die die Gebrauchsfähigkeit bzw. Konformität des Interfaces begutachtet und anhand von allgemeinen und einfachen Kriterien - den Heuristiken - beurteilt.<br /> <br /> =Evaluatoren=<br /> Da ein Evaluator nur rund 35% der Usability-Probleme eine Interfaces findet ist es sinnvoll mit mehreren Evaluatoren zu arbeiten. Nielsen und Molich schlagen in ihren Arbeiten für eine Evaluation drei bis fünf Evaluatoren vor, da kaum noch zusätzliche Informationen durch eine größere Zahl von Evaluatoren gewonnen wird.<br /> Bei der Auswahl der Evaluatoren sollte berücksichtig werden, dass sich die Auswahl verschiedener Evaluatoren positiv auf das Finden von Problemen auswirkt,was auch Studienergebnisse von Nielsen und Molich belegen. So sollten unter den Evaluatoren zwar hauptsächlich Experten sein die sich mit Usability beschäftigen, aber wenn es möglich ist auch ein End-User bzw. ein Experte der sich mit dem Anwendungsgebiet für das das System gedacht ist auskennt um eventuelle, spezielle Usability-Probleme zu finden.<br /> <br /> Die exakte Zahl der Evaluatoren die tatsächlich für eine heuristische Evaluation herangezogen werden hängt allerdings auch sehr stark von der Kosten-Nutzen-Analyse ab, die für jedes System anderes ausfällt und somit neu berechnet wird. Sie errechnet sich aus Fixkosten und variablen Kosten. Die Fixkosten ergeben sich aus dem Preis der benötigten Materialien, der Planungszeit und dem Schreiben des Reportes. Sie betragen meist zwischen $3,700 und $4,800. Dazu kommen die variablen Kosten, wie der Lohn pro Evaluator, die Analyse der einzelnen Reporte, die Kosten der Hilfsmittel u.a. Diese Kosten bewegen sich zwischen $410 und $900 pro Evaluator<br /> <br /> =Heuristiken=<br /> Die Heuristiken dienen bzw. helfen den Evaluatoren bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist.Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden.<br /> <br /> Als Beispiel für allgemeine Heuristiken diente die folgende 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt , aber 1994 nochmals von Nielsen, nach mehreren Studien, verfeinert wurde. <br /> <br /> Die Heuristiken oder Leitfäden dienen bzw. helfen den Evaluatoren, wie in der Einleitung erwähnt, bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist. Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden [1].<br /> Als Beispiel für allgemeine Heuristiken eine 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt, aber 1994 nochmals von Nielsen nach mehreren Studien verfeinert wurde.<br /> <br /> *''Sichtbarkeit des Systemstatus'' - Das System sollte dem User mit angebrachten Infos fortwährende mitteilen was geschieht <br /> <br /> *''Anpassung zwischen System und reeller Welt'' - Das System sollte in Wort und Phrase die Sprache der Anwender sprechen und nicht zu systemorientiert sein<br /> <br /> *''Benutzerkontrolle und –freiheit'' - Da User öfter mal Fehler machen sollte das System hierfür „Emergency Exits“ haben, sowie Undo- und Redo-Funktionen<br /> <br /> *''Konsistenz und Standards'' - Das System sollte Konsistent sein und bestimmten Standards folgen, damit sich der User immer zurechtfindet<br /> <br /> *''Fehler vermeiden'' - Besser als jede gute Fehlermeldung ist die Vermeidung von Fehlern<br /> <br /> *''Wiedererkennen statt sich erinnern'' - Die Bedienung sollte soweit es geht selbsterklärend sein ohne das sich der User groß erinnern muss. Auch sollte er sich nicht Informationen von einem Dialog für einen anderen merken müssen.<br /> <br /> *''Flexibilität und Effizienz'' - Für erfahrene User sollte es Abkürzungen geben die das Arbeiten mit dem System beschleunigen. Die „Shortcuts“ sollten allerdings Anfänger nicht verwirren. User sollten sich auch von ihnen häufig verwendete Funktionen speziell zurechtlegen können.<br /> <br /> *''Ästhetik und minimalistisches Design'' - Dialoge sollten notwendige Informationen enthalten. Jede zusätzliche Information lenkt nur von den Fakten ab und hält den Benutzer auf.<br /> <br /> *''Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern'' - Fehlermeldungen sollten in verständlicher Sprache sein, das Problem genau beschreiben und Lösung vorschlagen<br /> <br /> *''Hilfe und Dokumentation'' - Selbst wenn der User für die Nutzung des System keinerlei Unterstützung bedarf, sollte es doch, gerade bei komplexen Interfaces, gute Dokumentation geben die in die Struktur integriert sind. Eine Hilfe an entsprechender Stelle sollte sowohl kontextabhängig als auch verständlich verfasst sein und konstruktive Lösungsansätze bieten.<br /> <br /> =Durchführung=<br /> Bei der Evaluation selbst geht jeder Experte das Interface mehrmals durch und begutachtet die verschiedenen Dialogelemente und vergleicht diese dabei mit allgemeinen und/oder speziellen Heuristiken bzw. Usability-Prinzipien. Die Evaluatoren entscheiden selbst wie sie das Interface durchgehen, meistens zweimal. Beim ersten Durchlauf um ein Gefühl für das Interface und den allgemeinen Anwendungsbereich des Systems zu bekommen. Beim Zweiten achten sie dann auf spezielle Interface-Elemente und wie diese ins Gesamtbild passen.<br /> <br /> Erst nachdem alle Evaluationen abgeschlossen sind dürfen sich die Experten untereinander austauschen und ihre Ergebnisse zusammenführen. Dieses Verfahren ist Notwendig um sicherzustellen, dass die Evaluationen der einzelnen Personen unabhängig und vorurteilsfrei sind. Eine Evaluation eines Experten sollte durchschnittliche 1 bis 2 Stunden dauern. Sollte es durch die Komplexität des Produkts notwendig sein eine längere Evaluation abzuhalten, so ist es sinnvoll diese in mehrere kleinere aufzuspalten, welche sich dann jeweils nur mit einem bestimmten Aspekt beschäftigen. <br /> <br /> Die Erfassung der Evaluationen kann auf verschiedene Weiser geschehen. Zum einen als geschriebener Bericht des Evaluatoren selbst, was den Aufwand für den Evaluator selbst erhöht da er sich nicht ausschließlich auf das Interface konzentrieren kann, dafür erhält man aber einen formalen Bericht.<br /> Zum anderen eine Erfassung durch einen Beobachter, dem der Evaluator während er das Interface begutachtet seine Ergebnisse sagt und dieser sie schriftlich festhält. Hierbei sollten die Evaluatoren dem Beobachter allerdings alle von ihnen gefundenen Verstöße gegen die Heuristiken einzeln mitteilen, was in der Praxis nicht immer so problemlos klappt, da sie mehr mit dem Finden von Fehlern als der Mitteilung dieser beschäftigt sind. Der Beobachter darf darüber hinaus die Ergebnisse und Kommentare nur erfassen, sie aber nicht selber bewerten wie beim zum User-Testing. <br /> Trotzdem bringt diese Form der Erfassung viele Vorteile mit sich. Sie reduziert zum einen die Arbeitslast für den Evaluator, zum anderen braucht der Beobachter nur ein Set von Notizen zu bearbeiten, das er dazu noch selbst geschrieben hat. Ein Ergebnis der gesamten Evaluation steht dadurch auch schneller zu Verfügung. <br /> <br /> Eine Evaluation mit Beobachter hat auch noch den Vorteil, dass der Beobachter Fragen während der Evaluation beantworten kann und auch soll, aber nur solche die das Anwendungsgebiet des Interfaces betreffen. Dies hat vor allem Vorteile für Evaluatoren die keine Experten auf diesem Gebiet sind. Zum anderen kann der Beobachter auch Hinweise zum Gebrauch des Interfaces geben, falls es zu Problemen bei der Nutzung kommt. Dadurch wird auch teure und kostbare Evaluationszeit gespart. Allerdings muss noch erwähnt werden, dass der Beobachter den Evaluatoren von sich selbst aus erst Hilfe geben darf, wenn sie in richtigen Schwierigkeiten sind und sie sich zu dem aufgetretenen Usability-Problem geäußert haben. Um dies alles zu Garantieren muss der für die Evaluation gewählte Beobachten eine Experte auf diesem Gebiet sein und sich natürlich auch mit dem Interface sehr gut auskennen.<br /> <br /> =Ergebnis=<br /> Das Ergebnis einer Heuristischen Evaluation ist eine Liste der gefundenen Usability-Probleme. Da diese Liste die einzelnen Meinungen der Evaluatoren wieder spiegelt, müssen diese, in Verbindung mit den Heuristiken oder anderen Usability-Ergebnissen, erklären warum sie etwas nicht mochten oder was ihnen nicht gefiel. Allerdings zeigt diese Methode keinen gezielten Ansatz zur Lösung der gefundenen Probleme auf <br /> <br /> =Erweiterung=<br /> Als Erweiterung der einfachen Liste von Usability-Problemen eines Interfaces, die man als Ergebnis aus der Heuristischen Evaluation erhält gibt es die Möglichkeit die schwere der einzelnen Probleme zu gewichten, das so genannte [http://glossar.fh-augsburg.de/Severity_Ranking Severity Ranking]. <br /> <br /> =Quellen=<br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc. <br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516 <br /> <br /> =Links=<br /> *[http://www.useit.com/papers/heuristic/heuristic_evaluation.html Nielsen, J.: Heuristic Evaluation]<br /> *[http://www.fit-fuer-usability.de/1x1/messen/heuristik.html Über den Daumen: Heuristische Evaluation]<br /> <br /> [[Kategorie:HCI]]<br /> [[Kategorie:Content-Management-System]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Heuristische_Evaluation&diff=11912 2008-07-04T10:19:36Z

<p>Borchert: </p> <hr /> <div>=Definition=<br /> Bei der '''heuristischen Evaluation''' handelt es sich um eine systematische Usability-Inspektionsmethode um Usability-Probleme in einem User-Interface Design zu finden. <br /> Zur heuristischen Evaluation gehört immer eine kleine Gruppe von (Usability-)Experten die die Gebrauchsfähigkeit bzw. Konformität des Interfaces begutachtet und anhand von allgemeinen und einfachen Kriterien - den Heuristiken - beurteilt.<br /> <br /> =Evaluatoren=<br /> Da ein Evaluator nur rund 35% der Usability-Probleme eine Interfaces findet ist es sinnvoll mit mehreren Evaluatoren zu arbeiten. Nielsen und Molich schlagen in ihren Arbeiten für eine Evaluation drei bis fünf Evaluatoren vor, da kaum noch zusätzliche Informationen durch eine größere Zahl von Evaluatoren gewonnen wird.<br /> Bei der Auswahl der Evaluatoren sollte berücksichtig werden, dass sich die Auswahl verschiedener Evaluatoren positiv auf das Finden von Problemen auswirkt,was auch Studienergebnisse von Nielsen und Molich belegen. So sollten unter den Evaluatoren zwar hauptsächlich Experten sein die sich mit Usability beschäftigen, aber wenn es möglich ist auch ein End-User bzw. ein Experte der sich mit dem Anwendungsgebiet für das das System gedacht ist auskennt um eventuelle, spezielle Usability-Probleme zu finden.<br /> <br /> Die exakte Zahl der Evaluatoren die tatsächlich für eine heuristische Evaluation herangezogen werden hängt allerdings auch sehr stark von der Kosten-Nutzen-Analyse ab, die für jedes System anderes ausfällt und somit neu berechnet wird. Sie errechnet sich aus Fixkosten und variablen Kosten. Die Fixkosten ergeben sich aus dem Preis der benötigten Materialien, der Planungszeit und dem Schreiben des Reportes. Sie betragen meist zwischen $3,700 und $4,800. Dazu kommen die variablen Kosten, wie der Lohn pro Evaluator, die Analyse der einzelnen Reporte, die Kosten der Hilfsmittel u.a. Diese Kosten bewegen sich zwischen $410 und $900 pro Evaluator<br /> <br /> =Heuristiken=<br /> Die Heuristiken dienen bzw. helfen den Evaluatoren bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist.Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden.<br /> <br /> Als Beispiel für allgemeine Heuristiken diente die folgende 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt , aber 1994 nochmals von Nielsen, nach mehreren Studien, verfeinert wurde. <br /> <br /> Die Heuristiken oder Leitfäden dienen bzw. helfen den Evaluatoren, wie in der Einleitung erwähnt, bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist. Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden [1].<br /> Als Beispiel für allgemeine Heuristiken eine 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt, aber 1994 nochmals von Nielsen nach mehreren Studien verfeinert wurde.<br /> <br /> *''Sichtbarkeit des Systemstatus'' - Das System sollte dem User mit angebrachten Infos fortwährende mitteilen was geschieht <br /> <br /> *''Anpassung zwischen System und reeller Welt'' - Das System sollte in Wort und Phrase die Sprache der Anwender sprechen und nicht zu systemorientiert sein<br /> <br /> *''Benutzerkontrolle und –freiheit'' - Da User öfter mal Fehler machen sollte das System hierfür „Emergency Exits“ haben, sowie Undo- und Redo-Funktionen<br /> <br /> *''Konsistenz und Standards'' - Das System sollte Konsistent sein und bestimmten Standards folgen, damit sich der User immer zurechtfindet<br /> <br /> *''Fehler vermeiden'' - Besser als jede gute Fehlermeldung ist die Vermeidung von Fehlern<br /> <br /> *''Wiedererkennen statt sich erinnern'' - Die Bedienung sollte soweit es geht selbsterklärend sein ohne das sich der User groß erinnern muss. Auch sollte er sich nicht Informationen von einem Dialog für einen anderen merken müssen.<br /> <br /> *''Flexibilität und Effizienz'' - Für erfahrene User sollte es Abkürzungen geben die das Arbeiten mit dem System beschleunigen. Die „Shortcuts“ sollten allerdings Anfänger nicht verwirren. User sollten sich auch von ihnen häufig verwendete Funktionen speziell zurechtlegen können.<br /> <br /> *''Ästhetik und minimalistisches Design'' - Dialoge sollten notwendige Informationen enthalten. Jede zusätzliche Information lenkt nur von den Fakten ab und hält den Benutzer auf.<br /> <br /> *''Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern'' - Fehlermeldungen sollten in verständlicher Sprache sein, das Problem genau beschreiben und Lösung vorschlagen<br /> <br /> *''Hilfe und Dokumentation'' - Selbst wenn der User für die Nutzung des System keinerlei Unterstützung bedarf, sollte es doch, gerade bei komplexen Interfaces, gute Dokumentation geben die in die Struktur integriert sind. Eine Hilfe an entsprechender Stelle sollte sowohl kontextabhängig als auch verständlich verfasst sein und konstruktive Lösungsansätze bieten.<br /> <br /> =Durchführung=<br /> Bei der Evaluation selbst geht jeder Experte das Interface mehrmals durch und begutachtet die verschiedenen Dialogelemente und vergleicht diese dabei mit allgemeinen und/oder speziellen Heuristiken bzw. Usability-Prinzipien. Die Evaluatoren entscheiden selbst wie sie das Interface durchgehen, meistens zweimal. Beim ersten Durchlauf um ein Gefühl für das Interface und den allgemeinen Anwendungsbereich des Systems zu bekommen. Beim Zweiten achten sie dann auf spezielle Interface-Elemente und wie diese ins Gesamtbild passen.<br /> <br /> Erst nachdem alle Evaluationen abgeschlossen sind dürfen sich die Experten untereinander austauschen und ihre Ergebnisse zusammenführen. Dieses Verfahren ist Notwendig um sicherzustellen, dass die Evaluationen der einzelnen Personen unabhängig und vorurteilsfrei sind. Eine Evaluation eines Experten sollte durchschnittliche 1 bis 2 Stunden dauern. Sollte es durch die Komplexität des Produkts notwendig sein eine längere Evaluation abzuhalten, so ist es sinnvoll diese in mehrere kleinere aufzuspalten, welche sich dann jeweils nur mit einem bestimmten Aspekt beschäftigen. <br /> <br /> Die Erfassung der Evaluationen kann auf verschiedene Weiser geschehen. Zum einen als geschriebener Bericht des Evaluatoren selbst, was den Aufwand für den Evaluator selbst erhöht da er sich nicht ausschließlich auf das Interface konzentrieren kann, dafür erhält man aber einen formalen Bericht.<br /> Zum anderen eine Erfassung durch einen Beobachter, dem der Evaluator während er das Interface begutachtet seine Ergebnisse sagt und dieser sie schriftlich festhält. Hierbei sollten die Evaluatoren dem Beobachter allerdings alle von ihnen gefundenen Verstöße gegen die Heuristiken einzeln mitteilen, was in der Praxis nicht immer so problemlos klappt, da sie mehr mit dem Finden von Fehlern als der Mitteilung dieser beschäftigt sind. Der Beobachter darf darüber hinaus die Ergebnisse und Kommentare nur erfassen, sie aber nicht selber bewerten wie beim zum User-Testing. <br /> Trotzdem bringt diese Form der Erfassung viele Vorteile mit sich. Sie reduziert zum einen die Arbeitslast für den Evaluator, zum anderen braucht der Beobachter nur ein Set von Notizen zu bearbeiten, das er dazu noch selbst geschrieben hat. Ein Ergebnis der gesamten Evaluation steht dadurch auch schneller zu Verfügung. <br /> <br /> Eine Evaluation mit Beobachter hat auch noch den Vorteil, dass der Beobachter Fragen während der Evaluation beantworten kann und auch soll, aber nur solche die das Anwendungsgebiet des Interfaces betreffen. Dies hat vor allem Vorteile für Evaluatoren die keine Experten auf diesem Gebiet sind. Zum anderen kann der Beobachter auch Hinweise zum Gebrauch des Interfaces geben, falls es zu Problemen bei der Nutzung kommt. Dadurch wird auch teure und kostbare Evaluationszeit gespart. Allerdings muss noch erwähnt werden, dass der Beobachter den Evaluatoren von sich selbst aus erst Hilfe geben darf, wenn sie in richtigen Schwierigkeiten sind und sie sich zu dem aufgetretenen Usability-Problem geäußert haben. Um dies alles zu Garantieren muss der für die Evaluation gewählte Beobachten eine Experte auf diesem Gebiet sein und sich natürlich auch mit dem Interface sehr gut auskennen.<br /> <br /> =Ergebnis=<br /> Das Ergebnis einer Heuristischen Evaluation ist eine Liste der gefundenen Usability-Probleme. Da diese Liste die einzelnen Meinungen der Evaluatoren wieder spiegelt, müssen diese, in Verbindung mit den Heuristiken oder anderen Usability-Ergebnissen, erklären warum sie etwas nicht mochten oder was ihnen nicht gefiel. Allerdings zeigt diese Methode keinen gezielten Ansatz zur Lösung der gefundenen Probleme auf <br /> <br /> =Erweiterung=<br /> Als Erweiterung der einfachen Liste von Usability-Problemen eines Interfaces, die man als Ergebnis aus der Heuristischen Evaluation erhält gibt es die Möglichkeit die schwere der einzelnen Probleme zu gewichten, das so genannte [http://glossar.fh-augsburg.de/Severity_Ranking Severty Ranking]. <br /> <br /> =Quellen=<br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc. <br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516 <br /> <br /> =Links=<br /> *[http://www.useit.com/papers/heuristic/heuristic_evaluation.html Nielsen, J.: Heuristic Evaluation]<br /> *[http://www.fit-fuer-usability.de/1x1/messen/heuristik.html Über den Daumen: Heuristische Evaluation]<br /> <br /> [[Kategorie:HCI]]<br /> [[Kategorie:Content-Management-System]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Severity_Ranking&diff=11911 2008-07-04T10:18:54Z

<p>Borchert: </p> <hr /> <div>=Definition=<br /> Das '''Severity Ranking''' ist eine Zusatzmethode zum Bewerten der Ergebnisse der [http://glossar.fh-augsburg.de/Heuristische_evaluation heuristischen Evaluation].<br /> <br /> =Beschreibung=<br /> Die [http://glossar.fh-augsburg.de/Heuristische_evaluation heuristische Evaluation] liefert als Ergebnis nur eine einfache Liste aller gefundenen Usability-Probleme. Das Severity Ranikng (dt. etwa Ernsthaftigkeits-Rangliste) bietet die Möglichkeit die Schwere der einzelnen Probleme zu gewichten, <br /> <br /> Da es schwer bzw. so gut wie unmöglich ist dies direkt während der Evaluation zu tun, geschieht dies mit Hilfe eines Fragebogens, der für die Evaluatoren nach dem Test erstellt wird. Er stellt die Probleme aller Tester kurz dar. Es kann dadurch festgestellt werden, ob ein Problem nur von kosmetischer Natur ist oder eine wahre Usability-Katastrophe. Für die Bestimmung der Schwere eines Usability-Problems gibt es folgende drei Faktoren:<br /> <br /> *Die ''Häufigkeit'' des Problems<br /> *Die ''Härte'' des Problems<br /> *Die ''Beständigkeit'' des Problems – Ist es ein einmaliges Problem, das der User bewältigen kann nachdem er einmal davon weiß oder wird es ihn permanent stören? <br /> <br /> Neben den drei genannten Faktoren sollte auch abgeschätzen werden, welche (Markt-)Auswirkungen ein Problem hat. Bestimmte Usability-Probleme können einen verheerenden Effekt auf die Popularität eines Produkts haben, selbst wenn der Fehler einfach zu beheben ist.<br /> <br /> Der Fragebogen sollte von mindestens drei der Evaluatoren, die die heuristische Evaluation durchgführt haben, beantwortet werden. <br /> <br /> =Klassifikation der Probleme=<br /> Die gefundenen Probleme werden meistens anhand der folgender 5-Punkte Skala eingeordnet:<br /> <br /> {| class=&quot;prettytable&quot;<br /> |- class=&quot;hintergrundfarbe5&quot;<br /> |0 || Ich stimme nicht zu, dass das überhaupt ein Usability-Problem ist<br /> |-<br /> |1 || Kosmetisches Problem – Braucht nicht gemacht zu werden außer es ist Zeit dafür vorhanden<br /> |-<br /> |2 || Kleines Usability-Problem – Niedrige Priorität bei Bearbeitung<br /> |-<br /> |3 || Großes Usabilty-Problem – Hohe Priorität, wichtig bei Bearbeitung<br /> |-<br /> |4 || Usability-Katastrophe – Muss zwingend gemacht werden <br /> |}<br /> <br /> Als Abschluß werden die Ergebnisse der Evaluatoren zu einer Gesamtbewertung zusammengefasst, die die Probleme der Gesamtgewichtung nach deutlich aufzeigt.<br /> <br /> =Quellen=<br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc. <br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Severity_Ranking&diff=11910 2008-07-04T10:17:53Z

<p>Borchert: </p> <hr /> <div>=Definition=<br /> Das '''Severity Ranking''' ist eine Zusatzmethode zum Bewerten der Ergebnisse der [http://glossar.fh-augsburg.de/Heuristische_evaluation heuristischen Evaluation].<br /> <br /> =Beschreibung=<br /> Die [http://glossar.fh-augsburg.de/Heuristische_evaluation heuristische Evaluation] liefert als Ergebnis nur eine einfache Liste aller gefundenen Usability-Probleme. Das Severity Ranikng (dt. etwa Ernsthaftigkeits-Rangliste) bietet die Möglichkeit die Schwere der einzelnen Probleme zu gewichten, <br /> <br /> Da es schwer bzw. so gut wie unmöglich ist dies direkt während der Evaluation zu tun, geschieht dies mit Hilfe eines Fragebogens, der für die Evaluatoren nach dem Test erstellt wird. Er stellt die Probleme aller Tester kurz dar. Es kann dadurch festgestellt werden, ob ein Problem nur von kosmetischer Natur ist oder eine wahre Usability-Katastrophe. Für die Bestimmung der Schwere eines Usability-Problems gibt es folgende drei Faktoren:<br /> <br /> *Die ''Häufigkeit'' des Problems<br /> *Die ''Härte'' des Problems<br /> *Die ''Beständigkeit'' des Problems – Ist es ein einmaliges Problem, das der User bewältigen kann nachdem er einmal davon weiß oder wird es ihn permanent stören? <br /> <br /> Neben den drei genannten Faktoren sollte auch abgeschätzen werden, welche (Markt-)Auswirkungen ein Problem hat. Bestimmte Usability-Probleme können einen verheerenden Effekt auf die Popularität eines Produkts haben, selbst wenn der Fehler einfach zu beheben ist.<br /> <br /> Der Fragebogen sollte von mindestens drei der Evaluatoren, die die heuristische Evaluation durchgführt haben, beantwortet werden. <br /> <br /> =Klassifikation der Probleme=<br /> Die gefundenen Probleme werden meistens anhand der folgender 5-Punkte Skala eingeordnet:<br /> <br /> {| class=&quot;prettytable&quot;<br /> |- class=&quot;hintergrundfarbe5&quot;<br /> |0 || Ich stimme nicht zu, dass das überhaupt ein Usability-Problem ist<br /> |-<br /> |1 || Kosmetisches Problem – Braucht nicht gemacht zu werden außer es ist Zeit dafür vorhanden<br /> |-<br /> |2 || Kleines Usability-Problem – Niedrige Priorität bei Bearbeitung<br /> |-<br /> |3 || Großes Usabilty-Problem – Hohe Priorität, wichtig bei Bearbeitung<br /> |-<br /> |4 || Usability-Katastrophe – Muss zwingend gemacht werden <br /> |}<br /> <br /> Als Abschluß werden die Ergebnisse der Evaluatoren zu einer Gesamtbewertung zusammengefasst, die deutlich<br /> <br /> =Quellen=<br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc. <br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Heuristische_Evaluation&diff=11909 2008-07-03T18:24:06Z

<p>Borchert: </p> <hr /> <div>=Definition=<br /> Bei der '''heuristischen Evaluation''' handelt es sich um eine systematische Usability-Inspektionsmethode um Usability-Probleme in einem User-Interface Design zu finden. <br /> Zur heuristischen Evaluation gehört immer eine kleine Gruppe von (Usability-)Experten die die Gebrauchsfähigkeit bzw. Konformität des Interfaces begutachtet und anhand von allgemeinen und einfachen Kriterien - den Heuristiken - beurteilt.<br /> <br /> =Evaluatoren=<br /> Da ein Evaluator nur rund 35% der Usability-Probleme eine Interfaces findet ist es sinnvoll mit mehreren Evaluatoren zu arbeiten. Nielsen und Molich schlagen in ihren Arbeiten für eine Evaluation drei bis fünf Evaluatoren vor, da kaum noch zusätzliche Informationen durch eine größere Zahl von Evaluatoren gewonnen wird.<br /> Bei der Auswahl der Evaluatoren sollte berücksichtig werden, dass sich die Auswahl verschiedener Evaluatoren positiv auf das Finden von Problemen auswirkt,was auch Studienergebnisse von Nielsen und Molich belegen. So sollten unter den Evaluatoren zwar hauptsächlich Experten sein die sich mit Usability beschäftigen, aber wenn es möglich ist auch ein End-User bzw. ein Experte der sich mit dem Anwendungsgebiet für das das System gedacht ist auskennt um eventuelle, spezielle Usability-Probleme zu finden.<br /> <br /> Die exakte Zahl der Evaluatoren die tatsächlich für eine heuristische Evaluation herangezogen werden hängt allerdings auch sehr stark von der Kosten-Nutzen-Analyse ab, die für jedes System anderes ausfällt und somit neu berechnet wird. Sie errechnet sich aus Fixkosten und variablen Kosten. Die Fixkosten ergeben sich aus dem Preis der benötigten Materialien, der Planungszeit und dem Schreiben des Reportes. Sie betragen meist zwischen $3,700 und $4,800. Dazu kommen die variablen Kosten, wie der Lohn pro Evaluator, die Analyse der einzelnen Reporte, die Kosten der Hilfsmittel u.a. Diese Kosten bewegen sich zwischen $410 und $900 pro Evaluator<br /> <br /> =Heuristiken=<br /> Die Heuristiken dienen bzw. helfen den Evaluatoren bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist.Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden.<br /> <br /> Als Beispiel für allgemeine Heuristiken diente die folgende 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt , aber 1994 nochmals von Nielsen, nach mehreren Studien, verfeinert wurde. <br /> <br /> Die Heuristiken oder Leitfäden dienen bzw. helfen den Evaluatoren, wie in der Einleitung erwähnt, bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist. Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden [1].<br /> Als Beispiel für allgemeine Heuristiken eine 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt, aber 1994 nochmals von Nielsen nach mehreren Studien verfeinert wurde.<br /> <br /> *''Sichtbarkeit des Systemstatus'' - Das System sollte dem User mit angebrachten Infos fortwährende mitteilen was geschieht <br /> <br /> *''Anpassung zwischen System und reeller Welt'' - Das System sollte in Wort und Phrase die Sprache der Anwender sprechen und nicht zu systemorientiert sein<br /> <br /> *''Benutzerkontrolle und –freiheit'' - Da User öfter mal Fehler machen sollte das System hierfür „Emergency Exits“ haben, sowie Undo- und Redo-Funktionen<br /> <br /> *''Konsistenz und Standards'' - Das System sollte Konsistent sein und bestimmten Standards folgen, damit sich der User immer zurechtfindet<br /> <br /> *''Fehler vermeiden'' - Besser als jede gute Fehlermeldung ist die Vermeidung von Fehlern<br /> <br /> *''Wiedererkennen statt sich erinnern'' - Die Bedienung sollte soweit es geht selbsterklärend sein ohne das sich der User groß erinnern muss. Auch sollte er sich nicht Informationen von einem Dialog für einen anderen merken müssen.<br /> <br /> *''Flexibilität und Effizienz'' - Für erfahrene User sollte es Abkürzungen geben die das Arbeiten mit dem System beschleunigen. Die „Shortcuts“ sollten allerdings Anfänger nicht verwirren. User sollten sich auch von ihnen häufig verwendete Funktionen speziell zurechtlegen können.<br /> <br /> *''Ästhetik und minimalistisches Design'' - Dialoge sollten notwendige Informationen enthalten. Jede zusätzliche Information lenkt nur von den Fakten ab und hält den Benutzer auf.<br /> <br /> *''Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern'' - Fehlermeldungen sollten in verständlicher Sprache sein, das Problem genau beschreiben und Lösung vorschlagen<br /> <br /> *''Hilfe und Dokumentation'' - Selbst wenn der User für die Nutzung des System keinerlei Unterstützung bedarf, sollte es doch, gerade bei komplexen Interfaces, gute Dokumentation geben die in die Struktur integriert sind. Eine Hilfe an entsprechender Stelle sollte sowohl kontextabhängig als auch verständlich verfasst sein und konstruktive Lösungsansätze bieten.<br /> <br /> =Durchführung=<br /> Bei der Evaluation selbst geht jeder Experte das Interface mehrmals durch und begutachtet die verschiedenen Dialogelemente und vergleicht diese dabei mit allgemeinen und/oder speziellen Heuristiken bzw. Usability-Prinzipien. Die Evaluatoren entscheiden selbst wie sie das Interface durchgehen, meistens zweimal. Beim ersten Durchlauf um ein Gefühl für das Interface und den allgemeinen Anwendungsbereich des Systems zu bekommen. Beim Zweiten achten sie dann auf spezielle Interface-Elemente und wie diese ins Gesamtbild passen.<br /> <br /> Erst nachdem alle Evaluationen abgeschlossen sind dürfen sich die Experten untereinander austauschen und ihre Ergebnisse zusammenführen. Dieses Verfahren ist Notwendig um sicherzustellen, dass die Evaluationen der einzelnen Personen unabhängig und vorurteilsfrei sind. Eine Evaluation eines Experten sollte durchschnittliche 1 bis 2 Stunden dauern. Sollte es durch die Komplexität des Produkts notwendig sein eine längere Evaluation abzuhalten, so ist es sinnvoll diese in mehrere kleinere aufzuspalten, welche sich dann jeweils nur mit einem bestimmten Aspekt beschäftigen. <br /> <br /> Die Erfassung der Evaluationen kann auf verschiedene Weiser geschehen. Zum einen als geschriebener Bericht des Evaluatoren selbst, was den Aufwand für den Evaluator selbst erhöht da er sich nicht ausschließlich auf das Interface konzentrieren kann, dafür erhält man aber einen formalen Bericht.<br /> Zum anderen eine Erfassung durch einen Beobachter, dem der Evaluator während er das Interface begutachtet seine Ergebnisse sagt und dieser sie schriftlich festhält. Hierbei sollten die Evaluatoren dem Beobachter allerdings alle von ihnen gefundenen Verstöße gegen die Heuristiken einzeln mitteilen, was in der Praxis nicht immer so problemlos klappt, da sie mehr mit dem Finden von Fehlern als der Mitteilung dieser beschäftigt sind. Der Beobachter darf darüber hinaus die Ergebnisse und Kommentare nur erfassen, sie aber nicht selber bewerten wie beim zum User-Testing. <br /> Trotzdem bringt diese Form der Erfassung viele Vorteile mit sich. Sie reduziert zum einen die Arbeitslast für den Evaluator, zum anderen braucht der Beobachter nur ein Set von Notizen zu bearbeiten, das er dazu noch selbst geschrieben hat. Ein Ergebnis der gesamten Evaluation steht dadurch auch schneller zu Verfügung. <br /> <br /> Eine Evaluation mit Beobachter hat auch noch den Vorteil, dass der Beobachter Fragen während der Evaluation beantworten kann und auch soll, aber nur solche die das Anwendungsgebiet des Interfaces betreffen. Dies hat vor allem Vorteile für Evaluatoren die keine Experten auf diesem Gebiet sind. Zum anderen kann der Beobachter auch Hinweise zum Gebrauch des Interfaces geben, falls es zu Problemen bei der Nutzung kommt. Dadurch wird auch teure und kostbare Evaluationszeit gespart. Allerdings muss noch erwähnt werden, dass der Beobachter den Evaluatoren von sich selbst aus erst Hilfe geben darf, wenn sie in richtigen Schwierigkeiten sind und sie sich zu dem aufgetretenen Usability-Problem geäußert haben. Um dies alles zu Garantieren muss der für die Evaluation gewählte Beobachten eine Experte auf diesem Gebiet sein und sich natürlich auch mit dem Interface sehr gut auskennen.<br /> <br /> =Ergebnis=<br /> Das Ergebnis einer Heuristischen Evaluation ist eine Liste der gefundenen Usability-Probleme. Da diese Liste die einzelnen Meinungen der Evaluatoren wieder spiegelt, müssen diese, in Verbindung mit den Heuristiken oder anderen Usability-Ergebnissen, erklären warum sie etwas nicht mochten oder was ihnen nicht gefiel. Allerdings zeigt diese Methode keinen gezielten Ansatz zur Lösung der gefundenen Probleme auf <br /> <br /> =Erweiterung=<br /> Als Erweiterung der einfachen Liste von Usability-Problemen eines Interfaces, die man als Ergebnis aus der Heuristischen Evaluation erhält gibt es die Möglichkeit die schwere der einzelnen Probleme zu gewichten, das so genannte Severty Ranking. <br /> <br /> =Quellen=<br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc. <br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516 <br /> <br /> =Links=<br /> *[http://www.useit.com/papers/heuristic/heuristic_evaluation.html Nielsen, J.: Heuristic Evaluation]<br /> *[http://www.fit-fuer-usability.de/1x1/messen/heuristik.html Über den Daumen: Heuristische Evaluation]<br /> <br /> [[Kategorie:HCI]]<br /> [[Kategorie:Content-Management-System]]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Heuristische_Evaluation&diff=11908 2008-07-03T18:16:54Z

<p>Borchert: /* Links */</p> <hr /> <div>=Definition=<br /> Bei der '''heuristischen Evaluation''' handelt es sich um eine systematische Usability-Inspektionsmethode um Usability-Probleme in einem User-Interface Design zu finden. <br /> Zur heuristischen Evaluation gehört immer eine kleine Gruppe von (Usability-)Experten die die Gebrauchsfähigkeit bzw. Konformität des Interfaces begutachtet und anhand von allgemeinen und einfachen Kriterien - den Heuristiken - beurteilt.<br /> <br /> =Evaluatoren=<br /> Da ein Evaluator nur rund 35% der Usability-Probleme eine Interfaces findet ist es sinnvoll mit mehreren Evaluatoren zu arbeiten. Nielsen und Molich schlagen in ihren Arbeiten für eine Evaluation drei bis fünf Evaluatoren vor, da kaum noch zusätzliche Informationen durch eine größere Zahl von Evaluatoren gewonnen wird.<br /> Bei der Auswahl der Evaluatoren sollte berücksichtig werden, dass sich die Auswahl verschiedener Evaluatoren positiv auf das Finden von Problemen auswirkt,was auch Studienergebnisse von Nielsen und Molich belegen. So sollten unter den Evaluatoren zwar hauptsächlich Experten sein die sich mit Usability beschäftigen, aber wenn es möglich ist auch ein End-User bzw. ein Experte der sich mit dem Anwendungsgebiet für das das System gedacht ist auskennt um eventuelle, spezielle Usability-Probleme zu finden.<br /> <br /> Die exakte Zahl der Evaluatoren die tatsächlich für eine heuristische Evaluation herangezogen werden hängt allerdings auch sehr stark von der Kosten-Nutzen-Analyse ab, die für jedes System anderes ausfällt und somit neu berechnet wird. Sie errechnet sich aus Fixkosten und variablen Kosten. Die Fixkosten ergeben sich aus dem Preis der benötigten Materialien, der Planungszeit und dem Schreiben des Reportes. Sie betragen meist zwischen $3,700 und $4,800. Dazu kommen die variablen Kosten, wie der Lohn pro Evaluator, die Analyse der einzelnen Reporte, die Kosten der Hilfsmittel u.a. Diese Kosten bewegen sich zwischen $410 und $900 pro Evaluator<br /> <br /> =Heuristiken=<br /> Die Heuristiken dienen bzw. helfen den Evaluatoren bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist.Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden.<br /> <br /> Als Beispiel für allgemeine Heuristiken diente die folgende 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt , aber 1994 nochmals von Nielsen, nach mehreren Studien, verfeinert wurde. <br /> <br /> Die Heuristiken oder Leitfäden dienen bzw. helfen den Evaluatoren, wie in der Einleitung erwähnt, bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist. Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden [1].<br /> Als Beispiel für allgemeine Heuristiken eine 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt, aber 1994 nochmals von Nielsen nach mehreren Studien verfeinert wurde.<br /> <br /> *''Sichtbarkeit des Systemstatus'' - Das System sollte dem User mit angebrachten Infos fortwährende mitteilen was geschieht <br /> <br /> *''Anpassung zwischen System und reeller Welt'' - Das System sollte in Wort und Phrase die Sprache der Anwender sprechen und nicht zu systemorientiert sein<br /> <br /> *''Benutzerkontrolle und –freiheit'' - Da User öfter mal Fehler machen sollte das System hierfür „Emergency Exits“ haben, sowie Undo- und Redo-Funktionen<br /> <br /> *''Konsistenz und Standards'' - Das System sollte Konsistent sein und bestimmten Standards folgen, damit sich der User immer zurechtfindet<br /> <br /> *''Fehler vermeiden'' - Besser als jede gute Fehlermeldung ist die Vermeidung von Fehlern<br /> <br /> *''Wiedererkennen statt sich erinnern'' - Die Bedienung sollte soweit es geht selbsterklärend sein ohne das sich der User groß erinnern muss. Auch sollte er sich nicht Informationen von einem Dialog für einen anderen merken müssen.<br /> <br /> *''Flexibilität und Effizienz'' - Für erfahrene User sollte es Abkürzungen geben die das Arbeiten mit dem System beschleunigen. Die „Shortcuts“ sollten allerdings Anfänger nicht verwirren. User sollten sich auch von ihnen häufig verwendete Funktionen speziell zurechtlegen können.<br /> <br /> *''Ästhetik und minimalistisches Design'' - Dialoge sollten notwendige Informationen enthalten. Jede zusätzliche Information lenkt nur von den Fakten ab und hält den Benutzer auf.<br /> <br /> *''Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern'' - Fehlermeldungen sollten in verständlicher Sprache sein, das Problem genau beschreiben und Lösung vorschlagen<br /> <br /> *''Hilfe und Dokumentation'' - Selbst wenn der User für die Nutzung des System keinerlei Unterstützung bedarf, sollte es doch, gerade bei komplexen Interfaces, gute Dokumentation geben die in die Struktur integriert sind. Eine Hilfe an entsprechender Stelle sollte sowohl kontextabhängig als auch verständlich verfasst sein und konstruktive Lösungsansätze bieten.<br /> <br /> =Durchführung=<br /> Bei der Evaluation selbst geht jeder Experte das Interface mehrmals durch und begutachtet die verschiedenen Dialogelemente und vergleicht diese dabei mit allgemeinen und/oder speziellen Heuristiken bzw. Usability-Prinzipien. Die Evaluatoren entscheiden selbst wie sie das Interface durchgehen, meistens zweimal. Beim ersten Durchlauf um ein Gefühl für das Interface und den allgemeinen Anwendungsbereich des Systems zu bekommen. Beim Zweiten achten sie dann auf spezielle Interface-Elemente und wie diese ins Gesamtbild passen.<br /> <br /> Erst nachdem alle Evaluationen abgeschlossen sind dürfen sich die Experten untereinander austauschen und ihre Ergebnisse zusammenführen. Dieses Verfahren ist Notwendig um sicherzustellen, dass die Evaluationen der einzelnen Personen unabhängig und vorurteilsfrei sind. Eine Evaluation eines Experten sollte durchschnittliche 1 bis 2 Stunden dauern. Sollte es durch die Komplexität des Produkts notwendig sein eine längere Evaluation abzuhalten, so ist es sinnvoll diese in mehrere kleinere aufzuspalten, welche sich dann jeweils nur mit einem bestimmten Aspekt beschäftigen. <br /> <br /> Die Erfassung der Evaluationen kann auf verschiedene Weiser geschehen. Zum einen als geschriebener Bericht des Evaluatoren selbst, was den Aufwand für den Evaluator selbst erhöht da er sich nicht ausschließlich auf das Interface konzentrieren kann, dafür erhält man aber einen formalen Bericht.<br /> Zum anderen eine Erfassung durch einen Beobachter, dem der Evaluator während er das Interface begutachtet seine Ergebnisse sagt und dieser sie schriftlich festhält. Hierbei sollten die Evaluatoren dem Beobachter allerdings alle von ihnen gefundenen Verstöße gegen die Heuristiken einzeln mitteilen, was in der Praxis nicht immer so problemlos klappt, da sie mehr mit dem Finden von Fehlern als der Mitteilung dieser beschäftigt sind. Der Beobachter darf darüber hinaus die Ergebnisse und Kommentare nur erfassen, sie aber nicht selber bewerten wie beim zum User-Testing. <br /> Trotzdem bringt diese Form der Erfassung viele Vorteile mit sich. Sie reduziert zum einen die Arbeitslast für den Evaluator, zum anderen braucht der Beobachter nur ein Set von Notizen zu bearbeiten, das er dazu noch selbst geschrieben hat. Ein Ergebnis der gesamten Evaluation steht dadurch auch schneller zu Verfügung. <br /> <br /> Eine Evaluation mit Beobachter hat auch noch den Vorteil, dass der Beobachter Fragen während der Evaluation beantworten kann und auch soll, aber nur solche die das Anwendungsgebiet des Interfaces betreffen. Dies hat vor allem Vorteile für Evaluatoren die keine Experten auf diesem Gebiet sind. Zum anderen kann der Beobachter auch Hinweise zum Gebrauch des Interfaces geben, falls es zu Problemen bei der Nutzung kommt. Dadurch wird auch teure und kostbare Evaluationszeit gespart. Allerdings muss noch erwähnt werden, dass der Beobachter den Evaluatoren von sich selbst aus erst Hilfe geben darf, wenn sie in richtigen Schwierigkeiten sind und sie sich zu dem aufgetretenen Usability-Problem geäußert haben. Um dies alles zu Garantieren muss der für die Evaluation gewählte Beobachten eine Experte auf diesem Gebiet sein und sich natürlich auch mit dem Interface sehr gut auskennen.<br /> <br /> =Ergebnis=<br /> Das Ergebnis einer Heuristischen Evaluation ist eine Liste der gefundenen Usability-Probleme. Da diese Liste die einzelnen Meinungen der Evaluatoren wieder spiegelt, müssen diese, in Verbindung mit den Heuristiken oder anderen Usability-Ergebnissen, erklären warum sie etwas nicht mochten oder was ihnen nicht gefiel. Allerdings zeigt diese Methode keinen gezielten Ansatz zur Lösung der gefundenen Probleme auf <br /> <br /> =Erweiterung=<br /> Als Erweiterung der einfachen Liste von Usability-Problemen eines Interfaces, die man als Ergebnis aus der Heuristischen Evaluation erhält gibt es die Möglichkeit die schwere der einzelnen Probleme zu gewichten, das so genannte Severty Ranking. <br /> <br /> =Quellen=<br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc. <br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516 <br /> <br /> =Links=<br /> *[http://www.useit.com/papers/heuristic/heuristic_evaluation.html Nielsen, J.: Heuristic Evaluation]<br /> *[http://www.fit-fuer-usability.de/1x1/messen/heuristik.html Über den Daumen: Heuristische Evaluation]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Heuristische_Evaluation&diff=11907 2008-07-03T18:14:21Z

<p>Borchert: </p> <hr /> <div>=Definition=<br /> Bei der '''heuristischen Evaluation''' handelt es sich um eine systematische Usability-Inspektionsmethode um Usability-Probleme in einem User-Interface Design zu finden. <br /> Zur heuristischen Evaluation gehört immer eine kleine Gruppe von (Usability-)Experten die die Gebrauchsfähigkeit bzw. Konformität des Interfaces begutachtet und anhand von allgemeinen und einfachen Kriterien - den Heuristiken - beurteilt.<br /> <br /> =Evaluatoren=<br /> Da ein Evaluator nur rund 35% der Usability-Probleme eine Interfaces findet ist es sinnvoll mit mehreren Evaluatoren zu arbeiten. Nielsen und Molich schlagen in ihren Arbeiten für eine Evaluation drei bis fünf Evaluatoren vor, da kaum noch zusätzliche Informationen durch eine größere Zahl von Evaluatoren gewonnen wird.<br /> Bei der Auswahl der Evaluatoren sollte berücksichtig werden, dass sich die Auswahl verschiedener Evaluatoren positiv auf das Finden von Problemen auswirkt,was auch Studienergebnisse von Nielsen und Molich belegen. So sollten unter den Evaluatoren zwar hauptsächlich Experten sein die sich mit Usability beschäftigen, aber wenn es möglich ist auch ein End-User bzw. ein Experte der sich mit dem Anwendungsgebiet für das das System gedacht ist auskennt um eventuelle, spezielle Usability-Probleme zu finden.<br /> <br /> Die exakte Zahl der Evaluatoren die tatsächlich für eine heuristische Evaluation herangezogen werden hängt allerdings auch sehr stark von der Kosten-Nutzen-Analyse ab, die für jedes System anderes ausfällt und somit neu berechnet wird. Sie errechnet sich aus Fixkosten und variablen Kosten. Die Fixkosten ergeben sich aus dem Preis der benötigten Materialien, der Planungszeit und dem Schreiben des Reportes. Sie betragen meist zwischen $3,700 und $4,800. Dazu kommen die variablen Kosten, wie der Lohn pro Evaluator, die Analyse der einzelnen Reporte, die Kosten der Hilfsmittel u.a. Diese Kosten bewegen sich zwischen $410 und $900 pro Evaluator<br /> <br /> =Heuristiken=<br /> Die Heuristiken dienen bzw. helfen den Evaluatoren bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist.Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden.<br /> <br /> Als Beispiel für allgemeine Heuristiken diente die folgende 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt , aber 1994 nochmals von Nielsen, nach mehreren Studien, verfeinert wurde. <br /> <br /> Die Heuristiken oder Leitfäden dienen bzw. helfen den Evaluatoren, wie in der Einleitung erwähnt, bei der Begutachtung und Beurteilung des Interfaces. Sie sollen ihnen helfen Usability-Probleme zu finden, sie aber nicht einschränken. Darum kann jeder Evaluator neben allgemeinen Heuristiken die für alle Dialogelemente gelten jedes zusätzliche Usability-Prinzip oder Resultat das er kennt in Betracht ziehen, wenn es für ein bestimmtes Dialogelement sachdienlich ist. Darüber hinaus ist es möglich bestimmte kategoriespezifische Heuristiken zu erstellen die zusätzlich zu den Allgemeinen bei bestimmten Klassen von Produkten angewendet werden [1].<br /> Als Beispiel für allgemeine Heuristiken eine 10 Punkte Liste die ursprünglich 1990 von Nielsen und Molich zusammen als Grundprinzipien zur Gestaltung von User-Intefaces entwickelt, aber 1994 nochmals von Nielsen nach mehreren Studien verfeinert wurde.<br /> <br /> *''Sichtbarkeit des Systemstatus'' - Das System sollte dem User mit angebrachten Infos fortwährende mitteilen was geschieht <br /> <br /> *''Anpassung zwischen System und reeller Welt'' - Das System sollte in Wort und Phrase die Sprache der Anwender sprechen und nicht zu systemorientiert sein<br /> <br /> *''Benutzerkontrolle und –freiheit'' - Da User öfter mal Fehler machen sollte das System hierfür „Emergency Exits“ haben, sowie Undo- und Redo-Funktionen<br /> <br /> *''Konsistenz und Standards'' - Das System sollte Konsistent sein und bestimmten Standards folgen, damit sich der User immer zurechtfindet<br /> <br /> *''Fehler vermeiden'' - Besser als jede gute Fehlermeldung ist die Vermeidung von Fehlern<br /> <br /> *''Wiedererkennen statt sich erinnern'' - Die Bedienung sollte soweit es geht selbsterklärend sein ohne das sich der User groß erinnern muss. Auch sollte er sich nicht Informationen von einem Dialog für einen anderen merken müssen.<br /> <br /> *''Flexibilität und Effizienz'' - Für erfahrene User sollte es Abkürzungen geben die das Arbeiten mit dem System beschleunigen. Die „Shortcuts“ sollten allerdings Anfänger nicht verwirren. User sollten sich auch von ihnen häufig verwendete Funktionen speziell zurechtlegen können.<br /> <br /> *''Ästhetik und minimalistisches Design'' - Dialoge sollten notwendige Informationen enthalten. Jede zusätzliche Information lenkt nur von den Fakten ab und hält den Benutzer auf.<br /> <br /> *''Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern'' - Fehlermeldungen sollten in verständlicher Sprache sein, das Problem genau beschreiben und Lösung vorschlagen<br /> <br /> *''Hilfe und Dokumentation'' - Selbst wenn der User für die Nutzung des System keinerlei Unterstützung bedarf, sollte es doch, gerade bei komplexen Interfaces, gute Dokumentation geben die in die Struktur integriert sind. Eine Hilfe an entsprechender Stelle sollte sowohl kontextabhängig als auch verständlich verfasst sein und konstruktive Lösungsansätze bieten.<br /> <br /> =Durchführung=<br /> Bei der Evaluation selbst geht jeder Experte das Interface mehrmals durch und begutachtet die verschiedenen Dialogelemente und vergleicht diese dabei mit allgemeinen und/oder speziellen Heuristiken bzw. Usability-Prinzipien. Die Evaluatoren entscheiden selbst wie sie das Interface durchgehen, meistens zweimal. Beim ersten Durchlauf um ein Gefühl für das Interface und den allgemeinen Anwendungsbereich des Systems zu bekommen. Beim Zweiten achten sie dann auf spezielle Interface-Elemente und wie diese ins Gesamtbild passen.<br /> <br /> Erst nachdem alle Evaluationen abgeschlossen sind dürfen sich die Experten untereinander austauschen und ihre Ergebnisse zusammenführen. Dieses Verfahren ist Notwendig um sicherzustellen, dass die Evaluationen der einzelnen Personen unabhängig und vorurteilsfrei sind. Eine Evaluation eines Experten sollte durchschnittliche 1 bis 2 Stunden dauern. Sollte es durch die Komplexität des Produkts notwendig sein eine längere Evaluation abzuhalten, so ist es sinnvoll diese in mehrere kleinere aufzuspalten, welche sich dann jeweils nur mit einem bestimmten Aspekt beschäftigen. <br /> <br /> Die Erfassung der Evaluationen kann auf verschiedene Weiser geschehen. Zum einen als geschriebener Bericht des Evaluatoren selbst, was den Aufwand für den Evaluator selbst erhöht da er sich nicht ausschließlich auf das Interface konzentrieren kann, dafür erhält man aber einen formalen Bericht.<br /> Zum anderen eine Erfassung durch einen Beobachter, dem der Evaluator während er das Interface begutachtet seine Ergebnisse sagt und dieser sie schriftlich festhält. Hierbei sollten die Evaluatoren dem Beobachter allerdings alle von ihnen gefundenen Verstöße gegen die Heuristiken einzeln mitteilen, was in der Praxis nicht immer so problemlos klappt, da sie mehr mit dem Finden von Fehlern als der Mitteilung dieser beschäftigt sind. Der Beobachter darf darüber hinaus die Ergebnisse und Kommentare nur erfassen, sie aber nicht selber bewerten wie beim zum User-Testing. <br /> Trotzdem bringt diese Form der Erfassung viele Vorteile mit sich. Sie reduziert zum einen die Arbeitslast für den Evaluator, zum anderen braucht der Beobachter nur ein Set von Notizen zu bearbeiten, das er dazu noch selbst geschrieben hat. Ein Ergebnis der gesamten Evaluation steht dadurch auch schneller zu Verfügung. <br /> <br /> Eine Evaluation mit Beobachter hat auch noch den Vorteil, dass der Beobachter Fragen während der Evaluation beantworten kann und auch soll, aber nur solche die das Anwendungsgebiet des Interfaces betreffen. Dies hat vor allem Vorteile für Evaluatoren die keine Experten auf diesem Gebiet sind. Zum anderen kann der Beobachter auch Hinweise zum Gebrauch des Interfaces geben, falls es zu Problemen bei der Nutzung kommt. Dadurch wird auch teure und kostbare Evaluationszeit gespart. Allerdings muss noch erwähnt werden, dass der Beobachter den Evaluatoren von sich selbst aus erst Hilfe geben darf, wenn sie in richtigen Schwierigkeiten sind und sie sich zu dem aufgetretenen Usability-Problem geäußert haben. Um dies alles zu Garantieren muss der für die Evaluation gewählte Beobachten eine Experte auf diesem Gebiet sein und sich natürlich auch mit dem Interface sehr gut auskennen.<br /> <br /> =Ergebnis=<br /> Das Ergebnis einer Heuristischen Evaluation ist eine Liste der gefundenen Usability-Probleme. Da diese Liste die einzelnen Meinungen der Evaluatoren wieder spiegelt, müssen diese, in Verbindung mit den Heuristiken oder anderen Usability-Ergebnissen, erklären warum sie etwas nicht mochten oder was ihnen nicht gefiel. Allerdings zeigt diese Methode keinen gezielten Ansatz zur Lösung der gefundenen Probleme auf <br /> <br /> =Erweiterung=<br /> Als Erweiterung der einfachen Liste von Usability-Problemen eines Interfaces, die man als Ergebnis aus der Heuristischen Evaluation erhält gibt es die Möglichkeit die schwere der einzelnen Probleme zu gewichten, das so genannte Severty Ranking. <br /> <br /> =Quellen=<br /> *Nielsen, J. (1993): Usability Engineering, London, Academc Press Inc. <br /> *Nielsen, J.; Molich, R. (1994): Usability Inspection Methods, New York, John Wiley &amp; Sons Inc.<br /> *Ivory, Melody Y.; Hearst, Marti Arti A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In ACM Computing Surveys, Vol. 33 4/ 2001, S.470 - 516 <br /> <br /> =Links=<br /> *[http://www.useit.com/papers/heuristic/heuristic_evaluation.html/ Nielsen, J.: Heuristic Evaluation]<br /> *[http://www.fit-fuer-usability.de/1x1/messen/heuristik.html/ Über den Daumen: Heuristische Evaluation]</div>

Borchert https://glossar.hs-augsburg.de/w/index.php?title=Heuristische_Evaluation&diff=11906 2008-07-03T17:27:35Z

<p>Borchert: </p> <hr /> <div>Bei der heuristischen Evaluation handelt es sich um eine systematische Usability-Inspektionsmethode um Usability-Probleme in einem User-Interface Design zu finden. <br /> Zur heuristischen Evaluation gehört auch immer eine kleine Gruppe von Usability-Experten die die Gebrauchsfähigkeit bzw. Konformität des Interfaces begutachtet und anhand von allgemeinen und einfachen Kriterien, den Heuristiken zu beurteilt.</div>

Borchert