What’s behind? Zielorientiertes Denken im UI Design.

Kurzer Einblick in UID Gedankenprozesse und mein Senf dazu.

Wenn ich z.B eine für eine Software einen Interaktionsprozess / Designlösung gestalten soll, muss ich wissen, welch übergeordneter Workflow dahinter steht.

Mir reicht es also nicht , die puren Tasks/Aufgaben zu kennen, (User X gibt hier etwas ein dann soll dies und jenes passieren und er soll dahin kommen…) sondern ich muss eigentlich wissen, aus welchen Gründen User x das & das eingibt und was im Großen und Ganzen dahintersteckt, ich muss diesen mir erstmal völlig fremden & neuen Workflow (mitunter auch einen Ablauf in einer Firma) komplett verstehen und verinnerlichen sowie durchspielen:
Warum tut User X das? Wie sind die internen Zusammenhänge? Wer hat noch damit zu tun?

Kann man das viell. komplett anders lösen? (–> Ziel des Users ins Visier fassen und „Problem-breakdown“)
Tasks sind keine Ziele – Tasks sind Mittel, diese Ziele zu erreichen.

Dieser „sich-in etwas-hineinversetzen-Prozess“ kann mitunter sehr zeitaufwändig sein & werden, vor allem wenn noch etwas unklar ist, irgendwie für einen selbst schwammig definiert ist und man das übergeordnete Problem oder den Zusammenhang nicht richtig „fassen“ kann.

Oft bekommt man ja die Probleme erklärt, und im ersten Moment scheint alles sonnenklar – dann probiert man es selbst aus und man stößt auf absurde Fragen, wie dies und das eigentlich funktionieren soll..-und irgendwann wird man ganz deppert dabei und fängt schon an an sich selbst zu zweifeln ;)

Deshalb: beim Briefing zuhören, dann ungestört selbst ausprobieren/ einen oder mehrere Flows durchspielen, nochmals zusammensetzen und fragen, fragen fragen und nachhaken, sobald etwas – und wenn auch nur eine Kleinigkeit – unklar ist. Das merkt man schnell daran, das man irgendwo hängt und das Problem selbst nicht richtig präzise definieren kann. Keine falsche Scham an dieser Stelle – dieses Verstehen und „sich in etwas hineinversetzen“ kostet Zeit, und wenn man das verpasst muss man diese Zeit eventuell später aufbringen, wenn man merkt das es so doch nicht funktioniert.
Am besten hilft es eventuell, zusammen einen Prozess (viell. sogar in einer Art Rollenspiel? — ich bin User X und will jetzt dies und das erreichen..) durchzuspielen, und zwar nicht „mal eben schnell nebenher“ sondern in Ruhe mit mit Notizen und so.

Taskbasierte Problemstellungen sind zwar gut, und man kann damit auch was anfangen – man sollte aber trotzdem das Große & Ganze dahinter kennen. ;)

Ich denke, nur so kann man Designlösungen und Interaktionen entwickeln und optimieren, die es dem User x leichter machen.

2 Antworten zu „What’s behind? Zielorientiertes Denken im UI Design.“

  1. Deshalb: beim Briefing zuhören, […]

    Außerdem Notizen machen und scribbeln was geht. Lieber acuh etwas mehr.

    viell. sogar in einer Art Rollenspiel?

    Einen Cognitive Walkthrough habe ich gerade dieses Woche auch mal wieder gemacht. Ergebnis waren fünf Seiten Notizen und eine konkrete Liste von potentiellen Nutzungsproblemen und einem daraus abgeleiteten Satz von möglichen Verbesserungsansätzen.

    Erleichtert wird das Ganze vielleicht dann, wenn es sich um Produkte und Anwendungen handelt, für die man auch selbst Interesse hat.

    Nachdem dann Verbesserungsansätze umgesett sind, gilt es imho richtig zu testen. Mindestens in quantitativ analytischer Form als A/B-Test oder noch besser mit Nutzern aus der Zielgruppe.

  2. Hey Björn!

    jepp scribbeln & Notizen klar ganz wichtig :D – wenn allerdings schon etwas besteht und dies optimiert werden soll geht es mir zumindest so, das ich das Ding erst mal selbst erfahren & „erleben“ muss und mir darauf hin eher Notizen mache, und dann nochmal durchspreche. Wenn etwas komplett neu entsteht, ist das wieder etwas anders.

    Ich teile mir die Anforderungen auch immer gerne in „Must haves “ , Nice to haves “ etc. auf. Denke auch, das ein Walkthrough sehr viel bringt um das Verständnis für die Anwendung zu schärfen, ausserdem möchte ich in Zukunft auch ausprobieren, mir selbst schärfere Grenzen zu ziehen : z.B

    – sich selbst einen festen Zeitrahmen stecken : Testen (bei bereits best. Projekten) , Research (z.B je nach Umfang des Projektes 1 Std.)
    – mind. 3 versch. Lösungsansätze für ein Problem scribbeln ( auch in einem festen Zeitrahmen, man verliert sich nämlich sonst )
    – im Team diskutieren, event. „open design sessions“ in kurzen Blitzmeetings mit dem Team ins Leben rufen (Ideen sammeln, beste rauspicken)
    -erst wenn eine Lösung steht ( die beste für das jeweilige Problem) in der Software Wireframes bauen

    Man muss halt seine Methoden finden – da gehört auch leider trial & error dazu :)

    Super finde ich die Ansätze von Leah Buley (Experience Designer bei Adaptive Path) die sie auf dem SXSW 09 in dem Panel „How to be a UX Team of one“ präsentiert. Langes Video – aber unbedingt mal ansehen.

    +++ ugleah- How to be a UX Team of one

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

GDPR Cookie Consent mit Real Cookie Banner