Überspringen zu Hauptinhalt

Ein Blick hinter die Kulissen: So entsteht MADDOX

Wichtige Erfolgsfaktoren für einen Workshop sind:

  • eine kreative Umgebung mit viel freier Wandfläche, Klebezetteln (Design Thinking lässt grüßen ^^)
  • Teilnehmende mit unterschiedlichen fachlichen Hintergründen (Produktion und Verpackungsmaschinen, UX-Design, Softwareentwicklung, Psychologie etc.)
  • Mate, Kaffee, Obst und Naschkram

MADDOX ist für die Nutzenden das, was sie vor sich auf dem Bildschirm sehen. Vom unsichtbaren Technologie-Stack auf dem Server im Hintergrund haben wir bereits verschiedentlich berichtet (MADDOX Systemarchitektur, NATS als Message Broker). In diesem Post soll es daher um die Entstehung dessen gehen, was die Nutzung von MADDOX definiert: Funktionen, Abläufe, Interaktionselemente wie Eingabefelder und Buttons, sowie die visuelle Gestaltung. Die Entwicklung dieser Kernmerkmale wird meist unter dem Begriff UX-Design (UX für User eXperience) zusammengefasst. Am Anfang steht als „Zieldefinition“ meist nur eine grobe Idee aus der Praxis für eine neue Funktion; bspw. sollen Maschinenstopps in Form von Ereignissen in MADDOX erfasst, bearbeitet und protokolliert werden oder Kommentare sollen gelöscht werden können. An dieser Stelle gibt es meist den „Klingt logisch, machen wir; wie schwer kann das schon sein?!“-Moment. Inzwischen haben wir gelernt, dass dieser Schein nicht nur manchmal, sondern fast immer trügt.

Die wirklichen Herausforderungen offenbaren sich meist, wenn man die Idee aus Sicht der Nutzenden in allen Details und unter allen möglichen Randbedingungen durchspielt. Dann passen bestimmte Informationen oder Ansichten plötzlich nicht mehr auf einmal auf einen Tablet-Bildschirm; in bestimmten Sonderfällen erhält man undefinierte Zustände oder ein falscher Klick des Nutzenden hat irreversible Folgen. Gerade letzteres geht gerade auf Touch-Geräten schnell; so dass wir eine entsprechende interne Entwurfsrichtlinie haben, die liebevoll „Wurstfingerkompatibilität“ genannt wird.

Anschließend entwickeln wir bei komplexeren Funktionen zunächst Mock-Ups mit Adobe XD, dich sich als Klick-Dummy auch online bereitstellen lassen. Dadurch war es beispielsweise möglich, die inzwischen implementierte SAP-Schnittstelle nach der Klärung der Anforderungen dem Kunden binnen weniger Tage als testbares Mock-Up zur Verfügung zu stellen und weiteres Feedback für die Entwicklung zu sammeln.

Die folgende Übersicht zeigt einen Ausschnitt der vielen Mock-Up Ansichten, die in den letzten drei Jahren zusammen mit den UX-Designern bei unserem Partner Tyclipso erstellt wurden.

Erst wenn wir und die Ansprechpartnerinnen und Ansprechpartner bei unseren Kunden mit dem Design, den Workflows und der Usability zufrieden sind, beginnt der eigentliche Entwicklungsprozess. In wöchentlichen Meetings werden die Anforderungen in kleinere Tickets zerlegt und der Front- Backend-Entwicklung zugeordnet. Insgesamt sind so in den letzten drei Jahren über 2.600 Tickets entstanden, von denen derzeit noch 210 offen sind. Über einen Meilenstein- und Release-Plan folgt die zeitliche Einordnung. Dabei stellen wir uns immer wieder aufs Neue dem Spagat zwischen der flexiblen, prioritätsgetriebenen Berücksichtigung von Kundenbedarfen (eine umfangreiche Änderung an der SAP-Schnittstelle konnten wir bspw. in anderthalb Wochen umsetzen), einer planbaren Entwicklungsroadmap und der Planungsunsicherheit der Implementierungsaufwände.

Mit den neuen Funktionen werden zugleich auch automatisierte Tests für Front- und Backend implementiert, die die allermeisten Bugs bereits während der Entwicklung oder bei späteren Code-Änderungen automatisch abfangen. Zusätzlich wird jedes Release umfangreich manuell getestet (teils auf Testsystemen direkt in der Kunden-IT) und erst dann ausgerollt.

Dieser Beitrag hat 0 Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

An den Anfang scrollen