November 2015

Band 30, Nummer 12

Cutting Edge – Bessere Architektur mit UX-gesteuertem Design

Von Dino Esposito | November 2015

Design und Entwicklung eines jeden Softwaresystems beginnen mit einem allerseits bekannten Schritt: der Erfassung von Anforderungen von Benutzern. Dies umfasst meist mehrere Besprechungen und Interviews mit Kunden und Fachbereichsexperten. Im Anschluss an die letzte Besprechung sollten nahezu alle Projektbeteiligten meinen, dass alle Details des System geklärt seien und die Entwicklung sicher gestartet werden könne. Niemand sollte daran zweifeln, dass das Endprodukt sich von dem unterscheide, was erläutert und verstanden wurde. Kunden sollten zufrieden sein und Systemarchitekten glauben, dass sie genau wissen, was sie tun.

In der Praxis zeigt sich jedoch, dass eine Vereinbarung abstrakter Anforderungen keine erfolgreiche Implementierung garantiert. Denn wenn Kunden den tatsächlichen Prototyp sehen, gefällt er ihnen meist nicht. Ganz gleich, was im Vorfeld alles besprochen wurde, scheint es so, als hätten Kunden und Entwickler unterschiedliche Vorstellungen vom Endprodukt. Entwickler erhalten Anforderungen und entwickeln die entsprechende Software. Doch dem Endprodukt fehlt oft das Wesentliche, das sich Benutzer wünschen.

Ich denke, dass Entwickler häufig zu sehr auf funktionelle Vollständigkeit abzielen und den Schwerpunkt nicht genug auf Geschäftsprozesse und die Bedürfnisse der Endbenutzer legen, die das System erfüllen muss. Während also funktionelle Aspekte von Geschäftsprozessen erfasst werden, ist die generelle Umsetzung selten so glänzend und reibungslos wie erwartet. In diesem Artikel stelle einen Designansatz vor, mit dem Systemarchitekten ihre Chancen steigern können, gleich beim ersten Versuch die richtige Lösung zu entwickeln. Ich nenne diesen Ansatz UX-gesteuertes Design.

Der Apfel, der mir auf den Kopf fiel

Sie haben bestimmt schon einmal von dem legendären Apfel gehört, der Sir Isaac Newton auf den Kopf fiel und ihn zur Formulierung des nach ihm benannten Gravitationsgesetzes führte. Vor Kurzem ist mir ein Apfel auf den Kopf gefallen und die Botschaft, die ich erhielt, war, dass das aufmerksame Erfassen von Benutzererwartungen und realer Prozesse mitunter das Entwickeln anderer Dinge erfordert. Was bedeutet, dass mehr als bloß eine Funktionsanalyse nötig ist.

Ein Kunde bat um die Entwicklung einer (in seinen Augen) einfachen und schnellen Webanwendung zur Unterstützung des Turnierplans eines Tennisturniers. Es gab nur eine User Story. Der Bediener gab den Namen des Spielers und die dazugehörige Position im Turnierplan an und erwartete anschließend, dass das System einen XML-Feed verfügbar macht, der den aktuellen Status des Turnierplans widerspiegelt. Vor meinem geistigen Entwicklerauge sah ich eine Datenbanktabelle, die die Daten enthalten sollte. Als Nächstes schwebte mir ein kurzes HTML-Formular mit zwei Textfeldern vor: eines zum Angeben des Spielernamens und ein zweites für die Position im Turnierplan. Interessanterweise war sich der Kunde nach Ende unseres Gesprächs sicher, über ein Tool zum Eingeben von Spielern und Positionen und XML-Code zu dessen Unterstützung zu verfügen. Doch als der Entwickler (ich) dem Kunden die Lösung präsentierte und er sie in einer Simulation eines tatsächlichen Turnierplans testete, funktionierte sie nicht. Der Kunde wollte nämlich eigentlich etwas viel Komplexeres. Abbildung 1 veranschaulicht die unterschiedlichen Sichtweisen von Entwicklern und Kunden. Im Hintergrund sehen Sie, was sich der Kunde wünscht, und die Darstellung des realen Prozesses. Der gelbe Kasten mit dem schwarzen Rand ist die kostengünstige Lösung, die genauso klein wie ungeeignet ist.

Abbildung 1: Der Unterschied, zwischen dem was gewünscht und verstanden wird

Letztendlich ist die Benutzererfahrung (User Experience, UX) wesentlich mehr als bloß Gesten und Grafiken, sondern die Erfahrung, die der Benutzer macht, wenn er mit Ihrer Software interagiert. Zum Entwerfen einer effektiven UX sollten Sie sich als Softwarearchitekt und -entwickler mehr auf Aufgaben und Geschäftsprozesse als auf Datenmodelle und Speicherung konzentrieren. Zum Verstehen von Aufgaben müssen Sie sich mehr mit dem Fachgebiet, den Benutzern und ihren Aktivitäten in diesem Fachgebiet vertraut machen. UX-gesteuertes Design ist der Ansatz dafür, jedoch ohne allgemeine Empfehlung zum Einsatz von Drahtmodellen und Modelltools. Beim einem einfachen Szenario bin ich so vorgegangen, was aber nicht funktioniert hat, da der Kunde in seiner Vorstellung dachte, die Software wäre zu einfach und den Aufwand der umfassenden Entwicklung des realen Prozesses nicht wert. Als Softwarearchitekt habe ich vom Kunden nicht die richtige Botschaft zur Wichtigkeit der Aufgabe erhalten. Wählen Sie also nie eine Billiglösung, sondern stets eine effektive Lösung. Ich muss zugeben, dass meine vorgeschlagene Originallösung (die „Billiglösung“) in einem realistischen Szenario unmöglich einsetzbar war. Mein Fehler war, der Analyse des Kunden voll und ganz blind zu vertrauen und nicht mehr über die tatsächlichen Geschäftsprozesse erfahren zu haben.

Zum UX-gesteuerten Design gehören verschiedene architekturbezogene Vorgaben, bei deren Erfüllung das Risiko minimiert werden kann, wichtige geschäftliche Aspekte zu übersehen, die im Zusammenhang mit Aufgaben und der Benutzeroberfläche stehen. Interessanterweise können mit dem UX-gesteuerten Design einige der bewährten Praktiken bei der derzeitigen Softwareentwicklung verändert werden.

Hierarchisches Design

Aus Sicht der Funktionalität können Sie ein funktionsfähiges System unabhängig davon erfolgreich entwickeln, ob Sie mit dem Design unten (z. B. beim Persistenzmodell) oder oben (z. B. auf der Darstellungsschicht und beim Ansichtsmodell) beginnen. Aus UX-Perspektive können Sie nur Erfolg haben, wenn Sie Ihr Design bei den Darstellungs- und Ansichtsmodellen beginnen und alles andere, einschließlich des Back-End-Stapels, von dort aus entwickeln.

Viele von uns wissen aus der Praxis, dass wenn Sie ein aus Entitäten und Beziehungen bestehendes Persistenzmodell vor sich haben, das auf Benutzeranforderungen basiert, die Arbeit fast getan ist. Dieses Modell fungiert dann als Modell des gesamten Systems, wird im ganzen Stapel durchweg verwendet und nur gelegentlich durch UI-spezifische Datenübertragungsobjekte ergänzt. In diesem Kontext erfolgen das Entwerfen und Entwickeln des Systems von unten nach oben, und die Darstellungsschicht gibt unweigerlich die persistenzorientierte Vision des Datenmodells wieder. Wir nennen dies häufig CRUD (Create, Read, Update, Delete, dt. Erstellen, Lesen, Aktualisieren, Löschen) und reduzieren beliebige System auf CRUD mit lediglich ein wenig mehr an differenzierter Geschäftslogik. Dabei schenken wir der Darstellungsschicht nur wenig Aufmerksamkeit. Mitunter ist eine UI, die zu nahe am Datenmodell ist, gut für die Benutzer, manchmal aber auch nicht. Das zweite Szenario regt zusätzliche Verhandlungen an, nachdem der erste funktionierende Prototyp geliefert wurde. Sie ersinnen zunächst ein System ganz von vorn, um an einer bestimmten Stelle herauszufinden, dass die äußerste Schicht geändert werden muss, um andere Benutzerprozesse zu reflektieren. Dies unterscheidet sich in keinster Weise vom Versuch, eckige Klötzchen durch runde Löcher zu drücken. Aus diesem Grund sehe ich darin die größte Herausforderung bei vielen Softwareprojekten.

Was können wir tun, um den Prozess zu verbessern? Meiner Meinung ist die Antwort die Rückkehr zu einem Design von oben nach unten, der auf der Darstellungsschicht beginnt und bei dem alle weiteren Entscheidungs- und Implementierungsdetails von den Darstellungsanforderungen abhängen. Um dies zu realisieren, ist eine Art von Projekt vor dem Projekt oder vorgelagerter Schritt erforderlich, um sicherzustellen, dass ein umfassendes Verständnis der UX erlangt wird, bevor mit der Entwicklung des Back-Ends des Systems fortgefahren wird.

Die UX-gesteuerte Methodik

Ich habe von UX-Experten erfahren, dass Anforderungen besser im Rahmen eines evidenzbasierten Gesprächs aktiv generiert als aus Interviews passiv abgeleitet werden. Einige Softwarearchitekten und -analysten bleiben in der Anforderungsermittlungsphase meist zu passiv, was bewirkt, dass Benutzer die Priorität beliebiger Features heruntersetzen, damit die Software so schnell wie möglich zur Verfügung steht. Doch dann beschweren sie sich, dass das System kaum etwas taugt, sobald sie es dann haben. Gleichzeitig hilft es nicht, wenn man in der Anforderungsermittlungsphase mit der Entschuldigung zu passiv bleibt, dass "dies ist, was der Kunde will", ohne wirklich genau zu wissen, was entwickelt werden soll. Heute schreiben wir Software zum Abbilden von Teilen der realen Welt, anstatt zu modellieren, was uns als Wunsch des Kunden aufgetragen wurde. Das Nichterfassen struktureller Aspekte des Geschäfts ist eine kostspielige Todsünde.

Gängige Praxis ist das Verwenden von Drahtmodellen, um eine Vereinbarung hinsichtlich der erwarteten Benutzeroberfläche zu treffen. Benutzer Drahtmodelle schrittweise durchgehen zu lassen, um Rückmeldungen zu generieren, führt nicht besonders weit. Drahtmodelle haben durchaus ihre Berechtigung, aber ohne Storyboards nur einen begrenzten Nutzen.

Nur sehr wenige Aufgaben lassen sich komplett auf einem einzelnen Bildschirm erledigen, die Sie in einem Drahtmodell effektiv zusammenfassen können. Das bloße Betrachten des Drahtmodells eines Bildschirms ist ggf. nicht ausreichend, um mögliche Engpässe für die Prozessimplementierung auszumachen. Die Verkettung von Bildschirmen in einem Storyboard ist eine viel bessere Idee. In dieser Hinsicht ist die größte Herausforderung das Finden der Tools zum Erstellen von Storyboards. Der Markt für diese Tools wächst rapide. Abbildung 2 zeigt einige Tools zum raschen Erstellen eines Prototyps der Darstellungsschicht von Anwendungen auf eine Weise, die Benutzern eine konkrete Vorstellung des Prozesses verschafft, der entworfen wird.

Abbildung 2: Tools zum schnellen und effektiven Erstellen von UI-Prototypen

Darüber hinaus bieten aktuelle Versionen von Microsoft Visio und PowerPoint (insbesondere in Kombination mit Visual Studio Ultimate) ebenfalls Funktionen zum Erstellen von Prototypen. Alle Tools in Abbildung 2 bieten eine funktionsreiche Plattform zum Erstellen von Drahtmodellen und mitunter die Fähigkeit, anklickbare Modelle zu erzeugen und diese in funktionsfähige Prototypen umzuwandeln.

Die am weitesten entwickelten dieser Tools bieten frühzeitiges Feedback und, was noch wichtiger ist, lassen die Einbindung des Kunden früh im Designprozess und vor dem Schreiben der ersten Codezeile zu. Falls Sie feststellen, dass Sie wichtige Darstellungsaspekte vergessen haben, wenn schon das halbe Back-End fertig ist, fangen Sie entweder wieder von vorn an oder nehmen Anpassungen vor.

Gleichzeitig reicht das einfache Auslagern der Darstellungsschicht an ein Team von UX-Experten nicht aus. Die Darstellungsschicht ist mittlerweile der wichtigste Teil eines Systems und muss das Ergebnis der gemeinsamen Anstrengungen von Lösungsentwicklern, UX-Architekten und Kunden sein. Dies muss der erste Schritt sein, und idealerweise fahren Sie erst fort, nachdem der Kunde die Darstellung abgezeichnet hat. Hinsichtlich der Methodik ist es annehmbar, die Wasserfallperspektive einzunehmen und das gesamte Darstellungsdesign vor der Programmierung zu vervollständigen, um agiler zu sein und die Darstellungsanalyse als Schritt im Sprint hinzuzufügen (siehe Abbildung 3).

Abbildung 3: Die drei Schritte beim UX-gesteuerten Design der Architektur

Entwerfen des Rests der Lösung

Sobald Sie die Darstellungsschicht für die gesamte Lösung oder nur den aktuellen Sprint fertig gestellt haben, verfügen Sie über eine Gruppe von Bildschirmen, z. B. Formulare, mit einem überlegt definierten Datenfluss (d. h. Eingabe und Ausgabe jedes Formulars sind klar). Aus Architektursicht bedeutet dies, dass Sie das Eingabemodell jeder Aktion und das Ansichtsmodell kennen, das zum Ausfüllen des Formulars oder Erzeugen der erwarteten Antwort erforderlich ist. Die Darstellungsschicht verbindet sich mit dem Back-End über eine zwischengeschaltete Dienstebene, die konzeptuell mit dem von Martin Fowler (bit.ly/1JnFk8i) definierten Dienstebenenmuster sowie der Anwendungsebene in der Schichtarchitektur des Domain-Driven Designs (DDD) übereinstimmt. Es ist das logische Segment des Systems, in das Sie die Anwendungsfälle und beliebige Orchestrierungen von Aufgaben implementieren, die diese erfordern. Die Anwendungsschicht ist der oberste Teil des Back-Ends und kommuniziert direkt mit der Darstellungsschicht. Die Anwendungsschicht besteht aus direkten Endpunkten für jede der Aktionen, die von der Darstellung ausgelöst werden können. Diese Endpunkte dienen zum Empfangen und Zurückgeben der Eingaben und Ansichtsmodelle, die aus Drahtmodellen resultieren.

Ist dieser Ansatz wirklich effektiv? Und ob! Wenn Ihre Drahtmodellanalyse gründlich und korrekt ist, implementieren Sie nur die Prozesse, die der Kunde will, und sind gleich auf der richtigen Spur. Sie verringern erheblich die Wahrscheinlichkeit der Neuverhandlung von Änderungen, nachdem Sie das erste Release bzw. die erste Demo bereitgestellt haben. Dies spart Zeit und Geld. Wie in Abbildung 4 gezeigt, ist dies für Entwickler sinnbildlich, wie Benutzer Software betrachten. Und das UX-gesteuerte Design führt zum Entwerfen von Software auf diese Weise.

Abbildung 4: Das Wesen von Software aus Sicht der Benutzer

Zusammenfassung

Im Vergleich damit, wie wir Software derzeit entwerfen, also ausgehend vom Datenmodell, legt das UX-gesteuerte Design mehr Wert auf Aufgaben und Darstellung als auf Datenmodelle. Nicht, dass Datenmodelle und Persistenz unwichtig sind, aber ihre Rollen sind für Aufgaben sind eher funktioneller Art als umgekehrt. Ob es Ihnen gefällt oder nicht, sind wir damit näher daran, was die reale Welt von uns verlangt. Beim UX-gesteuerten Design geht es mehr um Methodik als um Technologie oder Muster. Dieses Design verlangt keine bestimmten Technologien oder Muster, wenngleich es sehr gut mit CQRS und Event-Sourcing harmoniert. Wenn Sie mit Ihrem aktuellen Prozess bei der Anwendungsentwicklung nicht zufrieden sind, denken Sie mit dem UX-gesteuerten Designansatz einmal quer.

Dino Esposito ist Mitautor von "Microsoft .NET: Architecting Applications for the Enterprise" (Microsoft Press, 2014) und "Programming ASP.NET MVC 5" (Microsoft Press, 2014). Esposito ist Technical Evangelist für die Microsoft .NET Framework- und Android-Plattformen bei JetBrains und spricht häufig auf Branchenveranstaltungen weltweit. Auf software2cents.wordpress.com und auf Twitter (@despos) lässt er uns wissen, welche Softwarevision er verfolgt.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Jon Arne Saeteras