Posts mit dem Label UX werden angezeigt. Alle Posts anzeigen
Posts mit dem Label UX werden angezeigt. Alle Posts anzeigen

2014-10-14

Bevormunde nie deine Nutzer

In der vergangenen Ausgabe der Heise-Zeitschrift "Technology Review" wird ein Zitat von mir wie folgt verwendet (S. 79). Es bezieht sich auf die Evaluation unserer Smarthome-Musterwohnung: 
"[...] Umgekehrt kam „jede Form der Bevormundung durch Technik schlecht an“. Auf wenig Gegenliebe stieß beispielsweise ein Vorhang, der sich nur elektronisch, aber nicht von Hand öffnen ließ."
Anfang letzter Woche hat Deutschlandradio Kultur den Radiobeitrag "Wenn der Mitbewohner Technik heißt" ausgestrahlt. Der Beitrag begleitete unsere technisch unerfahrenste Test-Bewohnerin während der Evaluation unserer Musterwohnung und zeigt eindeutig wie wichtig es ist, dass Technik nicht bevormunden darf, bzw. das neue Möglichkeiten bekannter Komponenten auch wie gewohnt benutzbar sein müssen. Bei den Gardinen/Vorhängen war eine manuelle Bedienung leider nicht realisierbar und genau das war ein Grund, warum bei dieser Probandin die Stimmung kippte und sie sich „gegen das System als Ganzes" entschieden hat.

Aus Evaluationssicht hat diese Bewohnerin - auch wenn die Lösung für sie nicht in Frage kommt - sehr wertvolle Erkenntnisse geliefert.

Mehr zum Projekt "Vernetztes Wohnen im Quartier" und der Evaluation auf der Projekt-Website.

Zum Thema Demenz: Frau Marquard hat ihre Erfahrungen mit der Demenz ihres Mannes in einem Buch festgehalten, welches vor kurzem erschienen ist. Es liest sich, anekdotisch, sehr gut.

Das Vorhaben „Vernetztes Wohnen im Quartier – zukunftsfähige Versorgung älterer Menschen in Hamburg“ wird gefördert von der Europäischen Union Europäischer Fonds für Regionale Entwicklung Investition in Ihre Zukunft und der Freien und Hansestadt Hamburg (Behörde für Gesundheit und Verbraucherschutz). 

2012-08-17

Designing Games for Non-Gamers

Dennis Paiz-Ramirez, Sarah Chu, Allison Salmon, and Belinda Gutierrez in User Experience Magazine: Volume 10, Issue 4, 2011


Tutorials: Too Much or Not Enough?

They tested their prototype of a real life simulation game with gamers an non-gamers and a pattern began to emerge:
Ann, the more experienced gamer, was willing to explore; Betty [familiar with computers but with little video game experience] was hesitant to click on anything before confirming it was the right action. [...] We learned that the tutorial should be explicit about what players can do in the game and should explain what happens when a player performs a game action. We also need to allow users to skip the tutorial and explore the game if they feel comfortable doing so.
I think it is import to tell the user, that she can "skip the tutorial and explore the game [AND can] feel comfortable doing so". -- Whatever tell means in this context. -- Otherwise the user might not trust that she can explore it without reading through all the tutorial stuff.


Conventions: Is That Supposed to Mean Something?

They have grayed-out non-clickable buttons, but:
it wasn't enough to follow web standards, especially when the target audience has little familiarity with digital media.
So they decided to not display buttons until they are introduced.


Content: Missing the Point

Too many feature, that are not directly connected to the main goal of the game, distracted the user from the main goal. Also, the head-up display became overcomplicated.
Featuritis -- who does not know the problem, but everybody runs into it from time to time -- everybody!


2012-08-06

Josh Clark - Buttons are a Hack


The New Rules of Designing for Touch - BD Conf, Sept 2011 (vimeo video)

Description:
Fingers and thumbs turn design conventions on their head. Touchscreen interfaces create ergonomic, contextual, and even emotional demands that are unfamiliar to desktop designers. Find out why our beloved desktop windows, buttons, and widgets are weak replacements for manipulating content directly, and learn practical principles for designing mobile interfaces that are both more fun and more intuitive. Along the way, discover why buttons are a hack, how to develop your gesture vocabulary, and why toys and toddlers provide eye-opening lessons in this new style of design.

My notes from the talk:


  • Fitt's Law
  • Let people be lazy
  • Step 1: Gestures as shortcuts for buttons
    • How to teach gestures?
    • How to find a uniform set of gestures?
  • Buttons are (visual) abstraction - they work in the distance - they are workarounds
  • Norman's new book: Living with complexity
    • Social understanding is not synchronized
    • UI conventions are social construction
  • Labels help, but better doesn't need them at all
    • Don't touch a button/label: Tap the content
  • Instructions at start of the app -> NO - no one wants to learn HOW to use before WHY to use ??
    • Nature itself doesn't have labels or instructions - but is an complex interface
  • embrace the UI metaphor you use
  • Play more video games to learn:
    • Coaching: time by time, don't overdo it, show feature hints when needed
    • Leveling up: Pause action, show how to use new feature, continue AFTER user SHOWS she has learned -> so divide your app into levels
    • Power ups: gestures are the keyboard shortcuts of touch, but they are hidden, so tell your users
  • Uzu (app): multitouch gestures: ten fingers - ten modes - no buttons or labels at all
  • no leadership yet for finding uniform set of gestures


2012-07-06

Die Zukunft von Mobile

Die Zukunft von Mobile heißt nicht Phone oder Tablet;
die Zukunft von Mobile bedeutet, sich diverser Umgebungen bewusst zu sein.
(Menschen lassen sich nicht auf Finger und Augen reduzieren ;)

Bildschirme sind billig, sie werden überall sein;
Personal Devices brauchen eine einheitliche Schnittstelle, dann können wir unsere Aufgaben über mehrere Bildschirme verteilen. Was ist das für ein Nutzererlebnis? Frage an die User Experience Spezialisten.

Mobile und Cloud Computing: Toy Story wurde in 800.000 Rechner-Stunden erzeugt - über die Cloud ginge das in fünf Minuten.

Die Interaktion zwischen Personal- und Mobile Devices bringt völlig neue User Experience; Beispiel: Nike plus.


Offene Punkte für die Zukunft von Mobile: 

  • Design, Hardware und Software müssen eng zusammenspielen.
  • Umdenken: Geräte sollen auf Menschen reagieren, nicht umgekehrt.
  • Neue Entwicklungsprozesse: Dokumentation, Produktion und Nutzung liegen verdammt eng beieinander; es geht nicht mehr um Bürosoftware, die man später den Mitarbeitern einfach vorsetzt.
  • Orts- und kontextabhängige Nutzung rückt noch weiter in den Vordergrund. 
  • Computer müssen Content filtern und verarbeiten und dürfen nur relevanten Content an den Nutzer liefern. Ansonsten ist die permanente Anwesenheit von Technik nicht akzeptabel.




In his opening keynote at the Design for Mobile conference in Chicago IL,. Jonathan Brill discussed several future scenarios for mobile user experience and their potential.


What Brill is focused on now: Multi-display/device interaction, 3D and gestural interfaces, glasses 3D display, Radios in things besides phones, positional and visual search.
Voice recognition, roll-up displays, and mesh networks have been “three years away” for a long time now.
When investigating, predicting, developing new technologies, laughter and delight signal a business opportunity.



2012-07-01

Mobile & UX


Kleine Auszüge aus Jared Spool Mobile & UX: Inside the Eye of the Perfect Storm (Video) auf der Mobilism 2011


Sturgeon's Law


Warum sind 90 Prozent aller Mobile-Anwendungen Mist?
90 Prozent von allem ist Mist!


Marktreife


Das generelle Erlebnis ist wichtiger als neue Funktionen. 
Nutzer sind von einfachen Lösungen begeistert.


Das Kano Model


Kano fragt: 
Wann lohnt es sich, den Nutzer glücklich zu machen?
Das Kano-Model verrät, wann etwas ein Highlight ist und wann etwas zu den Grunderwartungen gehört.

Eine Achse beschreibt die User-Zufriedenheit von entzückend bis frustrierend, die andere die nötigen Kosten. 
Es spielt bei allen Bemühungen aber keine Rolle wie weit man geht, wenn die Grunderwartungen nicht erfüllt werden - diese Feature müssen IMMER vorhanden sein. Für ein langlebiges Produkt ist hierbei zu bedenken, dass die Grunderwartungen über die Zeit zunehmen. Was heute noch entzückt, kann zum Beispiel so hilfreich sein, dass es in Zukunft schon  zu einer erwarteten Basisfunktion wird.


"The Perfect Storm"


UX-Teams aufzubauen, die in diesem Rahmen arbeiten, ist sehr schwierig. Teams, die herausragende User Experience bauen möchten, brauchen die verschiedensten Fähigkeiten wie zum Beispiel Schreiben, Informatins-Architekturen, Design-Prozess-Management, User Research Techniken. Darüber hinaus muss es ein Verständnis der verwendeten Technologie, ROI, Soziale Netze, Marketing, Analytics, Geschäftswissen, Story-Telling und weiterem geben.


Ziel ist es, in Sturgeon's Law zu investieren und sich auf das Nutzererlebnis zu konzentrieren, statt an Technologie und Features zu denken.
Basisfunktionen müssen erfüllt werden und darüber hinaus sollten einige Highlights eingebaut werden.



2012-06-20

Nicht immer Responsive Web Design


Responsive Web Design ist in aller Munde und wird derzeit sehr stark gehyped. Auch Luke W ist Befürworter von Responsive Web Design - dennoch hatte er gute Gründe für die mobile Variante von Bagcheck ein eigenes Interface zu entwickeln. Diese Gründe liefert er in seinem Blog-Post "Why Separate Mobile & Desktop Web Pages?", die ich hier kurz aufgreifen möchte:

Oberstes Gebot bei dem Projekt war Site Performance und Geschwindigkeit. Unter diesen Prämissen - und der generellen Philosopie: "Nur so viel wie nötig" - findet Luke vier Gründe:


Sourcecode Reihenfolge


Der Kern von Responsive Web Design ist die Auslieferung einer einzigen (HTML-) Website-Variante an alle Geräte. Die Anzeige des Contents passt sich dann entsprechend den Möglichkeiten des Gerätes an (in der Regel durch CSS gesteuert).

HTML Markup hat aber eine Reihenfolge, die bestimmt, in welcher Reihenfolge was gerendert wird. Diese kann natürlich mittels JavaScript manipuliert werden - aber dies zuverlässig für alle Geräte umzusetzen ist eine herausfordernde Aufgabe.

Ein einfaches Beispiel ist ein Site-weites Navigationsmenü. Während es auf Desktop-Größen in der Regel oben angeordnet ist, ist es für mobile Geräte, insbesondere in Smartphone Größe üblich, diese Menüs ans Ende der Seite zu rendern.


Medien


Responsive Web Design setzt sich auch mit Medien auseinander. Grafiken und Videos werden auf kleineren Displays kleiner dargestellt. Allerdings ist skalieren hier nicht unbedingt die beste Wahl. Erstens werden dabei unnötig Große Dateien übertragen (gerade an mobile Geräte mit evtl. nicht besonders schneller Anbindung). 
Anm.: Hier kommt zum Beispiel auch die iOS Retina--Display Diskussion ins Gespräch, da es sich für diese Geräte anbietet - genügend Bandbreite vorausgesetzt - hochauflösende Grafiken nachzuladen. (Siehe z.B. What the New iPad’s Retina Display Means for Web Developers. - Danke für den Tipp Moritz)

Zweitens kann es durchaus sinnvoll sein, dass man die Medien für unterschiedliche Display-Größen unterschiedlich aufbereitet: Große Grafiken mit vielen Details vs. kleine Grafiken mit weniger Details, also einem anders gewählten Ausschnitt.


URL-Struktur


Anm. vorab: Wie ich in Mobile und Content oder besser Content vs. Mobile? geschrieben habe, gibt es nur ein Web und ein und der selbe Content sollte auch unter ein und der selben URL zu erreichen sein. Aber:

Es gibt Situationen, in denen eine eigene URL-Struktur für kleinere Screens durchaus Sinn ergibt: Luke nennt als Beispiel eine Seite mit User-Content, Kommentaren dazu, Updates und "Likes". Dies passt alles zusammen gut auf eine Desktop-Seite und ist zum Beispiel unter der URL bagcheck.com/bag/7811 zu erreichen. Für kleinere Bildschirme ist es aber durchaus sinnvoll, einige der Informationen auf Unterseiten auszulagern, die dann unter den URLs bagcheck.com/bag/7811/updates, bagcheck.com/bag/7811/comments und bagcheck.com/bag/7811/likes zu erreichen sind.


Anwendungsdesign


Ein letzter entscheidender Punkt, der zu bedenken ist, ist folgender: Auf kleinen Displays kann es sinnvoll sein, längere Tasks von einer Seite auf mehrere zu verteilen.



2012-06-15

Drei wesentliche Attribute eines UX-Teams

Jared Spool über die drei wesentlichen Attribute eines effektiven UX-Teams in Dawning of the Age of Experience:

1. Vision

Kann jeder aus dem Team beschreiben, wie es sich anfühlen wird, wenn man ihr Produkt in fünf Jahren verwendet?

2. Feedback

Es muss Teammitglieder geben, die die Zielgruppe persönlich in direkter Interaktion mit dem Produkt erlebt haben. Minimal-Ziel: 2 Stunden Userbeobachtung jeweils innerhalb von sechs Wochen. Die besten Firmen machen dies wöchentlich.

3. Kultur

Werden Mitarbeiter für Designfehler belohnt? Jeder Fehler birgt die Möglichkeit etwas zu lernen: Was haben wir über unsere Nutzer gelernt? Über unser Produkt? Über uns selbst?


2012-06-12

Keep it Simple. At First. - Designing spielbasierte Tools für Kinder

Sarah Clue und Constance Steinkuehler beschreiben in "UX User Experience, Volume 10, Issue 1, 2011" (S.28ff), wie die World of Worcraft Entwickler es geschafft haben, das Interface so zu gestalten, dass es für Einsteiger einfach und übersichtlich ist und für erfahrene Spieler die notwendige Komplexität bietet, um alle benötigten Funktionen abzubilden.

  1. Das Interface ist beim Einstieg in das Spiel einfach gehalten und bietet nur die notwendigsten Funktionen. So können die Spieler am Anfang zum Beispiel einfaches Herumlaufen üben.

  2. Informationen und Funktionen werden erst nach und nach eingeführt - wenn der Spieler an entsprechende Stellen kommt, an denen er sie benötigt.

  3. Die Menge an geschriebenen Informationen ist auf ein Minimum reduziert. Es würde den Spieler eher stören, wenn am Anfang jede Minute ein neues Tutorial-Fenster aufpoppen würde.

  4. Individualisierung des Interfaces ist möglich: Spieler können selbst Interface-Addons entwickeln und installieren - je nach Bedarf und individuellem Gameplay. Dies optimiert nicht nur die Effizienz beim Spielen sondern fördert gleichzeitig auch die Community.


2012-06-05

Die Sieben Tödlichen Mythen über Mobile

Gestern Abend gab es zwei sehr interessante Vorträge bei der Interaction Design Association Hamburg.

Josh Clark, author of "Tapworthy: Designing Great iPhone Apps" and "Best iPhone Apps", and Karen McGrane, author of "Content Strategy for Mobile," (coming in 2013), will each give a thirty minutes presentation talking about mobile usage, design and content creation.

Josh Clark (http://www.globalmoxie.com/) hat über "The Seven Deadly Myths of Mobile" gesprochen. Anschließend Karen McGrane (http://www.karenmcgrane.com/) über „Adapting Ourselves to Adaptive Content“.

Zunächst zu den Sieben Tödlichen Mythen über Mobile:

A set of persistent myths are driving the development of mobile experiences that frustrate more than delight. "Info snacking." "The distracted, rushed mobile user." Those behaviors don't always, or even usually, exist, yet too often we design solely for those contexts, creating mobile apps as lite versions of their desktop counterparts. Instead, mobile apps should almost always do MORE than their desktop counterparts. Josh Clark explains the difficult craft of designing simple interfaces for complex mobile apps, sharing techniques for future-friendly mobile efforts and, along the way, debunking seven stubborn mobile myths.

Mythos #1: Mobile-Users sind immer in Eile - sind quasi IMMER auf dem Weg zum Bus


Ebay verkauft täglich Autos über ihre mobile App, also gibt es wohl doch User, die am Smartphone sitzen und Zeit haben sich mit dem Content in Ruhe zu beschäftigen.

  • 28% der mobile Users in den USA nutzen (fast) ausschließlich mobile Geräte. 
  • 11%, wenn man nur erwachsene User betrachtet.

Mobile != In Eile


Mythos #2: Mobile = Weniger


Schon mal auf einer smartphone-optimierten Website gewesen, deren Content sich perfekt an die Displaygröße angepasst hat? Dann aber den entscheidenden Menüpunkt nicht gefunden (weil der Anbieter der Meinung war, dass die Mobilen-User sich nicht dafür interessieren)? Ganz unten findet man ja meist einen Link „Full Desktop Version“. Dann hat man zwar eine nicht leserliche minikleine Seite auf dem Screen, aber irgendwie bekommt man es schon hin - durch vieles scrollen und zoomen - dann doch den Menüpunkt zu finden, zu bedienen und schwupp, nur wenige genervte Minuten später hat man endlich die Infos, die man gleich hätte haben können, wenn der Anbieter den Menüpunkt einfach auch in die mobile Version der Website gepackt hätte.

Der Fehler ist, dass Kontext und Vorsatz häufig verwechselt werden!
Der Mobile-User kann ja auch auf der Couch sitzen und nur zu faul sein, sich seinen Laptop zu holen oder ins Arbeitszimmer zu gehen.
Für uns heißt das, dass die mobile Version eines Services immer den vollen Umfang bieten sollte.

Mobile != Weniger


Mythos #3: Komplexität vermeiden und
Mythos #4: Extra Taps vermeiden


Die Regenschirm App verbirgt die Komplexität der Wettervorhersage in die einfache Antwort: „Brauche ich heute einen Schirm oder nicht?“ Sie kennen ihre User, denn dem Wetterinteressierten wären das zu wenige Informationen. Der Wetterexperte möchte eine komplexe App mit diversen Wetterdaten. Diese sollten ihm auch geboten werden. Komplexität sollte also nicht zwingend vermieden werden - sollte nicht als Gegenteil von Einfachheit verstanden werden. Ein komplexer Service kann ein einfaches Interface haben. Früher, als Webseiten noch Minuten zum Laden brauchten, war es wichtig, den User mit möglichst wenig Klicks zum Ziel zu bringen. Heute gilt dies nicht mehr. (Anm.: Ich habe auch mal gelesen, dass mehrere Klicks bei denen der User genau weiß, was sich hinter dem Link verbirgt, weniger störend empfunden werden, als ein einzelner Klick, bei dem der User dies nicht weiß. Wenn die iOS Human Interface Guidelines von Apple sogar davon sprechen, dass Scrollen auf einem Touch-Device zur positiven User Experience gehören, dann kann ein Tab wohl kaum störend sein.)

Das Interface eines Services sollte Komplexität in der Form verbergen aber bereitstellen, in der ein User an ein Problem herangeht. Frage -> Antwort -> Frage -> Antwort: Der User hat eine Frage: „Wie wird das Wetter die Tage?“ Die App antwortet: „sonnig“. Frage: „Wie wird das Wetter morgen genau im Verlaufe des Tages?“ Tab auf die zusammenfassende Vorhersage für morgen. Als Antwort wird dann der genaue Wetterverlauf gezeigt. Kaum ein User braucht wohl bei einer 5-Tages-Vorhersage bereits stundengenaue Werte.

Wenn jeder Tab neue und zufriedenstellende Informationen auf die aktuell gestellte Frage bietet, ist jeder Tab ein Gewinn für den User und trägt zur positiven User Experience bei.

Komplex != Kompliziert
Tab-Qualität sollte also vor Tab-Quantität stehen.


Mythos #5: Man braucht eine Mobile-Website


Es gibt so viele verschiedene Bildschirm-Formate im mobilen Bereich. Wie viel Aufwand will man betreiben, um all diesen Auflösungen gerecht zu werden? Und was ist mit den diversen anderen Kanälen? Warum nicht in ein paar Jahren auch auf dem TV stattfinden? Oder Radio. Sprachausgabe und -erkennung - Zukunft? Noch ist Apples Siri beta, aber bald wird es wohl Standard sein.

„Es gibt kein ,mobiles' Web.“ Es gibt nur Content. Einmal generierter Content muss für alle Kanäle passen. Content First, nicht Mobile First.

URL: Uniform Resource Locator (dt.: einheitlicher Quellenanzeiger). Schon mal einen Link auf mobile.mySite.com/... zugeschickt bekommen und auf einem großen Monitor geöffnet?
„Es gibt nur ein Web.“


Mythos #6: Mobile = App


„Eine App ist keine Strategie, es ist einfach nur eine App“ - ein Container!
Ein Produkt an sich ist meist nur Content.
Bruce Lee sagte einmal:
Wenn man Wasser in eine Tasse gießt, wird es zur Tasse. Gießt man Wasser in eine Flasche, wird es zur Flasche. Gießt man Wasser in eine Teekanne, wird es zur Teekanne.

Das Ziel: Ein Content, auf allen Geräten, immer synchron.


Mythos #7: CMS und API ist nur für Datenbank-Nerds


Ziel ist es nicht, das Design zu überdenken, wie der Content wo dargestellt werden soll. Ziel ist es, das Anlegen und die Speicherung des Contents zu überdenken. Wenn man alles richtig macht, dann ist Metadaten angereicherter Content, der über sinnvolle Schnittstellen angeboten wird, in jeglicher Form nutzbar - völlig unabhängig vom Präsentations-Layer.

Content as a Service


Dies war auch die Kernaussage von Karen McGrane über die Frage, wie wir uns anpassen müssen, um in der Zeit des „anpassbaren Contents“ Schritt halten zu können.


For years, we've been telling designers: the web is not print. You can't have pixel-perfect layouts. You can't determine how your site will look in every browser, on every platform, on every device. We taught designers to cede control, think in systems, embrace web standards. So why are we still letting content authors plan for where their content will "live" on a web page? Why do we give in when they demand a WYSIWYG text editor that works "just like Microsoft Word"? Worst of all, why do we waste time and money creating and recreating content instead of planning for content reuse? What worked for the desktop web simply won't work for mobile. As our design and development processes evolve, our content workflow has to keep up. Karen will talk about how we have to adapt to creating more flexible content.

Präsentations-unabhängiger, strukturierter und mit Metadaten angereicherter Content als Ausgangslage, um schnell auf allen Plattformen stattfinden zu können.
Von „Create Ones, Puplish Everywhere“ spannte sie den Bogen zu „Publish Once, Distribute Everywhere“. Umdenken ist gefragt.


Vielen Dank auch an FORK als Veranstalter.


2010-11-12

World Usability Day 2010 Hamburg (WUD2010HH)

Gestern war der World Usability Day 2010 - unter anderem auch in Hamburg.

In diesem Jahr fand die Konferenz nach dem BarCamp Prinzip statt. Da es nicht so viele Teilnehmer wie im letzten Jahr waren, vermute ich, dass dieses Konzept nicht so viele Leute anlockt - da man im Vorfeld nicht weiß über was geredet/diskutiert wird. Dennoch fand ich das Prinzip sehr gut, denn die Diskussionsrunden, die am Nachmittag stattfanden, waren sehr konstruktiv und informativ - Masse ist eben nicht Klasse.

Vielen Dank auch an das Orga-Team, das fleißig für den ganzen Aufbau und für Speis und Trank gesorgt hat.

Am Vormittag habe ich am Workshop "Living Place Hamburg: Neue Möglichkeiten zur benutzerzentrierten Entwicklung" teilgenommen. Workshop trifft es an dieser Stelle vielleicht nicht direkt, aber es war dennoch außerordentlich interessant: Kai von Luck hat die diversen Projekte der HAW Hamburg aus seinem Bereich vorgestellt:

  • Creative Lab: Projekte mit Künstlern
  • Development Lab: Business CSCW und Enterprise 2.0
  • Usability Lab: Usability Studien


Den Living Place Hamburg haben wir uns dann vor Ort angeschaut. Eine Ein-Zimmer-Wohnung als Usability Lab. Hier kann man untersuchen, wie sich Mensch und Technik im Ambiguous Computing verhalten.

Am Nachmittag habe ich mich an folgenden Diskussionen beteiligt:

  • Können theoretische Grundlagen aus der Psychologie für UX-Design dienen (und wie implementiert man dies)?
  • Agiles User Centered Design - Herausforderungen, Erfahrungen, Kompromisse, Lösungen.
  • Check-Ins: Wofür und warum.

Bilder von dem Event gibt es (bald?) bei flickr (WUD2010HH) und natürlich habe ich mich auch wieder am Micro-Sponsoring beteiligt.

In den folgenden Tagen werde ich meine Notizen zu den Sessions online stellen.


2010-10-05

Design for Mobile: What Gestures do People Use?

Luke Wroblewski schreibt in seinem Blog Ideation + Design immer Kurzfassungen von Vorträgen, an denen er teilnimmt.
Relativ aktuell ist eine Stichpunktesammlung 'What Gestures do People Use?' vom Vortrag von Dan Mauney von der 'Design for Mobile'-Konferenz in Chicago IL.

Es geht hierbei um eine Untersuchung, welche Gestiken Nutzer bei mobilen Endgeräten verwenden. Die Versuchspersonen wurden beauftragt, verschiedene Operationen durchzuführen und hierbei beobachtet.

Besonders erwähnenswert finde ich folgende drei Punkte:


  • Viele Nutzer haben die gefragten Operationen in einem Menü gesucht, obwohl sie gebeten wurden, die Operationen durch Gestiken auszuführen.
  • Die Wischgestik ('swipe') wurde für diverse Operationen verwendet (löschen, multi-select, ausschneiden, scrolling). Es ist also fraglich, ob man beim Entwerfen einer mobilen Benutzerschnittstelle dieser Gestik eine eindeutige Funktion zuweisen kann.
  • Wenn User nicht genau wussten, wie sie eine Funktion erreichen können, haben sie ein Symbol (zum Beispiel ein Fragezeichen für Hilfe) auf den Screen gemalt. Gute Idee - ich glaube, dass ich da nicht drauf gekommen wäre.

2009-06-16

7 Regeln der Usability

FlashCamp Berlin
aus Vortrag von Ron Hofer: User Experience & Fireflow

Für positive User Experience (UX) sind unter anderem folgende 7 Regeln der Usability notwendig:
  1. Aufgabenangemessenheit (Musikwahl bei einer elektrischen Zahnbürste sprengt den Rahmen und ist daher zu vermeiden)
  2. Selbstbeschreibungsfähigkeit (Dieser Punkt beschreibt sich von selbst)
  3. Erwartungskonformität (Eine Fahrstuhltür öffnet sich wieder, wenn ich mich dazwischen stelle.)
  4. Fehlertoleranz (Ein fehlertolerantes System schlägt mir automatisch on-the-fly z.B. einen freien Benutzername vor, wenn der gewählte bereits vergeben ist. Gutes Bsp. Twitter-Anmeldung)
  5. Steuerbarkeit ("Der Nutzer gibt den Takt an!" Mentales Modell des Nutzers darf nicht gebrochen werden.)
  6. Lernförderlichkeit (Neue Nutzer sind Anfänger des Systems und werden bei der Benutzung immer mehr zu Experten.)
  7. Individualisierbarkeit
UX bedeutet: Was brauche ich? + Was WILL ich?
Die Erwartungen, die an ein Produkt gestellt werden, steigen über die Zeit vom ersten Kontakt (z.B. Werbung) über den Kauf und der Nutzungszeit. Die UX muss ÜBER der Erwartung liegen, um mit dem Produkt zufrieden zu sein. Das heißt im Umkehrschluss, dass das System so eingerichtet sein muss, dass die Zufriedenheit mit der Benutzungsdauer steigen kann!

  • Generelles Problem bei Systemen: Je flexibler ein System ist, um so schlechter ist die Usability.
  • 20% der Funktionen können 80% der Aufgaben erledigen, die restlichen 80% kann man z.B. in Menüs "verstecken".
Akzeptanz/Nutzen von neuen Funktionen lassen sich gut wie folgt testen:
  • Die Feature werden in Form von "Produkten" abgebildet. Jedes Feature entspricht einem Produkt. Der virtuelle Preis ergibt sich aus dem Umsetzungsaufwand der Funktion.
  • Testpersonen bekommen eine begrenzte Menge an virtuellem Geld und können damit einige der "Produkte" kaufen.
  • Die meistgekauften Produkte sind die Feature, die man für die ausgewählte Zielgruppe umsetzen sollte.