Der Weg zum NUI

Natural User Interfaces – Natürliche Bedienbarkeit und der Weg dorthin
Kommentare

Natural User Interfaces (NUIs), also auf „natürliche“ Art und Weise bedienbare Benutzungsoberflächen, haben spätestens seit der Einführung von Smartphones und Tablets ihren Siegeszug angetreten. Häufig werden sie mit Touch- oder Multitouch-Bedienbarkeit gleichgesetzt – im eigentlichen Sinne umfasst NUI jedoch jede Art von natürlicher Bedienung: Bedienung mittels Sprache, Bedienung mittels realer Objekte wie Kleidungsstücke oder Brillen bis hin zur komplett berührungsfreien Interaktionen. Vor allem geht es um ein Nutzungserlebnis, das vom Nutzer unbewusst als „unterstützend“ und „begleitend“ wahrgenommen wird.

In diesem Artikel wird gezeigt, aus welchen Bausteinen sich ein moderner Softwareentwicklungsprozess zusammensetzt, der diese neue Art der Benutzerfreundlichkeit im Endprodukt zum Ziel hat. Anstatt zunächst konkrete Ausprägungen von NUIs zu betrachten, ist es im ersten Schritt sinnvoll, die Philosophie hinter dem Begriff „natürlich“ besser verstehen zu lernen. Ein NUI soll den Nutzer schneller und angenehmer zum Ziel führen, möglichst keine komplexen Denkprozesse oder indirekten Handlungen erfordern, ihm einen möglichst direkten und intuitiven Zugang zu Informationen oder Funktionen ermöglichen und dies, wie es für seinen aktuelle Nutzungskontext angemessen ist [1]. Ein NUI, das vorwiegend mobil in öffentlichen Verkehrsmitteln genutzt wird, muss grundlegend anders gestaltet werden als ein NUI zur stationären Steuerung einer Produktionsanlage. Interessanterweise kann ein und dasselbe User-Interface-Konzept in einem Nutzungskontext unterstützend wirken, während es in einem anderen eher kontraproduktiv ist. Auch wenn es trivial und leicht vermeidbar klingt, wird in der Praxis häufig bereits bei der Wahl der Hardware- und Softwaretechnologie der falsche Grundstein für den Entwicklungsprozess gelegt: Aktuelle technologische Möglichkeiten werden analysiert und anschließend ein daran angepasstes Oberflächenkonzept konzipiert. Vielmehr müssen zunächst Bedürfnisse, Probleme und Kontext der Nutzer analysiert werden, um dann zu entscheiden, welche Technologie es ermöglicht, optimal auf die identifizierten Bedürfnisse einzugehen. Es muss also „nutzerzentriert“ statt „technologiezentriert“ gedacht und entwickelt werden [2]. Ein konkretes Beispiel soll diesen Prozess verdeutlichen: Kapazitive Touchdisplays mögen im Vergleich zu resistiven Touchdisplays vordergründig die „bessere“ Touchtechnologie repräsentieren, da sie ToucheEreignisse feingranularer auflösen und dabei sogar mehrere Finger gleichzeitig erkennen können. Auf der anderen Seite wird diese Technologie in einer industriellen Umgebung, in der mit Sicherheitshandschuhen unter Spritzwasseraufkommen gearbeitet wird nur geringe Akzeptanz finden. Letztlich werden beide Technologien einem basalen menschlichen Bedürfnis bei der Bedienung nicht gerecht – dem des haptischen Feedbacks. Spielt die Eingabe längerer Textpassagen eine bedeutende Rolle im Workflow des Bedieners, sind „echte“ Hardwaretasten oder -regler mit haptischem Feedback im Gesamtkonzept nicht wegzudenken – egal wie anachronistisch dies im direkten Technologievergleich auch anmuten mag. Das impliziert keineswegs den Umkehrschluss, dass einige der zurzeit aufkeimenden NUI-Technologien nur eine Spielerei darstellen, die allenfalls die Herzen von Entwicklern und Ingenieuren höher schlagen lassen. Wenn ein Bediener in bestimmten Kontexten beide Hände im Einsatz hat – beispielsweise bei der Reparatur eines defekten Maschinenteils – lohnt es sich durchaus, über den Einsatz progressiver Eingabemodalitäten à la Google Glass, Siri oder andere Interaktionsprinzipien nachzudenken. Der Teufel steckt jedoch wie so oft im Detail: Eine Sprachsteuerung, die nur ab und zu das geforderte Kommando versteht, eine Brille, die nach einiger Zeit Schwindelgefühl beim Träger auslöst oder eine berührungslose Steuerung, die eine Bewegung hin und wieder auch mal anders interpretiert als erwartet, werden schlussendlich immer in einer schlechten User Experience münden. Egal welche Software auf solch wackligen Grundlagen entsteht: Sie wird es nicht schaffen, sich als „natürlich bedienbar“ zu behaupten, da sie dem Nutzer mit jedem Verstoß gegen seine Erwartungen die Technologie negativ bewusst macht.

Unplanbarkeit von User Experience

Nimmt man als Softwareentwickler diese Aspekte ernst, sieht man sich plötzlich völlig neuen Herausforderungen gegenüber. Der Lösungsraum, der durch die konkrete Definition von Softwareanforderungen aufgespannt werden soll, nimmt durch die neuen Dimensionen „Eingabemodalität“ und „Nutzungskontext“ plötzlich gigantische Ausmaße an. Die Frage, welcher Lösungsansatz für das eigene Softwareprojekt besser oder schlechter geeignet ist, kann plötzlich nicht mehr aufgrund von Langzeiterfahrungen und somit auch nur sehr eingeschränkt auf Grundlage von Best Practices beantwortet werden. Überspitzt formuliert gibt es so viele mögliche gute Lösungsansätze wie es individuelle Softwareprojekte gibt – und unglücklicherweise noch mehr schlechte. Um diesen neuen Herausforderungen in angemessener Weise zu begegnen, muss weniger das  Ergebnis sondern vielmehr der Prozess in den Fokus der Softwareentwicklung rücken – also eher der Weg als das Ziel. Kern eines solchen Prozesses ist neben den eigentlichen Software-Engineering-Aktivitäten (Modeling, Coding, Testing etc.) ein iteratives Wechselspiel aus Nutzeranalyse, Interaktionsdesign, intensivem Prototyping und Usability Testing [3]. Es muss einen ganzheitlichen Designprozess geben, der nicht ausschließlich Technologie- und Featureentscheidungen, sondern mindestens gleichberechtigt Nutzerziele, Nutzerverhalten sowie Nutzungskontexte betrachtet und die „Unplanbarkeit“ von User Experience vollständig berücksichtigt. Im Folgenden werden die wichtigsten Teamrollen sowie Stationen innerhalb des Gesamtprozesses im Detail erläutert.

Teamkonstellation

Um dem Ziel einer natürlich bedienbaren Benutzungsschnittstelle näher zu kommen, sollte das Kernteam nicht ausschließlich aus Entwicklern und Ingenieuren bestehen. Unerlässlich ist es, mindestens eine Person im Team zu haben, die dort dediziert die Rolle des Interaktionsdesigners einnehmen kann – nicht zwangsläufig auf Basis einer Vollzeitanstellung, jedoch mindestens kontinuierlich während der gesamten Projektlaufzeit. Der Interaktionsdesigner hat zwar wünschenswerterweise Grundkenntnisse in der Softwareentwicklung, um mit Entwicklern auf Augenhöhe reden zu können, seine Wurzeln und Schwerpunkte sind jedoch eher in der (kognitiven) Psychologie zu finden – er ist also näher am Menschen und dessen Bedürfnissen als an der Technologie und deren Möglichkeiten. Auf Grundlage seines detaillierten Zielgruppenwissens schafft der Interaktionsdesigner ein auf die potenziellen Nutzer zugeschnittenes Interaktionskonzept. Zudem sollte das Team über einen visuellen Designer verfügen, der die Ideen und Konzepte des Interaktionsdesigners greifbar und validierbar machen kann und auch dem intrinsischen Bedürfnis des Nutzers nach Ästhetik und Übersichtlichkeit nachkommt. Der visuelle Designer arbeitet eng mit dem Interaktionsdesigner zusammen, sodass ein visuelles Design umgekehrt auch wieder Auswirkungen auf das Interaktionskonzept haben kann und dieses verfeinert, denn die Grenzen zwischen „Form“ und „Function“ sind fließend [4].  Da visuelle Designer und Softwareentwickler mitunter zwei verschiedene Sprachen sprechen (was im Allgemeinen zu Spannung in der alltäglichen Arbeit führt), empfiehlt sich zudem die Rolle des Design Engineers zu besetzen. Der Design Engineer kann gute Interaktionskonzepte und visuelle Designs von schlechten unterscheiden, verfügt dabei jedoch zusätzlich über Know-how in der Softwareentwicklung und kann so dabei unterstützen, Designs zu realisieren und zwischen Konzeptions- und Implementierungsrollen zu vermitteln. In WinRT, WPF oder Silverlight – UI-Technologien also, die das MVVM Pattern unterstützen – ist der Design Engineer derjenige, der XAML-Markup auf View-Ebene produziert, während seine Entwicklerkollegen Models und View Models in C# implementieren. Der Design Engineer arbeitet sowohl evaluierend in einem prototypischen Kontext als auch implementierend direkt in der gemeinsamen Produktivumgebung [5]. Schließlich benötigt das Team einen Usability Engineer. Dieser verfügt ebenfalls über psychologische Kenntnisse und bewertet Interaktionskonzepte mithilfe von Prototypen. Wie in der Softwareentwicklung gilt auch hier: Designer und Usability Engineer sollten möglichst keine Personalunion bilden, denn niemand ist ungeeigneter, um ein Konzept zu testen, als derjenige der das Konzept entworfen hat.

Aufmacherbild: Woman hand using touch screen interface on circuit board background von Shutterstock / Urheberrecht: rvlsoft

[ header = Prozess und Agilität ]

Prozess und Agilität

Viele Softwareunternehmen setzen inzwischen Scrum oder andere agile Methoden für ihren Softwareentwicklungsprozess ein. Ein iteratives, inkrementelles Vorgehen steht auch nicht im Gegensatz zu einer herausragenden User Experience im Endprodukt – im Gegenteil. Die agile Methoden-Toolbox muss jedoch sinnvoll erweitert werden, um vor diesem Hintergrund auch wirklich effektiv zu sein (und nicht etwa kontraproduktiv). Grundsätzlich muss bezüglich der Wahl der Methodik unterschieden werden, ob das Entwicklungsteam sich noch in der eher explorativen Phase der Produktdefinition befindet – der Backlog also noch zu füllen ist – oder ob bereits die Umsetzungsphase läuft und einzelne Items des Backlogs bereits abgearbeitet werden. In der Phase der Produktdefinition – also vor allem bei Neuentwicklungen – werden leider auch in der agilen Softwareentwicklung mitunter ausgiebige Pflichtenhefte vom Produkt Management erstellt. Deren Anspruch ist es oft, ein möglichst breites Spektrum des anvisierten Systems zu beschreiben, damit in der folgenden Umsetzungsphase möglichst wenig Überraschungen auf das Team zukommen und es konkrete Akzeptanzkriterien für umgesetzte Features gibt. Trotz der Fülle von Informationen, die in solchen Dokumenten steckt, wird häufig mit keinem Satz erwähnt, was das konkrete und messbare Businessziel des Projekts ist und welche Nutzertypen oder andere Stakeholder dabei helfen können, dieses Ziel auch tatsächlich messbar zu erreichen. Überraschungen während der Umsetzungsphase erspart man sich mit diesem Ansatz tatsächlich meistens. Sie kommen leider dennoch – oft dann, wenn das System in den Markt geht und aufgrund geringer Nutzerakzeptanz seine Potenziale nicht entfalten kann. Häufig bleibt es auch bei schwammigen Formulierungen wie „Das System muss leicht zu bedienen sein“, was vom Informationsgehalt ungefähr dem Satz entspricht: „Das System muss von Menschen bedient werden“. Selbstverständlich sollte ein Softwaresystem leicht zu bedienen sein – soll diese Aussage jedoch als Abnahmekriterium fungieren, so ist sie bei Weitem zu grobgranular. Gerade vor dem Hintergrund der Unplanbarkeit von User Experience ist es keine Lösung, jedes einzelne Statement dieser Art noch konkreter zu formulieren und das Anforderungsdokument damit um weitere, meist ineffektive Seiten aufzublähen. 

Prototyping – früh scheitern und lernen

Im Sinne einer guten User Experience ist es umgekehrt viel wichtiger, auch bei Neuentwicklungen möglichst früh mit den Umsetzungsarbeiten (im weitesten Sinne) zu beginnen. Die Produktdefinitionsphase muss schmal, tief und kurz statt breit, flach und lang gehalten werden. Softwareanforderungen müssen entlang von Nutzungsszenarien und Nutzertypen organisiert werden anstatt ausschließlich entlang von Features. So entstehen früh im Prozess zahlreiche, eng umrissene Prototypen, von denen jeder für sich genommen ein Puzzleteil darstellt, um klarer auf die Welt möglicher natürlicher Bedienlösungen blicken zu können [6]. Die so entstehenden Prototypen sind hierbei weiter zu fassen, als in der klassischen Softwareentwicklung üblich. Es geht weniger um die Erschaffung von Prototypen, die zwangsläufig in Code implementiert sind (geschweige denn auf einer fest definierten technischen Plattform aufsetzen). Da es das vorrangige Ziel ist, mehr über das resultierende Nutzungserlebnis zu lernen, muss der Prototyp nur dem einzigen Anspruch gerecht werden, mit potenziellen Nutzern validiert werden zu können, um Bedienprobleme zu beobachten und diese Bedienprobleme in nachfolgenden Prototypen zu beheben.

Abb.1: Pixel-präziser Screen Mock eines Touch-HMIs, entworfen in Adobe Photoshop

Es liegt auf der Hand, dass Zeit und Aufwand für jeden Prototyp extrem reduziert werden müssen, damit der Prozess sich insgesamt schnell genug entfalten kann. Hierbei kann der visuelle Designer unterstützen – er erschafft auf Basis der Konzepte des Interaktionsdesigners in kurzer Zeit Pixel-präzise Abbilder der potenziellen Softwareoberfläche (Abb. 1), sodass der Usability Engineer diese mit potenziellen Nutzern validieren und auswerten kann. Bei natürlichen bedienbaren Oberflächen spielt jedes Detail der Interaktion eine Rolle. Zur Evaluation dieser so genannten „Mikrointeraktionen“ [7] kann der Design Engineer helfen, Prototypen zu entwickeln, die sich exakt wie das reale Endprodukt anfühlen. Hierbei entsteht zwar Quellcode – im Sinne des schnellen Voranschreitens muss dieser Code jedoch nicht einmal annähernd den Ansprüchen an eine Produktivumgebung gerecht werden (Einhalten von Konventionen, Beseitigung von Memory Leaks, Unit Testing etc.). Alles was „unter der Haube“ stattfindet ist in diesem Zuge nur Mittel zum Zweck und rein auf technologische Aspekte bezogen nur unter besonderen Voraussetzungen nachhaltig, denn Nachhaltigkeit entsteht zu diesem Zeitpunkt durch die Verdichtung des Interaktionskonzepts [8].

Herausforderungen im Spannungsfeld zwischen Technologie und Natur

Soll eine natürliche Interaktion speziell für ein WinRT oder gar ein Android-Tablet evaluiert werden, so ist es im Sinne des Prototypings durchaus legitim, den dafür konstruierten Interaktionsprototyp dennoch in WPF umzusetzen und auf einem Windows-8-Pro-Tablet zu testen, wenn dadurch aufgrund der größeren Vielfalt von APIs oder der besseren Toolunterstützung eine höhere Produktivität erreicht werden kann. Zur Bewertung eines Interaktionskonzepts geht es ja grundsätzlich mehr um das Erlebnis, das der Nutzer während eines Usability Tests bzw. im Zielsystem hat und weniger um die zugrunde liegende konkrete Technologie. Dennoch kann „Technologie“ an dieser Stelle nicht einfach zugunsten der „Natur“ wegrationalisiert werden. Im Gegenteil gilt unglücklicherweise: Je natürlicher sich ein Interface anfühlen soll, desto komplexer und fehleranfälliger ist die zugrunde liegende Implementierung und desto wichtiger die Optimierung von „Erlebnis-beeinflussenden“ Parametern.  Es gilt zum einen zu beachten, dass die später produktiv zum Einsatz kommende Hardware, der Prototyping-Hardware bezüglich Nutzungserlebnis auch in nichts nachstehen wird. Im industriellen Kontext etwa kämpfen Maschinenbauer und Automatisierungsanbieter damit, dass die zur Steuerung ihrer Geräte verwendeten Industrie-PCs und (Multi-)Touch-Terminals bei Weitem nicht die Performanz oder das akkurate Ansprechverhalten aktueller Consumer-Geräte an den Tag legen, da sie aufgrund des eher „rauen“ Nutzungskontexts größeren Einschränkungen unterliegen [9]. Zum anderen muss darauf geachtet werden, dass beispielsweise Animationen bezüglich ihres Timings exakt auf den Bewegungsfluss von Nutzergesten abgestimmt sind, oder dass Schwellenwerte so optimiert wurden, dass Nutzergesten vom System möglichst eindeutig und erwartungskonform unterschieden werden können, um Frustrationen durch Fehlinterpretationen auszuschließen.

[ header = Moderne Multitouch-Toolkits: WPF und Surface SDK]

Moderne Multitouch-Toolkits: WPF und Surface SDK

Da die Bedienung per Finger aktuell immer noch zu den populärsten natürlichen Interaktionsformen zählt, sei an dieser Stelle etwas näher auf damit verbundene technische Herausforderungen eingegangen. So bekannt und verbreitet diese Interaktionsform nämlich inzwischen sein mag – moderne User-Interface-Toolkits wie etwa WPF machen dem Entwickler den Einsatz nicht so leicht wie man gemeinhin vermuten könnte [10]. Da fast alle aktuellen Toolkits (auch fern der .NET-Welt) in erster Linie immer noch auf Single-Touch oder Klick-Eingaben ausgelegt sind, müssen Entwickler, die sich dem Multitouch verschrieben haben, zunächst einige Hürden überwinden. Wie im Kasten „Wischen oder nicht wischen? Reine Interpretationssache …“ erläutert, geben diese Toolkits inklusive WPF den „Zuschlag“ auf Eingabeereignisse standardmäßig zu früh an einzelne Kontrollelemente, obwohl diese unter Umständen gar nicht im Fokus des Bedieners lagen.

Wischen oder nicht wischen? Reine Interpretationssache … Eine global verfügbare Wischbewegung mit zwei Fingern („Two Finger Swipe“), beispielsweise zum Navigieren zwischen zwei Bildschirmen, besteht heruntergebrochen aus der Abfolge:  • Auflegen des ersten Fingers  • Auflegen des zweiten Fingers (den Bruchteil einer Sekunde später)  • Bewegen der beiden gehaltenen Finger • Abheben einer der beiden Finger (nicht zwangsläufig der erste) • Abheben des anderen Fingers Bereits beim Auflegen des ersten Fingers überprüft das WPF-Ereignissystem, ob der registrierte Touchpunkt innerhalb der Grenzen eines Kontrollelements liegt (beispielsweise eines Buttons). Ist dies der Fall, behandelt und konsumiert dieses Kontrollelement das Touchereignis, sodass das Auflegen des zweiten Fingers effektlos bleibt. Nur eine koordinierende Instanz, die zunächst innerhalb eines sehr kurzen Zeitintervalls „abwartet“, ob kurz nach dem ersten Finger nicht doch noch ein zweiter Finger folgt, um dann zu entscheiden, ob der erste Finger alleine durchgeht oder nur in Kombination mit dem zweiten Finger, kann an dieser Stelle Abhilfe schaffen.  Ähnlich geht es anschließend mit der Frage weiter, wie lange die beiden Finger bewegungslos an Ort und Stelle liegen. Bewegt der Nutzer die beiden Finger nach dem Auflegen innerhalb eines (zweiten) Zeitintervalls über eine gewisse Schwellendistanz, handelt es sich offensichtlich um eine „Two Finger Swipe“-Geste während es sich im anderen Fall lediglich um eine „Two Finger Press And Hold“-Geste handelt. Je mehr Gesten zur Verfügung stehen sollen, desto komplexer wird die Koordination dieser Gesten und desto größer die Menge an Schwellenwerten, die auf ein natürliches Bedienerlebnis hin optimiert werden müssen. Eine allumfassende Out-of-the-Box-Lösung sucht man bezüglich Multi-Touch-Interaktion trotz der Fülle „etablierter“ Gesten in den meisten User-Interface-Toolkits inklusive WPF vergebens. Eine Linderung verschafft an dieser Stelle das Surface 2.0 SDK [11]. Unabhängig davon, ob das SDK im finalen Produkt auch tatsächlich eingesetzt wird, unterstützt es Entwickler und Design Engineers dabei, mit dem Thema Multi-Touch „warm“ zu werden oder auf schnelle Art und Weise Multi-Touch-Prototypen zu konstruieren. Schließlich basieren die spezialisierten Surface-Kontrollelemente direkt auf den WPF-Standardkontrollelementen, erlauben aber eben ab Werk Mehrfingerbedienung oder physikalische Effekte wie das Schubsen und Abfedern von Listenelementen mittels der so genannten SurfaceListBox („kinetisches Scrolling“). Aufgrund der direkten Nähe zu WPF muss der Entwickler auch keinen Microsoft-Surface-Tisch sein eigen nennen, um die Vorteile des SDKs voll nutzen zu können. Ein handelsüblicher Multi-Touch-Monitor, angeschlossen an einen Windows-7/8-PC ist ausreichend. Selbst gänzlich ohne Toucheingabegeräte, also nur via Mausbedienung, kann über den so genannten „Input Simulator“ eine Multi-Touch-Umgebung simuliert werden. Unabhängig von den eingesetzten SDKs lohnt es sich vor dem Hintergrund der genannten Herausforderungen in jedem Fall, sich früh im Entwicklungsprozess darüber klar zu werden, welche Gesten auch tatsächlich sinnvolle Kandidaten für die eigene Anwendung sein könnten. Eine umfangreiche Auflistung möglicher Gesten – auch über Touchbedienung hinaus – findet sich bei Gesturecons [12].

Natürliche Interaktion weitergedacht

Ungeachtet der genannten technischen Herausforderungen gehört Multi-Touch in den Köpfen moderner Computernutzer inzwischen bereits zum State of the Art. Möchte man einen Schritt weitergehen und noch natürlicher in der Bedienung werden, muss über komplett berührungslose Steuerungen nachgedacht werden. Gerade in der Industrie existieren für berührungslose Steuerungen mannigfaltige sinnvolle Einsatzszenarien. Da eine intensive Betrachtung den Rahmen dieses Artikels sprengen würde, sei an dieser Stelle nur ein erster Einblick gegeben. Was Surface-Tisch und -Tablet für die Multi-Touch-Interaktion sind, sind Kinect [13] und Leap Motion [14] für die vollständig berührungsfreie Interaktion. Während der (aktuelle) Kinect-Sensor von Microsoft zwar relativ unpräzise arbeitet, dafür jedoch Daten zu Kopfbewegungen und allen vier Extremitäten liefert, richtet sich die Leap Motion besonders an stationäre Arbeitsplätze und kann „lediglich“ Hand- und Fingerbewegungen erkennen – diese jedoch mit bestechender Präzision. Für beide Technologien existieren SDKs für Windows, die zum Experimentieren einladen. Auch Google hat mit seinem Projekt „Glass“ einen Schritt in Richtung NUIs gemacht. Googles digitale Brille (oder eher „Monokel“) erlaubt es, per Sprachsteuerung Befehle wie „Mache ein Foto“ abzusetzen, woraufhin die eingebaute Kamera treu zur Tat schreitet. Zudem unterstützt das eingebaute Display den Nutzer dabei, Kontextinformationen über die reale Welt zu bekommen. Dank eingebautem Internetzugang ist das Thema „Augmented Reality“ somit in greifbare Nähe gerückt. Das Google SDK ist zurzeit leider nur für einen ausgewählten Entwicklerkreis zugänglich [15].  Auch die Bedienung mittels Stift kann trotz der indirekten Eingabe als natürlich bezeichnet werden. An dieser Stelle sei beispielsweise der InkAnalyser [16] von Microsoft genannt. Last but not least darf nicht vergessen werden, dass fast jedes moderne, mobile Endgerät zumeist mit zahlreichen hilfreichen Sensoren ausgestattet ist, über deren Einsatz es sich beim Prototyping oder in der finalen Software lohnt, nachzudenken. Beschleunigungssensor, Gyroskop, Kompass, GPS – alle haben sie das Potenzial, im richtigen Kontext ein natürlicheres Nutzungserlebnis zu schaffen und spielen oft gerade in Kombination ihre volle Stärke aus.

Fazit

Um NUIs im eigenen Softwareprojekt erfolgreich zu realisieren, muss sich der Entwicklungsprozess in erster Instanz an Nutzern, ihren Zielen und den Nutzungskontexten statt an technischen Gegebenheiten und Featurelisten orientieren. Dabei ist eine gute User Experience, also ein gutes Nutzungserlebnis, aufgrund der hohen Komplexität beeinflussender Faktoren nicht im Vorfeld der Entwicklung spezifizierbar. Vielmehr muss die Entwicklung so ausgerichtet werden, dass sie mittels intensivem Prototyping bereits früh im Prozess wertvolle Erkenntnisse über gute und schlechte Interaktionskonzepte liefert. Beim Prototyping sollten Interaktionsdesigner, visuelle Designer und Design Engineers aufgrund ihrer nutzerzentrischen Perspektive auf das Projekt eng verzahnt arbeiten und dem klassischen Softwareentwickler so greifbare Repräsentationen der zu implementierenden Konzepte liefern. Je mehr Details der natürlichen Interaktion eine Rolle spielen, desto stärker muss sich der Design Engineer oder Entwickler beim Prototyping mit aktuellen Hardwaremöglichkeiten und Software-SDKs auseinandersetzen und darf nicht davor zurückscheuen, zunächst eine Reihe von erkenntnisbringenden Machbarkeitsstudien (sog. „Spikes“) zu erschaffen.  Obwohl das Ziel der natürlichen Bedienbarkeit in der Regel die Komplexität des Entwicklungsprozesses erhöht, lohnt sich ein Umstieg – ein natürlich bedienbares Interface wird automatisch zum Verkaufskriterium einer Software, da Nutzer effizienter, effektiver und zufriedener ihre Ziele erreichen. Dies ist neben dem Set an gebotenen Features inzwischen das größere Differenzierungsmerkmal, um ein Softwareprodukt erfolgreich vom Wettbewerb abzuheben.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -