Effiziente Workflows für Entwickler*innen dank Razorpay
Das Designsystem-Team von Razorpay hat Blade entwickelt, um konsistente und intuitive Nutzererfahrungen zu ermöglichen und gleichzeitig verschiedene Produkte plattformübergreifend zu unterstützen.
Effiziente Workflows für Entwickler*innen dank Razorpay teilen
Als eines der größten und am schnellsten wachsenden Unternehmen der Finanzdienstleistungsbranche in Indien stellt Razorpay seine Dienstleistungen für 10 Millionen Unternehmen zur Verfügung. Trotz dieser Größe gelingt es den Design- und Entwicklungsteams mithilfe von Blade, dem Designsystem von Razorpay, reibungslos zusammenzuarbeiten. Erfahren Sie hier aus erster Hand mehr darüber, welche Ansätze das Designsystem-Team von Razorpay bezüglich Einführung und Messung verfolgt, wie mit Herausforderungen bei der Zusammenarbeit umgegangen wird und mit welchen proprietären Plug-ins es den Entwickler*innen gelingt, effizienter zu arbeiten.
Wie sind das Team und die Plattform strukturiert?
Es gibt ca. 70 Designer*innen und 100 Front-End-Entwickler*innen. Innerhalb dieser Teams widmen sich drei Designer*innen und fünf Ingenieur*innen unserem Designsystem.
Unser Produkt wird in verschiedenen Versionen als Webanwendung für Desktop oder Mobilgeräte sowie für iOS- und Android-Apps entwickelt. Mit Blade nutzen wir ein einheitliches Designsystem, das plattformübergreifend mit derselben API und dem gleichen Satz von Eigenschaften funktioniert. Beim Wechsel zwischen Web-Anwendung und mobiler App können Entwickler*innen so ihr jeweiliges Wissen zum Webcode übertragen. Wir haben uns für diesen Ansatz entschieden, weil wir keine Zeit in die Anpassung für verschiedene Plattformen investieren möchten.
Welche Probleme wurden mit dem Designsystem gelöst?
Vor dem Roll-out von Blade konnte es leicht vorkommen, dass Teams kleine Details übersehen, wie zum Beispiel den Status von Schaltflächen oder den Umgang mit Fehlern in Textfeldern. Die Teams waren darauf bedacht, Daten direkt einzubetten und jeweils individuelle Lösungen zu entwickeln, und dabei konnte es passieren, dass sie aus Versehen etwas ausließen. Es wurde viel ad hoc entwickelt, die Arbeit wurde sehr repetitiv und das Erlebnis für Kund*innen hat darunter gelitten. Dieses ist jedoch bei einem Produkt wie unserem wichtig, denn unsere Zielgruppe sind Unternehmen, die uns ihr Geld anvertrauen. Ein nahtloses Produkterlebnis schafft Vertrauen.
Razorpay bietet außerdem mehrere Produkte auf unterschiedlichen Domänen an. Wir müssen daher auf eine einheitliche Benutzeroberfläche für alle Produkte und Domänen 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 wird auch gewährleistet, dass alle Komponenten von Blade für alle Nutzer*innen zugänglich sind.
Wir beschäftigen uns mit Designsystemen, daher sind neben den Endanwender*innen sowohl Entwickler*innen als auch Designer*innen von Razorpay unsere Kunden. Dank Blade sprechen wir eine einheitliche Sprache, sodass es weniger Abstimmungsprobleme zwischen den Teams gibt und eine schnellere Markteinführung ermöglicht wird. Mit dem gleichen Code wird dasselbe Design erzeugt.
Wie hat das Team das Designsystem angenommen?
Das ist immer die heikelste Aufgabe bei Plattform-Werkzeugen. Wir haben verschiedene Schritte unternommen, um für eine möglichst reibungslose Übernahme zu sorgen:
- Unterstützung durch Führungskräfte: Es kommt in jeder Phase darauf an, Unterstützung durch Führungskräfte 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 relevanter 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 Designsystemkomponenten erstellt wurden. Auf diese Weise ist es für Führungskräfte und Arbeitsgruppen einfacher, den Fortschritt im Blick zu behalten.
- Unterstützung von Kunden: Während unserer Geschäftszeiten und über unseren Slack-Kanal können Kund*innen Fragen stellen oder Probleme melden. Außerdem haben wir ein Beratungsteam geschaffen, das sich aus Designer*innen zusammensetzt, die in ihren Teams Blade verwenden. Dieses Team unterstützt 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.
Wie wird die Effektivität der Teams gemessen?
Unser Ziel ist es, Teams in die Lage zu versetzen, moderne und elegante Benutzeroberflächen zu gestalten, während alles Andere durch das Designsystem übernommen wird. Unser Sollziel sieht vor, dass Teams, die neue Funktionen entwickeln, 70 % ihres Designs über Blade abwickeln; für vorhandene Produktoberflächen senken wir dieses Ziel auf 50 %. Es handelt sich um eine gemeinsame Kennzahl für Design und Entwicklung und beide Teams sind motiviert, diese zusammen zu erreichen.
Unser Ziel ist es, Teams in die Lage zu versetzen, moderne und elegante Benutzeroberflächen zu gestalten, während alles Andere durch das Designsystem übernommen wird.
Wir haben jedoch erkannt, dass es bereits auf die Designphase ankommt. Wenn die Designs nicht mit den Komponenten von Blade erstellt werden, wissen Entwickler*innen nicht, dass sie diese ebenfalls verwenden müssen. Hierzu haben wir ein Blade Coverage-Plug-in erstellt, das Designer*innen die Abweichung vom Designsystem anzeigt. Mit dem Plug-in können Designer*innen ihre Zeitpläne für die Einführung 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 Übernahme und Effektivität eines Designsystems vollständig zu erfassen. Wir sind daher auch auf interne Befragungen und Fokusgruppen angewiesen. Mit solchen eher qualitätsorientierten Maßnahmen gelingt es uns, Stimmungen zu erfassen, wie zum Beispiel ob Teams den Eindruck haben, dass sie mit Blade schneller liefern können. Außerdem erhalten wir Feedback zu Nutzererlebnis, Dokumentation, Schulungen sowie zur Zusammenarbeit zwischen Designer*innen und Entwickler*innen. All dies wird in einem Net Promoter Score zusammengefasst, den wir auf Jahresbasis ermitteln.
Wie gestaltete sich die Zusammenarbeit bei Handoff und Entwicklung im Team vor der Nutzung von Dev Mode?
Beim Handoff wird von Entwickler*innen erwartet, alle Elemente zu begutachten und die Eigenschaften entsprechend zu kopieren. Die ursprüngliche Vorgehensweise war nicht ideal. 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 drei Monaten ein proprietäres Plug-in namens RazorSharp entwickelt. Dies hat uns ermöglicht, äquivalenten Code für die Designs automatisch zu generieren. Die Entwickler*innen mussten diesen dann nur noch kopieren und einfügen.
Das RazorSharp-Plug-in hat für Abhilfe bei einigen Schwierigkeiten gesorgt, 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.
Wie wurden diese Probleme gelöst?
Die meisten Schwierigkeiten bei der Überprüfung spielen inzwischen bei uns keine Rolle mehr. Nachdem Figma Dev Mode eingeführt hat, 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 überführen 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.
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 beim Wechsel zwischen Figma und der Programmierumgebung den Kontext aus dem Blick zu verlieren. Das Box-Modell hilft den Entwickler*innen, die Designs innerhalb von Figma und möglichst nahe am Code zu visualisieren. Mit dem Vergleich 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.
Wie haben sich diese Änderungen auf die Produktivität und die Übernahme von Designsystemen ausgewirkt?
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.
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 Sie mehr über unser proprietäres Plug-in zur Codegenerierung erfahren möchten, lesen Sie die Dokumentation für Entwickler*innen von Figma oder nutzen Sie unser Beispiel für das Codegen-Plug-in auf GitHub.