Eines der schwierigsten Dinge für jemanden, dem Designsysteme sehr am Herzen liegen, ist die Begründung für ein dediziertes Designsystem. Leute in Führungspositionen werden Sie oft bitten, dessen Wert zu beweisen. Warum sollten wir uns für gutes Front-End-Development und Konsistenz interessieren? *Sicher, sicher, sicher*, sagen sie – jeder möchte ein schickes Designsystem – *aber ist es den Kosten wert*?
Diese Frage ist schwierig, da Entwicklerproduktivität, Front-End-Qualität und sogar Zugänglichkeit bis zu einem gewissen Grad so nebulöse Dinge sind. Im Gegensatz dazu ist dies eines der intelligentesten Dinge an Googles Core Web Vitals, da es das Problem in Zahlen fasst und sehr umsetzbare nächste Schritte bietet.
Wenn es um Designsysteme geht, haben wir keine wirklichen Metriken, auf die wir zeigen und sagen könnten: „Ah, ja, ich muss Leute ins Designsystem-Team stecken, damit wir unser Designsystem von einem schlechten Ergebnis von 60/100 verbessern können.“ Es wäre toll, wenn wir das hätten, aber ich glaube nicht, dass wir das jemals tun werden.
Hier kommt Sparkbox ins Spiel. Sie wollten dies beheben, indem sie testeten, wie viel schneller ihre acht Entwickler in einem kleinen Test waren. Sie ließen ihre Entwickler eine Formularvorlage von Hand erstellen und dann noch einmal mit dem Carbon Designsystem von IBM, das sie noch nie zuvor benutzt hatten.
Die Ergebnisse sind super interessant:
Die Verwendung eines Designsystems machte eine einfache Formularseite bei der Entwicklung 47 % schneller als die manuelle Erstellung von Grund auf. Die mediane Zeit für die manuellen Erstellungen betrug 4,2 Stunden, verglichen mit 2 Stunden medianer Zeit für die Carbon-Erstellungen. Die Carbon-Zeit beinhaltete die Zeit, die die Entwickler mit der Einarbeitung in das Designsystem verbrachten.
Stellen Sie sich nun vor, diese Entwickler wären mit dem Carbon-Designsystem *vertraut* gewesen! Wenn das der Fall gewesen wäre, stelle ich mir vor, dass die Zeit für die Erstellung dieser Formulare noch viel, viel schneller gewesen wäre als diese anfänglichen Ergebnisse.
Die Methodik der Studie scheint etwas fragwürdig. Alle 8 Entwickler haben zuerst das Formular von Grund auf neu codiert und *dann* mit Carbon erneut codiert. Das bedeutet, dass jegliche Zeit, die mit dem Verständnis des Formular-Designs verbracht wurde, gegen den manuellen Test und nicht gegen den Carbon-Test gezählt wird.
Zum vorherigen Kommentar. Die Methodik ist völlig in Ordnung. Sie macht das Designsystem trotzdem schneller. Wenn man die Zeit, die sie für das Erlernen des Carbon-Systems benötigen, abzieht, ist es jetzt weniger als 2 Stunden!
Ich entwickle diese seit etwa sieben Jahren in verschiedenen Unternehmen. Damit sie funktionieren, müssen sowohl Entwicklung als auch Design absolut hinter dem Ansatz stehen und mit dem Prozess vertraut sein.
Wenn das Designteam die Angewohnheit hat, Sonderfälle einzuführen, oder wenn die Entwicklung die Komponenten noch nicht übernommen hat, wird die erste Iteration sehr steinig und kostspielig sein.
Es scheint, dass Sparkbox von Anfang an viele sachkundige Leute zur Verfügung hatte, was Glück ist. Für die meisten Organisationen würde ich vorschlagen, dass das Designteam ein Designsystem entwirft und es als PDF (etwas sehr technisch Einfaches) liefert, und dass die Entwicklung es manuell in einem kleinen Projekt befolgt, damit jeder die Feinheiten der Konsistenz des Designs versteht. Dann steigert man sich allmählich zur „lebenden“ Version.