Wie wir bei sipgate Design-Patterns erschaffen

An einem Ort, an dem viele kreative Menschen zusammen arbeiten, entstehen tolle Dinge. Hier bei sipgate leben wir agile Arbeit. Dadurch ist die Geschwindigkeit, in der diese Dinge entstehen, oft so rasant, dass wir die Entwicklung kaum alle erfassen können.

Mit unserer neuen Pattern-Library haben wir 2017 den Grundstein für das einheitliche Erscheinungsbild all unserer Webauftritte geschaffen. Ein System, welches auf Konsequenz und Zweckmäßigkeit beruht.

Wie bringen wir nun diese zwei Welten überein: Ein agiles Umfeld, welches sich selbst weiterentwickelt, und eine Pattern-Library die eine Konsequenz benötigt, damit diese als einheitliches Design-System fungieren kann?

Die Entstehung eines Patterns
Essenziell ist, dass der Zweck eines Design-Patterns klar ist. Ein Pattern ohne Zweck ist ein Puzzleteil ohne Gesamtbild. Nachdem unsere Pattern-Library auf diesem Prinzip beruht, ergibt sich zu Beginn, bevor ein neues Design-Pattern angedacht wird, die Frage: Welchen Zweck verfolgen wir?

Wenn es diesen Zweck bereits gibt, erzeugen wir kein neues Design-Pattern, sondern verwenden ein Bestehendes oder arbeiten Eines auf. So wird der Pflegeaufwand an vorhandenen Patterns klein gehalten und die Konsequenz in der Verwendung wird gestärkt.

Es gibt aber Fälle in denen es noch kein Pattern für einen Anwendungsfall gibt. Diese Fälle entstehen oft spontan. Zum Beispiel arbeitet ein anderes Team an einer Kampagne und benötigt dazu ein Pattern, welches Videos abspielen kann.
Dann planen wir ein Wireframing ein. Oft können wir das Erscheinungsbild eines vorhandenen Patterns verwenden. Jedoch dient das Wireframing nicht der Gestaltungs-Findung, sondern der Festlegung der Informationsarchitektur und zeigt dabei frühzeitig Problematiken auf.

Das Wireframing hat den Zweck, dass unser Team eine einheitliche Vorstellung von Benutzerführung und Informationsarchitektur bekommt. Bei komplizierten Patterns oder Prozessen setzen wir uns auch an das visuelle Design. Das geschieht meist im Pairing und kann durchaus, wie auch das Wireframing, Nicht-Designer, z.B. Entwickler und andere Teams, mit einbeziehen. So werden technische Hürden bereits frühzeitig erkannt und können direkt vermieden oder gelöst werden.

User-Tests
Unsere Pattern-Library wird von uns als das internes Produkt angesehen. Wir nennen es Holodeck. Wir nehmen uns Zeit für unsere Kunden, und reden mit ihm, iterieren über Lösungen und beziehen ihn während des gesamten Prozesses mit ein, sodass wir sichergehen können auch wirklich ihre Probleme zu lösen. User-Tests führen wir oft als Umfragen durch, um herauszufinden wo Probleme bei der jetzigen Umsetzung liegen oder auch, um fehlende Ansatzpunkte für noch unangedachte Usecases zu liefern. Es gibt durchaus auch aufwändigere Tests, die ganze Prozesse mit Beobachtungen und Prozess-Dokumentationen beinhalten. Wie zum Beispiel: Wie wir das CMS für uns gefunden haben (link folgt).

User-Tests werden dann notwendig, wenn der “Impact”, die Außenwirkung, eines Patterns sehr groß ist; der Prozess komplex ist oder es aber einen Großteil unserer internen Kunden betrifft. Für die meisten Patterns im Redesign-Prozess holen wir uns einfach direktes Feedback.

Vom Design zum Pattern
Wenn das Pattern bereit ist, in Code gegossen und in die Pattern-Library zu ziehen, bauen wir ein Pattern mit SASS, HTML, PHP und ES6. Wir erstellen Screenshots und eine kurze Dokumentation, die wir auf GitHub und sipgate.design veröffentlichen. So haben alle Benutzer die Möglichkeit sich den Zweck und die Verwendung des Patterns anzuschauen, egal ob Entwickler, Kundenbetreuer oder Marketing Mensch.

Wichtig ist uns die Offenheit und Transparenz sowie eine simple Lösung an die Hand zu bringen. Kein System ist perfekt und unsere Pattern-Library entwickelt sich stetig weiter, genau wie die Dokumentationsform selbst.

Noch ein Boxenstop
Bevor das Pattern nun aber fertig ist, gibt es eine Review der Story (wir arbeiten nach SCRUM). Hier gucken wir noch einmal, ob wir auch nichts vergessen und alle Anforderungen erfüllt haben.

Bei uns ist das kein großer Prozess, sondern eher ein 5-Minuten auf der Couch sitzen Task. Denn wir haben zuvor durch das Herunterbrechen in viele kleine gemeinsam erarbeitete Aufgaben, große Fehlerquellen minimiert. Dadurch, dass wir im Pair arbeiten haben wir immer mindestens zwei Blicke auf eine Lösung und das; durchaus aus verschiedenen Fachrichtungen. Unsere Definition of Done hilft uns dann dabei möglichst schnell alle Punkte ab zu haken und unser tägliches Standup und der ständige Einbezug unseres Product-Owner, unterstützt ebenso unser Alignment.

Danach wird das Pattern im Holodeck live gestellt. Das passiert mit einem Git-push und einem Klick. Klingt alles doch recht viel: Ist es aber gar nicht. Viele kleine unkomplizierte Schritte führen so zu einem besseren Ergebnis.

Nichts ist in Stein gemeißelt
All diese Prozess-Schritte bedeuten nicht, dass ein Pattern nicht ein Update erhält, Änderungen zu Gunsten von Usability gemacht werden oder gar das Pattern irgendwann doch weggeschmissen wird, weil der Zweck nicht mehr gegeben ist. Wie sich die Anforderungen an das Holodeck ändern, so ändern sich auch unsere Patterns. Wichtig ist, den Zweck und die Konsequenz einzuhalten. Es ist ein sich ewig entwickelndes System. Und das ist gut so, denn um aktuellen Trends und Anforderungen gerecht zu werden, bedarf es eines fluiden Design-Systems, das wir ununterbrochen weiterentwickeln.

Ich hoffe euch hat der kurze Einblick in die Entstehung eines Design-Patterns gefallen und ihr habt einen Eindruck von unserer Arbeitsweise erhalten.