Design für das nächste Jahrzehnt – Teil 1:Produktdesign-Prozesse im agilen Kontext

Digitale Produkte in jederzeit nachvollziehbarer Qualität und mit nachhaltiger Geschwindigkeit entwickeln – dafür stehen agile Vorgehensmodelle. Doch reicht es, dass die Software-Entwickler jetzt „Scrum machen“, um am Markt erfolgreicher zu sein? Viele Unternehmen gehen auf Nummer sicher und rollen agile Methodiken vom Marketing bis zur Personalabteilung aus. Bei aller Begeisterung scheint dabei ein Bereich stiefmütterlich behandelt zu werden: Das Design. In der Entwicklung hoch gehaltene Prinzipien von Lean und Agile werden im Designprozess häufig nicht umgesetzt: Design erfolgt „upfront“ statt iterativ inkrementell, es ist wasteful statt lean, individuell statt kollaborativ, weisungsgebunden statt (team-)verantwortlich.

Wie funktioniert das Design digitaler Produkte, wenn die Philosophien von Lean und Agile verbunden mit Ansätzen aus Design Thinking und User Centered Design auf den gesamten Entstehungsprozess angewandt werden? Oder anders formuliert: Welche Konzepte sind hilfreich für Organisationen, die ihre Design- und Umsetzungsprozesse konsequent auf Nutzerzentrierung und Produkterfolg ausrichten wollen – oder müssen?

Dreiteilige Artikelserie zum Stand moderner Designprozesse

Mit dem vorliegenden Artikel starte ich eine dreiteilige Reihe, die den Stand moderner UX-Designprozesse aus verschiedenen Betrachtungswinkeln diskutiert: Frei von Patentrezepten, als Angebot, die eigene Organisation hinsichtlich verschiedener Aspekte und Konzepte zu hinterfragen.

Jeder Teil der Artikelserie beschäftigt sich mit einer anderen Betrachtungsebene:

  • (Produkt-)Management & Strategie stellt Designprozesse in den Gesamtzusammenhang von Management und Strategie des Unternehmens.
  • Prozesse & Rollen beschäftigt sich mit den Prozessen und Rollen, die an der Entstehung und Evaluierung von Produktdesigns beteiligt sind.
  • Tooling zeigt Trends im Bereich Tooling und Infrastruktur auf, die die vorgestellten Ansätze der anderen Betrachtungsebenen unterstützen.

Der vorliegende erste Artikel betrachtet zunächst Prozesse und Rollen. Von dieser „mittleren“ Betrachtungsebene zu starten, erscheint aus verschiedenen Gründen sinnvoll:

  • Prozesse und Rollen sind es, die unsere tägliche Arbeit am stärksten prägen: Als wirksame Unterstützung für die Ziele, die wir erreichen wollen, oder im schlimmsten Fall als Hindernis, gegen das wir täglich ankämpfen.
  • Das Tooling lässt sich nur im Kontext von Prozessen und Rollen betrachten und bewerten. Gute Tools unterstützen meine Abläufe und die Art, wie in meiner Organisation Aufgaben auf Personen aufgeteilt werden.
  • Die Management- und Strategieebene schließlich hebt den Blick auf die Gesamtorganisation und auf Grundprinzipien des Produktmanagements. Um dabei nicht „abzuheben“, ist es hilfreich, sich vorher mit den Leistungen und Bedürfnissen des Produktentwicklungsteams zu beschäftigen.

Prozesse und Rollen

Die Zuspitzung der Software-Krise1 in den 90er Jahre des letzten Jahrhunderts führte 2001 mit dem agilen Manifest zu einem fundamentalen Umdenken in der Art, wie Software geplant und produziert wird. Das ist jetzt 17 Jahre her. Und doch dauert der Wechsel vom Wasserfallmodell der 70er zum heute vorherrschenden agilen Vorgehensmodell „Scrum“ noch immer an. Auch 2018 feiern Unternehmen noch die erfolgreiche Einführung agiler Methoden. Wichtige Begleitkonzepte wie DevOps sind sogar noch deutlich jünger, ihre Verbreitung und effektiver Einsatz sind noch deutlich weniger etabliert.

Gibt es eine ähnliche Krise in der Gestaltung von Designprozessen? Betrachtet man die Entwicklung digitaler Produkte der letzten 20 Jahre, sticht eine Innovation hervor, die die Reichweite digitaler Produkte enorm erhöhte, aber gleichzeitig auch die Qualitätsansprüche an „funktionierendes“ Design erheblich ansteigen ließ. Gemeint ist der rasante Siegeszug des Smartphones, der nicht nur eine gesellschaftliche und wirtschaftliche Umwälzung von enormer Tragweite auslöste, sondern auch die traditionellen Vorgehensweisen im Designprozess in eine tiefe Krise stürzte.

Die durch die mobile Revolution und andere Entwicklungen (Cloud-IT, Startups etc.) beschleunigte Digitalisierung von Produkten und Services ließ UX Design branchenübergreifend zur strategischen Komponente werden – auch für solche Unternehmen, die ihren Markenkern bisher in ganz anderen Kompetenzen verorteten2.

Eine These dieser Artikelserie ist, dass die „Design-Krise“ mit der Software-Krise der 90er vergleichbar ist. Wie damals gibt es Ansätze zur Überwindung: Vordenker haben Bücher geschrieben (dazu später mehr), Unternehmen haben entsprechende Konzepte erfolgreich etabliert. Und doch begegnen vielen von uns in Unternehmen immer noch Kulturartefakte aus der Ära vor dem Launch des iPhones (2007 war das).

Wenn die Lösung vorgegeben ist: Building the product right

Bei der Entwicklung eines neuen Produktes steht eine Organisation immer vor zwei grundsätzlichen Herausforderungen:

  1. Wie muss mein Produkt gestaltet sein, damit es am Markt erfolgreich sein kann? („Building the right product“)
  2. Wie kann ich dafür sorgen, dass ich dieses Produkt in der notwendigen Qualität erstelle und anbiete? („Building the product right“)

Bei der ersten Herausforderung spielt das Management eine erhebliche Rolle. Es muss sich die Frage stellen, wie es den Auftrag für die Produktentwicklung so aufsetzt und begleitet, dass das Produktteam die Frage nach dem richtigen Produkt optimal beantworten kann. Da das Management im Spiel ist, möchte ich für diesen Punkt auf den zweiten Artikel verweisen, der sich ausführlich mit Management- und Strategiefragen beschäftigt.

Um nichts vorwegzunehmen, nehmen wir der Einfachheit halber an, dass das Management bereits definiert hat, wie das Produkt funktionieren soll – übrigens ein immer noch übliches Vorgehen:

Es ist Montagmorgen. Das Management hat uns ein Briefing übergeben. Das Briefing definiert, welches Feature oder welchen Service wir als Nächstes entwickeln sollen. Idealerweise haben wir mit dem Management dokumentiert, auf welchen Annahmen (und Risiken) das Briefing basiert und wir haben klare Vorgaben, welche geschäftlichen Ziele wir mit dieser Investition erreichen sollen.

Es geht jetzt also im wesentlichen darum, das Produkt/Feature „richtig“ zu entwerfen (und umzusetzen). Als moderne Organisation sind wir von den agilen Prinzipien überzeugt und wollen diese entsprechend konsequent im Projekt umsetzen.

Agile heißt Selbstorganisation und gemeinsame Verantwortung

Anmerkung: Im Artikel spreche ich vereinfachend nur von Designern und Entwicklern. Tatsächlich sind in modernen Produkt- und Entwicklungsteams viele spezialisierte Rollen beteiligt. Die beiden Begriffe sollen daher stellvertretend für alle Rollen stehen, die schwerpunktmäßig auf die Gestaltung des Nutzungserlebnisses („Designer“) bzw. die technische Umsetzung („Entwickler“) ausgerichtet sind.

Ein zentrales Konzept agiler Ansätze ist der Fokus auf das Team: Agile Teams verantworten gemeinsam die Arbeitsergebnisse, sind cross-funktional – also so aufgestellt, dass sie alle anfallenden Aufgaben erledigen können – und setzen bei der Zusammenarbeit den Fokus auf Kommunikation statt Dokumentation.

Das sind dann idealerweise so aus:

Foto: Quino Al auf Unsplash

Gilt das auch für die Designanteile des Produktentwicklungsprozesses? Für viele Designer (User Researcher, UX Manager etc.) fühlt sich der Scrum-Prozess häufig eher so an:

Designer sind häufig nur „zu Besuch“ und werfen im schlimmsten Fall fertige Konzepte über den Zaun. Sie nehmen nicht am Daily, am Sprint Planning oder der Retrospektive teil. Sie konzipieren im stillen Kämmerlein und haben wenig informellen Austausch mit den Kollegen, die ihre Designs umsetzen sollen. Ihre Arbeit ist häufig zu Ende, wenn sie ihre Designs übergeben: Die Umsetzung erleben sie nicht mehr mit. Weder beratend, wenn das Team auf technische Restriktionen trifft noch als Kontrollinstanz, wenn es um die Umsetzungsqualität geht. Und erst recht erreicht sie kein Feedback über die Wirkung auf den Nutzer.

Je nach Produkt oder Marktposition ist die Integration des Designers in das Entwicklungsteam immer noch wenig verbreitet. Was passiert, wenn Design und Technik sich nicht in enger Zusammenarbeit um ein stimmiges Nutzungserlebnis bemühen, hat sicher jeder von uns schon erlebt:

  • Das Smartphone mit den „Killer-Features“, die sich im Alltag als viel zu umständlich oder wenig nützlich erweisen.
  • Der schicke Online-Shop, der auf dem Handy unbenutzbar langsam ist.
  • Die Service-App der Bank, deren verschiedene Bereiche sich alle völlig unterschiedlich bedienen lassen.
  • Die Ticket-App der Verkehrsbetriebe, die jeden Tag wieder die gleichen überflüssigen Fragen stellt, obwohl ich doch jeden Tag die gleiche Strecke fahre.

Die enge Zusammenarbeit zwischen Designern und Entwicklern hat dagegen viele Vorteile für das Produkt:

  • Das Team gewinnt ein besseres Verständnis von den Nutzern und den zu lösenden Problemen durch gemeinsame Research- und Analyse-Maßnahmen (z. B. Nutzerinterviews oder Benutzungstests)
  • Mehr und bessere Lösungsideen (durch gemeinsame Ideengenerierung)
  • Frühe Hinweise auf Probleme der Machbarkeit
  • Gelegenheiten zur Kostenreduktion durch Optimierung des technischen Aufwands
  • Besseres beiderseitiges Verständnis (persönlich und fachlich)

Wie kann das Team eine solche enge Zusammenarbeit gestalten?

Das Team verantwortet das Design

Wenn am Ende eines zweischrittigen Prozesses – erst Design dann Entwicklung – etwas herauskommt, das nicht die Erwartungen der Nutzer erfüllt, wer ist dann Schuld? Hat der Designer ein schlechtes Konzept abgeliefert? Haben die Entwickler Fehler bei der Umsetzung gemacht. Oder haben gar die Kollegen vom Backend-Service das Produkterlebnis vermasselt?

Bei der Frage nach der Schuld am oder besser der Verantwortung für das Ergebnis kann sich in dieser Konstellation ein munteres Fingerpointing entwickeln. Gerade das möchte Scrum durch die Verlagerung der Verantwortung für das Ergebnis auf das gesamte Team eigentlich vermeiden.

In my view [this] requires a certain state of mind. It’s an attitude which says: I’m going to make a difference, I’m going to cooperate and communicate, and I’m going to understand that in the business of delivering great software, we’re all in it together.
– Stephen Nelson-Smith

Mit diesen Worten hat Stephen Nelson-Smith 2010 für eine bessere Zusammenarbeit plädiert. Kurioserweise geht es in diesem Zitat aber nicht um die Zusammenarbeit zwischen Technik und Design sondern zwischen Technik und Betrieb (DevOps). Die Herausforderung ist aber eine ganz ähnliche: Zwei Rollen mit sehr unterschiedlichen Perspektiven auf das Projekt wollen ihre Zusammenarbeit besser organisieren, um Qualität und Durchflussgeschwindigkeit von Änderungen zu verbessern.

Was bedeutet das für den Designer und für Designaktivitäten? Der Designer sollte vollwertiges Mitglied im Scrum-Team sein und zu allen Regelmeetings (Daily, Planning etc.) eingeladen werden. Gleichzeitig bindet er durch Elemente kollaborativen Designs die Teamkollegen (und weitere Stakeholder wie den PO) in seinen Designprozess ein.

Zum Vergrößern anklicken.

Zwar konzentriert sich die fachliche Expertise (Informationsarchitekur, Interaktionsdesign, visuelle Gestaltung, User Research Methodik etc.) immer noch beim Designer. Mit Techniken wie sie aus dem Umfeld von Design Thinking bekannt sind, kann er aber die verschiedenen Blickwinkel und Expertisen der anderen für seine Arbeit nutzen. Das gilt sowohl für Research als auch für Konzeption – mit Formaten wie Brainstorming, Design Studio Method und Design Sprints.

Auf dem Weg zur gemeinsamen Verantwortung des Teams für das Design sind allerdings mögliche Widerstände zu überwinden:

  • Alle Mitglieder müssen sich auf die zusätzliche Verantwortung und die „neuen“ Aktivitäten einlassen.
  • Der Designer verändert seine Rolle vom reinen Experten zum Moderator und Coach, der das Team in Methodiken einführt und in kollaborativen Sitzungen anleitet. Die daraus entstehenden Impulse und Ideen nimmt er vorbehaltlos auf und bindet sie (soweit hilfreich) in seine Konzeption ein.
  • Durch den ständigen Austausch mit den Teamkollegen wird die Arbeit des Designers sehr viel transparenter. Die Diskussion früher, „unfertiger“ Ideen und Konzepte verlangt von ihm eine offene Haltung und im Team eine gute Feedback-Kultur.

Wichtig zu beachten: Wie bei DevOps sind es nicht allein Prozesse und Rollen, die aufeinander zubewegt werden müssen, sondern Menschen, die sich in ihrer Haltung und Sichtweise auf die Perspektive des jeweils anderen einlassen müssen. Dass das Herstellen einer „gemeinsamen Wirklichkeit“ nicht immer einfach ist, zeigt (in leicht überzogener Weise) die folgende Illustration.

Für die Integration von Designaktivitäten in den Scrum-Prozess scheint sich zumindest bisher kein Königsweg herausgebildet zu haben. Es ist – wie bei allen Vorgehensmodellen (inklusive Scrum) – ein undogmatischer Ansatz empfehlenswert: Ausprobieren, was anspricht, und daraus einen eigenen Ansatz entwickeln, der zur Organisation und zum Marktumfeld passt.

Erstrebenswert ist ein Vorgehen, das die Designaktivitäten möglichst eng in den Scrum-Prozess integriert und den Designer zum vollwertigen Teammitglied macht. Ein Beispiel dafür ist das im Buch „Lean UX“  dargestellte Vorgehen, die Scrum-Regelmeetings um regelmäßige Discovery/Ideation- und Testing-Sessions zu ergänzen. Ein Beispiel für eine andere, weniger enge Integration wäre „Dual Track Agile“, die sich auch für Remote-Teams gut eignet. Verbunden allerdings mit der Gefahr, dass durch die geringere Kopplung wieder Design und Techniksilos entstehen.

Dual-Track Agile (Quelle: Devbridge Group)

Welcher Ansatz auch immer gewählt wird, ein informeller, ungeplanter Austausch zwischen Designer, PO und Frontend-Entwickler sollte jederzeit möglich sein.

Häufig arbeitet ein Designer nicht nur für ein Entwicklungsteam. Persönlich sind mir mehrere Fälle bekannt, in denen ein Designer vier Entwicklungsteams gleichzeitig betreuen musste. Wenn ein Designer seine Arbeitszeit auf mehrere Teams aufteilen muss, erschwert das seine wirksame Einbindung in die Teams. Oberhalb von zwei gleichzeitig betreuten Teams dürfte eine echte Kollaboration zwischen Design und Entwicklung in den meisten Umfeldern nur schwer zu realisieren sein.

Agile heißt „Continuous Everything“

Ein iterativ inkrementelles Vorgehen ist ein Kernprinzip agiler Vorgehensmodelle. Es hat zum Ziel, jederzeit „Working Software“ zu liefern. Das Streben nach dem schrittweisen Aufbau komplexer Software-Systeme in kleinen, jederzeit überprüfbaren Schritten hat eine ganze Welle von „Continuous Irgendwas“-Bewegungen ausgelöst.

Wie steht es um „Continous Design“, „Continuous Discovery“ oder „Continuous Research“?3 Wenn „Working Software“ auch „Working Design“ bedeutet, dann verbietet sich umfängliches Upfront Design. Wenn das Scrum-Team nicht nur sein Wissen über die Herausforderungen der technischen Lösung kontinuierlich erweitern und seine Planung entsprechend anpassen soll, sondern das Gleiche auch für das Nutzungserlebnis (und die Marktakzeptanz) gilt, dann müssen auch alle Design- und Research-Aktivitäten iterativ inkrementell in den Entwicklungsprozess eingebunden werden. Grundsätzliche Ideen zu einer solchen Einbindung wurden im letzten Abschnitt schon benannt. Was dies auf Ebene des Produktmanagements bedeutet ist Thema des nächsten Artikels. Bleibt noch ein Aspekt, der bei iterativ inkrementellem Vorgehen zu Konflikten im Team und zu Schwächen im Ergebnis führen kann: Schulden.

Schulden machen ist O.K. – oder?

Schulden sind bekannte Schwächen in bereits erstellten Anteilen des Produktes. Technische Schulden („Technical Debt“) sind ein weithin bekanntes Phänomen, das von vielen Entwicklerteams inzwischen explizit gemanagt wird. Eine besondere Gefahr von „Schulden“ ist, dass sie über Zeit so anwachsen können, dass aus kleinen Schwächen ein ernstes Projektrisiko erwächst.

Das Gleiche gilt auch für Designschulden. Sie entstehen unter anderem durch:

  • Abweichungen zwischen Konzept und Umsetzung
  • Vereinfachte, nicht vollwertige Lösungen, die im Sinne eines inkrementellen Vorgehens eigentlich schrittweise weiterentwickelt werden sollten
  • Designs, die nicht die erwartete Wirkung beim Nutzer haben
  • Wissen, dass bei Konzeption/Umsetzung noch nicht verfügbar war

Noch mehr als Technikschulden werden solche Schwächen im Nutzungserlebnis häufig gegenüber der Umsetzung neuer Features depriorisiert. Das iterative Element des iterativ inkrementellen Vorgehens geht so verloren. – Nicht falsch verstehen: Es kann durchaus opportun sein, „einen Kredit aufzunehmen“, also Designschulden für eine Weile auflaufen zu lassen. Sammeln sich aber zu viele Schwächen, können sie sich im Laufe der Zeit zu einer ernsthaften Bedrohung für den Produkterfolg auswachsen.

Auch bei Designschulden kann das explizite Managen bekannter Schwächen helfen, ihre Sichtbarkeit zu erhöhen. Dies kann zum Beispiel in Form eines eigenen Backlogs geschehen. Betreibt das Team konsequent „Continuous Research“ (in diesem Falle in Form von regelmäßigen Usability Tests und/oder User Tracking) können in diesem Rahmen vermeintliche Designschulden im Hinblick auf ihre tatsächlichen Auswirkungen evaluiert werden. Sehr wirksam kann die Erstellung und regelmäßige Aktualisierung von Journey Maps sein. Als Board fürs Team bereitgestellt, kann jeder sich jederzeit aktuelle Schwächen der User Journey vergegenwärtigen.

Design Process is never done

No one gets it right the first time.
Marc Rettig

Design ist von seiner Natur her iterativ. Das gilt nicht allein für das Design digitaler Produkte, sondern auch für die Gestaltung der Prozesse und Regeln, die wir für unsere Arbeit entwickeln. So wie es eine Kultur des Experimentierens und Lernens für gute Produkte braucht, sollten wir auch im Miteinander Spaß am Experimentieren und Explorieren entwickeln.

Es gibt kein Schnittmuster für den Erfolg. Agile ist keine Heilslehre sondern eine Sammlung von pragmatischen Prinzipien und Glaubenssätzen, die aus einer tiefen Krise der Software-Industrie entstanden ist. Design Thinking war der Versuch einiger Ingenieure und Designer, den Produktdesignprozess für Nicht-Designer zugänglicher zu machen. Beide Ansätze werden heute extrem gehyped und zum Teil mit religiösem Eifer verfolgt.

Was täte der Wirksamkeit von Agile und Design Thinking gut? Dass Unternehmen diese Methoden nicht als Selbstzweck verfolgen, sondern das eigentliche Ziel im Auge behalten: Erfolgreiche Produkte und geschäftlicher Erfolg. Und dass Unternehmen sich pragmatisch auf diejenigen fokussieren, auf die es immer noch ankommt: Mitarbeiter und Kunden. Das wiederum wäre auch ganz im Sinne der Erfinder dieser Vorgehensmodelle.

Der Fisch stinkt vom Kopf

Prozesse und Rollen geklärt. Alles gut? Im nächsten Artikel möchte ich „weiter vorne“ (im Prozess) und „weiter oben“ (in der Organisation) schauen, wo es nicht gut „riecht“. Welchen Einfluss haben Management und Strategie des Unternehmens auf den Designprozess – und damit verbunden auf den Produkterfolg?

In diesem Zusammenhang werfen wir auch einen Blick auf Skalierungsfragen: Wie kann man „agil und kreativ“ auf einen Konzern mit einer großen Anzahl von Scrum-Teams (und Designern) übertragen? So viel sei vorab verraten: Die Antwort ist kontra-intuitiv, und sie steht im Widerspruch zu den typischen Reflexen von Führungskräften in der Wirtschaft.

Lesetipps

Anmerkungen

  1. Der Begriff der Softwarekrise stammt ursprünglich schon aus den 60er Jahren. Die bis dahin genutzten Techniken zur Entwicklung von Softwaresystemen hielten nicht mit der wachsenden Komplexität dieser Systeme Schritt. Das war zunächst die Geburtsstunde des Software Engineering und der Verbreitung des Wasserfall-Modells. Lange Projektlaufzeiten und die weiter zunehmende Komplexität führten in den 80ern zu „iterativen“ und in den 90ern schließlich zur Geburt der später als „agil“ bezeichneten Vorgehensmodelle. Für einen historischen Abriss siehe zum Beispiel „To agility and beyond: The history – and legacy – of agile development“.
  2. In der Vergangenheit – und nicht selten auch noch heute – vermitteln Bankdienstleistungen den Charme von Behördengängen. Behörden stehen für Seriosität – insofern kein schlechtes Image für einen Finanzdienstleister. Für viele, insbesondere junge Kunden, sind solche Produkterlebnisse aber nicht mehr zeitgemäß. Und obwohl Banken im Bereich IT-gestützter Datenverarbeitung und bei Online Selfcare Services auf eine lange Erfahrung verweisen können, fehlt ihnen häufig die Kompetenz für die Entwicklung kundenzentrierter, digitaler Serviceerlebnisse, die es mit den Produktdesigns moderner Fintech-Startups aufnehmen könnten. – Wer glaubt, dass der Vorsprung der Startups allein auf technologischer Finesse beruht, hat die eigentliche Herausforderung der sogenannten „Digitalisierung“ noch nicht verstanden
  3. Ein wichtiger Vorreiter der Idee des kontinuierlichen Lernens und Innovierens ist Eric Ries mit seinem Buch „The Lean Startup“.

Alle Artikel aus der Serie

Über Hans-Joachim Belz

Hans-Joachim Belz ist Mitbegründer des Bonner Beratungsinstituts Anstrengungslos. Seine Leidenschaft sind nachhaltig erfolgreiche Produkte und die Rahmenbedingungen unter denen sie entstehen können. Als Designer, Trainer und systemischer Coach unterstützt er deshalb Unternehmen bei der menschzentrierten, kreativen Gestaltung sowohl ihrer Produkte als auch der dahinter stehenden Teams und Organisationen. Nebenbei organisiert er den UX Bonn Meetup mit und diskutiert mit Studenten der DHBW Mannheim in seiner Lehrveranstaltung über Mobile Commerce.

Ein Kommentar


Schreibe einen Kommentar

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

Mit Absenden des Kommentars stimmst Du der Speicherung deiner persönlichen Daten (Name, eMail-Adresse, Webseite und Nachricht) durch uns bis auf Widerruf zu. Zur Vermeidung von Spam und zur rechtlichen Absicherung wird deine IP für 2 Monate gespeichert. Ebenfalls zur Vermeidung von Spam werden diese Daten einmalig an Server der Firma Automattic inc. geschickt. Zur Darstellung eines Nutzerbildes wird die eMail-Adresse im pseudonymisierter Form an Automattic inc. übermittelt. Wenn du einen oder beide Haken für die eMail-Benachrichtigungen setzt, wird deine eMail-Adresse bei Automattic inc. gespeichert. (Datenschutzerklärung)

Du hast noch viel mehr zu erzählen?

Dann schreib doch einen eigenen Artikel auf produktbezogen.

Artikel vorschlagen →