it-swarm.com.de

Wie machen Sie UX-Ergebnisse / Einschränkungen / Designs für das Entwicklungsteam am sichtbarsten / präsentesten?

Das Erstellen eines User eXperience-Frameworks aus Erkenntnissen, Einschränkungen, Anforderungen, Designs, Personas usw. ist eine Sache.

Wie kommunizieren Sie es am besten mit dem Entwicklungsteam? Wie machen Sie Ihre Benutzer für Entwickler präsent?

2
Benoît Pointet

Hängt davon ab.

Ich zeige Ihnen zwei Extreme, etwas übertrieben, aber ich hoffe, Sie finden einige nützliche Ratschläge.

Stereotyp 1:

Wenn sie agil-verrückte Freaks sind, die ebenfalls in die neueste Mode (Frühling, Scala, was auch immer) verliebt sind, aber kein Verständnis für gewöhnliche Menschen haben, ist es wahrscheinlich, dass sie kein Programmdesign machen.

In diesem Fall führt UX normalerweise das Programmdesign durch, also eine vollständige plattformunabhängige "Spezifikation" bis zum letzten Bolzen, dem letzten Pixel, einschließlich vollständiger Flüsse, mit allen alternativen Pfaden und einem kohärent gepflegten Daten-Design.

Software ist ein Engineering-Produkt . Es wurde entwickelt, um alltägliche Probleme für eine Gemeinschaft von Menschen mithilfe wissenschaftlicher Fortschritte zu lösen.

Dies verbindet das Bürogebäude, in dem Sie leben, die Brücke, die Sie auf dem Weg zur Arbeit überquert haben, den Wasserhahn, den Sie zum Waschen Ihrer Zähne geöffnet haben (und das Rohrsystem darunter), das Fahrzeug, das Sie benutzt haben (es sei denn, Sie gingen ) und die Webapp/Mobile App/was auch immer Sie gerade erstellen.

Diese Dinge wurden vor dem Bau entworfen in den letzten 2100 Jahren .

Diese Art von Programmierern benötigt detaillierte Screen-to-Screen-Designs, basierend auf Szenarien, mit allen alternativen Abläufen.

Format eines Designdokuments:

  • Flussdiagramm der Bildschirme mit hervorgehobenem Hauptfluss, klar angegebenen Einstiegspunkten und Voraussetzungen. Es dient auch als Inhaltsverzeichnis für den Dokumentator.
  • Alle möglichen Zustände des Bildschirms nacheinander in der Reihenfolge des Hauptflusses.

Stellen Sie sicher, dass Sie keine Fehler machen: Wenn Sie etwas mit einem Pixel Abstand zeichnen, wird es um einen Pixel entfernt implementiert.

Wenn Sie Kenntnisse der Informationsarchitektur haben, ist es keine schlechte Idee, Klassendiagramme bereitzustellen. Einige UXer stellen sogar Flussdiagramme der Algorithmen bereit.

Stellen Sie keine zusätzlichen Flusen bereit: Bringen Sie einfach das, was eingegeben werden muss, auf den Computer. Sie hassen es, lange Dokumente zu lesen, es spielt keine Rolle, dass es voller Diagramme ist. Doch alles, was Sie wahrscheinlich verpassen, wird nicht eingegeben ...

Stereotyp 2:

Wenn sie ein großes Verständnis dafür haben, dass es beim Programmieren nicht um ihre neueste Technologie geht und dass es Menschen gibt, die sich nicht um ihre technischen Dinge kümmern, sondern stattdessen ein echtes Problem haben, das sie zufällig mit Hilfe von Computern lösen, dann normalerweise , Entwurfsmuster und Anti-Muster sind ausreichend, manchmal mit Szenarien.

Diese Art von Menschen wollen kreative Freiheit und wollen verstehen, was sie tun, wollen Teil des Designprozesses sein. Sie brauchen eine kreative Richtung, vielleicht eine Korrektur der Benutzerfreundlichkeit, aber Sie müssen immer den Grund angeben, warum Sie bestimmte Dinge auf bestimmte Weise tun möchten.

Für diese lasse ich sie normalerweise das tun, was sie sich zuerst einfallen lassen, vielleicht über das Feature auf Papier sprechen, ohne fertige Zeilen oder richtige Dokumente, da ich sie nicht wirklich in beide Richtungen zwingen möchte, sie hassen das.

Wenn sie sich dann mit der ersten Implementierung fertig fühlen, komme ich zurück, überprüfe, was sie getan haben, und sage ihnen, ob etwas aus Sicht der Benutzerfreundlichkeit problematisch ist. Ich sammle wiederkehrende Probleme in Form von "Faustregeln" oder "Antimustern" (ohne ihre Fehler als Beispiele zu verwenden!), Damit das Entwicklerteam diese beim nächsten Mal selbst klären kann.

Für sie ist Ihre Rolle zweifach:

  • sie sind die Hauptperson, die als "dummer Benutzer" auftritt: Sie werden möglicherweise aufgefordert, das System zu testen, und Sie müssen ihnen mitteilen, welche Teile ein idiotischer Benutzer nicht versteht.
  • sie sind der Usability-Architekt und wissen, wie die menschliche Psychologie funktioniert und was für eine intuitive Benutzeroberfläche erforderlich ist.

Der Grund ist immer wichtig. Egal was Sie sagen, sagen Sie immer so: "Ich möchte, dass Sie dies tun, weil/wir wissen von unseren Benutzern, dass/bei unseren Benutzertests gezeigt wurde, dass/Studien gezeigt haben/Wir erwarten von unseren Nutzern ".

Für sie sammle ich Entwurfsmusterbibliotheken: Ein Entwurfsmuster handelt von einem bestimmten Problem und Empfehlungen ( ohne tatsächliche Widgets ) darüber, wie man sie löst. Lassen Sie sie es durchsuchen und stellen Sie die Anwendung selbst zusammen. Überprüfen Sie natürlich die fertigen Ergebnisse, aber lassen Sie sie die Grundlagen basierend auf den Personas, vielleicht den Szenarien, schaffen.

(Ja, zeigen Sie ihnen Ihre Personas und erzählen Sie ein kleines kurzes Szenario für jede neue Funktion! Wenn Änderungsanforderungen durch echte Benutzerkämpfe unterstützt werden, ist das großartig!)

Wenn Sie nicht sagen können, warum es wichtig ist, etwas auf diese Weise zu tun, recherchieren Sie entweder und kommen Sie mit Ergebnissen zurück, oder zeigen Sie zumindest eine Designalternative und fragen Sie nach ihrer Meinung. Dies ist praktisch in Bezug auf visuelles Design und Layout. "Ich denke, dieses Layout sieht weniger überladen aus, was sagen Sie?" Visuelles Design ist eine Kunst, man kann nicht immer genaue Argumente haben, und das ist völlig in Ordnung, solange es großartig aussieht: )

Einige dieser Programmierer werden mit UX vertraut sein, da sie es als Hobby lesen. Tatsächlich sind sich die meisten der wirklich erstklassigen Leute, mit denen ich zusammengearbeitet habe, der Usability-Probleme bewusst und haben ein paar HCI-Bücher gelesen.

Für beide:

Unabhängig davon, mit welcher Art von Programmierern Sie arbeiten, da sie das System, das sie entwickeln, genau kennen, werden sie wahrscheinlich nicht sehen, wenn etwas mehrdeutig oder technisch ist. Wenn sie ein Formular sehen, das sie erstellt haben, sehen sie letztendlich auch den Backend-Code. Wenn es einen Fehler gibt, wissen sie (oder denken zu wissen), was das zugrunde liegende Problem ist, und es ist wirklich schwer, so zu handeln, als ob Sie sich der Rückseite nicht bewusst sind. Du kannst nicht anders ...

Außerdem können sich Programmierer an viele Dinge erinnern: Sie werden einfach für ihre Arbeit benötigt. Wenn Sie mit einem leitenden Entwickler zusammenarbeiten, hat dieser wahrscheinlich ein besseres Kurzzeitgedächtnis als eine durchschnittliche Person, einfach weil er sich während der Arbeit an mehrere Kontextebenen erinnern muss. Ich sage nicht, dass sie sich daran erinnern, was sie zum Frühstück gegessen haben, aber wenn sie sich nicht daran erinnern, was sie mitten im Code erreichen wollten, wird es Probleme geben.

Und noch etwas: Die beiden Stile stimmen nicht überein. Einige Entwickler mögen die ersteren, andere die letzteren, aber keine der beiden Methoden funktioniert mit beiden.

4
Aadaam

Beziehen Sie sie in den Prozess ein.

Wenn sie sich darum kümmern, sind die Informationen für sie auf ihre eigene Weise relevant. Wenn sie sich nicht darum kümmern, spielt es keine Rolle, wie die Informationen ihnen präsentiert werden - sie möchten nur, dass die Spezifikationen den Anforderungen entsprechen.

0
Michael Lai