Ein weiteres Missverständnis: Usability Tests sind teuer

In einem vorigen Artikel schrieb ich schon über verschiedene Usability-Missverständnisse (Usability – Schluss jetzt mit den Missverständnissen!). Ich möchte die Sammlung noch ein wenig erweitern.

Gerne werden an allen Ecken und Enden Kosten gespart. Und da wird gerne auf Usability Tests verzichtet: „Das hat ja schließlich ein guter Designer entworfen…“ Nun, auch Designer sind nur Menschen und können Fehler machen. Die sollte man schon aus Gründen des Investitionsschutzes frühestmöglich aufdecken. Und dazu sind eben Usability Tests da. Doch nun zu den Kosten. Denkt man an solche Tests, fallen häufig Stichwörter wie Usability Labor, Eye Tracking, Erhebungskampagnen, statistische Validierung etc. Ja, das kann alles dazu gehören – muss es aber nicht. Die Buchung und Beauftragung eines professionellen Usability-Labors ist kostenaufwendig. Aber selbst das lohnt sich in den meisten Fällen. Ich möchte hier aber zwei sehr einfache Testmethoden vorstellen, die mit wenig Aufwand durchzuführen sind und dennoch wertvolle Erkenntnisse liefern.

Papierprototypen-Test

Wie zuvor schon kurz erwähnt braucht man für diesen Test noch nicht mal lauffähigen Sourcecode. Es reichen Papierskizzen, die man aus dem Entwurfsprozess (frühe Konzeptionsphase) extrahiert. Diese Skizzen (Mockups) fallen da ja eh an, da man anhand dieser die Benutzerinteraktion durchdenkt und visualisiert. Nun überlegt man, welche Szenarien man mit welchen Nutzern überprüfen möchte. Man wählt die entsprechenden User Interface-Skizzen aus und lädt die Testteilnehmer ein. Eine Auswahl von fünf bis sechs Testteilnehmern sollte reichen. Mehr Teilnehmer erhöhen den Erkenntnisgewinn in der Regel nicht. Und statistisch belastbare Aussagen wird man auch mit 20 Teilnehmern nicht erreichen. Darum geht es aber auch gar nicht. Und wer keine sechs Teilnehmer „loseisen“ kann, beschränkt sich eben auf zwei. Lieber einen kleinen Test machen als gar keinen!

Weiterlesen

Teile diesen Beitrag:

Ohne UML in die Word-Falle

Über das Management in der UML-Falle habe ich bereits geschrieben. In dem Artikel habe ich darzustellen versucht, dass es eine große Gefahr birgt, wenn man sich in großen Projekten im Rahmen einer Spezifikation auf die Erstellung von UML-Diagrammen beschränkt und auf detaillierte textliche Erklärungen verzichtet. Man hat zwar schöne Fachklassen- und Use Case Diagramme, die gute Übersichten liefern. Die fachlichen Details – und die sind spätestens für die Entwickler unverzichtbar – gehen aber verloren.

Das andere Extrem

Doch es gibt auch das andere Extrem: den Versuch einer kompletten Fachspezifikationen in einem einzigen Dokument. Und das auch noch ohne grafische Übersichten.

Weiterlesen

Teile diesen Beitrag:

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:

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:

Management in der UML-Falle

Der Titel ist provokant. Das ist mir bewusst. Ich möchte zeigen, dass der unreflektierte Glaube in UML-Modelle zu einem echten Problem im Projekt führen kann. Und das droht besonders bei einem zeitlich engen Projektplan. Also genau dann, wenn man geneigt ist, es bei UML-Diagrammen zu belassen.

Der Werkzeugkasten UML

Die Unified Modelling Language –kurz UML- ist an sich gar nicht schlecht. Ganz im Gegenteil. Sie fasst verschiedene grafische Werkzeuge und Notationen für die Spezifikation von Software zusammen. Dazu gehören sehr unterschiedliche Diagrammtypen wie beispielsweise Aktivitäts- und Sequenzdiagramme zur grafischen Darstellung von Abläufen oder unterschiedliche Klassenmodelle zur Zerlegung der realen Welt in handhabbare Objekte. Und wie das bei Modellen eben so ist, haben sie Vor- und Nachteile. Einerseits machen sie die schier unvorstellbare Komplexität der echten Welt fassbar, andererseits laufen sie aber auch Gefahr, die Realität zu sehr zu vereinfachen oder zu oberflächlich zu betrachten. Wie hilfreich ein Modell wirklich ist, hängt letztlich von dem Modellierer ab – und der Fähigkeit des Empfängers, es richtig zu lesen und zu interpretieren.

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:

Das Web-Etwas als Eierlegendewollmilchsau

Als Berater werde ich häufig mit der Frage nach meinem Profil konfrontiert. Das ist ja auch erstmal sehr gut so. Wäre ja schlimm, wenn keiner nach mir fragte. Dann sehe ich einen Auszug aus dem Anforderungsprofil – und rolle mit den Augen.

Da wird nach einem Oberflächenentwickler gesucht, der ausgewiesene Expertise in den Bereichen Usability und Web Accessibility haben soll. Andererseits wird auch mal nach einem GUI-Designer gesucht, der von JavaScript bis php so ziemlich alles beherrscht, was an Scripting-Sprachen auf dem Markt ist. Natürlich das alles kombiniert mit zehn Jahren Erfahrung im Rational Unified Process (RUP) und UML 2.0.

Was wird da eigentlich gesucht? Die Eierlegendewollmilchsau! Keiner wird sagen, dass er das alles gleichermaßen beherrscht. Wie kommt das? Es sind Qualifikationen aus ganz unterschiedlichsten Professionen, die da zusammengeworfen werden.

Stellt Euch folgende klassische Stellenausschreibung vor:
Gesucht wird ein Zimmermann mit erwiesener Erfahrung als Möbelbauer, insbesondere Entwurf und Umsetzung von Intarsien unter Berücksichtigung konstruktiver Gebäudemerkmale.

Weiterlesen

Teile diesen Beitrag: