In der aktuellen ACM communications Ausgabe findet ihr ein Interview zum Thema UX in agilen Projekten: ACM Case Study: UX Design and Agile: A Natural Fit? Im Interview: Julian Gosper (UX-Designer) und Jean-Luc Agathos (Software Architekt), die über die Entwicklung des SAP BusinessObjects Explorers (BOx) berichten.
Da ich selbst gerade ein agiles Projekt „durchlitten“ habe, hat mich natürlich brennend interessiert, wie so etwas beim Riesen SAP abläuft. Ein Halbsatz relativ weit am Anfang des Artikels, legt schnell die Vermutung nahe, dass agile Projekte auch hier nicht anders ablaufen als sonst wo:
Although the Polestar team didn’t have the budget to conduct contextual inquiry […]
Projekte gehen also auch bei SAP an den Start, ohne eine Analyse des Umfelds, in dem das Produkt eingesetzt wird und ohne Anforderungsanalyse bei den späteren Nutzern. OK, niemand, der jemals mit einer SAP Oberfläche gearbeitet hat, wird etwas anderes erwartet haben… ;-).
Ich bin trotzdem neugierig, ob ich irgendwelche Informationen darüber finden kann, wie das Produkt beim Endkunden ankommt. Die Menge an Material ist dünn. Die einzige Rezension zum Thema, abgesehen von einer Menge offiziellem Werbematerial, gibt es von mayato.com:
http://www.mayato.com/downloads/Fact_Sheet_BOBJ_Explorer.pdf
„Der BOx selbst ist ein insgesamt gelungenes Werkzeug, dessen Integration in die „klassische“ SAP-Welt trotz kleinerer Brüche, z.B. bei Berechtigungen, Sprachabhängigkeit und Deployment/ Transport, grundsätzlich gut umgesetzt wurde. Allerdings kommen die Vorteile des BOx primär nur in solchen Anwendungsszenarien zum Tragen, in denen große Datenmengen auf relativ einfache Analysebedarfe treffen.[…] Darüber hinaus darf auch nicht übersehen werden, dass die Bereitstellung von Daten für den BOx, insbesondere bei Verwendung der Data Services, weiterhin spezielles Entwickler- bzw. Beraterwissen erfordert. Die Forderung nach unabhängig von der IT-Abteilung realisierbaren Adhoc-Analysen ist somit auch mit diesem Tool nicht uneingeschränkt erfüllbar.“
Eine euphorische Produktbeschreibung hört sich wohl anders an… Spannend wäre es, Meinungen aus erster Hand, direkt von echten Nutzern zu bekommen. Falls es da draußen also Menschen gibt, die mit dem Produkt schon gearbeitet haben, wäre es spannend zu hören, was ihre Erfahrungen sind!
Abgesehen davon finden sich im Interview noch einige spannende Aussagen zu grundlegenden Fragen des User Experience Designs in agilen Projekten:
Wann sollten UX Designer im agilen Projekt einsteigen?
„If you have a good set of user stories that have been agreed upon by the executive members of the project and include clear definitions of the associated workflows and use cases, then the Agile iterative process can begin. […] On the basis of that, both UX interaction designers and the development team should have enough to get going in parallel.“
Dem möchte ich noch hinzufügen, dass UX-Designer den Productowner bereits bei der Definition der User Stories mit Analysen, wie Usability Tests, Fokusgruppen, Interviews oder Umfragen unterstützen sollten.
UX Design bedeutet mehr als nur Oberflächen entwerfen!
„Collaborating closely with development at that stage was appealing in this particular case, however, because some of the directions we were taking with the user interface were likely to have serious back-end implications—for example, the ability of the application to return and reevaluate facets and visualizations with each click.“
„[…] is that Julian [the UX designer] essentially ended up taking on both roles. He acted as a program manager because he knew what the user stories were and how he wanted each of them to be handled in terms of product functionality. He also had a clear idea of how he wanted all of that to be exposed in the UI and how he wanted end users ultimately to be able to interact with the system. That greatly simplified things from my perspective because I had only one source I had to turn to for direction.“
Wie sieht ein Spezifikationsdokument für Oberflächen in agilen Projekten aus?
„Sometimes a set of wireframes supporting a particular use case seemed to be good enough, since most of what I wanted to communicate could be inferred from them. But there were other times when it would have been helpful for me to break things down into more granular specifications.“
Fazit: in so einem zielgerichteten und geordneten agilen Projekt möchte ich auch mal mitmachen. Vielleicht ergibt sich irgendwann ja mal die Chance… ;-)