Top 10 Fehler bei der UI Spezifikation - Ein Worst-of aus der Praxis
•
1 like•843 views
Die msg systems entwickelt Individualsoftware für eine Vielzahl von Branchen von Automobilindustrie über Versicherungen bis zum öffentlichen Dienst. Dabei werden viele User Interfaces spezifiziert – und dabei die selben Fehler immer wieder gemacht. Um dem zu begegnen wurde intern eine Checkliste zur Prüfung von UI-Spezifikationen entwickelt. Die „beliebtesten“ Fehler bei der Spezifikation von Benutzeroberflächen stellt Lisa Daske in ihrem Vortrag vor.
Recommended
More Related Content
Viewers also liked
Viewers also liked (15)
Recently uploaded
Recently uploaded (20)
Top 10 Fehler bei der UI Spezifikation - Ein Worst-of aus der Praxis
- 1. .consulting .solutions .partnership Top 10 Fehler bei der UI Spezifikation Ein Worst-of aus der Praxis
- 2. © msg | November 2015
- 3. © msg | November 2015
- 4. © msg | November 2015 4© msg | November 2015
- 5. © msg | November 2015 5© msg | November 2015
- 6. © msg | November 2015
- 7. © msg | November 2015
- 8. © msg | November 2015
- 9. © msg | November 2015 9© msg | November 2015
- 10. © msg | November 2015 10© msg | November 2015
- 11. © msg | November 2015 11© msg | November 2015
- 12. © msg | November 2015
- 13. .consulting .solutions .partnership Lisa Daske Usability Engineer +49 (0) 89 / 96101- 1664 lisa.daske@msg-systems.com @lisadaske msg systems ag Robert-Buerkle-Str. 1 85737 Ismaning Germany www.msg-systems.com http://tinyurl.com/ui-spec-worst-of
Editor's Notes
- Internationale Unternehmensgruppe Softwareentwicklungs- und Beratungsunternehmen Über 5.000 Mitarbeiter Hauptsitz im Münchener Norden in Ismaning Wir entwickeln Business-Software, die die Geschäftsprozesse unserer Kunden unterstützt Das bedeutet: mittlere bis hohe Komplexität, viele Daten, Benutzeroberflächen mit Formularen die sich über viele Seiten erstrecken, und über Jahre gewachsen sind. Das heißt für uns ist das Thema „UI-Spezifikation“ ein wichtiges Thema schon aufgrund der Komplexität und auch aufgrund der Teamgrößen – einfach nur eine Skizze erklären reicht nicht. Besonderheit Es gibt einen internen Beratunssbereich, in dem leite ich das Kompetenzzentrum für User Experience und Usability Unsere Projekteinsätze sind vielfältig: von kurzen Beratungen über Beschriftung zu einem Button, über Review oder Usability-Test bis hin zu Unterstützung bei Konzeption und Entwicklung. Die Erfahrung aus diesen Projekten - was läuft gut, was schlecht - versuchen wir für unsere Kollegen aufzubereiten Der heutige Vortrag ist das Ergebnis davon dass wir uns dieses Jahr gefragt haben – wie spezifiziert man Interfaces gut (nicht: gute Interfaces)? Wie das so ist: Wenn man sich fragt, wie macht man das gut, fallen einem 100 Sachen ein die man falsch machen kann. Ich möchte heute die aus unserer Erfahrung 10 häufigsten „Fehler“ bei der Spezifikation von User Interfaces vorstellen, und hoffe, wir können alle aus diesen Fehlern lernen Eins noch vorneweg: Wenn ich von Oberflächenspezifikationen spreche gibt es zwei wichtige Bereiche: Das eine ist das Rahmenwerk, das beschreibt, was in dieser Anwendung möglich ist. Das zweite ist die Beschreibung, wie konkrete Anwendungsfälle mit den Mitteln der Anwendung umgesetzt werden. Es lohnt sich, auch gedanklich diese beiden Themen zu trennen.
- Nummer 10 der 10 beliebtesten Fehler bei der UI Spezifikation ist dieser: Eine UI-Spec ist ein Styleguide. Ein persönlicher Liebling von mir. Ich bin dieses Jahr von 3 Projekten gebeten worden, einen Styleguide zu entwickeln. Und in allen Fällen hat sich herausgestellt, die meinen eigentlich etwas ganz anderes – für mich nicht überraschend. Unter Styleguide verstehe ich etwas, das Farbe, Form, Typografie, Layouts, Rastersysteme beschreibt. Kommt ganz klassisch aus den Printmedien, und sieht heute auch für Webanwendungen aus. Möglicherweise ist beschrieben, wie typische Bedienelemente aussehen. Vielleicht sogar in verschiedenen Zuständen. Styleguides sind gut. Sie sichern ein einheitliches Erscheinungsbild, so dass die Zugehörigkeit eines Produkts zu einer Marke immer offensichtlich erkennbar ist. Eine GUI-Spezifikation muss aber viel mehr leisten. UI-Spezifikationen haben aber schon große Gemeinsamkeiten: es geht darum, einen Rahmen zu schaffen, in dem man sich bewegen kann wenn man eine Software gestaltet. Es geht nicht darum, keine Kreativität in der Gestaltung zuzulassen, aber es werden klare Grenzen gesetzt. Das heißt mindestens so wichtig, wie zu beschreiben was man tut ist – was wollen wir nicht tun? Styleguides sichern Konsistenz. UI-Spezifikationen leisten das nicht nur in Bezug auf visuelles Erscheinungsbild, sondern auf Verwendung und Verhalten von Oberflächen-Elementen. Wann soll ich welches Bedienelement verwenden? Und, wichtiger: wann sollte ich dieses Element nicht verwenden? Oder welche verwenden wir generell nicht? Ich würde zum Beispiel gerne Kontextmenüs in Webanwendungen verbieten - Ein Wort noch zu Styleguides: Gerade im Web gilt: Styleguides auf Papier sind nicht hilfreich für Entwickler. Regeln gehören in den Code.
- Nummer 9 auf der Liste der beliebtesten Fehler bei GUI Spezifikationen ist nicht für unsere Nutzer zu arbeiten. Das Mantra der Usability Professionals ist: Know your User. Und wir schreiben viel zu oft Spezifikationen, die sich hauptsächlich an den Kunden wenden. Dem ist ein Teil der Spezifikation wichtig, nämlich: wie werden seine fachlichen Anforderungen, seine Arbeitsabläufe abgebildet. Aber er ist keinesfalls der Hauptnutzer einer GUI-Spezifikation. Vieles, was in GUI-Spezifikationen steht, könnte eigentlich ein internes Dokument sein. Wer größere Projekte kennt weiß, das kann den Vorteil haben, dass ich mir nicht jede Änderung neu abnehmen lassen muss, und das erlaubt mir eine größere Flexibilität. Zielgruppe sind zwei andere Gruppen im Projekt: Entwickler und diejenigen die auf Basis einer allgemeinen GUI-Spezifikation einzelne Anwendungsfälle in Benutzeroberflächen übersetzen – bei uns heißen die Kollen Business Analysts. Für die muss das Dokument gebrauchstauglich sein. Fragen eines Entwicklers sind beispielsweise: „Wie heißt dieses Oberflächenelement im Code?“, „was muss ich an Parametern mitgeben oder einstellen, um dieses Verhalten zu erreichen?“ Kurz: Entwickler lieben Code-Beispiele oder sogar Beispiel-Implementierungen aus denen sie sich bedienen können. Business Analysten brauchen eine klare Vorgabe: welche Elemente stehen Ihnen zur Gestaltung zur Verfügung, was können die, und was nicht? Sie brauchen ein übersichtliches und gut strukturiertes Dokument. … und damit sind wir schon beim nächsten
- Entwürfe die auf dem Papier gut aussehen, aber in der Praxis erhebliche Usability-Probleme bekommen Realistische Namen und Bezeichnungen verwenden Namensgenerator Mengengerüste erfragen Was sind die Extremwerte für dieses Eingabefeld/ diese Tabelle / etc.? Beispiel: 30.000.000.000 € Wie viele Datensätze müssen dargestellt werden?
- Wo findet der Nutzer das Handbuch? Wie erklärt die Anwendung, was (fachlich!) nicht offensichtlich ist? Wie findet der Nutzer die genau für diesen Nutzungskontext relevante Hilfe? Formate kreativ nutzen: vom kleinen Icon mit Popup, über In-Place Tutorials bis zu klassischen Online-Hilfen
- Fehler bewusst gestalten: Form, Platzierung, Design und Texte Welche Fehlerklassen gibt es? Was sind hier fehlerhafte Eingaben? Was passiert als Reaktion (und wann)? Was kann hier systemseitig schiefgehen, und wie zeigen wir das an?
- Rule of Silence: Normales Funktionieren muss nicht gemeldet werden Was muss das System dem Benutzer mitteilen? Wie werden Fehler von unkritischen Meldungen unterschieden? Formate für Feedback vorgeben, z.B. Animation, Cursorwechsel, Inline in Formularen, Popup, Notification, Fester Meldungsbereich, …
- Ein Thema, das die reine GUI-Spezifikation nur am Rande betrifft, aber so wichitg ist dass ich es trotzdem ganz oben sehe Was ist die minimale Funktionalität, damit dieser Anwendungsfall funktioniert? Komfort / Begeisterungsfeatures ausweisen
- Viele der Dokumente, die wir uns im Zuge unserer Untersuchungen angesehen haben, hatten eine unübersichtliche Struktur: Grundsatzentscheidungen sind irgendwo im Dokument versteckt, wie beispielsweise die Frage: speichern wir implizit immer oder nur wenn der Benutzer das explizit auslöst. Das liegt auch daran, dass diese Grundsatzfragen in wenigen Projekten explizit gestellt werden, sondern mehr im Vorbeigehen während der Beschreibung der ersten Dialoge entschieden werden. Wir haben eine Vorlage erstellt, die als Rumpf für Oberflächen-Spezifikationen dient.
- Diese Vorlage sieht so aus: Grundlegende Konzepte (z.B. Anwendungsrahmen und verwendete Layouts,) Querschnittsaspekte (z.B. Speichern implizit oder explizit, Bedienkonzepte wie in-Place Editieren) Styling allgemein Beschreibung einzelner Elemente und Komponenten Aussehen Verhalten Strukturierte Vorlage für die Spezifikation häufig verwendeter Elemente Typische Eigenschaften, z.B. für Tabelle: Sortierung, Filterung für Eingabefeld: gültige Formate Konfigurationsmöglichkeiten Code-Beispiele
- Wann wird diese Spezifikation aktualisiert? Wie wird das Feedback von den Nutzern (Entwickler!, Business Analyst!) eingeholt?
- Verantwortlichen Ansprechpartner festlegen: an wen kann ich Fragen zu dieser Spezifikation richten? Kommunikation ins Team Rahmenwerk: Änderungen kommunizieren Konkrete Oberflächen vor Realisierung an Entwickler übergeben mit intensiver Kommunikation: (z.B. Workshop, Schulung, Newsletter mit Änderungen)?