Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

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 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 inte­griert.

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­ein­flos­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 wer­den.

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.

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

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üh­len.

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­t­es­ten und gege­be­nen­falls stö­rende Abläufe oder feh­lende Funktionen erken­nen.

Interaktionsdesign per Klick Dummy
Beispiel für einen Click Dummy, um durch eine hier­ar­chi­sche Struktur zu navi­gie­ren.

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 jus­tie­ren.

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:

Feindesign für Details
Feindesign, um ein Gefühl zu erhal­ten, wie sich die Macros in Confluence inte­grie­ren.

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ät­zen.

Benutzeroberflächen entwickeln 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 (wink)

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 konn­ten.

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 hat­ten.

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 konn­ten.

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 regis­triert.

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.

Related Posts

Pin It on Pinterest