UI UX Best Practices

UI/UX Best Practices – Worauf es bei der Umsetzung ankommt

UI/UX steht für User Interface und User Experience und ist eine der Kernkompetenzen bei XITASO. UI/UX sorgt für eine einfache Bedienbarkeit der Software und somit für zufriedene Anwender und ein erfolgreiches Unternehmen.

In diesem Beitrag zeigt unser UI/UX-Experte Simon Engelmann, welche Herausforderungen in vielen Projekten bestehen und welche UI/UX Best Practices sich dafür bei XITASO bewährt haben.

Übersicht

1. Weniger ist mehr
Nur weil eine Software viele Funktionen hat, ist sie nicht gleich eine gute Software.

2. Je einfacher, desto schwieriger
Was am Ende kinderleicht aussieht, kann harte Arbeit bei der Prozessanalyse sein.

3. Der Nutzungskontext
Es geht um mehr als „Und was würden Sie sich von einer neuen Software wünschen?“

4. Ganzheitliche Betrachtung
Nur wer den Gesamtprozess und seine Abhängigkeiten sieht, kann Software erstellen, die wirklich angenommen wird.

5. Zusammenfassung

1. Weniger ist mehr

Am Anfang eines Projekts besteht oft nicht mehr als eine Idee oder eine Vision. Konkrete Vorstellungen, was für ein Produkt oder Service es genau werden soll, existieren selten. Welche Funktionen werden benötigt? Und welche davon am dringendsten?

Auf Kundenseite entscheidet darüber der Product Owner. Doch in der Regel gibt es viele weitere Stakeholder aus Vorstand und anderen Abteilungen, die bestimmte Funktionen umgesetzt haben wollen und auf die Entscheidungen des Product Owners einwirken. Während der Product Owner versucht, allen Stakeholdern gerecht zu werden, fehlt schnell der Fokus und es entstehen überladene und unschlüssige Oberflächen, die die Anwender*innen nicht mehr verstehen.

Ein großer Funktionsumfang ist prinzipiell nichts schlechtes, doch müssen die Anwender*innen dann unterstützt und geführt werden. So sollten die Anwender*innen pro Seite nur mit einer überschaubaren Anzahl an Funktionen konfrontiert werden und gleichzeitig Hilfestellung erhalten, in welcher Reihenfolge die jeweiligen Funktionen ausgeführt werden müssen.

Der Funktionsumfang kann ruhig groß sein, aber eben gut unterteilt, sodass die Anwender*innen nie das Gefühl haben, überfordert zu sein. Doch bleibt die Frage, welche Funktionen an welcher Stelle angeboten werden sollen. Hierzu ist es wichtig, sich an der Verwendungshäufigkeit der Funktionen zu orientieren. Funktionen, die ständig benötigt werden, dürfen nur einen Klick entfernt sein, vielleicht sogar dauerhaft sichtbar, egal auf welcher Seite man sich in der Software befindet. Für seltener verwendete Funktionen reicht ein weniger prominenter Platz.

Auch wenn eine gute Unterteilung besteht und die Anwender*innen sich trotz vieler Funktionen gut zurecht finden, sollte für jede Funktion kritisch hinterfragt werden:

Hilft diese Funktion den Anwender*innen wirklich bei der Erledigung ihrer Aufgaben?

Kann das nicht eindeutig mit „Ja“ beantwortet werden, muss man sich auch mal trauen, Funktionen wegzulassen. Wenige, sehr gut umgesetzte Funktionen nutzen den Anwender*innen am Ende mehr, als viele halb durchdachte.

2. Je einfacher, desto schwieriger

Weniger anzuzeigen heißt nicht, dass der Funktionsumfang kleiner ausfällt oder die Anwendung weniger komplex ist. Es bedeutet auch nicht weniger Arbeit bei der Erstellung der Anwendung, sondern deutlich mehr.

Neben der Analyse, wie oft welche Funktion benötigt wird, ist es wichtig, die Aufgaben und Prozesse im Detail zu verstehen. Nur so ist es möglich, Optimierungen vorschlagen zu können, die tatsächlich zu einer Vereinfachung führen.

Insgesamt kann man sagen: Je einfacher die Bedienung am Ende sein soll, desto mehr Aufwand muss in das Verständnis der Prozesse gesteckt werden. Je komplexer diese Prozesse sind, desto höher fällt der Aufwand zur Erstellung einer intuitiven Bedienung aus.

Im besten Fall werden die Anwender*innen erst gar nicht mit einer Aufgabe über die Benutzeroberfläche konfrontiert, da die Erledigung neuerdings automatisch im Hintergrund abläuft.

Schwieriges einfach zu machen ist umso zeitintensiver, je komplexer die Prozesse sind.

Schwieriges einfach zu machen ist umso zeitintensiver, je komplexer die Prozesse sind.

3. Der Nutzungskontext

Um überladene Oberflächen und nicht benötige Funktionen zu vermeiden, sollten von Beginn an die Anwender*innen in den Mittelpunkt gestellt und deren Nutzungskontext betrachtet werden.

Der Nutzungskontext umfasst die Anwender*innen, ihre Aufgaben und ihre Umgebung.

Der Nutzungskontext umfasst die Anwender*innen, ihre Aufgaben und ihre Umgebung.

Die Anwender*innen

Hier geht es darum, eine genauere Vorstellung davon zu bekommen, wer die Anwendung am Ende wirklich bedient. Wie viel Vorerfahrung besteht bereits im Umgang mit digitalen Anwendungen? Welche Ziele verfolgt die Person bei der Arbeit?

Haben die Anwender*innen später Schwierigkeiten bei der Erledigung ihrer Aufgaben oder stehen der Anwendung, aus welchen Gründen auch immer, skeptisch gegenüber, wird die neue Software nicht verwendet werden. Die gesamte Arbeit war umsonst.

Die Aufgaben

Die Aufgaben der Anwender*innen sind das Kernelement des Nutzungskontexts. Sie sind der Grund, warum das System und das User Interface überhaupt existieren. Die einzige Daseinsberechtigung einer Software ist die Vereinfachung von wiederkehrenden Aufgaben für die Anwender*innen. Deshalb ist das absolut Wichtigste, die primären Aufgaben herauszuarbeiten und zu bewerten.

Die Aufgaben müssen genau hinterfragt und verstanden werden. Nur so kann bewertet werden, wie wichtig die Aufgabe im Gesamtkontext ist und welche Optimierungsmöglichkeiten bestehen. Es könnte auch sein, dass die Aufgabe im neuen System gar nicht mehr erledigt werden muss.

Zur Bewertung der Aufgaben hilft es, Cluster zu bilden und pro Aufgabe einzustufen, wie häufig diese je nach Gerätetyp auftritt.

Was sind die Hauptaufgaben und wie häufig treten sie auf Smartphone, Tablet und PC auf?

Was sind die Hauptaufgaben und wie häufig treten sie auf Smartphone, Tablet und PC auf?

Die Umgebung

Die Umgebung der Anwender*innen hat große Auswirkung auf die Ausgestaltung der Benutzeroberfläche. Es geht um Fragen wie:

  • Welche Geräte werden verwendet?
  • In welchem Abstand werden diese betrachtet?
  • Werden z.B. Handschuhe getragen? Dies muss bei der Auswahl des Bedienpanels beachtet werden.
  • Zu welcher Zeit wird gearbeitet?
  • Besteht viel Ablenkung durch andere Tätigkeiten oder hohe Lautstärke?
  • Werden andere Anwendungen parallel verwendet?
  • Über welche Fachkenntnisse verfügen die Anwender*innen?
  • Wie viel Zeit zur Erledigung ihrer Aufgaben haben sie?
  • Welche Hilfsmittel stehen zur Verfügung?

Um Kenntnis von diesen Details zu erlangen, ist es wichtig, genügend Zeit in Interviews mit den Anwender*innen zu investieren.

Personas

Personas sind eine Methode, um greifbar zu machen, wer die Anwender*innen der Software konkret sind. Es werden Profile von Anwender*innen erstellt, welche jeweils stellvertretend für eine ganze Nutzergruppe stehen.

Die Profile enthalten die gesammelten Informationen über die Anwender*innen selbst, ihre Aufgaben, ihre Umgebung und ihre Ressourcen. Alle Projektbeteiligten haben ein konkretes Bild, für wen die Anwendung entwickelt wird. Durch eine detaillierte Darstellung mit Bild und Name wird die Person greifbar und bleibt gut in Erinnerung. Mit den erstellten Personas im Hinterkopf können Produktfeatures, Interaktionskonzepte oder Aussehen der Anwendung besser entwickelt werden.

Sogenannte Personas geben konkrete Beispiele wer die Software benutzt.

Sogenannte Personas geben konkrete Beispiele, wer die Software wie benutzt.

Wie wirkt sich der Nutzungskontext auf die Benutzeroberfläche aus?

In einem unserer Projekte wurde bei der Analyse des Nutzungskontextes festgestellt, dass die Software nur eine von vielen ist, die bedient werden musste. Die zu entwickelnde Software sollte sich „nebenher“ bedienen lassen. Am wichtigsten war hierbei die Statusanzeige. Trat ein kritisches Ereignis auf, mussten die Anwender*innen schnell darauf aufmerksam werden. In einer reduzierten Ansicht wurde deshalb vollflächig nur der Systemstatus (rot, gelb, grün) angezeigt. Eine Animation verdeutlichte mit unterschiedlichen Geschwindigkeiten die Dringlichkeit.

Die Software ist nur eine von vielen, die bedient werden muss. Wichtige Statusänderungen müssen deshalb groß und deutlich dargestellt werden.

Die Software ist nur eine von vielen, die bedient werden muss. Wichtige Statusänderungen müssen deshalb groß und deutlich dargestellt werden.

Eine weitere Erkenntnis war, dass die Anwendung auch häufig in dunkler Umgebung verwendet wurde, weshalb neben einer klassischen hellen Variante auch eine dunkle erstellt wurde. Die Augen mussten sich beim Wechsel zwischen Umgebung und Monitor weniger umstellen und ermüdeten weniger schnell.

Dunkle Benutzeoberfläche, um einem Ermüden der Augen in dunkler Umgebung vorzubeugen.

Dunkle Benutzeroberfläche, um einem Ermüden der Augen in dunkler Umgebung vorzubeugen.

4. Ganzheitliche Betrachtung

Für die erste Version der Software wird auf die primären Anwender*innen eingegangen. Bei ihnen ist der Bedarf der neuen Software am höchsten. Dies ist ein sehr wichtiger Schritt, doch sollten auch stets die anderen Gruppen, die gegebenenfalls Berührungspunkte mit dem System haben, bedacht werden.

Von innen nach außen: primäre Anwender*innen, sekundäre Anwender*innen, Interessensvertreter

Von innen nach außen: primäre Anwender*innen, sekundäre Anwender*innen, Stakeholder.

Der Adler auf Beutejagd

Wie kann man nun sicherstellen, dass alle Beteiligten mit ihren Bedürfnissen berücksichtigt werden und so Prozesse ganzheitlich optimiert werden können?

Bei einem unserer Projekte sollte ein Produktkonfigurator entwickelt werden, um die Vertriebsprozesse für Schiffsgetriebe zu beschleunigen.

Um alle Prozessbeteiligten zu berücksichtigen, wurde in der Analyse-Phase zunächst der gesamte Prozess aus der Vogelperspektive betrachtet. So bekommt man einen guten Überblick, wer alles beteiligt und gegebenenfalls mit einbezogen werden muss und welche Prozesse voneinander abhängen.

Prozessübersicht aus der Vogelperspektive: Angefangen bei der Anfrage eines Angebots über die Konfiguration des Schiffsgetriebes und deren Validierung bis hin zu Angebotserstellung, Fertigung und Auslieferung.

Prozessübersicht aus der Vogelperspektive: Angefangen bei der Anfrage eines Angebots über die Konfiguration des Schiffsgetriebes und deren Validierung bis hin zu Angebotserstellung, Fertigung und Auslieferung.

Der Adler im Sinkflug

Nach dem Gesamtüberblick nehmen wir uns einen Prozessschritt genauer vor. In unserem Fall den Prozessschritt „Preselection“, da dieser von den primären Anwender*innen am dringendsten benötigt wurde und Grundlage für die weiteren Schritte war.

Fokussierung auf einen Prozesschritt, der genauer betrachtet werden soll.

Fokussierung auf einen Prozessschritt, der genauer betrachtet werden soll.

Analyse und Optimierung des Ist-Zustands

Der Detail-Prozessschritt „Preselection“ wird in seine einzelnen Arbeitsschritte zerlegt und analysiert. Welche Mitarbeitergruppen sind beteiligt? Welche Dokumente bzw. Ressourcen werden verwendet? Welche Abhängigkeiten bestehen?

Mithilfe dieser Übersicht kann der Ist-Zustand auf Optimierungen überprüft werden. In diesem Fall wurde beispielsweise identifiziert, dass der Prozess über eine Echtzeit-Validierung der Konfiguration deutlich beschleunigt werden kann. Zuvor musste die Konfiguration manuell herausgesucht und anschließend von einer weiteren Stelle bestätigt werden.

Analyse und Optimierung des Ist-Zustands.

Analyse und Optimierung des Ist-Zustands.

Software, die angenommen wird

Durch die ganzheitliche Betrachtung und die breite Einbindung verschiedener Mitarbeitergruppen verschafft man sich nicht nur wertvolles Wissen für die neuen Konzepte, sondern stärkt auch die Bereitschaft der Anwender*innen, die neue Software anzunehmen. Wer eingebunden und mitgewirkt hat, ist viel motivierter, die neue Software dann auch zu benutzen und Feedback zu geben.

Nehmen wir mal Folgendes an: Die Software wurde im kleinen Kreis entwickelt und ist objektiv gesehen perfekt umgesetzt. Alle nötigen Funktionen stehen bereit, alle Usability-Richtlinien sind erfüllt und die Anwendung sieht ansprechend aus. Dass es zu diesem guten Ergebnis kommt, ist zwar unwahrscheinlich, wenn nur wenige Anwender*innen eingebunden wurden, aber nehmen wir es an. Selbst in diesem Szenario wird die Software nicht erfolgreich sein. Bei uns leuchten die Augen, wenn es um die Konzeptionierung einer neuen Software geht. Die Anwender*innen sehen es dagegen kritischer. Und das zu Recht. Sie sind es, die sich umstellen müssen und die Software täglich bedienen werden. Es besteht viel Skepsis. Werden meine Aufgaben in der neuen Version bedacht? Wie werden sie abgebildet? Bestehen meine Aufgaben durch die neuen Prozesse überhaupt noch?

Werde ich als Anwender*in aber frühzeitig eingebunden und kann mich selbst und meine Wünsche einbringen, ist die Software am Ende auch ein kleines Stück von mir und ich verwende sie gerne.

5. Zusammenfassung

 

Weniger ist mehr

Jede Funktion sollte kritisch hinterfragt werden, ob sie den Anwender*innen wirklich hilft, ihre Aufgaben zu erledigen. Ist das zweifelhaft, sollten diese Funktionen bewusst weggelassen werden.

Bei einem großen Funktionsumfang ist eine strukturierte und geführte Aufteilung auf mehrere Seiten sinnvoll. So haben die Anwender*innen nicht das Gefühl, in einem Cockpit mit Hunderten von Knöpfen allein gelassen worden zu sein.

Die Verwendungshäufigkeit gibt vor, welche Funktionen nur einen Klick entfernt sein sollten und für welche Funktionen ein weniger prominenter Platz ausreicht.

Je einfacher, desto schwieriger

Um sinnvolle Optimierungen zur Vereinfachung vorschlagen zu können, müssen die Prozesse im Detail verstanden worden sein. Je einfacher die Bedienung am Ende sein soll, desto mehr Aufwand muss in das Verständnis der Prozesse gesteckt werden. Was am Ende kinderleicht aussieht, war meistens harte Arbeit bei der Prozessanalyse.

Der Nutzungskontext

Der Nutzungskontext betrachtet die Anwender*innen, ihre Aufgaben und ihre Umgebung. In sogenannten Personas können diese Informationen für alle Projektbeteiligten visualisiert werden. Sie erinnern sehr greifbar, wer die Software am Ende bedient.

Die Anwender*innen und deren Nutzungskontext sollten von Beginn an im Mittelpunkt stehen. Nur so kann bedienerfreundliche Software entstehen, die akzeptiert und effektiv eingesetzt wird.

Ganzheitliche Betrachtung

Neben den primären sollten auch die sekundären Anwender*innen sowie die Stakeholder bedacht werden. Dazu hilft es, den Prozess zunächst auf höherer Flugebene zu betrachten, um die Abhängigkeiten zu erkennen.

Anschließend können einzelne Prozessschritte, die besonders dringend benötigt werden, näher analysiert werden. Ausgehend von einer Visualisierung des Ist-Zustandes können dann Optionen zur Optimierung vorgeschlagen werden.

Statt die Software im kleinen Kreis zu entwickeln, sollten möglichst viele Anwender*innen mit eingebunden werden. Wer selbst mitwirkt, macht nicht nur die Software besser, sondern benutzt sie am Ende auch noch gerne.

Autor & Ansprechpartner

Ihr habt Fragen, Ideen oder Feedback zu diesem Thema? Kontaktiert uns gerne!

Simon Engelmann
simon.engelmann@xitaso.com

Simon Engelmann ist seit 2016 bei XITASO und zertifizierter UI/UX-Experte. Als Teil von interdisziplinären Teams begleitet er die Projekte im Sinne des Human Centered Designs. Vom User Research über Klick-Prototypen bis hin zum Testing sorgt er für nachhaltig erfolgreiche und nutzerzentrierte Anwendungen.