Visueller Wandel in Designsystemen

Wir respektieren Code-APIs. Aber was ist mit Farbe, Typ und Raum?

# 4 of 6 der Reihe Releasing Design Systems:
Ausgänge | Trittfrequenz | Versionen | Brechen | Abhängigkeiten | Verarbeiten

Konstruktionssysteme legen einen grundlegenden visuellen Stil fest, der eine wesentliche Abhängigkeit darstellt. Diese Auswahlmöglichkeiten - Farbe, Typografie, Raum und mehr - sind streng spezifiziert und es wird erwartet, dass sie Release für Release stabil und vorhersehbar ändern. Wenn ein Anwender ein Upgrade durchführt, sollte ein Design-System seine Fähigkeiten nicht unerwartet beeinträchtigen.

Also, frag dich ...

Können Anwender, die ein Upgrade auf ein Minor-Release durchführen, sicher sein, dass ihre Benutzeroberfläche nicht aufgrund der visuellen Änderungen eines Systems unterbrochen wird?

Semantic Versioning (SemVer) bietet klare Kriterien, um Änderungen über Releases hinweg mit den Bezeichnungen Major, Minor und Patch zu kommunizieren. Jedes Entwurfssystem, dem ich begegne, verwendet SemVer und überwacht Änderungen in der Anwendungsprogrammierschnittstelle oder API des Pakets. Dies ist ein vertrautes Gebiet für Entwickler, die JavaScript-Requisiten und HTML-Markups codieren. Brechen Sie Ihre API, und Ihre nächste Version muss die Version auf eine nächste Hauptversion erhöhen, z. B. von 1.4.0 auf 2.0.0.

Die Angabe einer Schnittstelle zum kompositorischen visuellen Stil entgeht uns. Es ist so schwierig, klare, einfache Regeln für die Überwachung von Stiländerungen zu definieren. Systemhersteller haben Schwierigkeiten, zu artikulieren, was oder warum "das Ändern dieses Stils die Benutzeroberfläche eines Adopters zerstört" im Vergleich zu "das Ändern dieses Stils nicht". Nur wenige Systemteams dokumentieren solche Kriterien. Ich frage: „Welche speziellen Arten von visuellen Änderungen lösen für Sie eine Hauptversion aus?“ Ihre Antwort: ¯ \ _ (ツ) _ / ¯.

In diesem Artikel schlage ich vor, dass mindestens die Kriterien für Farbe, Typografie und Leerzeichen eine bahnbrechende Änderung darstellen. Es sind noch weitere Eigenschaften zu berücksichtigen. Ein Design-System kann diese Kriterien definieren, dokumentieren und kommunizieren, so dass Anwender Release für Release mit Zuversicht aktualisieren können.

Farbe brechen

Die meisten Systemteams fühlen sich sicher, wenn sie die Hintergrundfarbe einer Primärschaltfläche einstellen. Vielleicht liegt ihre Motivation darin, den Kontrast gegenüber einem normalerweise weißen Textetikett zu verbessern. "Lassen Sie uns die Krickente ein wenig abdunkeln", sagen sie. "Wir verbessern den für Schaltflächen zugänglichen Farbkontrast von AA auf AAA."

Anpassen der Hintergrundfarbe einer Primärschaltfläche

Die Annahme von Teams sollte den Farbsatz einer Standard-Primärschaltfläche auf keinen Fall überschreiben. Durch das Überschreiben einer Systemauswahl wird die Verbindung mit einem System getrennt. Zu diesem Zeitpunkt ist ein Adopter auf sich allein gestellt. Daher ist das Anpassen der Hintergrundfarbe des Primärknopfs sicher und keine brechende Änderung.

Das Ändern der Farben an anderer Stelle kann jedoch zu einer Gefährdung der Anwender führen. Stellen Sie sich die folgenden Szenarien vor.

Beispiel: Systemtext auf benutzerdefinierten Hintergründen

Stellen Sie sich vor, ein Systemteam optimiert das interaktive Blau, um den Farbkontrast zu verbessern. Das interaktive Blau von v1.4.0 war auf einem weißen Hintergrund verfügbar, schlug jedoch auf dem Kohlehintergrund fehl.

Farbkontrastprüfung über contrast-grid.eightshapes.com

In Version 1.5.0 hat das Team das interaktive Blau auf einen helleren, gesättigten Farbton eingestellt, der sowohl für Weiß als auch für Holzkohle geeignet ist.

Anpassen der Textfarbe einer Geistertastenbeschriftung auf unvorhersehbaren Hintergründen

Ein Anwender hatte jedoch die von dieser Farbe abhängige Ghost-Schaltfläche auf hellgrauem Hintergrund verwendet. Nach dem Systemwechsel ist der Kontrast der Textfarbe des Etiketts nicht mehr zugänglich. Ihr System hat das Produkt beschädigt.

Beispiel: Systemhintergründe mit benutzerdefiniertem überlagertem Text

Stellen Sie sich vor, ein System verdunkelt die Hintergrundfarbe der Kartenkomponente. Der Inhaltsbereich der Karte enthält eine "sichere" Inhaltscontainerzone, in der Benutzer den gewünschten Inhalt und das gewünschte Markup einfügen können.

Anpassen der Hintergrundfarbe einer Karte, die enthaltenen benutzerdefinierten Inhalt zulässt

In dieser vermutlich sicheren Zone fügte ein Anwender Sekundärtext hinzu, der zwar ein dezentes moderates Grau aufweist, aber einen Farbkontrasttest besteht. Nach dem Systemwechsel ist der Farbkontrast nicht mehr zugänglich. Ihr System hat das Produkt beschädigt.

Stellen Sie sich vor, die Nebenversion Ihres Systems enthält diese Anpassungen. Abwärtskompatibel, sagten Sie? Kein Risiko bei der Aktualisierung, vertrauten sie? Nee! Ihr System hat ihr Produkt kaputt gemacht!

Bewerten Sie daher die geänderten Farbeigenschaften, um festzustellen, ob sich ein System geändert hat, z. B .:

  • Textfarbe, die über der Hintergrundfarbe, dem Bild oder einer anderen Textur eines Anwenders angezeigt werden kann.
  • Hintergrundfarbe, über die die Textfarbe eines Adoptierenden gelegt wird.
  • Hintergrundfarbe, Rahmenfarbe, Textfarbe, Kastenschatten oder eine andere Eigenschaft, die neben, über oder unter dem Rand oder Inhalt einer anderen Komponente angeordnet ist, um den Kontrast zwischen den Elementen zu verringern.

Barrierefreiheit trieb diese Beispiele voran. Es besteht auch das ästhetische Risiko, dass durch wohlmeinende Systemänderungen die von einem Produktdesigner erzielte farbliche Harmonie gestört wird. Auf der gesamten Benutzeroberfläche gibt es eine Fülle von Farbinteraktionen, die ein Systemdesigner nicht steuert oder in die er keinen Einblick hat.

Imbiss: Brechen Sie das Wechselgespräch mit Farbkriterien ab. Es ist einfacher, Risiken zu vermitteln, objektiv messbar und an die Zugänglichkeit gebunden, die Leidenschaften erregt. Mit ein paar Kriterien ausgestattet, können Sie sich anderen Themen widmen.

Typografie brechen (durch Umwickeln)

Typografie ist eine Kernfacette jedes visuellen Stils. Die Teams wollen es genau richtig machen. Und es gibt so viele Einstellmöglichkeiten: Schriftfamilie, Schriftstärke, Schriftgröße, Texttransformation, Zeilenhöhe, Buchstabenabstand und mehr.

Nicht alle Erfahrungen riskieren einen Bruch, wenn ein System die Typografie anpasst. Für inhaltsintensive Erlebnisse kann der Inhalt jedes Elements unvorhersehbar sein, von unterschiedlicher Länge sein und so gestaltet sein, dass er Änderungen in der Breite des Ansichtsfensters umschließt und auf diese reagiert.

Für dichtere Schnittstellen muss die Typografie präzise sein. Designer arbeiten stundenlang an der Feinabstimmung der Typografie und ordnen die Etiketten so an, dass sie in kompakte Bereiche passen. Wenn Sie die Systemtypografie anpassen, werden die Elemente möglicherweise unerwartet umgebrochen oder beschnitten.

Beispiel: Das Umbrechen von Registerkarten ist schrecklich

Stellen Sie sich vor, Ihr System passt das Schriftgewicht der Registerkarten von normal auf fett an.

Nach einem geringfügigen Versions-Upgrade werden nicht reagierende Registerkarten umbrochen. Nicht gut.

Ein Anwender rüstet auf. Die vorhandenen nicht reagierenden Registerkarten überschreiten den zugewiesenen Speicherplatz und werden umbrochen. Grässlich! Ihr System hat das Produkt beschädigt.

Beispiel: Buchstabenabstand Chaos

Markenrichtlinien entwickeln sich und ergeben eine neue Überschriftenhierarchie und einen neuen Stil. So passt sich Ihr System an, indem Sie den Buchstabenabstand der einzelnen Überschriften erhöhen.

Ein Anwender aktualisiert seine dichte, einseitige Radiologie-App, die in 14 Sprachen übersetzt wurde und aus unzähligen Kontrollfeldern besteht, von denen jedes mit Formularelementen und Überschriften gefüllt ist. Sie aktualisieren, und die Benutzeroberfläche ist voll mit unvorhersehbar zugeschnittenen Überschriften. Sie nennen ein Krisentreffen. Sie laden die Back-End-Dateningenieure ein, um Himmels willen! Ihr System hat ihr Produkt kaputt gemacht!

Das Anpassen der Systemtypografie kann gefährlich sein. Für Sie ist es eine erfrischende typografische Entwicklung, die mühelos in einer Bibliothek implementiert werden kann. Für sie beginnt der Text sich schlecht zu benehmen. Sie geben dir die Schuld. Vielleicht haben sie dich im # system-design Slack-Kanal geflammt. Das braucht niemand.

Zum Mitnehmen: Arbeiten Sie vor Version 1.0.0 sorgfältig, um Schriftstile zu experimentieren, zu verfeinern und zu finalisieren, die der Vielfalt des Kunden entsprechen. Sobald 1.0.0 verstrichen ist, sollten Sie eine stabile Basis aufrechterhalten und Änderungen vorsichtig in Betracht ziehen. Ziehen Sie in Betracht, gefährliche Schichten für die nächste Hauptversion zu reservieren. Fügen Sie bis dahin inkrementell enthaltene Features hinzu, z. B. eine Langform-Textkomponente, mit der Sie nur Artikelkopien formatieren können.

Raum und Größe brechen

Zumindest sieht man Farbe und Typografie. Platz und Größe? Es ist schwerer, diese als konkret wiederverwendbar zu definieren, geschweige denn auf Veränderungen hin zu überwachen.

Wenn Sie in HTML die Boxmodelleigenschaften einer Komponente ändern - Abstand, Rand, Breite, Höhe, Anzeige, Boxgröße, Position, Links, Rechts, Oben, Unten -, kann dies Auswirkungen auf die Layout-Komposition haben, die diese Komponente mit anderen Seitenelementen anordnet.

Beispiel 1: Entfernen des vertikalen Abstands

Ihr Systemteam beschließt, Steuerelemente für Formulare mit vertikalem Abstand in Form von Rand unten zu entfernen. Dies wirkt sich auf , , , Mikrokopie und andere Elemente aus.

Ursprünglich mit eingebautem vertikalen Abstand eingestellt, entfernt ein System Ränder. Und so sehen Formen verschmiert aus.

Ein Anwender hatte 38 verschiedene Formen entworfen, die auf diesem Abstand beruhten. Nach dem Systemwechsel trennen alle ihre Formen keine Elemente mehr vertikal. Ihr System hat das Produkt beschädigt.

Beispiel 2: Benutzerdefinierte Dimensionierung basierend auf angenommenem Abstand

Nach ausgiebigen Diskussionen in der Design-Community erweitert Ihr System die Auffüllung des Inhaltsblocks einer Karte.

Eine benutzerdefinierte Symbolleiste wird nach einer Änderung des Abstandes umgebrochen. Ewww.

Ein Anwender hatte die Karten entsprechend den Hardwareeinstellungen seines Kunden angeordnet und dimensioniert. Außerdem wurde in der unteren Zeile eine Symbolleiste nur mit Symbolen hinzugefügt. Nach dem Systemwechsel werden die Symbole in zwei Zeilen umbrochen. Ihr System hat das Produkt beschädigt.

Zum Mitnehmen: Vermeiden Sie zunächst räumliche Regeln (normalerweise Ränder) außerhalb der Grenzen einer Komponente. Zweitens, nehmen Sie räumliche Anpassungen sehr, sehr vorsichtig vor. Die Verschlechterung des Layouts eines Adopters ist eine todsichere Methode, um Reibung zu erzeugen, das Vertrauen zu verringern und eine gerechtfertigte schlechte PR in einer Community zu erzielen.

Enthaltene, nicht brechende räumliche Veränderung

Einige räumliche Änderungen wirken sich nicht auf benachbarte Elemente oder die Seitenzusammenstellung aus. Das Festziehen oder Erweitern des Einfügepolsters oder des Stapelrandes zwischen Elementen in einem Menü stellt beispielsweise keine Änderung dar, da diese Anpassungen in einem Block enthalten sind, der vollständig vom System festgelegt wurde, keine anderen anpassbaren Elemente enthält und in einer Weise überlagert ist Andernfalls wirkt sich dies nicht auf das Seitenlayout aus, wenn es geöffnet und geschlossen wird.

Was kann sonst den visuellen Stil brechen?

Im Allgemeinen können Änderungen des visuellen Stils als Änderungen einer Reihe von CSS-Eigenschaften angegeben werden, für deren Umfang beispielsweise Designtoken-Sammlungen in Salesforce Lightning, Morningstar, REI und Open Table stehen.

Welche anderen Eigenschaften können Sie über die oben beschriebenen Eigenschaften Farbe, Typografie, Raum und Größe hinaus überwachen? Der Z-Index, der auf Komponenten wie Popovers, Dialogfelder, Modale und QuickInfos angewendet wird, ist für die Komposition in der dritten Dimension eines Layouts von zentraler Bedeutung. Eine Opazität, die häufig auf semitransparente Ebenen (z. B. unter einem Modal) angewendet wird, scheint ebenfalls ein guter Kandidat zu sein. Sogar subtile Änderungen wie ein Randboden wirken sich aus.

Anpassen der Randfarben einer Komponente, die in der Nähe anderer Komponenten angeordnet ist
  • Ihr System macht den unteren Rand des letzten Elements einer vertikalen Liste transparent. Ein Anwender hatte diese Liste genau über einem anderen Block positioniert und sich dabei auf die Linie verlassen, um Kontrast zu erzeugen. Nach dem Systemwechsel wird die Kopfzeile des Blocks auf eine Weise mit der Beschriftung des letzten Listeneintrags verschmolzen, die nicht erkennbar ist.
    In diesem Fall hat Ihr System das Produkt beschädigt.

Aber was ist mit der Anpassung des Schattenkastens? Oder Randradius fein einstellen? Queue-Designer-Ambivalenz. Es wäre schwer zu überzeugen, dass diese Anpassungen die Erfahrung eines Adopters zerstören würden.

Zum Mitnehmen: Überprüfen Sie die umfangreiche Sammlung möglicher CSS-Eigenschaften und diskutieren Sie mit Ihrem Team die Konsequenzen von Kandidateneigenschaften. In einer Arbeitssitzung wird die Toleranz der Gruppe für den Schutz von Adoptiveltern deutlich und es wird dokumentiert, wie weit Sie gehen werden.

Also, was ist eine visuelle Veränderung?

Denken Sie an dieser Stelle: Ist das wirklich wichtig? Sollten wir unser System nicht verwenden, um unsere visuelle Sprache zu steuern? Werden sich Adoptierende wirklich darum kümmern?

Ingenieure können sich interessieren. Designer auf jeden Fall kümmern. Sie verbringen Stunden mit der Feinabstimmung von Layouts, der Kommentierung und der Kommunikation von Details mit zusammenarbeitenden Entwicklern. Daher sollte ein Entwurfssystem beschreiben, wie es sich ändert. Und jedes Mal, wenn es sich ändert, wenn es sich um eine Änderung handelt, die das Design verschlechtert.

In Gesprächen mit Kollegen aus dem Konstruktionssystem sind die Gefühle:

"Wir wissen ein bisschen, was eine visuelle Veränderung ist."
"Wir diskutieren visuelle Veränderungen, wenn jemandes Instinkt dies auch andeutet."
"Ich stimme zu, dass dies eine Sache ist, wir würden es nicht rigoros tun und es ist wichtig."

In unserer Arbeit am Morningstar Design System haben wir dokumentiert, welche Änderungen als Haupt-, Neben- und Patch-Änderungen gelten. Unser Team setzt seine Meinungen in Kritikdiskussionen, Kommentaren zu Pull-Anfragen und in Diskussionen mit Adoptionsteams und Upgrades selbstbewusst durch.

Unser Gebiet wird sich an die Versionierung anpassen, da es tief in unserer Praxis verankert ist. Wir werden alles tun, um mit unseren Adoptierenden gut zu kommunizieren und sie zu schützen.

#3. Versionierung ← Zurück | Weiter → # 5. Abhängigkeiten