SAP DESIGN GUILD

UI First – Der Anwender im Mittelpunkt

Von Hendrik Achenbach, User Productivity, SAP AG – 19/11/2004

English Version • This article has also been published in SAP INFO 122

In der Vergangenheit hat das Design der Benutzungsoberfläche häufig eine untergeordnete Rolle im Entwicklungsprozess gespielt. Die Aufgaben und Anforderungen der Anwender wurden dabei außer Acht gelassen. Um die Benutzungsfreundlichkeit der Systeme und damit auch die Produktivität der Anwender zu steigern, hat SAP einen neuen Prozess entwickelt, bei dem die Anwender bereits früh in die Entwicklung einbezogen werden: UI First.

Jedem Softwareanbieter ist daran gelegen, Produkte zu entwickeln, die die Produktivität des Kunden steigern. In dieser Hinsicht sind Benutzungsoberflächen von besonderer Bedeutung. Denn sie können nicht nur für ein komfortableres Arbeiten sorgen und den Schulungsaufwand für die Software senken, sondern die Anwender sogar in die Lage versetzen, schneller bessere Ergebnisse zu erzielen.

In der Praxis stehen sich die Entwicklung der Softwarefunktionen und die Entwicklung intuitiver Benutzungsoberflächen allerdings manchmal gegenseitig im Weg. Denn häufig sind es die Entwickler, die sowohl den Programmcode als auch das Oberflächendesign entwickeln. Laut Alan Cooper führt dies unweigerlich zu einem Interessenkonflikt und Qualitätseinbußen beim Produkt, weil die "Entwickler in der Regel an ihrer Fähigkeit, effizient zu kodieren, und an der Einhaltung unglaublich enger Termine gemessen werden." [1]

Weiter verschärft wird diese Problematik dadurch, dass Entwickler sich aus einer technischen Perspektive mit den Benutzungsoberflächen befassen müssen, um sicherzustellen, dass sie reibungslos funktionieren. Die Oberfläche entwickeln sie häufig erst, wenn alle darunter liegenden technischen Gegebenheiten verfügbar sind. Denn die Benutzungsoberfläche setzt auf den Funktionen in der Programmlogik und der Datenbank auf; weshalb sollte man sich dann auch nicht zunächst um deren Entwicklung kümmern und einfach abwarten, was für eine Benutzungsoberfläche sich am Ende ergibt?

Diese Vorgehensweise führt aber unausweichlich zu einer Oberfläche, die wie eine Datenbank strukturiert ist und von den Anwendern verlangt, entlang der Programmlogik zu arbeiten und zu interagieren. Die Interaktion mit dem System sollte aber vielmehr von der Handlungs- und Denkweise der Anwender gesteuert sein.

Auch wenn Entwickler sich um eine intuitiv bedienbare Oberfläche bemühen: Ihre technische "Brille" können sie nicht einfach absetzen – und wer kann schon gleichzeitig durch zwei Brillen sehen?

 

Teams machen den Unterschied

Dieses Dilemma lässt sich lösen, indem die Aufgaben in einem Entwicklungsprojekt aufgeteilt werden, und dies ist eines der wichtigsten Merkmale von UI First, dem neuen SAP-Prozess für die Entwicklung von Benutzungsoberflächen. Während die Stärke der Produktmanager in der Zusammenarbeit mit den Anwendern und der Beurteilung der Marktsituation liegt, können Entwickler sehr gut beurteilen, inwieweit Designkonzepte technisch machbar und in Software umzusetzen sind. Technische Redakteure wiederum kümmern sich um die entsprechende Terminologie, weshalb sie auch für die Oberflächentexte verantwortlich sein sollten. Und die Designer der Benutzungsoberflächen haben das richtige Gespür dafür, wie die Oberflächenbausteine zu einem guten Prototyp vereint werden können.

Um die ganze Spannbreite dieser unterschiedlichen Fähigkeiten bestmöglich auszuschöpfen, hat SAP die Oberflächenentwicklung in vier Phasen mit insgesamt vierzehn Prozessschritten unterteilt:

• Phase 1: Forschung (Schritt 1 bis 4)
  In dieser Phase werden Kunden besucht, Anwender bei ihrer Arbeit beobachtet und nach ihren Anforderungen befragt. Die hier gesammelten Daten bilden die Grundlage für ein Dokument mit Benutzerszenarien, in dem die verschiedenen Benutzertypen sowie typische Arbeitssituationen und zentrale Aufgaben beschrieben werden.
• Phase 2: Designkonzept (Schritt 5 und 6)
  In dieser Phase werden die benötigten Anwendungen in einzelne Arbeitspakete aufgeteilt, so genannte Worksets (jedes Workset entspricht einem Einzelbereich einer bestimmten Tätigkeit, beispielsweise Budgetierung oder Berichtswesen). Anschließend folgt für jede Teilanwendung ein abstrakter Entwurf der Benutzungsoberflächen, das User Environment Design (UED). Es beinhaltet Informationen zu Funktionen, Arbeitsobjekten und zur Navigation zwischen verschiedenen Bildschirmen einer Anwendung.
• Phase 3: Detailliertes Design (Schritt 7 bis 10)
  In dieser Phase werden, aufbauend auf der Workset-Struktur und den UEDs, die ersten Prototypen der Benutzungsoberflächen erstellt. Dabei arbeiten die Designer mit verschiedenen Methoden und Werkzeugen, unter anderem mit klassischen Papierprototypen und mit HTML. Bevor die Prototypen den Anwendern für Tests zur Verfügung gestellt werden, erfolgt eine interne Prüfung, z. B. durch andere Designer.
• Phase 4: Übergabe (Schritt 11 bis 14)
  In dieser Phase nehmen die endgültigen Prototypen für die Oberfläche Gestalt an und die entsprechenden Spezifikationen werden geschrieben und verabschiedet. Danach kann die Implementierung der Oberflächen beginnen.

UI First funktioniert nur dann wie geplant, wenn das Team von Anfang bis Ende zusammenarbeitet. Erhalten die Entwickler die Prototypen und Spezifikationen erst nach der Fertigstellung und hatten sie keine Gelegenheit, etwas dazu beizutragen, ist die Wahrscheinlichkeit gering, dass sie die Oberflächen so implementieren, wie sie spezifiziert sind. Andererseits werden sie die Usability Tests, denen die Prototypen unterzogen werden, vermutlich mit anderen Augen sehen, wenn sie einmal an einem solchen Test teilnehmen konnten. Auf diese richtige Balance zwischen Aufgabenverteilung und Teamarbeit wird bei UI First sehr viel Wert gelegt.

 

Projektrollen und Benutzerrollen

UI First ist angewiesen auf ein Team, in dem jedes Mitglied eine andere Projektrolle hat (wie etwa Produktmanager, Entwickler oder Oberflächen-Designer). Der Begriff der "Rolle" erhält im Zusammenhang mit UI First aber auch noch eine zweite, ebenso wichtige Bedeutung: Die Teammitglieder müssen sich bereits von Entwicklungsbeginn an über die Benutzerrollen im Klaren sein. Denn von den Benutzerrollen hängt es ab, zu welchen Benutzern und Tätigkeiten im ersten Prozessschritt Daten gesammelt werden. Anhand dieser Informationen entwickelt das Team eine so genannte "Persona" (einen fiktiven, jedoch realistischen Benutzer), welche die Anwender repräsentiert und als ständiger Kontrollpunkt für Designentscheidungen dient.

Zwar hilft die Persona dem Projektteam dabei, die Anforderungen der Anwender besser zu verstehen, doch der stetige Kontakt zu den realen Benutzern bleibt unerlässlich und ist wesentlicher Bestandteil des UI-First-Prozesses. Die ersten Befragungen und Beobachtungen der Anwender, die in den zu entwickelnden Rollen arbeiten sollen, ergeben eine umfassende Datensammlung. Sie dient in den nächsten Prozessschritten als Grundlage für fundierte Entscheidungen bezüglich des Designs.

Nachdem das Team ein Designkonzept der "Rolleninhalte" (also alle Anwendungen und Informationen, die die Anwender für ihre Arbeit benötigen) erstellt hat, sollte es den Endanwendern vorgelegt werden. Das Gleiche gilt für die Prototypen der Benutzungsoberflächen, die später entwickelt werden.

Bei UI First stehen also zwei Aspekte im Vordergrund: Teamarbeit und eine iteratives Design von Oberflächen. Aufgrund der Rahmenbedingungen – hier sind vor allem knappe Budgets und Termindruck zu erwähnen – bleibt die Umsetzung dieser Aspekte jedoch eine der größten Herausforderungen in einem nach UI First aufgestellten Entwicklungsprojekt.

 

Keine Endlosschleife

Zwar stehen bei UI First die Anwender im Mittelpunkt des gesamten Entwicklungsprozesses; das Design kann und sollte aber auch durch einige andere Faktoren beeinflusst werden:

• Einige Aspekte im Design sind aus technischer Sicht vielleicht nicht realisierbar.
• Ein besseres Design, das bisher nicht umzusetzen war, kann dank technologischer Verbesserungen plötzlich doch realisiert werden.
• Das Designkonzept kann sich ändern.
• Softwareanbieter und Kunde haben eine unterschiedliche Meinung darüber, wie das Produkt aussehen soll.
• Bei den Usability Tests werden Designfehler entdeckt, die behoben werden müssen.

Diese Liste beinhaltet nur einige der zahlreichen Gründe, die eine Iteration (also eine "Wiederholungsrunde") im Designprozess erforderlich machen können: Die Teammitglieder gehen einen Schritt im Entwicklungsprozess zurück und fangen an dem Punkt wieder neu an, an dem eine problematische Entscheidung getroffen wurde.

Würde man ein Bild der möglichen Iterationen in diesem Prozess zeichnen, stünde man vor einem Bild, das einer Endlosschleife ähnelt. Selbstverständlich sind Endlosschleifen aber unerwünscht. Denn wie bei jedem anderen Projekt, werden auch bei einem nach UI-First-Prinzipien geführten Projekt ein Start- und ein Endtermin festgelegt. Nichtsdestotrotz müssen die Iterationen bei der Planung aber berücksichtigt werden, denn sie sind für die Qualität der Projektergebnisse sehr wichtig.

 

Schwarz auf weiß dokumentiert

Benutzer beobachten und befragen, Anwendungsinhalte sammeln, Benutzerszenarien und die Interaktion zwischen Benutzer und Schnittstelle beschreiben – wird der UI-First-Prozess vorschriftsmäßig befolgt, gibt es eine Fülle an Informationen zu erfassen. Um dem Verlust wertvoller Informationen vorzubeugen, bietet UI First für viele der vierzehn Prozessschritte Arbeitsvorlagen an. Durch sie wird die Datensammlung standardisiert, damit die Ergebnisse problemlos mit anderen Projektteams ausgetauscht und verglichen werden können. Dabei ist die Verwendung der meisten Vorlagen nicht obligatorisch, sondern soll den Teams lediglich helfen, ihre Ergebnisse effizient festzuhalten.

Die Zahl der zu erreichenden Arbeitsergebnisse des UI-First-Prozesses wurde auf drei reduziert. Sie unterstützen den Innovationszyklus der SAP:

1. Prototypen der Benutzungsoberflächen, die von realen Anwendern getestet wurden
2. Eine Rollenspezifikation mit Details zum Benutzertyp und einer Beschreibung der Anwendungen, die entwickelt werden sollen
3. Spezifikationen der Benutzungsoberflächen, die das Verhalten und die technischen Details der Oberflächen beschreiben, die im Laufe des Prozesses entwickelt wurden

 

Der Lebenszyklus der Innovation

Die Produktentwicklung bei SAP beruht auf einem ganzheitlichen Prozessmodell namens Product Innovation Lifecycle (PIL). PIL gliedert den gesamten Lebenszyklus eines Produkts, von der Idee über die Weiterentwicklung bis zur Versionierung, in mehrere Phasen: Invent (erfinden), Define (definieren), Develop (entwickeln), Deploy (einführen) und Optimize (verbessern). In der Invent-Phase werden die Ideen aus der Sicht des Marktes betrachtet und kategorisiert. Die so ermittelten Anforderungen werden in der Define-Phase in Entwicklungsmaßnahmen und in der anschließenden Develop-Phase in Entwicklungsprojekte umgesetzt. Daraufhin werden die Produkte in den Markt eingeführt und kontinuierlich weiterentwickelt und verbessert, wodurch letztendlich neue Versionen und Produkte entstehen.

UI First stellt hier den Teilprozess für die Entwicklung der Benutzungsoberflächen dar und ist eng mit dem oben beschriebenen Innovationszyklus verwoben. Wie bereits erwähnt, stellen die Rollenspezifikationen und die Spezifikationen der Benutzungsoberflächen die abschließenden Arbeitsergebnisse des Prozesses dar. Diese Dokumente dienen als Grundlage für die Softwarespezifikation – eines der wichtigsten Dokumente, das in der Define-Phase des SAP Product Innovation Lifecycle verfasst wird.

 

Fazit

Die Idee, die Anwender in den Mittelpunkt des Designprozesses zu rücken, ist nicht neu. Donald A. Norman, "der Vater des anwenderorientierten Designs", gab bereits 1986 einen Band zu diesem Thema heraus. Doch Softwareunternehmen scheinen sich mit der Umsetzung dieser Idee immer noch Zeit zu lassen. Ein Grund dafür liegt vielleicht darin, dass ein Ansatz wie UI First durchaus Schwierigkeiten in der praktischen Umsetzung mit sich bringt. Hier gilt es nämlich unter anderem, die folgenden Hürden zu überwinden:

• Es muss eine neue Form der Zusammenarbeit zwischen Entwicklung und Produktmanagement entstehen.
• Das Sammeln der Benutzerdaten und die umfassenden Tests zur Benutzungsfreundlichkeit sind kostenintensiver als die klassische Entwicklung, bei der hauptsächlich die Funktionalität zählt.
• Zu Beginn eines Entwicklungsprojekts wird vergleichsweise viel Zeit darauf verwandt, Designkonzepte zu entwickeln. Der herkömmliche Ansatz, früh mit dem Kodieren zu beginnen, erzeugt schneller erste Ergebnisse.

Diese Hürden sind nicht unüberwindbar. Benutzungsoberflächen, durch die sich die Produktivität der Anwender – und damit der Nutzen für unsere Kunden – nachhaltig erhöht, können aber nur entstehen, wenn der Anwender von Anfang an im Mittelpunkt steht.

 

Literatur

[1] Karen Holtzblatt, Hugh Beyer: Contextual Design: Defining Customer-Centered Systems, 1997

 

top