it-swarm.com.de

Haben wir eine Taxonomie der UX-Anforderungen für Softwareprodukte?

Ich bin ein Forscher auf UX. Mein Forschungsziel ist es, Softwareentwicklern in frühen Stadien, d. H. Dem Anforderungs-Engineering, zu helfen, mit UX-Anforderungen umzugehen, selbst wenn ihre Kenntnisse über UX und ID schlecht sind. Sie wissen, dass nicht alle Entwicklerunternehmen Zugriff auf UX- und Usability-Experten haben.

Bisher habe ich festgestellt, dass eine Herausforderung für Praktiker darin besteht, dass sie nicht wissen, welche Arten von UX-Anforderungen für verschiedene Software als relevant angesehen werden. Daher möchte ich in meiner Forschung eine Ontologie oder Taxonomie der UX-Anforderungen entwickeln (oder wiederverwenden). Der nächste Schritt besteht darin, Werkzeuge/Methoden bereitzustellen, wie diese Anforderungen ermittelt und dokumentiert/dargestellt werden können.

Kennen Sie eine verwandte Quelle? In welcher Liste oder Kategorie von konkreten UX-Anforderungen finden Sie?

Das Ergebnis meiner Forschung wird zu gegebener Zeit für alle kostenlos veröffentlicht.

26
Pariya Kashfi

Der Abschnitt Anforderungen auf der Wikipedia-Seite zum Design der Benutzeroberfläche ist ein guter Anfang. Es bezieht sich auf ISO 9241, insbesondere Teil 10, der zurückgezogen und durch ISO 9241-110: 2006 ersetzt wurde.

Es gibt die UX-Prinzipien , die Mozilla als Schlüsselwörter verwendet, um Fehler in Bugzilla zu markieren, die auf Jakob Nielsens basieren ) Zehn Usability-Heuristiken .

Ich habe kürzlich versucht, die Mozilla-Schlüsselwörter den Dialog-/Gefühlsprinzipien von ISO 9241 zuzuordnen, um zu sehen, wie sie übereinstimmen:

  • Eignung für die Aufgabe
    • uX-Effizienz
    • uX-Implementierungsebene
      • uX-Jargon
  • Selbstbeschreibung
    • uX-Erschwinglichkeit
    • uX-Entdeckung
      • ux-visuelle-Hierarchie
    • UX-Minimalismus
    • ux-userfeedback
    • UX-Ton
  • Kontrollierbarkeit
    • uX-Kontrolle
      • ux-rückgängig machen
    • uX-Unterbrechung
  • Übereinstimmung mit den Benutzererwartungen
    • uX-Konsistenz
    • uX-Modus-Fehler (Sonderfall der UX-Fehler-Verhinderung)
    • ux-natural-Mapping
  • Fehlertoleranz
    • uX-Fehlervermeidung
    • uX-Fehler-Wiederherstellung
  • Eignung zur Individualisierung
  • Eignung zum Lernen

Ich werde irgendwann mit den Definitionen aktualisieren.

Update : Siehe auch Heuristik der psychologischen Verwendbarkeit


† ISO 9241-110: 2006 ist eine 22-seitige PDF, die 108 Schweizer Franken, ~ 110 USD oder 70 GBP kostet. Ich würde gerne von jedem hören, der sie gelesen hat, ob sie es ist ist den Kauf wert.

8
Sam Hasler

Ich bin auch von Beruf Entwickler (und ich habe einen MSc in Software Engineering von einer bekanntermaßen harten Uni), aber heutzutage mache ich UX. Was folgt, kommt aus der Sicht der HCI-Perspektive von UX. Dies wurde mir beigebracht. Dies ist die Schule, zu der ich mich gehöre.

Im Allgemeinen ist UX nicht weit von der IT entfernt: Was Entwicklern an der Software Engineering Unis als "Software-Design" beigebracht wird und worum es bei UML ging, ist im Grunde das, was UX heute tut. Das Software-Design ging Ende der neunziger Jahre, Anfang der 2000er Jahre, mit dem Agile-Boom aus dem Mainstream (ich war dort, ich weiß), so dass es schwierig ist, Leute zu finden, die es tatsächlich üben , aber die meisten von ihnen davon gehört in der Universität.

UX ist ein Liebeskind von Software Engineering and Psychology

Lassen Sie uns dies relativieren, für die ich ein einfaches Diagramm zeichnen werde:

The UX coordinate system

Ich bin mir ziemlich sicher, dass es noch viel mehr Dinge gibt, aber das reicht für eine kurze Illustration.

Das "Micro-IT" -Viertel ist nicht leer, es muss nur keinem Frontend-Entwickler auf der Welt erklärt werden.

Ob Sie es glauben oder nicht, Taxonomien sind beispielsweise auch an allen IT-Universitäten ein Pflichtstudium und werden täglich in der objektorientierten Programmierung verwendet. Es ist dort also nichts Neues.

Den Entwickler verstehen: die gemeinsame Sprache

Für einen Entwickler würde ich mit vertrauten Dingen wie Flussdiagrammen beginnen. Ich habe die Beziehung zwischen Flussdiagrammen und sogenannten Finite-State-Maschinen (wieder eine erforderliche Studie) in einem anderen Antwort bei Programmers.SE erklärt

Um zu verstehen, was einem Entwickler beigebracht wurde, sollten Sie ein UML-Buch lesen, wie dieses , (synchronisiert das "iconix-Buch").

Was die Anwendungsfallanalyse betrifft, die im Allgemeinen behandelt, wie sich ein System am besten verhalten sollte, ist immer noch Cockburns Effektive Anwendungsfälle schreiben

Programmierer mögen es zu kategorisieren, und die meisten von ihnen mögen "lego", Design Patterns sind ein guter Anfang. Entwurfsmuster stammten aus der Architektur, gingen dann zur IT und von der IT zur UX. Heutzutage sind Designmuster in der IT immer noch weit verbreitet, aber nicht mehr so ​​verbreitet wie vor 10 Jahren.

Orientierung: Ziele und Warum

Für jede Partei ist es wichtig, die Zielorientierung zu verstehen : Normalerweise arbeiten Programmierer effektiver, wenn sie das Ziel verstehen, das der Benutzer gerne hat. Wir reden so viel über "es muss diesen Knopf und diesen Schatten und diesen Übergang haben", die für einen Entwickler nicht von Bedeutung sind, wenn Sie ihnen nicht sagen, warum.

Ich denke, dass dies manchmal auch in UX ein Problem ist. Viele "Musterbibliotheken" konzentrieren sich auf den Glanzfaktor anstatt auf Ziele und Probleme. Ein Muster sollte immer ein Problemmuster sein und immer die Erklärung enthalten, warum die empfohlene Lösung für dieses Problem funktioniert.

Unterstützen Sie Ihre erklärten Ziele mit Nutzerforschung oder wissenschaftlichen Arbeiten. Vielleicht geben Sie ihnen Live-Demonstrationen oder Statistiken aus der eigenen Forschung des Projekts. Andernfalls ist das Ziel nicht authentisch und Sie werden von den Entwicklern nicht respektiert.

Ich habe versucht, meine UXes in Bezug auf Ziele, Probleme und Muster zu erstellen: Für jeden Schritt gibt es ein Problem, das gelöst werden muss.

So sieht auch die Programmierausbildung aus: Sie stellen Sie vor ein Problem, warten einige Minuten, beginnen dann mit einer groß angelegten Lösung und sagen dann: "Es ist in Ordnung, aber = ", und dann gehen sie ins Detail, bis eine vollständige Lösung gefunden ist.

Quantifizieren, quantifizieren, quantifizieren

Programmierer verstehen Zahlen. Wenn Sie ihnen mitteilen, dass es wichtig ist, dass ein Feedback innerhalb von 1000 ms eingeht, können sie einen automatisierten Test schreiben, um zu überprüfen, ob dies der Fall ist. Automatisierte Tests sind heutzutage in vollem Gange, und dies ist etwas, das sie von einem Computer verlangen können, um es zu testen.

Wenn Sie ihnen sagen, dass es wichtig ist, innerhalb von 1000 ms eine Antwort zu erhalten, arbeiten sie auf dieses Ziel hin. Wenn Sie ihnen sagen, dass etwas auf dem Bildschirm mindestens 1 cm lang sein muss, arbeiten sie auf dieses Ziel hin.

Aber es ist immer wichtig, ihnen Gründe zu geben. Entwickler sind nicht dumm und sie hassen es, als solche behandelt zu werden, insbesondere von der UX-Community.

Geben Sie für Human Factors Kochbücher an

Es ist wahr, dass der stereotype Programmierer nicht gut darin ist, Menschen zu verstehen. Dies ergibt sich aus der Korrelation zwischen der Affinität zum Umgang mit Computern anstelle anderer Personen und der Anmeldung als Entwickler.

Sie werden zum Beispiel nicht wirklich verstehen, dass Menschen schlecht darin sind, sich an Dinge zu erinnern (Rückruf gegen Erinnern), da die meisten von ihnen wirklich gut darin sind (es wird für ihren Job benötigt).

Aber wenn Sie ein gutes Kochbuch haben (10 Gebote, Checklisten mit Aufzählungszeichen), das sie am Ende des Tages mit Erklärungen kreuzen können, könnte es funktionieren.

Dies ist, was die oft zitierten Bugzilla-Tags hier tun. Sie geben den Entwicklern die Faustregel. Zu sagen, dass es einen "UX-Undo" -Fehler gibt, sagt dem Entwickler: "Oh ja, es gibt eine Faustregel, dass alles leicht zurückgesetzt werden kann.".

Ein gutes Buch in solchen ist Weinschenks 100 Dinge

Akzeptiere, dass Programmierer von Technologie besetzt und verzaubert sind

In Flammenkriegen von Programmierern geht es um Technologie: Sie werden überrascht sein, wie wichtig es am Ende nicht ist, welche Technologie Sie verwenden und wie viel von ihrer Freizeit (und, ähm, Arbeitszeit, tatsächlich) darüber gestritten wird ist der beste. Sie streiten sich sogar zwischen Äpfeln und Orangen, und sie streiten sich, ob es zwei Äpfel oder ein Apple und ein Orange) sind.

Sie platzieren auch jedes einzelne glänzende Objekt, das sie finden, auf einer Website und denken, es sei "ergonomisch". Dies gilt insbesondere für glänzende Interaktionen.

Wenn etwas von der aktuellen Technologie nicht gut unterstützt wird (z. B. wenn ein bestimmtes Widget nicht in der Widget-Bibliothek des Systems enthalten ist), muss der UX-Designer Zeit und Mühe investieren, um zu verstehen, ob die technologische Barriere real ist oder nicht nicht.

Zusammenfassend

Ich hatte drei Ziele mit diesem Text:

  • Um einen allgemeinen Überblick über das zu geben, was die meisten Entwickler bereits wissen
  • Bereitstellung eines allgemeinen Ausgangspunkts für die Kategorisierung einer großen Taxonomie
  • Um eine Referenz zu haben, die jemand später in UX-vs-Devs-Diskussionen verlinken kann, nicht nur die bekannten Bugzilla-Tags

  • -
8
Aadaam

Es gelten die gleichen Grundregeln wie für Websites.

Dies sind auch die gleichen Grundregeln, die für die für Betriebssysteme veröffentlichten 'Schnittstellenrichtlinien' gelten (z. B. die Microsoft & Apple Schnittstellenrichtlinien).

Grundsätzlich müssen die Schnittstellen um das 'menschliche' Element herum aufgebaut sein - und dies bleibt natürlich gleich, unabhängig von der tatsächlichen Schnittstelle.

Die grundlegenden Konzepte werden in den ersten drei Kapiteln von Apple Human Interface Guidelines behandelt. (dauert eine Weile zum Laden)

2
PhillipW

Ich denke, die Herausforderung besteht darin, dass es keinen guten Weg gibt, eine einfache Referenz für diese Art von Dingen zu erstellen. Der beste Weg, um zu helfen, könnte sein, ihnen beizubringen, Anforderungen selbst zu sammeln (einer von ihnen bringt jemandem bei, zu fischen und sie für immer zu füttern). Jakob Nielsen hat eine tolle Artikel über Interviewbenutzer . Kombinieren Sie dies mit einer einfachen Überprüfung einiger ähnlicher/wettbewerbsfähiger Websites/Apps, und Sie sollten eine gute Basis haben, um mit der Arbeit an der Benutzeroberfläche/ID zu beginnen. Dies ist ein Prozess, der Ihnen (einem UI-Experten) einen Mehrwert bietet, ihnen aber dennoch einige Grundlagen beibringt, die sie nach Ihrem Tod anwenden können.

1
Andrew Shipe

Sehr interessante Frage.

Ich gehe davon aus, dass Sie nach einer Antwort suchen, die über Folgendes hinausgeht:

  1. Fragen Sie nach der Demografie des Benutzers.
  2. Erfahren Sie mehr über den Kontext des Benutzers. (Standort, Umwelt, sozioökonomische Faktoren usw .: Betrachten Sie Arbeitsmodelle in Contextual Design von Holtzblatt und Beyer.)

Der Sinn der anfänglichen Benutzerrecherche besteht darin, die Domäne zu verstehen und zu versuchen, die Probleme/Ausfälle im System zu finden. Erst danach können spezifischere anforderungsbezogene Fragen gestellt werden. Was Softwareentwickler normalerweise in Bezug auf Anforderungen erhalten (oder erhalten sollen), sind tatsächlich funktionale Anforderungen, die (unter Verwendung einer Art Datenanalyse) aus den Daten destilliert werden, die als Anforderungen vom Kunden/Benutzer eingehen.

Wie Andrew oben sagte, gibt es keinen guten Weg, eine Referenz dafür zu machen. Ein Grund dafür ist, dass sich verschiedene Projekte auf verschiedene Dinge konzentrieren. Zum Beispiel: Möchten Sie eine komplette Neugestaltung? Dann stellen Sie grundlegendere systemische Fragen. Wenn Sie nur das Erscheinungsbild ändern und die Geschäftslogik in Ruhe lassen möchten, sind die zu stellenden Fragen oberflächlicher.

Ein weiterer Grund für die Erstellung einer Referenz ist, dass verschiedene Softwareprojekte in unterschiedlichen Domänen liegen und die zu stellenden Fragen je nach Domäne erheblich voneinander abweichen.

Ich bin sicher, es gibt mehr Möglichkeiten, Softwareprojekte zu gruppieren.

Trotzdem kann es ein interessantes Projekt sein, verschiedene Arten von Projekten zu gruppieren und dann grundlegende Fragen zu stellen, die relevant wären.

1
Viraj