Design, das in Produktion Bestand hat, nicht nur im Prototyp.

UX- und Interface-Design decken die Bildschirme ab, mit denen jemand interagiert. Service Design deckt die gesamte Journey um diese Bildschirme herum ab, einschließlich dessen, was außerhalb des Bildschirms passiert: eine menschliche Übergabe, eine Bestätigungs-E-Mail, ein Lagerprozess, den der Kunde als eine einzige, durchgängige Sache erlebt, auch wenn dabei mehrere Systeme und Teams durchlaufen werden. Wir machen beides, weil ein wunderschönes Interface trotzdem scheitert, wenn der Prozess dahinter kaputt ist.

Beides. Dieselbe Recherche- und Journey-Mapping-Disziplin gilt, egal ob der Nutzer ein externer Kunde ist oder jemand aus Ihrem Team, der ein Tool für seine Arbeit nutzt. Interne Tools sind oft der Ort, an dem schlechtes Design am meisten verlorene Zeit kostet, obwohl sie die geringste Design-Aufmerksamkeit erhalten.

Durch den Aufbau von Interface-Designsystemen (einmal definierte und konsistent wiederverwendete Komponenten) und durch die Validierung von Designs mit Prototyp-Tests, bevor eine einzige Zeile Produktionscode geschrieben wird, sodass Probleme in einem klickbaren Prototyp entdeckt werden, statt nachdem Engineering es bereits gebaut hat. Und da IT im selben Unternehmen sitzt, gibt es keine Lücke zwischen der Design-Datei und dem Bau.

Sowohl qualitativ als auch quantitativ: Interviews und Usability-Sitzungen mit echten Nutzern, zusammen mit Verhaltensdaten darüber, wie Menschen das aktuelle Produkt tatsächlich nutzen, statt Annahmen darüber, wie sie es nutzen sollten. Schritt eins ist ausdrücklich Recherche und Entdeckung, bevor überhaupt ein Bildschirm gestaltet wird.

Ja. Ein bestehendes Designsystem ist ein Ausgangspunkt, kein Standardersatz; wir erweitern und verfeinern es nach Bedarf, statt es zu ersetzen, es sei denn, das Audit zeigt, dass es das Produkt tatsächlich ausbremst.

Echte Nutzer. Usability-Tests sind ein definierter Schritt im Prozess, kein optionales Extra: Designs werden gegen echtes Verhalten validiert, bevor Produktionscode geschrieben wird, weil interne Meinungen darüber, was intuitiv ist, ein schlechter Ersatz dafür sind, jemanden tatsächlich beim Versuch, es zu nutzen, zu beobachten.