Entwerfen mit Code: Ein moderner Designansatz (Herausforderungen bei der Entwicklung)

Dieser Artikel wurde freundlicherweise von unseren lieben Freunden bei UXPin unterstützt, deren Mission es ist, die besten Benutzererlebnisse zu ermöglichen, indem Design und Technik zu einer Welt besserer und schnellerer Produktentwicklung zusammengeführt werden. Danke!

Spannungen in der Zusammenarbeit zwischen Designern und Entwicklern befeuern eine sich ständig weiterentwickelnde Diskussion, die so alt ist wie die Branche selbst. Wir haben einen langen Weg dorthin zurückgelegt, wo wir heute sind. Unsere Werkzeuge haben sich geändert. Unsere Prozesse und Methoden haben sich geändert. Aber die zugrunde liegenden Probleme blieben oft dieselben.

Eines der wiederkehrenden Probleme, die ich unabhängig von der Art und Größe des Teams häufig sehe, ist die Aufrechterhaltung einer zuverlässigen Quelle der Wahrheit . Selbst wenn wir die besten Leute einstellen und bewährte Lösungen nach Industriestandard verwenden, fühlen wir uns oft unwohl, dass etwas definitiv hätte besser gemacht werden können. Die berüchtigte „Endversion“ ist oft über technische Dokumentationen, Designdateien, Tabellenkalkulationen und andere Orte verteilt. Sie alle synchron zu halten, ist normalerweise eine mühsame und entmutigende Aufgabe.

Hinweis : Dieser Artikel wurde in Zusammenarbeit mit dem UXPin-Team geschrieben. Die in diesem Artikel vorgestellten Beispiele wurden in der UXPin-App erstellt. Einige der Funktionen sind nur in kostenpflichtigen Plänen verfügbar. Die vollständige Übersicht über die Preise von UXPin finden Sie hier.

Das Problem mit Design-Tools

Apropos „Source of Truth“: Die Ineffizienz von Design-Tools wird oft als einer der belastendsten Schmerzpunkte bezeichnet. Moderne Design-Tools entwickeln sich weiter und sie entwickeln sich mit enormen Anstrengungen schnell weiter. Aber wenn es darum geht, die Brücke zwischen Design und Entwicklung zu schlagen, entsteht nicht selten der Eindruck, dass viele dieser Bemühungen auf falschen Annahmen beruhen.

Die meisten modernen Design-Tools basieren auf anderen Modellen als die Technologien, mit denen die Designs später umgesetzt werden. Sie sind als grafische Editoren aufgebaut und verhalten sich auch so. Die Art und Weise, wie Layouts in Designtools aufgebaut und verarbeitet werden, unterscheidet sich letztendlich von dem, was CSS, JavaScript und andere Programmiersprachen zu bieten haben. Das Erstellen von Benutzeroberflächen mit Vektor- (oder sogar Raster-) Grafiken ist ein ständiges Rätselraten darüber, wie und ob das, was Sie erstellen, später in Code umgewandelt werden soll.

Am Ende beklagen Designer oft, dass ihre Kreationen nicht wie beabsichtigt umgesetzt werden. Selbst die mutigsten Bemühungen um pixelgenaue Designs lösen nicht alle Probleme. In Design-Tools ist es nahezu unmöglich, sich alle möglichen Fälle vorzustellen und abzudecken. Die Unterstützung verschiedener Zustände, sich ändernder Kopien, verschiedener Ansichtsfenstergrößen, Bildschirmauflösungen usw. stellen einfach zu viele sich ändernde Variablen bereit, um sie alle abzudecken.

Hinzu kommen einige technische Zwänge und Einschränkungen . Als Designer ohne vorherige Entwicklungserfahrung ist es immens schwierig, alle technischen Faktoren zu berücksichtigen. Erinnern Sie sich an alle möglichen Zustände von Eingängen. Machen Sie sich mit den Einschränkungen der Browserunterstützung vertraut. Prognostizieren Sie die Leistungsauswirkungen Ihrer Arbeit. Design für Barrierefreiheit, zumindest in einem viel breiteren Sinne als Farbkontraste und Schriftgrößen. Da wir uns dieser Herausforderungen bewusst sind, akzeptieren wir ein gewisses Maß an Vermutungen als notwendiges Übel.

Aber Entwickler müssen sich oft auch auf Vermutungen verlassen. Mit Grafikeditoren nachgebildete Benutzeroberflächen beantworten selten alle ihre Fragen. Ist es die gleiche Komponente wie die, die wir bereits haben, oder nicht? Soll ich es als einen anderen Zustand oder als separate Entität behandeln? Wie soll sich dieses Design verhalten, wenn X, Y oder Z? Können wir es etwas anders machen, da es schneller und billiger wäre? Ironischerweise ist es nicht immer hilfreich zu fragen, wer die Designs überhaupt erstellt hat. Nicht selten wissen sie es auch nicht.

Und hier endet in der Regel noch nicht der Umfang wachsender Frustration . Denn dann gibt es auch noch alle anderen . Manager, Stakeholder, Teamleiter, Verkäufer. Da ihre Aufmerksamkeit und geistige Kapazität zwischen all den Werkzeugen und Orten, an denen verschiedene Teile des Produkts leben, dünn gesättigt sind, haben sie mehr als jeder andere Mühe, es gut zu verstehen.

Durch Prototypen zu navigieren, zu verstehen, warum bestimmte Merkmale und Zustände in den Designs fehlen, und zu unterscheiden, was fehlt, was in Arbeit ist und was bewusst aus dem Umfang ausgeschlossen wurde, fühlt sich fast unmöglich an. Es scheint auch kaum möglich, das bereits Erledigte schnell zu wiederholen, Ihr Feedback zu visualisieren und Ihre eigenen Ideen zu präsentieren. Ironischerweise zielen immer ausgefeiltere Tools und Prozesse auf Designer und Entwickler ab, um besser zusammenzuarbeiten ; Sie legen die Messlatte noch höher und die aktive Teilnahme an den Prozessen für andere noch schwerer.

Die Lösungen

Unzählige Köpfe unserer Branche haben daran gearbeitet, diese Probleme anzugehen, was zu neuen Paradigmen, Werkzeugen und Konzepten geführt hat. Und tatsächlich hat sich einiges zum Besseren verändert. Lassen Sie uns einen kurzen Blick darauf werfen, was einige der häufigsten Ansätze für die skizzierten Herausforderungen sind.

Coding-Designer

„Sollten Designer codieren?“ ist eine Klischeefrage, die unzählige Male in Artikeln, Konferenzgesprächen und allen anderen Medien diskutiert wird, wobei immer wieder neue Stimmen in der Diskussion auftauchen. Es gibt eine allgemeine Annahme, dass es für Designer einfacher wäre, Designs zu entwickeln, die die Technologie nutzen , wenn Designer „wissen, wie man codiert“ (lassen Sie uns nicht einmal anfangen, darüber nachzudenken, wie man „Wissen, wie man codiert“ definiert Beschränkungen berücksichtigen und einfacher umzusetzen sind.

Einige würden sogar noch weiter gehen und sagen, dass sie eine aktive Rolle bei der Umsetzung übernehmen sollten. In diesem Stadium ist es leicht, voreilige Schlüsse zu ziehen, dass es nicht sinnlos wäre, die Verwendung der Design-Tools ganz zu überspringen und nur „im Code zu entwerfen“.

So verlockend die Idee auch klingen mag, sie beweist sich selten in der Realität. Die besten Coding-Designer, die ich kenne, verwenden immer noch Design-Tools. Und das liegt definitiv nicht an mangelnden technischen Fähigkeiten. Um das Warum zu erklären, ist es wichtig, einen Unterschied zwischen Ideenfindung, Skizzieren und Bauen der eigentlichen Sache hervorzuheben.

Solange es viele gültige Anwendungsfälle für „Design im Code“ gibt, wie z. B. die Verwendung vordefinierter Stile und Komponenten, um schnell eine voll funktionsfähige Benutzeroberfläche zu erstellen, ohne sich überhaupt mit Design-Tools zu beschäftigen, bieten Design-Tools das Versprechen uneingeschränkter visueller Freiheit steht immer noch von unbestreitbarem Wert. Viele Leute finden das Skizzieren neuer Ideen in einem Format, das von Design-Tools angeboten wird, einfacher und besser geeignet für die Natur eines kreativen Prozesses. Und das wird sich so schnell nicht ändern. Design-Tools sind hier, um zu bleiben und für immer zu bleiben.

Designsysteme

Die große Mission von Designsystemen, eines der größten Schlagworte der digitalen Designwelt in den letzten Jahren, war schon immer genau das: Rätselraten und Wiederholungen zu begrenzen, Effizienz und Wartbarkeit zu verbessern und Quellen der Wahrheit zu vereinheitlichen. Unternehmenssysteme wie Fluent oder Material Design haben viel Vorarbeit geleistet, um für die Idee einzutreten und der Einführung des Konzepts bei großen und kleinen Akteuren Schwung zu verleihen. Und tatsächlich haben Designsysteme dazu beigetragen, vieles zum Besseren zu verändern. Ein strukturierterer Ansatz zur Entwicklung einer definierten Sammlung von Designprinzipien, Mustern und Komponenten half unzähligen Unternehmen , bessere und wartungsfreundlichere Produkte zu entwickeln .

Einige Herausforderungen wurden jedoch nicht sofort gelöst. Das Entwerfen von Designsystemen in populären Designtools behinderte die Bemühungen vieler, eine Single Source of Truth zu erreichen. Stattdessen wurde eine Fülle von Systemen geschaffen, die, obwohl sie vereinheitlicht sind, immer noch in zwei getrennten, inkompatiblen Quellen existieren: einer Designquelle und einer Entwicklungsquelle. Die Aufrechterhaltung der gegenseitigen Parität zwischen den beiden erweist sich normalerweise als schmerzhafte Aufgabe, bei der all die am meisten gehassten Schmerzpunkte wiederholt werden, die Designsysteme ursprünglich zu lösen versuchten.

Design- und Code-Integrationen

Um die Wartbarkeitsprobleme von Designsystemen zu lösen, ist bald eine weitere Welle von Lösungen eingetroffen. Konzepte wie Design-Token haben begonnen, an Bedeutung zu gewinnen. Einige waren für die Synchronisierung des Codestatus mit Designs gedacht, wie z. B. offene APIs, die es ermöglichen, bestimmte Werte direkt aus den Designdateien abzurufen. Andere waren dazu gedacht, die Designs mit dem Code zu synchronisieren, zB indem Komponenten in Design-Tools aus dem Code generiert wurden.

Nur wenige dieser Ideen fanden jemals breite Akzeptanz. Dies liegt höchstwahrscheinlich am fragwürdigen Vorteil des möglichen Nutzens gegenüber den notwendigen Einstiegskosten noch sehr unvollkommener Lösungen. Das automatische Übersetzen von Designs in Code stellt die meisten professionellen Anwendungsfälle immer noch vor immense Herausforderungen . Lösungen, mit denen Sie vorhandenen Code mit Designs zusammenführen können, wurden ebenfalls stark eingeschränkt.

Beispielsweise würde keine der Lösungen, mit denen Sie codierte Komponenten in Design-Tools importieren können, das Verhalten solcher Komponenten vollständig replizieren, selbst wenn sie visuell der Quelle entsprechen. Keine bis jetzt.

Verschmelzen von Design und Code mit UXPin

UXPin ist als ausgereifte und voll ausgestattete Design-App kein neuer Spieler auf der Bühne der Design-Tools. Aber die jüngsten Fortschritte, wie die Merge-Technologie, können die Chancen ändern, wie wir über Design- und Entwicklungstools denken.

UXPin mit Merge-Technologie ermöglicht es uns, echte, lebendige Komponenten in das Design einzubringen, indem sowohl ihre Optik als auch ihre Funktionalität erhalten bleiben – und das alles, ohne eine einzige Codezeile zu schreiben. Die Komponenten sollen sich, obwohl sie in Designdateien eingebettet sind, genau wie ihre echten Gegenstücke verhalten – weil sie ihre echten Gegenstücke sind . Dadurch können wir nicht nur eine nahtlose Parität zwischen Code und Design erreichen , sondern beide auch ununterbrochen synchron halten.

UXPin unterstützt Designbibliotheken von React-Komponenten, die in Git-Repositories gespeichert sind, sowie eine robuste Integration mit Storybook, die die Verwendung von Komponenten aus fast jedem gängigen Front-End-Framework ermöglicht. Wenn Sie es selbst ausprobieren möchten, können Sie auf der UXPin-Website Zugriff darauf anfordern:

• Fordern Sie Zugriff auf UXPin mit Merge-Technologie an →

Das Zusammenführen von Live-Komponenten mit Designs in UXPin erfordert überraschend wenige Schritte. Nachdem Sie das richtige Bauteil gefunden haben, können Sie es mit einem Klick auf der Designleinwand platzieren. Es verhält sich wie jedes andere Objekt in Ihren Entwürfen. Das Besondere daran ist, dass Sie es, obwohl es ein integraler Bestandteil der Designs ist, jetzt genauso verwenden und anpassen können, wie Sie es in code tun würden .

Mit UXPin haben Sie Zugriff auf die Eigenschaften der Komponente, können ihre Werte und Variablen ändern und sie mit Ihren eigenen Daten füllen. Nach dem Start des Prototyps soll sich die Komponente genau wie erwartet verhalten und alle Verhaltensweisen und Interaktionen beibehalten.

In Ihren Designs können Sie eine unbegrenzte Anzahl von Bibliotheken und Designsystemen kombinieren . Neben dem Hinzufügen einer eigenen Bibliothek können Sie auch aus einer Vielzahl von sofort einsatzbereiten Open-Source-Bibliotheken wie Material Design, Fluent UI oder Carbon wählen.

Die Verwendung einer Komponente „wie sie ist“ bedeutet auch, dass sie sich entsprechend der Änderung des Kontexts verhalten sollte, z. B. der Breite des Ansichtsfensters. Mit anderen Worten, solche Komponenten sind vollständig reaktionsschnell und anpassungsfähig.

Hinweis : Wenn Sie mehr über das Erstellen wirklich ansprechender Designs mit UXPin erfahren möchten, empfehle ich Ihnen dringend, diesen Artikel zu lesen.

Kontext kann auch Thematisierung bedeuten. Wer versucht hat, ein designfähiges Designsystem in einem Designtool zu erstellen (und zu warten!) oder zumindest ein System zu erstellen, mit dem Sie einfach zwischen einem hellen und einem dunklen Design wechseln können, weiß, wie schwierig und unvollkommen dies ist Ergebnisse sind in der Regel. Keines der Design-Tools ist gut für das Themating out of the box optimiert, und verfügbare Plugins, die darauf abzielen, dieses Problem zu lösen, sind weit davon entfernt, es vollständig zu lösen.

Da UXPin mit Merge-Technologie echte Live-Komponenten verwendet, können Sie sie auch als echte Live-Komponenten thematisieren . Sie können nicht nur so viele Themen erstellen, wie Sie benötigen, sondern sie auch so schnell wechseln, wie Sie das richtige Thema aus einem Dropdown-Menü auswählen. (Sie können hier mehr über Themenwechsel mit UXPin lesen.)

Vorteile

UXPin mit Merge-Technologie ermöglicht ein Maß an Parität zwischen Design und Code, das bisher selten erreicht wurde. Die Quellentreue in einem Designprozess bringt tadellose Vorteile für alle Seiten des Prozesses. Designer können mit Zuversicht entwerfen, da sie wissen, dass das, was sie machen, nicht falsch interpretiert oder falsch entwickelt wird. Entwickler müssen die Designs nicht in Code übersetzen und sich durch unerklärliche Grenzfälle und ungedeckte Szenarien wühlen. Darüber hinaus kann sich jeder an der Arbeit beteiligen und seine Ideen schnell mit Live-Komponenten prototypisieren, ohne überhaupt etwas über den zugrunde liegenden Code zu wissen. Demokratischere, partizipatorische Prozesse zu erreichen, rückt viel näher.

Das Zusammenführen Ihres Designs mit Code verbessert möglicherweise nicht nur die Zusammenarbeit von Designern mit den anderen Mitgliedern des Teams, sondern verfeinert auch ihre internen Prozesse und Praktiken. UXPin mit Merge-Technologie kann ein Wendepunkt für diejenigen sein, die sich auf die Optimierung von Designanstrengungen in großem Maßstab konzentrieren, manchmal auch als DesignOps bezeichnet.

Die Verwendung der richtigen Quelle der Wahrheit macht es unerklärlicherweise einfacher, die Konsistenz zwischen den Arbeiten aufrechtzuerhalten, die von verschiedenen Personen im Team erstellt wurden, hilft, sie aufeinander abzustimmen, und löst die richtigen Probleme zusammen mit einem gemeinsamen Satz von Tools. Keine „losgelösten Symbole“ mehr mit einer Handvoll unaufgeforderter Variationen.

Unter dem Strich ergibt sich eine enorme Zeitersparnis . Designer sparen Zeit, indem sie die Komponenten vertrauensvoll verwenden und ihre Funktionen sofort einsatzbereit sind. Sie müssen weder die Designdateien aktualisieren, wenn sich die Komponenten ändern, noch ihre Arbeit dokumentieren und mit der Hand winken, um dem Rest des Teams ihre Visionen zu erklären. Entwickler sparen Zeit, indem sie die Komponenten von Designern in einer sofort verständlichen Weise erhalten, die kein Rätselraten und zusätzliches Basteln erfordert.

Personen, die für Tests und QA verantwortlich sind, sparen Zeit beim Aufspüren von Inkonsistenzen zwischen Designs und Code und beim Herausfinden, ob die Implantation wie beabsichtigt erfolgt ist. Stakeholder und andere Teammitglieder sparen Zeit durch effizienteres Management und einfachere Navigation solcher Teams. Weniger Reibung und nahtlose Prozesse begrenzen die Frustration unter den Teammitgliedern.

Nachteile

Die Nutzung dieser Vorteile ist jedoch mit einigen Einstiegskosten verbunden. Um Tools wie UXPin effizient in Ihrem Prozess einzusetzen, müssen Sie über ein vorhandenes Designsystem oder eine Komponentenbibliothek verfügen . Alternativ können Sie Ihre Arbeit auf eines der Open-Source-Systeme stützen, die immer ein gewisses Maß an Einschränkungen bieten.

Wenn Sie sich jedoch dazu verpflichten, ein Designsystem zu erstellen, wäre die Verwendung von UXPin mit Merge-Technologie in Ihrem Prozess mit geringen bis keinen zusätzlichen Kosten verbunden. Mit einem gut aufgebauten Designsystem sollte die Einführung von UXPin kein Problem sein, während sich die Vorteile einer solchen Umstellung als drastisch erweisen könnten.

Zusammenfassung

Die weit verbreitete Einführung von Designsystemen befasste sich mit den Problemen der Medienentwickler und -designer, mit denen sie arbeiten. Derzeit können wir eine Verschiebung hin zu einheitlicheren Prozessen beobachten, die nicht nur das Medium verändern, sondern auch die Art und Weise, wie wir es erschaffen. Die Verwendung der richtigen Tools ist für diese Veränderung von entscheidender Bedeutung. UXPin mit Merge-Technologie ist ein Design-Tool, das die Kombination von Design mit Live-Code-Komponenten ermöglicht und die Lücke zwischen den Domänen, in denen Design und Entwicklung tätig sind, drastisch verringert.

Wohin als nächstes?

• UXPin Merge: Storybook-Integration
  Erfahren Sie, wie die Storybook-Integration Ihrem Produktteam helfen kann, und probieren Sie es aus!
• UXPin Merge: Git-Integration
  Fordern Sie Zugriff an, um zu sehen, wie die Integration mit dem Git-Repository funktioniert.
• Kurzes Erklärvideo zu UXPin Merge
  Im Rahmen von „Interactive Design Systems: Webinar with Johnson & Johnson“.
• Design mit Code: UXPin-Merge-Tutorial
  Ein einführendes Tutorial zu UXPin mit Merge-Technologie.
• Responsives Design mit UXPin Merge
  Ein Leitfaden zum Prototyping vollständig reaktionsschneller Erfahrungen mit UXPin mit Merge-Technologie.