Kategorie-Archiv: Produktgestaltung

Gutes Design fällt nicht vom Himmel – ein Plädoyer für bessere Designkritik im UX Design

Mir ist es bisher noch nie gelungen, bereits mit dem ersten Entwurf für ein Produkt oder eine Bedienoberfläche Perfektion zu erreichen. Weder früher als UX Designer noch heute als Creative Director. Gutes Design entsteht für mich durch einen iterativen Prozess aus Versuch und Irrtum. Um in diesem Prozess Erfolge von Irrtümern unterscheiden zu können, brauchen Designer Kritik bzw. Feedback. User Experience Professionals setzen dabei natürlich in erster Linie auf das Feedback der Verwender des Produktes bzw. Services. Dieses Feedback ist die Grundlage dafür, dass das Design verständlich und brauchbar ist.

Gutes Design ist aber nicht nur verständlich und brauchbar. Gutes Design weckt Emotionen bei seinen Anwendern. Es strahlt Persönlichkeit und Identität aus. Es verbindet das Unternehmen bzw. eine Marke und seine Kunden auf einer persönlichen Ebene. Die Qualitäten guter Gestaltung sind sehr vielschichtig und lassen sich nicht allein durch Kundenfeedback sicherstellen. (Siehe Principles of Good Design by Dieter Rams (Braun) and Jonathan Ive (Apple)). Damit ein Produktdesign erfolgreich wird, bedarf es der kreativen Auseinandersetzung mit den unterschiedlichen Qualitätsaspekten der Gestaltung.

„Design Critique – a formal discussion of the good and bad points of a particular design“ – Wikipedia

Diese kreative Auseinandersetzung erfolgt meiner Ansicht nach nicht nur durch das Einholen von Kundenfeedback, sondern auch durch Designkritik. Also die kritischen und ehrlichen Diskussion darüber, ob das Design allen Qualitätsaspekten gerecht wird. Ich habe manchmal den Eindruck, dass dies unter uns User Experience Designern nicht so bekannt oder anerkannt ist. Mag sein, dass dies auch in der Ausbildung zu kurz kommt oder in Vergessenheit geraten ist, weil wir in den vergangenen Jahren sehr viel Augenmerk auf das Feedback vom Anwender gelegt und dafür geworben haben.

Gutes Design braucht Kritik.

Ich bin davon überzeugt, dass Design nicht nur Kundenfeedback, sondern auch professionelle Kritik bzw. Design Critique braucht, um gut zu werden. Leider ist das gar nicht so einfach. Wenn Design Critique nicht geübt wird und ungewohnt ist, kann sie genau das Gegenteil von dem bewirken, was sie erreichen soll. Sie führt dann nicht zu einer besseren Gestaltung, sondern zu persönlichen Verletzungen und im schlimmsten Fall dazu, dass Designs in Teams zu wenig gezeigt oder diskutiert werden.

Ich finde, dass wir uns als UX Designer wieder mehr mit professioneller Designkritik beschäftigen sollten. Nicht nur, um unsere Designs besser zu machen, sondern auch um selbst besser zu werden.

Regelmäßige Kritik

Ich denke, dass in erster Linie Übung und Gewöhnung notwendig ist, um Design Critique sinnvoll nutzen zu können. Der erste Schritt ist es daher regelmäßig Kritik zu üben und zu empfangen. Regelmäßige Designkritik-Sessions, in denen UX Designer ihre Arbeiten vorstellen und diskutieren, sollten ähnlich wie regelmäßige Retros in der agilen Welt zum Handwerkszeug des UX Designs gehören.

Design Review anstatt Design Critique

Im Deutschen ist der Begriff „Kritik“ negativ belegt. Von daher kann es helfen, nicht von Design Critique oder Designkritik sondern von Design Review zu sprechen.

Kleine Gruppen

Je nach Diskussionskultur eines Teams kann es außerdem erforderlich sein, für die Diskussion einen Rahmen und Regeln zu schaffen. Aus meiner Erfahrung heraus funktioniert Kritik in kleinen Gruppen deutlich besser als in großen Gruppen. In kleinen Gruppen bis max. 4-5 Personen ist eine Diskussion zielführender und gehaltvoller. In großen Gruppen kann leicht ein Tribunal-Effekt entstehen, der in einem frustrierenden Erlebnis für den Kritisierten endet. Wenn beispielsweise in einer großen Runde (z.B. 20 Personen) die Arbeit eines Designers von zwei anderen Designer stark kritisiert wird und die restlichen Teilnehmer schweigen, kann der Eindruck eines von der Gruppe getragenen vernichtenden Urteils entstehen.

Heterogene Gruppen

Um die vielschichtigen Qualitätsaspekte von Design betrachten zu können, ist es hilfreich ein möglichst heterogenes Team zusammenzustellen. Warum also nicht auch User Researcher, Requirements Engineers, Entwickler oder Business Analysten zum Design-Review einladen. Wichtig ist, dass sich die Teilnehmer auf Augenhöhe begegnen. Weder Hierarchie noch Betriebszugehörigkeit oder Berufserfahrung sollten Einfluss auf die Relevanz eines Feedbacks haben. Dafür kann es hilfreich sein, dass sich dies auch in der Sitzordnung widerspiegelt. Am besten stehen alle um das zu diskutierende Design herum.

Keine Anschuldigungen

Bei der Formulierung von Feedback habe ich die Erfahrung gemacht, dass „Ich-Botschaften“ deutlich besser funktionieren, als „Du-Botschaften“. Eine Formulierung wie „Du hast das aber unordentlich gestaltet.“ kann vom Kritisierten als Anschuldigung verstanden werden. Im Ergebnis entsteht das Gefühl von Abwehr und Rechtfertigung. Eine Formulierung wie „Ich persönlich finde …“ hilft dem Kritisierten, das Gesagte als persönliche Meinung zu verstehen. Leider sind „Ich-Botschaften“ kein Garant für eine gute Diskussion. Wenn beispielsweise der Kritisierte sehr unsicher ist oder Selbstzweifel hat bzw. der Kritisierende sehr dominant oder bestimmend auftritt, können auch „Ich-Botschaften“ zu Abwehr und Rechtfertigung führen. Um die Kritik möglichst objektiv zu formulieren, kann es helfen, eine Kritik wie eine Anforderung zu formulieren: „Ich als Anwender könnte das Design als unprofessionell wahrnehmen, weil die Bedienelemente nicht am Raster ausgerichtet wurden.“

Gute Vorbereitung

Vor einem Design Review sollten die Designs entsprechend aufbereitet werden. Sie sollten auf einem Medium gezeigt werden, welches eine Diskussion über die relevanten Qualitätsaspekte ermöglicht. Es macht beispielsweise wenig Sinn über die Farben eines Designs für eine App auf Basis von Ausdrucken zu diskutieren. Weiterhin sollte dargestellt bzw. vorgestellt werden, welches Ziel das Design erreichen soll, welches Problem es lösen soll und in welchem Kontext es zum Tragen kommt. Außerdem kann es hilfreich sein, die Aspekte vorzustellen, über die im zu diskutierenden Design bereits nachgedacht wurde (z.B. wurde über Barrierefreiheit nachgedacht oder warum eine bestimmte Typographie gewählt wurde). Das hilft den Betrachtern dabei die Hintergründe für das Design zu verstehen und bessere Kritik zu üben.

Keine Endlos-Diskussionen

Am schlimmsten empfinde ich es, wenn dieselbe Kritik wiederholt und endlos auf einen hereinprasselt. Kritik sollte zeitlich begrenzt oder neu-deutsch „time-boxed“ sein. Eigentlich genügt es die Kritik einmal zu sagen und nur zu wiederholen, wenn der Kritisierte nachfragt.

Kritik aufmerksam empfangen

Wenn ich Kritik empfange, dann versuche ich zum einen aufmerksam zu zuhören und die Gründe für die Kritik zu verstehen. Das ist nicht immer leicht, da ja die eigene Arbeit im Mittelpunkt der Kritik steht. Ich versuche durch eine Zusammenfassung der Kritik zu spiegeln, was ich verstanden habe und durch Nachfragen die Hintergründe zu verstehen. Mir hilft es auch, Notizen zu machen, da ich mich durch das Formulieren der Notizen auf das Verstehen der Kritik fokussiere.

Wertschätzung

Ich halte wenig davon Kritik in ein Sandwich von Lob zu verpacken. Also erst loben, um dann zu kritisieren und dann wieder zu loben. Auch wenn das in manchen Feedback-Seminaren als der goldene Weg verkauft wird, trenne ich lieber Lob und Kritik. Wichtig ist für mich, dass die Kritik wertschätzend ist. Also der Kritisierte weiß oder spürt, dass der Kritisierende ihn und seine Arbeit trotz der Kritik schätzt. Das setzt natürlich ein gewisses Vertrauensverhältnis und Momente des Lobes voraus.

Design Review und Entscheidung trennen.

Zu guter Letzt halte ich es für wichtig die Diskussion über einen Designentwurf und die finale Entscheidung für oder gegen eine Umsetzung bzw. Produktion voneinander zu trennen. Die Designkritik bzw. ein Design-Review zielt darauf ab, einem Designer oder einem Designteam zu helfen das Design zur Perfektion zu bringen. Vermischt man dies mit einer Entscheidung über die Umsetzung, kann das die Diskussion in eine ausweglose Sackgasse führen aus der niemand lernen kann. Die finale Entscheidung, ob das Design dann für die Produktion geeignet ist oder umgesetzt wird, sollte in einem anderen Rahmen und auf Basis klarer Entscheidungsvorlagen getroffen werden. Dazu muss das Design im Ganzen eine finalen Zustand erreicht haben, entsprechend aufbereitet sein und sowohl Feedback aus Design Reviews als auch aus Tests mit Anwendern vorliegen.

Siehe auch

20 ways to make your design critiques more effective
How to give and receive a good design critique
How to Survive a Critique: A Guide to Giving and Receiving Feedback
Design Criticism and the Creative Process
9 Rules for Running A Productive Design Critique
How To Run a Design Critique
GV Guide to Design Critique
Peek Inside a Facebook Design Critique
Running productive design critiques

chi2016: Peek-A-View – Smartphone Cover Interaction for Multi-Tasking

Die Seoul National University stellte in ihrem Beitrag ein transparentes Smartphone-FlipCover vor, welches das Wechseln zwischen Aufgaben bzw. Anwendungen vereinfachen soll:

Das FlipCover wurde mit der herkömmlichen Navigation über der Funktionen des Smartphones zum Wechsel von Apps im Rahmen eines Tests mit 18 Testpersonen verglichen. Ergebnis: Auch wenn es seltsam aussieht, geht der Wechsel mit dem FlipCover schneller.

Siehe auch

Peek-a-View: Smartphone Cover Interaction for Multi-Tasking

chi2016: Getting User’s Attention in Web Apps in Likable, Minimally Annoying Ways

Die Carnegie Mellon University und HP untersuchten in ihrer Studie, welche Designelemente geeignet sind, um die Aufmerksamkeit der Nutzer von Webanwendungen zu erlangen. Untersucht wurden Popups, Einblendungen wie Laufschriften, blinkende Elemente, pulsierende Schatten und Icons. Insgesamt wurden 15 verschiedene Gestaltungsvarianten untersucht, die geeignet sind, die Aufmerksamkeit der Anwender auf sich zu ziehen. Im Rahmen einer Crowd-Testing-Studie wurden die Gestaltungsvarianten hinsichtlich Wahrnehmbarkeit, Reaktionszeit, Belastung und Akzeptanz getestet.

Die Ergebnisse im kurzen Überblick:

  • Popups haben erwartungskonform die beste Wahrnehmbarkeit, führen aber auch zur höchsten Belastung bei den Testpersonen.
  • Messageicons haben zwar die höchste Akzeptanz, aber die geringste Wahrnehmbarkeit.
  • Den besten Kompromiss hinsichtlich Belastung, Wahrnehmbarkeit und Akzeptanz bieten pulsierende Schatten, um Bedienelemente oder Informationen hervorzuheben.

Siehe auch

Getting Users‘ Attention in Web Apps in Likable, Minimally Annoying Ways

chi2016: Now Check Your Input: Brief Task Lockouts Encourage Checking, Longer Lockouts Encourage Task Switching

Das University College London ging in diesem Beitrag der Frage nach, ob erzwungene Wartezeiten dazu führen, dass Menschen ihre Eingaben in Bedienoberflächen besser überprüfen oder geplante Handlungen zur Sicherheit überdenken. Hintergrund ist die Beobachtung das Eingabefehler immer wieder zu Fehlern mit teilweise gravierenden Auswirkungen führen. Das kann eine falsche Übertragung eines Rechnungsbetrages in ein Bezahlsystem sein, was zu einer falschen Abbuchung führt. Das können aber auch falsche Eingaben in Flugcomputer oder Medikamentenpumpen sein.

If it is really important, people will check.

Sie führten zwei Studien durch, um die Auswirkungen von Wartezeiten zu überprüfen. Die erste Studie war eine Laborstudie in der Testpersonen unter kontrollierten Bedingungen mit unterschiedlichen Wartezeiten (bis zu 6 sec) konfrontiert wurden. Diese Studie zeigte, dass eine längere Wartezeit zur Überprüfung der Eingaben führt. Aber: Dieses Ergebnis ist nicht weiter von Bedeutung, da die Testpersonen im Test nur die Aufgabe hatten, die Eingaben korrekt zu tätigen. Es gab keine anderen Aktivitäten zu denen die Testpersonen hätten wechseln konnten. Also wurde eine ergänzende Crowd-Testing-Studie durchgeführt, bei denen Anwender die Testaufgaben unter normalen Bedingungen auf ihren eigenen Rechnern durchführten und deren Verhalten dabei aufgezeichnet wurde. Das Ergebnis zeigte, dass Testpersonen bei längeren Wartezeiten zu anderen Aufgaben wechseln. Die Autoren schlussfolgern daraus, dass erzwungene Wartezeiten auch funktionieren, wenn Menschen zu anderen Aufgaben wechseln können.

Ich würde diese Schlussfolgerung in Frage stellen, da die Testpersonen ihre Zeit nicht mit Überprüfung verbrachten, sondern für eine Tätigkeit nutzten, die sie für sinnvoll hielten. Meine Schlussfolgerung wäre, dass erzwungene Wartezeiten nicht dauerhaft funktionieren kann und wir lieber daran arbeiten sollten, dass die Überprüfung von manuellen Eingaben entfällt. Beispielsweise durch automatische Validierungsmechanismen oder schlicht dadurch, dass die Eingabe nicht mehr nötig ist.

Siehe auch

Now Check Your Input: Brief Task Lockouts Encourage Checking, Longer Lockouts Encourage Task Switching

chi2016: User Research to Inform Product Design: Turning Failure into Small Successes

Forrester Research und NANMANN berichten in ihrem Beitrag von einem fehlgeschlagenen UI Design-Projekt, welches sich durch Personas in einen kleinen Erfolg verwandelte. Zum Hintergrund: Forrester Research ist ein Unternehmen, welches Analysen und Berichte an Unternehmen verkauft. Vor einiger Zeit wurde das Geschäft von Berichten und Excel-Tabellen hin zu Dashboards erweitert. Die Hoffnung war, dass Dashboards eine interaktive Aufbereitung bieten, die Anwendern dabei hilft die Daten besser zu verstehen und den Lieferprozess für die Analysen und Berichte vereinfacht.

Leider trafen die entwickelten Dashboards die Kundenaforderungen nicht richtig, so dass nach einem Jahr nur 25% der Kunden Dashboards nutzten. Also wurden zwei UX Professionals (1x von intern und 1x von extern) beauftragt, die Probleme zu identifizieren und zu lösen. Die Analyse ergab 3 grundlegende Probleme: Die Ziele der Nutzer wurden mit den Dashboards nicht adressiert. Es war weder eine vergleichende Auswertung der Daten noch eine tiefe Analyse der Daten möglich. Die UX Pros sollten nun diese Probleme lösen. Wichtig zu wissen: Sie waren nicht Teil des Entwicklungsteams, sondern mussten von außen über Empfehlungen versuchen eine Verbesserung zu erreichen.

Also veranstalteten sie mit dem Entwicklungsteam für Dashboards einen Kickoff und versuchten es für ihre Analyse sowie ihr Vorgehen zu gewinnen. Es wurden 6 Interviews mit Dashboard-Nutzern durchgeführt. Das gesamte Entwicklungsteam nahm an den Interviews teil und analysierte sowie dokumentierte die Ergebnisse. Die zu Beginn erkannten Probleme wurden bestätigt. Außerdem bewerteten die Kunden Dashboards als unwichtig. Aus den Interviews wurden 3 relativ einfache Vorschläge entwickelt. Die Änderungen waren zwar einfach, wirkten sich aber bis in die Informationsarchitektur und auf die Anzahl der Dashboards aus. Die Empfehlungen wurden zwar vom Entwicklungsteam positiv aufgenommen, nicht aber vom Produktmanagement. Diese waren mit den Veränderungen nicht einverstanden, die sie nach der Anzahl der Dashboards bonifiziert werden, die verkauft werden. Eine bessere Informationsarchitektur hätte eine geringer Anzahl und damit vermeintlich weniger Bonus für das Produktmanagement bedeutet. Das Produktmanagement beauftragte eine neue Studie und entschied sich gegen die Vorschläge. Aufgrund der heftigen Gegenwehr gab das Entwicklungsteam seine Bestrebungen die Dashboards zu verbessern auf. Die Veränderung war gescheitert.

Die UX Professionals sammelten als Projektabschluss die Erkenntnisse zusammen und dokumentierten sie in Form von Personas sowie Anforderungen. Überraschenderweise wurden dann diese Personas vom Dashboard-Entwicklungsteam unter der Hand wieder aufgegriffen. Sie wurden in die Arbeitsräume gehängt und als Orientierung für die Entwicklung verwendet. In Schwung kam das Ganze, als die eigenen Forrester-Analysten diese Personas als ein gutes Beispiel in einem öffentlichen Bericht aufgriffen. Eine Entwicklerin nahm das zum Anlaß ein anwenderorientiertes Dashboard auf Basis der Erkenntnisse aus dem gescheiterten Projekt zu entwickeln. Dies war so erfolgreich, dass ein Produktmanager mit seinem Team die Dashboards seit dem nach diesem Konzept erstellt. Heute nutzen über 50% der Nutzer die Dashboards und das obwohl einige Produktmanager noch immer die Erreichung ihrer persönlichen Ziele über die Unternehmensziele stellen.

Siehe auch

User Research to Inform Product Design: Turning Failure into Small Successes

chi2016: Lightweight Journey Mapping: The Integration of Marketing and User Experience through Customer Driven Narratives

MathWorks stellte in ihrem Beitrag auf der CHI 2016 einen sehr einfachen Ansatz für das Customer Journey Mapping vor. MathWorks erstellt Software für komplexe Fragestellungen, wie z.B. Software für Kollisionsvermeidung. MathWorks wollte im zitierten Fallbeispiel einfache Hardware, wie Lego Mindstorms oder Arduino, an ihre Software anbinden. Unglücklicherweise schafften es nur 20 von 600 Nutzern die dafür nötigen Support-Pakete herunterzuladen und zu installieren. Seitens der Marketing-Abteilung war klar, dass es daran lag, dass die Kunden nicht die richtige Software-Version für die Pakete installiert hatten. Sie schlugen daher eine Hinweismeldung vor, welche die Anwender auf dieses Problem hinweist. Das UX-Team hingegen war der Auffassung, dass der Prozess für die Installation viel zu lange dauerte bzw. zu viele Schritte beinhaltete.

Im Ergebnis kam es zu Spannungen zwischen den Mitarbeitern von Marketing und UX. Beide einigten sich dann darauf Kunden nach ihren Erfahrungen zu fragen und die Ergebnisse in Customer Journey Maps zu dokumentieren. Da die Zeit knapp war, konnten aber keine umfangreiche Customer Journey Maps erstellt werden. Daher nutzte das Team eine Kombination einer einfachen Schmerzskala mit Smilies und einer einfachen Prozessdarstellung mit 6 Schritten.

Dies wurde den Testpersonen als leeres Template am Ende eines einstündigen Interviews vorgelegt. Die Testpersonen füllten das Template aus und beschrieben so ihre Erlebnisse bei der Installation. Testpersonen und Interviewer gingen anschließend durch diesen Prozess und diskutierten die Erlebnisse. Die so entstandenen Geschichten wurden verglichen und im Unternehmen kommuniziert. Da die Geschichten sehr komprimiert und anschaulich waren, wurden sie im Unternehmen u.a. von der Marketing-Abteilung aufgegriffen.

Abschließend benannten die Autoren noch die Vor- und Nachteil des Verfahrens:

Siehe auch

Lightweight Journey Mapping: The Integration of Marketing and User Experience through Customer Driven Narratives

chi2016: Use Your Words – Designing One-Time Pairing Codes to Improve UX

Die Welt der Connected Devices erfordert aktuell noch, dass Geräte miteinander verbunden bzw. „gepairt“ werden. Dazu geben Anwender einen Pairing-Code, der auf Gerät A angezeigt wird, in Gerät B ein. Da diese Pairing-Codes aus Sicherheitsgründen aus Buchstaben in Groß- und Kleinschreibung und Zahlen bestehen, ist die manuelle Übertragung des Codes aufwändig und fehleranfällig.

Beispiel: 1wEkXyilO023A

Dieses Paper der University of London und BBC Research beschäftigt sich daher mit der Frage, ob es möglich ist, die Codes für das Pairing von Geräten zu vereinfachen. Grundanforderung dabei ist, dass die Codes sowohl sicher als auch leicht einzugeben sind.

Die Grundidee ist es, auf die zufällige Mischung von Buchstaben und Zahlen zu verzichten und stattdessen Codes zu verwenden, die sich wie normale Worte lesen. Worte sind leichter zu merken und damit schneller einzugeben, als ohne Sinn kombinierte Zeichen. Damit es sicher ist, sprich einer Brutforce-Attacke lang genug Stand hält, müssen laut der Untersuchung immer drei bis vier Worte mit min. 3 Buchstaben kombiniert. Codes könnten damit zukünftig beispielsweise wie folgt aussehen:

  • Gib mal das
  • richtige pferde batterie stapel

Die Übertragung dieser Codes ist offensichtlich weniger fehleranfällig und einfacher.

Siehe auch

Use Your Words: Designing One-time Pairing Codes to Improve User Experience