Für die Entwicklung der itemis-Produkte verfolgen wir einen Usability-Engineering-Ansatz, der natürlich auch Prototyping beinhaltet. Um den Prozess des Prototypings in unserer Produktentwicklung zu verbessern, haben wir als mögliches neues Tool UXPin evaluiert. In diesem Artikel möchte ich meine gesammelten Erfahrungen mit UXPin mit euch teilen.
Warum UXPin?
In der Vergangenheit haben wir bei itemis mit Axure gearbeitet, ein oft genutztes und von seiner Funktion her ausgereiftes Prototyping-Tool. Warum also der Wechsel zu UXPin?
UXPin bietet einige Möglichkeiten, die Axure nicht bietet. So kann man mit mehreren Personen parallel am Prototypen arbeiten, ohne dass entsprechende Teile des Prototypen für andere Nutzer gesperrt werden müssen. Des Weiteren kann jeder, der den entsprechenden Link hat, ohne Account auf den Prototypen zugreifen und direkt im Prototypen Kommentare hinterlassen. Die Zusammenarbeit und Kommunikation mit dem Entwicklungsteam wird so deutlich vereinfacht. Außerdem können Spezifikationen direkt im Tool zu dem entsprechenden Element erzeugt werden. Automatisch mitgeliefert werden hier Styles, wie genutzte Schriftarten, Größen, Farben etc. Auch auf diese Spezifikation, das sogenannte “Design System”, können die Entwickler einfach über einen Link zugreifen.
Für den Produktentwicklungsprozess bei itemis klangen diese Möglichkeiten des Tools sehr vielversprechend, weshalb wir uns entschieden, UXPin näher zu evaluieren.
Konkret habe ich dazu in den letzten Wochen mehrere Prototypen mit verschiedenen Problemstellen gebaut und mich dabei intensiv mit UXPin auseinandergesetzt. So habe ich einen detaillierten Prototypen für eine neue Perspektive unseres Produkts YAKINDU Traceability (Information: YAKINDU Traceability Is Now itemis ANALYZE) erstellt. Außerdem habe ich einen Prototypen für eine neue Welcome Page für den Model Viewer gebaut und animiert, um diesen mit Nutzern zu testen. Insbesondere in Bezug auf den Model Viewer arbeiten wir gerade an einem Tastatur-Interaktionskonzept, weshalb ich mir auch die Möglichkeiten der Tastatur-Interaktionen in UXPin im Detail angesehen habe.
UXPin – Das Tool im Überblick
UXPin ist ein Prototyping-Tool, das direkt im Browser nutzbar ist. Es muss nicht installiert werden. Nach der Registrierung können verschiedene Projekte angelegt und bearbeitet werden.
Über Edit design gelangt man in den Bereich, in dem der Entwurf eines Prototypen stattfindet. Dabei ist der mittlere Bereich die Arbeitsfläche, auf der die Elemente per Drag and Drop angeordnet werden können. Am linken Rand befinden sich die Elemente, die zum Aufbau des Prototypen genutzt werden können. In den UXPin-eigenen Libraries stehen grundlegende Elemente, sowie einige spezifische Elemente z. B. für iOS oder Android zur Verfügung. Außerdem kann man selber Elemente erstellen und als UI-Pattern in einer eigenen Library speichern. Auch Farben, Typographie und Bilder können gespeichert werden. Diese Library ist ebenfalls links am Rand zur weiteren Verwendung zu finden.
Abbildung 1: Die Arbeitsfläche von UXPin
Am rechten Rand befindet sich der Bereich, über den die Elemente formatiert werden. So kann man dort Eigenschaften wie beispielsweise Farbe, Schrift, Größe oder Position bestimmen und außerdem in diesem Bereich auch die Interaktionen definieren. Elemente können etwa abhängig von Aktionen wie Klicken verborgen, gezeigt, eingefärbt, in ihrer Größe geändert oder verschoben werden.
Drückt man den Play Button oben rechts über der Arbeitsfläche, öffnet sich die Simulation des Prototypen. Auf diese Weise kann man direkt ausprobieren, ob alles so aussieht wie gewollt und ob die Interaktionen das tun, was sie sollen.
Vorteile von UXPin
Die große Stärke von UXPin ist, dass das Team zur selben Zeit am gleichen Projekt arbeiten kann. Hierfür müssen nicht einzelne Seiten für andere Teammitglieder gesperrt werden – wie etwa bei Axure – sondern alle können parallel direkt am selben Entwurf arbeiten. Indem den beteiligten Stakeholdern ein Link zur Simulation des Prototyps geschickt wird, können sie am Entstehungsprozess teilhaben und direkt im Prototypen Kommentare hinterlassen und die Spezifikationen der Elemente einsehen. Das Abstimmen und Überarbeiten ist so leichter zu handhaben.
Abbildung 2: Kommentarfunktion in UXPin
Auch das Erstellen von Prototypen an sich ist insgesamt weitestgehend intuitiv. Elemente können einfach aus der linken Seite per Drag and Drop auf der Fläche angeordnet werden. Des Weiteren wird beim Definieren einer Interaktion das Element, das geändert werden soll, gehighlightet. Dadurch ist die Auswahl des Elements einfach, selbst wenn der entsprechende Name mehrfach vorkommt.
Sehr vielversprechend ist die Möglichkeit, eigene Libraries anzulegen. In dieser können einmal erstellte Elemente oder ausgesuchte Farben abgespeichert, benannt und wieder verwendet werden, um eine Konsistenz über den gesamten Prototyp hinweg zu gewährleisten. Dies ist insbesondere wichtig, wenn mit mehreren Usability Engineers am Prototypen gearbeitet wird. Das erstellte Design System steht nicht nur im einzelnen Projekt, für das es erstellt wurde, zur Verfügung, sondern kann auch in anderen Projekten verwendet werden. Konsistent zu arbeiten, ist daher mit UXPin kein Problem.
Die im Design System abgelegten Elemente stehen in einer Webseite zur Verfügung. Hier können über eine einfache Edit-Funktion Texte, wie Richtlinien, Erläuterungen und Detailbeschreibungen hinzugefügt werden. So entsteht eine leicht handhabbare UI-Spezifikation, was einen der größten Vorteile von UXPin darstellt.
Positiv ist zudem auch die UXPin Community aufgefallen, die eine große Anzahl an leicht verständlichen Tutorials bietet. Der Menüpunkt “Help & Tutorials” im Burger-Menü des Arbeitsbereiches führt direkt dorthin.
Abbildung 3: Ein Design System vereinfacht das Einhalten von Konsistenz und das Erstellen von Spezifikationen
Nachteile von UXPin
Leider hat UXPin auch einige Schwächen. Der schwerwiegendste Nachteil ist meiner Meinung nach, dass es keine konditionalen Interaktionen gibt, wie wir das von Axure gewohnt sind. So kann folgendes zum Beispiel nicht definiert werden: Wenn das Element X sichtbar ist, soll der Text Y den Wert “sichtbar” haben. Solche Interaktionen lassen sich zum Teil nur schwergängig nachbauen. So kann man etwa, wenn das Element X sichtbar wird, gleichzeitig eine Interaktion definieren, die den Text Y verbirgt und einen neuen Text Z mit dem Inhalt “sichtbar” anzeigt, der vorher verborgen an der selben Stelle angeordnet wurde. Andere Situationen lassen sich jedoch gar nicht umsetzen. Zum Beispiel kann man nicht festlegen, dass, wenn ein Eingabefeld einen bestimmten Wert hat, ein Button aktiv werden soll. Somit können keine Validierungen von Formularen erstellt werden. Auch simple Interaktionen, wie etwa dass bei einer bestimmten Aktion ein Eingabefeld geleert werden soll, stehen nicht zur Verfügung. Auf Anfrage beim Support von UXPin wurde uns zwar gesagt, dass das Thema auf der Roadmap steht, aber nicht für wann.
Wie eingangs beschrieben, war zudem ein Ziel, einen Prototyp für ein Tastatur-Interaktionskonzept zu erstellen. Hier hat sich leider gezeigt, dass man zwar Interaktionen basierend auf einem Tastendruck ausführen kann, allerdings keine Tastaturkombinationen möglich sind. Dies ist ein großer Nachteil, denn Shortcuts bestehen im Normalfall nicht aus nur einer Taste, sondern aus mehreren. Für unseren Anwendungsfall lässt sich UXPin hier nicht einsetzen.
Ebenfalls für den Prototypen des Model Viewer ist es nötig, dass auf einer Seite verschiedene Inhalte angezeigt werden. Dies lässt sich mit Multistate-Elementen umsetzen. Über die Interaktionen lässt sich dann ein Wechsel des States festlegen. Beides ist leicht umzusetzen. Allerdings ist die Bearbeitung der States frustrierend: Per Doppelklick aktiviert man das Multistate-Element und kann den State auswählen, den man bearbeiten möchte. Klickt man jedoch während der Bearbeitung auf ein anderes Element, setzt sich das Multistate-Element zurück in den Default State und ist nicht mehr aktiviert. Dies passiert sehr oft versehentlich. Zum Beispiel klicke ich oft woanders hin, um zu sehen, wie ein Element aussieht, ohne dass es selektiert ist. Dadurch wird die Bearbeitung erheblich erschwert. Da States ein essentielles Konzept für die Erstellung von Prototypen ist, stellt dies einen erheblichen Nachteil von UXPin dar.
Auch weitere generelle Probleme sind aufgefallen. In der Simulation funktioniert beispielsweise die Interaktion “Hover” manchmal nicht. Auch das Umbenennen von Elementen ist schwergängig. Des Weiteren ist nie der ganze Arbeitsbereich zu sehen. Man muss immer zoomen oder scrollen. Bei dem Element “Text” ist es zudem sehr schwierig, einzelne Zeilen zu selektieren, um sie anders zu formatieren. Einzelne Worte auszuwählen, ist nicht möglich. Diese Schwachpunkte scheinen für sich genommen erst einmal nicht allzu kritisch. Insgesamt verlangsamen sie das Arbeiten jedoch enorm und führen zu einer schlechten User Experience.
Gesamteindruck
Trotz der großartigen Möglichkeit, gemeinsam an Entwürfen zu arbeiten, ein Design System anzulegen und Kommentare zu hinterlassen, kann ich das Tool UXPin nur bedingt empfehlen. Die Bedienung ist zwar weitestgehend intuitiv, aber es ist schon oft vorgekommen, dass ich genervt war, wenn ich einfache Interaktionen nur schwer oder gar nicht umsetzen konnte. Das Fehlen der konditionalen Interaktionen ist hierbei ein wirklich großer Nachteil. Das Nachbauen – wo möglich – ist zeitintensiv und kostet Nerven. Viele nötige Bedingungen sind nicht umsetzbar. Hier weißt UXPin große Lücken auf. Da es aber immer wieder Neuerungen gibt – so haben die Entwickler des Tools im letzten Jahr insgesamt 21 neuen Versionen herausgebracht – hoffe ich, dass insbesondere konditionale Interaktionen in Zukunft ermöglicht werden.
Kommentare