Visual Transparency - das Resultat

Visual Transparency begreift den klassischen Lead-to-Cash Prozess als zusammenhängendes Interface, das sich von Listen, Kacheln und Tabellen der Fiori-Designsprache unterscheidet, indem es über grafisch-skeuomorphe Metaphern Zusammenhänge dar- und klarstellt. Die Beziehungen zwischen den einzelnen Business Objekten werden sichtbar gemacht und ermöglichen greifbare Übersichtlichkeit, fluides Arbeiten mithilfe von Drag and Drop der Tickets und formulieren unmittelbaren Handlungsbedarf durch Einsatz von Farbe.

Themen wie Automatisierung oder Skalierung wurden nicht berücksichtigt.

(Übersicht der Tickets, Wechsel von der Rolle „Sachbearbeiter“ zu „Lagerarbeiter“, zusätzliche visuelle Kennzeichnung der Rolle in der Menüleiste)

Ähnlich wie in einem Kanban-Board werden die Business Objekte je nach funktioneller Einteilung im Lead-to-Cash Prozess (Angebot, Bestellung, Lieferung oder Rechnung) in ihrer jeweiligen Spalte eingereiht. Jede Kategorie bietet durch Filter Chips die Möglichkeit zur Sortierung und Neuanordnung je nach Zustand der enthaltenen Tickets: „Hohe Priorität“ steht für dringenden Handlungsbedarf und eine Problematik, „Neu“ beschreibt alle hinzugekommenen Tickets nach einem gewissen Zeitpunkt und „Neutral“ fasst alle weiteren Objekte ein. Über die oben angebundene Suchleiste können einzelne Tickets oder relevante Informationen gefunden werden.

Jedes Ticket, bzw. Business Objekt, wird in seiner Form klar hervorgehoben, um es zu denen anderer Spalten unterscheidbar zu machen. Ein Angebot etwa besitzt Abrisskanten im unteren Bereich, wohingegen ein Ticket im Bereich der Lieferung durch eine Briefmarke ausgezeichnet wird. Kleine skeuomorphe Metaphern sollen Funktionalität und Individualität innerhalb der Gruppe klar hervorheben. Zudem bietet der spielerische, aber dennoch zurückhaltende Charakter der eingesetzten Skeuomorphismen eine Abwechslung zur schlichten Kachelung und Anreihung rechteckiger Boxen.

Innerhalb der Tickets werden die relevantesten Informationen „auf einen Blick“ gekennzeichnet (bspw. bei Bestellungen der Bestellwert) und Blockaden über eine farbige Codierung hervorgehoben. Da nicht jeder Nutzer in einem Betrieb die Bearbeitungsrechte für jede Kategorie besitzt, sind bestimmte Bereiche nicht zugänglich, was durch ein Ausgrauen der entsprechenden Spalte kommuniziert wird und durch eine zusätzliche Animation, die zum Anfragen von Bearbeitungsrechten auffordert. Dennoch ist auch ein Sachbearbeiter im fiktiven Beispiel imstande, die Tickets im Bereich der Lieferungen zu sehen, die den eigenen Arbeitsbereich nicht tangieren. Zwar können keine Bearbeitungen vorgenommen werden, doch der Prozess bleibt transparent und eine Bestellung, die zur Lieferung wird, verschwindet nicht im luftleeren Raum unauffindbar für den Nutzer.

(Drag-and-Drop-Umwandlung eines Angebots in eine Bestellung)

Ziel ist es, das Angebot eines Kunden durch den Prozess zu bewegen und schlussendlich im Bereich der Rechnungen anzukommen, da dies auch für den realen Kauf und Kaufabschluss stellvertretend ist. Ein Ticket beginnt demnach im Bereich der Angebote und wird bis zur Rechnungen-Kategorie begleitet. Sofern es feststeckt durch ein Problem oder irgendwelche Sonderschritte nötig werden, kommt es zur farblichen Hervorhebung dieser Umstände. Wenn keinerlei Zusatzhandlungen erforderlich sind, kann das Ticket über Drag and Drop verschoben- und umgewandelt werden. Im obenstehenden Beispiel passiert dies mit einem Kundenangebot, welches angenommen- und in eine Bestellung transformiert wird. Hierdurch kann unmittelbar in den Prozess eingegriffen werden durch Schieben und Bewegen der Business Objekte. Dabei verschwindet ein verändertes Ticket nicht aus dem Sichtbereich und muss andernorts gesucht werden wie in einer klassischen Kacheldarstellung, sondern wechselt lediglich die Spalte angereichert mit veränderten Informationen.

(Detailansicht mit zusätzlichen Funktionen je nach Kategorie, Druckvorschau einer Rechnungs-PDF, Aufrufen eines Kundenblattes)

Sofern weitere Einzelschritte vonnöten sind, um mit einem Business Objekt zu interagieren, kann per Klick auf das entsprechende Ticket eine Detailansicht geöffnet werden. Diese befähigt den Nutzer zu weiteren Aktionen, erlaubt das Verändern des Objekts selbst und gibt Auskunft über relevante Informationen. Je nach Kategorie, in der das Ticket liegt, verändert sich auch die Detailansicht, da unterschiedliche Daten für verschiedene Zustände der Business Objekte vonnöten sind (bspw. eine Möglichkeit zum Drucken und Abrufen einer Rechnungs-PDF für ein Ticket im Bereich Rechnungen).

(visuelle Verlaufsdarstellung von Veränderung und Bewegung von Business Objekten über den Verlauf-Button)

Um Verschiebungen der Business Objekte oder Veränderungen ihrer Zustände besser verfolgen zu können, kann über einen Klick auf den Verlauf-Button eine historyartige Übersicht geöffnet werden. Darin lassen sich alle Änderungen anzeigen- und gesonderte Informationen ausklappen (bspw. ob- und wer für welche Veränderung verantwortlich war). Mit einem Klick auf die Benachrichtigung, kann der Nutzer die Detailansicht des Tickets aufrufen, wohingegen das Hovern über einer Notiz eine visuelle Darstellung des Verlaufs erzeugt. Hierbei kann nachvollzogen werden, in welchem Zustand- und an welcher Stelle sich ein Ticket befand, bevor es umgewandelt oder bearbeitet wurde. 

Der Nutzer soll darin bestärkt werden, stets das Gefühl von Übersicht und Wirksamkeit zu erlangen. Kein Prozess oder eine Veränderung soll „im Geheimen“ vorbeischleichen oder später nicht mehr nachvollzogen werden können. Die Beziehungen der Objekte zueinander und zu ihrer Position sind dauerhaft abrufbar und umgänglich kommuniziert.

Der Prozess

Da SAP-Systeme mit einem enorm hohen Grad an Komplexität funktionieren, war das Entwickeln eines potenten Konzepts in dem Maße schwierig, dass genaue Detailfunktionen nicht nachvollzogen werden konnten ohne beträchtlich viel Zeit auf Research zu verwenden. Die Entscheidung, eine grafisch-orientierte Lösung mit neuer Detailsprache und hilfreichen Metaphern zu finden ohne einen der hochkomplexen Workflows zu durchsteigen- und nachzuarbeiten mit seinen vielen „Wenn“s und „Aber“s, erschien wie ein vielversprechender Weg. In Zusammenarbeit mit einem UX-Kurs und dem stetigen Feedback im Kursformat durch Studierende und SAP-Mitarbeiter konnte „Visual Transparency“ immer weiter vorangetrieben und realisiert werden.

(Wireframe-Prototyp, Lösung über zwei Viewports)

In der ersten Findungsphase des Projekts wurde eine Zwei-Viewport-Lösung angestrebt. Über einen horizontal- sowie vertikal frei scrollbaren Raum sollten Business Objekte als 3D-Gegenstände begriffen- und Detailinformationen abgerufen werden können. Ähnlich wie in der finalen Version von „Visual Transparency“ konnte auch hier über Drag and Drop gearbeitet werden. Nach einem weiteren Feedbackloop wurde die vertikale Achse und der spielerisch aufgeblähte „3D-artige Raum“ aufgelöst. Doch der neue Lösungsansatz stellte sich als ungewöhnliches UX-Muster heraus, da die Kategorien je nach Klick auf die Spalte in den Vordergrund wechselten. Es entstand das Gefühl eines erheblichen Informationssprunges, welcher der Designphilosophie von Transparenz und Sichtbarkeit widersprach.

(Kanban-Board-Optik, Skeuomorphismen im Überfluss)

Die Idee, sich an bestehenden UX-Pattern wie beispielsweise Trello, zu orientieren, um eine Kanban-Board-artige Optik zu erreichen, entstand im Kurs. Die starre Trennung zweier Viewports in Listen und Objekten wurde zugunsten der kategorischen Spalteneinteilung aufgehoben. Im ersten Entwurf waren alle Elemente hierbei in ihrer Form gleichaussehend und wesentlich auffälliger farblich codiert. Dies stellte sich als noisy und ablenkend heraus, trotz des zurückhaltenden Weiß- und Grautons als neutraler Ausgleich. Auch die Informationen erschienen mitunter redundant und nicht auf das Wesentliche reduziert.

„Visual Transparency“ fehlte es zu diesem Zeitpunkt noch an Identität, Charakter und Detailtypografie. Auf den Vorschlag hin, sich skeuomorphen Metaphern anzunähern, entstanden zwei Designs. Einerseits die beinahe finale Version der Abgabe mit dezentem Einsatz von Skeuomorphismen und andererseits eine spielerische Auseinandersetzung mit charakterstarken und farbintensiven Bildern, die sich wesentlich kräftiger in die Thematik der Skeuomorphismen lehnt. Schlussendlich wurde sich für das corporate-tauglichere Design entschieden, doch das Entwickeln eines ungewöhnlichen Designs, welches dem klassischen flachen, minimalistischen Trend entkommt, war wichtig und sinnvoll, um aufzuzeigen, dass ein Interface nicht immer den aktuellen Modebewegungen folgen muss. Besonders dann nicht, wenn es sich um SAP-Software handelt, die von manchen Nutzern noch in ihren jüngsten Versionen verwendet- und bei der teils sogar auf Upgrades verzichtet wird.

Video