UX-Design bei der Entwicklung des neuen SharePoint Online Connectors

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

Doch wel­che Rolle spielt dabei ein UX-Designer oder - wie von Bitkom vor kur­zem neu defi­niert - ein „Digital Designer“? Er beglei­tet den Entstehungsprozess eines digi­ta­len Werkzeuges für den Kunden von der Analyse über die Entwicklung bis zum Test, immer mit dem Fokus auf ein posi­ti­ves Nutzererlebnis.

Des Pudels Kern

Ganz am Anfang wurde eine Analyse gestar­tet, um das bis­he­rige Produkt unter die Lupe zu neh­men. Dabei ist eine Sammlung mit den bis­he­ri­gen Funktionen und deren Bewertung zur Benutzbarkeit ent­stan­den sowie eine Übersicht über die Kundenwünsche und -pro­bleme. Dadurch hat­ten wir am Ende der Analysephase ein kla­res Bild, wel­che Probleme unsere neue Version lösen sollte.

Auch wenn nicht alle gewünsch­ten Funktionen in die erste Version hin­e­inflos­sen, konnte anhand der Übersicht aus der Analyse eine erste Roadmap mit den wich­tigs­ten Funktionen ange­legt wer­den. Mit dem Wissen zum Gesamtbild konnte zudem ein gutes und brei­tes Fundament bei der Konzeption gelegt werden.

Evolution im Kleinen

Auf Basis der Analyse wur­den nun die Anwendungsfälle und Anforderungen erstellt und bewusst ein­fach gehal­ten, damit sich das Team nicht im Detail ver­liert. Auch des­we­gen wur­den die Diskussionen anhand von Wireframes (ers­ten, ein­fach gehal­te­nen Prototypen) geführt, sodass der Fokus der Diskussionen auf der Informationsarchitektur und nicht auf der Ästhetik lag.

Diskussionen im gan­zen Team waren dabei sehr hilf­reich. Es wurde schnell und trans­pa­rent ange­merkt, dass die Schnittstellen bestimmte Informationen nicht her­ge­ben und so konnte noch bevor eine erste Codezeile geschrie­ben wurde, die Visualisierung ange­passt wer­den. Aber auch hin­sicht­lich Begriffsdefinitionen und Beschriftungen konn­ten die Experten im Team aus bei­den Bereichen (Confluence und SharePoint) schnell Feedback geben, damit sich die jewei­li­gen Benutzer in ihren Begriffswelten ange­spro­chen fühlen.

Um das Interaktionsdesign zu tes­ten, wur­den „Click Dummies“ erstellt, die eine Verlinkung von Wireframes dar­stel­len. Dabei konn­ten wir den Ablauf gan­zer Anwendungsfälle durch­tes­ten und gege­be­nen­falls stö­rende Abläufe oder feh­lende Funktionen erkennen.

Dies war beson­ders wich­tig für Benutzeroberflächenelemente, wel­che wir für unsere Zwecke neu ent­wi­ckelt haben. So konn­ten wir diese Werkzeuge mit wenig Aufwand schon mit poten­zi­el­len Benutzern tes­ten und in der Konzeptionsphase ite­ra­tiv Ideen kre­ieren, ver­wer­fen oder justieren.

Wenn wir unsi­cher waren, wie der Wireframe in der Confluence- oder SharePoint-Umgebung aus­se­hen würde, haben wir die­sen dann in den Farbtopf getaucht:

Eine Herausforderung war, dass wir uns an den bei­den Ökosystemen Confluence und SharePoint im Look & Feel ori­en­tie­ren muss­ten, damit unsere Lösung nicht als Fremdkörper erschei­nen und der Entwicklungsaufwand nicht über­stie­gen würde. Die bei­den Design-Systeme AUI auf Confluence- und Office UI Fabric auf der SharePoint-Seite dien­ten immer als Kompass bei der Entwicklung der Benutzeroberfläche für den „SharePoint Online Connector for Confluence“. Der UX-Designer, wel­cher auch Expertise aus der Softwareentwicklung besitzt, konnte das Wissen über die mög­li­chen Barrikaden in bei­den Systemen erken­nen und die Aufwände bei der spä­te­ren Umsetzung gut abschätzen.

Benutzeroberflächen ent­wi­ckeln nach Zahlen

Das Backend wurde par­al­lel schon gut vor­be­rei­tet und nun konnte den Konzepten, Wireframes und Feindesigns end­lich Leben ein­ge­haucht wer­den. Ein Designer in sei­ner ursprüng­li­chen Rolle würde sich nun ande­ren Themen wid­men, doch durch die breite inhalt­li­che Aufstellung der Rolle, konnte er die Umsetzung wei­ter beglei­ten und viele Benutzeroberflächen per HTML/CSS/JavaScript selbst umset­zen. Dies führte dazu, dass in der Umsetzung noch Feinheiten jus­tiert und aus­ge­las­sene Stellen im Konzept agil nach­ge­zo­gen wer­den konn­ten. „Hier gibt es lei­der keine Möglichkeit, dies so umzu­set­zen“, hatte man auf der SharePoint Seite im Office 365 Umfeld häu­fig gehört. Dabei musste schnell eine Lösung gefun­den wer­den, um die Entwicklung nicht zu ver­zö­gern. Da war es gut, dass der UX-Designer in der Doppelrolle als Designer und Entwickler schnell Alternativen ent­wi­ckeln konnte. Der Ehrgeiz sowie das „peni­ble“ Auge für Details erhöht zudem die Qualität bei der Umsetzung der eige­nen Designs, da es ihm sonst unru­hige Nächte besche­ren würde 

Durch unse­ren agi­len Softwareprozess wur­den im Sprint Review die Ergebnisse aus dem vor­he­ri­gen Sprint vor­ge­stellt und auch ein kur­zes UX-Review mit dem gesam­ten Team durch­ge­führt. Das brachte den Vorteil, dass viele Probleme, die erst durch die häu­fige Nutzung der Entwickler auf­ge­fal­len sind, im nächs­ten Sprint schnell ange­gan­gen wer­den konnten.

Die ers­ten Versionen wur­den auch ver­schie­de­nen ande­ren Teams bei Communardo vor­ge­stellt, das Feedback bewer­tet und eine Lösung dafür schnell gefun­den. Trotz, dass diese klei­nen Usability-Tests par­al­lel zur Entwicklung durch­ge­führt wur­den, hat es die Umsetzung nicht behin­dert, da wir min­des­tens einen Sprint lang erst­mal gesam­melt hatten.

Das erste Mal

Dann war es soweit, die erste Version mit dem geplan­ten vol­len Funktionsumfang stand. Nun wurde ein letz­tes Mal die Lösung auf Herz und Nieren geprüft. Dabei wur­den zum einen den Kunden aus der Analyse-Phase eine Beta-Version bereit­ge­stellt und geschaut, wie zufrie­den sie mit der neuen Version sind. Zum ande­ren wur­den intern bei Communardo zehn Personen aus den unter­schied­lichs­ten Bereichen, jung bis alt aus­ge­sucht, um die Beta-Version mit ihnen zu tes­ten. Dabei war es wich­tig, dass es ihre erste Benutzung mit dem neuen „SharePoint Online Connector for Confluence“ war, damit ihre Erwartungen und ers­ten Versuche doku­men­tiert wer­den konnten.

Die Erstnutzer muss­ten nach ein paar Hintergrundfragen gezielt Aufgaben erle­di­gen und wur­den dabei vom durch­füh­ren­den UX-Designer und der mit­lau­fen­den Aufzeichnung beob­ach­tet. Jede Rauchwolke über dem Kopf, jedes „Aaaha“ und Zögern, wurde dabei registriert.

Die Ergebnisse haben uns im Team über­rascht. Es wur­den bei der Auswertung ganze 32 Verbesserungen fest­ge­stellt. Diese wur­den dann nach der Häufigkeit und dem Frustpotenzial prio­ri­siert. Die schwer­wie­gen­den Probleme, wel­che bei der Benutzung bei allen Personen auf­tra­ten, wur­den dann sofort gelöst.

Fazit

Ein UX-Designer agiert wäh­rend des Entwicklungsprozesses ganz­heit­lich als "Anwalt des Benutzers". Er sollte von Beginn an einen roten Faden am Kern das Problemes und der Nutzerbedürfnisse kno­ten und mit die­sen von Meilenstein zu Meilenstein gehen.

Auch mit dem Hintergrund, dass bei einer sol­chen kom­ple­xen Lösung sehr viel poten­zi­el­ler Supportaufwand ent­steht, ist es wich­tig, die Benutzerfreundlichkeit der Lösung stän­dig - von der Analyse über die Entwicklung bis hin zum Test - im Blick zu haben. Die Anwender soll­ten unser Produkt gern benut­zen, im bes­ten Fall Spaß bei der Benutzung haben, denn das Ziel der Lösung „SharePoint Connector for Confluence“ ist das Verlinken von Inhalten aus den jewei­li­gen Systemen. Wenn die Benutzer die Lösung nicht gern ver­wen­den, dann hin­dert dies die Integration der bei­den Systeme und es ent­ste­hen im schlimms­ten Fall Wissensinseln.