Chantal

Seit ich Software entwickle, hat mich auch immer schon die Gestaltung der Schnittstellen – sei es graphische Oberflächen, APIs oder auch Voice User Interfaces – interessiert. All das ist Kommunikation. Auch die DesignerInnen von Duscharmaturen kommunizieren mit den Menschen, die später diese Duschen benutzen (und sich dabei vielleicht ärgern, weil sie zuerst mit der falschen Temperatur geduscht haben). Die Schnittstelle aus Sicht der EndbenutzerInnen zu betrachten und zu überlegen, ob die Bedienung verständlich, in sich schlüssig ist, hat mich immer wieder in Situationen gebracht, in denen ich entweder Kollegen, Projektleiter oder auch Kunden nach dem eigentlichen Zweck der Anwendung gefragt habe. Durchaus auch mit der Folge, dass ich – wenn möglich – die Schnittstelle/Anwendung aufgrund der Antworten angepasst habe. Ich wollte zunehmend früher in Entscheidungen einbezogen werden, um nicht unverständliche, unnötig komplizierte Schnittstellen implementieren zu müssen. Über Lars habe ich – noch in meiner vorherigen Firma – erfahren, dass die blu jemanden für Requirements Engineering sucht. Da die blu für mich ein bekannter Hafen war, hatte ich Vertrauen, dass ich nicht gleich ausgelacht und vor die Tür gesetzt werde, wenn ich mich bewerbe, um nicht nur das zu machen, was ich schon kann, sondern auch auf eine Rolle, die ich so noch nicht offiziell gemacht hatte. Was mich letztendlich sehr bestärkt hat, war die äußerst positive Rückmeldung von damaligen Kunden, denen ich meinen Wechsel Richtung Anforderungsermittlung und Konzeption mitgeteilt habe. Sie haben sich dafür bedankt, dass ich das damalige Projekt konzeptionell so gut begleitet hatte.

Die Essenz der Realität zu finden, die wir mit der Software abbilden: so einfach wie möglich und dabei doch korrekt.

Zum einen beim Verständnis, dass „Benutzeroberfläche“ und „Usability“ weder Luxus noch Kosmetik sind. Es ist die Haut der Anwendungen, die wir bauen (und das umfasst alle Systemgrenzen, auch APIs oder E-Mail-Versand oder PDF-Generierung). Es gibt kein System ohne Systemgrenze: das heißt, wenn wir kein Geld und keine Zeit für ein Bedienkonzept haben, dann bedeutet das nicht, dass wir keine Möglichkeit der Bedienung haben werden, sondern dass wir uns keine tiefergehenden Gedanken gemacht haben, wie die Bedienung in jeglicher Hinsicht (inklusive Fehlerbehandlung, Validierung, Systemgrenze etc.) aussehen soll. Das führt logischerweise dazu, dass das jede beteiligte EntwicklerIn so umsetzt, wie es ihr richtig erscheint. Zum anderen beim Missverständnis, dass das Bedienkonzept durch eine Reihe von Wireframes ausreichend beschrieben ist. Die Wireframes sind der notwendige Rahmen, aber der wirkliche Realitätscheck erfolgt, wenn man die Relationen zwischen Anzeigen und Bedienelementen beschreibt und die Interaktionsmöglichkeiten beleuchtet, die auf Basis dieser Wireframes möglich sein sollen.

Es ist einfacher zu beschreiben, welche Arten von Aufgaben anfallen können: - Calls mit Kunden, um o bestimmte Business Prozesse durchzusprechen und durchzugehen, wie die Software diese Prozesse unterstützen könnte o bestimmte Prozesse in der Software zu besprechen, ggf. Änderungen aufzunehmen, die das Verhalten justieren o Bugs identifizieren - E-Mails an Kunden ausformulieren, um Details zu klären - In Miro scribbeln: das reicht von Diagrammen, um Prozesse (in der SW oder im Business) zu visualisieren bis hin zu rudimentären Wireframes, je nach Bedarf - User Stories in Confluence aufschreiben und schon mal überlegen, wie sie technisch umgesetzt werden könnten. Das hilft mir dabei, kleine Arbeitspakete zu definieren, für die ich Jira-Tickets anlege. Ich versuche, dem Team keine technischen Vorgaben zu machen, aber meine eigene Erfahrung als Entwicklerin hilft mir schon, wenn ich diese Arbeitspakete festlege - Sofern im Projekt enthalten (wünschenswert): Absprachen mit UX/UI-Design - Schätz-/ und Planungsrunden mit dem Team, in denen ich beschreibe, was zu einem Arbeitspaket gehört, und auf welcher Business Logik das Ganze basiert - Calls mit Entwicklern oder QA wenn es Rückfragen gibt - Entwicklung – das mache ich auch noch, und gern - Code Reviews - Jeden zweiten Mittwoch um 11 Uhr haben wir unseren „UX-Team-Call“, in dem wir uns Anwendungen anschauen, die gerade von jemandem bei uns umgesetzt werden, oder die uns positiv oder negativ ins Auge gefallen sind. Wer sich dafür interessiert, kann sich gerne bei mir melden. - Reguläre Calls etc.

Ein/eine von Kunden-Seite gestellte Product Ownerin mit: Einer Vision, Durchblick und langfristigem Interesse

Sie müssen nicht wissen, was sie wollen sollen. Sie sollen mir erklären, wie sie aktuell einen Business Prozess bewältigen, und ich kann ihnen dann Vorschläge machen, wie die potenzielle Software sie unterstützen könnte.

Mein erstes Projekt als Requirements Engineer: Liprotect (Kunde Linde) ist mir in positiver Erinnerung. Am Anfang gab es zwar Schwierigkeiten in vieler Hinsicht – weil ich nicht wusste, wie ich die Tickets vorbereiten musste, damit sie im Team verstanden und geschätzt werden können, und weil ich Entscheidungen für die Kunden selbständig getroffen habe, und sie sich übergangen gefühlt haben. Nach einiger Zeit hat sich das aber eingespielt. Die schöne Sache in diesem Projekt war für mich, als die beiden Product Owner mit ihrer kleinen Gruppe von End Usern einen Workshop (intern) veranstaltet und uns das Ergebnis vorgelegt haben: ein grobes Bedienkonzept in Form von Fotos von Whiteboard-Zeichnungen für einen neuen Bereich der Applikation. Johann (Stuke) und Lars haben daraus ein tolles UI-Konzept gemacht, wir haben es umgesetzt, und die Product Owner waren mit dem Ergebnis sehr zufrieden.

Die Meta-Ebene: der gute Umgang untereinander, vor allem auch mit den Chefs und Vorgesetzten. Die Möglichkeit, grundsätzlich mit allen reden zu können (ja, auch schon anders erlebt…).

Die Fähigkeit, sich in die Situation anderer hineinversetzen zu können, um zu verstehen, wo die Aufmerksamkeit der Person in bestimmten Situationen ist. So kann man überlegen, wie eine Anwendung gestaltet werden sollte, damit sie dieser Person in einer bestimmten Situation entgegenkommen kann. Das betrifft nicht nur die geistige Ebene (also was weiß die Person in diesem Moment über Daten, über die Software etc.) sondern auch ganz physikalische Dinge wie: ist das Licht an, steht die Person im Freien und es regnet, hat sie Handschuhe oder Schutzbrille an? Nicht die Software steht im Mittelpunkt, sondern die Person, die sie bedient.

Dass ich Fehler machen darf, offen und sachlich dafür kritisiert werde - und es danach nochmal versuchen und zeigen kann, dass ich daraus gelernt habe.