"Könnt ihr das am Schluss noch schöner machen?" Der Satz fällt fast immer, wenn die Funktion steht. Er verrät eine Annahme: Design sei der Anstrich, den man am Ende über das fertige Haus streicht. Nur ist Design nicht die Farbe an der Wand. Es ist der Grundriss.
Design hat ein Imageproblem. Viele halten es für Geschmackssache, für die Kür nach der Pflicht, für das, was die Software hübsch macht. Und weil hübsch nach Luxus klingt, ist es das Erste, was gestrichen wird, wenn Zeit oder Budget knapp werden. Dieser Denkfehler kostet später mehr, als die schöne Oberfläche je gekostet hätte.
Design ist nicht, wie es aussieht, sondern wie es läuft
Wenn wir von Design reden, meinen wir nicht die Farbe eines Knopfs. Wir meinen die Frage, ob jemand ein Formular ausfüllt, ohne nachzufragen, oder ob es jede Woche drei Anrufe beim Support auslöst. Ob dein Mitarbeiter eine Bestellung in zwanzig Sekunden erfasst oder in zwei Minuten mit drei Fehlern. Das entscheidet sich nicht an der Optik, sondern daran, wie die Software führt: was auf dem Bildschirm steht, in welcher Reihenfolge, und was eben nicht.
Gutes Design ist deshalb meistens unsichtbar. Du merkst es nicht, wenn etwas einfach funktioniert. Du merkst nur das schlechte, jeden Tag, an der Stelle, wo du kurz stockst und überlegst, was das Ding jetzt von dir will.
Was schlechtes Design wirklich kostet
Die Rechnung steht nicht in der Offerte. Sie kommt später, in Raten.
Am Support. Jede Stelle, an der Leute nicht weiterwissen, wird zu einer Frage. An dich, ans Team, an den, der die Software gebaut hat. Eine Oberfläche, die sich selbst erklärt, spart genau diese Anrufe.
An der Einarbeitung. Ein Tool, das man erst in einer Schulung verstehen muss, kostet bei jedem neuen Mitarbeiter wieder. Eines, das man einfach benutzt, nicht.
An den Daten. Wo Eingaben umständlich sind, wird geschludert. Felder bleiben leer, es wird geraten, Falsches landet in der Datenbank. Und was schlecht reinkommt, kommt schlecht wieder raus.
Am schlimmsten: an der Umgehung. Wenn ein internes Tool im Weg steht, machen Leute es nicht besser, sie machen es daneben. Die Bestellung landet wieder in der Excel-Tabelle, die eigentlich abgelöst werden sollte. Dann zahlst du für Software, die keiner benutzt.
Gutes Design merkst du nicht. Schlechtes zahlst du jeden Tag, in Anrufen, in Fehlern und in der Excel-Tabelle, in die dein Team heimlich zurückkehrt.
Die wichtigsten Entscheidungen sind keine Farben
Wenn Design über Führung entscheidet, dann fallen die grossen Entscheidungen nicht bei der Farbwahl. Sie fallen vorher.
Was gehört überhaupt auf diesen Bildschirm, und was lenkt nur ab? In welcher Reihenfolge kommen die Schritte, damit sie dem folgen, wie jemand wirklich arbeitet, und nicht dem, wie die Datenbank aufgebaut ist? Was ist schon vorausgefüllt, weil es in neun von zehn Fällen stimmt? Und was passiert, wenn jemand etwas falsch macht, denn das wird passieren.
Der teuerste Denkfehler dabei heisst "der Weg, auf dem alles gut geht". Software wird gern für den Idealfall gebaut: Der Nutzer füllt alles richtig aus, in der richtigen Reihenfolge, ohne Tippfehler. Die Realität sieht anders aus. Gutes Design plant den holprigen Weg mit ein, nicht nur den glatten.

Software wird für den Idealfall gebaut. Benutzt wird sie im echten Leben
Der glatte Weg ist schnell gezeichnet: alles richtig, in der richtigen Reihenfolge. Nur läuft es selten so. Jemand springt zurück, vertippt sich, lässt ein Feld leer, kommt am Freitagnachmittag mit halbem Kopf. Ob die Software das abfängt oder den Nutzer auflaufen lässt, entscheidet sich im Design, nicht im Code danach.
Schön ist nicht dasselbe wie brauchbar
Es gibt einen Unterschied zwischen einer Oberfläche, die im Screenshot beeindruckt, und einer, mit der man gern arbeitet. Das Beeindruckende ist oft das Neue, das Verspielte, das noch keiner so gesehen hat. Das Brauchbare ist meistens langweilig: vorhersehbar und ruhig, an den Stellen, wo du es erwartest. Ein Knopf, der aussieht wie ein Knopf. Eine Suche, die dort ist, wo Suchen immer sind.
Gerade bei internen Werkzeugen gewinnt fast immer die ruhige Variante. Dein Team will nicht überrascht werden, es will fertig werden. Tempo und Klarheit schlagen jeden Effekt. Das heisst nicht, dass es hässlich sein muss. Es heisst, dass Schönheit hier aus Aufgeräumtheit kommt, nicht aus Dekoration.
Warum wir früh etwas Klickbares zeigen
Weil man Design nicht in Worten beurteilen kann, zeigen wir früh etwas, das man anfassen kann. Lieber ein grober, klickbarer Ablauf nach ein paar Tagen als ein perfektes Bild nach Wochen. Denn die ehrlichste Prüfung ist simpel: Setz einen echten Menschen davor, sag nichts, und schau zu, wo er stockt. Diese eine Minute verrät mehr als jede Diskussion über Farben.
Mit agentischen Werkzeugen können wir Oberflächen schnell bauen und wieder umwerfen. Das verschiebt den Engpass. Nicht mehr das Zeichnen der Bildschirme kostet am meisten, sondern die Entscheidung, was daraufgehört. Genau da steckt die Arbeit, und genau da hilft jemand, der schon viele Leute an Software hat scheitern sehen. Wie aus dem ersten klickbaren Entwurf etwas Belastbares wird, erzählen wir in Vom Prototyp zur Produktion. Und dass die Oberfläche nach dem Launch nicht fertig ist, sondern mit der Nutzung wächst, steht in Software ist nie fertig.
Die Faustregel
Frag nicht, ob die Oberfläche schön ist. Frag, ob jemand sie ohne Erklärung bedient, ob dein Team sie freiwillig benutzt, und was passiert, wenn einer etwas falsch eintippt. Schön ist ein Nebeneffekt von aufgeräumt. Brauchbar ist das Ziel.
Design ist keine Schicht, die man am Ende aufträgt. Es ist die Summe der Entscheidungen darüber, wie deine Software mit den Menschen umgeht, die sie benutzen. Deshalb reden wir früh darüber, nicht erst, wenn die Funktion schon steht und sich nichts mehr ändern lässt, ohne wehzutun. Die schönste Fassade rettet keinen Grundriss, in dem man sich verläuft.
Du hast ein Tool, das keiner gern benutzt, oder planst eines, das laufen soll? Zeig es uns, wir schauen ehrlich hin.



