Leistungen

Lexikon

Adaptive

Moderne Benutzeroberflächen müssen sich auf Bildschirmen mit unterschiedlichen Größen und Auflösungen darstellen können. Um dies zu gewährleisten, kombinieren wir adaptives Verhalten mit responsivem Verhalten. Adaptives Verhalten bezieht sich auf die Anpassung der Inhalte. Je nach verfügbarem Platz werden Informationen entweder dauerhaft angezeigt oder sind über Interaktionen erreichbar. Eine Navigation ist beispielsweise entweder ausgeklappt oder auf einen Burger-Menü-Button reduziert, über den die Inhalte aufgerufen werden können. Auf großen Bildschirmen kann ein Widget detaillierte Informationen darstellen oder besonders groß dargestellte KPIs bleiben auch mit einem größeren Betrachtungsabstand lesbar. Steht weniger Platz zur Verfügung, so reduzieren sich die Inhalte immer weiter auf das Wesentliche.

Backlog

Mit Backlog meinen wir Aufgaben, die noch nicht bearbeitet wurden. In der Analyse-Phase erstellen wir eine Liste von prioriserten Anforderungen, die anschließend entlang des Design- und Entwicklungsprozesses bearbeitet werden. In regelmäßigen Abständen prüfen wir, ob alle wichtigen Aufgaben erledigt sind.

Benutzer:innenbefragung

Was brauchen die Benutzer:innen? Wie können wir ihre Arbeit bestmöglich unterstützen? Um diesen Fragen nachzugehen, führen wir semistrukturierte Interviews mit ihnen. Ziel ist es dabei, dass die Interviewten von ihrem Arbeitsumfeld, ihren Aufgaben, Problemen und Bedürfnissen berichten. So können wir individuelle Erfahrungen, Bedürfnisse und Anwendungskenntnisse analysieren und Optimierungspotential für die Bedienung der Software ermitteln.

Darüber hinaus bitten wir Benutzer:innen, die Anwendung mithilfe von standardisierten DIN ISO Multiple Choice Fragebögen zu bewerten. Die statistische Auswertung dieser gibt wichtige Hinweise auf aktuelle Schwachpunkte der Software.

Benutzer:in

Benutzer:innen sind die Menschen, die eine Software verwenden. Human Machine Interfaces haben in aller Regel mehrere Benutzer:innen mit verschiedenen Anforderungen und Berechtigungen (siehe auch Benutzer:innenrollen). Die Bedürfnisse der Benutzer:innen stehen im Fokus unserer Arbeit. Zeitgemäßes User Interface Design ist immer nutzungszentriert.

Benutzer:innenrolle

Die Benutzer:innen eines Interfaces lassen sich anhand ihrer Aufgaben, Qualifikationen und Berechtigungen in Gruppen aufteilen. Ein zeitgemäßes Berechtigungssystem ist entsprechend zweistufig aufgebaut. Einzelne Benutzer:innen werden dabei vorgefertigten Rollen zugewiesen. Unser Aufgabe ist es, im Rahmen der Definition der Nutzungsanforderungen die Aufgaben und entsprechend Berechtigungen der jeweiligen Benutzerrollen zu definieren. So erhält jede Benutzer:in den genau auf ihre Rolle zugeschnittenem Informations- und Funktionsumfang. Eine Servicetechniker:in ist beispielsweise dazu berechtigt, Änderungen in der Software vorzunehmen, während eine Schichtleiter:in manche Parameter nur einsehen, aber nicht verändern darf. Ein einfacher Operator hingegen bekommt Parameter, die er nie benutzen muss, gar nicht erst angezeigt. Das reduziert die Komplexität jeder Anwendung und vermeidet, dass Benutzer:innen mit Informationen überfordert werden.

Design System

In Designsystemen beschreiben wir die Grundeigenschaften von Designkomponenten. Das sorgt für eine konsistente Softwareentwicklung und dient als Basis für die Zusammenarbeit zwischen unseren Designern und den Entwicklern. Designsysteme sorgen für effiziente Teamarbeit und ermöglichen die Erstellung von nachhaltigen und skalierbaren Designs. Inhaltlich umfasst ein Designsystem grundlegende Definitionen wie Grids, Farben, Stile…, außerdem die Bausteine, wie Icons, Components, Patterns, Templates, … und die Regeln zu deren Anwendung. Designsysteme beschränken sich nicht auf die reine Dokumentation des Designs, sondern bilden das langfristige Rahmenwerk eines Produktes. Im Designprozess und der anschließenden Reviewphase werden von uns kontinuierlich Optimierungen am Produkt vorgenommen, die das Aussehen, das Verhalten und die Muster der Designkomponenten verändern. Die Entwicklung eines Designsystems ist entsprechend immer im Fluss.

Design Tokens

Ein entscheidender Bestandteil von Design-Systemen ist die Dokumentation von Design-Eigenschaften wie Farben, Abständen und Größen als Variablen, den sogenannten Design-Tokens. Diese werden in einer globalen Liste verwaltet und können dann an den jeweiligen Objekteigenschaften sowohl im Design als auch im Code referenziert werden. Ziel ist dabei, die Beschreibung des Designs so nah wie möglich an die Implementierung heranzuführen, während gleichzeitig Plattform- und Technologieunabhängigkeit gewährleistet bleibt. Änderungen am Design können dadurch standardisiert an die Entwicklung übergeben werden, ohne dass diese vom Entwickler "übersetzt" werden müssen – im Idealfall funktioniert das sogar komplett automatisch.

Expert:innenevaluation

Im Gegensatz zur Benutzer:innenbefragung kommen hier wir zum Zug. Als Usability-Expert:innen bewerten wir die Software im Hinblick auf ihre Nutzungsfreundlichkeit. Dabei identifizieren wir mit geschultem Blick Schwächen und Probleme, sowie Abweichungen von bekannten Nutzungsgewohnheiten oder Erfahrungswerten, die wir bei unseren zahlreichen Projekten sammeln konnten. Grundlage unserer Bewertung sind immer die standartisierten Dialogprinzipien der DIN EN ISO 9241-10 bzw. die Usability Heuristiken nach Nielsen.

Informationsarchitektur

Informationsarchitektur bezeichnet den Aufbau eines Softwareprodukts hinsichtlich seiner Struktur und der Beziehung seiner Inhalte. Die Informationsstruktur erstellt für uns die Grundlage der Gliederung eines UIs dar. Die Erstellung der Informationsarchitektur ist deshalb in unserem Prozess einer der ersten Schritte bei der Gliederung der Nutzungsanforderungen und findet in der Konzeptionsphase statt. Hierbei legen wir fest, welche Inhalte dem Benutzer später im UI wo angeboten werden. Dabei ist es uns wichtig, sowohl Informationen abhängig von z.B. Nutzungskontext, oder Nutzerrolle zu unterteilen, aber auch sinnvolle Zusammenhänge herzustellen, die bisher in der Software nicht intuitiv erreichbar waren. Durch das Erkennen dieser Beziehungen fällt es uns dann leicht, im späteren Prozess eine logische Navigationsstruktur abzuleiten.

Intuitiv

Wir konzipieren unsere Interfaces immer im Hinblick auf Vorwissen und Navigationsgewohnheiten der Benutzer:innen. Diese erlernen im alltäglichen Umgang mit digitalen Anwendungen bestimmte Navigationsschemata und treten mit einer bestimmten Erwartungshaltung an jede Software heran. Je besser ein User Interface diese Erwartungen erfüllt, desto intuitiver ist die User Experience und desto leichter fällt den Nutzer:innen die Bedienung. Intuitive Bedienung ist somit immer das Resultat eines erfolgreich durchgeführten, nutzungszentrierten Entwicklungsprozesses.

Nutzungskontextanalyse

Benutzer:innen können nicht immer alle Schwachstellen einer Software oder alle Anforderungen in Worte fassen. Um einen zusätzlichen Einblick in das Arbeitsumfeld und ihre Bedürfnisse zu erhalten, besuchen wir sie deshalb am Arbeitsplatz.

Vor Ort bei den Betreibern der Maschinen beobachten wir Benutzer:innen während der Arbeit an einer Maschine und der Interaktion mit dem HMI. Zusätzlich finden bei solchen Terminen auch Benutzer:innenbefragungen statt. Mit Fingerspitzengefühl und Empathie gelingt es uns dabei, Problemen und Bedürfnissen auf die Schliche zu kommen.

Aus den Ergebnissen der Nutzungskontextanalyse leiten wir dann die Nutzungsanforderungen für die Bedienung des Interfaces ab. Sie sind der Schlüssel, um die Anwendung optimal an den Einsatzbereich und die Bedürfnisse der Benutzer:innen anpassen zu können.

Nutzungstest

Beim Qualitativen Benutzungstest wird eine kleine Fallzahl Benutzer:innen beim Bedienen des Interfaces beobachtet. Wir fordern sie dabei auf, laut zu denken, um ihre Schritte und Reaktionen besser nachvollziehen zu können. Mit Empathie und Fingerspitzengefühl können wir so ihre Probleme und Bedürfnisse identifizieren und Verbesserungen am Interface vornehmen.

Nutzungstests können bereits in frühen Stadien anhand von Low Fidelitiy Prototypen durchgeführt werden, aber dienen auch der Evaluation nach Abschluss des Projektes.

Paper Prototype

Papierprototypen können schnell und ohne Computer hergestellt werden und eignen sich besonders gut, um Ideen festzuhalten und agil im Team zu besprechen. Hier geht es vor allem um schnelle Studien zum grundsätzlichen Aufbau und den Basisfunktionen des späteren Interfaces.

Sind die ersten Ideen festgezurrt, gehen wir im nächsten Schritt an den Computer und digitalisieren die so entwickelten Konzepte in Form von Wireframes, die dann detailliert ausgearbeitet werden.

Persona

Das Erstellen von Personas ist eine Design Thinking Methode, die die Bedürfnisse von Benutzer:innen greifbarer macht. Wir erstellen dafür den Steckbrief einer fiktiven Person anhand von stereotypischen Merkmalen einer Benutzer:innengruppe. Die Idee ist es, sich in diese fiktive Person hineinzuversetzen und die Bedienbarkeit aus ihrer Perspektive nachzuvollziehen.

Prototyping

Das Prototypisieren macht unsere Entwürfe lebendig. In sogenannten Low Fidelity Prototypen wird die Anwendung von uns simuliert und ganz ohne Programmierung bedienbar gemacht. Wir verlinken dabei im einfachsten Fall einzelne Screens. Es sind aber auch animierte Seitenwechsel und Mikroanimationen möglich. So erzielen wir in einer frühen Projektphase bereits eine realistische User Experience und haben ideale Bedingungen um erste Nutzungstests durchzuführen. Gegen Ende des Designprojektes ist es möglich auch High Fidelity Prototypen auf Basis des finalen Interface Designs zu erstellen. Dabei entsteht eine Software-Simulation, die dem finalen Produkt bereits sehr nahe kommt.

Responsive

Moderne Benutzeroberflächen werden von uns von Anfang an für den Einsatz auf verschiedenen Bildschirmgrößen und Auflösungen konzipiert. Wir definieren ein flexibles Rastersystem von Anfang an und erstellen optimierte Designvarianten für bestimmte Platzverhältnisse. Anhand sogenannter Breakpoints entscheidet das System dann selbst, welche Variante aktuell dargestellt werden soll. Die Datenbasis bleibt dabei immer die gleiche. Das bedeutet, dass das System nur einmal gepflegt werden muss und trotzdem auf zahlreichen Ausgabegeräten optimal genutzt werden kann. Idealerweise wird das responsive Verhalten mit adaptivem Verhalten kombiniert eingesetzt.

Sitemap

Sitemaps ermöglichen es uns, einen klaren Aufbau der Software und eine konsistente Informationsarchitektur zu garantieren. Sie visualisieren in Form von Baumdiagrammen Navigationsmöglichkeiten und inhaltliche Zusammenhänge. So wird der organisatorische Aufbau eines Systems logisch strukturiert und vereinfacht. In der Regel erstellen wir Sitemaps zu Beginn der Konzeptionsphase und passen sie während der weiteren Ausarbeitung bei Bedarf weiter an.

Styleguide

Der Styleguide ist eine Spezifikation, die entlang des Designprozesses entsteht und als Schnittstelle zwischen Design und Entwicklung dient. Er enthält die Informationen, die das Entwicklungsteam braucht, um das Designkonzept umzusetzen. Der Styleguide umfasst alle Spezifikationen und Regeln des Designkonzeptes, grafische wie funktionale Design Patterns.

Wir arbeiten dabei mit so genannten Living Styleguides. Das bedeutet, dass wir auch über den initialen Designprozess hinaus Erweiterungen und Ergänzungen am Styleguide vornehmen. Um eine optimale Weiterentwicklung und Pflege der Software zu ermöglichen, setzen wir dabei auf eine enge Zusammenarbeit von Design- und Entwicklungsteam.

Styling

Während sich beim Wireframe alles um die Bedienbarkeit dreht, fokussieren wir in der Globalen Designphase die visuelle Ausgestaltung des User Interfaces. Erst hier erstellen wir eine geeignete Farbpalette und definieren Icon-, Control-, Infografik-, und Illustrations-Stile. Hier entscheidet sich zum Beispiel, ob Elemente Schatten und/oder abgerundete Ecken erhalten. Das finale User Interface passen wir harmonisch an das Corporate Design der Hersteller und das Industriedesign der Maschinen an. Die grafischen Spezifikationen werden im Anschluss im Styleguide dokumentiert.

Szenario

Eng verbunden mit den Personas, ist das Szenario eine Design Thinking Methode, die eine bestimmte Anwendungssituation möglichst greifbar machen soll. Dabei geht es uns vor allem um die Frage, in welchen Kontexten Nutzer:innen sich jeweils bewegen. Wir verwenden Szenarien in Form von erzählerischen Beschreibungen beispielhafter Szenen. Diese helfen uns bei der Überprüfung einer Nutzungsanforderungen oder beim Testen eines Workflows.

Thinking Aloud

Im Rahmen unserer Nutzungstests nutzen wir gerne die Thinking Aloud Methode. Wir bitten dabei Nutzer:innen ihre Gedanken und Beobachtungen im Umgang mit der Software laut auszusprechen. So können wir die Reaktionen der Nutzer:innen leichter nachvollziehen und eventuelle Probleme im Umgang mit der Software schnell aufdecken.

Usability

Usability lässt sich am besten als Gebrauchstauglichkeit oder Benutzungsfreundlichkeit übersetzen. Genauer ist sie ein Maß dafür, wie effektiv, also erfolgreich, die Nutzung abläuft. Darüber hinaus geht es um die Effizienz, also wie schnell die erfolgreiche Nutzung durchgeführt werden konnte. Und letztendlich spielt auch die Zufriedenheit der Bediener:innen bei der Nutzung eine große Rolle.

Usability wird bei uns nach den Standards der DIN ISO 9241 Norm im Form eines interativen Prozesses optimiert. Sie ist dabei mit wissenschaftlichen Methoden messbar und kann statistisch ausgewertet werden.

Für uns ist ein hohe Usability die Grundvoraussetzung für die Erstellung jedes Projektes. Nur wenn eine Software optimal bedient werden kann macht es auch Sinn das User Interface grafisch ansprechend zu gestalten.

User Experience

Ein wichtiger Bestandteil der Usability ist, dass der Nutzungsprozess auch zufriedenstellend verläuft. Um das sicher stellen zu können ist es notwendig, dass neben der reinen Interaktion am HMI auch der restliche Arbeitsprozess der Nutzer:innen und vor allem auch der Kontext vor und nach der Nutzung des HMIs in die Betrachtung mit einbezogen wird. Man spricht dann von einem ganzheitlichen Nutzungserlebnis, der sog. User Experience.

Wireframe

Unter Wireframe verstehen wir eine erste grobe Studie des User Interface Designs. Da es uns dabei um eine rein funktionale Abbildung des Interfaces geht, arbeiten wir immer mit unserer standardisierten Wireframe Library in einem abstrahierten, skizzenhaften Stil.

Positionen, Größen und Inhalte der Elemente werden hier schon erarbeitet, konkrete Gestaltungselemente lassen wir aber bewusst weg. Auf diese Weise kann man sich bei der Abstimmung voll auf die Funktionen konzentrieren und wird nicht von Geschmacksfragen bei der Beurteilung abgelenkt.