Goulasz

Hallo @nmike! Inhaltlich ist finde ich schon alles gesagt. Ich möchte eigentlich auch nur zum Ausdruck bringen, wie sehr ich mich über deine sachliche und besonnene Reaktion freue. Grade in letzer Zeit nehme ich hier für kritische, aber berechtigte Anmerkungen zu Projektanträge vermehrte, teils auch verbal drastische Rechtfertigungsversuche wahr und deine Antwort finde ich grade vor diesem Hintergrund sehr professionell und sachlich. Wenn du mit der gleichen Art an dein Projekt in Runde 1,5 herangehst, sehe ich da keine großen Probleme. Gruß, Goulasz

Nach längerem Überlegen und intensiver Beratung durch @Sullidor habe ich mich auch dazu entschieden, mir eine Smartwatch, konkret, eine Gear 2 Classic anzuschaffen. Abgesehen davon, dass ich meine Termine damit irgendwie viel besser auf die Kette kriege als mit "Papierkalender und Stift" oder "Nur Smartphone" nutzt mir die Schlafaufzeichnung (ich trage sie Nachts) relativ viel, um mein Schlafverhalten rückwirkend zu analysieren und mein "ins Bett gehen" so anzupassen, dass ich zu dem Zeitpunkt, zu dem meine Kinder meistens unruhig werden, schon die erste Tiefschlafphase hinter mir habe. Davon abgesehen hat mich dieses Watchface hier einfach überzeugt.

Gesagt, getan:

Hallo Welt! Jetzt gab es eine ganze Weile lang keine neuen Inhalte hier aber inspiriert durch einen interessanten Thread im Fachinformatiker.de-Forum habe ich mich entschlossen, einen Beitrag zu einem allgemein gültigen Thema zu schreiben, das mir seit einer Weile sehr am Herzen liegt. Den 7 Dialogprinzipien - Intro Die 7 Dialogprinzipien, in ISO 9241-110 als "Grundsätze der Dialoggestaltung" beschrieben, beschreiben, wie Nutzer mit interaktiven Systemen interagieren und welche Prinzipien dieser Interaktion allgemein zu Grunde liegen. Sie können positiv besetzt und erfüllt werden, oder verletzt. Werden sie verletzt, entstehen "Nutzungsfehler". Nicht so, Eierlegende Wollmilchsau, CC-BY-SA 2.5, Autor: Georg Mittendecker, Entnommen aus: https://commons.wikimedia.org/wiki/File:Wollmilchsau.jpg Wichtig ist hier die feine Unterscheidung der Begrifflichkeiten. Ich spreche von "Nutzungsfehlern" nicht von "Nutzerfehlern". Interaktive Systeme, deren Benutzungsschnittstellen(User Interfaces) so gebaut sind, dass sie zum Nutzungskontext der angepeilten Benutzergruppe passen, sind wesentlich weniger fehleranfällig als Systeme, die versuchen, die eierlegende Wollmilchsau für "alle Benutzer jemals" zu sein. Eine nicht vollständige oder fehlerhafte Benutzergruppenanalyse ist einer der Hauptgründe für viele Usability-Probleme und unzufriedene Benutzer. Aber genug Einführung. Hier kommen sie. Die 7 Dialogprinzipien - Übersicht Vorweg: Die Großzahl auftretender Nutzungsfehler entsteht aus Verletzungen der ersten 3 hier genannten Dialogprinzipien. Zur Illustrierung der Dialogprinzipien halten wir uns an die folgende Aufgabe: "Einen Mietwagen buchen". Aufgabenangemessenheit Ein interaktives System ist aufgabenangemessen, wenn es den Benutzer unterstützt, seine Arbeitsaufgabe zu erledigen, d. h., wenn Funktionalität und Dialog auf den charakteristischen Eigenschaften der Arbeitsaufgabe basieren, anstatt auf der zur Aufgabenerledigung eingesetzten Technologie. Es kommen keine unnötigen oder nicht zur Lösung der Aufgabe benötigten Schritte vor. Standort-Buchung hertz.de, Screenshot, aufgenommen am 13.07.2017 Beispiel: Wenn ich bei hertz.de als Standort "Kassel" auswähle, kann ich die Standortgruppe "Kassel DE (4 locations)" anwählen. Erst wenn ich alle anderen Eingaben getätigt habe und im Formular weitergehen möchte, muss ich einen spezifischen Standort auswählen. Ein unnötiger Schritt, den man direkt im ersten Formular bearbeiten können sollte. Selbstbeschreibungsfähigkeit Ein Dialog ist in dem Maße selbstbeschreibungsfähig, in dem für den Benutzer zu jeder Zeit offensichtlich ist, in welchem Dialog, an welcher Stelle im Dialog er sich befindet, welche Handlungen unternommen werden können und wie diese ausgeführt werden können. Beispiel: In einem weißen Suchfeld zur Fahrzeugsuche steht neben einer Lupe der Text "Hier können Sie durch Texteingabe Fahrzeugtypen suchen" Erwartungskonformität Ein Dialog ist erwartungskonform, wenn er den aus dem Nutzungskontext heraus vorhersehbaren Benutzerbelangen sowie allgemein anerkannten Konventionen entspricht. Beispiel: Ein Klick auf ein kleines Kalender-Icon in einem Auswahlbereich zur Abholung des Fahrzeugs öffnet ein Datepicker-Steuerelement. Erlernbarkeit / Lernförderlichkeit Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen der Nutzung des interaktiven Systems unterstützt und anleitet. Beispiel: Wenn erkannt wird, dass der Benutzer die Webseite zum ersten mal besucht, wird er durch ein Assistenzprogramm und verschiedene Highlights durch den Buchungsprozess geleitet. (Abdunkeln von zum momentanen Zeitpunkt nicht benötigten Steuerelementen) Steuerbarkeit Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist. Negativbeispiel: Eine fehlerhafte Eingabe in einem Kontaktformular führt dazu, dass der Nutzer das gesamte Formular erneut ausfüllen muss, anstatt an den Punkt zu springen, in dem die Falscheingabe liegt. Fehlertoleranz Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann. Beispiel 1: Der Benutzer gibt im Texteingabefeld das Datum "23.12.2017" ein. Das System gibt einen Fehler aus und weist ihn darauf hin, dass das Datumsformat dem folgenden Schema genügen muss. "MM-DD-YYYY". Noch besser wäre hier allerdings, statt einer Benutzereingabe eine Auswahl durch z.B. ein Datepicker-Element zu ermöglichen.Beispiel 2: Der Benutzer gibt eine E-Mail Adresse im falschen Format an und erhält eine Fehlermeldung, die als Beispiel ein korrektes Format anzeigt. Individualisierbarkeit Ein Dialog ist individualisierbar, wenn Benutzer die Mensch-System-Interaktion und die Darstellung von Informationen ändern können, um diese an ihre individuellen Fähigkeiten und Bedürfnisse anzupassen. Beispiel 1: Ein Benutzer kann dauerhaft speichern, in welchem Format Zahlen und in welcher Sprache Texte in einer Anwendung dargestellt werden sollen.Beispiel 2: Ein Benutzer hat die Möglichkeit, ein Benutzerkonto anzulegen und dort Informationen zu speichern, die er beim nächsten Lösen der Aufgabe nicht mehr manuell eingeben muss. Die 7 Dialogprinzipien - Fazit So viel zu merken ist es eigentlich gar nicht. Und wenn man die ersten 3 Prinzipien verinnerlicht hat und weiß, worauf es beim Entwickeln von Benutzungsschnittstellen ankommt, kann man das Fehlerpotential seiner interaktiven Systeme drastisch senken. In diesem Sinne, viel Spaß beim Überarbeiten und Entschuldigung im Voraus für all die Verletzungen der Dialogprinzipien, die ihr nach dem Lesen dieses Beitrags wahrnehmen werdet. Gruß, euer "devopsdad" Patrick

Hallo @StefanE Da hast du aber recht, genau sowas ist unter anderem der Job eines Usability Engineers. Eine der wichtigsten Aufgaben ist es, vor der Entwicklung eines interaktiven Systems Benutzer in ihrem Benutzungskontext zu beobachten und Nutzungskontextbeschreibungen zu erstellen. Ich hole mal etwas aus und gebe Beispiele dazu. --- (Fiktives) Beispiel 1: Eine Hersteller medizinischer Geräte konzipiert ein neues Monitoring-System für OP-Säle. Die Maschine wird am Reißbrett entworfen, ist mit modernster Technologie ausgestattet. Der Herstellter beschäftigt sich nicht mit Usability und geht ohne große Praxistests durchzuführen in die Produktion. Nach dem Ausrollen wird festgestellt, dass der kapazitive Touchscreen des Geräts nicht mit den im OP üblicherweise verwendeten Handschuhen nutzbar ist und ein resistiver Touchscreen hätte verwendet werden müssen. Die Firma geht pleite. (Fiktives) Beispiel 2: Eine Firma entwirft eine neue Wecker-App. Die Firma beobachtet und interviewt Nutzer, die üblicherweise Wecker benutzen und stellen fest, dass neben dem pünktlichen Signalisieren der Weckzeit häufig die Funktionalität gewünscht wird, anstelle der "aktuellen Zeit" und der "Weckzeit" die "Restzeit bis zum Wecksignal" ausgegeben wird. So könnte man beim nächtlichen Aufwachen ohne groß rechnen zu müssen, wonach man erst mal wach ist, erkennen, wie lange noch "Zeit" ist. Das folgende Erfordernis wird identifiziert: "Der Benutzer muss wissen, wie viel Zeit er noch bis zum Wecksignal hat, um entscheiden zu können, ob er sich noch einmal hinlegt oder nicht." Die App wird häufig genutzt und das Unternehmen wird von einem Smartphonehersteller aufgekauft. Die Funktionalität geht in das Betriebssystem des Telefons über. --- Ihr wärt überrascht, wie viele Hersteller es gibt, die aufgrund ihrer Größe und Expertise eigentlich genau wissen müssten, worauf sie in Sachen Usability achten müssten, es dennoch nicht tun, und damit bares Geld und/oder Reputation einbüßen. Ein Beispiel aus der echten Welt. "Die Funktionssuche in Microsoft Office 2016-Produkten" Eigentlich ein gutes Feature. Man gibt dort Dinge ein, z.B. "Drucken" und erhält dann eine Liste aller Funktionen, die mit dem Thema "Drucken" zu tun haben. Wird aber selten genutzt oder ist gar nicht bekannt. Wie kommt das? Das Steuerelement dazu verbirgt sich hinter "Was möchten Sie tun?". Das Element, das eigentlich ein Suchfeld ist, ist nicht unmittelbar als solches erkennbar. Das Dialogprinzip der "Erwartungskonformität" ist verletzt. Ebenso hat das Element keinen "Aufforderungscharakter". Es ist nicht unmittelbar erkennbar, das hier eine Eingabe möglich ist. Zuletzt ist das Dialogprinzip der "Selbstbeschreibungsfähigkeit" verletzt, da nicht klar ist, was man mit dem Element eigentlich tun kann. Sehen wir uns meinen eben dazu im besten Mockup-Tool der Welt (MSPAINT FUCK YEAH!) erstellen Gegenentwurf an: Das Element sieht aus wie ein Suchfeld. Es ist weiß, enthält eine Lupe, einen Textcursor und mein erster Textentwurf aus der Hüfte "Funktionssuche" ist zumindest für mich aussagekräftiger als "Was möchten Sie tun?". Der nächste Schritt nun wäre, mit mehreren Entwürfen des Designs und des Textes Usability-Tests durchzuführen und die größte Akzeptanz zu ermitteln. Papier oder Screenshot reicht hier in der Regel schon. 5 Nutzer befragen, was sie sich unter dem Element vorstellen und dann ggfs. basierend auf dem Feedback anpassen. Je mehr, desto besser. Ich hoffe, es ist etwas klarer geworden, worum es hier geht. Gruß und einen guten Arbeitstag euch, Goulasz P.S.: Wer sich damit und besonders mit "Do it yourself Usability Testing" (also ohne teuren Profi, sondern mit den Mitteln, die man in der Firma zur Verfügung hat) auseinandersetzen möchte, dem sei das folgende Buch wärmstens ans Herz gelegt. Und bitte, bitte in Englisch bestellen. Die deutsche Übersetzung ist imho nicht zu empfehlen. Don't Make Me Think: A Common Sense Approach to Web Usability (Amazon, kein Affiliate-Link)

Hallo @Crash2001! Für mich klingt das abwertend. Aber sei's drum, ich will mal nicht so sein. UX heißt hier übrigens "User Experience". "User Experience Lieferungen" sind hier also die Ergebnisse der einzelnen Teilprozesse. Als Usability Engineer bin ich Schnittstelle zwischen den Projektverantwortlichen auf Kunden- bzw. Anwenderseite und den Umsetzenden auf der Auftragnehmerseite. Zum einen unterstütze ich alle anderen Rollen bei ihrer Arbeit, zum anderen sehe ich als Verantwortlicher zu, dass alle Rollen die Mittel zur Verfügung haben, die sie zur Erfüllung ihrer Tätigkeiten benötigen. Ich organisiere also für den User Requirements Engineer Interviewpartner und schaffe Situationen, in denen er Anwender beim Lösen des Problems, bei dem das Produkt, das entwickelt werden soll, helfen soll, beobachten kann. Ich kümmere mich um die Erstellung von Listen relevanter Zielgruppen für die Rekrutierung von Usability Testenden, rekrutiere diese ggfs. direkt oder gebe diese Informationen an eine Agentur weiter. Ich diene dem Informationsarchitekten und dem Interaktionsdesigner sowie dem User Interface Designer als ständiger Sparrings- und Reviewpartner und gleiche als Gesamtverantwortlicher zusätzlich die Ergebnisse mit den Nutzungsanforderungen ab. So gesehen bin ich in der Rolle des "Usability Engineers" eine Art Projektmanager für den gesamten Teil eines Projekts, in dem es in Gesamtverantwortung um "Usability" geht. Schwammig ist das nicht unbedingt. Zumindest nicht nach meiner Sicht. Das "Hochgestochene", das du meinst, rührt daher, dass es, wenn man die formalen Inhalte der ISO kennt, eine sehr trennscharfe und spezifische Sprache mit spezifischen Begriffen gibt, damit sich die verschiedenen Usability Professionals eben nicht darüber streiten müssen, ob ein Kunde jetzt etwas "will" oder "braucht", sondern dass klar zwischen Erfordernissen und Anforderungen unterschieden wird. Am Agile Monday Kassel habe ich dazu einen Vortrag gehalten. Die begleitenden Slides dazu findest du hier: https://de.slideshare.net/secret/lgsDzRLiNVREp7 Eine Videoaufnahme, auf der man die Erläuterungen dazu findet, existiert leider nicht. Würde ich das alles so im Detail erläutern, müsste ich dafür aber vermutlich schon fast eine Rechnung schreiben. Gruß, Goulasz

Hallo @Crash2001! Basierend auf der ISO-9241 und diversen Fachpublikationen zur Gestaltung interaktiver Systeme ergeben sich folgende Rollen, die ein Usability Professional im Laufe des Prozesses zur Gestaltung gebrauchstauglicher Systeme einnehmen kann: TL;DR: Usability Engineer: Managt den UX Prozess User Requirements Engineer: Beschreibt Nutzungskontext und Nutzungsanforderungen Usability-Tester: Führt Usability-Tests aus Informationsarchitekt: Kreiert die Informationsarchtitektur und die Navigationsstruktur Interaktionsdesigner: Definiert die Interaktion zwischen Mensch und System User Interface Designer: Implementiert das Benutzererlebnis Mittelfassung: Usability Engineer: Betreut in einer Querschnittsfunktion den menschzentrierten Gestaltungsprozess, quasi der "SCRUM Master" des Prozesses. Idealerweise hat er bereits Erfahrung in der Ausfüllung der anderen Rollen. Mindestens jedoch User Requirements Engineer und Usability Tester. User Requirements Engineer: Identifiziert und beschreibt den Nutzungskontext, leitet daraus Erfordernisse und Nutzungsanforderungen ab. Er priorisiert die Nutzungsanforderungen, damit die Erfordernisse erfüllt werden können Usability-Tester: Evaluiert die Benutzungsschnittstellen und erstellt für die verschiedenen Stadien im Gestaltungsprozess die entsprechenden UX Lieferungen, z.B. einen Usability-Testbericht, quantitative/qualitative Umfragen und Ähnliches Informationsarchitekt: Er kreiert und organisiert die Struktur für das effiziente Auffinden von Informationen im interaktiven System durch den Benutzer Interaktionsdesigner: Er konzipiert und definiert die Interaktion zwischen Mensch und interaktivem System auf Basis der Nutzungsanforderungen und der zu erledigenden Aufgaben. Die für die Erstellung der Interaktion genutzten Szenarien werden gemessen an der Effektivität, Effizienz und dem Grad der Zufriedenstellung im Verlauf der User Experience User Interface Designer: Er implementiert letztendlich das konkrete Benutzererlebnis anhand von Gestaltungsregeln, Styleguides und den Ergebnissen des Informationsarchitekten, des Interaktionsdesigners und des User Requirements Engineers. Langfassung: Setz dich mit der ISO auseinander und/oder besuch entsprechende Weiterbildungen zu dem Thema, bevor du hier mit Begriffen wie "heiße Luft" um dich wirfst. Nur weil es Menschen gibt, die keine Ahnung haben und Begriffe "buzzwordig" verwenden, trifft das nicht auf alle zu. Gruß, Goulasz P.S.: Zum besseren Verständnis hier der Prozess zur Gestaltung interaktiver Systeme. Wer Anleihen an William Edwards Deming erkennt, darf sie behalten:

Moin @Kimo1785! Die meisten Data-Mining Algorithmen existieren ja schon. Die "Magic" bei dem Thema ist es ja, die richtigen Trainingsdaten zu wählen und verschiedene, passende Algorithmen damit zu füttern, um dann zu entscheiden, ob die Ergebnisse jetzt Korrelationen oder Kausalitäten sind und welche Kombinationen weiter verfolgt werden. R(mit RStudio), Knime und Konsorten bieten dir da out of the box viele Möglichkeiten, Daten zu clustern, auszuwerten und Schlüsse zu ziehen. Schon mit verhältnismäßig überschaubaren Datenmengen. Da brauchst gar keine riesigen Datenbanken mit 3 Fantastilliarden Datensätzen. Für die meisten Anwendungsfälle im B2B-Bereich reicht aber schon etwas logisches Denkvermögen und Wissen über Geschäftszusammenhänge um Daten richtig in Kontext zu setzen. Das kann man sich auf einem Niveau, das für den Einstieg reicht, auch locker privat aneignen. Ich bin "nur" FiAe und hatte 4 Punkte in Mathe im Abi, aber beschäftige mich jetzt trotzdem mit den Themen. Klar ist der Aufwand des Verstehens für mich etwas höher als für jemanden, der die Grundlagen hinter den Mechaniken und Algorithmen im Schlaf beherrscht, aber es funktioniert trotzdem. Gruß, Goulasz