Wie wir ein zentralisiertes Mehrmarken-Bibliotheksökosystem für einen der größten Edtech-Bestände in Brasilien aufgebaut haben.

Zunächst muss ich sagen, dass dies kein Artikel ist, der darauf abzielt, zu erklären: „Was ist ein Designsystem?“ oder „Wie wichtig ist es für Ihr Unternehmen?“ (Um einen Überblick über das Thema zu erhalten, empfehle ich die Lektüre dieses Artikels von Meiuca ). Unser Ziel ist es, einen kleinen Einblick in die Art und Weise zu geben, wie wir ein Mehrmarken-Designsystem für eine der größten Edtech-Beteiligungen in Brasilien aufgebaut haben. Dabei konzentrieren wir uns hauptsächlich auf die Herausforderungen im Designbereich und auf die Ergebnisse, die wir mit diesem Projekt erzielt haben.

Aus diesem Grund werden wir natürlich über Dinge sprechen, die Sie dazu inspirieren können, gemeinsam mit Ihrem Team eine Entscheidung zu treffen, oder, wer weiß, sogar einige Stakeholder davon überzeugen können, in ihr eigenes Designsystem zu investieren (ich hoffe, dieser Artikel kann Ihnen dabei helfen). ).

Da wir in der Schlange stehen, lasst uns gehen!

Kontext und Probleme

Heutzutage ist Wiser Education ein Anbieter digitaler Produkte für den Bildungsmarkt, insbesondere für die Erwachsenenbildung. Dies war jedoch nicht immer unsere Realität.

Wiseup Online , meuSucesso.com , Conquer und Power House zusammen kommen auf mehr als 300.000 Benutzer.

Wiser begann als Franchisegeber für Englischschulen für Menschen über 18 Jahre. Ich glaube, sie haben die nationale Szene erobert, weil sie sich immer so positioniert haben, dass sie neue Markttrends aufgreifen konnten (Englisch für Erwachsene war damals beispielsweise nicht üblich).

Im Jahr 2020 erlebten wir jedoch alle, wie der weltweite Bildungsmarkt durch eine Pandemie auf den Kopf gestellt wurde. Unser bisher auf Präsenzlehre basierendes Geschäftsmodell musste nun komplett auf ein Online-Lehrformat umgestellt werden.

Wie üblich hat Wiser diese neue Marktrealität angenommen und sich offiziell zu einem Unternehmen für digitale Bildungsprodukte entwickelt.

Da jedoch jedes beschleunigte Wachstum seinen Preis hat, mussten wir monatelange Arbeit ohne eine klare und skalierbare Organisation in Rechnung stellen. Und dieses Konto war teuer.

„Wir wachsen schnell, aber mit zu vielen OPEX“
OPEX: Betriebsausgaben. Ausgaben für Betriebsausgaben: Humankapital – https://www.suno.com.br/artigos/capex/ oder Mittel

Anfang 2022 hatten wir dieses Szenario: Zu viele Dateien und zu viele Inkonsistenzen (Komponenten, Farbsysteme und Bibliotheken). Infolgedessen hatten wir eine enorme Zeitverschwendung bei der Neugestaltung von Bildschirmen und Komponenten, die wiederverwendet werden konnten.

Wir kamen zu dem Schluss, dass wir ein Designsystem brauchten, aber die unbeantwortete Frage war: Wie können wir das machen, wenn man bedenkt, dass wir unsere Bibliotheken an verschiedene Marken und Produkte anpassen müssen und darüber hinaus kein voll engagiertes Team dafür haben?

Agil war die Antwort

Wir dachten, dass mehrere Frameworks zur Steuerung dieses Projekts in Frage kommen: 5W2H, Double Diamond, aber denken Sie daran, dass unser Szenario von mehreren Lieferungen umgeben war, die die Entwicklung eines Designsystems parallel unterstützen mussten! (Es war keine einfache Aufgabe).

„Wir müssen unserem Endbenutzer etwas liefern und so schnell wie möglich daraus lernen.“

Anstatt einen klaren und linearen Prozess zu implementieren, haben wir uns daher entschieden, die Grundprinzipien des agilen Denkens zu beherzigen und von dort aus zu beginnen.

• Einzelpersonen und Interaktionen über Prozesse und Tools.
• Software, die auf einer vollständigen Dokumentation läuft.
• Kundenzusammenarbeit bei Vertragsverhandlungen.
• Reagieren Sie auf Veränderungen, anstatt einem Plan zu folgen.

Entdecken

Wir gingen davon aus, dass wir nicht alles über Designsysteme wussten und dass wir noch viel über den Umgang mit einem Mehrmarkenszenario lernen mussten. Deshalb haben wir einige Vertreter der Technologie-, Geschäfts- und Designteams eingeladen, sich wöchentlich als Gilde zu treffen und so die Ergebnisse ihrer Entdeckungen zu präsentieren (alle geleitet von Zielen und Vorgaben).

Von den Bibliotheken großer Unternehmen über Sprachtests bis hin zum Farbsystem haben wir viel gelernt, vor allem aber, dass es viele Möglichkeiten gibt, ein Designsystem aufzubauen, lol. Daher wird unser Fokus darauf liegen, die Entscheidungen vorzustellen, die wir getroffen haben, um dieses Ökosystem von Bibliotheken an das Wiser-Szenario anzupassen.

1. Globale und Marken-Tokens

Wir wissen, dass einer der großen Vorteile eines solchen Projekts die Systematisierung der Definitionen zwischen Designern und Entwicklern ist. Aus diesem Grund glauben wir, dass es für unseren Kontext wichtig ist, zwei Token-Klassifizierungen zu erstellen: Global und Marke.

So einfach es auch erscheinen mag, diese Definition hat uns geholfen zu verstehen, welche Elemente der Benutzeroberfläche allen Produkten gemeinsam sein sollten (Schriftstärke, Randradius, Schatten usw.) und welche kontextbezogen sein sollten (Schriftfamilie, Farben). Um mehr über diese Abteilung zu erfahren, schauen Sie sich dies live auf dem DS von XP Investimentos an.

2. Kernkomponenten des E-Teams

Wir hatten nicht viel Zeit, um alle Komponenten zu erstellen, die wir für Version 1 haben wollten (abgesehen von der Tatsache, dass es nicht sehr mit der agilen Vision der kontinuierlichen Implementierung übereinstimmen würde), also haben wir definiert, was am meisten ist Gemeinsame Komponenten unter den Schnittstellen, die wir analysieren, und nennen sie Kernkomponenten (Komponenten, die zwischen den von uns erstellten Produkten gleich sein sollten, mit nur wenigen Unterschieden in Farbe, Typografie und Randradius zwischen ihnen).

Teamkomponenten wären wiederum Komponenten, die von der Produktgruppe selbst erstellt wurden und Informationen aus dem Designsystem verbrauchen würden, aber nicht unbedingt für alle Produkte vorhanden wären (z. B. Live-Klassenkomponenten).

3. Dokumentation und Governance.

Wir haben unsere Dateien entsprechend ihrer Governance aufgeteilt, um Fehler zu vermeiden und eine Skalierung zu gewährleisten. Diese Klassifizierung erfolgte wie folgt:

• Globale Token
  (Nur wenige Leute konnten diese Datei bearbeiten, da sie die Token abdeckte, die von allen Marken verwendet würden).
• Kernkomponenten (Nur wenige Personen konnten diese Datei bearbeiten, da sie alle von anderen Produkten gemeinsam genutzten Kernkomponenten abdeckte.)
  
• Stylesheet (Alle Kaderdesigner können diese Datei bearbeiten. Gruppierung von Markentokens und Teamkomponenten – erstellt vom Kader selbst unter Verwendung von DS-Elementen).
  

Nach dieser Definition haben wir die Schnittstellen der in unserem Unternehmen vorhandenen Produkte analysiert und identifiziert, welche Komponenten in unserem Kontext am häufigsten vorkommen. Anschließend haben wir definiert, welche Kernkomponenten für DS v.1 generiert werden sollen.

1. Typografie
2. Farbe
3. Taste
4. Textfeld
5. Wählen
6. Kontrollkästchen
7. Radio knopf
8. Basiskarte

Unmittelbar nach unseren Entdeckungen und der Festlegung des Umfangs begannen wir mit der Generierung der Komponenten für unsere erste Version des Designsystems. Zu diesem Zweck folgten wir einem Prozess, der die folgenden Schritte umfasste:

Da wir kein eigenes Team hatten, sondern eine Gilde bestehend aus Menschen, die sich für das Thema interessierten, erkannten wir die Notwendigkeit, Projektlieferungen an eine bestimmte Gruppe zu delegieren, die ihre wöchentlichen Anforderungen mit DS-Lieferungen verknüpfen konnte.

Daher haben wir festgelegt, dass die Kassenabteilung von Wiser-Produkten für die Lieferung der ersten Komponenten des Designsystems verantwortlich sein sollte, da sie ein White-Label-Produkt koordinieren.

Wir haben ein spürbares Engagement zwischen den Technologieteams erzeugt, da alle durch den Checkout generierten Lieferungen von Kernkomponenten von anderen Teams angewendet werden konnten. Dieser Prozess, der nach und nach neue Komponenten zur Verfügung stellte, weckte bei den Teams ein Gefühl der Neugier und veranlasste die Technologieführer selbst, das Designsystem LIB zu verwenden, um sicherzustellen, dass von da an neue Front-End-Lieferungen in gewisser Weise verwendet wurden das Design System-Repository.

Ergebnis und kontinuierliche Entdeckung

Wir haben das Thema in unsere Umgebung integriert und dabei festgestellt, dass jedes Team, das das Designsystem übernommen hat, seine Lieferzeit erheblich verkürzt hat. Wir hinterlassen hier einige der Ergebnisse, die wir bisher erhalten haben.

Lernen und nächste Schritte

Wir haben aus diesem gesamten Prozess viel gelernt. Hier sind einige Punkte, die es meiner Meinung nach wert sind, mitzuteilen:

1. Wenn Sie Wert (Ergebnis) zeigen, wird es einfacher, mehr Zeit und Geld zu verlangen.
   Wir haben viele Male versucht, dieses Projekt auf den Weg zu bringen, und unsere Stakeholder wussten um die Bedeutung. Aber erst als wir die ersten Lieferungen generierten, gewann das Projekt erst richtig an Priorität.
2. Farben können im Mehrmarkenkontext zu einer großen Herausforderung werden.
   Wir wissen, dass Farbpaletten vielseitig und einfach sein müssen, aber es war eine Herausforderung, einen Standard zu definieren, der automatisch für mehrere Produkte gilt und manuelle Anpassungen durch Designer und Entwickler überflüssig macht.
3. Teamarbeit ist großartig!
   Wir hatten noch nicht viele Fans, die an dem Projekt mitarbeiteten, also hat jeder Partner, der bereit war, an der Idee mitzuarbeiten, einen Unterschied gemacht!
4. Kontinuierliche Lieferungen!
   Ich habe das vielleicht schon einmal gesagt, aber Continuous Delivery war der Schlüssel zur Entwicklung dieses Designsystems. Achten Sie darauf, dass Sie nicht in endlosen Lernzyklen stecken bleiben. Generieren Sie jeden Tag, jede Woche, jeden Monat, jedes Quartal einen Mehrwert.

Danke fürs Lesen!

Verweise

Marinheiro, Felipe – Greenstone Design System Hassu Thiago – Design System na visão da Meiuca Invision – DesignOps ins Spiel bringen IBM – Carboom Design System Google – Material Design

Kredit

Maria Fernanda – Produktdesignerin Ops
Renata Caraih – Produktdesignerin Ops
Marcus Vinícius – Tech Lead
Adson Amorim – Front-End
Diogo Thomaz – Product Owner
Luan Lima – Produktleiter