Usability – Schluss jetzt mit den Missverständnissen!

Der folgende Artikel ist in einem internen Newsletter meines Arbeitgebers Steria Mummert Consulting erschienen. Er wendet sich an Berater und Projektmanager, die in der Regel keine Usability Professionals sind. Dennoch könnte der Artikel auch hier den ein oder anderen interessierten Leser finden. Zusätzlich habe ich einige Links zu anderen Artikeln eingefügt.

Begrifflichkeit: Usability ist ein Kunstwort (use + ability) und beschreibt die Gebrauchstauglichkeit eines Gegenstandes oder einer Software. Usability ist heute kein Luxus mehr sondern eine unumgängliche Voraussetzung für den wirtschaftlichen Erfolg. Leider wird der Begriff von zu vielen als leere Hülse verwendet – mehr als Buzz Word denn als Prio-1-Projektziel. Unter dem Begriff der Usability werden heute auch alle Aktivitäten zusammengefasst, die geeignet sind, eben diese Usability zu erreichen. Begegnen Ihnen Schlagwörter wie User Experience Design, User Interaction Design, User Interface Design, Usability Testing, User Centered Design usw., so hat das alles mit Usability zu tun.

Was kann man um das Thema Usability alles falsch machen? Leider mehr als ich hier aufzeigen kann. Ich möchte im Folgenden nicht auf die Dos and Don’ts des Screen Designs eingehen. Die Liste wäre extrem lang. Jenseits schräger Maskengestaltung und wirren Dialogsalats sehe ich ein gravierendes Problem darin, dass sich um das Thema Usability viele Missverständnisse ranken. Einige möchte ich aufdecken. Vielleicht erreichen wir so eine größere Bereitschaft, in dieses Thema zu investieren und so bessere Software anbieten zu können. Weiterlesen

Teile diesen Beitrag:

Kontextsensitive Katalogunterstützung: Handhabung umfangreicher Auswahllisten

Mit der richtigen Platzierung und plausiblen Interaktionsmöglichkeiten lassen sich auch sehr große Auswahllisten handhaben. Doch lesen Sie selbst…

Viele Anwendungen bieten zum Ausfüllen verschiedener Eingabefelder umfangreiche Auswahllisten. Diese Auswahllisten werden auch Kataloge genannt. Man setzt sie ein, um sicherzustellen, dass nur bestimmte Werte eingegeben werden. Als kontextsensitiv wird eine Anwendung bezeichnet, wenn abhängig vom Feld, das den Fokus hat, unterschiedliche Informationen angeboten werden. Wir kennen das von der Hilfe. Wenn man auf der Erfassungsmaske A die Hilfe aufruft, werden genau zu dieser Maske passende Erklärungen angezeigt – und nicht die gesamte Onlinehilfe oder die Hilfetexte zur Maske B. Genau so kann man auch mit Katalogen verfahren. In einem festgelegten Bereich zeigt man für das Feld, das gerade den Fokus hat, den entsprechenden Katalog an. Das ist also die sogenannte kontextsensitive Katalogunterstützung.

Dafür gibt es doch die Select-Felder, könnte man meinen. Nicht ganz. Wenn ich hier von Katalogen spreche, meine ich Listen mit teilweise bis zu 1000 Einträgen. Und die einzelnen Einträge können auch recht lang sein. 100 und mehr Zeichen sind keine Seltenheit. So etwas begegnet einem in Onlineshops nicht so häufig, Fachanwendungen in der Verwaltungen setzten derart große Kataloge häufig ein. Und dafür sind einfache Select-Felder schlichtweg nicht geeignet.

Früher hat man umfangreiche Kataloge in separate Dialoge ausgelagert. An dem jeweiligen Feld fand sich ein Button – häufig mit drei Punkten gekennzeichnet -, über den man den Dialog öffnen konnte. Dann musste man durch lange Listen blättern und den gewünschten Eintrag auswählen. Und zuguterletzt musste der Dialog meistens noch bestätigt werden. Bei der Anzahl erforderlicher Nutzerinteraktionen kann einem doch wirklich schwindelig werden. Da geht nicht nur die Produktivität flöten. Es nervt einfach. Das können wir heute besser. Weiterlesen

Teile diesen Beitrag:

Halb leer oder halb voll? Je nach Kontext!

Die Frage, ob das Glas halb leer oder halb voll ist, scheint müßig, offenbart aber ein Verständnisproblem. Und das impliziert auch ein Usability-Problem. Um genau zu sein, es ist ein Content Usability-Problem.

Doch wenden wir uns der Frage zu. Je nach dem, ob man den Füllstand des Glases als halb voll oder halb leer bezeichnet, wird man als Pessimist oder eben als Optimist beurteilt. Für den Pessimisten ist das Glas halb leer, der Optimist beschreibt es als halb voll. So scheint jedenfalls das allgemeine Verständnis zu sein.

Kürzlich führte ich eine teilweise sehr engagierte Diskussion um genau diesen Punkt. Ich konnte die Frage beim besten Willen nicht eindeutig beantworten. Irgendetwas fehlte da noch…

Ohne Kontext kein Urteil

Weiterlesen

Teile diesen Beitrag:

Das User Interaction-Masterdocument

Ist es Euch auch schon mal passiert: Da wird eine Änderung einer bestimmten Funktionalität diskutiert, Ihr habt ein mulmiges Gefühl dabei. Irgendetwas ist faul. Ihr wisst genau, wenn ich dem jetzt zustimme, hat das Auswirkungen auf einige Storyboards…

Warum? Weil eine Funktionalität diskutiert wird, die ein oder mehrere User Interaction Patterns betreffen, die Ihr im längeren Projektverlauf mühsam entwickelt und abgestimmt habt. Und jetzt soll diese Änderung vorgenommen werden!

Was bedeutet das denn nun wirklich? Wäre es da nicht schön, wenn man eine zentrale Stelle im Projekt hätte, die darüber Auskunft geben könnte. Tja, genau diese Stelle sind wir als verantwortliche User Interaction Designer normalerweise. Doch, Hand auf’s Herz. In einem Projekt, das seit einem Jahr läuft kann man sich nicht mehr an jeden Entscheid erinnern, der irgendwann getroffen worden ist. Jetzt könnte man einen Stapel von Protokollen durchsehen – oder den Styleguide befragen. Das erste ist zu langwierig, das zweite ist zu allgemein. Man könnte auch alle Storyboards durchsehen. Da steht ja drin, wie User Interaction laufen soll (siehe hierzu Storyboards: Eine Erfolgsgeschichte). Doch dazu fehlt die Zeit.  Also: keine Antwort, nur ein schlechtes Bauchgefühl. Weiterlesen

Teile diesen Beitrag:

Storyboards: Eine Erfolgsgeschichte

Was sind Storyboards?

Storyboards sind Geschichtenbretter – jedenfalls wörtlich übersetzt. Ok, wir malen die nicht auf Holz. Storyboards beschreiben die Umsetzung eines fachlichen Anwendungsfalls in eine konkrete Software-Benutzeroberfläche. Beschreibt ein Anwendungsfall (Use Case) die rein fachlichen Abläufe (z.B. Anlegen eines Kontos), so beschreibt das entsprechende Storyboard, wie das in der Software-Oberfläche vor sich geht.

Herkunft

Storyboards verbindet man eher mit der Erstellung von Trickfilmen oder der Planung von Werbespots. Verschiedene Scribbles (flüchtige Skizzen) werden mit Pfeilen und Symbolen miteinander verbunden. Ziel ist es, eine Geschichte zu erzählen und den Ablauf der Geschichte zu verdeutlichen. Nun, da hat die gute alte IT-Welt mal von so neumodischem Kram wie Zeichentrick und Werbung gelernt. Wobei ich mir jetzt gar nicht so sicher bin, ob Storyboards nicht schon viel früher im Filmgeschäft eingesetzt wurden. Das Ziel sollte dasselbe gewesen sein: eine Geschichte erzählen. Wie dem auch sei, die Storyboards haben in die IT Einzug gehalten. Weiterlesen

Teile diesen Beitrag:

Usability verkaufen – aber wie, und an wen?

Wir Usability Professionals sehen uns häufig einem Problem gegenübergestellt. Alle finden unsere Bemühungen äusserst ehrenswert, wichtig und spannend. Doch wenn es zur Nagelprobe kommt, fällt Usability als erstes dem Projektrotstift zum Opfer. Die Projektverantwortlichen wollen dafür kein extra Geld ausgeben. Nun könnten wir uns damit trösten, dass Usability nicht die einzige Disziplin ist, der es so ergeht. Fundiertes Anforderungsmanagement und Konfigurationsmanagement erleiden nicht selten dasselbe Schicksal. Doch das wird uns wohl kaum beruhigen.

Wo liegt das Problem?

Im Prinzip habe ich die Antwort schon mit der Artikelüberschrift geliefert. Ein Usability Professional muss seine Dienstleitung genauso verkaufen wie ein Accountmanager sein Projekt. In diesem Sinne müssen wir also wirklich als Vertriebler auftreten. Mancher mag die Nase rümpfen, doch Verkaufen ist nichts Schlimmes – es ist die Grundlage des Austauschs von Waren und Leistungen, und das seit Erfindung der Tauschwirtschaft.

Weiterlesen

Teile diesen Beitrag:

Entwurf speichern? Gerne – aber nur auf Befehl!

Vor längerer Zeit stieß ich in einem Projekt auf eine Problematik, die sich um das Zwischenspeichern von Entwürfen rankt. Nicht aktuell – aber vielleicht interessant genug, um es hier im Blog nachzutragen.

Die Ausgangssituation

Es geht um eine eigentlich recht einfache Situation: Der Nutzer möchte ein Dokument oder eine Mail erstellen. Nun, unser Vertrauen in die Technik hat durch den ein oder anderen Bluescreen oder andere Abstürze gelitten. Was machen wir also? Ctrl+S gehört zu den Shortcuts, die man schnell lernt und schon fast automatisch alle paar Minuten eingibt… Wenn man nicht ein UI einer browsergestützten Anwendung vor sich hat! Das führt nämlich dazu, dass man die HTML-Seite lokal speichert. Das WordPress, an dem ich gerade sitze, bietet mir an, post-new.php.html lokal zu speichern. Hm, das möchte ich aber nicht. Ich möchte nur sicherstellen, dass der Artikel nicht verloren geht. Ctrl+S ist also nicht die Lösung.

Die vermeintliche Lösung

Dieselbe Situation habe ich in jenem Projekt erlebt: Eine browserbasierte Oberfläche, in der umfangreiche Dokumente erstellt werden. Wie löst man das? Beim Erstellen eines Dokuments wird sofort ein Entwurf angelegt. Dieser wird aktualisiert, sobald man innerhalb eines Assistenten vor oder zurück navigiert. Dies wird dem Nutzer nicht signalisiert. Wenn man das Dokument erstellt und versendet hat, wird der Entwurf gelöscht. Das klappt alles ganz prima, solange man die Erstellung des Dokuments nicht abbricht. Beim Abbrechen wurde dann nämlich gefragt: „Es ist ein Entwurf automatisch angelegt worden. Wollen Sie den Entwurf löschen?“ Wie bitte? Was soll ich hier entscheiden? Ich weiß doch gar nicht, was da im Hintergrund passiert ist und was im Entwurf drin steht. Ich habe den nicht angelegt. Da wir aber vorsichtige Nutzer sind, löschen wir den Entwurf nicht und klicken auf Nein. Die Erfassungsmaske der Mail schließt sich und alles ist gut. Wirklich? Es sammeln sich so im Laufe der Zeit viele Entürfe an, deren Inhalt ich nicht einschätzen kann. Ok, das ist das Usability-Problem Nr. 1.: Ansammeln unbekannter Dateien. Das ist besonders dann ein Problem, wenn mehrere Nutzer an einem Ordner arbeiten und nicht wissen, was die Entwürfe des anderen Kollegen sollen. Lieber Finger weg!

Weiterlesen

Teile diesen Beitrag:

Tabpages werden häufig falsch eingesetzt

Tabpages in Thunderbirds Systemeinstellungen

Irgendwann Anfang der 90er haben sich sogenannte Tabpages in die User Interfaces eingeschlichen. Im Prinzip bilden diese Tabpages (kurz Tabs – nein, nicht die für den Geschirrspüler) ein Notizbuch nach. Die Tabs unterteilen das Notizbuch in verschiedene Bereiche. Bei OS/2 ist das für komplexe Systemeinstellungen verwendet worden. Und dafür haben sich die Tabpages auch als probates Mittel bewährt, um die Fülle der Einstellungen zu ordnen. Bei OS/2 ist der Notizbuchcharakter sogar noch durch eine Spiralbindung am linken Rand visualisiert worden.

Nun scheinen diese Tabpages aber so beliebt geworden zu sein, dass man sie fast überall im User Interface Design findet. Bevor man aber nun die Welt komplett ins Notizbuch steckt, gilt es noch mal zu hinterfragen, was die Tabpages leisten und was nicht. Es können sich nämlich aus falschen Verwendung ernsthafte Usability-Probleme ergeben.

Weiterlesen

Teile diesen Beitrag: