Vereinfachung von Komplexität

Visual Application Design – bessere UX durch gezielte Projektkonzeption
Kommentare

Eine der größten Herausforderungen in klassischen IT- und Softwareprojekten sind die Kommunikation zwischen allen Beteiligten und das einheitliche Verständnis der einzelnen Schritte und Ergebnistypen. Nicht jeder hat die gleiche Erwartungshaltung an Ergebnis, Vorgehensweise und Umsetzung. Zudem gehen die Bilder vom Ergebnis in den Köpfen der Beteiligten meist extrem auseinander. Hier wurden schon etliche Methoden entwickelt und Verfahren eingeführt, um dieses Problem in den Griff zu bekommen. Oft gehen zudem unzählige Stunden an Abstimmungsmeetings ins Land, bis am Ende etwas entsteht, das man sich am Anfang ein bisschen anders vorgestellt hatte.

Vor allem im Bereich der Web- oder Anwendungsoberflächen hat jeder der Beteiligten nach dem ersten Briefing meist schon ein grobes Bild seiner Erwartungen im Kopf. Da spielen eigene Präferenzen, moderne User Interfaces und nicht zuletzt auch das Interesse daran, seine Erwartungen an das Projekt priorisiert wiederzufinden, eine tragende Rolle. Es besteht somit ein Risiko, dass das Ergebnis nicht den verschiedensten Erwartungen entspricht. Der Weg der klassischen Web- und Softwareentwicklung birgt genau diese Risiken, da ein greifbares Ergebnis erst nach längerer Entwicklungszeit vorliegt. Auch wenn im Vorfeld Mengen an Anforderungen, Spezifikationen, Agreements, technischen Vorgaben etc. heruntergeschrieben wurden, liest doch jeder etwas anderes daraus.

Im Zuge der aktuellen „Agilisierung“ von fast jedem Businessprozess hat sich auch im Bereich des Oberflächendesigns etwas getan. Bei der Vorgehensweise des „Visual Application Design“ werden nach den ersten schriftlichen Anforderungen und Spezifikationen des Projektrahmens direkt ein Wireframe oder auch nur Mockups entwickelt, die sofort ein klares Bild des zu erwartenden Projektergebnisses zeigen. Auch wenn hier noch keine echten Funktionalitäten und auch kein Corporate Design einfließen, hat man doch relativ schnell eine Diskussionsgrundlage für alle Beteiligten geschaffen – jeder weiß nun, wovon die Rede ist. Agieren klassische Digital- und Werbeagenturen schon länger mit dieser Methode, ist sie doch nicht so oft (auch wenn bewährt) in der klassischen IT-Entwicklung im Einsatz.

Der Mockup oder Wireframe übersetzt in diesem Stadium alle technischen, fachlichen, vertrieblichen und marketingtechnischen Anforderungen in eine bildhafte Darstellung, die jeder sofort begreift und die ein einheitliches Verständnis schafft.

Abbau von Barrieren und Ängsten

Das Zusammenspiel der verschiedenen Stakeholder bei der Applikationsentwicklung gestaltete sich schon immer schwierig. Wollen die Technologen, damit es schnell läuft, eine einfache, aber effiziente Technologie nutzen, die sich möglichst perfekt in die bisherige IT-Landschaft integriert, wünscht sich der Vertrieb ein schnelles und effizientes Zugreifen auf die gewünschten Applikationen. Das Marketing möchte, dass die Anwendung auf allen Endgeräten verfügbar ist, das Corporate Design widerspiegelt und möglichst viele Kommunikationsmöglichkeiten integriert. Letztlich wünschen sich aber alle eine schlanke, übersichtliche und nutzerfreundliche Oberfläche, die intuitiv bedienbar und modern ist. Dabei hat auch jede Abteilung ihre fachlichen Begriffe, die in den Abstimmungsmeetings fallen, die aber nicht jeder versteht. Technik und Entwicklung können sich unter „Flat Design“ oder „Call-to-Action-Bereichen“ so wenig vorstellen, wie Marketing, Management oder Vertrieb oft unter „Framework“ oder „SmartClient“.

Die Vorgehensweise des Visual Application Design setzt genau darauf auf. Man zieht das Ergebnis einfach in nichtfunktionaler und abgespeckter Form vor, damit sich jeder wiederfindet und sofort im Kopf mit seiner Expertise die für ihn relevanten Informationen aus dem schemenhaft abgebildeten Ergebnis ziehen kann. Man bildet also eine Brücke zwischen den Anforderungen der einzelnen Stakeholder und dem zu erwartenden Ergebnis. So kann jeder für sich sehen, ob seine Erwartungen und Anforderungen erfüllt werden.

Vereinfachung von Komplexität

Bilder können komplexe Strukturen und Mechaniken in einem kleinen simplen Objekt vereinen. Aktionen, die davon abgeleitet werden, setzen sich aus Bekanntem und Erlerntem zusammen. So versteht jeder, was zu tun ist, wenn er ein Symbol mit einem „X“ findet – er kann einen Vorgang abbrechen. Oder der Architekt, der zur Verdeutlichung seines Hauskonzepts einen Grundriss des Projekts aufzeichnet, unter dem sich jeder unmittelbar etwas vorstellen kann. Wände, Türen, Fenster, Treppen, sogar Steckdosen sind ikonisiert dargestellt und verhelfen allen Beteiligten sofort zu einem Bild im Kopf, bei dem jeder mit seiner Expertise (Bauherr, Schreiner, Elektriker etc.) auch sein Konzept von dem Haus ableiten kann. Es ergeben sich direkt Aufgaben, Strukturen und Workflows im Kopf. Warum machen wir es dann bei Softwareprojekten zum Teil anders?

Fachspezifikationen, egal von welcher Abteilung ausgearbeitet, sind meist sehr komplex und bilden im Hintergrund Abhängigkeiten ab, die zum Beispiel ein lineares Dokument oft schlecht darstellen kann. In einem linearen Dokument muss der Betrachter bzw. Leser gedanklich sehr springen. Vor allem bei Korrekturen an irgendeiner Stelle verliert man entsprechend schnell den Überblick.

Beim Visual Application Design wird nach den ersten Anforderungen schon mit realen Bildern und Masken gearbeitet. Sie zeigen relativ schnell, ob das, was der Entwickler sich ausgedacht hat, auch funktioniert. Man setzt also schnell die Brille des Kunden oder Nutzers auf – was einen meist nachgelagerten Usability-Test schon im frühen Stadium einbezieht. Viele komplexe Abläufe, die in Fachspezifikationen meist über viele Seiten hinweg beschrieben werden, lassen sich dadurch in ein paar einfachen Masken visualisieren. Ein Beispiel ist der Upload von Daten. Hier reicht im Grunde ein einziger Button, der den Uploadprozess startet. Auch bei den klassischen Icons haben sich allgemeingültige Zeichen bewährt, die jedem sofort klar machen, was sich hinter dem Button verbirgt. Taucht das Symbol im Wireframe oder Mockup auf, übersetzt es jeder Stakeholder für seinen Aufgabenbereich und hat sogleich eine Vorstellung davon, was dort genau passiert.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Nutzerfreundlichkeit von Anfang an

Eine gute Frage, die immer wieder zu Diskussionen führt, ist: Wann zieht die Nutzerfreundlichkeit in das Projekt ein? Und wo setzt man damit in der Projektplanung an?

Es gibt kaum noch ein digitales Projekt, das nicht mit klassifizierten und zielgerichteten Anforderungen an die Barrierefreiheit und Nutzerfreundlichkeit beginnt. Die Vorgaben sind meist schon in der Präambel jedes Projekts verankert und stellen eine ganz klare Erfolgserwartung an das fertiggestellte Projekt. Also spielt dieser Faktor – in den Augen der Kunden – eine extrem wichtige Rolle bei der erfolgreichen Entwicklung einer Anwendung oder Webseite. Letztendlich sind es die Nutzer, die das Produkt gern nutzen oder ablehnen und somit auch den damit verbundenen Geschäftsprozess erfolgreich machen oder nicht. Usability oder Nutzerfreundlichkeit sind extrem wichtige Faktoren, die direkten Einfluss auf Arbeitsprozesse, Geschwindigkeiten von Abläufen und Verkaufszahlen haben. Hier liefert die Anwendungsoberfläche als primäre Schnittstelle zwischen Mensch und Maschine das größte Einflusspotenzial.

Der Teufel steckt bei der Konzeption in nahezu jedem Detail, denn jedes Element beeinflusst das spätere Nutzererlebnis:

  • Die Wahl des Ausgabemediums und Ausgabekanals (Desktop, Tablet, Mobile, Terminal etc.)
  • Die zugrunde liegende Technologie
  • Alle abgebildeten Prozesse
  • Die Informationsdichte
  • Das bereits vorhandene Corporate Design
  • Strukturen, Abhängigkeiten, Altsysteme und deren Verknüpfungen
  • Und so weiter …

Die Oberfläche ist dann nur noch ein kleiner Teil, der das Nutzererlebnis positiv beeinflussen kann. Nehmen wir an, dass es circa zehn verschiedene Faktoren sind, die das Nutzererlebnis stark beeinflussen, dann würde die Oberfläche hier eigentlich auch mindestens zehn Prozent ausmachen. Trotzdem ist die Nutzeroberfläche als Schnittstelle zwischen Mensch und Maschine mit Sicherheit auch die prägnanteste und besitzt daher auch eine besonders hohe Priorität. Sie müsste also eigentlich viel mehr Aufmerksamkeit in der Entwicklung bekommen, schließlich ist die Oberfläche das Element, das die Nutzer als Erstes vom neuen Projekt sehen. Daher ist es naheliegend, die klassische Vorgehensweise bei der Entwicklung nach dem „Wasserfallmodell“ zu überdenken und ergonomische Software als ganzheitliche Entwicklung zu betrachten. Da das aber bisher nicht funktioniert, nähert man sich am besten mit einer agilen Methode, die immer wieder Prototypen entwickelt, sie testet beziehungsweise überprüft, dann verbessert und anpasst. So entsteht nach und nach eine ganzheitliche Software, die sich von Anfang an visuell entwickeln lässt.

Abb. 1: Das Softwaremodell nach Jesse James Garrett

Abb. 1: Das Softwaremodell nach Jesse James Garrett

Das in Abbildung 1 gezeigte Softwaremodell von Jesse James Garrett sollte eigentlich nur die verschiedenen Ebenen der Software beschreiben und ist in dieser Form auch noch aktuell. Leider werden aber immer noch viele Projekte nach genau diesem Modell entwickelt, was natürlich nicht Sinn und Zweck dieses Modells war. Hier wird ein klassisches Wasserfallmodell beschrieben, bei dem sich die Oberfläche beziehungsweise das Oberflächendesign nur noch über den Content legt, aber keine echte Funktion besitzt. Genau so wird oft erst entwickelt und dann eine Oberfläche über die Anwendung gelegt, die aber im gleichen Zug alle Prozesse extrem nutzerfreundlich und übersichtlich gestalten soll. Das funktioniert leider nur in den wenigsten Fällen. Denn sind die Prozesse und Masken im Vorfeld schlecht konzipiert, kann die Oberfläche keine Gestaltung in Richtung Nutzerfreundlichkeit, Barrierearmut und positivem Nutzererlebnis mehr vornehmen.

What you see is what you get

Das Prinzip „WYSIWYG“ kennt jeder. Zudem ist es seit Jahren ein Renner im Public-Software-Sektor. Gerade wenn extrem heterogene Nutzergruppen mit der Software arbeiten sollen, hat sich diese Arbeitsmethode als sehr erfolgreich herausgestellt. Visual Application Design ist also so etwas wie WYSIWYG in der Softwareentwicklung. Man zeigt bereits früh im Projekt Strukturen und Oberflächen, um sie direkt im Kopf durchzuspielen und sie vor allem auch zu bewerten. Unser Gehirn funktioniert nun einmal am erfolgreichsten und zuverlässigsten, wenn es sich gleichzeitig aller Sinne bedienen kann. Dabei helfen visuelle Elemente sehr, um sich ein Projekt vorstellen zu können.

Eine weitere einfache Hilfe neben dem klassischen WYSIWYG-Editoren-Prinzip sind so genannte „Bootstrap Themes“ oder Sammlungen, die bereits vorgefertigte (und meist auch moderne, mobil affine) Interaktionspatterns als Set mitbringen. Aus dieser Sammlung kann sich jeder Entwickler nach Herzenslust bedienen, auch wenn es dadurch erst einmal keine Garantie für eine positive Nutzerfreundlichkeit gibt. Es hilft aber, aus dem Stand einen ersten, interaktiven Prototyp in HTML zu entwickeln.

Nicht nur Look, sondern auch Feel

Auch wenn man bei digitalen Oberflächen nicht wirklich von Haptik sprechen kann, spielt sie doch eine absolut wichtige Rolle. Das Gehirn komplettiert viele flache Designs mit uns bekannten Elementen aus dem Alltag. Das ist auch der Grund, warum das bekannte Apple-Design mit seinen Reglern und Schaltern (teilweise sogar noch mit simuliertem Schatten) so einen durchschlagenden Erfolg hatte. Es kommt unserem klassischen Begriff der Bedienung am nächsten.

Aber auch das Feedback einer Oberfläche bei der Eingabe oder bei Veränderung spielt eine wichtige Rolle. Was passiert, wenn man etwas auswählt? Sieht man schon alle Optionen oder schalten sie sich eingabebezogen frei? Sieht man dann noch die nicht ausgewählten Optionen? Kann man eine Auswahl einfach rückgängig machen? Wie eindeutig wird man auf Fehler hingewiesen? Welches Feedback bekommt man auf eine falsche Auswahl oder wie reagieren Interaktionselemente auf einen Klick? Das alles sind Dinge, die die Haptik beziehungsweise das „Feeling“ der Oberfläche ausmachen.

Neuere Wireframing- und Prototyping-Software wie zum Beispiel Axure RP kommen mit ihren interaktiven Elementen und dynamischen Feldern schon sehr nah an die Haptik der zukünftigen Bedienung der zu erstellenden Oberfläche. Mit solchen Programmen lassen sich schnell gesamte Prozesse und Abläufe auf modernen Webportalen simulieren und grob die ersten Fehler und Missverständnisse erkennen und ausmerzen, ohne großen Programmieraufwand. Zudem bieten die meisten dieser Programme auch einen passwortgeschützten Bereich im Web an, in dem sich eine HTML-Version veröffentlichen lässt. So kann jeder der Beteiligten seine eigene Erfahrung mit dem letzten Stand des Prototyps machen und Feedback geben.

Verortung im agilen Prozess

Hält die Oberfläche als Entwicklungstool relativ früh Einzug in den Projektablauf, dann hat sie auch einen festen Platz in der agilen Projektplanung. Für die spätere Entwicklung lassen sich von ihr wertvolle Erkenntnisse ableiten. Basis für die ersten Mockups, Wireframes:

  • Zieldefinition: Was soll mit dem Projekt erreicht werden?
  • Technische Basis: Auf welcher Plattform, welcher Basis, welchem Endgerät, welcher Technologie soll das Projekt umgesetzt werden?
  • Basisanforderungen: Was soll in dem Projekt passieren, was soll integriert werden, was sind die Kernprozesse etc.?
  • Danach wird der gleiche Prozess immer wieder bis zur vollständigen Darstellung beziehungsweise Abnahme der Wireframes wiederholt
  • Entwicklung von Mockups und/oder Wireframes
  • Akzeptanztests in der internen Gruppe
  • Einarbeitung der Änderungen in die Mockups bzw. Wireframes
  • Ableitung der Spezifikationen anhand des Designs

Bei der Ableitung in die verschiedenen Expertisen sind dann wieder die Experten aus den Fachbereichen gefragt. So integriert sich die Oberfläche als Element schon früh in den agilen Prozess und kann Überlegungen visualisieren, erste Usertests ermöglichen, Varianten aufzeigen, Spezifikationen und Prozesse greifbar machen und schon vor der Entwicklung eine solide Basis für den Erfolg des Projekts schaffen. Grundlage hierfür ist der Ansatz des „User-Centered Designs“ (Abb. 2), der an sich schon eine iterative Methode ist, die sich gut in agile Vorgehensmodelle integrieren lässt. Anhand dieses UCD-Modells lassen sich komplexe und umfangreiche Oberflächenkonzepte unter Zuhilfenahme von Nutzerfeedback entwickeln.

Abb. 2: User-Centered-Design-Modell

Abb. 2: User-Centered-Design-Modell

Vorgehensweise Visual Application Design

Grundsätzlich gibt es keine strenge Vorgabe für die richtige Vorgehensweise beim Visual Application Design, doch es gibt ein paar Rahmenbedingungen, die einen unterstützen. Hier ein paar Leitsätze, die helfen, Softwareprojekte schneller, effektiver, nutzerfreundlicher und verständlicher für alle Beteiligten zu gestalten:

  • Holen Sie zu Beginn jedes Projekts alle Vertreter der beteiligten Abteilungen/Unternehmensbereiche an einen Tisch und definieren Sie die wichtigsten Ziele gemeinsam. Alle Expertisen sollen sich direkt zu Beginn einbringen können – so wird niemand übergangen.
  • Definieren Sie den Hauptprozess ihres Projekts. Was soll er abbilden und wie soll er umgesetzt werden?
  • Schreiben Sie gemeinschaftliche und wichtige Ziele, die das Softwareprojekt erreichen will, in einem gemeinsamen Dokument auf. Das bietet vor allem dem Usability Engineer oder Designer wichtige Hinweise für die Umsetzung.
  • Entwickeln Sie einen ersten Prototyp um den Hauptprozess herum, mit den Bedingungen, die bis dahin bekannt sind (muss nicht interaktiv sein). Ausnahmen, Sonderregelungen und Nebenprozesse verkomplizieren das Gesamtprojekt in der Entwicklung, halten vor allem am Anfang sehr auf und sollten zurückgestellt werden. Sind die Bedingungen schon bekannt, die den Hauptprozess erheblich beeinflussen können, dann sollte man sie, soweit es geht, schon integrieren.
  • Hat man neben der Startseite ein bis zwei weitere Templates gestaltet, sollte dieser Status bereits in die Abstimmung gehen. Es gilt: Je eher, desto besser. Nach der ersten Korrekturrunde hat man somit eine erste Grundlage, das erste Bild im Kopf, an dem sich nun alle orientieren können. Alle wissen, wovon die Rede ist, was möglich sein wird und was auf die Beteiligten zukommt.
  • Meist ist es für den Prototypenstatus exemplarisch ausreichend, die verschiedenen Templates einmalig grob als Wireframes anzulegen. So haben die Entwickler, zusammen mit den Designvorgaben, genug Informationen, um die Fachspezifikationen umsetzen zu können.
  • Wichtig ist, dass auch die Prototypphase effizient gestaltet wird. Es muss nicht jeder einzelne Screen gestaltet werden, meist sind die Startseite bzw. eine Übersichtsseite sowie exemplarisch aus jedem Bereich eine Seite ausreichend. Sonst würde sich der positive Effekt des „schnellen“ Prototypings in hohen Aufwänden auflösen.

Neben den beschriebenen Effekten gibt es auch noch kleinere Nebeneffekte, die sich in der Vergangenheit ebenfalls als sehr positiv herausgestellt haben:

  • Die beteiligten Abteilungen sitzen von Anfang an einem Tisch – jeder ist über den aktuellen Stand informiert und fühlt sich eingebunden.
  • Die Oberflächen werden während der Entwicklung immer wieder optimiert – es gibt viel weniger Korrekturphasen nach der Implementierung.
  • Das Projekt bekommt direkt ein Gesicht und wird greifbarer.

Diese Methode hat sich vor allem bei Applikationen und mobilen Anwendungen bewährt. Dort sind Design beziehungsweise Oberfläche die am stärksten limitierenden Faktoren und in hohem Maße für Erfolg oder Misserfolg der Anwendung verantwortlich. Gerade die starke Verbreitung mobiler Anwendungen wird immer mehr Druck auf die Oberflächenentwicklung ausüben, sodass sich hier auch die Methoden in der Entwicklung über kurz oder lang anpassen müssen.

Anwender erwarten einfach, dass Oberflächen nutzerfreundlich entwickelt werden. Somit ist es notwendig, die Nutzerschnittstellen möglichst früh in der Entwicklung zu berücksichtigen.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -