guerillagirl

“If we want users to like our software we should design it to behave like a likeable person: respectful, generous and helpful.” (Alan Cooper)

Das Web entwickelt sich immer mehr zur Plattform für sogenannte Apps – webbasierte Anwendungen (auch bekannt als SaaS = Software as a Service), die der Software ähneln, die wir auch tagtäglich auf unserem Computer benutzen.
Der einzige Unterschied besteht also darin, das diese Anwendungen in einer browser-basierten Umgebung genutzt werden, und oder mit Sprachen geschrieben werden, die jeder Browser versteht (z.B. HTML in Kombination mit JavaScript).
Dies hat den Vorteil, das diese Anwendungen plattformübergreifend genutzt werden können – also nicht speziell für verschiedene Betriebssysteme entwickelt werden müssen und keinen Platz auf Festplatte verbrauchen.

Webbasierte Anwendungen wie Doodle, die z.B dazu dienen, um Termine mit mehreren Teilnehmern zu koordinieren, Intranets oder Wikis, die dem Wissensaustausch innerhalb von Unternehmen oder Organisationen dienen und die eventuell noch spezielle, auf die Bedürfnisse der Nutzer zugeschnittene Funktionen beinhalten, online Flugbuchungssysteme und viele andere webbasierte Anwendungen bedürfen einer von Grund auf völlig anderen Planung und einem anderen Designprozess als beispielsweise herkömmliche B2B Webseiten, die z.B ausschliesslich der Präsentation eines Unternehmens dienen.

Es geht darum, diese webbasierten Anwendungen sehr nutzerfreundlich zu gestalten und den Nutzer/den Menschen in das Zentrum der Anwendung zu stellen.
Diesen speziellen, auf den Nutzer zugeschnittenen Designprozess dahinter, nennt man User-Centered Design (UCD).

Interaktion = Kommunikation!
…und was haben mentale Modelle jetzt damit zu tun?

Interaktion mit einer Anwendung ist immer Kommunikation – allerdings in diesem Fall mit einer Maschine.
Maschinen reagieren nicht unbedingt so flexibel und höflich wie (manche) Menschen – und um diese Hürde in der Kommunikation Mensch – Maschine etwas zu erleichtern sollte man einige Dinge beachten:

Nicht die Funktionsweise der Anwendung sollte im Designprozess abgebildet werden, sondern ein mentales Modell des Nutzers steht im Vordergrund. Das bedeutet, das die Bedienung der Anwendung näher am mentalen Modell, also den Erwartungen des Nutzers liegen soll, als an dem Modell, wie die Anwendung im Hintergrund funktioniert/konstruiert ist. Wenn eine Anwendung nicht gut designed wurde, sondern lediglich eine Abbildung der dahinter liegenden Hardware oder Datenbank ist, wird sie nicht den mentalen Erwartungen der Nutzer gerecht. Die Anwendung sollte also eine „Sprache“ sprechen, die der Nutzer versteht. Schon mal Erfahrungen mit kryptischen Fehlermeldungen, die sehr viele numerische Werte beinhalten gemacht, die nicht helfen, sondern nur das wiederkauen, was die Maschine macht? Das ist z.B ein Parade- Beispiel für das nicht durchdachte Ausspucken einer Hardware-basierten Abbildung, mit der 97 % der Nutzer garantiert nichts anzufangen wissen.

Das Ergebnis davon ist, das Nutzer es sehr schwierig oder umständlich finden, die Software zu bedienen oder zu erlernen, weil das Interface der Mensch/Maschine Schnittstelle einer eher abstrakten als einer menschlichen Logik folgt, die für die meisten Menschen miserabel zu bedienen /unverständlich ist. Das führt zu Frustration

Das Stichwort hier heisst also: Intuitive Bedienung eines Produktes.
Dafür muss man verstehen, wie Nutzer denken, handeln, welche Ziele oder Aufgaben sie verfolgen und
was sie sich von der Bedienung der Software/Anwendung erwarten.

Wie wird man diesen Erwartungen im Designprozess gerecht? Wie erreichen Nutzer möglichst einfach ihre Ziele? Wie bringe ich die Nutzer dazu, den Service sogar GERNE zu nutzen?
Wie folge ich dem mentalen Modell der Nutzer (der Erwartung: jetzt könnte „dies & das“ passieren, das würde an dieser Stelle jetzt „passen“)
Dafür muss man als Designer mitunter die Abläufe, wie Menschen handeln um eine Aufgabe zu lösen oder ein Ziel zu erreichen, 100%ig verstehen und sich sozusagen in ihre Köpfe „hineinversetzen“.

Methoden für den Designprozess hierfür wären z.B.

-Im Briefing abklären: worum geht es überhaupt? Existiert schon eine Anwendung, die verbessert werden muss? Oder ist es eine neue Anwendung, die zu planen und gestalten ist?
-Fragen, fragen, fragen ( – es gibt hier keine blöden Fragen! )

1) Bei existierenden Anwendungen:

• – bei komplexen schon existierenden Anwendungen eventuell tageweise Workshops, in denen bestenfalls Nutzer, also Personen die mit der Anwendung arbeiten ,beobachtet und interviewed werden, was sie machen, welches Ziel sie verfolgen und warum sie das so machen.
• – Welche Nutzungsprobleme gibt es? Welche Wünsche? Das übergeordnete Problem verstehen lernen.
• – Hotlines befragen, Leute die mit Kunden/Anwendern in Kontakt kommen. ( z.B „Was sind die häufigsten Fragen die Ihnen so gestellt werden?“)
• – Auswertung dieser Ergebnisse
• – Überlegungen. wie man dieses Problem (anders?) lösen kann / das übergeordnete Ziel anders erreichen kann
  schnelles Ideen-Skizzieren von Interaktionslösungen auf Papier.
• – Nicht projektinvolvierten Kollegen/Freunden diese Lösungen zum „Papier“- Usability Testen vorlegen ( Funktioniert das? Versteht man das? Wo hakt es noch? Was kann man veressern? )
• – Wiederholen dieser Methoden, bis man die beste Lösung gefunden hat. (Iteration)

2) Bei neuen Anwendungen

• – Wer soll die Anwendung nutzen? Was ist Sinn und Zweck der Anwendung? Die Anwendung genau verstehen lernen. ( Das übergeordnete „Problem“/Ziel erfassen )
• – Gibt es eventuell schon einen „analogen“ Prozess zu dem die Anwendung als „Goodie“ hinzukommen soll?
• – Hotlines befragen, Leute die mit Kunden/potentiellen Anwendern in Kontakt kommen. (Was sind die häufigsten Fragen die gestellt werden?)
• – Recherche, wer sind die Nutzer? Wie leben Sie, was erwarten Sie/ was sind ihre Bedürfnisse?? Wie alt sind sie?
• – Sind Personas notwendig? ( bei grösseren Anwendungen ein sehr gutes Hilfsmittel, um den späteren Nutzer „nicht aus den Augen zu verlieren“ )
• – Schnelles Ideen-Skizzieren von Interaktionslösungen auf Papier
• – Nicht projektinvolvierten Kollegen/Freunden diese Lösungen zum „Papier“- Usability Testen vorlegen ( Funktioniert das? Versteht man das? Wo hakt es noch? Was kann man veressern? )
• – Wiederholen dieser Methoden, bis man die beste Lösung gefunden hat. ( Iteration )

Mit diesen Lösungsansätzen zum Kunden gehen und ( event. anhand von Personas ) versch. Nutzerszenarien anhand von Wireframes durchspielen.
Ggf. Wiederholung der oben aufgeführten Schritte.

So gewährleistet man nebenbei einen durchweg agilen Ansatz, den man schon im frühen Stadium perfekt auf die Nutzer zuschneiden/ändern kann, noch bevor eine Zeile Code geschrieben wurde.

Änderungen in einem späteren Stadium werden meistens im Endeffekt sehr viel teuerer , falls überhaupt noch so durchführbar. Im schlimmsten Fall führt das Bedienen der Anwendung dann zu unzufriedenen Nutzern, die die Anwendung/das Produkt nicht gern (wenn überhaupt) nutzen. Zufriedene Nutzer sind meist auch zufriedene Kunden.