it-swarm.com.de

Wie würde man den Umfang von UX definieren?

Ein Teil meiner Arbeit besteht darin, vorhandene Anwendungen aus einer UX-Perspektive zu überprüfen, dann einen beratenden Ansatz zu verfolgen und Verbesserungen vorzuschlagen. Diese Aufgabe wird jedoch parallel zu anderen Teams ausgeführt, die die Anwendung ebenfalls überprüfen, jedoch unter anderen Gesichtspunkten wie Funktionalität, Leistung, Sicherheit usw. Alle Teams arbeiten praktisch in Silos.

Kürzlich bin ich auf eine Anwendung gestoßen, bei der der Benutzer einige Daten aus mehreren Quellen erhalten würde (kann keine spezifischen Daten bereitstellen, da alles proprietär ist). Diese Daten werden dann mithilfe der Anwendung optimiert und anschließend ein Abschlussbericht erstellt. Grundsätzlich muss, sobald der Benutzer mit den optimierten Daten zufrieden ist, auf eine Schaltfläche geklickt werden und ein PDF Bericht wird automatisch generiert.

Bei der Prüfung des Antrags stellte ich fest, dass im Bericht einige Daten nicht angemessen angezeigt wurden. Wenn ein Teil der Daten "x" wäre und der Benutzer sie in "y" ändern würde, würde der Bericht im Grunde immer noch "x" widerspiegeln.

Ich habe dies als UX-Problem dokumentiert, mein Chef sagte jedoch, dass dies zwar die Benutzererfahrung beeinträchtigen würde, jedoch eher als Funktionsproblem als als UX-Problem eingestuft werden sollte, da dies nur bedeutet, dass die Anwendung nicht ordnungsgemäß funktioniert.

Obwohl ich seinem Standpunkt zustimme, war ich dennoch der Meinung, dass es auch als UX-Problem eingestuft werden könnte, da der Benutzer eine Reihe von Aufgaben ausführen würde, um ein bestimmtes Ziel zu erreichen (in diesem Fall die Erstellung des Berichts). Wenn der Bericht jedoch nicht so ist, wie der Benutzer es erwartet hat, würde dies zu Frustration führen.

Dieser Gedanke brachte mich dazu, weiter darüber nachzudenken, ob alle Probleme, ob Funktionalität, Leistung, Sicherheit oder Kompatibilität, die Benutzererfahrung direkt oder in einigen Fällen indirekt beeinflussen würden. Daher kann jedes Problem in einer Anwendung einen UX-Winkel haben.

Wie definiert man in solchen Fällen den Umfang von UX im Vergleich zu anderen Facetten der Anwendung wie Sicherheit, Funktionalität usw.

Ich verstehe, dass dies ein wenig breit und subjektiv sein könnte, daher habe ich es umformuliert und unten etwas spezifischer gemacht, um es etwas objektiver zu machen

  • Gibt es Standardparameter/-prinzipien/-regeln für die Unterscheidung eines UX-Problems oder eines Nicht-UX-Problems?

  • Wurden in diesem Bereich Forschungsarbeiten/Artikel/Artikel verfasst?

  • Während Antworten für alle Kontexte willkommen sind, konzentriert sich diese Frage eher auf den Umfang, wenn es um Aufgaben wie Überprüfung und Bewertung geht.

5
TDsouza

Wie ich nie müde werde zu sagen, existiert alles in einem Spektrum. In der realen Welt gibt es keine Schwarz-Weiß-Szenarien. Alles wirkt sich auf die Endbenutzererfahrung aus, aber nicht alles fällt in den Verantwortungsbereich der UX-Rolle. Von oben bis unten in der Organisation haben unterschiedliche Personen unterschiedliche Verantwortlichkeiten, unterschiedliche Ansichten, unterschiedliche Gründe und unterschiedliche Interessen und Interpretationen in Bezug auf das Produkt, seine Funktionalität und die Benutzererfahrung.

Folglich ist es in einer UX-Rolle unmöglich, die Benutzererfahrung zu gestalten, einfach weil sie von allem und vor allem von jedem auf einer bestimmten Ebene beeinflusst wird. Dies schließt auch die Unterschiede zwischen jedem Benutzer und seiner Umgebung ein. Wir können keine Benutzer entwerfen und wir können keine Situationen entwerfen. Das Beste, was wir tun können, ist Design für eine beabsichtigte Erfahrung.

Angesichts der Tatsache, dass die UX-Designer-Rolle bereits auf Benutzerseite einige ziemlich große Einschränkungen aufweist, ist es nicht unangemessen, unsere Verantwortung auch auf Produktebene - in der Organisation - einzuschränken. Während es wichtig ist, dass UX-Designer gut in ihrer Arbeit sind, wird Ihnen jeder anständige Manager sagen, dass das Beste, was sie tun können, darin besteht, Leute einzustellen, die mehr wissen als sie selbst - die richtigen Leute für den richtigen Job. Während Sicherheit, Leistung, Kompatibilität usw. alles Bereiche sind, in denen es nützlich ist, einen 'UX-Finger am Puls' zu haben, sind dies Bereiche, die am besten den Experten überlassen werden und bei Bedarf einige Benutzer-Touchpoint-Anleitungen bereitstellen.

Das Gegenteil davon ist, dass es als UX-Designer Bereiche gibt, in denen Sie als Experte gelten. Andere werden ihren eigenen "Finger am Puls" haben wollen, aber diese Bereiche sind am besten Ihnen überlassen, während sie einige Berührungspunkt-Anleitungen liefern zu ihren eigenen Interessen.

Abhängig von der Wissensverteilung und den Fachgebieten (oder dem Mangel an Fachwissen) ist es manchmal unklar, wer der Experte ist, und es ist eine Frage der gemeinsamen Entdeckung und Entwicklung.

Mit anderen Worten, die wichtigsten Dinge sind Zusammenarbeit, Kommunikation und Austausch. Manchmal als Experte, manchmal mit einem Experten und auf jeder Ebene zwischen.

"Alle Teams arbeiten so ziemlich in Silos" Sie sagten. Genau da liegt das Problem.

Silos töten das. Sie töten die Kommunikation. Sie blockieren dieses Spektrum der Zwischenzeit. Sie erzwingen eine binäre Entscheidung: "Ist das mein Gebiet oder nicht?", Wenn es in fast allen Fällen einfach nicht so einfach ist.

Umfassen Sie die Unsicherheit. Umfassen Sie das Spektrum.

3
Roger Attrill

Im Allgemeinen hängt es davon ab, wie Sie innerhalb der Organisation/mit dem Kunden arbeiten. Wenn Sie sich in einer Organisation befinden und Seite an Seite mit anderen Teams arbeiten, ist Ihre Arbeit Teil des größeren Systems und kann nur in diesen Begriffen beurteilt werden. Sie und Ihr Chef hätten also Recht: Die UX hat ein Problem aufgrund eines Entwicklungsfehlers, aber sobald dieser Fehler behoben ist, ist auch das UX-Problem behoben (theoretisch ... dies behebt es in der Realität selten).

Wenn Sie jedoch mit Kunden zusammenarbeiten und kaum oder gar keine Kontrolle über andere Teile des Entwicklungsprozesses haben, sind Sie fertig, sobald Sie Spezifikationen und Konstruktionsdokumentation geliefert haben. Es ist Sache des Kunden, Ihre Arbeit fortzusetzen. Sollten sie Sie auf der Gehaltsliste halten, mit der Absicht, dass Sie die Arbeit überwachen, hängt dies theoretisch nur vom Umfang Ihrer Rolle ab.

Ich hatte dies letztes Jahr (vor ungefähr 8 Monaten), als ich als UX-Berater für ein Unternehmen eingestellt wurde, das an einem Slack-Bot arbeitet. Ich habe gerade den regulären Prozess der Gestaltung der Registrierungs- und Kommunikationsabläufe durchlaufen und als das erledigt war, war ich theoretisch fertig. Der Kunde wollte aber auch, dass jemand die täglichen Aufgaben erledigt und sicherstellt, dass die Entwicklungsarbeiten gemäß meiner Spezifikation durchgeführt wurden. Dies bedeutete, dass ich, während ich meine UX-Arbeit abgeschlossen hatte, auch die Entwicklung dieser Arbeit überwachte.

In Wirklichkeit war das überhaupt keine UX-Arbeit. Meine Aufsicht war alles von Projektmanagement und Qualitätssicherung bis hin zu grundlegendem Babysitting. Und ich wurde dafür bezahlt und hatte nichts dagegen, da es oft wenig Aufsicht von mir erforderte.

Für Auftragnehmer/Freiberufler ist dies etwas, das im Vertrag sehr klar aufgeführt sein muss. Wenn es sich um eine Organisation handelt und Sie nicht gerne zusätzliche Aufgaben übernehmen, die nicht in Ihrer Stellenbeschreibung enthalten sind, sollten Sie dies Ihrem Chef und/oder Ihrer Personalabteilung mitteilen.

1
Jamezrp

Meiner Meinung nach ist die Benutzererfahrung mit jedem technischen Aspekt verknüpft, der sie unterstützt. Das liegt daran, dass Form, Funktion und Ästhetik miteinander verflochten sind. Die Benutzererfahrung sollte nicht isoliert werden. Es ist ein Aspekt der technischen Bemühungen, die Anwendungen zu entwickeln.

In Ihrem speziellen Fall hat Ihr Chef absolut Recht. Dies ist ein Fehler. Eine sehr schlechte. Ihre Beschreibung ist etwas vage, aber es scheint mir ein völliger Fehler bei der primären Verwendung der Funktionalität zu sein (ändern, dann drucken). Das ist für mich inakzeptabel. Fehler sind Teil des Lebens, aber eine nicht funktionierende Hauptfunktion ist ein Zeichen für unsachgemäße Testverfahren.

1
Lucas