Warum das so ist, habe ich hier beschrieben: English first

Es würde mich freuen, wenn diejenigen, die den Webzeugkoffer schon länger verfolgen, dem Link zum jungen Blog folgen und ihren Feedreader aktualisieren. Hier wird es so schnell nichts Neues zu lesen geben. Sorry

Sketch dominiert – nicht nur als Software

Die Umfrageergebnisse gibt’s hier: Design Tools Survey

Die Seite uxtools.co bietet übrigens eine ausführliche und aktuelle Übersicht für UX-Tools.

Natürlich, Mobile First sollte es sein. Aber nicht unreflektiert und ohne Kontext. Und ja es gibt sogar noch Anwendungsfälle für Desktop First and only: Mobile UX isn’t just about breakpoints

Wie sich mit alltägliche Design-Sünden einfache Designprinzipien erklären lassen: 4 Design Principles My Landlord Doesn’t Understand, Apparently

Zur besseren Lesbarkeit und Scannen von Inhalten trägt auch das Layout entscheidend bei. Zigzag Image–Text Layouts Make Scanning Less Efficient. Wobei das nicht immer gilt. Apple z.B. kann es sich leisten, kreativer zu sein und stützt durch das Brechen von Konventionen sogar das Storytelling.

Wie erklär ich es dem Stakeholder? Gute Ansätze zum Zählen, Messen und Wiegen von UX: Measuring and Quantifying User Experience

Auf den zweiten Artikel verweise ich hier mal: UX is dead, long live the User Experience!

Das werden erstmal keine tiefer gehende Fachartikel werden, da das Schreiben in einer anderen Sprache zunächst mal aufwendiger ist. Vielmehr sollen das kleine Übungen mit fachlichem Bezug zu meiner täglichen Arbeit sein. Dadurch möchte ich erst mal meinen aktiven Wortschatz erweitern und für mich neue, „englischere“ Formulierungen dazulernen. Parallel dazu werde ich auch bei der Arbeit mehr Englisch sprechen.

Zum Abschluss noch ein Klassiker:

Well, Amazon have X, Y and Z, so we should too!

In einem Artikel auf medium.com geht es um schlechte Einflüsse auf Design. Man kann es auch Design for me & Design like them nennen. Es passiert v.a. dann, wenn man nur sich selbst als Nutzer sieht (ich habe Empathie) oder, wenn man andere/die Konkurrenz unreflektiert kopiert (die können das).

Die Anderen

Es spricht natürlich nichts dagegen Benchmarking zu betreiben bzw. die Konkurrenz zu beobachten. Im Gegenteil, ist das ein wichtiger Baustein im Rahmen einer Kontextanalyse. Aber bitte bloß nicht einfach schnell die anderen kopieren – auch wenn sie erfolgreich sein mögen. Denn der Erfolg anderer basiert oft auf anderen Voraussetzungen.

• Sie haben andere Kunden
• Sie werben anders
• Sie haben anderen Traffic
• Sie haben einen anderen Device Mix
• Sie machen andere Fehler (!)
• usw.

Ändert man nur eine Variable (Voraussetzung), kann das ganze System in sich zusammenfallen. Wenn schon, dann muss man Beobachtungen bei der Konkurrenz im Kontext und zu den Zielen der eigenen Kunden/Nutzer betrachten.

Vergleichtest und Wettbewerbsanalyse

Ein erster Schritt ist ein Test anderer Websites. Man macht dann z.B. einen Usability-Test mit zwei, drei Seiten von Wettbewerbern und der eigenen. So lässt sich schon mal herausfinden, ob man unter dem Aspekt Usability besser oder schlechter liegt, als die Konkurrenz. Man gewinnt also erste Ansätze für wirklich relevante Anpassungen und Verbesserungen. Je nach Testobjekt aber auch nur ausschnittweise, z.B. beim Test einer Warenkorb-Seite. Besser noch, man macht eine umfassende Analyse des Wettbewerbs: How To Do A UX Competitor Analysis.

Der erweiterte Kontext und UX Research

Neben guten Benchmarks ist ein möglichst umfassendes Verständnis der Nutzerziele und -Tasks, bezogen auf das eigene Angebot, entscheidend. Aber Vorsicht! Wer nur Usability als Kriterium ansetzt, kann immer noch weit vorbei zielen. Gut benutzbar, aber nicht relevant. Dazu ein paar Quellen zur erweiterten Kontextanalyse und UX Research:

• User Analysis Before Diving Into Design
• Complete Beginner’s Guide to UX Research
• Method Cards – Tools to bring human-centered design into your project
• UX Project Checklist

Was wirklich zählt

Nicht durchs Kopieren wird man besser. Fokus ist am wichtigsten:

• Deine Nutzer & Kunden
• Ihre Bedürfnisse & Ziele
• Deine Ziele & Visionen

Desktop first and only? Komm‘ ich mit dem Laptop drauf? Wahrscheinlich auch noch mit Schreibmaschine geschrieben, eingescannt und hochgeladen.

UX buzzed weiter. Schon 2009 und jetzt in 2017 immer noch. Kein Unternehmen mehr, das keine UXer sucht. Oft zu eng gefasst. „Wir brauchen einen UX Designer“ ist das neue „Wir brauchen ein Blog“.

It’s a tiny acronym for a huge area, but many companies only use it in a very narrow way. It’s often used to mean something like an “Interaction Designer”, who works on the details of how people interact with an interface.

Hinter den beiden Buchstaben U und X erstreckt sich ein sehr weites Feld, das weiter über schönes Malen hinaus geht. Eine aktuelle und ausführliche Einleitung dazu: How to Get Started with UX – And what ‘UX’ really means

Jeder kann zeichnen – mehr oder weniger – und sollte das auch tun. Selbst noch so krakelige Scribbles sind eine gute Ausgangsbasis. Außerdem gibt’s Übungen, mit denen man seine Fertigkeiten verbessern kann: 6 methods to improve sketching skills in user experience

Was ist ein UX Review und wie macht man das? Auch Reviews sind nur ein Teil unserer täglichen Arbeit. Eine Einführung, die anhand einer Disziplin zeigt, dass UX Design nicht nur was mit Malen zu tun hat: How to do a UX Review

People ignore design that ignores people.
Frank Chimero

No fear. As the maths phobic I am what follows is more about an underlying thinking approach. Phew

UX is neither a science nor pretty paint on the system. It’s still and basically about human beings, their needs and experiences with web sites and apps. Some inequations may give better guidance.

• Strategy ≠ Pants
• Concept ≠ Meeting+Brainstorming
• UsersNeeds ≠ You + (HIPPO*GutFeeling)
• User ≠ GoogleBot
• Persona ≠ Testimonial
• Empathy ≠ Data
• Emotion ≠ StockPhotoPeople
• Useful ≠ FeatureRich

One can think about many more inequations. Basically for me one key lies in learning by inequations and antipatterns.

Give it a try and also keep the UX principles in mind. A classic from 52 weeks of UX: 10 Principles of UX

Tools können manchmal im Weg stehen. Stift und Papier sind oft der beste Startpunkt, aber irgendwann stellt sich doch die Frage nach dem passenden Tool, gerade dann, wenn es vom Grundmodell zum Design, Prototypen bis hin zum fertigen Produkt gehen soll. Einen Überblick bietet UXTOOLS.co

Schlechte Icons sind nervig und halten die Nutzer auf. Ein Artikel über schlechte Icons und Gegenmaßnahmen. Garniert mit einem fast unglaublichen Beispiel realen Irrsinns aus der Praxis. Bad Icons: How to Identify and Improve Them

Zur Lesbarkeit von Tabellen Designing Tables to be Read, Not Looked At und allgemein zur Lesbarkeit 15 Minuten für gute Webtypografie mit CSS.

Und noch eine Buchvorstellung

Jens Grochtdreis hat ein schlankes, aber trotzdem gehaltvolles Buch zu modularer Webentwicklung geschrieben.

Im Laufe der Lebenszeit eines Projektes wird häufig schlecht wartbarer Code geschrieben. Die Gründe dafür sind vielfältig.

Grundlegend und auf den Punkt, gibt es Anleitungen dazu, wie man effizienten und gut wartbaren Code schreibt, der schließlich auch Grundlage für sinnvoll modulare Frontendentwicklung ist. Hier die Website zum Buch: Modulare Webentwicklung

Kurz und knapp bei DECAF

Jetzt! Und das ist eigentlich schon zu spät! Der Mobile First Index wird uns fressen und die Nutzer unsere Website nicht benutzen können! Ja, das kann passieren, ist aber kein Grund zur Panik.

Der Begriff mobile first und damit einhergehende Strategien existieren seit gut 8 Jahren. Gut beraten war und ist, wer nicht gleich von der nachfolgenden Hysterie erfasst wurde und kopflos losgerannt ist. Auch wenn Luke Wroblewski in dem oben verlinkten Artikel von 2009 recht hatte und damit den Grundstein für viele sinnvolle Entwicklungen und Strategien legte.Mittlerweile haben viele Website-Betreiber ihre Erfahrungen gemacht. Wahrscheinlich genauso viele negative, wie positive Erfahrungen. Mobile first wird mittlerweile, zumindest in seiner radikalen und oft kurzsichtig umgesetzten Form, auch infrage gestellt. Radikal, weil immer und ausnahmslos mobil zuerst betrachtet und umgesetzt – oft zu einfach. Kurzsichtig, weil vermeintlicher Ballast überhastet weggeworfen und das was übrig bleibt responsiv gemacht wird. Auf der Strecke bleiben dann oft – Überraschung! – die Nutzer.

Noch ein kleiner retro Exkurs zu radikalen Ansätzen im Webdesign. Fluides Webdesign. Es galt als barrierefrei per se und überhaupt war es gerade im Trend, so ca. 2005. Viele werden sich noch erinnern. Reihenweise wurden schnell und scheinbar ohne weiter darüber nachzudenken, Websites verflüssigt. Im wahrsten Sinn. Das Ergebnis waren oft hässliche und ab bestimmten Monitorgrößen schlecht lesbare Websites. 1.000+x Pixel breite Textzeilen. Barrierefrei? Hier half ein ganz einfaches Mittel: max-width.

Mobile first als gedanklicher Leitsatz

Mobile first ist nicht eine (technische) Lösung. Sondern mehr ein Denkansatz, eine Methode, vielleicht sogar eine Philosophie, mit der man an die (Weiter-) Entwicklung von Websites, Shops, Apps etc. heran geht – möglichst einfach und erweitert um den mobilen Kontext.

Tweet von @_lizzelo_

Die einfachst mögliche Lösung. Klingt gut und galt schon immer, noch bevor es Smartphones gab. Mobile first ist insofern immer ein guter Ausgangspunkt – zumindest gedanklich. Mobile first zwingt uns zu fokussieren. Aber nicht nur technisch, wie auch Luke Wroblewski 2009 schon feststellte.

So when a team designs mobile first, the end result is an experience focused on the key tasks users want to accomplish without the extraneous detours and general interface debris that litter today’s desktop-accessed Web sites.

Ich denke, dass sich viele bereits im entschlackenden und responsiven Ansatz ihrer Konzepte und Designs verlieren – Desktop-Diät-Wahn. Vergessen dabei aber Nutzer, Content, Technologie und Strategie im Zusammenspiel zu betrachten – den Kontext. Weil sie mobile first zu eng fassen und dabei fast einzig an ihre (responsiven) Frontends denken.

Egal wie, User Experience steht im Mittelpunkt und muss überall, in jedem Kontext bestmöglich sein. User first!

Links zum Weiterlesen

Mobile First und verschiedene Einschätzungen dazu:

• Mobile First
• Where Do We Go from Mobile First?
• Mobile First Is Just Not Good Enough: Meet Journey-Driven Design
• Mobile First, Desktop Worst
• Hört bitte auf von Mobile First zu sprechen
• Mobile First oder Context First? Wann Mobile First die falsche Strategie ist

Besser man hält erstmal kurz und knapp fest, was man warum, wo und wie ändern möchte. Wie getestet werden soll und wie man das messen möchte. Hier z.B. ein Steckbrief für Variantentests, wie wir ihn auch schon verwendet haben.

Solche Test-Steckbriefe stehen am Anfang des Testprozesses. Noch vor der Ausarbeitung des detaillierten Testkonzepts, bis hin zum konkreten Entwurf, sollte man sich darüber im Klaren sein, was man konkret testen möchte. Man befasst sich zunächst also mit der Testidee und der Hypothese für einen Test.

Die Steckbriefe sind außerdem bei der Entwicklung einer langfristigen Teststrategie und entsprechenden Testreihen ein handliches Tool. So z.B. wenn man ganze Bestellprozesse über mehrere Seiten hinweg testen möchte. Das braucht ein klares Ziel, sinnvoll aufeinander aufbauende Schritte und manchmal auch Ausdauer (Wochen und Monate). Mit Hilfe der Steckbriefe lässt sich so die „Teststory“ erzählen und man behält einen besseren Überblick.

Unter dem Artikel findet Ihr einen Link zu einer kleinen Vorlage, mit der sich ganz schnell erste Testideen und Hypothesen festhalten lassen. Hier jetzt noch ein paar Anmerkungen dazu.

Die Hypothese

Vielen Tests fehlt eine (gute) Hypothese. Ohne Hypothese ist es aber schwer, gezielt und am Ende auch mit Erfolg und Erkenntnis zu testen. Eine gute Hypothese ist noch kein Garant für den Erfolg eines Tests. Sie garantiert aber zumindest einen Erkenntnisgewinn.

A thoroughly researched hypothesis doesn’t guarantee a winning test. What it does guarantee is a learning opportunity, no matter the outcome (winner, loser, or inconclusive experiment.) – How to Write a Solid A/B Test Hypothesis

Eine gute Testhypothese zu formulieren ist eigentlich gar nicht so schwer und folgt immer dem gleichen Aufbau.

Wir beobachten dass _______

Wenn wir _______ können/werden Nutzer _______

Dadurch _______

Ist es nicht möglich, anhand dieser groben Struktur eine runde Hypothese zu formulieren, ist die Sachen eigentlich auch keinen Test wert. Eine Hypothese lautet nämlich nicht: wir machen den Button größer und dadurch steigt die Conversion Rate…

Problem

Aus der Hypothese …Wir beobachten dass

Kein Test einfach so ins Blaue. Wenn wir einen Test machen, dann v.a. deshalb weil wir ein bestimmtes Problem lösen möchten. Wir brauchen also eine Problembeschreibung.

Lösung

Aus der Hypothese …Wenn wir

Beschreibt die Anpassungen/Änderungen, die gemacht werden, um das beschriebene Problem zu lösen, bzw. das Ziel zu erreichen.

Auswirkungen

Aus der Hypothese …können/werden Nutzer

Beispiel: Es werden dann mehr Nutzer den Button anklicken und im Bestellprozess einen Schritt weiter gehen.

Aus der Hypothese …Dadurch

Dadurch werden, bei sonst gleichem Nutzerverhalten, mehr Nutzer den Bestellprozess durchlaufen.

Ziele und KPIs (Kennzahlen) – Erfolgsmessung

Es handelt sich meistens um Conversion-Ziele, bei denen es v.a. darum geht, dass Nutzer bestimmte Aktionen ausführen (oder auch sein lassen), was sich im Ergebnis dann insgesamt auf Registrierungen, Conversion Rates, Verkäufe, etc. positiv auswirken soll. Deren Erreichung lässt sich anhand konkreter Kennzahlen (KPIs) messen.

Im Beispiel oben soll sich die Conversion Rate und damit auch die Bestellungen erhöhen. Aber nicht nur das Gesamtergebnis (Macro Conversion) ist dabei messbar. Sondern z.B. auch die CTR oder Click Through Rate (Micro Conversion) der Seite, auf der die Änderung gemacht wurde. V.a. beeinflusst durch die Klicks auf den Button (Micro Conversion), die wiederum auch messbar sind. Im Beispiel hätten wir dann zumindest folgende Kennzahlen:

• CR (Conversion Rate) – Macro Conversion
• Bestellungen – Macro Conversion
• Klicks auf den Button – Micro Conversion
• CTR – Micro Conversion

Erreichen wir unser Ziel nicht – mehr Nutzer in und durch den Bestellprozess zu führen – dann haben wir anhand der verschiedenen Messpunkte wieder gute Ansatzpunkte für weitere Schritte und Tests.

Die Vorlage für Variantentests

Die Vorlage habe ich als Google Tabelle abgelegt: Steckbrief für Variantentests

Zum Nachlesen

Zum Abschluss eine kleine Sammlung von Quellen zur vertiefenden Recherche:

• The Surprising Power of Online Experiments
• How to Write a Solid A/B Test Hypothesis
• Begin with a Problem and Hypothesis
• Micro Conversions – Definition, Relevance and Tracking
• 6 A/B Testing Myths
• Signifikanzrechner für A/B und multivariate Tests