Denken Sie in letzter Zeit über Styleguides nach? Mir scheint, dass es heutzutage kein heißeres Thema geben könnte. Ich freue mich, das zu sehen, als jemand, der versucht hat, auf diese Weise zu denken und zu bauen, als die vorherrschende Weisheit lautete: nette Idee, aber das funktioniert nie. Ich vermute, es gibt dreierlei Gründe, warum Styleguides und Designsysteme so populär geworden sind.
- Komponentenbasierte Front-End-Architekturen, die sehr beliebt werden.
- Styling-Philosophien, die Styles scope-fähig machen, werden sehr beliebt.
- Eine Veränderung der Einstellung in der Community, dass Styleguides funktionieren.
Das Letzte kommt mir irgendwie wie Kryptowährung vor. Wenn jeder an den Wert glaubt, funktioniert es. Wenn die Leute aufhören, an den Wert zu glauben, stirbt es.
Wie auch immer, bei meinen typischen Kaffee-und-RSS-Morgen bin ich auf einige kürzlich erschienene Artikel über Styleguides gestoßen, also dachte ich, ich fasse sie für Ihr Vergnügen zusammen.
Wie man ein Designsystem mit einem kleinen Team aufbaut von Naema Baskanderi
Als kleines Team, das an B2B-Enterprise-Software arbeitet, haben wir uns an die Erstellung eines Designsystems mit begrenzter Zeit, Budget und Ressourcen gemacht … Wo fängt man an, wenn man nicht genug Ressourcen, Zeit oder Budget hat?
Ihre fünf Tipps scheinen für mich zu stimmen.
- Fangen Sie nicht bei Null an.
- Wissen Sie, womit Sie arbeiten (eine Bestandsaufnahme).
- Bauen Sie nebenbei auf.
- Kennen Sie Ihre Grenzen.
- Bleiben Sie organisiert.
Styleguide-gesteuerte Designsysteme von Brad Frost
Ich lasse Teams oft am ersten Tag ihrer Designsystem-Initiative die Styleguide-Website einrichten. Ein Styleguide dient als Schaufenster, das alle Bestandteile des Designsystems präsentiert und als greifbares Zentrum der Masse für das gesamte Vorhaben dient.
This Also veröffentlichte seinen Styleguide (Hier sind 100 weitere, wenn Sie gerne Einblicke in die Ansichten anderer Leute zu dieser Art von Dingen erhalten).
Bemerkenswert daran ist für mich, dass es der Bedeutung von Styleguide am nächsten kommt (im Gegensatz zu einer Pattern Library oder einem Designsystem, die eher Gestaltungsanweisungen für den Aufbau von Website-Teilen sind). Sie enthalten nur die drei Dinge, die für ihre Marke am wichtigsten sind: Typografie, Schreiben und Identität. Klug.
Alles, was Sie schreiben, sollte leicht verständlich sein. Klarheit im Schreiben folgt normalerweise Klarheit im Denken. Nehmen Sie sich Zeit, darüber nachzudenken, was Sie sagen wollen, und sagen Sie es dann so einfach wie möglich. Beachten Sie diese Regeln, wenn Sie im Namen des Studios schreiben.
Grundlagen für Systemdesign schaffen von Andrew Couldwell
Ich verwende den Begriff „Grundlagen“ als Teil einer Hierarchie für Designsysteme und Denken. Stellen Sie sich die Grundlagen als digitale Markenrichtlinien vor. Sie inspirieren und ergänzen unsere Designsysteme und leiten alle unsere digitalen Produkte an.
- Auf Markenebene decken sie Dinge wie Werte, Identität, Tonfall, Fotografie, Illustration, Farben und Typografie ab.
- Auf digitaler Ebene decken sie Dinge wie Formatierung, Lokalisierung, Call-to-actions, responsives Design und Barrierefreiheit ab.
- Und in Designsystemen bilden sie die Grundlage für und decken die Anwendung von Dingen wie Textstilen, Formularfeldern, Schaltflächen und responsiven Grids ab.
Wieder ein Schritt zurück und ein weiter Blick. Ja, ein Designsystem, aber eines, das mit Markenwerten zusammenarbeitet.
Wie man einen lebendigen Styleguide erstellt von Adriana De La Cuadra
Ähnlich wie ein Standard-Styleguide bietet ein lebendiger Styleguide einen Satz von Standards für die Verwendung und Erstellung von Stilen für eine Anwendung. Bei einem Standard-Styleguide besteht der Zweck darin, die Markenkohäsion zu erhalten und den Missbrauch von Grafiken und Designelementen zu verhindern. Ebenso werden LSGs verwendet, um die Konsistenz in einer Anwendung aufrechtzuerhalten und ihre Implementierung zu steuern. Aber was einen LSG unterscheidet und leistungsfähiger macht, ist, dass ein Großteil seiner Informationen direkt aus dem Quellcode stammt.
Eine einfache erste Reaktion könnte sein: Natürlich ist unser Styleguide „lebendig“, wir wollen keinen toten Styleguide bauen. Aber ich denke, es ist eine interessante Unterscheidung. Styleguides können an verschiedenen Stellen in Ihrem Entwicklungsprozess angesiedelt sein, wie ich vor einigen Jahren geschrieben habe.
Es ist nur zu leicht, einen Styleguide zu erstellen, der am Rande des Prozesses steht oder „der Abfall“ des Prozesses ist. Es ist etwas ganz anderes, Ihren Styleguide mitten in einen Entwicklungs-Workflow zu platzieren und kein Umgehen zuzulassen.
Zuletzt rundet Punit Web einige sehr neu veröffentlichte Styleguides ab, falls Sie sich besonders für frische interessieren, die Sie vielleicht noch nicht gesehen haben.
Mein Punkt wäre, dass der Styleguide vom Designteam aufgeschrieben werden muss. Der Geist der Dinge und wie sie tatsächlich aussehen.
Dann kann das Entwicklungsteam eine Art Kopie dieses Styleguides erstellen, die die tatsächliche Implementierung zeigt und vielleicht erklärt, wie man diese oder jene Komponente erreicht.
Das Problem, das ich bei einem „lebendigen Styleguide“ sehe (einem Guide, der automatisch aktualisiert wird, sobald man eine Definition in seinem Code hinzufügt), ist, dass wenn man einen Stil erstellt, der keine vorherigen Einschränkungen berücksichtigt, er trotzdem Teil des Styleguides wird. Eine gebrochene Regel wird zur Regel.
Aus Designperspektive, wenn ich oft das einzige UX-Team war und als jemand spreche, der mehr CSS als üblich kennt, aber vehement kein Front-End-Entwickler ist.
Es gibt wunderbare Komponentenbibliotheks-Tools (Fractal fällt mir ein), aber die meisten davon sind entwicklerzentriert. Um sie zum Laufen zu bringen, müssen Sie Node, Build-Toolchains, Task-Runner und JSDoc und/oder Git usw. verstehen. Dies wird zu einer Barriere, wenn nicht jeder beitragen kann.
Zum Beispiel gibt es nicht viele CMS-Themes, die sich für die Erstellung von Stil- und Komponentendokumentationen mit beliebten Tools wie WordPress eignen. (Vielleicht mit einem CodePen Custom Field Plugin?)
Es gibt eine Handvoll Designer-orientierter SaaS-Tools zur Erstellung von Online-Styleguides, wie Frontify, aber die meisten versagen, wenn es um Live-Code-Vorschauen geht (CSS war, zumindest als ich es ausprobierte, undicht).
Und natürlich gibt es wenige bis gar keine wirklich guten WYSIWYG-Tools für Web-Prototyping oder Stilerstellung. (Ich warte darauf zu sehen, ob Invision Studio der heilige Gral sein wird, den es verspricht).
Idealerweise würden ein Designer + Entwickler als Team zusammenarbeiten, um es zu erstellen – aber öfter als wir zugeben, arbeiten nicht-codierende Designer in ihrem eigenen Silo und erstellen viele statische Comps und Google Docs, die, wie wir alle wissen, fast sofort veralten, was eine Zeitverschwendung ist, wenn sie Prototypen erstellen und Stil-Dokumente für ein gemeinsames Werkzeug beitragen könnten.
Wenn Styleguides / Komponentenbibliotheken also wirklich übernommen werden sollen, müssen sie sowohl für Designer als auch für Entwickler benutzerfreundlich sein.
Ich würde sagen, ein guter Kompromiss ist, eine „Vanilla“-Kanonische Version einer Komponente in reinem HTML/CSS/JS als visuelle und Interaktionsdesign-Referenz zu haben, neben Code, der für ein oder mehrere Frameworks angepasst ist… sonst müssen Sie Ihr Werkzeug vielleicht innerhalb des Frameworks erstellen, das Sie verwenden, damit die Komponente richtig gerendert wird.
Und was passiert, wenn Sie diese Stile in ein anderes Framework portieren müssen (z. B. wenn Ihr Unternehmen ein ergänzendes Produkt erwirbt oder Sie ein Front-End für einen Kunden anpassen usw.?)