bachelor arbeit
TRANSCRIPT
Stiftung Universität HildesheimFachbereich III: Sprach- und Informationswissenschaften
Institut für Informationswissenschaften und Sprachentechnologie
Bacherlorarbeit im Studiengang Internationales Informationsmanagement zur Erlangung des akademischen Grades
„Bachelor of Arts“
Konzeption eines First-Click-Tools für mobile Websites
Vorgelegt von:
Jennifer Machura
Matrikelnummer: 204121E-Mail: [email protected]
Erstgutachterin: Prof. Dr. Womser-HackerZweitgutachter: Ben Heuwing
Hildesheim, 11.03.2013
Zusammenfassung
Das mobile Internet nimmt einen immer größeren Einfluss auf unsere Gesellschaft und unser
Internetverhalten. Viele Firmen wollen ihren Kunden aus diesem Grund einen mobilen
Internetauftritt präsentieren. Die Übertragung ihrer Desktopwebsite auf das mobile Internet kann
jedoch zu Konflikten in der Benutzerfreundlichkeit führen, sodass es einer neuen Gestaltung des
mobilen Webauftritts bedarf. Diese Arbeit soll eine Konzeption eines Prototypens des
Usabilitywerkzeugs First-Click für mobile Anwendungen erstellen, sodass der mobile
Webauftritt auf Benutzerfreundlichkeit getestet werden kann. Das First-Click-Tool wird
gegenwärtig nur für Usabilitytests von Desktopwebsites verwendet. Die Konzeption eines
Prototypens für mobile Anwendungen stößt somit auf neue Herausforderungen.
2
Abstract
Mobile Web has an enormous impact on our society and our behaviour on the internet. Hence,
many companies choose to present their clients a mobile version of their website. However,
transferring a desktopwebsite to the mobile web leads to usability conflicts, so that there is a
need for a new mobile web design. This paper is supposed to show a conception of a prototype
of an usability tool called First-Click which can be used on mobile applications so that a mobile
version of a website can be tested on its usability. This tool is currently in use to test
desktopwebsites only. The conception of a prototype is therefore facing new challenges.
3
Inhaltsverzeichnis
0. EINLEITUNG.................................................................................................................................................... 5
1. THEORIE............................................................................................................................................................ 71.1 BESONDERHEITEN DER MOBILITÄT............................................................................................................................7
1.1.1 Probleme bei der Nutzung mobiler Geräte......................................................................................................71.1.2 Nutzertypen mobiles Web........................................................................................................................................ 81.1.3 Aufgabentypen mobiles Web............................................................................................................................... 101.1.4 Responsive Webdesign........................................................................................................................................... 11
1.2 NAVIGATIONSSTRATEGIEN MOBILES WEB............................................................................................................131.2.1 Lineare Navigationselemente.............................................................................................................................. 141.2.2 Hierarchische Navigationselemente................................................................................................................. 151.2.4 Best Practices für mobiles Navigieren............................................................................................................ 17
1.3 FIRST-CLICK-TEST........................................................................................................................................................181.3.1 Durchführung First-Click-Test.......................................................................................................................... 191.3.2 Forschungsergebnisse........................................................................................................................................... 20
1.4. MOBILES PROTOTYPING.............................................................................................................................................211.4.1 Low- Fidelity Prototypen...................................................................................................................................... 211.4.2 High- Fidelity Prototypen.................................................................................................................................... 22
2. KONZEPTION UND PROTOTYPING.................................................................................................... 232.1 ZIELSETZUNG AN DEN FRONTEND-BEREICH DES FIRST-CLICK-TOOLS......................................................232.2 ZIELGRUPPE.....................................................................................................................................................................24
2.2.1 Statistische Daten über Smartphone-Nutzer.................................................................................................242.3 VERGLEICHENDE ANALYSE.......................................................................................................................................26
2.3.1 Vergleichsgegenstände.......................................................................................................................................... 262.3.2 Heuristische Evaluation........................................................................................................................................ 27
2.4 FRONTEND-PROTOTYP.................................................................................................................................................292.4.1 Brainstorming........................................................................................................................................................... 302.4.2 Benutzerführung....................................................................................................................................................... 312.4.3 Gestaltrichtlinien für mobile Websites............................................................................................................ 322.4.4 Skalierung................................................................................................................................................................... 342.4.5 Der Prototyp.............................................................................................................................................................. 35
3. EVALUATION DES PROTOTYPENS.....................................................................................................423.1 COGNITIVE WALKTHROUGH......................................................................................................................................433.2 NUTZERTESTS................................................................................................................................................................. 44
3.2.1 Vorbereitung.............................................................................................................................................................. 443.2.2 Testpersonen.............................................................................................................................................................. 443.2.3 Testaufbau.................................................................................................................................................................. 453.2.4 Besonderheiten......................................................................................................................................................... 47
3.3 ERGEBNISSE DER NUTZERTESTS...............................................................................................................................47
4. SCHLUSSFOLGERUNGEN........................................................................................................................ 55
5. LITERATURVERZEICHNIS..................................................................................................................... 57
I. ABBILDUNGSVERZEICHNIS................................................................................................................... 60
II. TABELLENVERZEICHNIS...................................................................................................................... 61
III. ANHANG....................................................................................................................................................... 62
4
0. Einleitung
Die Bedeutung des mobilen Internets nimmt einen immer größer werdenden Stellenwert in
unserer Gesellschaft ein. Während im Jahr 2011 28% der Deutschen Zugriff auf das mobile
Internet hatten, waren es 2012 bereits 58% (Vgl. Accenture, 2012). Die Fähigkeit mobil zu sein
und somit überall und zu jederzeit agieren zu können, bietet uns eine neue Möglichkeit der
Kommunikation, des Einkaufens und der Freizeitgestaltung. Auch im Bezug auf die Geschäfts-
und B2B-Welt ist das mobile Internet heutzutage unverzichtbar. Bereits im Jahr 2015 werden
mehr Internetnutzer das Internet von mobilen Endgeräten aufrufen als von ihrem Desktop-PC
oder Notebook (vgl. Morgan Stanley Research, 2009) und gegenwärtig werden etwa 10% der
Websiteaufrufe aus dem mobilen Internet getätigt (vgl. MobiThinking, 2012). Im Verlauf dieser
Entwicklungen steigen dementsprechend die Erwartungen der mobilen Nutzer an die mobilen
Websites und deren Benutzerfreundlichkeit. Aus diesem Grund erweitern viele Firmen ihren
Internetauftritt von konventionellen Desktopwebsites auf mobile Websites, wobei es nach
Wroblewski (2011) für Firmen effizienter wäre zunächst den mobilen Webauftritt zu gestalten
und diesen als Basis zur Implementierung einer Desktopwebsite zu nutzen.
Die Erwartungen und Wünsche der Nutzer an die mobilen Websites können mit Tests bezüglich
der Usability herausgearbeitet werden. Im Deutschen werden die Begriffe
„Benutzerfreundlichkeit“ oder „Gebrauchstauglichkeit“ oftmals als Synonyme für den Begriff
Usability verwendet. Usability wird von der International Standardization Organization (ISO)
wie folgt definiert:
„Usability is the capability of the software to be understood, learned, used and liked by
the user, when used under specified conditions“ (DIN EN ISO 9126-1, 2001).
Die Usability wird oftmals als ein Teilkonzept der User Experience (UX), also dem
Benutzererlebnis, verstanden (vgl. Vermeeren et al. 2010:521). Während Usability sich auf die
effektive und effiziente Aufgabenerledigung eines Users während der tatsächlichen Nutzung der
Website beschränkt, betrachtet User Experience auch den Prozess vor und nach einer Nutzung.
Antizipierte Erwartungen, sowie die emotionale Bindung zum Produkt werden hier untersucht
(vgl. ISO 9241-210, 2009). Entwickler müssen somit den Faktor der User Experience in ihre
5
Arbeit miteinbeziehen, da nur eine positive Einstellung und Zufriedenheit des Nutzers zum
Produkt darüber entscheidet, ob der Nutzer die Website noch einmal besucht.
Während verschiedenen Phasen der Entwicklung können diverse Usability-Methoden eingesetzt
werden, sodass die Usability und User Experience der Website optimiert werden können.
Usability-Methoden können dabei kombiniert oder je nach Informationsbedarf der Entwickler
individuell eingesetzt werden. In der Literatur wird bezüglich des Gutachters eines Produkts
zwischen expertenorientierten und benutzerorientierten Methoden unterschieden (Schweibenz &
Thissen, 2003). Während bei den expertenorientierten Methoden, wie heuristische Evaluationen,
Walkthrough-Verfahren oder Kriterienkataloge, Experten als Ersatz-Nutzer zur Evaluation
herangezogen werden, werden für benutzerorientierten Methoden, wie Labortests, Umfragen
oder Card Sorting, zukünftige bzw. reale Nutzer mit dem Produkt konfrontiert. (vgl. Schweibenz
& Thissen, 2003:86ff). In dieser Arbeit soll die benutzerorientierte Methode des First-Click-
Tests betrachtet und auf den mobilen Kontext übertragen werden. Mit einem First-Click-Test
können Entwickler einfach und schnell die Navigationsarchitektur einer Website in einem
beliebigen Stadium der Entwicklung kostengünstig und schnell testen, indem die Testperson eine
kurze Aufgabe durch einmaliges Anklicken einer Darstellung der Website bearbeitet. Ziel dieser
Arbeit ist es, ein solches First-Click-Tool für mobile Geräte zu konzipieren, da gegenwärtig nur
First-Click-Tools zum Testen von Desktopwebsites existieren. Dabei soll die Theorie auf
Besonderheiten der Mobilität, wie Nutzer- und Anwendungstypen, Probleme bei der Nutzung
mobiler Websites und das responsive Webdesign thematisieren. Im Verlauf dieser Arbeit werden
Anforderungen an das mobile First-Click-Tool herausgearbeitet, Zielgruppen und technische
Besonderheiten ermittelt, sodass ein interaktiver Prototyp des Durchführungsbereichs eines
solchen First-Click-Tools erstellt werden kann. Der Prototyping-Prozess dient hierbei als
Methode zur Erstellung des mobilen First-Click-Tools und soll einen ersten Entwurf für den
Durchführungsbereich des Tools darlegen. Nachdem der Prototyp erwartungskonform erstellt
werden konnte, sollen Nutzertest Aufschluss über die Benutzerfreundlichkeit des Prototypens
geben und eventuelle Schwachstellen und Stärken aufdecken.
6
1. Theorie
Dieser Teil der Arbeit soll den theoretischen Rahmen für die Konzeption eines Prototypens für
den Durchführungsbereich eines mobilen First-Click-Tools setzen. Hierbei sollen zunächst die
Besonderheiten der Mobilität, wie zum Beispiel die Probleme beim Benutzen von mobilen
Websites oder das responsive Webdesign, aufgezeigt werden. Des Weiteren wird auf die
verschiedenen Nutzertypen des mobilen Internets eingegangen. Auch Navigationsstrategien
mobiler Websites und die Usability-Methode First-Click-Test sollen in diesem Kapitel
präsentiert werden. Schließlich folgt ein Kapitel, welches den Prototyping-Prozess erläutert.
1.1 Besonderheiten der Mobilität
1.1.1 Probleme bei der Nutzung mobiler Geräte
Während der Entwicklung von mobilen Websites müssen Entwickler sich den Problemen und
Schwierigkeiten, die während der Nutzung auftreten können, bewusst sein. Ein wesentlicher
Unterscheid bei der Nutzung des mobilen Internets im Vergleich zum stationären Internet ist die
Größe und das Gewicht der hierfür verwendeten Geräte. Die mobilen Geräte werden immer
kleiner, sodass die technischen Anforderungen an diese Geräte steigen und die Ergonomie der
Benutzerschnittstelle beachtet werden muss (vgl. Müller-Wilken, 2002:4). Auch die Bedienung
wird bei immer kleiner werdenden Eingabemöglichkeiten schwieriger, sodass das Eingeben von
längeren Texten auf mobilen Geräten mühselig ist. Des Weiteren unterscheiden sich mobile
Geräte von stationären Geräten durch eine geringe Rechen-, Speicher- und
Kommunikationsgeschwindigkeit, sodass der Nutzer des mobilen Internets seine Ansprüche und
Anforderungen an die mobilen Geräte einschränken muss (vgl. Müller-Wilken 2003:3).
Hassanein und Head haben 2003 hinsichtlich der Probleme bei der Nutzung mobiler Geräte das
„Ubiquitous Usability Model“ entwickelt, welches verschiedene Einflussfaktoren, nämlich
Nutzer, Umgebung, Aufgabe und Benutzeroberflächlich, in einem zusammenhängenden Kontext
betrachtet. Der Nutzer stellt dabei den zentralen Gegenstand des Modells dar, da er oder sie die
Aufgabe mithilfe einer gegebenen Benutzeroberfläche in einer bestimmten Umgebung lösen
will. (vgl. Hassanein & Head 2003:181). Allerdings kann der Nutzer während der Nutzung
mobiler Geräte auf kognitive Limitationen, wie Aufnahmekapazität von Informationen, visuelle
7
Kapazitäten oder motorische Fähigkeiten, stoßen. Der Psychologe George A. Miller (1956) hat
beispielsweise festgestellt, dass der Mensch nicht mehr als sieben +/- zwei Informationseinheiten
gleichzeitig in seinem Kurzzeitgedächtnis speichern kann, sodass Entwicklern von mobilen
Websites dazu geraten wird, die Navigationsstruktur der Website übersichtlich und
minimalistisch zu gestalten (vgl. W3C Best Practices). Auch die visuellen Kapazitäten des
menschlichen Gehirns stoßen auf Grenzen und sind zudem individuell geprägt. Motorische
Fähigkeiten eines Menschen, wie Reaktionsgeschwindigkeit und Treffsicherheit, müssen
besonders während der Entwicklung von mobilen Geräten und Websites beachtet werden, indem
Zielobjekte, wie Menüelemente oder Buttons, groß genug gestaltet werden und Objekte, die vom
Nutzer bewegt werden können, nur in einer geringen Reichweite bewegt werden. Der zweite
Einflussfaktor der Nutzung von mobilen Geräten ist nach Hassanein & Head die Umgebung.
Dabei unterscheiden sie zwischen statischen Umgebungen, in denen der Nutzer auf etwas wartet
und sich körperlich nicht bewegt, und dynamischen Umgebungen, in welchem der Nutzer das
mobile Gerät nutzt, während er sich bewegt (vgl. Hussanein & Head 2003:183f).
Umgebungsfaktoren, wie Lärm, Temperaturen oder Zeitdruck müssen somit von Entwicklern
berücksichtigt werden. Die Aufgabe bildet den dritten Einflussfaktor des Ubiquitous Usability
Modells. Aufgaben, die Nutzer mit ihrem mobilen Endgerät lösen wollen, können in
Komplexität und Interaktionsgrad variieren (vgl. Hussanein & Head 2003:185f). Auch das
Aufgabenziel, nämlich offen ohne Ziel oder geschlossen mit einem bestimmten Ziel, kann die
Nutzung des mobilen Endgeräts beeinflussen. Der vierte Einflussfaktor der Nutzung von
mobilen Endgeräten ist die Benutzeroberfläche, welche die Navigationsarchitektur mobiler
Endgeräte und Websites beinhaltet. Hier können Probleme hinsichtlich der Größe und Qualität
von Displays oder Eingabemöglichkeiten auftreten. Das Eingeben von Texten ist auf mobilen
Endgeräten schwieriger und kann zu einer hohen Fehlerquote führen (vgl. Hussanein & Head
2003:187f).
Entwickler mobiler Endgeräte und Websites müssen sich diesen Besonderheiten der Mobilität
bewusst sein, um eine für den Nutzer angenehme Benutzung zu gewährleisten. Die Ansprüche an
die Geräte und Websites sollten folglich hochgestellt sein und Nutzer sollten frühzeitig in den
Entwicklungsprozess miteinbezogen werden, sodass potentielle Störfaktoren aufgedeckt werden
können.
1.1.2 Nutzertypen mobiles Web
8
Aufgrund der Besonderheiten der Mobilität bilden sich im Vergleich zum stationären Internet
neue Nutzertypen für das mobile Internet. Um eine Typologie der mobilen Nutzer erstellen zu
können, müssen im Vorhinein Kriterien festgelegt werden, in welche die Nutzer eingeordnet
werden können. Solche Kriterien können Dauer der Nutzung, Art der Medienplattform (z.B.
Blogs, Apps, mobile Websites), Inhaltsvorlieben (Welches ist die Hauptaktivität, die ein Nutzer
im mobilen Internet tätigt?), oder die Nutzungsvielfalt (Wie vielfältig wird das mobile Internet
genutzt?) sein. Die TU Darmstadt hat in Kooperation mit der Agentur MRM Worldwide die
Studie „A Mobile Web User Typologie“ (2011) veröffentlicht, in welcher 1.717 mobile Nutzer
aus Deutschland und Großbritannien bezüglich ihres mobilen Internetverhaltens befragt wurden.
Daraus ist eine Typologie aus vier mobilen Internetnutzern entstanden: Rookie, Rationalist,
Everyday und Restless.
Rookie: Dieser Nutzertyp macht 15 % der mobilen Internetnutzer aus und ist älter als 45
Jahre. Er weist eine geringe Nutzungsintensität auf, nutzt nicht die volle Bandbreite der
Mobilität und nimmt den Wert und die Relevanz des mobilen Internets nicht als solches
wahr. Nur 1 % dieser Nutzergruppe kauft Online ein.
Rationalist: Dieser Nutzertyp ist mit 50% der am stärksten vertretender Typus und ist
zwischen 25 und 45 Jahre alt. Der Rationalist nutzt das mobile Internet häufig, allerdings
auf einem niedrigen Level. Seine Nutzung ist eher selektiv als intensiv.
Everyday: 20 % der mobilen Internetnutzer können diesem Typus zugeordnet werden.
Diese Nutzer, die nicht älter als 33 Jahre sind, nutzen häufig das mobile Internet,
insbesondere soziale Netzwerke, und erkennen den Mehrwert des mobilen Internets.
Restless: Das mobile Internet gehört für diese Nutzergruppe, die 12% der mobilen
Internetnutzer ausmacht, zum täglichen Leben. Insbesondere Apple- und Android-
Smartphones sind für den Restless-Nutzer interessant. Seine Nutzung ist extensiv, wobei
er sehr häufig soziale Netzwerke besucht. 70% der Restless-Nutzer sind unter 34 Jahre alt
und vorwiegend männlich. 65% dieses Typus kaufen Artikel Online ein.
Die Ergebnisse dieser Studie zeigen wirkungsvoll, dass Smartphones zum ständigen Begleiter in
fast allen Lebensbereichen geworden sind und das Verhalten der Mediennutzung der Menschen
9
nachhaltig verändern. Entwicklern und Websitebetreibern müssen diese Entwicklungen und
Typologie bekannt sein, um mobile Endgeräte und mobile Websites nach den Bedürfnissen und
Wünschen der Nutzer gestalten zu können
1.1.3 Aufgabentypen mobiles Web
Ein weiterer wesentlicher Faktor, der während der Gestaltung mobiler Webauftritte
berücksichtigt werden muss, sind die Aufgabentypen, die im mobilen Kontext existieren.
Betreibern und Entwicklern von mobilen Websites muss bewusst sein, welche verschiedenen
Motivationen den Nutzer dazu bewegen, eine mobile Website zu besuchen, sodass spezifische
Nutzereigenschaften in den mobilen Websites integriert werden können.
Auf der Tagung „Google Presents User Experience & Mobile App“ im Jahr 2007 hat Googles
User Experience Designer Leland Rechis die Benutzung des mobilen Webs auf drei
Aufgabentypen eingeschränkt: Repetitive Now, Bored Now und Urgent Now (vgl.
Wellman:2007).
Repetitive Now: Der „Repetitive Now“-User ist jemand, der das mobile Web immer
wieder nach den gleichen Informationen durchsucht. Dies kann beispielsweise die
Wettervorhersage oder der Aktienkurs sein.
Bored Now: Der „Bored Now“ -User ist jemand, der in Situationen, in denen er Zeit hat
oder auf etwas wartet, auf das mobile Web zugreift, um sich die Zeit zu vertreiben. Der
Bored Now – User hat kein spezifisches Ziel in mobilen Internet, sondern kann soziale
Netzwerke oder Online-Shops durchstöbern, sich Videos angucken oder eine e-Zeitung
lesen.
Urgent Now: Der „Urgent Now“ -User verwendet das mobile Web in Situationen, in
denen er schnellstmöglich eine Information anfordern will. Dies kann zum Beispiel der
aktuelle Standort oder eine Wegbeschreibung sein.
Wroblewski erweitert die von Google präsentierten Aufgabentypen um einen Weiteren, dem
Edit/Create User (vgl. Wroblewski 2011:50).
10
Edit/Create: Dieser Nutzer verwendet das mobile Web, um etwas schnellstmöglich zu
erledigen. Dies kann beispielsweise das Verfassen einer E-Mail oder das Verschicken
einer Kurznachricht sein.
Kennen Auftraggeber und Entwickler diese verschiedenen Aufgabentypen, ist es ihnen möglich,
die spezifischen Anforderungen dieser, an den mobilen Webauftritt anzupassen. Für einen
Nutzer, der z.B. immer wieder auf die gleiche Information zugreift, ist es wichtig, dass
Entwickler bedenken, Cookies in die mobile Website zu integrieren. Während bei einem Nutzer,
der das mobile Web als Zeitvertreib durchstöbert, Entwickler darauf achten müssen, dass die
mobilen Websites übersichtlich gestaltet sind. Für die Nutzer, die sich schnell orten lassen
wollen, müssen Entwickler im Hinterkopf behalten, dass eine Lokalisierungsfunktion in die
Applikation eingebaut wird (vgl. Wellman:2007).
Neben den spezifischen Aufgabentypen muss allerdings auch der Faktor Zeit in das
Nutzungsverhalten miteinbezogen werden. Nicht jede Aufgabe kann im mobilen Kontext so
gelöst werden, wie sie an einem Desktop-PC oder Laptop gelöst werden würde, da der Nutzer
nur eine beschränkte Zeit hat, seine Aufgabe zu lösen. Aus diesem Grund suchen mobile Nutzer
selektiver nach Informationen als stationäre Internetnutzer (vgl. Hassanein & Head 2003:184).
Miller et al. (1960) hat drei Wege beschrieben, mit denen unter Zeitbeschränkung
Informationsrecherche erfolgen kann. Diese sollen auf den mobilen Kontext übertragen werden:
Beschleunigung: Informationen können vom Nutzer nur kurz wahrgenommen werden.
Dabei können aufgrund der Überlastung des Kurzzeitgedächtnisses Fehler bei der
Aufgabenerledigung auftreten.
Vermeidung: Nutzer brechen ihre Informationssuche bzw. Aufgabe ab, wenn sie keine
Zeit mehr haben. Dies führt dazu, dass Aufgaben nicht vollkommen erledigt werden
können.
Filterung: Nutzer suchen schnell nach der Lösung ihrer Aufgabe und filtern hierbei die
für sie wichtigsten Informationen heraus, sodass die Aufgabe in kurzer Zeit erledigt
werden kann.
Folglich müssen Entwickler und Betreiber mobiler Websites neben den Aufgabentypen den
Faktor Zeit, die einem Nutzer zur Aufgabenerledigung zur Verfügung steht, in Betracht ziehen,
sodass die mobile Website dem Nutzer ermöglicht, seine Aufgabe in kurzer Zeit erledigen zu
können.
11
1.1.4 Responsive Webdesign
Wie bereits in Kapitel 1.1.1 erwähnt, stellen die verschiedenen Größen und Auflösungen der
mobilen Endgeräte die Entwickler von mobilen Websites vor eine Herausforderung. Für die
Entwickler ist es demnach zeitlich und finanziell nicht möglich, eine Version der mobilen
Website für jedes einzelne Gerät zu designen. Daher kann während der Implementierung mobiler
Websites auf das responsive Webdesign zurückgegriffen werden. Der Begriff responsive
Webdesign wurde erstmals von Ethan Marcotte (2011) beschrieben und wird wie folgt definiert:
„[Responsive web design] suggests that design and development should respond to the user’s
behavior and environment based on screen size, platform and orientation.“(Knight 2012:5).
Mithilfe des responsive Webdesigns bekommen Entwickler mobiler Websites die Möglichkeit,
die Website den Bildschirmgrößen der einzelnen mobilen Geräten anzupassen, indem es auf
diese reagiert und mit ihnen korrespondiert. Somit folgt das responsive Webdesign dem Nutzer,
und nicht, wie während der Nutzung konventioneller Websites, der Nutzer dem statischen
Design.
Marcotte (2011) nennt die drei Bestandteile des responsive Webdesigns:
Ein flexibles, Layout, das auf einem Gitter basiert,
flexible Bilder und Medien und
Medien Queries1.
Das responsive Webdesign kann mithilfe von Webstandards, wie HTML5 oder CSS3, realisiert
werden und erkennt somit ,von welchem Gerät auf die mobile Website zugegriffen wird.
Neben der Größe und Bildschirmauflösung kann der Inhalt der Seite durch das responsive
Webdesign auch der Orientierung, also Hoch- oder Querformat, und den Eingabemöglichkeiten,
also Tastatur, Touch oder Sprache, angepasst werden. Im Folgenden sollen einige Vor- und
Nachteile dieser jungen Technik aufgezeigt werden:
Vorteile Nachteile
Geringer Pflegeaufwand der Website, da der
Inhalt nur einmal angelegt werden muss und
sich zukünftigen Endgeräten anpasst.
Technisch anspruchsvoll, da es sich um eine
neuartige Technik handelt, die noch nicht
vollkommen ausgereift ist.
Verbesserte Suchmaschinenoptimierung, da Implementierung des responsive Webdesigns
1 Mit Media Queries lassen sich „bestimmte Stylesheet-Angaben in Abhängigkeit einzelner Parameter des Ausgabegeräts realisieren[...]. Parameter können
beispielsweise die maximale Breite des Fensters sein oder die Fähigkeit, Farben darzustellen.“ (Maurice 2008:329)
12
nur eine URL nötig ist. stellt einen zeitlichen Aufwand dar und kann
aufgrund der Neuheit dieser Technik Probleme
aufzeigen.
Bessere User Experience, da Nutzer es als
angenehm empfinden wenn sich die mobile
Website an ihr Endgerät anpasst und sie
weniger raus- oder reinzoomen müssen.
Bisher limitierte Ressourcen der
Implementierung, da sich noch nicht sehr viele
Entwickler mobiler Websites mit der Thematik
ausführlich auskennen.
Angenehmes Teilen der Website, da der
Nutzer eines Desktop-PCs den Link einer
Website an mobile Endgeräte schicken kann
und die Website beim Öffnen mithilfe des
responsive Webdesigns an das mobile
Endgerät anpasst wird.
Längere Ladezeiten einer mobilen Website,
da Bilder oftmals nur herunterskaliert werden
anstatt verkleinert zu werden.
Neue Bildschirmauflösungen oder
Displaygrößen stellen keine
Herausforderung dar, sodass die Entwickler
keine neue Version der Website für diese
designen müssen.
Tab. 1: Vor- und Nachteile des responsive Webdesigns
Aufgrund der steigenden Zahl von Websitezugriffen aus dem mobilen Internet und wachsenden
Absatzzahlen mobiler Endgeräte, nimmt das responsive Webdesign einen wichtigen Stellenwert
zur Verbesserung der User Experience ein, da mehr denn je auf die Bedürfnisse der Nutzer
eingegangen wird. Abbildung 1 zeigt, wie die Desktopwebsite von Starbucks mithilfe von
responsive Webdesign auf mobilen Endgeräten angezeigt wird.
Abb. 1: Responsive Webdesign Starbucks
13
1.2 Navigationsstrategien mobiles Web
Der wichtigste Meilenstein für eine benutzerfreundliche Website ist gelegt, wenn sie über eine
übersichtliche und strukturierte Navigation verfügt. „Die Navigation einer Website
stellt den Zugang zu Informationen bereit,
zeigt die Position innerhalb der Website,
spiegelt die thematische Bedeutung der Website wider,
trägt zum Branding bei,
beeinflusst die Vertrauenswürdigkeit einer Website und
hat Einfluss auf das Endresultat der Website.“ (Kalbach 2008:5f)
Um die Informationssuche des Nutzers so bequem und einfach wie möglich zu gestalten, sollten
Websites Navigationsstrategien unterstützen. Hierbei ist zu beachten, dass Menüs dabei helfen
die Website strukturiert navigieren zu können, miteinander verlinkte Inhalte die
Informationssuche fördern, indem der Nutzer Assoziationen erstellen kann und Such- und
Filterfunktionen eine gezielte Suche unterstützen (vgl. Reinhard, o.J.). Zur Umsetzung der
Navigationsstrategien können Navigationselemente herangezogen werden. Ein
Navigationselement „besteht aus einem Link, oder einer Gruppe von Links, die sich ähnlich
Verhalten und ähnlich aussehen. Sie sind die Instrumente und Bauteile von
Navigationssystemen“ (Kalbach 2008:57) und steht in wechselseitiger Beziehung mit der
Struktur einer Website. Ändert sich die Struktur der Website, können sich die
Navigationselemente ebenfalls ändern und umgekehrt (vgl. ebd.). Dabei nehmen
Navigationselemente einer Website unterschiedliche Rollen ein und werden zwischen linearen
und hierarchischen Navigationselementen unterschieden. Im Folgenden sollen Beispiele für
lineare und hierarchische Navigationselemente, die besonders im mobilen Kontext relevant sind,
gegeben werden.
1.2.1 Lineare Navigationselemente
Eine lineare Navigation führt den Nutzer Schritt für Schritt von einer Seite zur nächsten.
Dabei ist der Benutzer in seiner Navigationsfreiheit stark eingeschränkt, da er nur vor und
zurück navigieren kann. In der Regel werden lineare Navigationselemente als Teil einer
ganzen Websitenavigation verwendet und mit den horizontalen Navigationselementen
kombiniert. Ziel einer solchen linearen Navigation ist es, dem Nutzer einen vorgegebenen
Navigationspfad zu präsentieren. Somit kann die lineare Navigation hauptsächlich bei Inhalten
mit feststehender Präsentationsreihenfolge eingesetzt werden (vgl. Montada 2010).
14
1.2.1.1 Schrittweise Navigation
Mithilfe der schrittweisen Navigation ist es dem Nutzer möglich, zwischen einzelnen Seiten vor
und zurück zu navigieren. In der Regel besteht dieses Navigationselement aus einem Pfeil und
einer Beschriftung. Dabei führt der Linkspfeil auf die vorherige Seite, während der Rechtspfeil
den Nutzer auf die nächste Seite navigiert (vgl. Kalbach 2008:57).
Abb. 2: Beispiel einer schrittweisen Navigation (vgl. Ebay/m)
In Abb. 1 weist der Linkspfeil mit der Beschriftung „Suchen“ den Nutzer darauf hin, dass er
durch das Drücken dieses Elements zurück zur Suche navigiert wird. Entwicklern von Websites
wird geraten die Pfeile zu beschriften, um Unklarheiten zu umgehen (vgl. ebd.)
1.2.1.2 Nummerierte Navigation
Eine nummerierte Navigation führt den Nutzer, ähnlich wie während einer schrittweisen
Navigation, durch die vorhandenen Seiten. Hierbei dienen Zahlen als Orientierungspunkte für
den Nutzer, sodass er weiß, wo genau er sich auf der Seite befindet.
Abb. 3: Beispiel einer nummerierten Navigation (vgl. Spiegel/m)
In Verbindung mit der schrittweisen Navigation ist, laut Kalbach, die nummerierte Navigation
die einfachste Form der Navigation (vgl. Kalbach 2008:58).
1.2.2 Hierarchische Navigationselemente
Hierarchische Navigationselemente dienen zur Unterstützung des logischen und strukturierten
Navigationsverhalten eines Nutzers, indem sie die Inhalte einer Website von Ober-Rubriken
zu Sach-Rubriken ordnen (vgl. Montada 2010). Des Weiteren helfen sie dem Nutzer den
Inhalt einer Website zu organisieren und zu strukturieren. Hierarchische Navigationselemente
werden vor allem auf Websites mit tiefer Struktur verwendet, wie z.B. Online-Shops, um die
Vielzahl der Produkte einordnen zu können.
1.2.2.1 Tree-Navigation
Die Tree-Navigation, oder Navigation mit Baumstruktur, erlaubt den Zugriff auf hierarchische
Strukturen und ist Nutzern oft bereits bekannt durch das Durchstöbern von Ordnen in ihrem
Betriebssystem, wie z.B. im Microsoft Windows Explorer (vgl. Kalbach 2008:65). Der Nutzer
15
gelangt mithilfe der Tree-Navigation von einer Startseite zu Unterseiten, die wiederrum zu
tieferführenden Seiten führen. Designelemente wie Plus- und Minuszeichen oder Links- und
Rechtspfeile fungieren für den Nutzer bei Baumstrukturen als Öffnen- bzw. Schließenzeichen
(vgl. ebd.).
Abb. 4: Beispiel einer Tree-Navigation (vgl. H&M/m)
Dabei ist zu beachten, dass der Nutzer der mobilen Webseite die Orientierung nicht verliert und
zu jeder Zeit die Möglichkeit hat zurück zu navigieren (vgl. Dilthey, 2000).
1.2.2.2 Akkordeon-Menü
In einem Akkordeon-Menü werden einzelne Listenpunkte (list-items) durch auf- und zuklappen
dieser dargestellt. Es ist besonders gut geeignet, Haupt- und Unterpunkte voneinander zu trennen
und bietet sich daher auf Websites mit großem Inhalt an.
Abb.5: Beispiel eines Akkordeon-Menüs (vgl. ESPN/m)
Mithilfe eines Akkordeon-Menüs kann der Nutzer schnell zwischen einzelnen Inhalten
navigieren und bewahrt dabei eine Übersicht, sodass er weiß, wo er sich auf der mobilen Website
befindet. Element angezeigt werden.
16
1.2.4 Best Practices für mobiles Navigieren
Wird im mobilen Kontext designt, muss den Entwicklern bewusst sein, dass sie auf neue
Herausforderungen stoßen (s. Kapitel 1.1.1). Eine dieser Herausforderungen ist es, wesentliche
Inhalte der konventionellen Website so zu reduzieren, dass es Nutzern der mobilen Version
möglich ist, ihre Suche erfolgreich und einfach zu tätigen. Dabei spielt die Navigationsstruktur
eine wichtige Rolle, denn sie entscheidet über Erfolg oder Misserfolg der Aufgabenerledigung.
Best Practices2 für das mobile Navigieren sollen Entwicklern und Betreibern mobiler Websites
hilfreiche Ratschläge geben, sodass das Navigationserlebnis für den Nutzer angenehm gestalten
werden kann. Das World Wide Web Consortium (W3C) hat in ihren Richtlinien zur Gestaltung
mobiler Websites (2008) folgende sieben Best Practices hinsichtlich der Navigation genannt:
1. [NAVBAR] Stelle nur wenige Navigationselemente oben auf der Seite bereit.
Nur die nötigsten Navigationselemente sollen oben auf der Seite sichtbar sein. Dabei ist es
wichtig, dass der Nutzer den Navigationsinhalt sofort nach dem Laden der Seite sehen kann und
hierfür nicht scrollen muss.
2. [NAVIGATION] Stelle einheitliche Navigationsmechanismen bereit.
Das Verwenden von immer gleichen Navigationsmechanismen hilft dem Nutzer sich schnell auf
der Seite zu orientieren und die Mechanismen schneller identifizieren zu können.
3. [LINK TARGET ID] Bestimme das Ziel eines Links eindeutig.
Nutzer mobiler Endgeräte können Zeit verlieren, indem sie zu vielen Links folgen, um an ihr
Ziel zu gelangen. Aus diesem Grund ist es wichtig, Navigationselemente so zu beschriften, dass
der Nutzer weiß, wohin er weitergeleitet wird.
4. [LINK TARGET FORMAT] Wenn du nicht weiß, ob ein Endgerät ein bestimmtes
Format unterstützt, dann gib Informationen zum Format des Ziels.
Links mit Inhalt in einer anderen Sprache oder anderem Format als HTML, JPG oder GIF,
sollten so beschriftet werden, dass der Nutzer sich dem bewusst ist und vorher entscheiden kann,
ob er das Navigationselement anklickt oder nicht.
5. [ACCESS KEYS] Ordne den Links in Navigationsmenüs und oft genutzten
Funktionalitäten Access Keys zu.
Access Keys (Tastaturkürzel) können dem Nutzer die Navigation zwischen viel geklickten Links
vereinfachen, indem der Nutzer beispielsweise nur eine Nummer auf seiner Tastatur klickt, um
auf einen bestimmten Bereich der Seite zu gelangen.
6. [URI] Halte die URIs von Eingangsseiten kurz.
2 (besonders in Wirtschaft und Politik) bestmögliche [bereits erprobte] Methode, Maßnahme o. Ä. zur Durchführung, Umsetzung von etwas (vgl. Duden) 17
Das Eingeben von URIs auf mobilen Endgeräten kann mühselig sein und Nutzer folgen aus
diesem Grund lieber Hyperlinks. Allerdings ist dies nicht immer möglich und die Eingabe von
URIs sollte deswegen kurz gehalten werden. Anstatt der Nutzer
http://www.example.org/index.html eingibt um auf die Seite zu gelangen, sollte er durch eine
kurze URI wie http://example.org auf die Seite navigiert werden.
7. [BALANCE] Behalte eine Balance zwischen zu vielen Links und den Links, die für
den Nutzer relevant sind.
Je mehr Zeit der Nutzer für seine Suche investiert, desto frustrierter ist er. Folglich sollten viel
gesuchte Informationen der Seite durch eine minimale Anzahl von Links erreicht werden
können.
Allerdings sollten die Best Practices der W3C mit Bedacht betrachtet werden, da es sich in
einigen Fällen nur um reine Theorie handelt, welche in der Praxis teilweise schwer umsetzbar
oder zum jeweiligen Zweck nicht möglich ist (vgl. Bieh 2008:228).
1.3 First-Click-Test
First-Click-Tests sind Remote-Tests, die Nutzungsprobleme bezüglich der
Informationsarchitektur3 und des Navigationsdesigns aufdecken können. Bei einem First-Click-
Test soll die Testperson eine kurze Aufgabe bearbeiten, indem sie durch einmaliges Anklicken
eines dargestellten Bereichs der Website anzeigt, wo sie die benötigte Information zur Lösung
der Aufgabe vermutet.
Im Vergleich zu anderen Evaluations-Methoden, wie z.B. Nutzertests oder Remote-Nutzertests,
bringen First-Click-Tests zwei Vorteile mit sich. Zum einen können wesentlich mehr Aufgaben
durchgeführt werden, da die Bearbeitungszeit einer Aufgabe sehr kurz ist und zum anderen
können Entwickler systematisch mit dem Testen der Homepage beginnen und erst nach
Verbesserung dieser können tiefere Ebenen der Website konzipiert und getestet werden (vgl.
Bailey, 2010). Studien haben gezeigt, dass die Erfolgsrate den richtigen Navigationsweg zum
Zielobjekt zu finden bei 87% liegt wenn der Nutzer beim ersten Anklicken den richtigen Weg
eingeschlagen hat. Hat der Nutzer beim ersten Klick den falschen Weg eingeschlagen, liegt die
Erfolgsrate nur noch bei 46% (vgl. ebd.). Die Navigationsarchitektur einer Website ist also
ausschlaggebend für das Verbleiben des Nutzers auf der Seite und dessen Erfolg sein Ziel zur
erreichen.
3 „[...]Systematisierung der Inhalte und Funktionen (Informationsstruktur) und ihre Abbildung in der Benutzeroberfläche (Navigationsdesign)[...]“ (Eck et. al,
2013)
18
First-Click-Tests können anhand von existierenden Websites, Prototypen oder Wireframes4
getestet werden. Die Klicks der Nutzer können vom Testleiter durch Tools, wie Chalkmark oder
Usabilla, nachvollzogen werden. Im Anschluss des Tests kann eine Heatmap erzeugt werden, die
anzeigt, wo auf der Website die Nutzer ihren ersten Klick gesetzt haben.
First-Click-Tests können somit Probleme der Navigation, des Designs und inhaltlicher
Strukturen aufdecken, sodass diese von den Entwicklern bereits in einem frühen Stadium der
Entwicklungsphase behoben werden können. Gegenwärtig existieren nur First-Click-Tools, die
konventionelle Desktopwebsites testen, weswegen die Konzeption eines mobilen First-Click-
Tests auf neue Herausforderungen stößt.
1.3.1 Durchführung First-Click-Test
Der Usability-Experte Jeff Sauro (2011) nennt sieben Schritte einen First-Click-Test erfolgreich
durchzuführen. Dabei können Websites, Prototypen, Wireframes oder Screenshots getestet
werden.
1. Kreiere ein paar Szenarien: Diese Szenarien müssen nicht sehr detailliert sein. Es ist im
Hinblick auf die Messung des Erfolgs sinnvoller, offene Szenarien zu erstellen anstelle von
Anweisung über die genaue Angabe des Objekts, auf das geklickt werden soll.
2. Definiere den optimalen und korrekte Navigationswege, die zum Erfolg führen: Der
optimale Navigationsweg beginnt auf der Homepage und führt über tiefere Ebene hin zur Lösung
der Aufgabe. Vor dem Test muss festgelegt werden, welcher der optimale oder korrekte Weg ist.
3. Verfolge, wo die Nutzer klicken: Hierbei können Tools wie Chalkmark nutzen, die mithilfe
von JavaScript die Mausklicks nachverfolgen. Die dabei erzeugte Heatmap kann zur besseren
Veranschaulichung in Präsentationen verwendet werden.
4. Zeit, die die Nutzer für den ersten Klick benötigen: Zeit ist eines der sensibelsten Größen
während des First-Click-Tests. Je höher die Zeitspanne zwischen dem Lesen der Aufgabe und
dem erstem Kick des Testers ist, desto wahrscheinlicher sind Navigationsprobleme.
5. Wie zufrieden waren die Testpersonen? Es ist ratsam dem Tester eine Zufriedenheitsskala
nach jeder Aufgabe zu präsentieren. Auf dieser kann er angeben, wie zufrieden er mit seiner
Lösung ist. Dabei kann man beispielsweise von 1 (gar nicht zufrieden) bis 7 (sehr zufrieden)
4 Schematische Darstellung einer Website, in welcher nur das grundlegende Layout dargestellt wird.
19
skalieren.
6. Wie schwierig war die Aufgabe? Es mag sein, dass die Testperson die Aufgabe richtig gelöst
hat, sie aber für schwierig empfunden hat. Um die Schwierigkeit der Aufgabe zu messen, bietet
sich ebenfalls eine Skala nach jeder Aufgabe an. Sieht der Testleiter, dass die Testperson die
Aufgabe als schwierig empfand, kann er durch Nachfragen auf Probleme des Designs oder der
Navigation stoßen.
7. Im Vergleich: Ein eindeutiges Ergebnis der Effektivität einer Seite kann erzielt werden, wenn
zunächst eine Gruppe von Testpersonen auf die alte oder erste Version der Website getestet wird
und danach eine Gruppe die neuere, verbesserte Version testet. Hier kann man einen Vergleich
der Zwischenergebnisse ziehen und es wird deutlich, ob noch mehr Bearbeitungsbedarf
vorhanden ist.
1.3.2 Forschungsergebnisse
Gegenwärtig lassen sich wenige Forschungsergebnisse bezüglich von First-Click-Tests in der
Literatur auffinden. Dieses Kapitel soll insbesondere auf eine Studie von Neo Insight (2011)
eingehen, die mithilfe eines First-Click-Tests an einer kanadischen Universitätsbibliothek, 3
wesentliche Usability-Probleme aufdecken und somit Schlussfolgerungen auf das Nutzen von
First-Click-Tests ziehen konnte. Für die Durchführung des First-Click-Tests wurde das Optimal
Workshop Chalkmark Tool herangezogen. Die Nutzer der Universitätsbibliothek bekamen nach
Aufrufen der Startseite eine Einladung zum Test und konnten entscheiden, ob sie teilnehmen
oder nicht. Dabei haben sich mehr als 200 Nutzer, darunter Studenten, Universitäts- und
Bibliotheksmitarbeiter, dazu entschieden am Test teilzunehmen. Zuvor hat das Testteam
definiert, dass der Erfolg einer Aufgabe erwiesen ist, wenn mindestens 80% der Testpersonen
den korrekten Link angeklickt haben. Insgesamt sollten 10 Aufgaben von den Testpersonen
bearbeitet werden. Dabei konnten diese drei Usability-Probleme ermittelt werden:
Usability-Problem 1: Die Performance eines wichtigen Links wird negativ durch ähnliche
Benennung anderer Links beeinflusst.
Sind Links ähnlich oder zu allgemein beschriftet, finden Nutzer schwieriger zu ihrem Ziel und
wählen den Link, der sie als erstes anspricht, anstelle eine optimale Lösung zu suchen.
Usability-Problem 2: Nutzer können wichtige Links, die sich auf sekundärer Ebene der
Website befinden, nicht finden.
20
Sind Links auf der Startseite der Website schlecht beschriftet, finden Nutzer weitere wichtige
Links in den tieferen Ebenen der Website nicht und haben somit einen zeitlich höheren
Suchaufwand.
Usability-Problem 3: Einige Nutzergruppen haben schlechtere Erfolgsraten als andere
Nutzergruppen.
Für Nutzer, die sich weniger mit der Website und ihrer Terminologie beschäftigen als Nutzer die
mit der Website familiär sind, ist es schwieriger eine Erfolgsrate in der Aufgabenbearbeitung
aufzuzeigen. Sie brechen die Aufgabe eher ab oder entscheiden sich für einen längeren
Navigationsweg.
Diese Studie hat gezeigt, dass sich First-Click-Tests vor allem zum Aufdecken und Beheben
primärer Navigationselemente eignet und eine kostengünstige und schnelle Variante des
Usability-Testings sind.
Diese Ergebnisse werden von der aktuellen Studie Eigenen sich Tree-Tests und Firstclick-Tests
für die nutzerzentrierte Evaluierung der Informationsarchitektur? (Eck et al., 2013) unterstützt.
Der Nachteil von First-Click-Tests, laut der Studie, ist jedoch, dass dynamische Elemente der
Website auf den Screenshots nicht genutzt und analysiert werden können.
1.4. Mobiles Prototyping
Mithilfe eines Protoypens ist es während eines Projekts frühzeitig möglich, die geplante Struktur
oder das geplante Layout einer Website darzustellen. Dabei kann der Detailierungsgrad des
Prototypens je nach Zweck variieren. Unterschieden wird zwischen Prototypen mit einfachem
Detailierungsgrad, den low-fidelity Prototypen, und Prototypen mit hohem Detailierungsgrad,
den high-fidelity Prototypen (vgl. Saffer 2008:117ff). Bevor jedoch der Prototyp erstellt wird,
sollte das Ziel der Website, die Zielgruppe und die Navigationsstruktur festgelegt werden. Ein
Prototyp sollte nicht 1:1 als Endergebnis der Entwicklung übernommen werden, sondern
lediglich Schwachstellen während der Entwicklung aufdecken (vgl. Saffer 2008:124).
1.4.1 Low- Fidelity Prototypen
Low-Fidelity Prototypen sind die einfachste und simpelste Form des Prototypings und können
mithilfe von Papier-Protoypen, Storyboards oder Wireframes erstellt werden. Während des
Papier-Prototypings wird das geplante Interface einer mobilen Website auf Papierkarten, die der
Größe des zu testenden mobilen Endgeräts gleichen, skizziert. Die Größe des mobilen Papier-
Prototypens ist von hoher Bedeutung, da Entwickler einen ersten Eindruck der verfügbaren
21
Fläche für das geplante Design erhalten und Testpersonen im Fall eines Nutzertests realitätsnah
agieren können (vgl. Fling 2009:103f). Low-Fidelity Prototypen können zu Beginn der
Entwicklungsphase erstellt werden, sodass ein Basiskonzept der mobilen Website erstellt werden
kann. Dabei dienen sie als kostengünstiges Werkzeug, welches schnell erstellt werden kann, um
dem Kunden einen ersten Eindruck des geplanten Designs vorzustellen. Papier-Prototypen
können in einem frühem Stadium der Entwicklung in Nutzertests eingesetzt werden. Dabei soll
eine Testperson simulieren, wie sie auf der mobilen Website navigieren und interagieren würden,
indem sie beispielsweise vorgibt ein Icon auf dem Papier-Prototypen zu drücken. Der Testleiter
kann dann sofort reagieren, indem er der Testperson eine weitere Papierkarte des Prototypens
vorlegt. Während des Testens mit einem Papier-Prototypen wird ein hoher Abstraktionsgrad der
Testpersonen erfordert, jedoch können bereits in diesem Stadium der Entwicklung fehlende
Funktionalitäten und Bedürfnisse des Nutzers erkannt werden.
1.4.2 High- Fidelity Prototypen
Ein high-Fidelity Prototyp wird in späteren Phasen der Entwicklung eingesetzt und baut auf dem
low-Fidelity Prototypen auf. Im Gegensatz zu low-Fidelity Prototypen ist ein high-Fidelity
Prototyp komplexer aufgebaut und ermöglicht insbesondere im mobilen Kontext ein
realitätsnahes Testen der Website (vgl. Fling 2009:103). Die Entwicklung dieser Art von
Prototypen erfordert zwar einen hohen Zeitaufwand , ist jedoch im Hinblick auf die Probleme
der Mobilität ein effektives Werkezeug zum Testen der Schwachstellen, da unter realistischen
Bedingungen getestet werden kann (vgl. Fling 2009:105). Während low-Fidelity Prototypen ein
Konzept nur darstellen, verfeinert und erweitert ein high-Fidelity Prototyp dieses Konzept (vgl.
Saffer 2008:123). Sie können mithilfe von HTML, CSS oder PDFs erstellt werden, sodass das
Navigieren durch die Testperson zwischen den einzelnen Ebenen und das Anklicken des
Prototypens ermöglicht wird. Das Layout des high-Fidelity Prototypens ist dabei zweitrangig.
Somit stehen das Konzept und die Ideen im Vordergrund des Prototypings. Durch das Testen der
mobilen Website mit einem high-Fidelity Prototypen können fehlende Funktionalitäten
aufgedeckt und aussagekräftige Icons bewertet werden (vgl. Stone et al. 2005:120).
2. Konzeption und Prototyping
Die Konzeption und das Prototyping des First-Click-Tools sollen sich lediglich auf den
Durchführungsbereich, also dem eigentlichen Testbereich, konzentrieren und erfolgt in mehreren
22
Schritten. Zunächst soll ein Anforderungskatalog für einen Prototypen des Frontends erstellt
werden, sodass obligatorische und optionale Anforderungen gegeben sind. Hierbei soll das
Ermitteln der Zielgruppe und eine vergleichende Analyse von Anbietern des First-Click-Tools
Hilfe leisten. Danach sollen Gestaltrichtlinien für mobile Websites als Basis für den Frontend-
Prototypen betrachtet werden, sodass letztendlich ein Prototyp erstellt werden kann.
2.1 Zielsetzung an den Frontend-Bereich des First-Click-Tools
Die Wünsche und Erwartungen der Nutzer sollen immer m Vordergrund der Entwicklung eines
Prototypens für ein mobiles First-Click-Tool stehen, sodass eine positive User Experience erzielt
werden kann. Allerdings müssen auch Anforderungen des Betreibers während der Entwicklung
in Betracht gezogen werden. Aus diesen beiden Komponenten setzt sich ein
Anforderungskatalog zusammen, welcher im Laufe dieser Arbeit erweitert werden soll.
Es werden folgende obligatorische Anforderungen für das Frontend des First-Click-Tools
definiert:
Anforderung 1: Als allgemeine Anforderungen gilt die Demonstration eines Frontend-
Bereichs eines First-Click-Tools auf mobilen Endgeräten.
Anforderung 2: Dabei soll der Aufwand der Entwicklung für den Frontend-Prototypen
überschaubar sein, da ein zeitlicher Rahmen gegeben ist.
Anforderung 3: Der Prototyp für das Frontend soll interaktiv sein und ein Minimum an
Funktionen aufweisen.
Anforderung 4: Des Weiteren sollen Bedienaufwand und die Menütiefe minimal gehalten
werden.
Anforderung 5: Der Frontend-Prototyp soll an den mobilen Kontext angepasst werden,
sodass es von Nutzer und Betreiber von verschiedenen mobilen
Endgeräten aufgerufen und bedient werden kann.
Anforderung 6: Der Frontend-Prototyp soll über ein einheitliches und intuitives Design
verfügen, das den Nutzer durch den Test führt.
2.2 Zielgruppe
Die Endnutzer und deren Wünsche und Erwartungen an eine mobile Website oder Applikation
stehen stets im Vordergrund. Aus diesem Grund ist es für den Betreiber und die Entwickler
23
wichtig zu wissen, wer genau die Personen sind, die auf die Website oder Applikation zugreifen.
Daher muss vor der eigentlichen Entwicklung die Zielgruppe ermittelt werden. Hierbei sollen die
verschiedenen Nutzertypen aus Kapitel 1.1.3, statistische Daten über Smartphone-Nutzer und
Personas5 Aufschluss über die mögliche Zielgruppe des Frontend-Prototypen geben.
2.2.1 Statistische Daten über Smartphone-Nutzer
Es muss berücksichtigt werden, dass die Zielgruppe im Falle eines Prototypens für das Frontend
je nach Anwendung und Themengebiet der zur testeten Website oder Applikation variiert, da
Smartphone-Nutzer verschiedene Nutzungseigenschaften und Vorlieben aufzeigen. So
gebrauchen 74% aller Nutzer ihr Smartphone um E-Mails zu lesen und zu versenden, 70%
verwenden es für die allgemeine Informationssuche, 63% der Smartphone-Nutzer besuchen
täglich soziale Websites und 26% der Nutzer kaufen über ihr Smartphone Produkte oder
Dienstleistungen ein (vgl. Google, 2012).
Es lassen sich vier Dimensionen von Bedürfnissen und Wünschen des Nutzers an das mobile
Internet darstellen (vgl. GO SMART, 2012). Die erste Dimension ist die Nutzung. Nutzer
wünschen sich eine einfache, intuitive Nutzung, die ohne Unterbrechungen oder Störung abläuft.
Die zweite Dimension ist die Effizienz. Hierbei spielen die Dynamisierung des Alltags, die
Flexibilität durch allzeitige Verfügbarkeit und die Ortsunabhängigkeit eine wesentliche Rolle.
Die dritte Dimension ist die Kommunikation. Von dieser Dimension erwarten Smartphone-
Nutzer, dass Social Media die SMS- und Telefonkommunikation ergänzt, dass die direkte
Interaktionsfähigkeit den Inhalt und die Form der Kommunikation verkürzt, sowie eine
permanente Verfügbarkeit. Die letzte Dimension bildet die Konvergenz. Nutzer haben
Erwartungen bezüglich der Personalisierung des Geräts, die mithilfe von Applikationen, der
Synergie von Kommunikation, Entertainment und Information, sowie der Multifunktionalität
ihrer Geräte erzeugt werden kann. Weitere Faktoren zur Ermittlung der Zielgruppe sind
Nutzungsdauer und Nutzungsort. Die Tatsache, dass 75% der Smartphone-Nutzer nicht ohne ihr
mobiles Gerät das Haus verlassen und 42% es immer, sogar nachts, in Reichweite haben (vgl.
ebd.) zeigt, dass eine allzeitige Erreichbarkeit und Verfügbarkeit von den Nutzern verlangt wird.
Die User Experience wird aufgrund der vielen unterschiedlichen Nutzungsumgebungen stark
beeinflusst, sodass vermutet werden kann, dass die Nutzer den Test zwischenzeitlich abbrechen
könnten.
5 Unter Personas versteht man „eine steckbriefartige Beschreibung von Nutzern hinsichtlich der für das Produkt relevanten Eigenschaften. Es werden nur dir
repräsentativen Nutzer beschrieben, nicht alle möglichen.“ (Balzert, 2009:26)
24
Hieraus lassen sich weitere Anforderungen an den Frontend- Prototypen stellen:
Anforderung 7: Der Frontend-Prototyp soll jederzeit und überall ausführbar sein.
Anforderung 8: Texte und Elemente sollen unter verschiedenen Lichtverhältnissen
erkennbar sein.
Anforderung 9: Die Dauer eines Testdurchlaufs soll auf maximal 6 Minuten beschränkt
werden.
Anforderung 10: Die Umfrage sollte sich für die Testperson lohnen. Eine „Belohnung“ wird
im Gegenzug verlangt.
2.2.2 Personas
Personas sind fiktive Darstellungen der potentiellen Nutzer eines Produkts. In einem Steckbrief
werden kurz relevante Daten erfasst. Personas werden in die Konzeption und Entwicklung eines
Prototypens miteinbezogen, sodass in einem frühen Stadium auf die Bedürfnisse und Wünsche
der Nutzer eingegangen werden kann (vgl. Schmidt 2012:52). Während der Konzeption des
Frontend- Prototypens für das First-Click-Tool, wurden drei Personas (s. A2) erstellt, die die
potentiellen Nutzer eines solchen Tools repräsentieren sollen.
Die Unerfahrene: Persona 1 repräsentiert die Nutzer, die das mobile Web auf ihrem
Smartphone selten benutzen und häufig auf Probleme während des
Browsens stoßen.
Die Erfahrene: Persona 2 soll eine erfahrene Smartphone-Nutzerin sein, die ihr
Smartphone häufig im Laufe des Tages zum Koordinieren ihres
Terminplans, zur Kommunikation und Informationssuche verwendet.
Der Profi: Persona 3 ist ein Profi im Umgang mit dem Smartphone, da er an der
Entwicklung von mobilen Websites und Applikationen beteiligt ist.
2.3 Vergleichende Analyse
Aufgrund der Existenz von verschiedenen Anbietern für First-Click-Tests, bietet es sich an, diese
gegenüberzustellen und hinsichtlich ihrer Stärken und Schwächen zu vergleichen. In der
Geschäftswelt ist das Ziel einer solchen vergleichenden Analyse, die auch Benchmarking
25
genannt wird6, ein im Vergleich zu den konkurrierenden Unternehmen besseres Endprodukt zu
erzeugen (vgl. Knapp, 2004). Hierbei ist es wichtig, die gut umgesetzten Lösungsansätze (Best
Practices) und die Schwachstellen der Konkurrenz zu identifizieren, um daraus Folgerungen für
die Entwicklung des eigenen Produkts ableiten zu können.
An dieser Stelle der Arbeit soll eine vergleichende Analyse von First-Click-Anbietern als
Inspiration zur Ideenfindung eines Frontend-Prototypen für ein mobiles First-Click-Tool dienen,
sodass die Ergebnisse dieser Analyse in die spätere Konzeption des Frontend- Prototypens
einfließen können
2.3.1 Vergleichsgegenstände
Verglichen werden sollen drei Anbieter von First-Click-Tools: Chalkmark7, ClickTest8 und
Usabilla9.
Der erste zu untersuchende Vergleichsgegenstand ist Chalkmark. Dieses Tool ist in drei
Funktionsbereiche unterteilt: dem Setup-Bereich, dem Durchführungsbereich mit dem
eigentlichen First-Click-Test und dem Analysebereich. Setupbereich und Analysebereich sind
dabei ausschließlich vom Testleiter einsehbar und editierbar. Im Setup-Bereich wird der Test
konfiguriert, indem der Testleiter zunächst einen Namen und die Sprache für den Test wählt.
Danach kann er eine unbegrenzte Anzahl an Wireframes10 oder Screenshots des zu testenden
Objekts hochladen um diese im nächsten Schritt mit Aufgaben an die Testnutzer zu beschriften.
Des Weiteren kann in diesem Bereich ein Leitrahmen mit Willkommens-, Anleitungs- und
Dankestext, sowie ein Pretest und Post-Test, erstellt werden. Die kostenpflichtige Version des
Tools erlaubt anschließend noch das Einfügen des Firmenlogos. Ist der Test konfiguriert, kann
der Testleiter vor Veröffentlichung den Test durchlaufen und ihn dann noch. Ist der Testleiter
zufrieden, kann er den Test veröffentlichen. Der Test wird durch einen Link geöffnet und
gestartet. Im Analysebereich kann der Testleiter die durchschnittliche Bearbeitungszeit des
Tests, die einzelnen Ergebnisse der Tester, die Antworten zu den Pre- und Post-Tests und die
Heatmap einsehen. Er kann die Heatmap auch als PDF oder XLS-Datei downloaden.
6 „Instrument der Wettbewerbsanalyse. Benchmarking ist der kontinuierliche Vergleich von Produkten, Dienstleistungen sowie Prozessen und Methoden mit
(mehreren) Unternehmen[...]. Grundidee ist es, festzustellen, welche Unterschiede bestehen, warum diese Unterschiede bestehen und welche
Verbesserungsmöglichkeiten es gibt.“ wirtschaftslexikon.gabler.de/Definition/benchmarking.html
7 http://www.optimalworkshop.com/chalkmark.htm
8 http://theclicktest.com
9 http://usabilla.com
10 Wireframes sind „[...] vorläufige Entwürfe von Seiten, also konzeptionelle Prototypen der Seite. Sie zeigen das Skelett des Navigationssystems ohne das
letztendliche visuelle Design.“ (Kalbach 2008:259)
26
Das zweite zu vergleichende First-Click-Tool wird von ClickTest angeboten. Dieses Tool erlaubt
es im Setup-Bereich einen Namen und die Sprache für den Test zu wählen, einen Screenshot
oder Wireframe hochzuladen und die dazugehörige Aufgabe einzugeben. Der Analysebereich
wird nach der Konfiguration und Publikation des Tests angezeigt. Der Testleiter kann dabei in
einem Drop-Down-Menü wählen, welche Anzeige der Ergebnisse er wünscht. Hier stehen drei
Möglichkeiten zur Verfügung: plasma map, heat map und click map. Des Weiteren kann im
Analysebereich die Anzahl der erwünschten Ergebnisse bestimmt werden. Der Test wird
entweder zufällig von anderen Nutzern der Seite durchgeführt oder kann vom Testleiter als Link
an die Tester versendet werden.
Der dritte Vergleichsgegenstand ist das First-Click-Tool von Usabilla. Im Setup-Bereich dieses
Tools kann eine Einleitung mit Anweisungen über den Test und ein Dankestext optional erstellt
werden. Der Testleiter hat die Möglichkeit dem Tests mehrere Screenshots oder Wireframes
hinzuzufügen und diese mit Aufgaben zu beschriften. Zudem kann er entscheiden, ob die
Aufgabe mit einem Klick oder mit mehreren Klicks gelöst werden soll. Wird der Test vom
Testleiter aktiviert, bekommt er mehrere Links für diverse Plattformen, wie Facebook oder
Twitter, um den Test zu teilen. Im Analysebereich kann der Testleiter die Ergebnisse in einer
Heatmap einsehen. Des Weiteren kann er in diesem Bereich alle Ergebnisse der einzelnen Tester
einsehen und erkennen, ob die Aufgabe gelöst wurde und wie viel Zeit der Tester für die
einzelnen Tasks aufgebracht hat. Die Heatmap kann als CSV oder PNG-Datei exportiert
werden.
2.3.2 Heuristische Evaluation
Eine heuristische Evaluation ist eine Usability-Methode zur Aufdeckung der Usability-Probleme
eines User Interface Designs, die mit Hilfe von Richtlinien, den Heuristiken, Schritt für Schritt
durchgeführt wird (vgl. Nielsen, 1995).
Die heuristische Evaluation der drei zu vergleichenden First-Click-Tools soll helfen die
Schwachstellen und Stärken der jeweiligen Tools aufzudecken. Nielsens zehn Usability-
Heuristiken (vgl. Nielsen, 1995) dienen hierfür als Grundlage der Evaluation. Während die
Ergebnisse in einer Tabelle zusammengefasst werden (s. A3) , sollen an dieser Stelle weitere
Anforderungen an den Frontend- Prototypen des mobilen First-Click-Tools resultieren.
1. Visibility of system status: Das System soll den Nutzer mithilfe von Feedback über den
aktuellen Status informieren.
27
Anforderung 11: In einer Statusanzeige oben rechts soll der Tester den aktuellen Fortschritt
des Testdurchlaufs erkennen können. Damit die Anzeige schnell erfasst
werden kann, soll sie optisch dem Design des Tools angepasst werden,
darf jedoch nicht irritierend wirken.
2. Match between system and the real world: Das System soll die Sprache des Nutzers
sprechen anstatt Fachliteratur anzuwenden. Informationen sollen in natürlicher und logischer
Reihenfolge erscheinen.
Anforderung 12: Der Test soll mit einem Willkommens-, Anleitungs- und Dankestext
umrahmt werden, sodass der Nutzer sich zu keiner Zeit verloren sieht, ihm
hilfreiche Informationen bereitgestellt werden und er durch den Test
geführt wird.
3. User control and freedom: Oft vertippen oder verirren sich Nutzer im System. Hierfür soll
ein „Notausgang“, also ein „Abbrechen“ oder „x“, dem Nutzer die Möglichkeit geben, die
Funktion zu beenden.
Anforderung 13: Der Test soll jederzeit von der Testperson abgebrochen werden können.
Hierzu soll ein „Zurück zur Website“-Button unten eingefügt werden.
Anforderung 14: Fühlt der Nutzer sich überfordert oder hat Verständnisschwierigkeiten,
will den Test aber nicht abbrechen, soll ein „Überspringen“-Button in
den einzelnen Tasks eingebaut werden.
4. Consistency and standards: Der Nutzer soll sich an einer konsistenten Gestaltung
orientieren können. Er soll sich nicht über den plötzlichen Wechsel des Layouts oder
Bedeutungen von Buttons irritiert fühlen.
Anforderung 15: Das Tool soll ein einheitliches Design aufzeigen. Buttons und Design
sollen während des gesamten Tests die gleiche Funktion und das gleiche
Design haben.
5. Error prevention: Zwar soll das Design so erstellt werden, dass keine Fehlermeldungen
erscheinen, ist dies dennoch der Fall, soll der Nutzer die Möglichkeit einer Bestätigungsoption
haben, bevor er eine weitere Aktion ausführt.
6. Recognition rather than recall: Objekte, Aktionen und Optionen sollen dem Nutzer stets
28
gegenwärtig sein. Der Nutzer soll sich Informationen nicht merken müssen. Anweisungen an den
Nutzer sollen aus diesem Grund immer sichtbar sein.
Anforderung 16: Die Aufgabenbeschreibung soll in den einzelnen Aufgaben jederzeit
sichtbar sein.
7. Flexibility and efficiency of use: Akzeleratoren, also Beschleuniger, können zur
Beschleunigung der Prozessschritte eingesetzt werden (z.B. beim Eingeben von Texten).
Anforderung 17: Die Anzahl der Textfelder soll gering gehalten werden.
Eingabemöglichkeiten des Nutzers sollen eher durch das drücken von
Radio-Buttons oder Drop-Down-Menüs erfolgen.
8. Aesthetic and minimalist design: Irrelevante Informationen sollen nicht dargestellt werden,
da sie von den relevanten Informationen ablenken können und den Nutzer irritieren.
Anforderung 18: Der Test soll minimalistisch und schlicht gestaltet sein. Das Design soll
jedoch ansprechend wirken.
9. Help users recognize, diagnose, and recover from errors: Fehlermeldungen sollen in
natürlicher Sprache und nicht in Codes erscheinen, das Problem genau benennen und einen
Lösungsweg vorschlagen.
10. Help and documentation: Dem Nutzer sollen stets Hilfe und Anweisung zur Verfügung
stehen.
Anforderung 19: Ein „Help“-Button, der unten links platziert werden soll, soll den
Anleitungstext anzeigen.
2.4 Frontend-Prototyp
Dieses Kapitel soll die Konzeption eines Prototypens für den Durchführungsbereich, also den
First-Click-Test, des Tools darstellen. Über die Methode des Brainstormings sollen erste Ideen
zusammengefasst werden, die dann im Laufe des Kapitels in der Benutzerführung und dem
Design des Tests erweitert werden, sodass ein Prototyp für den Durchführungsbereich vorgestellt
werden kann.
29
2.4.1 Brainstorming
Brainstorming kann zu kreativen Ergebnissen führen, die im Laufe der Entwicklung eines
Projekts angewandt werden können. Nach Cory (2003) ist es zunächst wichtig, sich die fünf W-
Fragen (Was, Warum, Wo, Wann und Wer) zu stellen, sodass eine Strategie entwickelt werden
kann.
Was: Konzeption eines Frontend-Prototypen eines First-Click-Tools für mobile
Anwendungen.
Warum: First-Click-Tools gibt es bisher nur für die Desktop-Anwendung, jedoch nicht für
mobile Endgeräte.
Wo: Konzeption erfolgt mit dem Prototyping-Tool Axure
Wann: Konzeption erfolgt in einem Zeitraum von 8 Wochen.
Wer: Nutzer von mobilem Internet.
Ziel des Brainstormings ist es ein Grundgerüst für das Frontend zu entwerfen, sowie neue
Funktionen und Eingabemöglichkeiten zu integrieren. Ideen und Strategie werden
skizziert und sind somit jederzeit einsehbar. Folgende Regeln nach Ginsburg (2011) wurden
während des Brainstormings eingehalten:
Es darf zunächst keine Kritik geäußert werden, auch wenn diese Probleme bei der
Implementierung hervorrufen können.
Auch ausgefallene Ideen sollen geäußert werden, da sie trotz der Wahrscheinlichkeit
nicht umgesetzt zu werden, trotzdem inspirierend sein können.
Die Qualität der Skizzen ist nicht wichtig, da nur der Inhalt relevant ist.
Es ist vorteilhaft, Ideen mehrere Personen zusammenzufügen, da nicht jeder die gleichen
Ideen hat und eine Verknüpfung der vielen verschiedenen Ideen zu einem besseren
Ergebnis führen kann.
30
Abb. 6: Skizzen des 1. Brainstormings
Während der einzelnen Sitzungen entstanden mehrere Skizzen (s. Abb. 6), von welchen einige
Ideen später in den Frontend- Prototypen eingebaut wurden.
2.4.2 Benutzerführung
Die Navigation des Frontend-Prototypens soll dem Nutzer mithilfe einer einfachen
Benutzerführung ermöglicht werden. Dabei soll die Benutzerführung den Nutzer nicht
tatsächlich führen, sondern ihm einen Überblick über seine Navigationsmöglichkeiten
geben. Die Benutzerführung ist folglich konsistent und logisch aufzubauen, sodass der
Nutzer nach kurzer Zeit die Reaktionen des Systems vorhersehen kann, seine
Erwartungskonformität somit gedeckt wird (vgl. Beier 2002:102 f.). Der Frontend-
Prototyp soll eine lineare Benutzerführung ermöglichen, indem der Nutzer durch Drücken
eines „Weiter“-Buttons vorwärts und durch das betätigen eines „Zurück zur Website“-
Buttons zurück zur Startseite der mobilen Website navigieren kann. Der Nutzer soll
innerhalb des Frontend-Prototypens nicht zurück navigieren können, da er dadurch
Ergebnisse verfälschen könnte, indem er die Aufgabe nochmals bearbeitet. Die Konsistenz
der Navigation soll durch gleichbleibende Gestaltung der Buttons gewährleistet werden,
indem Farben und Wording der Buttons innerhalb des Prototypens unveränderlich
gestaltet sind. Des Weiteren soll darauf geachtet werden, dass das Wording, also die
Beschriftung, der Buttons vom Nutzer leicht zu verstehen ist.
31
2.4.3 Gestaltrichtlinien für mobile Websites
Neben der Benutzerführung ist die Gestaltung der mobilen Website ebenfalls auschlaggebend für
eine positive User Experience, da eine gute, übersichtliche Gestaltung der Website zur einer
erfolgreichen Bedienung führt. Damit die Gestaltungsfreundlichkeit optimiert werden kann,
stehen den Entwicklern Richtlinien zur Gestaltung mobiler Websites zur Verfügung. Dan
Seward (2011) beschreibt in seinem Practical Guide 17 Richtlinien, die zur Gestaltung mobiler
Websites herangezogen werden können. Diese Richtlinien sollen daraufhin in den Prototypen
eingebaut werden.
Richtlinie 1: Entferne überflüssiges Material.
Aufgrund der Besonderheiten der Mobilität, wie z.B. kleine Displays, muss der Inhalt der Seite
auf das Nötigste beschränkt werden. Dies kann durch das Verwenden von kleinen Bildern,
kurzen Texten, einem einfachen Fronend-Code oder durch Vermeiden von Popups realisiert
werden.
Richtlinie 2: Hebe den besten Nutzungspfad hervor.
Nachdem der Inhalt auf das Nötigste reduziert wurde, ist es des Weiteren wichtig, die vom
Nutzer am häufigsten genutzten Funktionen oben auf der Seite zu platzieren, um dem Nutzer die
Führung an sein Ziel zu vereinfachen.
Richtlinie 3: Gib klare Angaben über den Fortschritt.
Dem Nutzer muss in effizienter Art und Weise dargestellt werden, wo er sich gerade befindet.
Dies geschieht beispielsweise durch das Integrieren des Logos auf der mobilen Website oder
einer übersichtlichen Informationsarchitektur.
Richtlinie 4: Gib dem Nutzer die Möglichkeit zwischen mobiler und klassischer Website
wechseln zu können.
Aufgrund der Vertrautheit des Nutzers mit der konventionellen Desktopwebsite, soll dem Nutzer
der mobilen Website ein Wechsel zu dieser ermöglicht werden. Auch um Funktionen, die in der
mobilen Version nicht eingebunden sind, zu finden, bietet es sich an, dem Nutzer einen Zugriff
auf die Desktopwebsite zu ermöglichen. Damit der Nutzer weiß, dass er sich auf der mobilen
Website befindet, sollte dies in der URL gekennzeichnet werden (z.B. m.site.com).
Richtlinie 5: Ermögliche eine einfache Kontaktaufnahme über das Telefon.
Da der Nutzer der mobilen Website sein Telefon bereits in der Hand hält, soll ihm ermöglicht
werden durch einfache Tastenkürzel oder Drücken der Telefonnummer bzw. E-Mailadresse
Kontakt mit der zuständigen Person aufnehmen zu können.
Richtlinie 6: Verwende ein einspaltiges Layout.
32
Damit das Layout sich den vielen verschiedenen Geräte, von denen auf die mobile Website
zugegriffen wird, anpassen kann, empfiehlt es sich, ein einspaltiges, dynamisches Layout zu
verwenden.
Richtlinie 7: Vermeide horizontales scrollen.
Das Layout der mobilen Website sollte auf ein flüssiges, horizontales Layout hinauslaufen. Die
Möglichkeit des Scrollens sollte weitgehend vermieden werden, da das Risiko besteht, dass
wichtige Inhalte eventuell vom Nutzer nicht wahrgenommen werden könnten.
Richtlinie 8: Eingeschränktes vertikales Scrollen kann verwendet werden.
Das vertikale Scrollen ist aufgrund der für die mobile Website zur Verfügung stehenden Größe
oftmals nicht zu vermeiden und kann aus diesem Grund in die mobile Webseite integriert
werden. Allerdings sollte nur minimales vertikales Scrollen vom Nutzer verlangt werden.
Richtlinie 9: Minimiere den Input, insbesondere den Textinput.
Da das Eingeben von Texten über mobile Endgeräte für den Nutzer sehr mühselig sein kann,
empfiehlt es sich zum Sammeln von Daten des Nutzers Tap-Funktionen oder Drop-Down-Menüs
in die mobile Website einzubauen.
Richtlinie 10: Verwende hohe Kontraste bezüglich visuellen Elementen und Texten.
Damit der Nutzer den Inhalt der mobilen Website auch unter verschiedenen Umwelteinflüssen
wie starkes oder schwaches Licht erkennen kann, ist es wichtig, dass Kontraste das Lesen unter
diesen Bedingungen ermöglichen.
Richtlinie 11: Verwende große Schriftgrößen.
Die Schriftgröße muss zwar dem mobilen Kontext angepasst werden, jedoch soll der Text gut
leserlich sein.
Richtlinie 12: Gestalte auswählbare Elemente der mobilen Website groß und mit
ausreichendem Abstand zueinander.
Da der Inhalt einer konventionellen Desktopwebsite minimiert wird, muss darauf geachtet
werden, dass auswählbare Elemente, wie Buttons, aufgrund des Fat-Finger-Problems (vgl.
Wroblewski) groß genug gestaltet werden. Damit der Nutzer sich nicht verdrückt, sollen die
Abstände zwischen den Elementen ausreichend sein.
Richtlinie 13: Limitiere die Navigationsoptionen.
Wichtige Inhalte müssen von unwichtigen Inhalten getrennt werden, sodass die mobile Website
nur noch aus Navigationselementen besteht, die den Nutzer zu den wichtigen Inhalten führen.
Das Wording von Links und Buttons der mobilen Website muss mit Bedacht gewählt werden,
sodass der Nutzer schnell an sein Ziel kommt.
33
Richtlinie 14: Biete dem Nutzer gleich auf der Startseite die aktuellsten und beliebtesten
Themen an.
Damit der Nutzer auf schnellsten Weg an sein Ziel gelangt und dafür nicht viele Links öffnen
muss, sollen die aktuellsten und beliebtesten Themen in Form von Links auf der Startseite
präsentiert werden.
Richtlinie 15: Platziere Logos, Home-Buttons und Breadcrumbs in der oberen Hälfte der
mobilen Website.
Das Logo dient dem Nutzer zur Orientierung und sollte aus diesem Grund immer sichtbar sein.
Breadcrumbs können bei mobilen Websites mit einer tiefen Navigationsarchitektur ebenfalls zur
Orientierung hilfreich sein, müssen allerdings aufgrund ihrer kleinen Größe nicht verwendet
werden.
Richtlinie 16: Platziere ein einfaches Menü am Ende der mobilen Website.
Wenn der Nutzer am Ende der Website angekommen ist, bietet es sich an, an dieser Stelle ein
Menü einzubauen, welches die wichtigesten Navigationsoptionen wie Kontakte, Home-Button,
Link zur Desktopwebsite, beinhaltet. Mithilfe dieses Menüs muss der Nutzer nicht nach oben
scrollen.
Richtlinie 17: Stelle für den Nutzer wichtige Elemente oben sowie unten auf der mobilen
Website bereit.
Für mobile Websites, die eine Suche erfordern, ist es von Vorteil wenn oben und unten auf der
Seite eine Sucheingabe ermöglicht wird, sodass der Nutzer keinen hohen Scrollaufwand leisten
muss.
2.4.4 Skalierung
Eine weitere Überlegung hinsichtlich des HTML-Prototypens des Frontend-Bereichs ist die
Darstellung der mobilen Website auf verschiedenen Endgeräten. Aufgrund der verschiedenen
Größen von Smartphone-Displays ist es im Rahmen dieser Arbeit unmöglich Screenshots der
mobilen Website an die verschiedenen Endgeräte anzupassen. Der Frontend-Prototyp soll
deswegen nur mit Screenshots der mobilen Website, die über das iPhone 4 aufgenommen
wurden, getestet werden, sodass eine realistische Darstellung der mobilen Website möglich ist.
Um jedoch einen Eindruck über die Darstellung unterschiedlicher Auflösungen zu bekommen,
sollen drei Screenshots Aufschluss über die Wahrnehmung von den unterschiedlichen
Auflösungen geben. Hierbei wurde ein Screenshot mithilfe des Smartphones Samsung Galaxy 3,
welches eine geringe Auflösung von 240 x 400 Pixel aufweist, aufgenommen (s. B2.1). Ein
weiterer Screenshot wurde über das iPhone 4 mithilfe der kostenlosen Applikation Screenshot
34
aufgenommen (s. B2.2). Die Applikation nimmt dabei einen Screenshot der ganzen mobilen
Website auf. Der dritte Screenshot wurde im Browser des iPhone 4s mithilfe der
Tastenkombination HOME + ON/OFF gemacht (s. B2.3). Alle drei Screenshots wurden danach
mit dem Grafikprogramm GIMP auf die iPhone 4 Standardauflösung, nämlich 640 x 960 Pixel,
skaliert. Der Screenshot der Applikation Screenshot soll aufgrund der Darstellung der ganzen
mobilen Website in den Prototypen integriert werden, sodass ein realitätsnahes Testen mit
Scrollen ermöglicht werden kann. Alle drei Screenshots sollen den Testpersonen in der
Nachbefragung der Nutzertests vorgelegt werden, sodass diese äußern können, welche
Auflösung sie spontan anspricht.
2.4.5 Der Prototyp
Nachdem der Anforderungskatalog erstellt wurde und die Richtlinien zur Gestaltung mobiler
Websites in Verbindung mit mehreren Brainstorming-Sitzungen erste Ideen zur Gestaltung des
Frontend-Prototypens verschaffen konnten, kann der Prototyp erstellt werden. Der Frontend-
Prototyp wird mit dem Programm Axure RP Pro 6.5 erstellt und an das iPhone 4 angepasst. Das
Programm Axure ermöglicht es, einen interaktiven HTML-Prototypen des Frontend-Bereichs zu
entwickeln.
Für die Konzeption des Frontend-Bereichs des mobilen First-Click-Tools liegt folgendes
Nutzungsszenario zu Grunde: Öffnet der Nutzer die mobile Startseite von Tchibo, wird er
mithilfe eines Fensters im unteren Bereich der Website zu einer kurzen Umfrage eingeladen.
Entscheidet sich der Nutzer an der Umfrage teilzunehmen, öffnet sich der Frontend-Bereich des
First-Click-Tools und der Nutzer wird Schritt für Schritt durch diesen geführt. Wurde der Test
erfolgreich beendet oder bricht der Nutzer den Test selbständig ab, wird er zurück zur Startseite
der mobilen Website geleitet.
Im Folgenden sollen die einzelnen Stadien des Frontend- Prototypens erläutert und diskutiert
werden.
Starten des Prototypens
Hat sich der Nutzer entschieden an der Umfrage teilzunehmen, erscheint zunächst ein kurzer
Willkommenstext (s. Abb. 7). Diese Seite des Prototypens klärt den Nutzer kurz über den Zweck
der Umfrage auf, nämlich der Verbesserung des mobilen Webauftritts, und teilt dem Nutzer mit,
von wem die Umfrage durchgeführt wird. Hier soll sichergestellt werden, dass die Umfrage nicht
von Tchibo konzipiert wurde, sondern eine Firma diese entwickelt hat und durchführt. Zur
Orientierung des Nutzers ist oben links das Logo dieser Firma platziert. Somit weiß der Nutzer,
35
dass er sich nicht mehr auf der mobilen Website von Tchibo befindet und kann sich auf die
Umfrage einstellen. Möchte der Betreiber der mobilen Website, dass die Umfrage während der
gesamten Dauer des Tests mit der Website assoziiert wird, kann das Grundgerüst des Frontend-
Prototypens auch im Corporate Design der Firma designt werden. Hier wurde gegen ein
Corporate Design entschieden, da der Fokus der späteren Nutzertests auf dem Frontend-
Prototypen liegen soll und nicht auf der mobilen Website von Tchibo. Auch soll das gesamte
Layout des Frontend-Prototypens eher schlicht und einfach gestaltet werden, sodass die
Funktionalitäten im Vordergrund stehen können.
Abb.7: Frontend-Prototyp: Willkommenstext
Diese Seite bietet dem Nutzer zwei Navigationsoptionen, die unter dem Willkommenstext
platziert sind. Somit liest der Nutzer den Text zunächst und kann dann vor oder zurück
navigieren. Der „Weiter“-Button führt den Nutzer zum nächsten Schritt der Umfrage, während
der „Zurück zur Website“-Button die Umfrage abbricht und den Nutzer wieder zur Startseite der
mobilen Website leitet. Da dem Betreiber der Webseite eine hohe Beteiligung an der Umfrage
wichtig ist, soll das Navigationselement, dass den Nutzer weiter durch die Umfrage führt, größer
und an erste Stelle sein, als das Element, dass den Nutzer zum Abbruch der Umfrage verleitet. In
einem vorigen Stadium des Prototypens wurde anstelle des „Zurück zur Website“-Buttons ein
[x]-Button oben rechts platziert. Allerdings entspricht ein [x] zum Schließen der Seite nicht den
Konventionen der Mobilität, sondern wird mit dem Browsen auf einem Desktop-PC verbunden.
Da das Klicken eines [x]-Buttons auf dem Desktop-PC das Schließen des kompletten Fensters
erzwingt und den Nutzer nicht zurück zur Startseite führt, wurde diese Funktion durch den
„Zurück zur Website“-Button ersetzt. Der „Zurück zur Website“-Button hat in dem Frontend-
36
Prototypen eine globale Funktion, sodass der Nutzer die Umfrage jederzeit abbrechen kann.
Allerdings soll der Button immer unten auf der Seite zu finden sein, sodass eine geringe
Abbruchquote erzielt wird.
Anleitung
Nachdem der Nutzer den „Weiter“-Button der Willkommensseite gedrückt hat, gelangt er zu
einer Anleitung der Umfrage (s. Abb. 8). Diese Seite beinhaltet wieder das Logo der Firma
oben links und eine Fortschrittsanzeige oben rechts. Mithilfe der Fortschrittsanzeige kann der
Nutzer einschätzen wo er sich gerade befindet und wie viel Zeit die Umfrage noch ungefähr
beanspruchen wird.
Abb. 8: Frontend-Prototyp: Anleitung
Neben der Orientierung des Nutzers hat die Fortschrittsleiste des Weiteren die Funktion, die
Abbruchsquote gering zu halten. Wenn der Nutzer bildlich vor Augen hat, auf welchen zeitlichen
Rahmen die Umfrage sich bezieht, bricht er die Umfrage mit geringerer Wahrscheinlichkeit ab.
Unter Berücksichtigung des mobilen Kontexts und seinen Besonderheiten (s. Kapitel 1.1) wird
die Anleitung zum Aufgabenbereich des Frontend-Prototypens als eine gif-Animation
dargestellt, sodass der Nutzer keinen langen Text lesen muss, sondern ihm alle wichtigen
Schritte des Aufgabenbereichs schnell und einfach präsentiert werden. Die gif-Animation besteht
aus vier Bildern (s. A4) und bezieht sich auf eine vom Test unabhängige Website. Das erste Bild
zeigt dem Nutzer, wo er die Aufgabenstellung findet. Das zweite Bild weist den Nutzer darauf
37
hin, sich die Darstellung der mobilen Website anzugucken, wobei das dritte Bild sicherstellen
soll, dass dabei gescrollt werden kann. Das letzte Bild der gif-Animation soll zeigen, dass der
Nutzer die Aufgabe durch Drücken des dargestellten Bereichs lösen kann. Die Dauer zwischen
dem Abspielen der einzelnen Bildern beträgt 2,5 Sekunden. Ist die Animation einmal
durchgelaufen, kann der Nutzer diese durch Drücken eines Play-Buttons wiederholen. In den
Nutzertests ist herauszufinden, ob die Anleitung in dieser Form von den Testpersonen verstanden
wird. In einer vorigen Version des Frontend-Prototypens wurde der Aufgabenbereich durch eine
kurzen Anleitungstext erläutert. Allerdings erfordert das Lesen eines Textes mehr Aufwand als
das Anschauen einer Animation. Zudem ist eine gif-Animation als Gestaltungselement
innovativer als ein herkömmlicher Anleitungstext. Nachdem die Animation vom Nutzer
angeschaut wurde, kann er wie in der Seite zuvor, zwischen den zwei Navigationsoptionen
„Weiter“ oder „Zurück zur Website“ wählen.
Aufgabenbereich
Der eigentliche First-Click-Test folgt nach der Anleitung des Frontend-Prototypens im
Aufgabebereich. Der Aufgabenbereich (s. Abb. 9) besteht aus drei einzelnen Aufgaben, auf
welche jeweils eine Schwierigkeitseinschätzung folgt.
Da der Aufgabenbereich den wichtigsten Bestandteil des First-Click-Tools darstellt, wurde
dieser in seinen Funktionalitäten komplex konzipiert. Dem Nutzer wird zur Orientierung, wie in
den Seiten zuvor, die Fortschrittsleiste oben rechts präsentiert. Das Logo der durchführenden
Firma wurde aufgrund des Platzmangels im oberen Bereich der Aufgabe entfernt und durch die
Aufgabennummerierung „Aufgabe 1“ ersetzt. Zur deutlicheren Orientierung des Nutzers kann in
späteren Versionen des Prototypens eine Aufgabenummerierung in Form von „Aufgabe 1/4“
eingefügt werden, sodass der Nutzer weiß, wie viele Aufgaben er insgesamt bearbeiten soll. Eine
der wichtigsten Überlegungen während der Entwicklung des Prototypens war die Platzierung
und Präsentation der Aufgabenbeschreibung. In der finalen Version des Prototypens wurde
entschieden, die Aufgabenbeschreibung für den Nutzer sichtbar oberhalb der Darstellung
anzuzeigen. Dies unterstützt zum einen dem natürlichen Lesefluss von oben nach unten, sodass
der Nutzer erst die Aufgabe liest und sich dann die Darstellung anschaut und zum anderen ist die
Aufgabenbeschreibung dem Nutzer während der Bearbeitung der Aufgabe immer präsent.
Allerdings muss vom Entwickler des Tests darauf geachtet werden, dass die
Aufgabenbeschreibung kurz und präzise formuliert wird.
38
Abb. 9: Der Frontend- Prototyp: Aufgabenbereich
Eine andere Überlegung zur Präsentation der Aufgabenbeschreibung war es, diese in Form eines
Drop-Down-Menüs darzustellen. Der Vorteil einer solchen Präsentation ist, dass dadurch Platz
im oberen Bereich eingespart werden kann und weitere Funktionalitäten oberhalb der
Darstellung integriert werden können. Allerdings wäre die Aufgabenbeschreibung nur nach
Betätigen des Drop-Down-Menüs für den Nutzer sichtbar und könnte eventuell durch das Fat-
Finger-Problem (vgl. Wroblewski) zu Nutzungsproblemen führen. Aus diesen Gründen wurde
die Überlegung verworfen. In einem vorigen Entwurf des Prototypens wurde die
Aufgabenbeschreibung sowohl oberhalb der Darstellung, als auch auf einer einzelnen Seite vor
jeder Aufgabenbearbeitung dargestellt. Dies wurde in der finalen Version des Prototypens nicht
eingefügt, da es als überflüssige Interaktion seitens des Nutzers betrachtet wurde. Unterhalb der
Aufgabenbeschreibung hat der Nutzer die Möglichkeit sich die mobile Website mithilfe von
39
Scrollen anzuschauen. Im Prototypen wurde ein Screenshot der ganzen Website eingebaut,
sodass der Nutzer dass Gefühl hat, er wäre tatsächlich auf der mobilen Website von Tchibo. Der
Screenshot wurde mit der Applikation Screenshot, welche kostenlos im AppStore erhältlich ist,
erstellt und in einem Grafikprogram auf die Auflösung 640 x 960 Pixel hochskaliert, sodass sich
die jpg-Datei dem Display des iPhone 4s anpasst. Scrollt der Nutzer bis zum unteren Bereich der
Seite, werden ihm vier Funktionalitäten angezeigt. Zum einen kann der Nutzer durch das
Drücken des „Hilfe“-Buttons unten links auf eine Anleitung in Textform (s. A4) zugreifen. Diese
Funktionalität soll dabei helfen, dass der Nutzer während der Aufgabenbearbeitung bei
Verständnisschwierigkeiten nochmals die Möglichkeit bekommt, eine Anleitung zum Test zu
lesen und ein Abbruch verhindert werden kann.
Der „Hilfe“-Button wurde aufgrund des Platzmangels im oberen Bereich auf den unteren
Bereich der Seite verschoben. Zuvor wurde eine Hilfefunktion in Form eines [?]-Buttons links
neben die Fortschrittsanzeige platziert. Allerdings wurde während der Konzeption des finalen
Prototypens vermutet, dass dieser Button für den mobilen Kontext zu klein gestaltet ist, sodass
ein Button mit der Aufschrift „Hilfe“ als benutzerfreundlicher betrachtet wird. Des Weiteren
befindet sich im unteren Bereich dieser Seite ein „Überspringen“-Button. Diese Funktion soll
dem Nutzer ermöglichen, die Aufgabe überspringen zu können, wenn er keine passende Lösung
findet oder die Aufgabe trotz Hilfefunktion nicht versteht. Überspringt der Nutzer eine Aufgabe
wird er zur Schwierigkeitsabfrage auf einer Skala von -3 (sehr schwierig) bis +3 (sehr leicht)
geleitet (s. A4) und kann dort seine Bewertung abgeben. Ziel des „Überspringen“-Buttons ist es
den Testabbruch zu verhindern. Das wesentliche Problem während der Entwicklung des
Prototypens bestand im Wording dieser Funktion. Zur Auswahl standen Möglichkeiten wie
„Skip“ oder „Ich weiß nicht“. Allerdings wurde sich gegen „Skip“ entschieden, da vermutet
werden kann, dass der englische Begriff für „Überspringen“ nicht jedem Nutzer geläufig ist. Die
Idee den Button mit „Ich weiß nicht“ zu beschriften wurde ebenfalls verworfen, da dies den
Nutzer in seiner Motivation den Test durchzuführen negativ beeinflussen kann. Der Nutzer soll
nicht das Gefühl vermittelt bekommen, er sei nicht in der Lage die Aufgabe lösen zu können.
Das Wording „Überspringen“ ist somit die beste Alternative, da sie dem Nutzer neutral
entgegensteht. Zudem befindet sich im unteren Bereich der Aufgabe die globale Funktion
„Zurück zur Website“, sodass der Nutzer den Test jederzeit abbrechen kann. Da dies jedoch
verhindert werden möchte, ist dieser Button unterhalb des „Hilfe“- und „Überspringen“-Buttons
platziert. Die vierte Funktion in diesem Bereich ist eine Scrollhilfe in Form eines Dreiecks.
Drückt der Nutzer auf dieses Dreieck, wird er automatisch zur Aufgabenbeschreibung im oberen
Bereich der Seite geführt. Somit muss der Nutzer bei großen Darstellung nicht den ganzen Weg
40
hochscrollen. In folgenden Prototypen kann diese Funktion mit „zurück nach oben“ beschriftet
werden, sodass die Funktion eindeutiger gestaltet ist.
Nachbefragung
Nachdem der Nutzer alle drei Aufgaben bearbeitet hat, folgt eine kurze Nachbefragung, die
sowohl Fragen zum Test, als auch personenbezogene Fragen beinhaltet (s. Abb. 10). Die
wesentlichen Elemente dieser Nachbefragung sind Drop-Down-Menüs und Radio-Buttons,
sodass der Nutzer keine freien Texten eingeben muss und die Nachbefragung schnell ausgefüllt
werden kann.
Abb. 10: Frontend-Prototyp: Nachbefragung
Zur Orientierung des Nutzers beinhaltet diese Seite ebenfalls eine Fortschrittsleiste und das
Firmenlogo. Zudem stehen dem Nutzer hier wieder die beiden Navigationsoptionen „Weiter“
und „Zurück zur Website“ zur Verfügung. In einer vorigen Version des Frontend-Prototypens
wurde eine Vorbefragung anstelle einer Nachbefragung integriert. Eine Vorbefragung wurde
allerdings als vorzeitiges Abbruchskriterium betrachtet und sollte daher vermieden werden. Hat
der Nutzer bereits alle Aufgaben bearbeitet und nähert sich dem Gewinnspiel, wird er die
Nachbefragung mit hoher Wahrscheinlichkeit nicht mehr abbrechen.
41
Ende und Gewinnspiel
Die letzte Seite des Frontend-Prototypens besteht aus einem kurzen Dankestext, der den Nutzer
darauf hinweist, dass der Umgang mit seinen Daten vertraulich ist und er nun die Möglichkeit
hat am Gewinnspiel teilzunehmen (s. Abb. 11).
Abb.11: Der Prototyp: Dankestext
Hierfür kann er die Navigationsoption „Zum Gewinnspiel“ wählen und wird so zur Teilnahme
weitergeleitet. Im Prototypen erscheint dann eine Seite, die darauf hinweist, dass an dieser Stelle
das Gewinnspiel zu finden wäre (s. A4). Entscheidet sich der Nutzer gegen das Gewinnspiel, soll
er zurück zur Startseite von Tchibo navigieren und seine Suche fortsetzen können. Da der
Prototyp nicht mit der mobilen Website von Tchibo verbunden wurde, erscheint durch Drücken
des „Weiter auf Tchibo.de“ eine Fehlermeldung. Des Weiteren wurde auf der Dankesseite ein
Link zur Website der durchführenden Firma unterhalb der Navigationsoptionen eingebaut,
sodass Nutzer die Möglichkeit bekommen sich über diese informieren oder Kontakt aufnehmen
zu können. Diese Funktion ist im Prototypen allerdings aufgrund der Fiktion der Firma nicht
aktiviert.
3. Evaluation des Prototypens
Probleme hinsichtlich der Nutzung des Prototypens können frühzeitig durch eine angemessene
Evaluierung behoben werden, sodass der finale Prototyp den Bedürfnissen und Wünschen
potentieller Nutzer angepasst werden kann. Die Evaluierung findet dabei während verschiedenen
42
Entwicklungsstadien statt und umfasst unterschiedliche Evaluierungsmethoden, die den
Prototypen bewerten und verbessern sollen. Während des Prototypings wird die Methode des
Cognitive Walkthroughs angewendet, welche direkt potentielle Nutzungsprobleme beheben soll,
indem ein Experte sich in die Situation des Nutzers begibt und realistische Handlungsabläufe
durchspielt. Nachdem der Prototyping-Prozess abgeschlossen ist, werden an dem Prototypen
Nutzertests durchgeführt. Hierbei können die Testpersonen den Prototypen bewerten und somit
Nutzungsprobleme aufdecken. Mithilfe dieses iterativen Prozesses kann eine Optimierung des
Prototypens ermöglicht werden.
3.1 Cognitive Walkthrough
Potentielle Nutzungsprobleme können mit der Methode des Cognitive Walkthroughs behoben
werden. Dabei versetzt sich ein Experte in die Situation des Nutzers und spielt unterschiedliche
Handlungsabläufe mehrmals durch. Der Cognitive Walkthrough dieser Arbeit fand vor und
während des Prototypings statt. Als Basis dieser Evaluierungsmethode dienten die erstellten
Personas (vgl. 2.2.2). Ziel eines Cognitive Walkthroughs ist es vorauszusagen, ob spätere
Nutzer selbstständig die festgelegten Handlungen durchführen können (vgl. Sarodnick
2006:145).
Folgende Handlungsabläufe sind dabei entstanden:
Jasmin stößt zufällig auf die mobile Website von Tchibo. Sie sieht, dass sie gebeten wird
an einer Umfrage teilzunehmen und entscheidet sich aufgrund des Gewinnspiels
mitzumachen. Sie versucht die Umfrage schnell zu beantworten, um an das Gewinnspiel
zu gelangen. Dabei achtet sie nicht auf Details und klickt sich schnell durch die Umfrage.
Christina sieht, dass sie gebeten wird an einer Umfrage teilzunehmen. Da sie nicht
zufrieden mit dem mobilen Webauftritt von Tchibo ist, ist sie glücklich darüber, an einer
Umfrage teilzunehmen. Sie liest sich die Anweisungen und Aufgaben aufmerksam durch
und entscheidet sorgfältig, wie sie vorgeht.
Andreas hat von der Umfrage auf der mobilen Website von Tchibo gehört und ist
interessiert daran teilzunehmen. Dabei achtet er auf Funktionalitäten und Aufbau der
Umfrage. Die Aufgaben und Nachbefragung beantwortet er dabei nicht sorgfältig.
Die Erkenntnisse dieses Cognitive Walkthroughs haben während der Entwicklung des Frontend-
Protoypens dabei geholfen, neue Funktionalitäten aufzunehmen und vorher integrierte Ideen zu
verwerfen.
43
3.2 Nutzertests Neben dem Cognitive Walkthrough vor und während der Entwicklungsphase des Frontend-
Prototypens, wurden nach der Entwicklung als weitere Evaluierungsmethode Nutzertests
herangezogen. Dumas (1999) beschreibt die fünf Charakteristika von Nutzertests wie folgt:
Das Ziel eines Nutzertests ist es, die Benutzerfreundlichkeit eines Produktes zu
verbessern.
Die Testpersonen repräsentieren reale Nutzer des Produkts.
Die Testpersonen durchspielen realistische Aufgaben.
Der Testleiter beobachtet und nimmt auf, was die Testpersonen sagen und machen.
Der Testleiter analysiert die Ergebnisse, findet die Nutzungsprobleme und macht
Verbesserungsvorschläge.
Somit eignen sich Nutzertests gut für eine formative Evaluation, sodass Schwachstellen, die
zuvor in der Entwicklungsphase übersehen wurden, aufgedeckt werden können.
3.2.1 Vorbereitung
Bevor ein Nutzertest durchgeführt wird, bedarf es an genauer Vorbereitung und Planung. Die
Vorbereitung dieses Nutzertests bestand zunächst darin, einen Leitfaden (s. B1) zu erstellen. Der
Leitfaden gewährleistet dem Testleiter eine chronologische Struktur des Nutzertests und dient
somit als Stütze. Nachdem der Leitfaden erstellt wurde, wurde sich mit den technischen
Hilfsmitteln vertraut gemacht. Als Testgeräte fungierten in diesem Nutzertest das iPhone 4 und
iPhone 4s, sowie eine integrierte Webcam des Laptops, als auch eine USB-Webcam. Während
die im Laptop integrierte Webcam zur Aufzeichnung der Mimik und Gesten der Testpersonen
diente, hat die USB-Webcam in den Nutzertests, die mit dem iPhone 4 durchgeführt wurden, den
Bildschirm des Smartphones erfasst. In Nutzertests, die mit dem iPhone 4s aufgenommen
wurden, standen ein AV-Kabel und HD-Recorder zur Verfügung, mit welchen es möglich war,
die Aktionen des Bildschirms aufzuzeichnen. Mithilfe der Software Morae Recorder konnten die
Aufnahmen des Bildschirms und die Aufnahmen der Mimik und Gestik zu einer Aufnahme
zusammengefügt und für die spätere Auswertung gespeichert werden. Nachdem die technischen
Hilfsmittel auf Funktionalität überprüft wurden, konnten die Testpersonen rekrutiert und ein Pre-
Test von Testleiter durchgeführt werden.
3.2.2 Testpersonen
Bei der Rekrutierung von Testpersonen ist es wichtig, darauf zu achten, dass es Testpersonen
sind, die eine potentielle Nutzergruppe des Produkts repräsentieren. Aus diesem Grund wurde
44
während der Rekrutierung der Testpersonen für diesen Nutzertest darauf geachtet, dass es sich
um Personen handelt, die eine gewisse Affinität zum mobilen Internet aufzeigen können und ein
Smartphone besitzen, sodass die Testpersonen potentielle Nutzer des Durchführungsbereichs des
First-Click-Tools repräsentieren. In der Literatur wird häufig von einem Teilnehmerkreis aus
maximal 20 Testpersonen ausgegangen, da bei mehr Testpersonen die Chance neue
Nutzerprobleme aufzudecken sehr gering ist (vgl. Nielsen, 1994). Für diesen Nutzertest wurden
acht Personen rekrutiert, sodass der Aufwand im Zuge dieser Arbeit gering gehalten werden
konnte, jedoch genügend Teilnehmer vorhanden waren, um Nutzerprobleme des Frontend-
Prototypen aufzudecken. Da Studien bezüglich der Nutzung des mobilen Internets zeigen, dass
der prozentual höhere Anteil der Nutzer männlich ist (vgl. GO SMART, 2012), wurden für
diesen Nutzertest fünf Männer und drei Frauen rekrutiert. Vor der Entwicklungsphase wurde
eine Altersgruppe zwischen 18 und 35 Jahren als potentielle Zielgruppe des First-Click-Tools
definiert. Im Rahmen dieses Nutzertests wurden drei Altersgruppen gebildet, von welchen fünf
Testpersonen aus der Altersgruppe 1 (zwischen 18 und 25 Jahre), drei Testpersonen aus der
Altersgruppe 2 (zwischen 25 und 30 Jahre) und eine Testperson aus der Altersgruppe 3
(zwischen 30 und 40 Jahre) stammten. Alle acht Teilnehmer verfügen privat über ein
Smartphone und gaben in der Vorbefragung an, dass sie täglich über ihr Smartphone auf das
mobile Internet zugreifen. Des Weiteren ergab die Vorbefragung, dass 50 % der Teilnehmer
bereits an einer Online-Umfrage teilgenommen haben.
3.2.3 Testaufbau
Nachdem ein Pre-Test vor dem eigentlichen Nutzertest erfolgreich durchgeführt wurde und
sichergestellt werden konnte, dass der Nutzertest technisch und verständlich einwandfrei ist,
startete der Nutzertest. Dieser ist in vier Teile gegliedert: einer Vorbemerkung zum Testablauf,
einer Einverständniserklärung, dem eigentlichen Test des Prototoypens und einer
Nachbefragung.
Zunächst wurde der Testperson eine Vorbemerkung (s. B1) vorgelegt, welche klarstellen soll,
dass es sich im folgenden Test um einen Prototypen handelt, der Bereiche enthalten kann, die
noch nicht fertiggestellt oder funktionsfähig sind. Des Weiteren weißt die Vorbemerkung darauf
hin, dass ausschließlich der Prototyp getestet und verbessert werden soll und der Fokus dieses
Tests nicht auf der mobilen Website von Tchibo liegt. Nachdem die Testperson die
Vorbemerkung gelesen hat und keine Rückfragen mehr hatte, wurde sie gebeten eine
Einverständniserklärung (s. B1) zu unterschreiben. Diese stellt sicher, dass die Testperson damit
einverstanden ist, dass von ihr Ton- und Videoaufnahmen während des Tests aufgezeichnet
45
werden und zur späteren Auswertung zur Verfügung stehen. Danach sollte die Testperson eine
kurze Vorbefragung beantworten, welche für die Auswertung relevante Nutzungseigenschaften
des mobilen Internets beinhaltet.
Im nächsten Schritt fand der Test des Prototypens statt. Hierzu wurde der Testperson folgendes
Szenario zum Einstieg in den Prototypen vorgelegt:
1) Sie möchten sich über die aktuellen Angebote von Tchibo informieren, da ein guter
Freund Ihnen von den Themenwochen von Tchibo erzählt hat. Da Sie sich gerade nicht in
der Nähe eines PCs befinden, öffnen Sie die mobile Website von Tchibo. Als die Seite
sich öffnet, sehen Sie ein Fenster, in welchem Sie gebeten werden, an einer kurzen
Umfrage teilzunehmen.
Erfolgskriterium: Der Nutzer entscheidet sich (nicht) an der Umfrage teilzunehmen und
drückt hierfür den entsprechenden Button.
Abbruchkriterium: Dem Nutzer fällt die Einladung zur Umfrage nicht auf und er
versucht auf der Startseite auf die Themenwochen zuzugreifen.
Zeitbegrenzung: 1 Minute
Nachdem diese Aufgabe erfolgreich bearbeitet wurde, wurde die Testperson gebeten
anzukreuzen, ob sie außerhalb der Testsituation an dieser Umfrage teilgenommen hätte. Um den
Übergang von der Startseite zum eigentlichen Testteil einfach zu gestalten, folgte die zweite
Aufgabe:
2) Sie entschließen sich an der Umfrage teilzunehmen. Starten Sie nun die Umfrage.
Erfolgskriterium: Der Nutzer drückt auf den „Ja, Umfrage jetzt starten“-Button.
Abbruchskriterium: Technische Probleme.
Zeitbegrenzung: 1 Minute.
Nachdem die Testperson die Umfrage gestartet hat, befand sie sich im Durchführungsbereich des
First-Click-Tools und wurde schrittweise durch diesen ohne weitere Szenarien von Anfang bis
hin zum Ende der Umfrage geführt. Wurde die Umfrage erfolgreich abgeschlossen, folgte der
letzte Schritt des Nutzertests, nämlich die Nachbefragung. In dieser hat die Testperson die
Möglichkeit die Schwierigkeit der Umfrage auf einer Skala von -3 (sehr schwierig) bis 3 (sehr
leicht) einzuordnen. Des Weiteren beinhaltet die Nachbefragung den User Experience
Questionnaire nach Laugwitz et al. (2008), der mithilfe von weichen und harten Usability-
46
Kriterien den Eindruck der Testperson bezüglich des Prototypens quantitativ messen soll. Die
Bewertung des Prototypens mithilfe dieses Questionnaires kann dann in die fünf Dimensionen
Durchschaubarkeit, Attraktivität, Effizienz, Originalität und Stimulation kategorisiert werden.
Zudem wurde die Testperson in der Nachbefragung gebeten, ihren Eindruck bezüglich von
Stärken und Schwächen des Prototypens in einem freien Textfeld wiederzugeben.
3.2.4 Besonderheiten
Um ein realitätsnahes Testsetting zu gewährleisten, wurden die Nutzertests nicht im Labor,
sondern unter realen Bedingungen durchgeführt. Unter realen Bedingungen werden hier
Situationen verstanden, in denen ein Smartphone üblicherweise bedient wird (s. 2.2.1). Hierzu
wurden beispielsweise Testpersonen für die Aufnahme des Nutzertests in ihrer Wohnung
besucht, sodass sie sich in der für sie gewohnten Testumgebung wohl fühlen konnten, sich nicht
beobachtet fühlten und der Testleiter die Bedienung des Frontend-Prototoypens unter realen
Umständen beobachten konnte. In zwei der acht Nutzertests lief im Hintergrund leise ein
Fernsehgerät, sodass vom Testleiter beobachtet werden konnte, wie die Testpersonen mit dem
Frontend-Prototypen agieren während sie sich in einer Geräuschkulisse befinden. Diese
Geräuschkulisse kann auf alltägliche Situationen, wie z.B. eine Busfahrt oder das Warten an
verschiedenen Orten, simulieren.
3.3 Ergebnisse der Nutzertests
Das primäre Ziel der Nutzertests des Frontend-Prototypens ist es qualitative Daten zu betrachten,
sodass kritische Ereignisse (Nutzungsprobleme) erkannt werden und der Prototyp hinsichtlich
dieser verbessert werden kann. Quantitative Ergebnisse, wie die gesamte Dauer des
Testdurchgangs oder die Bearbeitungszeit einzelner Aufgaben, sollen bei der Evaluation der
Nutzertests nicht von primärer Bedeutung sein, da sie nicht ausschlaggebend für eine
erfolgreiche Bedienung des Prototypens sind.
Die Evaluation des Frontend-Prototypens basiert auf dem Modell zur Diagnose von
Nutzungsproblemen nach Hassenzahl & Seewald (2004). Die Teilschritte dieses Modells
bestehen aus:
Erfahrung (Datenerhebung), in welcher die kritischen Ereignisse durch Beobachtung
und Befragung identifiziert werden,
Konstruktion (Datenauswertung), welche die kritischen Ereignisse gruppiert und
klassifiziert, sowie der
Interpretation, welche eine gemeinsame Ursache für eine Ereignisgruppe unterstellt.
47
Des Weiteren werden die herausgearbeiteten Nutzungsprobleme priorisiert und
Verbesserungsvorschläge erarbeitet. Der Evaluator muss während der Evaluation darauf achten,
dass die kritischen Ereignisse zunächst nur Beobachtungen und keine voreiligen Interpretationen
enthalten (vgl. Hassenzahl & Seewald, 2004).
Die Priorisierung der Nutzungsprobleme kann in Severity Ratings (Nielsen, 1994), also in
Schweregrade, kategorisiert werden, sodass entschieden werden kann, welche
Nutzungsprobleme definitiv behoben werden müssen und welche Nutzungsprobleme bei Bedarf
behoben werden können. In Anlehnung an Nielsen (1994) definiert Schweibenz (2001) folgende
fünf Schweregrade:
0 = Kein Usability- Problem
1 = Kosmetisches Problem (kann beseitigt werden, wenn genug Zeit zur Verfügung steht)
2 = Kleines Usability- Problem (geringe Priorität bei der Beseitigung)
3 = Großes Usability- Problem (hohe Priorität bei der Beseitigung)
4 = Usability- Katastrophe (muss unbedingt beseitigt werden).
Basierend auf diesen Schweregraden wurden sieben Nutzungsprobleme des Frontend-
Prototypens absteigend kategorisiert. Die Lösungsvorschläge für die Nutzungsprobleme, sowie
die Vor- und Nachteile dieser, wurden mit einem der Betreuer dieser Arbeit in einem
Diskussionsworkshop besprochen, sodass die beschriebenen Löschungsvorschläge ein Mix aus
meinen und denen des Betreuers sind.
1. Anleitung: Trotz der Seitenüberschrift „Anleitung“ hat keine der Testpersonen
wahrgenommen, dass es sich um die tatsächliche Anleitung des Tests handelt. Der
Testleiter hat in 3 Nutzertests die Testperson darauf hingewiesen, dass es sich um die
Anleitung der Umfrage handelt. Dieses Eingreifen des Testleiters kann als potenzielles
Abbruchskriterium betrachtet werden, da nicht beurteilt werden kann, ob die betroffenen
Testpersonen den Test ohne das Eingreifen an dieser Stelle abgebrochen hätten. Als der
Testleiter darauf hingewiesen hat, dass es sich um eine Anleitung zum Test handelt
äußerten sich die Testpersonen überrascht („Achso, das war die Anleitung“; „Ach, das
hab ich gar nicht gecheckt, dass das die Anleitung war.“). Zwei der Testpersonen haben
bereits nach dem ersten Bild der gif-Animation auf „Weiter“ gedrückt und hatten somit
nicht die Möglichkeit diese als Animation wahrzunehmen. Vier Testpersonen haben
einen Kommentar wie „Okay, ich soll nach einer neuen Sonnenbrille suchen“ geäußert
48
und dachten folglich, dass nach dem Drücken des „Weiter“-Buttons eine Sonnenbrille
gesucht werden soll. Einer Person war die gif-Animation trotz Wiederholung zu schnell.
Allerdings hatte das Missverständnis bzw. der Abbruch der Anleitung keinen Einfluss auf
die Aufgabenerledigung. Alle acht Testpersonen konnten die Aufgaben 1 – 3 problemlos
durchführen.
Schweregrad: 3
Lösungsvorschlag Vorteil Nachteil
Statische Anleitung in Form
eines kurzen Texts, der
mithilfe von Screenshots
deutlich kennzeichnet, was in
der Umfrage verlangt wird.
Alle Schritte der Umfrage
werden dargestellt, sodass der
Nutzer über alle Funktionalitäten
im Klaren ist.
Anleitung wird der individuellen
Lesegeschwindigkeit des Nutzers
angepasst.
Gefahr eines Abbruchs des
Tests, da Nutzer nicht viel
Text lesen möchte.
Nutzer liest den Text nicht
und drückt auf „Weiter“.
Im ersten Bild der Animation
einen Hinweis darauf geben,
dass eine Anleitung in Form
einer Animation folgt.
Nutzer weiß, dass es sich um eine
Anleitung handelt.
Nutzer weiß, dass eine
Animation folgt.
Anleitung in Anleitung.
Nutzer schaut sich die
Animation trotz Hinweis
nicht an und drückt auf
„Weiter“.
Anleitung komplett
weglassen. Vorher in
Nutzertests überprüfen, ob sie
notwendig ist.
Zeitersparnis Gefahr eines Abbruchs des
Tests, da Nutzer überhaupt
nicht weiß, was von ihm
verlangt wird.
Tab. 2: Lösungsvorschläge: Anleitung
2. Scrollen: Weitere Nutzungsproblemen sind in Verbindung mit der Scrollfunktion des
Prototypens zu beobachten gewesen. Der Testleiter musste eine Testperson während der
Bearbeitung von Task 1 darauf hinweisen, dass auf der Seite gescrollt werden kann und
die Einladung zur Umfrage dann sichtbar wird. Die Testperson antwortete darauf „Das
49
fand ich jetzt aber unübersichtlich, dass man scrollen muss“. Hätte der Testleiter nicht
darauf hingewiesen, kann vermutet werden, dass die Testperson die Task 1 abgebrochen
und die Umfrage erst gar nicht gestartet hätte. Des Weiteren war zu beobachten, dass
50% der Testpersonen während der Aufgabenbearbeitung nicht scrollten, sodass die
Lösung der Aufgabe im oberen Bereich gesucht wurde und die komplette Darstellung der
mobilen Website, sowie die Funktionalitäten im unteren Bereich der Seite, diesen
Testpersonen nicht sichtbar war. Aufgrund des Eingreifens des Testleiters stellt das
Nicht-Scrollen und seine Auswirkungen auf den Test ein Abbruchsrisiko dar und wird
deshalb mit einem höheren Schweregrad bewertet.
Schweregrad: 2
Lösungsvorschlag: Da momentan nur Vermutungen über die Gründe für das mangelnde
Scrollverhalten gestellt werden können, ist in weiteren Nutzertests darauf zu achten,
wann die Testpersonen scrollen und warum sie dies eventuell nicht tun. Das
Scrollverhalten kann dann mit speziellen Mechanismen aufgezeichnet und ausgewertet
werden. Zudem sollte die Einladung zum Gewinnspiel eindeutiger platziert werden,
sodass sie dem Nutzer sofort nach Besuch der Startseite auffällt. Dies kann
beispielsweise durch ein Pop-Up-Fenster oder einem Fenster, das sich mit der
Scrollbewegung des Nutzers stätig mitbewegt, realisiert werden.
3. Hilfe & Überspringen: In der Beobachtung und der späteren Analyse der Ton- und
Videoaufnahmen ist aufgefallen, das keiner der Testpersonen den Hilfe- und
Überspringen-Button im unteren Bereich der drei Aufgaben wahrgenommen hat. Einige
Testpersonen konnten diese nicht wahrnehmen, weil sie erst gar nicht bis dorthin
gescrollt haben, allerdings haben die Testpersonen, für die die Buttons durch Scrollen
sichtbar waren, keine Reaktion auf diese gezeigt. Weder wurde ein Kommentar zu diesen
Funktionalitäten geäußert, noch hat nonverbales Verhalten, wie das Gestikulieren des
Fingers über den Buttons, darauf hingewiesen, dass die Hilfe- und Überspringen-Buttons
wahrgenommen wurden. Aufgrund der Nutzungsprobleme, die die Anleitung mit sich
gebracht hat, kann vermutet werden, dass diese beiden Funktionalitäten nicht erkannt
wurden, da die Testpersonen sich deren nicht bewusst waren.
Schweregrad: 2
Lösungsvorschlag Vorteil Nachteil
In der Anleitung deutlicher Nutzer, die die Anleitung Nutzer, die die Anleitung
50
auf diese Funktionalitäten
hinweisen.
lesen nehmen die
Funktionalitäten wahr und
ziehen sie eventuell in
Erwägung.
überspringen, wissen
weiterhin nicht, dass diese
Funktionalitäten existieren.
Zeit- bzw. Suchintensive
Aufgaben werden eher
übersprungen, als dass der
Nutzer sich mit diesen
beschäftig. Führt zu nicht
aussagekräftigen
Ergebnissen.
In weiteren Nutzertests eine
Task integrieren, die die
Nutzer dazu hinführt, die
Funktionalitäten zu bedienen
und beobachten, wie sie
darauf reagieren.
Klarheit über die
Notwendigkeit dieser
Funktionalitäten.
-
Hilfefunktion oberhalb der
Aufgabenbeschreibung in
Form eines Overlays
platzieren.
Überspringen-Button
ebenfalls oberhalb der
Aufgabenbeschreibung
platzieren.
Funktionalitäten sind für
den Nutzer immer sichtbar.
Anleitung muss nicht
präzise auf diese
Funktionalitäten eingehen.
Platzmangel im oberen
Bereich der
Aufgabenbereiche.
Nutzer tendieren schneller
dazu die Aufgabe zu
überspringen, als sich mit
dieser zu beschäftigen.
Tab.3: Lösungsvorschläge: Hilfe & Überspringen
4. Doppeltes Drücken: Eine Testperson hatte aufgrund von sehr langen Ladezeiten der
Seiten Probleme beim Drücken von der Darstellung der mobilen Website. Nachdem die
erste Aufgabe gelesen wurde und auf die Darstellung gedrückt wurde, hat sich die
nächste Seite nicht geladen und die Testperson drückte nochmals auf einen beliebigen
51
Part der Darstellung. Im späteren Tool kann ein wahlloses Drücken des Bereichs zu
falschen Interpretationen in der Analyse führen.
Schweregrad: 2
Lösungsvorschlag Vorteil Nachteil
Implementierung eines
Feedbacks, das dem Nutzer
in Form eines farblich
abgesetzten Kreises anzeigt,
wo er hingedrückt hat.
Nutzer kann sicher sein,
dass seine Aktion vom
Tool wahrgenommen
wurde.
Falsche Interpretationen in
der Analyse werden
nicht vermieden, da das
Feedback auch aufleuchtet,
wenn der Nutzer sich
verdrückt hat.
Implementierung eines
Bestätigungs-Buttons.
Nutzer kann seine Auswahl
bestätigen oder ändern.
Nutzer kann sicher sein,
dass seine Aktion vom Tool
wahrgenommen wurde.
Nutzer kann seine Auswahl
revidieren.
Analyse zeigt tatsächlich
gemeinten Taps der Nutzer.
Präzisere Ergebnisse.
Sinn von First-Click bzw.
Tap geht verloren.
Nutzer, die bewusst
gedrückt haben, ändern
eventuell nach
nochmaligem Betrachten
der Darstellung ihre
Meinung und der erste
Eindruck wird verworfen.
Tab. 4: Lösungsvorschläge: Doppeltes Drücken
5. Drop-Down: Eine Testperson hatte Probleme beim Anklicken des Drop-Down-Menüs in
der Nachbefragung. Die Person hat sich zwar nicht verbal dazu geäußert, in den
Videoaufnahmen und während der Beobachtung war sie allerdings sichtlich irritiert, dass
sich das Drop-Down-Menü trotz Anklicken nicht öffnete.
Schweregrad: 1
Lösungsvorschlag: Das Drop-Down-Menü sollte vergrößert werden, sodass es beim
ersten Anklicken sofort aufklappt.
6. Gewinnspiel: Eine Testpersonen hat erst zum Ende des Tests bemerkt, dass an einem
Gewinnspiel teilgenommen werden kann („Mensch, hätte ich mal gleich gewusst, dass es
’nen Gewinnspiel gibt“). Eine weitere Testperson äußerte in der Nachbefragung, dass sie
52
nur am Gewinnspiel teilgenommen hätte, wenn sie im vorhinein über die Art und Höhe
des Gewinns aufgeklärt worden wäre.
Schweregrad: 1
Lösungsvorschlag: Im Fenster, das zur Umfrage einlädt, sollte bereits die Art und die
Höhe des Gewinns genau beschrieben werden, sodass die Anzahl der teilnehmenden
Nutzer erhöht und die Motivation an der Umfrage teilzunehmen gesteigert werden kann.
7. Layout: Eine Testperson äußerte sich während des Nutzertests kritisch zum Layout des
Prototypens, indem sie sagte, es sei zu minimalistisch, nicht innovativ und hätte noch
Optimierungsbedarf.
Schweregrad: 0
Lösungsvorschlag: Nachdem der Prototyp hinsichtlich seiner Funktionalitäten optimiert
wurde, kann das Layout innovativer und ansprechender gestaltet werden.
Der letzte Schritt des Nutzertests bestand aus der Nachbefragung, welche zur Auswertung der
quantitativen Ergebnisse bezüglich der Wahrnehmung des Prototypens herangezogen wurde. Auf
die Frage, wie schwierig oder leicht die Testpersonen den Test empfunden haben, antworteten
sie auf einer Skala von -3 (sehr schwierig) bis +3 (sehr leicht) durchschnittlich mit +1,75
Punkten (s. Abb. 12).
-3 -2 -1 0 1 2 30
2
4
6
8
Wie schwierig oder leicht fanden Sie den Test ?
Abb. 12: Ergebnis der quantitativen Auswertung: Schwierigkeit des Tests
Trotz der oft missverstandenen oder missachteten Anleitung hatten die Testpersonen keine
Probleme, die Aufgaben zu lösen und bewerteten den Test somit insgesamt als positiv. Dies
deutet darauf hin, dass der Prototyp einfach zu verstehen und bedienen ist.
Des Weiteren wurde von den Testpersonen in der Nachbefragung ein User Experience
Questionnaire (UEQ) nach Laugwitz et al. (2008) ausgefüllt (s. B1). Der UEQ soll dabei helfen
53
das subjektive Empfinden der Testpersonen gegenüber dem Prototypen in harte und weiche
Usability-Kriterien einordnen zu können. Dabei werden fünf Dimensionen zur Bewertung der
Software betrachtet: Durchschaubarkeit, Stimulation, Effizient, Attraktivität und Originalität.
Das Ergebnis des UEQs zeigt, dass alle fünf Dimensionen im positiven Bereich liegen (s. Abb.
13) und der Prototyp somit durchschnittlich einen positiven Eindruck bei den Testpersonen
hinterlassen hat.
Attraktiv
ität
Durchsc
haubarkeit
Effizie
nz
Stimulatio
n
Origin
alität
-3
-2
-1
0
1
2
3
UQE
Abb. 13: Ergebnis der quantitativen Auswertung: User Experience Questionnaire
Zudem sind positive Äußerungen und Wünsche an den Prototypen zu vermerken. Die
Benutzerführung des Frontend-Prototypens wurde von sechs Testpersonen positiv
hervorgehoben, indem sie in der Nachbefragung äußerten, dass der Test „übersichtlich“,
„idiotensicher“ und „einfach“ gestaltet sei und „man wusste was von einem verlangt wird“. Die
einfache Gestaltung des Prototypens wird dadurch bestätigt, dass keine der Testpersonen den
Test abgebrochen oder den Testleiter während der Aufgabenbearbeitung um Hilfe gebeten hat.
Zudem wurde die kurze Testdauer von zwei Testpersonen als positiv bewertet, da der Test
dadurch „keinen großen Aufwand“ mit sich brachte und „schnell erledigt“ werden konnte. Die
durchschnittliche Dauer des eigentlichen Tests betrug 4,3 Minuten. Neben den positiven
Äußerungen, wurden auch Wünsche an den Prototypen gestellt. Eine Testperson hätte sich
gewünscht, dass der Prototyp einen Scroll-Balken auf der rechten Seite des Displays anzeigt,
sodass die Scroll-Funktion dem Nutzer offensichtlich erscheint. Eine weitere Testperson hätte
ein ansprechenderes Design vom Prototypen erwartet.
54
4. Schlussfolgerungen
Der wachsenden Stellenwert der Mobilität und die damit verbundenen Probleme konnten anhand
der Entwicklung und Evaluation eines Frontend-Prototypens für ein First-Click-Tool in dieser
Arbeit bestätigt werden. Die im empirischen Teil dieser Arbeit herausgearbeiteten
Herausforderungen der Mobilität wurden insbesondere während der Konzeptions- und
Entwicklungsphase des Prototypens deutlich und konnten nur mithilfe intensiver Brainstorming-
und Diskussionssitzungen bewältigt werden.
Aufgrund der steigenden Bedeutung mobiler Websites ist die Integration von Wünschen und
Erwartungen der Nutzer während der Entwicklungsphase unumgänglich. Iterative Prozesse
können Aufschluss über diese Bedürfnisse des Nutzers geben und das Produkt auf diese
zuschneiden. Vor allem die in dieser Arbeit vorgestellte Methode des First-Click-Tests bietet den
Entwicklern im Vergleich zu Labortests eine schnelle und kostengünstige Alternative des
Testens und eignet sich zudem mobile Websites auf ihre Benutzerfreundlichkeit zu testen, da
Nutzer den First-Click-Test schnell und überall durchführen können. Aufgrund der Reduktion
einer Desktopwebsite auf eine mobile Website, können insbesondere Nutzungsprobleme der
reduzierten Navigation auftreten. Dabei können First-Click-Tests Hinweise auf eine mangelhafte
Navigationsarchitektur geben und den Entwicklern somit hilfreiche Erkenntnisse diesbezüglich
liefern.
Die Evaluation des Frontend-Prototypens eines First-Click-Tools hat gute Ergebnisse erzielen
können und wurde von den Testpersonen durchweg positiv bewertet. Diese positiven Ergebnisse
bestätigen, dass First-Click-Tests im mobilen Kontext sehr gut zur Aufdeckung von
Nutzungsproblemen mobiler Websites geeignet sind. Trotz einer fehlinterpretierten bzw.
missachteten Anleitung, konnten alle Testpersonen die Aufgaben des First-Click-Tests
erfolgreich bearbeiten. Dies deutet darauf hin, dass dieser Tests verständlich und einfach ist.
Neben der Anleitung als schwerwiegendstes Usability-Problem des Prototypens, wurden
lediglich kosmetische Probleme, welche in weiteren Phasen schnell behoben werden können,
deutlich. Folgende Bereiche sollen in den nächsten iterativen Schritten des Prototypens
bearbeitet und erweitert werden:
55
Die in Kapitel 3.3 vorgestellten Lösungsvorschläge sollen betrachtet und in weiteren
Versionen des Prototypens umgesetzt werden. Die Lösungsvorschläge sollen dann in
weiteren Nutzertests evaluiert und auf Schwachstellen geprüft werden.
Insbesondere die mangelhafte Anleitung des Prototypens und das Scroll-Verhalten der
Nutzer soll in weiteren Nutzertests beobachtet werden, sodass entschieden werden kann,
ob eine Anleitung für den Durchführungsbereich des First-Click-Tools notwendig ist.
Die Validität, Reliabilität und Objektivität des First-Click-Tests sind in weiteren Studien
zu testen.
Des Weiteren können Fokusgruppen mit potentiellen Endnutzern Aufschluss über weitere
Wünsche, Bedürfnisse und Anmerkungen zum Prototypen geben.
Sobald eine finale Version des Frontend-Prototypens erstellt werden konnte und alle
notwendigen und erwünschten Funktionalitäten integriert wurden, kann ein innovatives
und ansprechendes Design des Durchführungsbereichs entworfen und getestet werden.
Der in dieser Arbeit entwickelte Prototyp bezieht sich lediglich auf den Frontend-
Bereich, also den Testteil, des First-Click-Tools. Um ein vollständiges Tool zu
veröffentlichen, müssen in weiteren iterativen Prozessen Prototypen zum Setup- und
Analysebereich des Tools entwickelt und getestet werden.
Zusammenfassend lässt sich sagen, dass mit der Entwicklung dieses Frontend-Prototypens ein
Grundgerüst für weitere iterative Prozesse zur Erstellung eines mobilen First-Click-Tools
erarbeitet werden konnte. Weitere Forschungen bezüglich von First-Click-Tests könnten sich
beispielsweise mit Motivationen, die die Nutzer dazu bewegen an einem First-Click-Test
teilzunehmen beschäftigen. Mit wachsenden Umsatzzahlen von Tablet-PCs wäre eine
Erweiterungen des First-Click-Tools auf diese Geräte interessant zu untersuchen. Insgesamt
sollten mit der rasanten Entwicklung der Mobilität und der damit verbundenen Bedeutung für
das Nutzungsverhalten neue Usability-Methoden konzipiert und herausgearbeitet werden.
56
5. Literaturverzeichnis
ACCENTURE (2012): Mobile Web Watch 2012; Special Edition: Germany, Austria, Switzerland.< http://www.accenture.com/SiteCollectionDocuments/PDF/Accenture-Study-Mobile-Web-Watch-Germany-Austria-Switzerland-EN.pdf> (Verifizierungsdatum: 18.02.2013)
BAILEY, Robert W.; WOLFSON, Cari A.; NALL, Janice; KOYANI, Sanjay (2009): Performance-Based Usability Testing: Metrics that have the Greatest Impact for Improving a System’s Usability. In: KUROSU, M. (Hrsg.): First international conference, HCD 2009, held as apart of HCI International 2009, San Diego, USA. Berlin: Springer.
BAILEY, Robert W. (2010): First click usability testing. < http://webusability.com/firstclick-usability-testing.html> (Verifizierungsdatum: 02.02.2013).
BEIER, Markus (2002): Usability. Nutzerfreundliches Web-Design. Berlin: Springer.
BIEH, Manuel (2008): Mobiles Webdesign. Konzeption, Gestaltung, Entwicklung; [Struktur, Design und Programmierung; Umsetzung mit (X)HTML, CSS und PHP; Standards und Best Practices]. 1. Aufl. Bonn: Galileo Press.
CORY, Timothy R. (2003): Brainstorming: Techniques for New Ideas. Lincoln, NE, USA: iUniverse.
ECK, Katja; HEUWING, Ben; WOMSER-HACKER, Christa (2013): Eigenen sich Tree-Tests und Firstclick-Tests für die nutzerzentrierte Evaluierung der Informationsarchitektur? Proceedings des 13. Internationalen Symposiums für Informationswissenschaften (ISI 2013); Potsdam, 19.-22. März 2013.
DUMAS, Joseph S.; REDISH, Janice C. (1999): A practical guide to Usability Testing. Bristol: Intellect.
FLING, Brian (2009): Mobile Design and Development: Practical concepts and techniques for creating mobile sites and web apps. Beijing u.a.: O’Reilly.
GINSBURG, Suzanne (2011): Designing the iPhone user experience. A user-centered approach to sketching and prototyping iPhone apps. Boston, Mass.; London: Addison-Wesley.
GO SMART (2012): Always in-touch. Studie zur Smartphone-Nutzung 2012. < http://www.ottogroup.com/media/docs/de/studien/go_smart.pdf> (Verifizierungsdatum: 01.03.2013).
HASSANEIN, Khaled; HEAD, Milena (2003): Ubiquitous Usability: Exploring Mobile Interfaces within the Context of a Theoretical Model. CAiSE Workshop, 2003.
ISO (2001): Software engineering – Product Quality - Part 1 (ISO 9126-1). International Organization for Standardization.
57
ISO (2009): Human-centred design for interactive systems. Ergonomics of human system interaction Part 210 (ISO 9241-210). International Organization for Standardization.
KALBACH, James (2008): Designing Web Navigation. Beijing u.a.: O’Reilly.
KNIGHT, Kayla (2011): Responsive Web Design: What it is and how to use it. < http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/> (Verifizierungsdatum: 13.02.2013)
KRANNICH, Dennis (2010): Mobile System Design: Herausforderungen, Anforderungen und Lösungsansätze für Design, Implementierung und Usability-Testing Mobiler Systeme. Norderstedt: Books on Demand.
MARCOTTE, Ethan (2011): Responsive web design. New York: A Book Apart.
MAURICE, Florence; REX, Patricia (2008): Jetzt lerne ich CSS. Webdesign mit Cascading Style Sheets. München: Markt + Technik. S.329 – 331.
MOBITHINKING (2012): Global mobile statistics 2012: all quality mobile marketing research, mobile Web stats, subscribers, ad revenue, usage, trends... .< http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats> (Verifizierungsdatum: 18.02.2013)
MONTADA, Jörg (2010): Navigationstypen. < http://www.montada.de/Website/navigation.html> (Verifizierungsdatum: 14.02.2013)
MRM Germany; TU Darmstadt (2011): Mobile & Attitudes – A Mobile Web User Typology. < http://www.mobile-attitudes.com> (Verifizierungsdatum: 23.02.2013).
MÜLLER-WILKEN, Stefan (2002): Mobile Geräte in verteilten Anwendungsumgebungen. Ein Integrationsansatz zwischen Abstraktion und Migration. Dissertation, Universität Hamburg, Fachbereich für Informatik.
NEO INSIGHT (2011): First-click testing finds and solves 3 common usability problems.< http://www.neoinsight.com/insights-articles/firstclick-tests-spot-3-problems.html> (Verifizierungsdatum: 01.03.2013)
NIELSEN, Jakob (1994): Usability Engineering. San Francisco: Morgan Kaufmann.
NIELSEN, Jakob (1995): Ten Usability Heuristics. < http://www.nngroup.com/articles/ten-usability-heuristics/> (Verifizierungsdatum: 19.01.2013).
REINHARD, Kerstin (o.J.): Navigationsgestaltung für Websites. < http://usability-toolkit.de/usability/navigationsgestaltung-fuer-websites/> (Verifizierungsdatum: 03.02.2013).
RYU, Hokyoung (2009): Mobile user interfaces analysis and design. A practitioner’s guide to designing user interfaces for mobile devices. New York: Nova Science Publishers.
SAFFER, Dan (2008): Designing Gestural Interfaces. Beijing u.a.: O’Reilly.
58
SAURO, Jeff (2011): Getting the First Click right. <http://www.measuringusability.com/blog/first-click.php> (Verifizierungsdatum: 01.03.2013)
SARODNICK, Florian; BRAU, Henning (2006): Methoden der Usability Evaluation: Wissenschaftliche Grundlagen und praktische Anwendung. Bern: Huber.
SCHWEIBENZ, Werner; THISSEN, Frank (2002): Qualität im Web: Benutzerfreundliche Webseiten durch Usability-Evaluation. Berlin: Springer.
SEWARD, Dan (2011): Designing Usable Mobile Websites. A Pratical Guide.< http://www.peakusability.com.au/__documents/pdf/peak_mobile_guidelines.pdf> (Verifizierungsdatum: 24.02.2013).
STONE, Debbie; JARRETT, Caroline; VOODROOFFE, Mark; MINOCHA, Shailey (2005): User Interface Design and Evaluation. San Francisco: Morgan Kaufmann.
PHAI, Dai (2011): Smartphone user study shows mobile movement under way.< http://googlemobileads.blogspot.de/2011/04/smartphone-user-study-shows-mobile.html> (Verifizierungsdatum: 19.02.2013)
VERMEEREN, A.; LAI-CHONG LAW, E.; ROTO, V.; OBRIST, M.; HOONHOUNT, J.; VÄÄNÄNEN-VAINIO-MATTILA, K. (2010): User Experience Evaluation Methods: Current State and Development Needs. In: NordiCHI ’10: Proceedings of the 6th Nordic Conference on Human-Computer Interaction: Extending Boundaries. Reykjakvik, Iceland: ACM.
W3C (2008): Mobile Web Best Practices 1.0. Basic Guidelines. < http://www.w3.org/TR/mobile-bp/> (Verifizierungsdatum: 04.03.2013).
WELLMAN, Stephen (2007): Google Lays out its Mobile Users Experience Strategy.< http://www.informationweek.com/mobility/business/google-lays-out-its-mobile-user-experien/229216268> (Verifizierungsdatum: 14.02.2013).
WROBLEWSKI, Luke (2011): Mobile First. New York: A Book Apart.
59
I. Abbildungsverzeichnis
Abbildung 1: Responsive Webdesign Starbucks
Abbildung 2: Beispiel einer schrittweisen Navigation (vgl. Ebay/m)
Abbildung 3: Beispiel einer nummerierten Navigation (vgl. Spiegel/m)
Abbildung 4: Beispiel einer Tree-Navigation (vgl. H&M/m)
Abbildung 5: Beispiel eines Akkordeon-Menüs (vgl. ESPN/m)
Abbildung 6: Skizzen des 1. Brainstormings
Abbildung 7: Der Frontend-Prototyp: Willkommenstext
Abbildung 8: Der Frontend-Prototyp: Anleitung
Abbildung 9: Der Frontend-Prototyp: Aufgabenbereich
Abbildung 10: Der Frontend-Prototyp: Nachbefragung
Abbildung 11: Der Frontend-Prototyp: Dankestext
Abbildung 12: Ergebnis der quantitativen Auswertung: Schwierigkeit des Tests
Abbildung 13: Ergebnis der quantitativen Auswertung: User Experience Questionnaire
60
II. Tabellenverzeichnis
Tabelle 1: Vor- und Nachteile des responsive Webdesigns
Tabelle 2: Lösungsvorschläge: Anleitung
Tabelle 3: Lösungsvorschläge: Hilfe & Überspringen
Tabelle 4: Lösungsvorschläge: Doppeltes Drücken
61
III. Anhang
A Konzeptionsphase
A1. Anforderungskatalog
Anforderung 1: Als allgemeine Anforderungen gilt die Demonstration eines Frontend-
Bereichs eines First-Click-Tools auf mobilen Endgeräten.
Anforderung 2: Dabei soll der Aufwand der Entwicklung für den Frontend-Prototypen
überschaubar sein, da ein zeitlicher Rahmen gegeben ist.
Anforderung 3: Der Prototyp für das Frontend soll interaktiv sein und ein Minimum an
Funktionen aufweisen.
Anforderung 4: Des Weiteren sollen Bedienaufwand und die Menütiefe minimal gehalten
werden.
Anforderung 5: Der Frontend-Prototyp soll an den mobilen Kontext angepasst werden,
sodass es von Nutzer und Betreiber von verschiedenen mobilen
Endgeräten aufgerufen und bedient werden kann.
Anforderung 6: Der Frontend-Prototyp soll über ein einheitliches und intuitives Design
verfügen, das den Nutzer durch den Test führt.
Anforderung 7: Der Frontend-Prototyp soll jederzeit und überall ausführbar sein.
Anforderung 8: Texte und Elemente sollen unter verschiedenen Lichtverhältnissen
erkennbar sein.
Anforderung 9: Die Dauer eines Testdurchlaufs soll auf maximal 6 Minuten beschränkt
werden.
Anforderung 10: Die Umfrage sollte sich für die Testperson lohnen. Eine „Belohnung“ wird
im Gegenzug verlangt.
Anforderung 11: In einer Statusanzeige oben rechts soll der Tester den aktuellen Fortschritt
des Testdurchlaufs erkennen können. Damit die Anzeige schnell erfasst
werden kann, soll sie optisch dem Design des Tools angepasst werden,
darf jedoch nicht irritierend wirken.
Anforderung 12: Der Test soll mit einem Willkommens-, Anleitungs- und Dankestext
umrahmt werden, sodass der Nutzer sich zu keiner Zeit verloren sieht, ihm
hilfreiche Informationen bereitgestellt werden und er durch den Test
geführt wird.
62
Anforderung 13: Der Test soll jederzeit von der Testperson abgebrochen werden können.
Hierzu soll ein „Zurück zur Website“-Button unten eingefügt werden.
Anforderung 14: Fühlt der Nutzer sich überfordert oder hat Verständnisschwierigkeiten, will
den Test aber nicht abbrechen, soll ein „Überspringen“-Button in den
einzelnen Tasks eingebaut werden.
Anforderung 15: Das Tool soll ein einheitliches Design aufzeigen. Buttons und Design
sollen während des gesamten Tests die gleiche Funktion und das gleiche
Design haben.
Anforderung 16: Die Aufgabenbeschreibung soll in den einzelnen Aufgaben jederzeit
sichtbar sein.
Anforderung 17: Die Anzahl der Textfelder soll gering gehalten werden.
Eingabemöglichkeiten des Nutzers sollen eher durch das drücken von
Radio-Buttons oder Drop-Down-Menüs erfolgen.
Anforderung 18: Der Test soll minimalistisch und schlicht gestaltet sein. Das Design soll
jedoch ansprechend wirken.
Anforderung 19: Ein „Help“-Button, der unten links platziert werden soll, soll den
Anleitungstext anzeigen.
63
A2. Personas A2.1 Persona „Der Profi“
A2.2 Persona „Die Erfahrene“
64
A2.3 Persona „Die Unerfahrene“
65
A3. Heuristische Evaluation von drei First-Click-Tools
Heuristik Chalkmark ClickTest Usabilla
Visibility of system status
Pro: Fortschritt der Tasks wird angezeigt (Aufgabe 1 von 2)
Contra: Fortschritt im Pre- und Posttest nicht angezeigt.
Contra: Keine Fortschrittsanzeige des gesamten Tests.
Contra: Keine Fortschrittsanzeige.
Pro: Fortschritt der Tasks wird angezeigt (z.B. 1/2)
Contra: Keine Fortschrittsanzeige des gesamten Tests.
Match between system and real world
Pro: Willkommens-, Anleitungs- und Dankestext vorhanden.
Pro: Sprachauswahl
Pro: Anleitungs- und Dankestext vorhanden
Contra: Kein Begrüßungstext. Fängt sofort mit der Anleitung an.
Contra: Keine Sprachauswahl, nur Englisch
Pro: Anleitungs- und Dankestext vorhanden
Pro: Sprachauswahl
Contra: Kein Begrüßungstext. Fängt sofort mit der Anleitung an.
User control and freedom
Pro: Nutzer hat die Möglichkeit die Tasks zu überspringen.
Contra: Test kann nur über den Browser beendet werden.
Contra: Nutzer kann nicht zurück navigieren.
Pro: Nutzer hat die Möglichkeit die Tasks zu überspringen.
Contra: Test kann nur über den Browser beendet werden.
Contra: Nutzer kann nicht zurück navigieren.
Pro: Nutzer hat die Möglichkeit die Tasks zu überspringen.
Contra: Test kann nur über den Browser beendet werden.
Contra: Nutzer kann nicht zurück navigieren.
Consistency and standards
Pro: konsistentes Design
Pro: Logo der Seite bzw. des Tools immer präsent
Pro: Checkbox wird angehakt
Pro: konsistentes Design
Pro: Logo der Seite bzw. des Tools immer präsent
Pro: konsistentes Design
Contra: Logo der Seite bzw. des Tools nicht präsent
66
Error prevention Pro: Keine Fehlermeldung
Pro: Keine Fehlermeldung
Pro: Keine Fehlermeldung
Recognition rather than recall
Pro: Task immer einsehbar
Pro: Task vor Anzeige des Screenshots einsehbar
Pro: Nutzer kann Task jederzeit durch „Start“-Button starten
Pro: Task immer einsehbar
Pro: Task vor Anzeige des Screenshots einsehbar
Pro: Nutzer kann Task jederzeit durch „Show image“-Button starten
Pro: Task immer einsehbar
Pro: Task vor Anzeige des Screenshots einsehbar
Pro: Nutzer kann Task jederzeit durch „Start“-Button starten
Flexibility and efficiency of use
Pro: Es wird versucht auf Textfelder zu verzichten
Pro: Es wird versucht auf Textfelder zu verzichten
Pro: Es wird versucht auf Textfelder zu verzichten
Aesthetic and minimalist design
Pro: Design minimalistisch gehalten
Contra: Grüner Rahmen kann irritierend wirken, da er sehr viel Platz einnimmt
Pro: Design minimalistisch gehalten
Contra: Werbebanner unter dem Bild wirkt irritierend. Nutzer könnte aus Versehen darauf klicken.
Pro: Design minimalistisch gehalten
Contra: Design wirkt durch viele Grau konservativ
Help users recognize, diagnose, and recover from errors
Pro: Keine Fehlermeldung
Pro: Keine Fehlermeldung
Pro: Keine Fehlermeldung
Help and documentation
Contra: Keine Hilfefunktion während des Tests
Contra: Keine Informationen über Datensicherheit
Contra: Keine Hilfefunktion während des Tests
Contra: Keine Informationen über Datensicherheit
Contra: Keine Hilfefunktion während des Tests
Contra: Keine Informationen über Datensicherheit
67
A4. Der Prototyp
68
69
70
71
72
Seite im Fall einer GewinnspielteilnahmeSeite im Fall eines Abbruchs
73
Seite, die nach Betätigen des Hilfe-Buttons angezeigt wird
Prototyp online aufrufbar unter: share.axure.com/ACT249/layer.html
74
B. Evaluationsphase
B1. Testleitfaden
75
76
77
78
79
80
81
B2. Skalierung B2.1 Screenshot Samsung Galaxy 3
82
B2.2 Screenshot App
83
B2.3 Screenshot Browser
84
B3. Quantitative Ergebnisse
85
18 - 25 Jahre 25 - 30 Jahre 30 - 40 Jahre012345678
Alter
Soziale Netzwerke
Kommunikation
Online-Shopping
Informationsrecherche
Apps
0 1 2 3 4 5 6 7 8
In welchen Bereichen nutzen Sie das mobile Internet?
Ja Nein 0
1
2
3
4
5
6
7
8
Haben Sie schon mal an einer On-line-Umfrage teilgenommen?
86
täglich 3 - 5 wöchtentlich seltener 0
1
2
3
4
5
6
7
8
Wie oft greifen Sie von Ihrem Smartphone auf das Internet zu?
Ja Nein0
1
2
3
4
5
6
7
8
Hätten Sie an der Umfrage teilgenommen?
-3 -2 -1 0 1 2 30
1
2
3
4
5
6
7
8
Wie schwierig oder leicht fanden Sie den Test ?
87
Attraktivität Durchschaubarkeit Effizienz Stimulation Originalität
-3
-2
-1
0
1
2
3
UQE
Ja Nein0
1
2
3
4
5
6
7
8
Hätten Sie am Gewinnspiel teilgenommen?
a - 320 skalliert b - app-skalliert c - browser-skalliert 0
1
2
3
4
5
6
7
8
Welches Bild spricht Sie spontan an?
88
Eigenständigkeitserklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Die Stellen der Arbeit, die dem Wortlaut oder dem Sinn nach anderen Werken (dazu zählen auch Internetquellen) entnommen sind, wurden unter Angabe der Quelle kenntlich gemacht.
Vienenburg, 07.03.2013 Jennifer Machura
89