Design

Was diese Kategorie abdeckt

Tools zum Entwerfen von Oberflächen und der Systeme dahinter: Bildschirme, Komponenten, Variablen, Dokumentation und die Übergabe an die, die es bauen. Manche Produkte hören beim Zeichnen auf, manche reichen bis zu Prototypen, Forschung und Content-Workflow.

Klickbare Abläufe zum Testen einer Idee stehen unter Prototyping. Alles, was auf Video- oder Bewegtbild-Ausgabe zielt, gehört zu Video und Bildschirmaufnahme.

Zusammenarbeit hat verändert, was diese Tools sind

Design-Software war früher eine Einzelspieler-Anwendung, die Dateien erzeugte. Heute ist sie meist ein gemeinsamer Arbeitsbereich, und dieser Wandel entscheidet, welches Produkt zu einem Team passt.

Gleichzeitiges Bearbeiten zählt weniger als der Verkehr drumherum: Kommentare, die sich erledigen lassen, Versionen mit lesbarem Verlauf, Links, die immer den aktuellen Stand zeigen, und Berechtigungen, mit denen ein externer Kunde hineinsehen kann, ohne etwas kaputt zu machen.

Browserbasierte Produkte gewinnen beim Zugang und verlieren bei Offline-Arbeit und schweren Dateien. Dateibasierte Produkte kehren beides um. Keines ist allgemein besser, und die Antwort hängt davon ab, wie Ihr Team tatsächlich arbeitet, nicht davon, welches neuer ist.

Designsysteme sind das eigentliche Produkt

Jenseits einer Handvoll Bildschirme wandert der Wert von den Zeichnungen zum System darunter.

Sehen Sie, wie Komponenten mit Varianten, Zuständen, Verschachtelung und Überschreibungen umgehen, und dann, wie schmerzhaft ein Update wird, wenn eine Komponente an zweihundert Stellen vorkommt. Sehen Sie dann auf Variablen oder Tokens: Farben, Abstände, Radien und Schriftgrößen, einmal benannt, mit Modi für Themes und Dichten.

Die Verbindung zum Code ist der Punkt, an dem Systeme sich bewähren. Fragen Sie, ob sich Tokens in einem Format exportieren lassen, das ein Build verarbeiten kann, und ob Komponentennamen in der Datei den Komponentennamen im Repository entsprechen. Wenn beide auseinanderlaufen, hört jeder auf, der Datei zu trauen, und fragt direkt die Designerin.

Dokumentation verdient einen Platz im selben Arbeitsbereich. Ein System ohne geschriebene Regeln wird binnen eines Jahres zu vierzig Varianten desselben Buttons.

Übergabe und was Entwickler wirklich brauchen

• Maße und Abstände, lesbar ohne einen Editor-Platz zu öffnen.
• Benannte Tokens statt in ein Ticket eingefügter Hexadezimalwerte.
• Assets, exportierbar in den richtigen Maßstäben und Formaten, einschließlich dessen, was Ihre Plattform verlangt.
• Zustände für leer, Laden, Fehler und lange Inhalte, wo Entwürfe meist scheitern.
• Ein aktueller Link, damit niemand nach einem Screenshot baut, der letzten Monat in den Chat gestellt wurde.

Dieser fünfte Punkt verursacht mehr Nacharbeit als jede fehlende Funktion. Welches Tool Sie auch wählen: Die gemeinsame Wahrheit muss an einem Ort liegen, den alle erreichen.

Dateien, Performance und die langweiligen Beschränkungen

Bei großen Dateien trennen sich diese Produkte. Ein Dokument mit Hunderten Frames, eingebetteten Bildern, verschachtelten Komponenten und zehn Jahren Verlauf zeigt Ihnen innerhalb einer Minute den Unterschied zwischen einem schnellen und einem langsamen Tool.

Prüfen Sie die Tiefe des Versionsverlaufs, denn Einstiegstarife behalten oft nur ein kurzes Fenster, und über Designentscheidungen wird Monate später gestritten. Prüfen Sie die Plugin-Verfügbarkeit, wenn Ihr Workflow von einem abhängt. Prüfen Sie, was mit geteilten Links passiert, wenn ein Tarif ausläuft.

Nutzerplätze, Betrachter und was ein Team wirklich kostet

Die Preise gelten fast überall pro Editor. Kommentierende und Betrachter sind kostenlos oder deutlich günstiger. Diese Struktur belohnt, wenn man entscheidet, wer wirklich bearbeitet.

Entwickler, Produktverantwortliche, Geschäftsleitung und Kunden müssen meist lesen und kommentieren statt zeichnen. Ihnen volle Plätze zu kaufen, ist der Standardweg, wie diese Kategorie doppelt so viel kostet wie nötig.

Achten Sie auch auf die Tarifgrenzen: Geteilte Bibliotheken, Branching, Single Sign-on und erweiterte Berechtigungen liegen tendenziell über der Einstiegsstufe, und eines davon ist meist der Grund, warum ein wachsendes Team upgradet. Ähnliche Muster im ganzen Markt stehen in was Preisseiten verschweigen.

Ziehen Sie vor der Entscheidung ein echtes Projekt um. Keine Beispieldatei, sondern eine laufende mit unaufgeräumten Ebenen und einem Kunden, der an der falschen Stelle kommentiert.

Mit Leuten arbeiten, die nicht gestalten

Der größte Teil der Reibung in dieser Kategorie kommt von den Menschen um das Designteam herum und nicht vom Tool.

Entwickler brauchen Maße, Tokens und einen aktuellen Link. Produktverantwortliche müssen kommentieren können, ohne etwas kaputt zu machen. Die Geschäftsleitung braucht ein Bild, keine Datei mit vierzig Artboards.

Richten Sie das bewusst ein. Eine einzige Seite pro Projekt mit den aktuellen Bildschirmen, während die Exploration woanders liegt, verhindert die immer wiederkehrende Frage, welche Version die echte ist.

Dieselbe Disziplin gilt für die Benennung. Dateien namens final, final zwei und final abgenommen sind ein Symptom einer fehlenden Konvention, und kein Produkt löst sie. Einigen Sie sich, worauf der geteilte Link zeigt, und halten Sie alles andere aus dem Weg von Leuten, die es nicht suchen.