Werkzeuge zum Denken und Werkzeuge für Systeme

In den letzten zwei Jahren habe ich mich intensiv mit Design-Tools beschäftigt, wobei Anwendungen wie Sketch, Figma und Photoshop wohl die produktivsten davon sind. Wir nutzen diese Werkzeuge, um hochfidelle Mockups zu erstellen und eine hohe Qualität der Benutzererlebnisse zu gewährleisten. Diese Werkzeuge (und andere) sind fantastisch und verbessern generell unsere Arbeit als Designer und Entwickler, aber ich glaube, dass die Art und Weise, wie sie unsere Arbeitsweise verändert und UX definiert haben, bald eine weitere neue Welle von Werkzeugen hervorbringen wird.

In Zukunft prognostiziere ich zwei getrennte Kategorien von Design-Anwendungen: **Werkzeuge zum Denken** und **Werkzeuge für Systeme**.

Ich werde es erklären.

Werkzeuge zum Denken

Vor Kurzem beschrieb Oliver Reichenstein, warum wir Ablenkungen mögen und wie wir, um Großes zu schaffen, Momente der Konzentration, Disziplin und Fokussierung brauchen.

Beginnen und Beenden braucht Mut. Es gibt keine App oder kein Werkzeug, das Ihnen Mut gibt. Aber es gibt Umgebungen, die Ablenkung fördern. Und es gibt Umgebungen, die Sie zur Konzentration anregen.

Als ich das las, dachte ich darüber nach, wie mächtig die Design-Apps sind, die ich benutze, und wie sie für einen bestimmten Zweck entwickelt wurden – aber sie fördern auch Ablenkungen. Ich brauche selten Mockups einer Benutzeroberfläche mit der hohen Detailtreue, zu der die Apps fähig sind, und jede Zeit, die ich damit verbringe, Pixel in diesen Apps zu verschieben, ist für mich fast reine Verschwendung.

Stattdessen brauche ich ein Werkzeug, um mich auf die komplexen, UX-bezogenen Arbeiten zu konzentrieren, die all den visuellen Aspekten einer großen Website zugrunde liegen, und ich brauche dringend Konzentration, um diese Arbeit zu erledigen. Ich muss keine hübsche Schriftart auswählen, ich möchte keine benutzerdefinierten Farben und es ist mir egal, wie präzise die typografische Hierarchie im Vergleich zu dem ist, was tatsächlich veröffentlicht wird. In dieser Phase des Designprozesses ist *alles ein Vorschlag, alles eine Skizze*, und das ist in Ordnung. Je unordentlicher die Skizze, desto mehr Freiheit hatte ich, wild in alle Richtungen zu experimentieren, und entscheidend ist, dass mehr Zeit bleibt, um die Informationen, mit denen ich arbeite, wirklich zu verstehen.

Hier liegt das Problem: **Unsere aktuellen Werkzeuge fordern uns auf, zuerst das fertige Produkt zu gestalten.** Sie flehen uns an, mit abgerundeten Ecken, Farben, Schriftarten und Strichstilen zu spielen. Aber erst wenn ich innerhalb eines strengen Designsystems arbeite, muss ich diese Dinge deklarieren.

Nehmen wir an, wir haben eine halbwegs brauchbare Komponentenbibliothek, in der wir unsere typografische Hierarchie, unsere Optionen für den Radius der Ecken und die Hintergrundfarbe unserer Schaltflächen festgelegt haben. Müssen wir in unseren Mockups wirklich so spezifisch sein? Können wir bewusst vage sein, ohne pixelgenaue Mockups zu verwenden, und stattdessen diese Wireframes zugunsten von realen, funktionierenden Prototypen aufgeben, die mit Komponenten aus unseren Bibliotheken erstellt wurden? Andere haben diese Art von Prozess natürlich schon früher vorgeschlagen, aber was ich hier interessant finde, ist die Rahmung, oder vielmehr die Identifizierung dieser neuen Kategorie von Werkzeugen und das Konzept, dass ein Design mit der Zeit an Detailgenauigkeit gewinnen kann. Ich glaube, wir sollten nicht erwarten, dass ein einziges Werkzeug uns durch den gesamten Designprozess begleitet.

Ich glaube, dass Balsamiq dasjenige ist, das wir heute wohl am ehesten als Beispiel dafür haben, was ich mir vorstelle: Werkzeuge, die uns beim Denken helfen und Ablenkungen beseitigen, damit wir uns auf die größeren und wichtigeren architektonischen, organisatorischen und inhaltlichen Probleme konzentrieren können, mit denen wir uns zuerst befassen sollten.

Aber es wird immer auch Bedarf an einem weiteren Satz von Werkzeugen geben.

Werkzeuge für Systeme

Ich höre viele Argumente gegen die Verwendung von Balsamiq-ähnlichen, detailarmen Design-Mockups. Die Hauptbeschwerde scheint zu sein, dass sie viel zu unpräzise sind, um nützlich zu sein; sie sind nicht interaktiv und nicht responsiv. Sie sind lediglich Zeichnungen der endgültigen App.

Vor Kurzem schrieb Dan Eden einen interessanten Artikel mit dem Titel „Die Last der Präzision“, der sich ein wenig mit diesem Thema beschäftigt.

Ohne Ingenieure sind unsere Produkte nur statische Bilder von Produkten. Ein blasser Schatten des Endergebnisses. Im besten Fall sind unsere Designs gekapselte Emulationen des Originals; komplexe Prototypen, die einen Bruchteil der realen Zustände demonstrieren, die das Produkt erfahren kann. Wir investieren all diese Zeit und Energie, um mit präzisen Werkzeugen perfekte Karikaturen von Dingen zu erstellen, deren Herstellung wir selten verstehen.

Ich stimme Dan hier voll und ganz zu, insbesondere dort, wo er argumentiert, dass

Die Präzision wird vom Ingenieur eingeführt, wo sie richtig hingehört. Schließlich sind unsere Entwürfe völlig nutzlos, bis sie gebaut sind – was in den Händen des Benutzers ist, ist das endgültige Design, und nichts weniger.

Dieses Argument erinnert mich an die Szene in Scott McClouds Understanding Comics, wo der Autor eine Reihe von Gesichtern auf einer Linie zeichnet, mit einer Strichmännchenzeichnung am einen Ende und einer realistischen Zeichnung eines menschlichen Gesichts am anderen. McCloud argumentiert, dass

Die Fähigkeit von Cartoons, unsere Aufmerksamkeit auf eine Idee zu lenken, ist meiner Meinung nach ein wichtiger Teil ihrer besonderen Kraft…

Ebenso kann eine Anwendung, die die Möglichkeit bietet, sich auf die notwendigen Details zu konzentrieren, die Qualität der von uns erstellten Benutzeroberflächen enorm verbessern. Wenn wir bereits eine Komponentenbibliothek haben, warum müssen wir dann überhaupt hochfidelle Mockups erstellen? Wir haben bereits alle Teile vorhanden.

Ich denke, wir brauchen Werkzeuge, die uns helfen, unsere detailarmen Mockups in reale, funktionierende Codebeispiele zu übersetzen. Code aus unseren eigenen Codebasen, wohlgemerkt, nicht WYSIWYG-Generatoren. Dann können wir viel schneller arbeiten und uns darauf konzentrieren, unsere UI als Ganzes zu verbessern, anstatt den Kopf in eine Funktion nach der anderen zu stecken. Wir werden weniger Inkonsistenzen haben, und unsere Styleguides und Komponentenbibliotheken können als Prototypen dienen, um unsere Designs schnell und iterativ zu testen.

</rant>

Wenn wir Werkzeuge haben, die uns beim Denken helfen, wird sich die UX unserer Produkte, Dienstleistungen und Apps exponentiell verbessern, weil wir eine Umgebung haben, die die Konzentration auf die richtigen Dinge zur richtigen Zeit fördert. Wir werden nicht durch das Erstellen schöner Bilder abgelenkt.

Ebenso können wir, wenn wir Werkzeuge haben, die uns helfen, unsere detailarmen Mockups in fertige Codebeispiele zu übersetzen – Code aus unseren eigenen Codebasen, wohlgemerkt, nicht WYSIWYG-Generatoren –, viel schneller arbeiten und uns darauf konzentrieren, unsere UI als Ganzes zu verbessern, anstatt uns mit einer Funktion nach der anderen zu beschäftigen. Wir werden weniger Inkonsistenzen haben, und unsere Styleguides und Komponentenbibliotheken können als Prototypen dienen, um unsere Designs schnell und iterativ zu testen. Airbnbs jüngste Erkundungen mit Sketch sind interessant, aber ich kann nicht anders, als diese Experimente als Hacks auf einem komplizierten Designwerkzeug zu sehen. Stattdessen stellen wir uns eine Anwendung vor, die von Grund auf neu entwickelt wurde, um diese art von systemischen Dingen zu erledigen, und die Funktionen für hochfidelle Mockups hinter sich lässt.

Damit gesagt, glaube ich, dass es immer eine Nachfrage nach Tools wie Figma oder Sketch geben wird und ich weiß, dass ich sie sicherlich auch in absehbarer Zeit nutzen werde. Aber ich glaube, es gibt enorme Möglichkeiten, unsere Design-Tools in die beiden Kategorien aufzuteilen, die ich zuvor erwähnt habe: Werkzeuge zum Denken und Werkzeuge für Systeme.