Razorpay: Verbesserte Designsystemnutzung und Zusammenarbeit zwischen Design und Entwicklung mit Figma mit Figma

Als eines der größten und am schnellsten wachsenden Unternehmen der Finanzdienstleistungsbranche in Indien bedient Razorpay 10 Millionen Unternehmen. Wir haben mit dem Designsystem-Team über folgende Themen gesprochen:

• Ansätze zur Einführung und Bewertung von Designsystemen
• Herausforderungen bei der Zusammenarbeit von Design und Entwicklung
• Nutzung des Dev Mode und proprietärer Plug-ins zur Optimierung von Team-Workflows
• Einfluss von Figma auf die Produktivität und Akzeptanz von Designsystemen

Wie sind das Team und die Plattform strukturiert?

Soni: In unseren Teams gibt es ungefähr 70 Designer*innen und 100 Frontend-Entwickler*innen. Von diesen konzentrieren sich speziell drei Designer*innen und fünf Entwickler*innen ausschließlich auf die Pflege und Weiterentwicklung unseres Designsystems.

Kamlesh: Unser Produkt ist als Webanwendung für Desktop- und Mobilgeräte sowie als native Anwendung für iOS und Android verfügbar. Wir verwenden ein konsistentes Designsystem, das plattformübergreifend mit derselben API und identischen Eigenschaften arbeitet. Dadurch können Entwickler*innen ihr Wissen über Webcode nahtlos auf die mobile Anwendung übertragen. Dieser Ansatz ermöglicht es uns, die Entwicklungszeit zu optimieren, da keine separate Anpassung für unterschiedliche Plattformen erforderlich ist.

Was macht das Designsystem von Razorpay aus und warum hat es einen so hohen Stellenwert?

Soni: Das Designsystem von Razorpay ist Blade. Vor dessen Einführung war es für Teams nicht unüblich, Kleinigkeiten wie den Status von Buttons oder den Umgang mit Fehlern in Eingabefeldern zu übersehen. Oft konzentrierten sich die Teams darauf, Daten direkt einzubetten und jeweils individuelle Lösungen zu entwickeln, und dabei konnte es passieren, dass sie aus Versehen etwas ausließen.

So wurde viel ad hoc entwickelt, die Arbeit wurde sehr repetitiv und die Benutzerfreundlichkeit hat darunter gelitten. Bei einem Produkt wie unserem ist jedoch die Kundenzufriedenheit von größter Bedeutung, insbesondere weil unsere Zielgruppe aus Unternehmen besteht, die uns ihr Geld anvertrauen. Eine reibungslose Produktnutzung ist entscheidend, da sie Vertrauen aufbaut.

Die Marke Razorpay besteht außerdem aus mehreren Produkten auf unterschiedlichen Bereichen. Wir müssen daher auf eine einheitliche Benutzeroberfläche für alle Produkte achten. Mit einem einheitlichen Designsystem und einer einheitlichen Sprache gelingt es uns, die Benutzeroberfläche von Anfang an und mit deutlich mehr Agilität zu gestalten. So stellen wir sicher, dass alle Komponenten von Blade für alle Nutzer*innen zugänglich sind.

Kamlesh: Wir beschäftigen uns mit Designsystemen, daher sind neben den Endanwender*innen sowohl Entwickler*innen als auch Designer*innen unsere Kund*innen. Dank Blade sprechen wir eine einheitliche Sprache, sodass es weniger Abstimmungsprobleme zwischen den Teams gibt und eine schnellere Markteinführung möglich wird. Was im Design zu sehen ist, wird auch so im Code umgesetzt.

Wie ist dein Team an die Umstellung auf Blade herangegangen?

Kamlesh: Das ist immer die heikelste Aufgabe bei Plattform-Tools. Wir haben verschiedene Schritte unternommen, um für einen möglichst reibungslosen Umstieg zu sorgen:

• Unterstützung durch Führungskräfte: Es kommt bei der Entwicklung unseres Designsystems darauf an, die Führungskräfte zur Unterstützung zu gewinnen. Angefangen bei der Gründung und Ausstattung der Teams bis hin zur Förderung der Übernahme von Blade in den jeweiligen Teams dieser Führungskräfte.
• Ermittlung wichtiger Kennzahlen: Mithilfe interner Tools und Skripte beobachten wir qualitative und quantitative Kennzahlen, wie die Anzahl der Projekte, die auf Blade eingestellt wurden, oder die Anzahl der Apps, die mit unserem Designsystem erstellt wurden. Auf diese Weise ist es für Führungskräfte und uns einfacher, den Fortschritt im Blick zu behalten.
• Aktive Unterstützung von Kunden: Während unserer Geschäftszeiten und über unseren Slack-Kanal können Kund*innen Fragen stellen oder Probleme melden. Wenn es sich um ein ernsthaftes Problem handelt, öffnet das Verbraucherteam ein GH-Thema, denen unser Team Prioritäten zuweist. Außerdem haben wir ein Beratungsteam geschaffen, in dem sich auch Designer*innen unseres Verbraucherteams befinden. Sie unterstützen bei Entscheidungen zu Komponenten und und deren Nutzung in ihren Teams.
• Werbung innerhalb unseres Unternehmens: Neue Komponenten kündigen wir mit einem Demo-Video und einem Update auf der Komponenten-Statusseite an. Dadurch verhindern wir, dass Verbraucherteams Komponenten schaffen, die bereits im Designsystem vorhanden sind.

Wie wird die Effektivität der Teams gemessen?

Kamlesh: Unser Hauptziel ist es, unseren Teams die Erstellung moderner und ansprechender Benutzeroberflächen mit minimalem Aufwand in Figma zu ermöglichen. Dadurch können sie sich auf die Implementierung neuer Produktfunktionen konzentrieren, während der Rest vom Designsystem abgedeckt wird. Wir haben uns ein Ziel gesetzt, nach dem neue Funktionen zu mindestens 70 % mit Blade umgesetzt werden müssen, für bestehende Produktoberflächen senken wir dieses Ziel auf 50 %. Diese Vorgabe dient als gemeinsame Metrik für die Design- und Entwicklerteams, die beide gleichermaßen motiviert sind, dieses Ziel gemeinsam zu erreichen.

Uns ist allerdings aufgefallen, dass die Weichen für die Nutzung des Designsystems schon in der Designphase gestellt werden. Wenn Designs nicht mit Designsystem-Komponenten erstellt werden, wissen Entwickler*innen nicht, dass sie Blade nutzen sollten. Deswegen haben wir ein Blade Coverage-Plug-in erstellt, das Designer*innen anzeigt, wie weit sie vom Designsystem abweichen. Mit dem Plug-in können Designer*innen ihre Launch-Zeitpläne genauer prognostizieren und Schwierigkeiten bei der Übergabe reduzieren, da sie bereits zu einem früheren Zeitpunkt Feedback zu den von ihnen verwendeten Komponenten erhalten.

Quantitative Kennzahlen genügen jedoch nicht, um Akzeptanz und Effektivität eines Designsystems vollständig zu analysieren. Wir setzen daher auch auf interne Befragungen und Fokusgruppen. Damit gelingt es uns, Stimmungen zu erfassen, zum Beispiel ob Teams den Eindruck haben, dass sie mit Blade schneller liefern können. Außerdem erhalten wir Feedback zur Teamerfahrung mit Tools, Dokumentation, Schulungen, und ob die Zusammenarbeit zwischen Designer*innen und Entwickler*innen reibungslos ist. All dies wird in einer Empfehlunskennzahl (Net Promoter Score) zusammengefasst, den wir auf Jahresbasis ermitteln.

Reibungslosere Zusammenarbeit zwischen Designer*innen und Entwickler*innen mit proprietären Plug-ins in Figma

Wie gestaltete sich die Zusammenarbeit bei Übergabe und Entwicklung im Team vor der Nutzung von Dev Mode?

Kamlesh: Bei der Übergabe wird von Entwickler*innen erwartet, alle Elemente zu begutachten und die Eigenschaften entsprechend zu kopieren. Die ursprüngliche Vorgehensweise war nicht ideal und lästig. Entwickler*innen mussten sich durchklicken, bis sie zufällig zur richtigen Komponente gelangten, die Komponenten ermitteln, deren Eigenschaften ansehen und diese dann entsprechend programmieren.

Um diesen ineffizienten Überprüfungsvorgang zu vermeiden, hat ein Mitglied unseres Entwicklungsteams im Rahmen eines Zusatzprojekts innerhalb von zwei bis drei Monaten ein eigenes Plug-in namens RazorSharp entwickelt. Dies hat uns ermöglicht, äquivalenten Code für die Designs automatisch zu erzeugen. Die Entwickler*innen mussten diesen dann nur noch kopieren und einfügen.

Das RazorSharp-Plug-in hat einige Abläufe für Entwickler*innen erleichtert, es konnten jedoch nicht alle Probleme damit gelöst werden. Vor Dev Mode konnten Plug-ins in Figma nur mit Schreibzugriff auf die Datei ausgeführt werden, über den die meisten unserer Entwickler*innen nicht verfügten. Wenn sie daher eine Figma-Datei vom Designteam erhielten, musste diese zunächst durch die Entwickler*innen in eine neue Datei geklont werden, um das RazorSharp-Plug-in ausführen zu können.

Schnellere Nutzung von Designsystemen mit Dev Mode

Wie hat Dev Mode, einschließlich Variablen, diese Probleme gelöst?

Kamlesh: Die meisten Schwierigkeiten bei der Überprüfung spielen inzwischen bei uns keine Rolle mehr. Nachdem Dev Mode eingeführt wurde, haben wir über ein Update die Ausführung von RazorSharp als Dev Mode-Plug-in ermöglicht. Dieses können unsere Entwickler*innen verwenden, ohne Dateien bearbeiten zu müssen, um die Codeimplementierung anzuzeigen. Da die Funktionen bereits vorhanden waren, hat es lediglich zwei Tage gedauert, um die Kompatibilität von RazorSharp und Dev Mode zu erreichen.

Wir verwenden Dev Mode auch, um Storybook-Links für die einzelnen Komponenten zu integrieren, damit unsere Designsystem-Kund*innen leichter zur Code-Testumgebung für die jeweilige Komponente in Storybook gelangen können.

Derzeit wandeln wir unsere Token in Variablen. Auch wenn sich dieser Prozess in einer frühen Phase befindet, können wir bereits Vorteile für die Arbeit unserer Entwickler*innen erkennen.

Das Kopieren von Token aus Designs in Code ist jetzt nahtlos möglich. Anstatt Schrägstriche aus den Namen der Tokens zu entfernen (surface/text/subtle), ist es jetzt möglich, eine passende entwicklerfreundliche Struktur zuzuweisen (surface.text.subtle). Außerdem sind Abstands-Token jetzt Variablen zugeordnet, was unsere Verbraucherteams immer wieder gefordert hatten.

Standardmäßig lassen sich der Hell- und der Dunkelmodus implementieren, ohne dass die Designs für die beiden Modi neu erstellt werden müssen. Ein weiteres Problem bei Blade auf Figma war der enorme Speicherbedarf aufgrund der verschiedenen Modi (Hell/Dunkel) für die verschiedenen Themes (Zahlung/Banking) für jede unserer Komponenten. Dies hat die Produktivität unserer Designer*innen aufgrund der Verlangsamung der Systeme während des Designs spürbar beeinträchtigt. Mit der Einführung von Variablen ist es uns jedoch gelungen, Blade zu einem einheitlichen Theme zu verschlanken, was die Produktivität unserer Designer*innen deutlich erhöht.

Saurav: Es gibt auch einige weitere Funktionen, mit denen wir unsere Workflows optimieren konnten. Mit dem VS Code-Plug-in können unsere Entwickler*innen programmieren, ohne den Kontext aus dem Blick zu verlieren, indem sie zwischen Figma und der Programmierumgebung wechseln. Das Box-Modell hilft den Entwickler*innen, die Designs innerhalb von Figma und möglichst nahe am Programmcode zu veranschaulichen. Durch Abgleich von Änderungen und dem Versionsverlauf können Entwickler*innen besser nachvollziehen, wann eine Datei verändert wurde. So können sie Dateien einfrieren und gründlich analysieren, um zu vermeiden, dass Fristen verpasst werden, weil in letzter Minute Änderungen erforderlich sind.

Bessere Produktivität und Übernahme von Designsystemen

Wie haben sich diese Änderungen auf das Team ausgewirkt?

Saurav: Bei einer Befragung haben 80 % unserer Designer*innen und Entwickler*innen angegeben, dass sie mit Blade produktiver arbeiten als ohne das Designsystem. Dev Mode hat erheblich dazu beigetragen, dass unser Designsystem leichter verständlich ist und vermehrt eingesetzt wird.

Kamlesh: Wir befinden uns noch in der Anfangsphase und noch nicht alle Entwickler*innen haben Dev Mode getestet. Entwickler*innen, die damit begonnen haben, Dev Mode zu verwenden, konnten Verbesserungen bei ihren Workflows feststellen: entweder durch reibungslosere Zusammenarbeit zwischen Design- und Entwicklungsteams oder durch eine Steigerung der Gesamtproduktivität.

Wenn du mehr darüber erfahren möchtest, wie Razorpay seine Designsysteme erstellt und wartet, sieh dir das Blade-Designsystem auf GitHub oder die Best Practices in den Blogs Razorpay Design und Engineering an. Besuche ihren Design-Blog oder sieh dir das Blade-Designsystem auf GitHub an.

Wenn du mehr über unser selbstentwickeltes Plug-in zur Codegenerierung erfahren möchtest, lies die Dokumentation für Entwickler*innen von Figma oder nutze unser Beispiel für das Codegen-Plug-in auf GitHub.