Induktive Benutzeroberfläche

Dieses Thema beschreibt das Benutzeroberflächen-Modell, das als Induktive Benutzeroberfläche (IUI) bekannt ist. Das auch als induktive Navigation bezeichnete IUI-Modell schlägt vor, Softwareanwendungen zu vereinfachen, indem Funktionen in Seiten oder Bildschirme aufgeteilt werden, die leicht zu erklären und zu verstehen sind. Dieses IUI-Modell ist in verschiedenen Microsoft-Projekten zu finden, z. B. in Microsoft Money 2000, den Windows-Steuerelementen, verschiedenen Seiten und Dialogen in Microsoft Visual Studio 2010 und den Aufgabenbereichen in Microsoft Office.

• Einführung
• IUI in Aktion: Die Lösung eines generellen Designproblems
  • Das Problem: Software ist schwer zu bedienen
  • Deduktive Benutzeroberfläche
  • Eine Lösung: Induktive Benutzeroberfläche
• Schritte zum Erstellen einer induktiven Benutzeroberfläche
  • Schritt eins: Konzentrieren Sie jede Seite auf eine einzige Aufgabe
  • Schritt zwei: Geben Sie den Status der Aufgabe an
  • Schritt drei: Passen Sie den Inhalt der Seite an die Aufgabe an
  • Schritt vier: Bieten Sie Links zu sekundären Aufgaben an
• Weitere Leitlinien
  • Verwenden Sie einheitliche Seitenvorlagen
  • Machen Sie deutlich, wie die Aufgabe mit den Steuerelementen auf der Seite auszuführen ist.
  • Bieten Sie eine einfache Möglichkeit, eine Aufgabe abzuschließen und eine neue zu beginnen.
  • Machen Sie den nächsten Navigationsschritt deutlich.
• Benutzerhilfe
  • Primäre Hilfe
  • Sekundäre Hilfe
• Anhang: Design und Test von Microsoft Money 2000
  • Design und Test von Money 2000
  • Tests zur Benutzerfreundlichkeit
  • Vergleich mit Websites

Einführung

Das IUI ist ein Benutzerinterfacemodell, das vorschlägt, wie man Softwareanwendungen einfacher gestalten kann, indem man Funktionen in Seiten oder Bildschirme aufteilt, die leicht zu erklären und zu verstehen sind. Microsoft hat dieses Modell in Money 2000, einer großen kommerziellen Softwareanwendung, implementiert. Informelle Tests deuten darauf hin, dass Benutzer*innen mit diesem Modell Aufgaben genauso schnell erledigen können wie mit herkömmlichen Benutzeroberflächen und dass sie Dinge leichter finden können.

Viele kommerzielle Softwareanwendungen verfügen über Benutzeroberflächen, bei denen eine Seite eine Reihe von Steuerelementen vorgibt, es aber dem/der Benutzer*in überlässt, den Zweck der Seite zu erkennen und herauszufinden, wie die Steuerelemente zur Erreichung dieses Zwecks zu verwenden sind.

Die in diesem Dokument beschriebenen Prinzipien erfordern oder implizieren keine bestimmten starren Vorgaben für Designs, Steuerelemente oder visuelle Elemente. Wie grafische Benutzeroberflächen im Allgemeinen lassen auch die in diesem Dokument beschriebenen Prinzipien viel Raum für Flexibilität und Kreativität beim Design.

Die allgemeinen Grundsätze der Induktiven Benutzeroberfläche werden anhand von Beispielen aus Money 2000 demonstriert.

Wichtig

Das Gesamtkonzept der IUI befindet sich noch in den Kinderschuhen. Designer, die diese Techniken anwenden, lernen und entdecken mehr darüber, während sie es für ihre Software nutzen. Die Informationen in diesem Dokument werden sich im Laufe der Zeit weiterentwickeln, wenn die Untersuchungen und das Wissen in diesem Bereich zunehmen. Dieses Thema bietet eine Einführung in die IUI und ist kein fester, umfassender Leitfaden.

IUI in Aktion: Die Lösung eines generellen Designproblems

In diesem Abschnitt wird ein generelles Designproblem heutiger Softwareprodukte erörtert und IUI als eine Technik zur Überwindung des Problems vorgestellt.

Das Problem: Software ist schwer zu bedienen

Die meiste Software ist zu schwer zu bedienen. Diese Schlussfolgerung ergibt sich aus Usability-Tests, anekdotischen Fakten und persönlichen Erfahrungen von Software-Designern. Das Konzept der IUI wurde erstellt, indem Untersuchungen durchgeführt wurden, Vermutungen darüber angestellt wurden, was die Nutzung aktueller Software erschwert, und dann Lösungen vorgeschlagen wurden. Designer, die IUI verwenden, sollten den Erfolg ihres Entwurfs an der Kundenzufriedenheit messen.

Die meisten aktuellen Softwareprodukte sind aus den folgenden allgemeinen Gründen schwer zu benutzen:

• Die Benutzer*innen scheinen kein angemessenes mentales Modell des Produkts zu erstellen.

  Das Oberflächendesign der meisten aktuellen Softwareprodukte geht davon aus, dass die Benutzer*innen ein konzeptionelles Modell verstehen, das die Designer sorgfältig ausgearbeitet haben. Leider scheinen die meisten Benutzer*innen nie ein mentales Modell zu entwickeln, das gründlich und genau genug ist, um ihnen eine entsprechende Anleitung zur Navigation zu geben. Diese Benutzer*innen sind wahrscheinlich sehr beschäftigt und mit Informationen überfrachtet. Sie haben weder die Zeit noch die Energie oder den Wunsch, ein konzeptionelles Modell für ihre Software zu studieren.

• Selbst viele langjährige Benutzer*innen beherrschen allgemeine Abläufe nicht.

  Die Designer wissen, dass neue Benutzer*innen anfangs Schwierigkeiten haben können, erwarten aber, dass diese Probleme verschwinden, wenn die Benutzer*innen die üblichen Vorgänge erlernen. Daten zur Benutzbarkeit zeigen, dass dies oft nicht der Fall ist. In einer Untersuchung legten die Untersuchenden eine automatische Einrichtung fest, um die Benutzer*innen zu Hause zu filmen. Die Aufnahmen zeigten, dass Benutzer*innen, die sich auf die zu erledigende Aufgabe konzentrieren, nicht unbedingt bemerken, wie sie vorgehen, und dass sie nicht aus den Erfahrungen lernen. Wenn die Benutzer*innen denselben Vorgang das nächste Mal durchführen, stolpern sie möglicherweise auf genau dieselbe Weise durch den Vorgang.

• Benutzer*innen müssen hart arbeiten, um jede Funktion oder Seite zu verstehen.

  Die meisten Softwareprodukte sind für (die wenigen) Benutzer*innen konzipiert, die das konzeptionelle Modell verstehen und die allgemeinen Abläufe beherrschen. Für die Mehrheit der Menschen ist jede Funktion oder Prozedur ein frustrierendes, unerwünschtes Rätsel. Die Benutzer*innen nehmen vielleicht an, dass diese Rätsel ein unvermeidlicher Preis für die Nutzung von Computern sind, aber sie wären sicherlich glücklicher ohne diese Last.

Die beste Lösung für diese Probleme besteht darin, eine allgemeine Strategie zu finden, um die Funktionen von Softwareprodukten selbstverständlicher und selbsterklärender zu machen. Benutzer*innen müssen in der Lage sein, eine Funktion jedes Mal zu finden, wenn sie sie brauchen, und sie müssen in der Lage sein, diese Funktion jedes Mal zu benutzen, wenn sie sie benutzen wollen.

Deduktive Benutzeroberfläche

Die meisten Elemente in der heutigen Software erfordern, dass die Benutzer*in sie studiert und daraus ihr Verhalten ableitet, wie der folgende Screenshot zeigt.

Erfahrene Benutzer*innen, einschließlich Softwareentwickler*innen, erkennen schnell, dass dieses Dialogfeld ihnen die Möglichkeit bietet, eine Liste von Dingen zu verwalten. Sie wissen, dass die Schaltflächen unter der Liste zum Hinzufügen und Entfernen von Objekten dienen und Informationen über die Objekte der Liste liefern. Beachten Sie jedoch, dass nichts von diesem Verhalten explizit im Dialogfeld selbst angegeben ist.

Sehen Sie sich das Dialogfeld noch einmal aus der Sicht einer/eines gelegentlichen Benutzer*in an. Viele Benutzer*innen werden sich angesichts dieses Dialogs fragen: „Was soll ich damit machen?“. Wenn das Dialogfeld erscheint, muss die/der Benutzer*in innehalten und sich überlegen, was sie/er als Nächstes tun soll. Zunächst muss die/der Benutzer*in erkennen, dass es sich bei dem großen, weißen Rechteck um ein leeres Listenfeld handelt, das mit Elementen gefüllt werden soll. Die Beschriftung des Feldes „Things“ ist ein vager Hinweis. Manche Benutzer*innen würden versuchen, in das Listenfeld zu tippen, weil es wie ein Textfeld zum Bearbeiten aussieht.

Als Nächstes muss die/der Benutzer*in ableiten, dass die Schaltflächen unterhalb der Liste deren Inhalt beeinflussen. Einige der Schaltflächen sind zunächst deaktiviert, was eine weitere potenzielle Quelle der Verwirrung für den/die Benutzer*in darstellt. Der/die Benutzer*in muss mit den Steuerelementen experimentieren, um zu lernen, wie der Dialog funktioniert.

Benutzer*innen können sich auch andere Fragen stellen: „Wie viele Elemente soll ich in die Liste eingeben? Soll ich die Einträge in einer bestimmten Reihenfolge eingeben? Warum habe ich dieses Dialogfeld überhaupt bekommen? Wofür ist es da?“

Benutzer*innen werden von ihren Zielen abgelenkt, wenn sie herausfinden müssen, welchen Zweck eine Seite hat und wie sie zu verwenden ist. Das kostet letztendlich Zeit und die Zufriedenheit der Benutzer*innen. Schlimmer noch, die Benutzer*innen nehmen den Preis immer wieder in Kauf, da sie jedes Mal, wenn sie eine Funktion verwenden, über die Oberfläche rätseln.

Eine Seite sollte einen Titel haben, der ihren Zweck klar erklärt. Wenn Designer*innen eine Seite erstellen, wird selten verlangt, dass sie einen klar formulierbaren Zweck hat. Stattdessen kann sie einfach Teil eines größeren konzeptionellen Modells sein, das sich der/die Benutzer*in erschließen muss.

Studien zeigen, dass viele Benutzer*innen selbst von grundlegenden Vorgängen in Software verwirrt sind. Sie haben Schwierigkeiten zu verstehen, was das Produkt für sie tun kann, wohin sie gehen müssen, um einen Vorgang auszuführen, und wie sie diesen Vorgang ausführen können, wenn sie ihn gefunden haben. Die Vereinfachung von Software durch grundlegende Änderungen ist ein wirksames Mittel, um bestehende Kunden besser zufriedenzustellen und neue Benutzer*innen zu gewinnen.

Eine Lösung: Induktive Benutzeroberfläche

Als neue Art der Softwareentwicklung zielt IUI darauf ab, dass Benutzer*innen weniger denken müssen, um sich erfolgreich zwischen den Teilen eines Produkts zu bewegen und seine Funktionen zu nutzen. Das Wort induktiv kommt von dem Verb induzieren, was soviel bedeutet wie führen oder bewegen durch Einwirken oder Überzeugen.

IUI ist eine Erweiterung der allgemeinen Benutzeroberfläche im Web-Stil. In der Webumgebung müssen die Seiten einfach und aufgabenbezogen sein, da jede Information über eine relativ langsame Verbindung an einen Server gesendet werden muss. Der Server antwortet dann mit dem nächsten Schritt und so weiter. Gutes Webdesign bedeutet, sich auf eine einzige Aufgabe pro Seite zu konzentrieren und die Navigation durch die Seiten zu ermöglichen. In ähnlicher Weise beginnt die induktive Navigation mit der Fokussierung der Aktivitäten auf jeder Seite auf eine einzige, primäre Aufgabe.

Eine gut gestaltete induktive Benutzeroberfläche hilft Benutzer*innen bei der Beantwortung zweier grundlegender Fragen, die sich ihnen beim Blick auf eine Seite stellen:

• Was soll ich jetzt tun?
• Wohin gehe ich von hier aus, um meine nächste Aufgabe zu erledigen?

Software, die nach diesen Prinzipien entworfen wurde, beantwortet diese Fragen, indem sie von einer grundlegenden Prämisse ausgeht: Eine Seite mit einem einzigen, klar formulierten, eindeutigen Zweck ist leichter zu verstehen als eine Seite ohne einen solchen Zweck. Wenn die Seite leichter zu verstehen ist, weiß die/der Benutzer*in auch leichter, was zu tun ist und wohin sie/er als Nächstes gehen soll.

Diese grundlegende Prämisse kann zu einer Reihe von vier Schritten für die Gestaltung von Software erweitert werden, die IUI verwendet:

• Konzentrieren Sie jede Seite auf eine einzige Aufgabe.
• Geben Sie den Status der Aufgabe an.
• Passen Sie den Inhalt der Seite an die Aufgabe an.
• Bieten Sie Links zu sekundären Aufgaben an.

In diesem Dokument werden die allgemeinen Grundsätze der IUI beschrieben und anhand von Beispielen aus Money 2000 und anderer Software in der Praxis demonstriert. Betrachten Sie diese Beispiele als besondere Ausprägungen von IUI, nicht als striktes Modell für die Implementierung.

Zusätzlich zu den vier oben aufgeführten Schritten können Sie Ihre Schnittstelle verbessern, indem Sie die folgenden fünf Richtlinien befolgen:

• Verwenden Sie einheitliche Seitenvorlagen.
• Stellen Sie Seiten für den Start von Aufgaben bereit.
• Machen Sie deutlich, wie die Aufgabe mit den Steuerelementen auf der Seite auszuführen ist.
• Bieten Sie eine einfache Möglichkeit, eine Aufgabe abzuschließen und eine neue zu beginnen.
• Machen Sie den nächsten Navigationsschritt deutlich.

Prozesse

Bei vielen Aufgaben müssen die Benutzer*innen durch eine Reihe von Seiten navigieren. Ein/e Benutzer*in, der/die eine Aufgabe ausführt, könnte auf einen Link zu einer sekundären Aufgabe klicken, die sich von der Sequenz der Seiten entfernt, aus denen die primäre Aufgabe besteht. Wenn der/die Benutzer*in die sekundäre Aufgabe erledigt hat, sollte es eine einfache Möglichkeit geben, direkt zum Verzweigungspunkt der ursprünglichen Aufgabe zurückzukehren. Benutzer*innen werden wahrscheinlich Schwierigkeiten haben, herkömmliche Steuerelemente wie die Schaltflächen Zurück und Vorwärts zu verwenden, um zum Ausgangspunkt zurückzukehren.

Um diese Möglichkeit zu bieten, definiert IUI ein Navigationskonzept, das als Prozess bezeichnet wird, eine Seite oder eine Reihe von Seiten, die eine Aufgabe erfüllen. Ein Prozess fungiert als eine Art Navigationsunterroutine. Benutzer*innen können einen Prozess beginnen, sich durch eine Reihe von Bildschirmen arbeiten und dann auf der letzten Seite auf eine Schaltfläche „Fertig“ klicken, um schnell zu der Seite zurückzukehren, auf der sie den Prozess begonnen haben.

Schritte zum Erstellen einer induktiven Benutzeroberfläche

In diesem Abschnitt werden die vier Schritte, mit denen Sie eine IUI erstellen können, eingehend beschrieben.

Schritt eins: Konzentrieren Sie jede Seite auf eine einzige Aufgabe

Der erste Schritt bei der Gestaltung einer IUI besteht darin, eine Funktion oder eine Reihe von Funktionen in einzelne Seiten aufzuteilen. Jede Seite sollte sich auf eine einzige Aufgabe konzentrieren, die so genannte primäre Aufgabe der Seite.

Diese Idee klingt einfach, aber nur wenige Anwendungen folgen ihr. Die meisten Anwendungen präsentieren eine Seite, von der aus alle zugehörigen Funktionen ausgeführt werden. Dieses Design verlangt von den Benutzer*innen, dass sie herausfinden (ableiten), was getan werden kann und wie man es tut.

Die primäre Aufgabe kann entweder spezifisch oder offen sein. In einem Programm für persönliche Finanzen könnte eine spezifische Aufgabe beispielsweise lauten: „Wählen Sie die Rechnung aus, die Sie bezahlen möchten“, während eine offene Aufgabe lauten könnte: „Überprüfen Sie die Wertentwicklung Ihrer Investitionen.“

Die primäre Aufgabe muss etwas sein, das für den/die Benutzer*in einen Sinn ergibt, und nicht ein Detail der Implementierung oder ein anderes abstraktes Konzept widerspiegeln. Die Aufgabe sollte etwas sein, an das die Benutzer*innen denken und das sie vorzugsweise in ihren eigenen Worten beschreiben.

Beispiel

In diesem Abschnitt werden zwei verschiedene Versionen von Money miteinander verglichen. Die Beispiele zeigen sehr ähnliche Funktionen, die den Benutzer*innen die Möglichkeit bieten, Finanzkonten einzusehen und zu verwalten.

Das IUI-Modell wurde bei der Erstellung von Money 2000 entwickelt, einer Anwendung zur Verwaltung persönlicher Finanzen. Money 2000 ist die achte große Version des Produkts. Money 2000 ist ein umfangreiches Windows-Programm mit weit über einer Million Zeilen Code.

Money 2000 ist eine Anwendung im Web-Stil. Es ist keine Website, hat aber viele Eigenschaften mit Websites gemeinsam. Die Benutzeroberfläche besteht aus Full-Stack-Seiten, die in einem gemeinsamen Rahmen angezeigt werden, mit Tools zum Vor- und Zurückblättern durch einen Stack. Auf dieser Grundlage fügt Money 2000 eine Reihe neuer Konventionen für die Benutzeroberfläche hinzu, die eine besser strukturierte Benutzeroberfläche erstellen.

Obwohl die IUI erstmals im Web-Stil von Money 2000 eingesetzt wurde, kann sie auch mit traditionellen Oberflächenelementen wie Fenstern und Dialogfeldern verwendet werden.

In Money 99 führten die Benutzer*innen oft eine Vielzahl von Aufgaben auf einer einzigen Seite aus. Der folgende Screenshot zeigt zum Beispiel den Konto-Manager, der alle kontobezogenen Funktionen in Money 99 auf einer einzigen Seite darstellte.

Auf dieser Seite sind eine allgemeine Aufgabe, die Navigation zu einem Konto sowie seltene Aufgaben wie das Erstellen und Löschen von Konten zusammengefasst. Keine dieser spezifischen Aufgaben kommt direkt im Titel der Seite zum Ausdruck, Konto-Manager. Viele Benutzer*innen werden diese Seite als ebenso herausfordernd empfinden wie den Beispieldialog in Abbildung 1. In beiden Fällen muss die/der Benutzer*in den Zweck der Seite erkennen und herausfinden, wie sie zu bedienen ist.

Money 2000, das der IUI folgt, bietet eine fast identische Reihe von kontobezogenen Funktionen, stellt sie jedoch auf zwei separaten Seiten bereit. Der folgende Screenshot zeigt die erste dieser Seiten, die sich ganz darauf konzentriert, den/die Benutzer*in zur Auswahl eines Kontos zu bewegen.

Die Seite von Money 2000 enthält ungefähr die gleiche Anzahl visueller Elemente wie die frühere Seite von Money 99, aber die Seite konzentriert sich jetzt ganz auf die Auswahl eines Kontos durch den/die Benutzer*in. In der Money 99-Version musste ein/e Benutzer*in zum Beispiel zwei Klicks machen, um ein Konto zu eröffnen: einen, um es auszuwählen, und einen weiteren, um den offenen Vorgang auszuwählen. In der Version Money 2000 klickt ein/e Benutzer*in nur noch auf ein Konto, um es zu eröffnen, sodass ein einziger Klick ausreicht. Auf diese Weise wird die Anzahl der Klicks, die für eine allgemeine Aufgabe erforderlich sind, oft reduziert, auch wenn die Anzahl der Seiten zunimmt.

Gelegentlich werden Benutzer*innen ein Konto hinzufügen oder entfernen wollen. Um diese Aufgabe in Money 2000 zu erledigen, navigieren die Benutzer*innen zu einer zweiten Seite (siehe folgender Screenshot), die sich auf das Einrichten von Konten konzentriert.

Der Zweck der einzelnen Seiten ist in der IUI-Version von Money 2000 klarer. Außerdem steht auf jeder Seite mehr Platz zur Verfügung, um den jeweiligen Zweck zu erfüllen. Im Konto-Manager von Money 99 konnte beispielsweise der Schaltfläche Konto löschen nur sehr wenig Platz eingeräumt werden, da sie im Vergleich zu den anderen Befehlen auf der Seite nur selten verwendet wurde. Auf der Seite für die Einrichtung von Konten in Money 2000 hingegen kann diese Funktion stärker hervorgehoben werden, sodass sie leichter zu finden und selbsterklärend ist.

Was ist eine einzelne Aufgabe?

Woher wissen Sie, ob eine Seite wirklich nur auf eine Aufgabe ausgerichtet ist? Eine Seite, die viele Aufgaben unterstützt, kann so dargestellt werden, als hätte sie nur einen Zweck, wenn dieser Zweck abstrakt genug ist. Hier eine Faustregel: Eine Seite ist auf einen einzigen Zweck ausgerichtet, wenn die Designer*innen diesen Zweck mit einem prägnanten, aussagekräftigen und natürlich klingenden Bildschirmtitel ausdrücken können.

Die Designer*innen von Money 2000 haben erwogen, diese Seiten (Wählen Sie ein Konto aus und Einrichten Ihrer Konten in Money) in mehrere Seiten aufzuteilen. Da jedoch jeder Bildschirm bereits einen prägnanten, aussagekräftigen und natürlich klingenden Titel hat, waren die Designer*innen der Meinung, dass die Seiten ausreichend konzentriert sind. Wenn Ihnen bei der Gestaltung einer Seite kein klarer und einfacher Titel einfällt, versuchen Sie wahrscheinlich, zu viel auf der Seite zu erreichen.

Schritt zwei: Geben Sie den Status der Aufgabe an

Jede Seite sollte mit einer prägnanten und eindeutigen Erklärung ihrer primären Aufgabe betitelt werden. Dies kann eine direkte Anweisung sein („Wählen Sie das Konto aus, das Sie ausgleichen möchten“) oder eine Frage, die der/die Benutzer*in beantworten soll („Welches Konto möchten Sie ausgleichen?“).

Dies ist ein weiterer, einfach klingender Grundsatz, der oft nicht befolgt wird. In früheren Versionen von Money gab es beispielsweise Seiten mit Titeln wie Online Financial Services Manager und Konto ausgleichen. Die Benutzer*innen mussten den Zweck und das Verhalten dieser Seiten aus der Anordnung und den Labels der Steuerelemente ableiten.

Der Titel der Seite oder des Bildschirms ist sehr wichtig. Unabhängig davon, ob das Produkt Fenster, Seiten im Web-Stil, Dialoge oder ein anderes Design verwendet, sollte der Titel keinen Interpretationsspielraum bieten.

Benutzerfreundliche Seiten haben klare Titel

Seiten, die viele Aufgaben erfüllen, benötigen abstrakte oder komplexe Titel. Die in Abbildung 2 gezeigte Seite „Money 99“ ließ dem/der Benutzer*in beispielsweise die Möglichkeit, sowohl zu Konten zu navigieren als auch Konten einzurichten. Der abstrakte Titel „Konto-Manager“ wurde dieser Seite gegeben, um diese beiden Aufgaben zu erfassen. Auch wenn die Benutzer*innen eine Vorstellung davon haben, was eine „Konto-Manager“-Seite tun könnte, ist ihnen vielleicht nicht klar, dass die häufigste Aufgabe auf dieser Seite einfach die Auswahl eines Kontos war.

Einige Seiten oder Befehle haben einen abstrakten Zweck, für den sich nicht ohne Weiteres ein klarer Titel finden lässt. Für diese Seiten wählen die Designer*innen möglicherweise absichtlich vage Namen wie „Einstellungen“, prägnante Schlagworte wie „QuickStep“ oder einen Jargon, der Details zur Implementierung verrät („Datenbankverdichtung“). Diese Arten von Namen sind für die Benutzer*innen oft verwirrend oder irreführend. Außerdem handelt es sich bei solchen Namen in der Regel um Substantive, die nicht die Aktion ausdrücken, die der/die Benutzer*in ausführen möchte, was die Verwirrung noch vergrößert.

Bildschirmtitel und andere Namen werden oft erst gegen Ende des Designprozesses festgelegt. Die Designer*innen bitten die Autor*innen oft, sich einen passenden Namen für eine Seite auszudenken, nachdem sie entworfen und programmiert worden ist. Zu diesem Zeitpunkt gibt es keinen Ausweg mehr, wenn kein guter Name gefunden wird, und so muss sich das Team möglicherweise mit Namen zufrieden geben, die nicht eindeutig sind. Die Lösung für dieses Problem besteht darin, dass die Designer*innen schon früh im Entwurfsprozess über die Transparenz von Bildschirmfunktionen und Titeln nachdenken.

Die Funktionen und Titel auf der Seite sollten sich auf die häufigsten Aufgaben konzentrieren, die von den Kund*innen ausgeführt werden. Designer*innen sind oft versucht, eine enorme Menge an Funktionen bereitzustellen, um möglichst viele Kund*innen und die Wünsche des Designteams selbst zu erfüllen. Zusätzliche Funktionen führen jedoch immer zu mehr Komplexität und anderen Kosten.

Der Titel der Seite verdeutlicht die Transparenz des Designs

Beim IUI-Modell wählen die Designer*innen die Titel der Seiten bereits in der frühesten Phase des Designprozesses aus. Anstatt einen Titel auszuwählen, um die Funktionsweise der Seite zu rechtfertigen, wird der Titel verwendet, um festzustellen, ob die Seite einen Sinn ergibt. Wenn kein passender Titel gefunden werden kann, wird die Funktion neu entworfen. Wenn kein Entwurf einen klaren und prägnanten Titel zulässt (d. h. wenn es keine Möglichkeit gibt, die Funktion zu erklären), verzichten die Designer*innen möglicherweise auf die Funktion. Vergleichen Sie in den folgenden Screenshots den Bildschirm für die Bezahlung von Money 99-Rechnungen auf der linken Seite, der ein statisches Label für die Seite bereitstellt („Anstehende Rechnungen & Einzahlungen“), und den entsprechenden Money 2000-Bildschirm auf der rechten Seite, der einen expliziten Titel hat („Klicken Sie auf die Rechnung, die Sie bezahlen möchten“):

Ein Bildschirmtitel, bei dem es sich natürlich nur um eine Phrase oder einen Satz handelt, ist leichter zu ändern als ein Design oder ein Code. Trotzdem hat die Erfahrung mit IUI gezeigt, dass die frühzeitige Festlegung eines eindeutigen Bildschirmtitels zu besseren Designs führt. Bei der Wahl des Titels sollten die Mitglieder des Teams für Benutzer*innen und Benutzerfreundlichkeit sowie die Produktdesigner*innen mitwirken.

Manchmal versuchen Teammitglieder, diese Entscheidung aufzuschieben, weil sie davon ausgehen, dass die Kund*innen den Zweck einer Seite schon verstehen werden. Wenn sie jedoch gezwungen sind, eine klare und präzise Aussage zu diesem Zweck zu machen, kommen oft Meinungsverschiedenheiten zum Vorschein. Wenn Sie diese Meinungsverschiedenheiten ausräumen und sich frühzeitig für einen Titel entscheiden, können die Designgespräche reibungsloser verlaufen.

Sobald ein Titel ausgewählt wurde, sollten Sie ihn nicht als unveränderlich betrachten. Wie bei jedem Design werden die Designer*innen die Titel der Seiten im Laufe der Zeit wahrscheinlich verfeinern. Der erste gewählte Titel sollte jedoch so stark sein, wie es in diesem Stadium der Entwicklung möglich ist.

Richtlinien für die Auswahl von Bildschirmtiteln

In diesem Abschnitt wird eine einfache Technik für die Auswahl guter Bildschirmtitel beschrieben. Um diese Technik anzuwenden, stellen Sie sich vor, dass ein/e Freund*in Sie fragt: „Wofür ist diese Seite?“, und überlegen sich dann eine klare, hilfreiche Antwort, die den Satz vervollständigt: „Das ist die Seite, auf der du ...“ Die Wörter, die den Satz vervollständigen, werden zum Bildschirmtitel.

Während der Entwicklung von Money 2000 erstellten die Dokumentationsautor*innen des Teams Richtlinien für Bildschirmtitel, um Qualität und Konsistenz zu gewährleisten. In diesen Richtlinien wurden beispielsweise Titel vorgeschlagen, die Verben verwenden und als Fragen oder direkte Anweisungen formuliert sind. Die Designer*innen vermieden statische Namen, die mehr Abstraktion zuließen und vage sein könnten.

Um die Titel zu vereinfachen, vermieden die Designer*innen zusammengesetzte Sätze und bemühten sich um eine umgangssprachliche Sprache, in der umständliche Begriffe und Fachjargon vermieden werden. Wenn die Designer*innen die Aufgabe nicht beschreiben können, ohne auf Konjunktionen („und“, „oder“) zurückzugreifen, versucht die Seite wahrscheinlich, mehr als eine Aufgabe zu erfüllen, und es ist weniger wahrscheinlich, dass die Benutzer*innen sofort verstehen, was zu tun ist.

Selbst wenn ein Titel sorgfältig ausgewählt wurde, kann die Titelleiste zu klein sein, um eine komplexe Aufgabe adäquat zu erklären. Um dieses Problem zu umgehen, können Sie einen kurzen beschreibenden Absatz am oberen Rand des Inhaltsbereichs der Seite einfügen, der die Aufgabe näher erläutert.

Die folgende Tabelle enthält einige Beispiele für Bildschirmtitel in Money 99 und Titel für dieselben oder verwandte Bildschirme in Money 2000.

Bildschirmtitel in Money 99	Neue Bildschirmtitel in Money 2000	Kommentar
Konto-Manager	Wählen Sie ein KontoRichten Sie Ihre Konten ein	Statische Titel in aktive Titel geändert.
Kontodetails	Kontoeinrichtung ändern	Statischer Titel in aktiven, spezifischen Titel geändert.
Zahlungskalender	Bezahlen Sie eine Rechnung	Vager Titel wurde beschreibend.
Manager für Online-Finanzdienste		Seite wird nach der Umgestaltung nicht mehr benötigt.

Den Titel der Seite auffällig gestalten

Sobald Sie sich auf einen nützlichen Titel für die Seite geeinigt haben, müssen Sie dafür sorgen, dass die Aufmerksamkeit des/der Benutzer*in auf diesen Titel gelenkt wird. Einige Studien haben gezeigt, dass Benutzer*innen Anleitungstexte nur selten lesen. Um dieses Problem zu überwinden, sollten Bildschirmtitel auffällig und ansprechend gestaltet sein, um die Aufmerksamkeit der Benutzer*innen auf sich zu ziehen. Die visuelle Gestaltung der Seite sollte den Benutzer*innen vermitteln, dass der Titel das Wichtigste ist, das sie lesen müssen.

Schritt drei: Passen Sie den Inhalt der Seite an die Aufgabe an

Wenn Sie eine Software erstellen, die den Richtlinien der IUI folgt, besteht die schwierigste Designarbeit in der Regel darin, Funktionen in Seiten oder Bildschirme aufzuteilen. Der nächste Schritt besteht darin, festzulegen, welche Steuerelemente auf jeder Seite verwendet werden, um die primäre Aufgabe zu erfüllen. Diese Steuerelemente bilden den Inhalt der Seite, auf der die Benutzer*innen ihre Arbeit verrichten. Der Titel und der Inhalt der Seite sind die beiden Hälften eines Dialogs zwischen dem Programm und den Benutzer*innen. Der Titel stellt die Frage des Programms oder gibt eine Anweisung, und die Reaktion der Benützer*innen erfolgt über die Schnittstelle der Seite.

Wenn der Titel des Bildschirms klar und einfach ist, ist die Gestaltung des Bildschirms in der Regel sehr einfach. Eine der oben gezeigten Seiten von Money 2000 trägt beispielsweise den Titel „Wählen Sie ein Konto aus“. Angesichts dieses Titels sollte die Seite natürlich eine einfache Liste von Konten enthalten, aus denen die Benutzer*innen wählen können. Eine andere Money 2000-Seite trägt den Titel „Überprüfen Sie die Posten, die Sie in Ihre Steuern einbeziehen müssen“. Natürlich enthält diese Seite eine Checkliste mit Posten.

Die Benutzer*innen sollten leicht herausfinden können, wie sie die Steuerelemente verwenden müssen, um die primäre Aufgabe der Seite zu erfüllen. Wenn Benutzer*innen aufgefordert werden, ein Konto auszuwählen, und sie auf der Seite eine Liste von Konten finden können, dann bestätigt das, dass sie die Aufgabe verstanden haben. Dies erhöht die Wahrscheinlichkeit, dass die Benutzer*innen die Aufgabe erfolgreich bewältigen, was wiederum ihr Vertrauen in die Ausführung anderer Aufgaben stärkt.

Bereiche des Bildschirminhalts

Die genaue Lage und Form der Bildschirminhaltsbereiche hängt von der Gestaltung der Software ab. In Money 2000 befindet sich die Region für den Bildschirminhalt unterhalb des Bildschirmtitels und rechts neben der Aufgabenliste. Diese Region kann auf langen Seiten scrollen. Einige unwichtige Inhalte können auch im Statusbereich unterhalb der Aufgabenliste erscheinen.

Designer*innen können sich dafür entscheiden, die primäre Aufgabe der Seite in einem Absatz am oberen Rand der Region für den Inhalt zu erläutern. Die Benutzer*innen müssen diesen Text nicht lesen, aber sie können ihn hilfreich finden. Viele Benutzer*innen können ihn überspringen und die Seite trotzdem erfolgreich nutzen. Im Gegensatz zum Titel kann diese Beschreibung weggescrollt werden, wenn die Seite scrollbar ist. Weitere Einzelheiten finden Sie unter Richtlinien für die Auswahl von Bildschirmtiteln.

Wenn Designer*innen möchten, dass auf einer Seite unwichtige Erinnerungen, Warnungen oder andere Statusinformationen angezeigt werden, können diese links vom Hauptinhaltsbereich unter der Aufgabenliste auf der linken Seite der Seite angezeigt werden. Funktionell ist dieser Statusbereich eine zusätzliche Region für den Inhalt der Seite. Dieser Bereich ist nicht prominent genug, um wichtige Steuerelemente zu enthalten.

Bieten Sie einen eindeutigen Ausgang von der Seite.

Nach der erfolgreichen Erledigung einer Aufgabe stehen die Benutzer*innen vor einem weiteren Problem: Wann und wie sie die Seite verlassen sollen. Bei Bildschirmen, deren primäre Aufgabe die Navigation ist, wird der/die Benutzer*in auf die nächste Seite weitergeleitet, wenn er/sie die Aufgabe selbst erledigt. Bei anderen Seiten kann es für die Benutzer*innen schwieriger sein, zu wissen, wie es weitergehen soll. Auf einer Seite, die Benutzer*innen auffordert, Informationen in Felder einzugeben, braucht der/die Benutzer*in möglicherweise Hilfe, um herauszufinden, wann und wie er/sie weitergehen soll. Auf solchen Seiten ist es oft sinnvoll, eine eindeutige Schaltfläche Weiter oder Erledigt an einer einheitlichen Stelle anzubieten.

Usability-Studien haben gezeigt, dass Benutzer*innen solche Schaltflächen auch dann bevorzugen, wenn globale Navigationsschaltflächen wie Zurück oder Startseite auf einer Symbolleiste zur Verfügung stehen. Benutzer*innen fühlen sich auf Seiten, die keinen klaren Ausgang haben, oft unwohl, selbst auf Seiten, deren einziger Zweck es ist, Informationen zu liefern, die gelesen werden sollen.

Weitere Informationen zu diesem Thema finden Sie unter Bieten Sie eine einfache Möglichkeit, eine Aufgabe abzuschließen und eine neue zu beginnen im Abschnitt „Zusätzliche Richtlinien“.

Schritt vier: Bieten Sie Links zu sekundären Aufgaben an

Der letzte Schritt bei der Gestaltung einer Seite besteht darin, Links zu sekundären Aufgaben anzubieten. Dabei handelt es sich um Funktionen, die nicht direkt die primäre Aufgabe erfüllen, aber mit der Seite in Verbindung stehen. Wenn die primäre Aufgabe auf einer Seite z. B. darin besteht, einen Brief zu schreiben, können sekundäre Aufgaben auf dieser Seite darin bestehen, eine Postadresse zu suchen oder einen Umschlag zu drucken.

Sekundäre Aufgaben können Dialogfelder aufrufen, die visuelle Darstellung des Bildschirminhalts ändern oder die Benutzer*innen zu einer anderen Seite navigieren. Eine sekundäre Aufgabe kann indirekt die primäre Aufgabe erfüllen oder verirrte Benutzer*innen zu der Stelle umleiten, nach der sie suchen.

Wenn eine Seite eine Unterhaltung zwischen dem Computer und dem/der Benutzer*in darstellt, kann der/die Benutzer*in mit einer sekundären Aufgabe die aktuelle Frage des Computers ignorieren und den Computer stattdessen bitten, etwas anderes zu tun. Stellen Sie sich zum Beispiel diesen Dialog vor: Computer: „Welche Rechnung möchten Sie bezahlen?“ Benutzer*in: „Eigentlich möchte ich nur eine Rechnung finden, die ich vor einiger Zeit bezahlt habe.“

Einige Seiten in Ihrem Produkt werden keine sekundären Aufgaben haben, während andere mehrere haben werden. Sie sollten es vermeiden, eine lange Liste von Aufgaben zu erstellen, die für Benutzer*innen wahrscheinlich schwer zu durchschauen ist. Wenn eine Seite eine relativ lange Liste von sekundären Aufgaben hat, sollten die allgemeinsten Aufgaben an erster Stelle stehen, in einem separaten Abschnitt gruppiert oder anderweitig visuell hervorgehoben werden.

Die Liste sollte nicht jede denkbare sekundäre Aufgabe enthalten, solange sie den nächsten Navigationsschritt deutlich macht. Anstatt viele sekundäre Aufgaben anzubieten, kann eine Seite sekundäre Aufgaben anbieten, die zu untergeordneten Seiten mit weiteren Aufgaben navigieren.

Visuelle Gestaltung der sekundären Aufgaben

Sekundäre Aufgaben sollten an einer untergeordneten Stelle auf der Seite aufgeführt werden, wo sie bei Bedarf zugänglich sind, aber die Benutzer*innen nicht von der primären Aufgabe ablenken. Wenn Sie diese Liste an einer einheitlichen Stelle auf jeder Seite platzieren, können die Benutzer*innen die Liste bei Bedarf schnell finden.

Wenn Sie die Liste der sekundären Aufgaben auf der linken Seite des Bildschirms anzeigen, sollte die Liste selbst nicht gescrollt werden können und auch nicht mit der Seite mitscrollen, wie im folgenden Screenshot des Bildschirms Rechnung bezahlen aus Money 2000 gezeigt.

Weitere Leitlinien

In diesem Abschnitt werden fünf nützliche Richtlinien für das Erstellen einer IUI gemäß den vier im vorangegangenen Abschnitt beschriebenen Schritten beschrieben.

Verwenden Sie einheitliche Seitenvorlagen

Bei der Entwicklung von Software, die dem IUI-Modell folgt, sollten Sie eine Vorlage erstellen, die als Anleitung für jede Seite dient. Das induktive Modell diktiert Ihnen nicht, dass Sie eine bestimmte Vorlage verwenden müssen. Es gibt viele mögliche Varianten, die ein induktives Design erfüllen können. Ihr Produkt braucht vielleicht nur eine Vorlage für alle Seiten, oder Sie erstellen mehrere verschiedene Vorlagen für unterschiedliche Zwecke.

Eine gute Vorlage bietet Benutzer*innen die Möglichkeit, schnell zu verstehen, wie die Seiten des Produkts funktionieren. Die konsequente Verwendung der Vorlage in den Bildschirmen des Produkts sorgt für einen guten Flow auf der Benutzeroberfläche von Seite zu Seite. Da die Benutzer*innen lernen, dieselben Elemente an denselben Stellen zu erwarten, können sie jede neue Seite schneller erfassen und nutzen.

Stellen Sie Seiten für den Start von Aufgaben bereit

Bei Produkten, die mit IUI entwickelt wurden, werden häufig spezielle Seiten verwendet, um Benutzer*innen mit festgelegten Aufgaben zu beginnen. Diese Seiten werden Aktivitätsseiten genannt, weil sie zusammengehörige Gruppen allgemeiner Aufgaben organisieren. Aktivitätsseiten bieten einen Ausgangspunkt für die Benutzer*innen. Eine Aktivitätsseite enthält in der Regel Links zu anderen Seiten, auf denen die Benutzer*innen ihre Aufgaben erledigen können. Aktivitätsseiten fragen die Benutzer*innen „Was möchten Sie jetzt tun?“ und präsentieren eine Liste möglicher Antworten. Aktivitätsseiten können einer speziellen Vorlage folgen, damit die Benutzer*innen sie leichter erkennen können.

Eine Aktivitätsseite ist eine gute Standardstartseite für ein Produkt. Wenn Benutzer*innen eine Anwendung starten, haben sie in der Regel eine Vorstellung von der Aufgabe, die sie erledigen möchten, im Kopf. Normalerweise ist der Grund für den Start des Produkts eine der wenigen sehr allgemeinen Aufgaben. Die Standard-Startseite des Produkts trägt diesem Umstand Rechnung, indem sie deutlich macht, wie man mit allgemeinen Aufgaben beginnt.

Die Money 2000 Start-Seite ist ein Beispiel für eine Aktivitätsseite. Benutzer*innen sehen beim Start der Anwendung standardmäßig diese Seite, auf der der Zugriff auf allgemeine Finanzaufgaben wie das Bezahlen einer Rechnung und den Kontoabschluss angezeigt wird.

Der folgende Screenshot zeigt die Money 2000 Start-Seite.

Da Money viele finanzielle Funktionen bietet, passen nur die allgemeinsten finanziellen Aufgaben auf die Seite Start. Für alle anderen Aufgaben gibt es auf der Seite Start Links zu einer Reihe von Aktivitäten, den sogenannten Finanzzentren. Jeder größere Bereich von Money bietet ein Finanzzentrum. Diese Seiten stellen die nächste Ebene von Aufgaben vor und dienen als Ausgangspunkt für alle Funktionen in jedem Bereich.

Der Money-Bereich Steuern zum Beispiel enthält die steuerbezogenen Funktionen des Produkts. Der Bereich Steuern bietet Links zu diesen Funktionen auf einer Seite Steuercenter, wie im folgenden Screenshot gezeigt.

Eine Aktivitätsseite kann auch viel einfacher sein, wenn weniger Optionen verfügbar sind. Der folgende Screenshot zeigt, wie eine Aktivitätsseite für die Verwaltung von Windows-Benutzerkonten verwendet werden könnte.

Machen Sie deutlich, wie die Aufgabe mit den Steuerelementen auf der Seite auszuführen ist.

Am besten befolgen Sie diese Richtlinie, indem Sie einen geeigneten Titel für die Seite wählen und den Bereich der primären Aufgaben auf die allgemeinsten beschränken. Sobald Sie einen eindeutigen Titel und einen klaren Zweck für die Seite gefunden haben, ist die Auswahl der richtigen Steuerelemente ein Kinderspiel.

Bieten Sie eine einfache Möglichkeit, eine Aufgabe abzuschließen und eine neue zu beginnen

Das letzte Hindernis, mit dem Benutzer*innen auf einer Seite konfrontiert werden, ist die Frage, wann und wie sie die Seite verlassen können. In der Regel verlässt der/die Benutzer*in die Seite, indem er/sie auf einen Link klickt oder einen Befehl ausführt, der zu einer anderen Seite navigiert. Diese Links können im Inhaltsbereich der Seite, in der Aufgabenliste oder in den Symbolleisten der Navigation erscheinen. Benutzer*innen können eine Seite auch verlassen, indem sie die aktuelle Datei oder die Anwendung selbst schließen.

Auf manchen Seiten geht es darum, einen Vorgang vorzubereiten, den der/die Benutzer*in bestätigen oder abbrechen muss. Solche Seiten bieten in der Regel einen Link, der den Vorgang ausführt und bestätigt, und einen weiteren Link, der ihn abbricht. Wenn der/die Benutzer*in diese Optionen ignoriert und auf einen anderen Link klickt, sollte das Programm die weniger destruktive Option ausführen. Auf den Seiten sollte angegeben werden, was passiert, wenn die Benutzer*innen diesen Weg einschlagen. Sie können die Links so formulieren, dass dies deutlicher wird. Eine Schaltfläche mit der Aufschrift „Änderungen speichern“ bedeutet zum Beispiel, dass die auf der Seite vorgenommenen Änderungen erst dann wirksam werden, wenn Sie auf diese Schaltfläche klicken.

Auch wenn Benutzer*innen die Seite verlassen können, wann immer sie wollen, sollten Sie einen Link anbieten, der auf das Verlassen der Seite hinweist. Das Gleiche gilt für Seiten, die lediglich statische Informationen anzeigen. Weitere Informationen zu diesem Thema finden Sie im Abschnitt Bieten Sie einen eindeutigen Ausstieg aus der Seite.

Starten und Beenden von Prozessen

Für die Zwecke dieses Artikels sind Prozesse Techniken für den Umgang mit Aufgaben, die die Benutzer*innen auf mehr als eine Seite führen.

Nehmen wir an, eine/ein Benutzer*in klickt auf einen Link in der Inhalts- oder Aufgabenliste einer Seite und wird zu einer anderen Seite weitergeleitet. Diese Seite wiederum könnte die erste einer Reihe von Seiten sein, die ein bestimmtes Endergebnis liefern. Am Ende dieser Reihe von Bildschirmen möchte die/der Benutzer*in zu dem Bildschirm zurückkehren, der dem Prozess vorausging. Es gibt mindestens zwei Möglichkeiten, wie der/die Benutzer*in zurückkehren kann: Indem er/sie wiederholt auf die Schaltfläche „Zurück“ klickt oder zur Startseite zurückkehrt und von dort aus navigiert. Doch keine dieser beiden Methoden ist offensichtlich oder natürlich. Die meisten Benutzer*innen erwarten, dass sie auf der letzten Seite eine Schaltfläche finden, die sie direkt zur ursprünglichen Seite zurückbringt.

Das IUI-Modell unterstützt dieses Szenario durch das Konzept eines Prozesses, einer Seite oder einer Reihe von Seiten, die als eine Navigationseinheit behandelt werden. Benutzer*innen können den Prozess betreten, sich durch seine Seiten arbeiten und auf der letzten Seite eine Schaltfläche finden, die sie zum Ausgangspunkt zurückbringt. Wichtig ist, dass die Benutzer*innen den Prozess von mehreren Stellen im Produkt aus starten können. Die Benutzer*innen kehren immer an die Stelle zurück, an der sie begonnen haben, unabhängig davon, wo sie sich befanden, als sie den Prozess begannen.

Prozessname

Jedem Prozess sollte ein Name gegeben werden, und der Name sollte irgendwo auf jeder Seite des Prozesses erscheinen. Money 2000 verwendet diesen Ansatz. Jede Seite, die Teil eines Gesamtprozesses ist, enthält den Namen dieses Prozesses am oberen Rand. Dieser Prozessname wird weniger prominent angezeigt als der eindeutige Titel der Seite, da er weniger wichtig ist. Der Prozessname erinnert die Benutzer*innen daran, welchen Prozess sie gerade durchführen, und verstärkt den Eindruck, dass alle Seiten des Prozesses Teil einer einzigen Funktion sind. Der Bereich Besteuerung enthält zum Beispiel einen Steuerschätzer-Prozess, der sich über mehrere Seiten erstreckt. Auf jeder Seite dieses Prozesses wird sowohl der Name des Gesamtprozesses als auch der Titel des jeweiligen Bildschirms angezeigt.

Implementierung von Prozessen

Ein und derselbe Prozess kann über verschiedene Links auf unterschiedlichen Seiten gestartet werden, und die Benutzer*innen werden immer auf die richtige Startseite zurückgebracht. Dieses Verhalten kann nicht durch einen fest codierten Link auf der letzten Seite des Prozesses erreicht werden, da das Ziel des Links variiert. Stattdessen kann die Anwendung dieses Verhalten implementieren, indem sie einen Stack aktiver Prozesse unterhält, unabhängig von dem normalen Navigationsstack, der von den Befehlen Zurück und Weiter verwendet wird. Wenn die Benutzer*innen einen Prozess starten, wird die Seite, die den Prozess startet, auf den Stack gepusht. Wenn der/die Benutzer*in auf der letzten Seite des Prozesses auf die Schaltfläche Fertig klickt, entfernt die Anwendung die letzte Startseite aus dem Stack und kehrt zu dieser Seite zurück.

Wenn Benutzer*innen eine Seite eines Prozesses verlassen, bleibt der Prozess auf dem Stack aktiv. Benutzer*innen können den Prozess abschließen, indem sie zu der Seite zurückkehren, auf der sie ihn verlassen haben, und dann fortfahren. Dies bietet Benutzer*innen die Möglichkeit, einen Umweg zu machen, zurückzugehen und dann mit dem Prozess fortzufahren. Um zu sehen, wie dieses Verhalten funktioniert, beginnen Sie einen beliebigen Online-Einkaufsprozess im World Wide Web, verlassen die Website und drücken dann die Schaltfläche Zurück. Im Allgemeinen können Sie dort weitermachen, wo Sie aufgehört haben.

Schältfläche „Fertig”

Um eine Seite abzuschließen und zur nächsten Seite des Prozesses zu gelangen, können Bildschirme eine Schaltfläche am unteren Rand der Seite anzeigen. Das Label dieser Schaltfläche lautet „Weiter“, „Erledigt“ oder etwas Ähnliches. Wenn die Schaltfläche den Prozess beendet und der Prozess von mehreren Stellen aus aufgerufen werden kann, kann die Beschriftung der Schaltfläche Erledigt den Namen der aufrufenden Stelle enthalten.

Navigationsleiste

Auf jeder Seite können Benutzer*innen entscheiden, dass sie mit dem aktuellen Bereich des Produkts fertig sind und etwas anderes beginnen möchten. Möglicherweise möchten sie die aktuelle Seite nicht explizit abschließen, bevor sie zu einem anderen Teil des Produkts wechseln. Eine Navigationssymbolleiste kann den Benutzer*innen eine Reihe von Links zum Starten neuer Aufgaben anbieten. Wie bei anderen Listen von Links zu Aufgaben sollten diese dem Prinzip folgen, dass der nächste Navigationsschritt offensichtlich sein muss, was im folgenden Abschnitt ausführlich erläutert wird.

Machen Sie den nächsten Navigationsschritt deutlich

Nur wenige Programme können alle ihre Funktionen gleichzeitig zur Verfügung stellen. Benutzer*innen müssen im Allgemeinen durch ein Programm navigieren, um eine bestimmte Funktion zu finden. Benutzer*innen sind bei der Navigation erfolgreicher, wenn sie leicht erkennen können, wie sie zumindest einen Schritt näher an ihr gewünschtes Ergebnis kommen. Bei der Gestaltung von Seiten, die IUI verwenden, wird dieses Prinzip berücksichtigt.

Zum Beispiel zeigen Aktivitätsseiten nicht unbedingt alle denkbaren Aufgaben oder Ziele an, die die Benutzer*innen von diesem Punkt aus erreichen möchten. Stattdessen bieten Aktivitätsseiten eine Liste von Aufgaben, die vollständig genug ist, sodass Benutzer*innen leicht den passenden Link zum Anklicken finden können, selbst wenn dieser sie nur zu einer anderen Seite mit Links führt. Die häufigsten Aufgaben sollten am deutlichsten hervorgehoben sein und den geringsten Navigationsaufwand erfordern. Weniger häufige Aufgaben können mehr Schritte erfordern.

Hier ist ein Beispiel aus Money 2000. Angenommen, Benutzer*innen möchten einen Vorgang durchführen, den sie nur gelegentlich erledigen, z. B. die geschätzte Höhe der Einkommenssteuerzahlung für das nächste Jahr überprüfen. Die Benutzer*innen beginnen zunächst mit der Suche nach dieser Funktion auf der Money 2000-Startseite. Da die Funktion nicht in der Liste der allgemeinen Aufgaben erscheint, müssen sie die Liste der Finanzbereiche durchsuchen. Der Bereich Steuern klingt vielversprechend, also klicken Sie ihn an. Die Seite Steuer-Center enthält einen Link zu der gesuchten Funktion für die Steuerschätzung, also klicken sie darauf und erledigen ihre Aufgabe. Durch die Anwendung der IUI-Prinzipien ermöglicht Money 2000 den Benutzer*innen, intuitiv das zu finden, was sie suchen.

Benutzerhilfe

Dieser Abschnitt beschreibt eine Reihe von Vorschlägen für die Integration von Benutzer*innen in ein Produkt, das IUI verwendet.

Primäre Hilfe bezieht sich auf den gesamten Text, der auf der Seite sichtbar ist (wie im folgenden Screenshot gezeigt). Die primäre Hilfe bietet aufgabenbezogene, textliche Hinweise, damit die Benutzer*innen alle auf der Seite dargestellten Informationen leicht verstehen können. Sie verstehen das Ziel der Seite und die Art und Weise, wie die Objekte zueinander in Beziehung stehen, um die Aufgaben zu erfüllen. Da sich der Text direkt auf dem Bildschirm befindet, sind die Informationen, die Neulingen Fragen wie „Was soll ich tun?“ beantworten, leicht zugänglich und gut sichtbar, ohne dass die Benutzer*innen etwas tun müssen.

Die sekundäre Hilfe besteht aus dem gesamten Text, der auf der Seite nicht sichtbar ist und für den Zugriff eine gewisse Interaktion der Benutzer*innen erfordert, z. B. durch Klicken oder Bewegen des Mauszeigers über ein Element auf der Benutzeroberfläche. Dieser Inhalt ist nicht unbedingt notwendig, um die Aufgabe zu erfüllen, steht aber dennoch in direktem Zusammenhang.

Primäre Hilfe

Die primäre Hilfe kann einige oder alle der folgenden Komponenten enthalten:

• Titel der Seite

  Beispiel: Ändern Sie Ihr Bild

  Der Titel der Seite ist das erste und wichtigste Element, das auf der Seite erscheint. Er soll in der Sprache der Benutzer*innen die Aufgabe beschreiben, die auf dieser Seite erledigt werden kann. Der Titel der Seite sollte es vermeiden, die Details zur Erledigung der Aufgabe zu beschreiben. Der Text im Bildschirmtitel sollte sich nur auf die Kernaufgabe der Seite beziehen. Als Faustregel gilt: Je einfacher und kürzer die Beschreibung der Aufgabe ist, desto besser ist die Aufgabe wahrscheinlich definiert. Ausführlichere Informationen zu diesem Thema finden Sie unter Schritt zwei: Status der Aufgabe.

• Untertitel der Seite

  Beispiel: Sie können auch ein neues Bild aus dem Internet herunterladen.

  Selbst wenn Sie sich große Mühe geben, reicht der Titel der Seite möglicherweise nicht aus, um eine komplexe Aufgabe angemessen zu erklären. Der Untertitel bietet Ihnen die Möglichkeit, den Zweck der Seite näher zu erläutern. Sie können einen Untertitel verwenden, um den Zweck der Seite zu verdeutlichen, eine zusätzliche Aufgabenbeschreibung bereitzustellen oder um Erwartungen festzulegen. Benutzer*innen, die den Untertitel nicht lesen, sollten in der Lage sein, die Seite erfolgreich zu nutzen. Genau wie der Titel sollte auch der Untertitel keine Details zur Erledigung der Aufgabe beschreiben.

• Aufgaben

  Beispiel: Ändern Sie Ihren Bildschirmschoner

  Aufgaben können als Textlinks oder grafische Bilder dargestellt werden, die eine Interaktion der Benutzer*innen erfordern. Befehle, die als Textlinks dargestellt werden, sollten auf Verben basieren und als klare und prägnante Aufgaben geschrieben sein.

• Labels für Befehlsschaltflächen

  Beispiel: Kennwort erstellen

  Es gibt drei Arten von Befehlsschaltflächen:

  • Abbrechen
  • Fertig
  • Commit

  Die Schaltflächen „Abbrechen“ und „Fertig“ verwenden einfach „Abbrechen“ und „Fertig“ als Label. Bei Schaltflächen für Befehle sollten Sie anstelle von „OK“ aktive Text-Labels verwenden. Verwenden Sie zum Beispiel „Kennwort erstellen“ anstelle von „OK“.

• Labels für andere Steuerelemente

  Beispiel: Kennwort eingeben

  Labels für Steuerelemente wie Optionsschaltflächen, Kontrollkästchen und Textfelder sollten klar und prägnant formuliert sein, sodass die Benutzer*innen genau wissen, wofür die Steuerelemente da sind, welche zu verwenden sind und welche Informationen zur Erledigung ihrer Aufgabe eingegeben werden müssen.

• Links für „Verwandte Aufgaben“

  Beispiel: Verwandte Aufgaben – Anderes Konto ändern

  Links zu „verwandten Aufgaben“ sind explizite Einstiegspunkte zu anderen Aufgaben, die mit der aktuellen Funktion zusammenhängen. Sie sollten als aufgabenbezogene Links geschrieben werden.

• „Siehe auch“-Links

  Beispiel: Siehe auch – Ändern des Designs

  Links zum Thema „Siehe auch“ sind sekundäre Aufgaben. Sie stehen in Zusammenhang mit der primären Aufgabe, führen die Benutzer*innen aber aus dem aktuellen Kontext heraus. Sie sollten wie normale Links zu Aufgaben erscheinen. Weitere Informationen zu sekundären Aufgaben finden Sie unter Visuelle Gestaltung von sekundären Aufgaben.

Sekundäre Hilfe

Die sekundäre Hilfe kann einige oder alle der folgenden Komponenten enthalten:

• InfoTips

  Sie können einen InfoTip verwenden, um dem/der Benutzer*in zusätzliche Informationen über einen Aufgaben-Link oder eine Befehlsschaltfläche zu geben. Ein InfoTip zu einem Link für eine Aufgabe könnte beispielsweise lauten: „Zeigt eine Seite an, auf der Sie ein Bild auswählen können, das Sie für Ihr Konto verwenden möchten.“ Der InfoTip erscheint, wenn die Benutzer*innen mit der Maus über das zugehörige Objekt fahren. Sie sollten InfoTips für alle Elemente der Benutzeroberfläche erstellen, auf die die Benutzer*innen klicken können.

• „Erfahren Sie mehr“-Hilfethemen

  Beispiel: Erfahren Sie mehr über – Herunterladen einer Datei

  Links zum Thema „Erfahren Sie mehr“ öffnen Hilfethemen wie Übersichten über Funktionen, konzeptionelle Informationen, unterstützende Informationen und Informationen zur Vorgehensweise. Um die Übersichtlichkeit zu wahren, sollten Sie die Anzahl der „Erfahren Sie mehr“-Hilfethemen auf der Seite minimieren.

Anhang: Design und Test von Microsoft Money 2000

Dieser Abschnitt basiert auf den eigenen Beschreibungen der Designer*innen. Er beschreibt, wie das Money 2000-Team den Entwurfs- und Testprozess geändert hat, um das IUI-Modell zu berücksichtigen.

Design und Test von Money 2000

Die Entwicklung von Money 2000 unter Verwendung des induktiven Navigationsmodells veranlasste das Team, Entwürfe in Frage zu stellen, die schon seit Langem im Produkt enthalten waren. Da die Prinzipien des Modells einfach sind, war es einfach, das Modell im Designprozess zu adaptieren und beizubehalten. Letztendlich glauben die Designer*innen, dass das Modell ihnen geholfen hat, bessere Entwürfe zu erstellen, als sie es ohne das Modell hätten tun können.

Klarere Titel und Designs

Den Designern*innen von Money 2000 fiel auf, dass sie Funktionen oft mit Worten beschrieben, die auf der Seite gar nicht vorkamen. Nach dem IUI-Modell sollten sich die Seiten selbst erklären. So erklärte das Team zum Beispiel, dass die Seite mit dem Label Zahlungskalender für das Bezahlen von Rechnungen gedacht war. In Money 2000 heißt diese Seite Rechnungen bezahlen. Alle Elemente, die nicht mit diesem Zweck in Verbindung stehen, wurden auf untergeordnete Seiten verschoben, was zu einem klareren Design führt.

Ein weiteres Beispiel ist eine Seite mit dem Namen Online Financial Services Manager. Das Team hatte Mühe, eine einfache Erklärung für den Zweck dieser Seite zu finden. Als dies nicht gelang, entfernten sie diese Seite und verteilten ihre Funktionen auf logischere Seiten.

Hilfe für neue Designer*innen

Dem Team fiel es leicht, neuen, unerfahrenen Software-Designer*innen IUI-Designtechniken beizubringen. Die Techniken boten Designer*innen aller Erfahrungsstufen die Möglichkeit, ihre Seiten anhand von Bildschirmtiteln auf ihre Transparenz hin zu überprüfen. Wenn sie einen klaren und prägnanten Titel für eine schlecht gestaltete Seite entwerfen mussten, erkannten die Designer*innen schnell, dass kein Titel gut genug für diese Seite war. Sie erkannten, dass das Problem nicht in der Wahl der Worte für einen Titel lag, sondern in einer mangelhaften Gestaltung der Seite. Mit dieser Erkenntnis konnten sie dann die Seite so umgestalten, dass sie eine klarere Interaktion der Benutzer*innen und damit auch einen klareren Titel unterstützte.

Autor*innen einbeziehen

Im Laufe des Entwurfs erkannte das Team, dass Dokumentationsautoren*innen und Redakteur*innen in die Erstellung von Bildschirmtiteln einbezogen werden sollten. In früheren Versionen waren die Autor*innen nur begrenzt in der Lage, gute Titel auszuwählen, da sie erst in einem späten Stadium einbezogen wurden. Die Designer*innen oder Programmierer*innen gaben den Seiten in der Regel vorläufige Arbeitstitel. Diese Titel wurden erst spät im Produktzyklus verwendet, als die Autor*innen gebeten wurden, die endgültigen Bildschirmtitel zu entwerfen. Zu diesem Zeitpunkt war es zu spät, schlecht gestaltete Seiten zu überarbeiten.

Im Gegensatz dazu bezog das Money 2000-Team die Autor*innen schon in den frühesten Phasen des Designprozesses mit ein. So konnten sie bereits wertvolle Beiträge zu den Bildschirmtiteln liefern, als diese noch für das Design von Bedeutung waren. Wenn eine Seite zu komplex war, um einen klaren Titel zu ermöglichen, konnten die Autor*innen vorschlagen, die Seite neu zu gestalten.

Am Ende des Projekts waren die Autor*innen und Designer*innen der Meinung, dass die Seitentitel klarer und aussagekräftiger waren als in früheren Versionen. Die Autor*innen fanden es auch einfacher, neue Seiten zu erklären, was die Arbeit an der Dokumentation des Produkts vereinfachte. Alle Teammitglieder waren der Meinung, dass die Einbeziehung aller Disziplinen in die Designphase das Produkt besser und benutzerfreundlicher gemacht hat.

Tests zur Benutzerfreundlichkeit

Während der Entwicklung von Money 2000 führte das Team mehrere Usability-Tests durch, um die Unterschiede zwischen der alten Navigationsstruktur von Money 99 und den Änderungen zu untersuchen, die durch die Anwendung des IUI-Modells vorgenommen wurden.

Testen des Prototyps

Zu Beginn der Produktentwicklung erstellten die Designer*innen einen Prototyp, um herauszufinden, wie die Benutzer*innen auf IUI reagieren würden. Diese Arbeit wurde in einem sehr frühen Stadium der Entwicklung durchgeführt, um die Möglichkeit zu bieten, die Prinzipien des Modells zu verfeinern, bevor die Entwickler*innen mit der Überarbeitung des Produkts selbst begannen.

Das Team erstellte einen Prototyp in Microsoft Visual Basic und HTML, der die Aktivitäten im Bereich der persönlichen Finanzen simulierte, die normalerweise in Money durchgeführt werden. In dem Prototyp konnten die Benutzer*innen zu mehr als 50 Seiten navigieren, die die Hauptbereiche des Produkts darstellten. In diesen Bereichen konnten sie Finanzkonten festlegen, Rechnungen bezahlen, Berichte einsehen und mit ihren Investitionen arbeiten.

Elf Testpersonen führten dieselben Aufgaben sowohl in Money 99 als auch im IUI-Prototyp aus. Die Testpersonen wurden nach dem Zufallsprinzip ausgewählt, um eines der beiden Produkte zuerst zu benutzen. Vier Personen waren derzeitige Benutzer*innen von Money, vier waren derzeitige Benutzer*innen eines Konkurrenzprodukts, und drei hatten noch nie ein Produkt für persönliche Finanzen verwendet.

Die Gesamtpräferenzen zeigten, dass die vier derzeitigen Benutzer*innen von Money Money 99 (die Version, die sie zu Hause verwendet hatten) bevorzugten, während die übrigen sieben Benutzer*innen den neuen Prototyp der aktuellen Version vorzogen. Bei allen anderen Messungen gab es keinen Unterschied zwischen den Benutzer*innen der drei Gruppen. In Bezug auf die Gesamtleistung befanden sich die Benutzer*innen mit Money 99 doppelt so oft im falschen Bereich des Produkts (2,82 Mal pro Aufgabe) wie mit dem Prototyp (1,45 Mal pro Aufgabe). Andere Präferenzdaten und Kennzahlen, die zwar nicht signifikant waren, schienen den Prototyp zu bevorzugen. Auf der Grundlage dieser Daten und anderer Tests beschloss das Money-Produktteam, die IUI-Prinzipien in Money 2000 zu integrieren.

Testen des Produkts

Nachdem der Großteil des Codes für das Produkt fertiggestellt war, führte das Team eine weitere Nutzbarkeitsstudie durch, um die endgültige Implementierung von IUI zu untersuchen. Bei diesem Test wurden 10 Testpersonen, die noch nie ein Produkt für persönliche Finanzen benutzt hatten, ausgewählt, um entweder Money 99 oder Money 2000 zu benutzen. Alle Benutzer*innen führten die gleichen Aufgaben aus.

Die Benutzer*innen von Money 2000 erledigten 89 % der Aufgaben erfolgreich, während die Benutzer*innen von Money 99 nur 74 % der Aufgaben erfolgreich erledigten. Wie beim Prototyp schienen die Benutzer*innen auch bei Money 2000 im Vergleich zu Money 99 schneller zu navigieren, allerdings ohne signifikante Unterschiede. Darüber hinaus waren die subjektiven Messungen der Gesamtzufriedenheit mit der Navigation bei Money 2000 tendenziell höher als bei Money 99.

Kontrolliertes Testen

Da Money 2000 riesig und komplex ist, eignet es sich nicht gut für die Durchführung kontrollierter Experimente zu den Auswirkungen der Anwendung von IUI. Stattdessen erstellte das Team eine eingeschränktere Umgebung für den Test.

Der Test umfasste eine Anwendung „Stock Market Viewer“, die den Benutzer*innen die Möglichkeit bot, den Bildschirm eines auf der Seite angezeigten Börsenberichts zu verändern. Die Benutzer*innen konnten ändern, welche Datenspalten in dem Bericht enthalten waren, die Reihenfolge der Berichtsspalten, ihre Ausrichtung und die Anzahl der verwendeten Dezimalstellen. Die Designer*innen wollten sehen, wie ein IUI-Ansatz für diese Aufgabe im Vergleich zu einer herkömmlichen grafischen Benutzeroberfläche abschneiden würde.

Der folgende Screenshot zeigt die herkömmliche Benutzeroberfläche, die für den Test verwendet wurde. Ein einziger Dialog führt alle Aufgaben der Berichtsanpassung aus. Viele Anwendungen bieten ein ähnliches Dialogfeld für die Auswahl einer Untermenge aus einer Liste von Elementen. Der Dialog enthält zwei Listen: Die linke Liste liefert alle verfügbaren Berichtsspalten, die rechte zeigt die Untermenge der Spalten an, die der/die Benutzer*in für den Bericht ausgewählt hat. Zusätzliche Steuerelemente ändern die Reihenfolge und die Formatierungsattribute für die in der rechten Liste ausgewählten Berichtsspalten.

Für die IUI-Version dieser Aufgabe erstellte das Team eine Anwendung im Web-Stil. Jede Anpassungsaufgabe wurde auf einer eigenen Seite platziert. Die Anwendung enthielt auch eine Hauptseite, die im folgenden Screenshot zu sehen ist und auf der die Benutzer*innen gefragt werden, wie sie den Bericht anpassen möchten.

Durch Anklicken von Links auf dieser Hauptseite gelangen die Benutzer*innen zu weiteren Seiten, auf denen sie bestimmte Anpassungsaufgaben durchführen können. Der folgende Screenshot zeigt zum Beispiel die Seite, die zur Auswahl von Berichtsspalten dient.

In Tests beider Versionen wurden die Testpersonen gebeten, Berichte von einem bestimmten Ausgangsstatus (auf dem Bildschirm angezeigt) bis zu einem bestimmten Zielstatus (auf einem Papierhandzettel) anzupassen. Der Computer zeichnete die Zeit und die Anzahl der Versuche auf, die die Testpersonen unternahmen, um den Bericht anzupassen. Der Computer informierte die Benutzer*innen, wenn sie den Bericht erfolgreich angepasst hatten.

An dem Test nahmen 88 Personen teil. Die Testpersonen wurden gebeten, einen Satz von 11 Berichten mit einer der beiden Versionen der Anwendung individuell anzupassen. Darüber hinaus kamen 72 dieser Testpersonen eine Woche später zurück, um einen weiteren Satz von 11 Berichten mit der gleichen Version wie in der ersten Sitzung anzupassen. Alle Probanden wurden als Computeranfänger*innen eingestuft, die den Computer hauptsächlich für E-Mails, zum Spielen von Solitaire und zum Surfen im Internet nutzen.

Es gab keine signifikanten Unterschiede zwischen den Benutzer*innen der beiden Versionen oder einer der anderen Variablen von Interesse. Die Benutzer*innen erledigten die Aufgaben mit der gleichen Geschwindigkeit, wiederholten die Aufgabe genauso oft und hatten die gleichen subjektiven Bewertungen für die beiden Versionen. Dieser Test zeigte also keine Messungen, bei denen IUI zu einer Verbesserung oder Verschlechterung der Leistung oder der subjektiven Bewertungen führte.

Man könnte argumentieren, dass, wenn die Benutzer*innen mehr navigieren müssen, um die Aufgabe zu erfüllen, der Zeitaufwand für die Erfüllung der Aufgabe größer sein sollte. Auch wenn dieses Experiment nicht auf dieses Ergebnis hindeutet, ist es doch wichtig festzustellen, dass die mittleren Leistungszeiten und die dazugehörigen Standardabweichungen für die beiden unterschiedlichen Ansätze für diese Aufgabe nahezu identisch waren.

Weitere Untersuchungen werden notwendig sein, um festzustellen, ob es messbare Verbesserungen durch den Einsatz von IUI gibt. Zumindest lieferte dieser Test keine Fakten dafür, dass IUI die Leistung oder die Produktnutzung beeinträchtigt.

Vergleich mit Websites

Viele gut gestaltete Websites verwenden ähnliche Prinzipien wie das in diesem Dokument beschriebene IUI-Modell. Dies ist wahrscheinlich ein Nebeneffekt der Funktionsweise des Webs. Da es schwierig ist, komplexe Interaktionen zwischen Steuerelementen auf einer einzigen Webseite zu implementieren, teilen die Designer*innen die Aufgaben oft in mehrere Teile auf, die mehr als einen Abruf einer neuen Seite auf dem Server erfordern. Einige Websites enthalten sogar Seitentitel, die den Zweck der Seite klar angeben.

Designer*innen traditioneller Anwendungen verfügen über eine wesentlich umfangreichere Palette von Tools. Das gibt ihnen mehr Flexibilität, bietet aber auch mehr Möglichkeiten, komplexe und verwirrende Seiten zu erstellen. Beim Erstellen induktiver Benutzeroberflächen sollten Designer*innen diese Möglichkeiten mit Bedacht nutzen und daran denken, dass sie Wert auf Transparenz und Einfachheit legen.