Freitag, 19. Dezember 2014

Von Erwartungen und Konzepten. Struktur für das User Interface.

Ein System für den Entwurf einer Benutzerschnittstelle.

Artikelübersicht
1. Teil Die Erweiterung des Requirements Engineering durch das Usability Engineering.
2. Teil Mit Zielen zum User Interface.
3. Teil Dem Ziel entspringt die Anforderung. Alles ist im Fluss.
4. Teil Von Erwartungen und Konzepten. Struktur für das User Interface.
5. Teil Struktur gibt es nicht, ohne die Zeit, die Dinge in Ordnung zu bringen.
6. Teil Schlagen Sie mit Konventionen vielfältige Konfigurationen in die Flucht.
7. Teil Elemente verteilen ohne Ausraster.
8. Teil Mit den Sinnen den Sinn der Oberfläche erfassen.


Nach der Strategie- und der Umfangsebene bzw. dem Anforderungsmanagement verlassen wir die abstrakte Ebene und wenden uns Konkreterem zu. Wir treten in die Designphase ein. Diese unterteilt sich nach [GARRETT12] in die Strukturebene, die Rasterebene und die Oberflächenebene. Auch hier verbleiben wir in der Bewegungsrichtung vom Abstrakten zum Konkretem.

In der Strukturebene spielen zwei Teilgebiete eine herausragende Rolle, das Interaktionsdesign und die Informationsarchitektur. "Beim Interaktionsdesign geht es darum, mögliches Nutzerverhalten zu beschreiben und zu definieren, wie sich das System an dieses Verhalten anpasst und darauf reagieren wird." [S.81, GARRETT12] "Bei der Informationsarchitektur geht es darum, wie wir Informationen kognitiv verarbeiten." [S.89, GARRETT12]

In beiden Teilgebieten geht es um das tiefe Verständnis in Bezug auf das mögliche Handeln und Denken der Benutzer. Natürlich können wir uns auf den arroganten Standpunkt stellen, es vermeintlich zu kennen oder gar den Benutzer besser zu kennen als er sich selbst. Eine zweite Form der Ignoranz ist das Ausblenden dieser Wissensgebiete und die Annahme, der Benutzer wird sich schon anpassen. Aber selbst, wenn Entwickler wollten können sie nicht (immer) so wie sie wollen. Es gibt höhere Entscheidungsebenen, die Teilgebiete wie Requirements Engineering, Qualitätssicherung aber auch Usability Engineering als Kostenfresser streichen. Am Ende dieser Entwicklungen steht Software, die schwer zu bedienen ist, ein hohes Maß an EDV-Wissen verlangt und den Benutzer verwirrt und teilweise sogar verängstigt zurück lässt. Natürlich kann man sich über diese armen Menschen lustig machen, aber der Grund des Übels liegt bei denen die sie auslachen.

Versuchen wir einen anderen Weg zu gehen. Zuerst erstellen wir im Interaktionsdesign ein konzeptionelles Modell. Menschen erwarten, geprägt durch ihre Umwelt, ihr Erlerntes und ihre Erfahrungen, bei bestimmten Vorgängen ein bestimmtes Verhalten. Bei Einkaufen vollzieht man gewöhnlicherweise bestimmte gewohnte Teilschritte, genau wie beim Erlernen von Vokabeln. Bieten wir dem Kunden eine Software, die diesen Erwartungen widerspricht, haben wir erhebliche Schwierigkeiten. Auf der einen Seite ist die Akzeptanz sehr niedrig, auf der anderen Seite muss man die ungewohnten Schritte ganz neu erlernen. Stimmt unser konzeptionelles Konzept mit den Erfahrungen des Nutzers in diesem Bereich überein, werden viele Dinge intuitiv erfolgen. Die Entwicklung eines solchen Modells kann nur gemeinsam mit dem Benutzer erfolgen. Er ist der Maßstab für den Erfolg.

Was genau sind nun konzeptionelle Modelle. Der Warenkorb ist ein solches Modell. Dahinter verbirgt sich ein Symbol, bei dem wir erwarten, dass wir etwas hineinlegen können, damit wir es später zur Kasse schieben und bezahlen. Das Icon für den Drucker in einer Office-Anwendung ist ebenfalls ein konzeptionelles Modell. Wir wissen, wenn wir dieses Icon anklicken wird unser Geschriebenes gedruckt. Wenn das nicht erfolgt ist entweder der Drucker aus oder wir haben ein Problem mit dem Kunden. Im zu erklären, dass wir für dieses Icon ein ganz anderes Verhalten vorgesehen haben, erhöht den Missmut ungemein. Unser konzeptionelles Modell beschreibt also die Erwartungshaltung des Kunden und die dafür eingesetzten Konzepte.



Wir beschreiben also Erwartungshaltungen. Diese ermitteln wir beim Benutzer, einer geeigneten Auswahl von Benutzer oder an gut durchdachten Personas und extremen Charakteren. Die Erwartungshaltungen können, wie unsere Abbildung der Ziele, in einem UND-ODER-Baum verfeinert werden. Für diese Erwartungen entwickeln wir Konzepte zur Lösung. Diese beziehen sich auf die Erwartungen.



"Ein großer Teil jedes Projekts zum Interaktionsdesign ist der Umgang mit Anwenderfehlern – was tut das System, wenn der Nutzer einen Fehler macht, und was kann das System tun, um solche Fehler von Vornherein zu vermeiden?" [S.86, GARRETT12] Wir müssen uns also genaue Wege überlegen, wie wir auf Anwenderfehler reagieren. Zwingen wir den Anwender alle Falscheingaben zu korrigieren? Verbessern wir kleine Fehler oder tolerieren sie? Was nervt mehr? Einen guten Weg zu finden zwischen Reparatur, Korrektur und Fehlerhinweisen ist eine schwierige Sache. Sie ist ein weiteres Gebiet, in dem die Zusammenarbeit mit dem Benutzer dringend notwendig ist. Es ist also dringend geboten die Erwartungshaltungen des Benutzers an die Fehlerbehandlungen zu ergründen und Konzepte zur Umsetzung zu finden. Das oben beschriebene Modell wird somit einfach nur erweitert.

Das zentrale Objekt der Begierde im Interaktionsdesign, später auch in der Informationsarchitektur ist der Anwender. Das Verstehen seiner sozialen Situation, seines emotionalen Zustands und der erlernten Rationalisierungsmuster ist von ausschlaggebender Bedeutung. Nun kann man aber Folgendes einwenden, die wichtigste Aufgabe einer Softwarefirma ist es, mehr Geld einzunehmen als auszugeben. Dafür kann man natürlich Schrott an den Kunden verkaufen. Nur das Korrektiv, der Kunde kauft nichts mehr, sorgt in unserer Art zu wirtschaften dafür, dass die Firma mehr und mehr gezwungen wird Qualität zu liefern. Diese gesteht sie aber nur soweit zu, wie es den Plan mehr Geld einzunehmen als auszugeben nicht stört.

Ich behaupte, der primären Faktor in der (kommerziellen) Softwareentwicklung ist, dass man Mehreinnahmen erwirtschaften muss. Ich beziehe mich damit auf die augenblickliche Art zu Wirtschaften, schließe also nicht aus, dass es andere und vielleicht sogar bessere Arten zu wirtschaften gibt. Leichte Erweiterbarkeit, Qualität und Benutzerfreundlichkeit einer Software sehe ich nur als sekundäre Faktoren, die sich immer nur durchsetzen, wenn man den primären Faktor erfüllt. Ich denke, die sekundären Faktoren sind oft Erfüllungsgehilfen des primären Faktors. Der Beweis dafür erfolgt jedoch immer erst in der Zukunft. Ist das Management nicht von diesen Argumenten überzeugt hat man einen schweren Stand. Ist das Management auf kurzfristige Erfolge aus, ist der Stand umso schwerer.

Im nächsten Post dieser Reihe werden wir uns mit weiteren Aspekten der Strukturebene befassen. Erwähnt wurde schon das Teilgebiet der Informationsstruktur, auf das wir eingehen werden. Schritt für Schritt nähern wir uns einem benutzbaren User Interface.



Ich wünsche allen Lesern ein frohes Weihnachtsfest und ein gesundes neues Jahr! "Muße ist der schönste Besitz von allen." [Sokrates] Deshalb wünsche ich Ihnen außerdem ein Jahr, angefüllt mit vielen Mußestunden!


  • [GARRETT12] : Jesse James Garrett: "Die Elemente der User Experience", Addison-Wesley Verlag, 2012


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen