5Als Design- und Usability Agentur spezialisiert auf Industrie- und Business-Projekte haben wir in den letzten 18 Monaten im Kundenauftrag die Steuerung einer Erodiermaschine überarbeitet und Teile der Entwicklung verantwortet. Dabei haben wir nicht nur gelernt, wie Erodieren funktioniert, sondern auch, dass die aktuell verfügbaren Design-Tools sich nur bedingt für den Relaunch einer komplexen Industrie-Anwendung eignen.
Project Scope: Worum ging es genau?
Erodieren ist ein “thermisches, abtragendes Fertigungsverfahren für leitfähige Materialien”. Kurz gesagt wird mittels Elektrode und Funkenschlag Material von einem leitfähigen Werkstück abgetragen. Das Verfahren ist so präzise, dass damit beispielsweise die Gussformen für filigrane Einzelteile von Modelleisenbahnen hergestellt werden können.
Auch wenn so eine Maschine feinste Bauteile herstellen kann, sind die eigenen Ausmaße alles andere als filigran. 2,65m × 1,8m × 2,75m und eine Masse von stattlichen 7000kg sprechen für sich. Die Maschine muss allerdings nicht bewegt werden, vielmehr steuert der Nutzer alle Arbeitsschritte über ein Touchdisplay und ein Handbedienteil.
Diese Steuerung galt es in unserem Projekt gemeinsam mit dem Hersteller Zimmer & Kreim zu überarbeiten. Dabei ging es initial eigentlich “nur” darum, im Zug einer technischen Überarbeitung der Maschine die Steuerung touch-fähig zu machen. Schon mit unserem ersten Aufschlag für die Anpassung des Bedienkonzeptes stellte sich allerdings heraus, dass das ursprünglich historisch gewachsene Konzept grundlegend überarbeitet werden musste. Das Ziel dabei war, den natürlichen Arbeitsablauf beim Erodieren eines Werkstückes möglichst intuitiv in der Oberfläche abzubilden und den Nutzer bestmöglich bei seinen komplexen Arbeitsschritten zu unterstützen.
Projektorganisation und Ablauf
Eine der ersten Fragen, die wir uns als Usability-Experten naturgemäß stellen: “Wie kommen wir in Kontakt mit Nutzern?” Insbesondere bei einer solch speziellen Zielgruppe ist das gar nicht so einfach zu bewerkstelligen. Fündig wurden wir dann bei Zimmer & Kreim selbst. Hier sind gleich mehrere sogenannte “Anwender” beschäftigt: ein kleines Team, das neue Maschinen beim Kunden in Betrieb nimmt, Schulungen durchführt und auch im Service tätig ist. Innerhalb dieser Anwendergruppe ist also extrem viel Wissen über den Nutzungskontext und die Bedürfnisse der eigentlichen Maschinenbediener aggregiert. Aus diesem Grund haben wir jede neue Projektphase stets mit einem Workshop mit diesen Anwendern begonnen. In der Z&K eigenen Maschinenhalle haben wir uns von ihnen die jeweilige Funktionen erläutern lassen, Konzepte entwickelt und iteriert und sogar Usability Tests mit einem eigens entwickelten Prototypen direkt auf der Maschine durchgeführt.
Einige Eindrücke aus einem der Anwenderworkshops: wie man sieht, haben wir die Themen erst mit Hilfe von Statty Notes an der Wand strukturiert und uns Thema für Thema Konzepte gescribbelt.
Zudem gewährleistete die Arbeit in der abgeschlossenen Halle mit einem definierten Team auch die notwendige Geheimhaltung für ein solches Projekt. Erst auf einer Messe nach etwa einem Jahr Entwicklungszeit, sollte die “Katze aus dem Sack” gelassen und die neue Steuerung erstmals der Öffentlichkeit präsentiert werden.
Aber der Reihe nach. Im ersten Schritt haben wir uns die für die Bediener wesentlichste d.h. die am häufigsten genutzte Funktion herausgegriffen. Auf Basis eines Anforderungsworkshops vor Ort haben wir rund um diese Funktion ein erstes Bedienkonzept entwickelt. Ergänzend dazu entstand auch schon der neue visuelle Stil, den wir aus dem bestehenden Erscheinungsbild des Auftraggebers abgeleitet haben. So verbinden sich ein Erscheinungsbild-konformes intuitives Interface mit dem prägnanten Industrie-Design der Z&K Maschinen.
Doch warum dieser Kopfsprung direkt ins Projekt? Nun, zu Beginn war der initiale Wunsch des Auftraggebers, das Bedienkonzept beizubehalten und lediglich touch-fähig zu machen. Somit war ein klassischer Start mit einer Research- und Analyse-Phase nicht argumentierbar. Zudem fehlte beim Auftraggeber Erfahrung damit, das Interface durch einen externen Dienstleister gestalten und entwickeln zu lassen.
Der direkte Einstieg in die Konzeption war daher zum einen eine vertrauensbildende Maßnahme für das Projektteam und zum anderen eine Leistungsschau für die Entscheider. Das Ergebnis hat schnell gezeigt, wie groß das Potential einer Überarbeitung ist und was alles erreicht werden kann, wenn die gesamte Steuerung bearbeitet wird.
Vergleich der Steuerung vor unserer Überarbeitung und nach dem initialen Aufschlag.
Aufgrund des schnellen Einstiegs mussten wir allerdings die erste Konzeptversion im Projektverlauf kontinuierlich iterieren und anpassen. Hier lässt sich der User Centered Design Prozess allerdings wunderbar adaptieren, um im Projektverlauf auftretende zusätzliche Nutzungsanforderungen zu berücksichtigen.
In der darauffolgenden zweiten Projektphase wurden dann erste Ansichten der neuen Steuerung bereits in der Entwicklung umgesetzt und an die Maschine angebunden.
Parallel dazu nahmen wir uns den zweiten Funktionsbereich der Steuerung vor. Da wir die erste, zugegeben etwas unruhige, Projektphase hinter uns gelassen hatten, konnten wir die Arbeiten am Interface jetzt analog zum Erodierprozess gestalten. Um bei den kontinuierlichen Änderungen am Interface und damit auch am Code den Überblick zu behalten, haben wir für beide Leistungsarten ein zentrales Ticketsystem verwendet, auf das die Designer, Entwickler und der Auftraggeber Zugriff hatten. So wurde der Weg von Anforderungen und Ideen über die Ausarbeitung von Konzepten und Designs bis hin zur Umsetzung via HTML und CSS für alle nachvollziehbar.
Unsere Toolchain: Axure, Sketch & Zeplin
Neben der organisatorischen Steuerung spielt bei einem so komplexen Projekt auch die Wahl der Waffen … ähm … Tools eine große Rolle. Bei uns kam neben dem bereits beschriebenen Ticketsystem ein Dreiklang aus Axure für die Konzepte, Sketch fürs Visual Design und Zeplin für die Kommunikation mit der Entwicklung bzw. dem Kunden zum Einsatz.
Stand heute hat unser Axure Prototyp einen Umfang von über 40 miteinander verlinkten Seiten mitsamt Interaktionen und Effekten. In Zeplin befinden sich insgesamt über 60 Screens (einzelne Ansichten und ihre Zustände) und noch einmal über 20 einzelne Doku-Seiten, die das Verhalten von komplexen Informationsdarstellungen und Interaktionselementen definieren.
Axure war für uns speziell direkt nach den Workshops mit den Anwendern wichtig. So konnten wir die Funktionen, dir wir vor Ort gemeinsam gescribbelt hatten, vergleichsweise einfach digital abbilden und auch direkt die wichtigsten Interaktionen zeigen.
Ein Beispiel für eine vergleichsweise komplexe Seite mit verschiedenen Interaktionen, umgesetzt in Axure. Neben dem Menü links sind z.B. auch die Toggle-Buttons rechts und die Navigation oben klickbar.
Der Kunde konnte sich unsere Konzepte über einen Link zum Prototyp direkt anschauen und auch vor Ort noch einmal mit seinen Anwendern besprechen. Alle freigegeben Funktionen wurden im Anschluss in Sketch ausgestaltet. Die entstandenen Ansichten inkl. der Definition von z.B. Zuständen stellten wir via Zeplin bereit.
Beispiel für eine Ansicht in Zeplin zusammen mit der Definition eines Details, Achsendarstellung links in der Ansicht (zum Vergrößern anklicken)
Und genau hier zeigt sich auch schon die Sollbruchstelle dieses Vorgehens, das bis dato leider noch nicht von einer einzelnen Applikation gehalten werden kann. So gut Axure und Sketch/Zeplin jeweils für ihre Teildisziplinen sind, bringt es zahlreiche Nachteile mit sich, überhaupt zwei verschiedene Tools nutzen zu müssen:
Der erste Nachteil ist aus unserer Sicht, dass diese Aufteilung verlangt, dass der Auftraggeber mental zwischen Konzept und Visual unterscheiden kann – eine Grenze, die selbst für uns nicht immer trennscharf zu definieren ist. Es stand also immer mal wieder die Frage im Raum, wo jetzt eine bestimmte Information zu finden ist: gehört die Information zum Konzept und ist daher im Axure Prototyp oder ist es doch eher eine visuelle Sache in Zeplin? Im Zweifel wurde meist der Stand in Zeplin vom Kunden als “fertiger” wahrgenommen und der Axure-Prototyp und die dort getroffenen Entscheidungen gerieten allzu schnell in Vergessenheit.
Ein zweiter Nachteil dieses Vorgehens ist der Pflegeaufwand. Wir hatten immer wieder Fälle, in denen Entscheidungen im Laufe des Umsetzungsprozesses angepasst oder vervollständigt wurden. Im Worst Case fielen erst bei der Anbindung eines bereits implementierten Teils der Oberfläche an die Maschine technisch bedingte Lücken oder Unstimmigkeiten auf. Dann wurden ad hoc Anpassungen vorgenommen, die dazu führten, dass sowohl der Stand in Zeplin als auch im Axure Prototyp veraltet war (der iterative Grundgedanke einer agilen Vorgehensweise lässt grüßen). Das rückwirkende Ändern aller vorangegangen Stellen im Projekt mussten wir aus Aufwands- und Zeitgründen schnell aufgeben. Das hat dazu geführt, dass eigentlich nur die fertig entwickelte Oberfläche als “Goldstandard” anzusehen ist.
Im Gegensatz dazu war jedoch auch ein Verzicht auf ein explizites Konzept- oder Designtool für uns nicht möglich. Gerade Sketch zieht zwar momentan erste Prototyping-Funktionen nach, für unsere Anforderungen ist das jedoch noch längst nicht ausreichend. Die eierlegende Wollmilchsau gibt es aus unserer Sicht noch nicht und selbst Adobe XD ist immer noch eine Vollkatastrophe im gefühlten Beta-Stadium. Wenn Ihr eine besser funktionierende Lösung habt, freuen wir uns über Eure Kommentare.
Das Pareto-Prinzip lässt grüßen: Warum es am Ende immer länger dauert
Zum Abschluss sei noch ein Wort zu unserem vielleicht größten Learning gesagt, dass uns das komplexe Projekt wieder einmal wunderbar vor Augen geführt hat: Pareto hatte Recht.
Nachdem sich das Team formiert hatte und die Marschrichtung klar war, gingen uns die ersten Funktionen recht einfach von der Hand. Entscheidungen über die Aufteilung der Screens und zentrale Interaktionselemente wurden getroffen. Es entstand Funktion nach Funktion. Vielleicht ist die 80/20 Aufteilung etwas übertrieben, aber es ist definitiv so, dass der Aufwand für weitere Funktionen im Projektverlauf immer weiter zunimmt. So gilt es mit jeder neuen Funktionen zu bedenken, wie sich neue Elemente in das bisherige Konzept einfügen.
Ein Beispiel dafür: die Buttonleiste mit den Funktionstasten am unteren Rand. Am Anfang kamen uns die sieben im Raster verfügbaren Buttons sehr großzügig vor. Am Ende mussten wir sogar über eine Art “Buttonkarusell” nachdenken, um alle nötigen Funktionen abzubilden.
Das “Buttonkarusell”: über einen Pfeil rechts werden weitere Buttons ein- und ausgeblendet. Das hat u.a. den Nachteil, dass man die versteckten Funktionen erst nach dem Klick auf den Pfeil sieht.
Der Fortschritt wird also für alle Beteiligten merklich mühsamer. Gleichzeitig arbeitet man sich ja (glücklicherweise) entlang der Nutzungshäufigkeit an den Funktionen entlang. D.h. Kompromisse in der Bedienung, die vor allem in den späteren Projektphasen gemacht werden müssen, kommen bei Funktionen zum Tragen, die nicht zentral für die Usability der Steuerung insgesamt sind.
Zusammenfassung: Was haben wir gelernt?
Ein wenig zusammengedampft lassen sich die Learnings für die Überarbeitung komplexer Benutzeroberflächen für die Industrie wie folgt auf den Punkt bringen:
- Kundennahe Mitarbeiter des Maschinenherstellers sind eine exzellente Wissensquelle um den Nutzer und den Nutzungskontext im Projekt zu verankern
(sofern kein Zugriff auf “echte” Nutzer besteht). - Phasen der persönlichen Zusammenarbeit (z.B. in Workshops) an einem Ort sind unerlässlich für das gegenseitige Verständnis.
- Ein Projektstart unter Verzicht auf User Research und Analyse hat seinen Preis (aber ist manchmal nicht zu vermeiden).
- Die Verteilung von Konzept- und Designleistungen auf mehrere Applikationen hat viele Nachteile, ist aber momentan bei komplexen Oberflächen mit vielen Interaktionen mangels Alternativen leider noch notwendig.
- Vorsicht vor der Festlegung auf nicht-skalierbare Interaktionselemente, (z.B. Buttonleisten mit einer festen Maximalanzahl an Schaltflächen) in frühen Phasen der Konzeption.
- Je mehr vom Konzept schon steht, desto mühsamer (und aufwendiger) werden Erweiterungen, das sollte insbesondere bei der Projektbudgetierung beachtet werden.
Habt ihr ähnliche Erfahrungen gemacht? Oder doch was ganz anderes erlebt? Gern könnt ihr uns einen Kommentar hinterlassen, wir freuen uns auf euer Feedback!
vielen dank für den interessanten artikel. stelle mir gerade die frage wieso adobe xd eine vollkatastrophe ist?
Hallo Marc,
zugegebenermaßen war der Begriff “Vollkatastrophe” ein wenig hart gewählt. Wir testen regelmäßig neue bzw. evaluieren bestehende Tools und schauen, was sich in unseren Workflow integrieren lässt. Bis dato konnten wir mit XD noch nicht die Ergebnisse in der Zeit erzielen, die wir mit dem beschriebenen Tool-Set erreichen konnten. Es scheitert meistens an kleinen Details, die sich dann lästig durchs ganze Projekt ziehen. Neben der Feature-Frage ist im Agenturgeschäft aber auch immer der Faktor “Zeit” im Sinne von Geschwindigkeit wichtig. Adobe XD hat uns hier noch nicht überzeugt.
XD hat nach dem großen 2018er Update eine Menge an Funktionalität gewonnen, allerdings ist das eher für die Bereiche Webseiten und Apps interessant. Wir bedienen mit unserem Industrie-Fokus eine ziemliche Nische was Interfaces angeht. Das ist alles sehr Technik getrieben, weil die Interfaces für Steuerungen von Maschinen i.d.R. viel weniger Gestaltungsfreiheiten bieten – verglichen mit Consumer-Produkten. Wir haben hier einfach andere Ansprüche und Anforderungen. Würden wir primär Webseiten und Apps bauen, wäre Adobe XD mittlerweile sicherlich ein heißer Kandidat.
Mit welchem Tool-Set setzt Du denn Deine Projekte um?
Interessanter Artikel! Gab mir einen schönen Einblick in die Arbeitsweise die ich sonst bei mir nicht habe, weil ich eher eine One-Man-Show abziehen muss.
Eine Frage habe ich allerdings, ihr schreibt folgendes: “Der Kunde konnte sich unsere Konzepte über einen Link zum Prototyp direkt anschauen und auch vor Ort noch einmal mit seinen Anwendern besprechen.”
Verstehe ich das richtig, dass ihr den Prototyp auf Servern von Axure hattet und der Kunde darauf zugegriffen hat? Oder wird dies alles komplett bei euch gehostet?
Aus Datenschutzgründen darf ich keine Prototypen irgendwo in der Cloud speichern, wie wird dies bei euch gehandhabt? Was sagen die Kunden dazu?
Hallo Martin,
ob wir den Dienst axshare nutzen können, hängt immer an einer individuellen Vereinbarung mit dem Auftraggeber. Hier hat jeder eigene IT-Richtlinien. Als Alternative kann der Prototyp als HTML exportiert werden und dann entweder auf einem eigenen Server gehostet werden, oder aber man versendet die Daten als Zip und der Auftraggeber schaut sich den Prototypen lokal an. Die HTML-Export Variante ist natürlich nicht ganz so komfortabel wie axshare.
Vielen Dank für die Übersicht! Mein Sohn wurde jetzt in einer Firma für Erodiertechnik angenommen und ich muss sagen, der Begriff hat mir überhaupt nichts gesagt. Daher ist es gut zu wissen, dass man bei diesem Verfahren Material von einem Werkstück abtragen lässt. Ich hoffe, diese Kenntnisse aus diesem Beitrag reichen aus, um Interesse an dem Job meines Kleinen zu zeigen.