So erreichen Sie eine breite Akzeptanz Ihres Entwurfssystems

Nutzung der Dokumentation zur Förderung des Miteigentums zwischen Design und Entwicklung

Dieser Beitrag ist der zweite in einer Reihe über HubSpot Canvas, unsere neue Designsprache. Lesen Sie das erste hier.

Ich kam zu HubSpot als Software-Engineering-Genossenschaft, als gerade eine Bewegung wuchs. Das Designteam hatte in den vergangenen Monaten eine Reihe neuer Typografien, Farben und grundlegender Komponenten geschaffen, die den Grundstein für eine umfassende Neugestaltung unserer gesamten Plattform bilden sollten.

Da es zuvor keinen einzigen Styleguide gab - keine einzige Quelle der Wahrheit - bedeutete dies in Wirklichkeit, dass wir das Frontend unseres Produkts komplett neu schreiben mussten. Es bedeutete, dass wir die Arbeit von mehr als 40 Teams unterbrechen und Hunderte von Seiten mit einem komplett neuen Satz von Komponenten neu erstellen mussten, um das Redesign zum Leben zu erwecken.

Ich bin dem Front-End-Infrastruktur-Team von HubSpot beigetreten, dem Team, das für die Entwicklung unseres internen Build-Systems und die Unterstützung der HubSpot-Entwickler beim Testen bis zu Abhängigkeiten von Drittanbietern verantwortlich ist. Sie waren die natürliche Wahl, um die Neugestaltung voranzutreiben, und fünf Entwickler, darunter ich, waren bestrebt, jedem Team dabei zu helfen, auf unser neues Design-System, HubSpot Canvas, aufzurüsten. Als ich meinen Auftrag bekam, war mein erster Gedanke: Am besten. Job. Je. gefolgt von: Wow. Das scheint eine Menge Arbeit zu sein.

Und es war viel Arbeit. Aber es wäre viel mehr Arbeit gewesen, wenn wir nicht eine wichtige Lektion gelernt hätten:

Redesigns funktionieren nur im gemeinsamen Besitz von Designern und Entwicklern.

Wir haben dieses Miteigentum größtenteils durch den Bau guter Werkzeuge und Unterlagen gefördert. Unsere Dokumentation ist eine Quelle der Wahrheit für alle im Team, und die Tools, die unsere Designer und Entwickler verwenden, spiegeln sich gegenseitig wider, geben jedem eine gemeinsame Sprache und machen ihn zu Partnern in der Verantwortung für unser Design-System.

Dies ist die Geschichte, wie die Dokumentation uns nicht nur geholfen hat, ein massives Redesign durchzuführen, sondern als Team besser zu werden.

Gegenwind und Rückenwind

Bei jedem großen Projekt wirken Kräfte zu Ihren Gunsten (Rückenwind) und Kräfte gegen Sie (Gegenwind). In unserem Fall waren sie:

Die Rückenwinde

Unser gesamtes Produkt befand sich auf einem ziemlich ähnlichen technischen Stack. Das JavaScript-Ökosystem kann sich im Handumdrehen ändern, und ich hätte nie erwartet, dass ein Unternehmen mit HubSpot-Größe auf demselben Stack liegt. Aber eine von Entwicklern betriebene Bewegung zu React und von Backbone weg war weitgehend erfolgreich gewesen. Dies bedeutete, dass Teams ihre Apps neu gestalten konnten, ohne auf einen neuen Stack umsteigen zu müssen, und dass mein Team die Konsistenz relativ einfach aufrechterhalten konnte.

Wir hatten bereits die Voraussetzungen für eine wiederverwendbare Komponentenbibliothek und ein entsprechendes Dokumentationswerkzeug. Als die Teams zu React wechselten, hatte einer unserer Ingenieure eine wiederverwendbare React-Komponentenbibliothek mit einfach zu wartenden, codierten Beispielen erstellt, die inline bearbeitet werden konnten. Das bedeutete, dass wir unsere Dokumentation nicht von vorne beginnen mussten.

Der Gegenwind

Im Gegensatz zu unseren Apps haben unsere Bibliotheken keine spezielle QS-Phase. Ich war von einem Finanzsoftware-Unternehmen gekommen und habe wahrscheinlich meinen technischen Leiter gefragt, wo die QS-Ingenieure in meiner ersten Woche fünf Mal waren, bevor es wirklich einsetzte. Wir waren nicht nur auf dem Haken, unsere eigene Qualitätssicherung zu machen, sondern jede Änderung Die von uns vorgenommenen Änderungen werden von allen zukünftigen Builds übernommen. Da unsere Teams mehr als tausend Mal am Tag eingesetzt werden, bedeutet dies, dass alle Änderungen an den Komponenten sofort für jede App übernommen werden.

Wir brauchen koordinierte Anstrengungen zwischen dem Front-End-Infrastrukturteam und den Produktteams, um sicherzustellen, dass alle Bildschirme zum Zeitpunkt des Starts bereit sind, und gleichzeitig darauf zu achten, dass keine ungewollten Fehler im Produkt auftreten. Solange wir uns jedoch schnell bewegten und es uns leicht machten, alle schlechten Änderungen rückgängig zu machen, konnten wir den Schaden minimieren.

HubSpot Product besteht aus kleinen, autonomen Teams. Die Teams von HubSpot sind vollständig im Besitz eines Teils des Produkts und haben die Freiheit und Befugnis, nach Lösungen zu suchen, diese zu iterieren und zu finden. Wir hatten die Befürchtung, dass es schwierig sein könnte, ein neues Design-System zu implementieren, das die Kohärenz mit Teams gewährleistet, die eine so starke Kultur und Geschichte in Bezug auf Autonomie haben.

Während der Umstellung müssten sie ganz aufhören, an neuen Funktionen zu arbeiten, und wir würden auch die Prozesse und Standards entwickeln, die das gesamte Team für die weitere Entwicklung benötigen würde. Es besteht ein empfindliches Gleichgewicht zwischen der Unterstützung Ihrer Mitarbeiter mit einem System und dem Verlust ihrer Kreativität. Wir waren jedoch auch zuversichtlich, dass wir durch das Entfernen sich wiederholender Probleme auf niedriger Ebene von den Tellern unserer Mitarbeiter diese kreative Energie in die Lösung größerer Probleme leiten können.

Unsere Sorgen waren größtenteils unbegründet. Auch die Teams waren zu einer systemweiten Neugestaltung bereit, weil:

  1. Niemand musste seinen Stack oder seine Geschäftslogik ändern.
  2. Inkonsistenz zog uns runter. Produktmanager sahen es in Benutzer-Feedback. Designer sahen es in den zahlreichen Grautönen unseres Produkts. Entwickler sahen darin viel zu viele Date Picker Libraries. Eine zuverlässige, wiederverwendbare Komponentenbibliothek, die von einem anderen Team erstellt und gewartet wurde, klang wie ein süßer Deal.
  3. Unser neues Designsystem, HubSpot Canvas, sah gut aus. Sehr gut.

Vom Projekt zum Prozess

Wenn andere Unternehmen große Umgestaltungen vornehmen, werden sie häufig mit großer Aufregung enthüllt, z. B. indem sie ein Blech von einem Auto abziehen - gestern hatten Sie das alte und heute haben Sie das brandneue.

Das würde für uns nicht funktionieren.

Unser Produkt und unser Produktteam waren einfach zu groß, um alles auf einmal zu erledigen. Wir entschieden uns stattdessen, Teile des Produkts einzeln zu behandeln, angefangen bei denjenigen, die weniger Benutzer hatten, und schrittweise zum Kern der Software überzugehen. Dieser Prozess wäre weitaus weniger störend und hätte zur Folge, dass wir das Design-System verbessern könnten, bevor es weitgehend übernommen wurde.

Wir wollten schnell vorankommen und legten einige Regeln fest. Wir haben betont, dass der erste Durchgang nur eine visuelle Aktualisierung ist - keine neue Funktionalität. Wir wollten unser Haus neu streichen, keinen Anbau bauen. Wenn Teams während der Neuerstellung ihrer Produkte neue Funktionen hinzufügen, wird die Zeitleiste auf unbestimmte Zeit verschoben.

Anhand der ersten Arbeit jedes Designteams als Leitfaden haben wir eine Handvoll vorhandener Komponenten in eine grundlegende Sammlung reaktionsschneller, barrierefreier und browserkompatibler React-Komponenten umgewandelt. Um die Arbeit schnell erledigen zu können, haben wir in den Apps der Teams gearbeitet und die Komponenten selbst ausgetauscht.

Aber.

Es war nicht schnell. Wir hatten nur fünf Ingenieure in unserem Team und arbeiteten in unbekannten Codebasen. Die Arbeit ging also langsam voran. Und noch schlimmer, da wir das Design-System implementierten, hatte das App-Team nicht die Möglichkeit, die Design-Sprache selbst zu beherrschen, und ließ ihnen eine App voller Code-Teile, die sie kannten, und Teile, die ihnen völlig fremd waren. Wir haben erkannt, dass dieses Redesign von einem praktischen Projekt zu einem echten Prozess werden muss, den die Teams selbst in Angriff nehmen können.

Deshalb haben wir begonnen, diesen Prozess zu vereinfachen, indem wir Unterstützung geleistet und die Komponentenbibliothek aufgebaut und gewartet haben. Wir haben mit dem Designteam zusammengearbeitet, damit jeder Produktdesigner seinen Teil des Produkts mit einem Sketch-Kit neu gestaltet, das alle Elemente unseres Designsystems enthält. Anschließend haben wir mit jedem Team eine Komponentenüberprüfung durchgeführt, um nach potenziellen neuen Komponenten, neuen Variationen oder neuen Funktionen für bereits vorhandene Komponenten zu suchen.

Dann erstellte mein Team Probleme in GitHub, damit wir während der Erstellung von Komponenten weiterhin bei der Entwicklung und beim Design zusammenarbeiten und jedes Team den Fortschritt der benötigten Komponenten verfolgen konnte. Wir haben das Timing der einzelnen Apps gestaffelt, um sicherzustellen, dass der Rückstand unseres Teams den Fortschritt der Neugestaltungen anderer Teams nicht verlangsamt.

Für eine Weile war es glattes Segeln. Als die Teams ihre Neugestaltungen abgeschlossen hatten, kehrten sie zur Arbeit mit Funktionen zurück. Ihre Apps enthielten glänzende, neue Komponenten.

Manchmal wussten die Teams jedoch nicht, wie oder wann eine Komponente richtig verwendet werden sollte oder ob das Verhalten einer Komponente beabsichtigt war oder nicht. Als sie uns ihre Fragen stellten, wurden wir mit Fragen und Aufforderungen zur Klärung bombardiert. Wir fielen immer weiter zurück, als wir versuchten, die Teams zu unterstützen, die fertig waren, und unterstützten die Teams auch bei ihren eigenen Neugestaltungen.

Die Lösung lag auf der Hand, wäre aber nicht einfach.

Wir brauchten eine bessere Dokumentation.

Einen Living Style Guide erstellen

Gute Dokumentation ist einfach zu verkaufen. Jede Sekunde, die Sie damit verbringen, eine klare Dokumentationszeile zu schreiben, spart Ihnen in Zukunft eine unermessliche Menge an Zeit. Sie müssen beispielsweise versuchen, sich an die brillante Sache zu erinnern, an die Sie gedacht haben, bevor Sie einen Link ausgegraben haben, um ihn Ihrem Kollegen zu erklären Wieder der Unterschied zwischen einem Tooltip und einem Popover. Sie sollten diese Zeit mit neuen Problemen verbringen, nicht mit Problemen, die bereits besprochen, gelöst und beigelegt wurden.

Wir wussten, dass wir unsere Dokumentation haben wollten:

  • Leicht auffindbar. Wir wollten nicht, dass jemand Zeit damit verbringt, eine Komponente oder Variation zu erstellen, die bereits existiert, oder dass er einen Gatekeeper fragt, wo sie lebt.
  • Relevant und hilfreich. Es sollte die endgültige Ressource für das Entwurfssystem sein, und jeder sollte zuversichtlich sein, Antworten auf seine Fragen zu finden.
  • Selbstwartend und automatisiert, damit nichts veraltet wird.

Samen einpflanzen

Um unser Dokumentationswerkzeug richtig zu machen, haben wir uns dazu entschlossen, es so zu erstellen, wie wir Produkte für unsere Kunden erstellen. Wir haben zunächst verschiedene Mitarbeiter des Produktteams interviewt, sowohl Designer als auch Entwickler, von denen, die seit Jahren bei HubSpot sind, bis zu denen, die gerade beigetreten sind. Wir haben eine Übung zum Sortieren von Karten erstellt, in der wir Screenshots vorhandener Komponenten ausgedruckt und HubSpotters gebeten haben, die Komponente zu benennen, dann die Komponenten kategorisch zu sortieren und diese Kategorie zu benennen.

Überraschenderweise stellten wir eine große Diskrepanz zwischen der Sprache fest, in der Entwickler und Designer über unsere Komponenten sprachen. Entwickler verweisen in anderen Front-End-Bibliotheken und Frameworks (wie jQuery und Bootstrap) häufig mit ihrem Namen auf Objekte. Designer bezeichnen Komponenten normalerweise mit den Namen ihrer Schwesterkomponenten im Material Design System von Google. Es wurden Personen gefunden, die dasselbe Wort für zwei sehr unterschiedliche Komponenten oder unterschiedliche Namen für genau dieselbe Komponente verwendeten.

Jeder Designer oder Entwickler wollte unbedingt, dass weniger Möglichkeiten für Entwurfsentscheidungen zwischen der beabsichtigten Benutzererfahrung (dem Modell des Designers) und der tatsächlichen (der Implementierung des Entwicklers) bestehen. Und sie wussten, dass es nicht nur Aufgabe des Designs oder der Entwicklung war - es lag in der Verantwortung aller.

Anstatt eine weitere Komponentenbibliothek zu erstellen, die sich ausschließlich an Entwickler richtet, mussten wir eine Ressource erstellen, die der Hub für alle im Team sein sollte. Diese Dokumentation und Tools würden Designer und Entwickler gemeinsam an dem Design-System beteiligen.

Wir haben zunächst einige Komponenten umbenannt, einige Komponenten mit Tags versehen, damit sie bei der Suche leichter auffindbar sind, und zu Beginn des Komponentendesigns nach vorgeschlagenen Komponentennamen gefragt, damit Designer und Entwickler gemeinsam über den richtigen Namen entscheiden können. Wir haben auch Komponentenfamilien aufgrund ihrer Ähnlichkeiten zusammengefasst. So befinden sich jetzt beispielsweise alle Komponenten, die für Warnungen und Nachrichten verwendet werden, auf derselben Seite.

Damit Designer nahtlos zwischen Sketch und der Komponentendokumentation wechseln können, haben wir beschlossen, Navigation, Struktur und Terminologie im Sketch-Kit und in der UI-Bibliothek zu spiegeln und ein System zu entwickeln, mit dem Aktualisierungen des Sketch-Kits und der UI-Bibliothek synchronisiert werden .

Voller Blüte

Mit den Grundlagen haben wir uns an die Arbeit gemacht, um die tägliche Arbeit von Designern und Entwicklern viel einfacher und effizienter zu gestalten, indem wir den Rest der Erkenntnisse aus unserer Forschung zum Leben erwecken.

Die Entwickler gaben an, dass sie häufig Probleme haben zu wissen, welche React-Komponente mit der im Modell ihres Designers übereinstimmt. Daher haben wir eine visuelle Suchebene mit echten, automatisch generierten Screenshots hinzugefügt, um das Auffinden der gesuchten Komponente zu vereinfachen. Sie brauchten auch einen Ort, an dem sie alle Optionen jeder Komponente sehen konnten, und einen Ort, an dem sie Informationen über die API der Komponente finden konnten. Deshalb haben wir diese in der Komponentenbeschreibung in den Vordergrund gerückt.

Die Entwickler benötigten außerdem eine Sandbox, in der sie Komponenten schnell testen konnten. Daher verbesserten wir die Bearbeitungsmöglichkeiten für Komponenten in der Bibliothek in Echtzeit, indem wir einen React-Code-Editor einbauten, in dem alle unsere Komponenten enthalten waren (einschließlich Syntaxhervorhebung und hübscherer Funktionen). Wir haben es auch einfach gemacht, diese Beispiele in einen ablenkungsfreien Editor zu verschieben, mit dem auch Komponenten sofort gerendert werden können. Entwickler können ihn daher verwenden, um die Anfänge eines Designs zu erstellen oder eine bestimmte Kombination von Komponenten zu testen. Anschließend können sie es problemlos mit anderen HubSpottern teilen und so schnell Ideen und Lösungsvorschläge durchlaufen, debuggen und bequem austauschen.

Die Designer brauchten einen Ort, an dem sie auf Assets verweisen und diese freigeben konnten. Daher haben wir Browsing-Seiten für unsere Richtlinien zu Farben, Typografie, Illustrationen, Symbolen und Produktkopien mit einem Link zum Herunterladen der aktuellsten Version des Sketch-Kits erstellt. Wir haben auch unseren gesamten Designprozess in der UI-Bibliothek dokumentiert, um neuen Designern dabei zu helfen, sich auf dem Laufenden zu halten.

Weder Designer noch Entwickler waren sich immer sicher, welche Komponenten es dem Benutzer ermöglichen würden, ein bestimmtes Interaktionsmuster zu vervollständigen (z. B. das Kopieren einer URL oder das schrittweise Durchlaufen eines Ablaufs). Deshalb haben wir Musterseiten erstellt, um zu erklären, welche Komponenten und welche Kopie erforderlich sind wird in allgemeinen Benutzerszenarien verwendet.

Wir wollten mehr Entwickler in die Designsprache einbinden, deshalb gaben wir Richtlinien für die Erstellung von Komponenten bekannt und begannen, auf unseren Basiskomponenten aufzubauen, indem wir sie mit unseren bevorzugten Open-Source-Bibliotheken kombinierten. Dies bot die Freiheit, mit neuen Tools aus der OSS-Community zu experimentieren, unserem Stack mehr Funktionalität und Produktivität hinzuzufügen und offen gesagt allen Entwicklern bei HubSpot, die erstellen wollten, das Erstellen zu ermöglichen. Weil wir darauf abzielen, unsere Komponenten als visuelle Grundlage für alle unsere Front-End-Apps zu verwenden, die viel Platz für (und Bedarf für) zusätzliche Ebenen darüber ließen. Dies machte die Entscheidung für Konsistenz für unsere Entwickler trivial.

Um die Benutzer zu ermutigen, täglich mit dieser Dokumentation zu interagieren, haben wir Schaltflächen hinzugefügt, um eine neue Komponente vorzuschlagen, eine Änderung an einer vorhandenen Komponente vorzuschlagen, einen Fehler zu melden oder eine Illustration direkt aus der Bibliothek anzufordern. Diese Schaltflächen füllen GitHub-Probleme vorab mit den erforderlichen Beschriftungen und relevanten Fragen, damit sie in unserem Prozess in die Warteschlange gestellt werden. Dies gibt neuen Designern und Entwicklern einen zentralen Anhaltspunkt für das Erlernen der Verwendung des gesamten HubSpot Canvas-Ökosystems vom ersten Tag an.

Der Effekt

Jetzt teilen unsere Designer und Entwickler eine Quelle der Wahrheit für unser Designsystem und das gegenseitige Verständnis hat zugenommen. Ein höheres Vertrauen in die Dokumentation zeigt ein höheres Vertrauen in das Gesamtsystem. Ich war so stolz, diesen Tweet vor ein paar Wochen von einem unserer Front-End-Tech-Leads gesehen zu haben:

Wir führen zweimal im Jahr eine Plattforminfrastruktur-Umfrage für alle unsere Ingenieure durch. Seitdem wir Fragen zu unserer UI-Bibliothek aufgenommen haben, haben wir wiederholt folgende Antworten erhalten:

100.000 / 10
Oh Gott, das Frontend-UI-Framework ist umwerfend und jedem Open Source-UI-Framework um Lichtjahre voraus

Unsere Arbeit, unsere Dokumentation zu einem gründlichen, lebendigen Dokument zu machen, wird niemals zu Ende gehen. Mit solchen Rückmeldungen können wir jedoch feststellen, dass wir auf dem richtigen Weg sind.

Überzeugen Sie sich selbst

Hier sehen Sie, wie schnell Sie mit einer vorgefertigten Vorlage beginnen und dann mit dem Sandbox-Editor in unserer UI-Bibliothek eine Seite erstellen können.

Wir haben eine Version unserer HubSpot Canvas-UI-Bibliothek veröffentlicht. Darin finden Sie eine Teilmenge unserer Komponenten und Stile, die direkt aus unserem Produktionscode entnommen wurden. Es ist ein Fenster in die Art und Weise, wie wir unsere Produkte hier bei HubSpot herstellen, und wir teilen es, weil wir stolz auf die Zeit und Mühe sind, die wir in die Erstellung und Optimierung unseres Design-Systems für Entwickler und Designer gesteckt haben, damit es immer grün bleibt . Wir laden Sie ein, einen Blick darauf zu werfen und Ihre Gedanken zu teilen - wir können es kaum erwarten, sie zu hören.

Credits:
Illustrationen von Sue Yee

Ursprünglich im HubSpot-Produktblog veröffentlicht