Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
+49 (0) 351/8 33 82-0

UX-Design bei der Entwicklung des neuen SharePoint Online Connectors

Am Beispiel der Entstehung des SharePoint Online Connectors stellen wir in diesem Beitrag die Rolle eines UX-Designer im Software-Entwicklungsprozess vor.

Anfang letzten Jahres haben wir mit der Produktentwicklung für eine Neuauflage des „SharePoint Connector for Confluence“ begonnen und dabei die Rolle „UX-Designer“ von Anfang an integriert.

Doch welche Rolle spielt dabei ein UX-Designer oder – wie von Bitkom vor kurzem neu definiert – ein „Digital Designer“? Er begleitet den Entstehungsprozess eines digitalen Werkzeuges für den Kunden von der Analyse über die Entwicklung bis zum Test, immer mit dem Fokus auf ein positives Nutzererlebnis.

Des Pudels Kern

Ganz am Anfang wurde eine Analyse gestartet, um das bisherige Produkt unter die Lupe zu nehmen. Dabei ist eine Sammlung mit den bisherigen Funktionen und deren Bewertung zur Benutzbarkeit entstanden sowie eine Übersicht über die Kundenwünsche und -probleme. Dadurch hatten wir am Ende der Analysephase ein klares Bild, welche Probleme unsere neue Version lösen sollte.

Auch wenn nicht alle gewünschten Funktionen in die erste Version hineinflossen, konnte anhand der Übersicht aus der Analyse eine erste Roadmap mit den wichtigsten Funktionen angelegt werden. Mit dem Wissen zum Gesamtbild konnte zudem ein gutes und breites Fundament bei der Konzeption gelegt werden.

Evolution im Kleinen

Auf Basis der Analyse wurden nun die Anwendungsfälle und Anforderungen erstellt und bewusst einfach gehalten, damit sich das Team nicht im Detail verliert. Auch deswegen wurden die Diskussionen anhand von Wireframes (ersten, einfach gehaltenen Prototypen) geführt, sodass der Fokus der Diskussionen auf der Informationsarchitektur und nicht auf der Ästhetik lag.

Erster Wireframe zum Thema SharePoint List
Erster Wireframe zum Thema SharePoint List

Diskussionen im ganzen Team waren dabei sehr hilfreich. Es wurde schnell und transparent angemerkt, dass die Schnittstellen bestimmte Informationen nicht hergeben und so konnte noch bevor eine erste Codezeile geschrieben wurde, die Visualisierung angepasst werden. Aber auch hinsichtlich Begriffsdefinitionen und Beschriftungen konnten die Experten im Team aus beiden Bereichen (Confluence und SharePoint) schnell Feedback geben, damit sich die jeweiligen Benutzer in ihren Begriffswelten angesprochen fühlen.

Um das Interaktionsdesign zu testen, wurden „Click Dummies“ erstellt, die eine Verlinkung von Wireframes darstellen. Dabei konnten wir den Ablauf ganzer Anwendungsfälle durchtesten und gegebenenfalls störende Abläufe oder fehlende Funktionen erkennen.

Interaktionsdesign per Klick Dummy
Beispiel für einen Click Dummy, um durch eine hierarchische Struktur zu navigieren.

Dies war besonders wichtig für Benutzeroberflächenelemente, welche wir für unsere Zwecke neu entwickelt haben. So konnten wir diese Werkzeuge mit wenig Aufwand schon mit potenziellen Benutzern testen und in der Konzeptionsphase iterativ Ideen kreieren, verwerfen oder justieren.

Wenn wir unsicher waren, wie der Wireframe in der Confluence- oder SharePoint-Umgebung aussehen würde, haben wir diesen dann in den Farbtopf getaucht:

Feindesign für Details
Feindesign, um ein Gefühl zu erhalten, wie sich die Macros in Confluence integrieren.

Eine Herausforderung war, dass wir uns an den beiden Ökosystemen Confluence und SharePoint im Look & Feel orientieren mussten, damit unsere Lösung nicht als Fremdkörper erscheinen und der Entwicklungsaufwand nicht überstiegen würde. Die beiden Design-Systeme AUI auf Confluence- und Office UI Fabric auf der SharePoint-Seite dienten immer als Kompass bei der Entwicklung der Benutzeroberfläche für den „SharePoint Online Connector for Confluence“. Der UX-Designer, welcher auch Expertise aus der Softwareentwicklung besitzt, konnte das Wissen über die möglichen Barrikaden in beiden Systemen erkennen und die Aufwände bei der späteren Umsetzung gut abschätzen.

Benutzeroberflächen entwickeln nach Zahlen

Das Backend wurde parallel schon gut vorbereitet und nun konnte den Konzepten, Wireframes und Feindesigns endlich Leben eingehaucht werden. Ein Designer in seiner ursprünglichen Rolle würde sich nun anderen Themen widmen, doch durch die breite inhaltliche Aufstellung der Rolle, konnte er die Umsetzung weiter begleiten und viele Benutzeroberflächen per HTML/CSS/JavaScript selbst umsetzen. Dies führte dazu, dass in der Umsetzung noch Feinheiten justiert und ausgelassene Stellen im Konzept agil nachgezogen werden konnten. „Hier gibt es leider keine Möglichkeit, dies so umzusetzen“, hatte man auf der SharePoint Seite im Office 365 Umfeld häufig gehört. Dabei musste schnell eine Lösung gefunden werden, um die Entwicklung nicht zu verzögern. Da war es gut, dass der UX-Designer in der Doppelrolle als Designer und Entwickler schnell Alternativen entwickeln konnte. Der Ehrgeiz sowie das „penible“ Auge für Details erhöht zudem die Qualität bei der Umsetzung der eigenen Designs, da es ihm sonst unruhige Nächte bescheren würde (wink)

Durch unseren agilen Softwareprozess wurden im Sprint Review die Ergebnisse aus dem vorherigen Sprint vorgestellt und auch ein kurzes UX-Review mit dem gesamten Team durchgeführt. Das brachte den Vorteil, dass viele Probleme, die erst durch die häufige Nutzung der Entwickler aufgefallen sind, im nächsten Sprint schnell angegangen werden konnten.

Die ersten Versionen wurden auch verschiedenen anderen Teams bei Communardo vorgestellt, das Feedback bewertet und eine Lösung dafür schnell gefunden. Trotz, dass diese kleinen Usability-Tests parallel zur Entwicklung durchgeführt wurden, hat es die Umsetzung nicht behindert, da wir mindestens einen Sprint lang erstmal gesammelt hatten.

Das erste Mal

Dann war es soweit, die erste Version mit dem geplanten vollen Funktionsumfang stand. Nun wurde ein letztes Mal die Lösung auf Herz und Nieren geprüft. Dabei wurden zum einen den Kunden aus der Analyse-Phase eine Beta-Version bereitgestellt und geschaut, wie zufrieden sie mit der neuen Version sind. Zum anderen wurden intern bei Communardo zehn Personen aus den unterschiedlichsten Bereichen, jung bis alt ausgesucht, um die Beta-Version mit ihnen zu testen. Dabei war es wichtig, dass es ihre erste Benutzung mit dem neuen „SharePoint Online Connector for Confluence“ war, damit ihre Erwartungen und ersten Versuche dokumentiert werden konnten.

Die Erstnutzer mussten nach ein paar Hintergrundfragen gezielt Aufgaben erledigen und wurden dabei vom durchführenden UX-Designer und der mitlaufenden Aufzeichnung beobachtet. Jede Rauchwolke über dem Kopf, jedes „Aaaha“ und Zögern, wurde dabei registriert.

Die Ergebnisse haben uns im Team überrascht. Es wurden bei der Auswertung ganze 32 Verbesserungen festgestellt. Diese wurden dann nach der Häufigkeit und dem Frustpotenzial priorisiert. Die schwerwiegenden Probleme, welche bei der Benutzung bei allen Personen auftraten, wurden dann sofort gelöst.

Fazit

Ein UX-Designer agiert während des Entwicklungsprozesses ganzheitlich als „Anwalt des Benutzers“. Er sollte von Beginn an einen roten Faden am Kern das Problemes und der Nutzerbedürfnisse knoten und mit diesen von Meilenstein zu Meilenstein gehen.

Auch mit dem Hintergrund, dass bei einer solchen komplexen Lösung sehr viel potenzieller Supportaufwand entsteht, ist es wichtig, die Benutzerfreundlichkeit der Lösung ständig – von der Analyse über die Entwicklung bis hin zum Test – im Blick zu haben. Die Anwender sollten unser Produkt gern benutzen, im besten Fall Spaß bei der Benutzung haben, denn das Ziel der Lösung „SharePoint Connector for Confluence“ ist das Verlinken von Inhalten aus den jeweiligen Systemen. Wenn die Benutzer die Lösung nicht gern verwenden, dann hindert dies die Integration der beiden Systeme und es entstehen im schlimmsten Fall Wissensinseln.

Kommentar hinterlassen