Artikel von Björn Ganslandt

Design Systeme enthalten – wie ihre Verwandten, die Pattern Libraries – geteilte UI-Komponenten und Design-Prinzipien. Es geht also nicht nur darum, Entwickler_innen eine Anlaufstelle fürs Copy & Paste zu geben. Gute Design Systeme erlauben Menschen aus den verschiedensten Berufskategorien ein gemeinsames Verständnis einer Designsprache zu bekommen.

Deshalb ist es wichtig, beim Start eines neuen Design Systems Benennungen und Kategorien zu finden, die ein gemeinsames Gespräch zwischen Design, Entwicklung und Produktmanagement erlauben. Egal ob das eigene Medium Sketch, HTML oder Excel ist: wenn von einem Akkordeon gesprochen wird, sollten sich alle auf die gleiche Komponente beziehen.

Um in kurzer Zeit zu einem Vokabular zu kommen, das für heterogene Gruppen funktioniert, haben wir zu diesem Zweck den Informationsarchitektur-Klassiker Card Sorting mit der kollaborativen Designmethode Design Studio kombiniert.

Und das Ergebnis konsequenterweise Card Studio getauft.

Weiterlesen →

Kaum eine Woche vergeht, in der nicht ein weiteres Unternehmen stolz seine Pattern Library bzw. zunehmend sein Design System ins Web stellt. Was weit weniger öffentlich diskutiert wird, ist wie es sechs Monate später um diese Projekte steht. Erfahrungsgemäß sind Pattern Libraries (vergleichbar mit Balkongärten) nämlich von zwei Formen der Vernachlässigung bedroht: Dem Verdorren und dem Überwuchern.

Verdorren ist dann eine Gefahr, wenn die Patterns, trotz ihrer Verknüpfung mit lebendigem CSS, nicht wirklich angenommen werden, weil sie technisch oder funktional an den Bedürfnissen im Unternehmen vorbei gehen oder nicht genügend evangelisiert wurden.

Umgekehrt kann eine Pattern Library aber auch an ihrem eigenen Erfolg zugrunde gehen und zuwuchern, weil zu viele neue Patterns mit überlappender Funktionalität eingepflegt werden, bis praktisch das gesamte UI in der Library liegt und niemand mehr den Überblick hat.

Während sich Pattern Libraries für kleine Teams relativ leicht aufsetzen lassen, erfordert die Integration einer unternehmensweiten Pattern Library mehr architekturelle Planung. Dabei gibt es einige zentrale Entscheidungen, die auf die technische Umsetzung und die notwendigen organisatorischen Prozesse wirken. Diese Optionen sollen hier mit Vor- und Nachteilen vorgestellt werden, damit nach sechs Monaten weder Verdorren noch Überwuchern zum Problem werden.

Weiterlesen →

Responsive Now

Die gute Nachricht zuerst. Wer 2015 responsive werden will, hat dafür mehr vorgefertigte Bausteine als je zuvor: es gibt kaum eine Template-Sammlung, in der sich nicht auch 1-2 responsive Varianten finden. Mit etwas Glück sogar mit Parallax-Effekt. Allerdings stoßen Templates schnell an ihre Grenzen, weil sie dann doch nicht viel Raum für eigene Business-Logik bieten und es schmerzt, wenn man im gleichen Gewand wie die Konkurrenz im Netz steht.

Also greift man dann doch zu kleineren Bausteinen und baut mit Hilfe von responsiven Frameworks wie Bootstrap oder Foundation. Keine schlechte Idee, denn diese Frameworks sind erprobt, und das auch auf Geräten, die sich in den meisten Device-Sammlungen nicht finden. Aber auch hier ist der Preis für die Bequemlichkeit mangelnde Flexibilität, denn jedes Framework trifft gewisse Design-Entscheidungen, die sich nachträglich nur schwer ändern lassen. Zum Beispiel welche Browser unterstützt werden oder wie viele Spalten ein Grid haben sollte.

Weiterlesen →

Glaubt man den Verkaufszahlen, dürfte Eric Ries’ Buch »The Lean Startup« inzwischen in einigen Bücherschränken stehen. Was aber tun, wenn man kein Startup, sondern ein Teil eines großen und möglicherweise wandlungsresistenten Unternehmens ist? Wie so oft: Klein anfangen und mit Pilotprojekten beweisen, dass agile und leane Methodik funktioniert. Strukturierte AB/MV-Tests eignen sich dazu besonders gut – wenn man ein paar Grundregeln beachtet.

Weiterlesen →