Der zeitlos skalierbare Designprozess Teil 4

Teil 4: Die Ursprünge seiner Zeitlosigkeit

Die wichtigste Innovation dieses Designprozesses liegt in seiner Skalierbarkeit. Viele Autoren behaupten, ihre Ansätze seien skalierbar, ohne dies zu belegen oder zu erklären. Dieser Ansatz ist anders: Er beruht auf vielfältigen Perspektiven und vereint Erkenntnisse aus Designstudien, Gesprächen mit Spitzen-Designer:innen auf UX-Konferenzen, praktischer Erfahrung, Mentoring sowie meiner eigenen beruflichen Laufbahn in verschiedenen Design-Disziplinen. (Eine unvollständige Liste finden Sie in den Referenzen und Danksagungen.)

Ich habe aus erster Hand gelernt, was funktioniert und was nicht. Was bisher kein anderer Designprozess leistet, ist die Trennung von Methode und Prozess – spezifisch auch für Softwareprojekte. Der Kern dieses skalierbaren Prozesses ist: Lassen Sie sich von den Prozesszielen leiten, nicht von starren Methoden. Kompetente Designer:innen analysieren den Kontext und wählen die Methode, die die Designziele am besten erfüllt. (Bei Bedarf unterstützt Keen Design Unternehmen bei dieser Analyse – projektbezogen oder organisationsweit.)

In meinem letzten Artikel habe ich diesen strukturierten, aber flexiblen Rahmen beschrieben. Dieser "Random Walk" fördert Innovation, indem er Designer:innen zwingt, sich mit unbequemen Fragen auseinanderzusetzen und kritisch zu denken. Kritik kommt oft von weniger professionellen Designenden, die die "explodierende Komplexität" bemängeln – was mehr über ihre eigene Denkweise aussagt als über den Prozess selbst. Ein echter Designprozess trennt wahre Designer:innen von KI-"Carbon Copies". Denn er liefert Ergebnisse, die innovativ und langlebig sind – im Gegensatz zu beliebigen, kurzfristigen Lösungen.

Natürlich dauert ein fundierter Designprozess länger bis zum ersten Ergebnis, doch am Ende entstehen konsistentere, durchdachtere und nachhaltigere Designs. Ad-hoc-Vorgehen führen häufig zu einem "Frankenstein-Design" voller Workarounds und Inkonsistenzen.

Vier Phasen zwischen Ist- und Wunschzustand

Der folgende vierphasige Prozess verläuft von einem konkreten Ausgangspunkt, dem sogenannten „Ist-Zustand“, zum schwer fassbaren „Wunschzustand“. Der Wunschzustand ist aufgrund seiner Unbestimmtheit schwer fassbar. Früher, etwa als Herbert Simon den Begriff „Wunschergebnis“ prägte, hatte Design ein klares Ende. Heute befinden wir uns jedoch in einem Zeitalter, das Horst von Rittel treffender beschreibt: Designprojekte enden „nicht aus Gründen, die in der Logik des Problems liegen. Vielmehr halten wir aufgrund von Überlegungen an, die außerhalb des Problems liegen: Uns gehen Zeit, Geld oder Geduld aus. Schließlich sagen wir: ‚Das ist gut genug‘, ‚Das ist das Beste, was ich im Rahmen der Projektgrenzen erreichen kann‘, ‚Mir gefällt diese Lösung‘“ usw. Die vier Phasen zwischen diesen beiden Zuständen sind:

1. Discover (Entdecken): In dieser Phase geht es zunächst darum, die Designherausforderung zu verstehen und das Problem anschließend zu erweitern und neu zu formulieren. Durch kritisches und systemisches Denken wird das Problem interaktiv mit den Stakeholdern neu formuliert, um ein ganzheitliches Verständnis zu erlangen, bevor eine Definition erarbeitet wird, die das Projekt maßgeblich bestimmt.
2. Konzept (Konzeption): Formative Forschung in Kombination mit kritischem Denken bildet die Grundlage für drei bis zehn einzigartige konzeptionelle Lösungen. Durch iteratives Design und formativ-evaluative Forschung werden diese Konzepte zu einem einzigen konzeptionellen Modell zusammengefasst, das den Rest des Projekts steuert.
3. Detail (Ausarbeitung): Durch eingehendere Forschung wird der konzeptionelle Entwurf in einen konkreten Entwurf umgesetzt. Der Entwurf wird außerdem mit technischen Ressourcen für die Implementierung und die Designressourcen koordiniert. Die detaillierten Entwürfe werden durch Nutzerforschung validiert und münden schließlich in Interaktionsmustern, Bausteinen und anderen Designelementen.
4. Deliver (Umsetzung): Diese Phase beginnt oft als „Der Teufel steckt im Detail“, da während der Implementierung unerwartete Probleme auftreten. Sie erfordert eine enge Abstimmung mit der Entwicklung, um Probleme zu lösen und gleichzeitig die konzeptionelle Integrität zu wahren. Am Ende wird sie zur „Gott steckt im Detail“-Phase, da das geplante Benutzererlebnis Gestalt annimmt.

Timeless

Was den Prozess zeitlos macht, ist die Fokussierung auf universelle Ziele pro Phase statt auf bestimmte Methoden. Dadurch lassen sich Vorgehen an Projektumfang, Ressourcen und Kompetenzniveau anpassen, ohne die Phasenziele zu verfehlen.

Die konkreten Schritte basieren nicht auf spontanen Ideen, sondern auf einem soliden Fundament von Theorie, Praxis und kollektiver Erfahrung vieler Designer:innen.

Doch wie entstand dieser Prozess eigentlich?

Ursprünge des Designprozesses

Eine einfache Antwort: Dieser Prozess entstand aus einer Synthese der Designprozesse, die ich und meine vielen Kollegen praktiziert haben; aus der Designtheorie, die ich angewendet habe, und aus den Beiträgen vieler anderer Designer, die diesen Prozess kommentiert und verfeinert haben (eine umfangreiche, wenn auch unvollständige Liste finden Sie in der Liste der Referenzen und Danksagungen am Ende). Wie bereits erwähnt, war auch das Studium zahlreicher Designprozesse führender Designer, Designschulen und Designbewegungen von besonderer Bedeutung.

Was hatten all diese Prozesse und Theorien gemeinsam? Es waren sicherlich nicht die Methoden oder die angewandten Techniken. In diesen Bereichen herrschte wenig Übereinstimmung. Dennoch gab es viele Erkenntnisse, die ich im Folgenden mit Ihnen teilen werde.

Was ist der Designprozess und woher stammt er? Eine vollständige Geschichte des Designs mit der Methode „Entdecken-Konzeption-Ausarbeitung-Umsetzung“ (die Begriffe, die in den gängigsten Versionen des Doppeldiamanten verwendet werden) würde leicht einen viel größeren Wälzer füllen, als wir hier abdecken können. Für unsere Zwecke werde ich nur eine kurze Zusammenfassung anhand einiger Beispiele früher und prägender Versionen des Designprozesses und seiner Schritte geben (und ich entschuldige mich bei den Liebhabern der Designgeschichte, die dies als zu starke Vereinfachung empfinden werden). In diesen Beispielen scheinen die Begriffe sehr unterschiedlich zu sein, aber mit zunehmender Erfahrung in der Designpraxis erhalten wir immer mehr verfeinerte und destillierte Themen und Variationen, bis wir die Schritte wie unten beschrieben synthetisieren können.

Frühe Pioniere

Unsere Reise muss irgendwo beginnen, und aus Zeitgründen beginne ich mit einem der ersten Designprozesse und einem für uns erkennbaren Designverständnis. László Moholy-Nagy, der seine Karriere an der Bauhausschule begann, artikulierte seinen Designprozess am besten in seiner Arbeit am Chicago Institute of Design, das später als Institute of Design am Illinois Institute of Technology bekannt wurde. Aber er begann viel früher an der Bauhausschule in Weimar. Am Bauhaus und anderen etwa zeitgleichen Designbewegungen (Konstruktivismus, Deutscher Werkbund usw.) entwickelte sich ein standardisierter Designansatz, der allgemein mit „die Form folgt der Funktion“ zusammengefasst werden könnte, was bedeutet, dass die Form von der Funktion eines Objekts bestimmt werden sollte. In Chicago erweitert Moholy-Nagy dieses Konzept: „Die Aussage ‚die Form folgt der Funktion‘ muss ergänzt werden, d. h., die Form folgt auch – oder sollte zumindest – bestehenden wissenschaftlichen, technischen und künstlerischen Entwicklungen, einschließlich der Soziologie und der Ökonomie.“ Dabei berücksichtigt der Designprozess eine Welt jenseits von Form und Funktion und umfasst einen breiteren Kontext, einschließlich der Ästhetik. Darin fasste er einen Designprozess zusammen. Moholoy-Nagys Prozess lässt sich wie folgt zusammenfassen:

Diese Schritte entsprechen in etwa unserem Entdecken-Konzipieren-Detaillieren-Liefern.

Discover – Investigation

Define – Ideation

Detail – Experimentation

Deliver – Realization

Seitdem sind Varianten dieses Designansatzes aufgetaucht, die in der einen oder anderen Form dasselbe gemeinsame Thema aufweisen. Hier ist nur eine Auswahl.

Akademische Versuche: Brian Archer

Brian Archers systematische Designmethodik spezifizierte den Prozess in einer Art Kochbuch oder Checkliste, die alle Variationen eines Designprojekts zu erfassen versucht. Die Übung umfasste über 250 Schritte, die sich jedoch in etwa sieben Phasen unterteilen ließen:

Wenn wir die Definitionen dieser Phasen untersuchen würden, könnten sie ebenfalls leicht in die folgenden vier Phasen zusammengefasst werden:

Discover – Preliminaries & briefing

Concept – programming & data collection

Detail – Synthesis

Deliver – Communication

HCI-Engineering-Prozesse

Parallel zur Design-Community verfolgte die HCI-Community ihren eigenen Weg. Sie war unter zwei ähnlichen Namen bekannt: CHI (Computer-Human Interaction Community), die akademische Gemeinschaft der ACM/SIGCHI, und HCI (Human-Computer Interaction Community), die die akademische Disziplin im Allgemeinen repräsentierte. Diese Gruppen waren weitgehend austauschbar, je nachdem, wer zuerst drankommen sollte – der Computer oder der Mensch. Die wichtigste Konferenz für UX-Design in den 80er und 90er Jahren waren jedoch die CHI-Konferenzen (und andere spezialisierte UX-Konferenzen), die von ACM/SIGCHI gesponsert wurden. Auf diesen Konferenzen trafen sich andere UX-Designer, um HCI-Arbeiten auszutauschen und weiterzuentwickeln.

Diese Community verfolgte ihre eigenen UX-Designprozesse, isoliert von den Entwicklungen anderer Designbereiche. Ihr Ansatz ähnelte eher einem ingenieurwissenschaftlichen Ansatz. Tatsächlich bezeichneten sich in den 1980er und 1990er Jahren viele HCI-Praktiker als „Usability Engineers“. Es entwickelte sich zudem eine eigene Industrie von Usability Engineering Consultants, die Softwareunternehmen bei der Entwicklung benutzerfreundlicherer Software unterstützten, da es intern niemanden gab, der diese Funktion übernehmen konnte. Diese frühen HCI-Experten folgten deutlich eher dem alten Bauhaus-Prinzip: „Form folgt Funktion“ und achteten kaum auf Ästhetik, abgesehen von einem der alten Lieblingsmantras von IBM: „Keep It Simple Stupid“.

Einheitlicher Softwareentwicklungsprozess

So wie heute das Design von der agilen Softwareentwicklung dominiert, wenn nicht gar unterworfen zu sein scheint, so war auch in den 80er und 90er Jahren ein anderer Softwareentwicklungsprozess, der sogenannte Unified Software Development Process, maßgeblich. Dieser war äußerst einflussreich, da es selbstverständlich war, dass das Usability Engineering dem jeweiligen Entwicklungsprozess folgen musste. Der Unified Software Development Process war eine Wasserfallmethode. Damals sah der Unified Software Development Process folgendermaßen aus:

Diese Schritte folgten einem rein technischen Prozess, bei dem Inception den Anfang bildete. Es begann mit einem ersten Treffen des Softwareteams mit einer ersten „Iteration“. Nach einigen Analysen wurde eine zweite Iteration erstellt, die die Grundlage für den nächsten Schritt bildete. Die Ausarbeitung umfasste dann die zweite Iteration, extrapolierte Anforderungen und führte zu einer weiteren Analyse, die mit dem Beginn des sogenannten „Designs“ endete. In der Konstruktion wurde dann die Software erstellt und getestet; das war dann das Ende des Designs. Der Prozess endete mit der Übergangsphase, der Bereitstellung der Software. Dieser Übergang wurde auch als „Iterationen 3+“ bezeichnet. Stellen Sie sich diese „Iterationen“ als Softwareversionen vor, bei denen der gesamte Prozess nicht wiederholt, sondern erweitert wird: um neue Funktionen oder Fehlerbehebungen.

HCI-Experten haben versucht, Designaktivitäten in diesen (und andere) Wasserfallprozesse der Softwareentwicklung zu pressen.

Der Unified Software Development Process (USP) legte den Schwerpunkt auf die Veröffentlichung eines einzigen Wasserfallprogramms, das anschließend in mehreren Versionen iteriert wurde. Er setzte dem Softwareprojekt ein klares Ende, worüber Herbert Simon und seine Design-Anhänger sich gefreut hätten, wenn es irgendjemanden interessiert hätte (was aber nicht der Fall war). Wasserfall-Entwicklungsprozesse waren nicht überlebensfähig, da Software immer komplexer wurde, die Softwareproduktion immer länger dauerte und frühzeitiges Feedback erforderlich wurde. Dieser Bedarf führte zur Entwicklung der heute allgegenwärtigen inkrementellen agilen Entwicklungsmethoden.

Benutzerzentriertes Design

Mit der Weiterentwicklung des Designs in der Human-Intelligence-Computation (HCI) entwickelten sich auch die Designprozesse weiter. Die HCI-Community profilierte sich insbesondere als Vertreterin des Benutzers in Form von benutzerzentriertem Design. Verschiedene Varianten des benutzerzentrierten Designprozesses tauchten insbesondere in Workshops auf verschiedenen HCI-Konferenzen auf, wie beispielsweise dem von J. Gulliksen, der HCI-Experten benutzerzentriertes Design vermitteln wollte. Gullicksens Prozess orientierte sich an den Softwareentwicklungsprozessen des Unified Software Development Process (USP), nicht an den Designprozessen von László Moholy-Nagy oder Brian Archer.

Diese HCI-basierten Prozesse hatten vereinfachte Vorstellungen vom Stellenwert des Designs in Softwareprojekten. Es fehlte insbesondere eine explizite Discovery-Phase, da lediglich ein Design-Briefing so akzeptiert wurde, wie es vorgelegt wurde, und sofort ein detaillierter UX-Plan erstellt wurde (der als universell für den Entwicklungsprozess galt). Anschließend wurden die Nutzerbedürfnisse und -anforderungen in formativer Nutzerforschung analysiert, was zu einem Konzept führte, das einem solchen am nächsten kommt, obwohl es nicht als solches bezeichnet wird. Design für Benutzerfreundlichkeit ist die Detailphase, kombiniert mit der Evaluation, die bereits früh am Ende des Prozesses sichtbar wird.

Einfluss anderer Disziplinen

Mit dem Wachstum der HCI-Community kam sie mit anderen ähnlichen Fachrichtungen wie Architektur, Anthropologie und sogar Design in Kontakt. Aspekte dieser anderen Disziplinen begannen, sich hinsichtlich Methoden, Techniken und manchmal sogar Prozessen gegenseitig zu beeinflussen. Beispielsweise entwickelte die Design-Community ursprünglich das Konzept der Design-Rationale aus der Arbeit von Horst von Rittel. Die CHI-Community übernahm es jedoch schnell, und die neuesten Arbeiten zur Design-Rationale stammen meist aus der CHI-Community. Die Tatsache, dass sich mittlerweile die Hälfte der Leser am Kopf kratzt, zeigt, wie wenig Rolle die Design-Rationale in vielen UX-Projekten spielt, obwohl sie ein wesentlicher Aspekt ist.

Viele Designer, wie Karen Holtzblatt (Leiterin einer sehr erfolgreichen Usability-Beratung), griffen eine populäre Version der Anthropologie auf und wandten vereinfachte In-situ-Forschung kreativ auf die HCI-Entwicklung an. Holtzblatts spezieller Ansatz heißt Kontextuelles Design. Dieser Prozess entwickelte sich etwa zur Zeit des Aufkommens einer neuen Generation von HCI-Beratern, die Softwareunternehmen ohne eigene Designer unterstützten. Daher wurde die Designarbeit vorab in das Projekt integriert und die Arbeit abgeliefert, wobei die Berater in der Regel während der Entwicklungsphase kaum anwesend waren und die Ergebnisse ihrer Arbeit nicht sehen konnten. Diese Version des Kontextuellen Designs orientierte sich an einem formelhaften oder rezeptbasierten Ansatz für einen nutzerzentrierten Designprozess mit den erforderlichen Schritten und Ergebnissen. Sie beinhaltete auch deutlich die Idee des iterativen Designs und zeigte ein zunehmendes Bewusstsein für die externe Design-Community. Die ursprüngliche Version (inzwischen wurden modernisierte Versionen weiterentwickelt) des Kontextuellen Designs folgte diesen Schritten:

Dieser Prozess versucht, unabhängig von der technischen Entwicklung einen Prozess zur Entwicklung eines benutzerzentrierten Designs zu etablieren, der ausschließlich darauf ausgelegt ist, das Produkt aus der Perspektive des Benutzers zu hinterfragen. Die Phasen sind beschreibend und ein Beispiel für einen Kochbuchansatz, der laut Autor stets zu einem erfolgreichen benutzerzentrierten Design führen sollte.

Die ersten zwei Schritte entsprechen dem Discovery-Prozess, jedoch nur insoweit, als es darum geht, Benutzeranforderungen und -feedback zu ermitteln. Es gibt keine Neuformulierung des Problems oder andere wichtige Designüberlegungen. Es basiert weiterhin darauf, Design-Assets basierend auf den angegebenen Anforderungen an die Entwicklung zu liefern und dann Benutzereingaben hinzuzufügen. Auch dies ist kein Designprozess im Sinne der Design-Community. Die nächsten zwei Schritte beziehen sich auf die Definitionsphase, jedoch mit vorgeschriebenen Aktivitäten, wie z.B. Papierprototypen. Die Definitionsphase, wie Designer sie damals verstanden, folgte den Praktiken von Designtheoretikern wie Donald Schon, bei denen viel mehr Wert auf Designreflexion und dialogorientiertes generatives Design mit Stakeholdern (normalerweise Kunden und andere, aber nicht unbedingt die Benutzer) gelegt wurde. Wie mir ein Grafikdesigner anno 1994 einmal stolz sagte: „Wir brauchen keine Benutzereingaben, wer macht schon einen Usability-Test einer Broschüre?“

Die letzten beiden Phasen des kontextuellen Designs treten ein, wenn die Designarbeit abgeschlossen und zur Entwicklung bereit ist. In diesem Fall wird das visuelle Design (das als separater, unabhängiger Designaspekt betrachtet wurde) unabhängig zum Endprodukt hinzugefügt.

Näher am Nutzer: Szenariozentriertes Design

Weitere Varianten des benutzerzentrierten HCI-Designs entstanden, um näher am Nutzer zu sein. Einer der interessantesten und nachhaltigsten Ansätze unter den vielen, die aufkamen, war das „Szenariobasierte Design“ von Mary Beth Rosson und John Carroll. Bei diesem Ansatz entstanden Endbenutzerszenarien aus Benutzerinterviews, die die Arbeitsweise und das Arbeitsverständnis der Nutzer widerspiegelten. Daraus entstanden Szenarien der Arbeitsablauf- und Aufgabenanalyse, die als Orientierung für das Design dienten. Der ursprüngliche Prozess folgte dieser Struktur:

Wie bei Holtzblatt hat auch dieser Prozess keinen direkten Bezug zur Entwicklung, da nach der Evaluierung die Entwicklung beginnt. Die Design-Exploration beschränkt sich ebenfalls auf die Szenarien, die anschließend in Wireframes umgesetzt werden.

Usability Engineering

Deborah Mayhews Prozess war ein großer Schritt hin zu einem eher designorientierten Prozess (trotz seiner stark ingenieurorientierten Struktur). Sie führte außerdem das Konzept der Iteration in den sogenannten Usability Engineering Life Cycle ein. Dieser Zyklus umfasste folgende Schritte:

Das konzeptionelle Modell wird zum ersten Mal ausdrücklich in das Design integriert, und statt sequenzieller Schritte legt Mayhews Prozess den Schwerpunkt auf die iterative Natur dessen, was sie Usability Engineering nennt. Auch hier wird spät im Prozess getestet, aber es ist iterativ bei Bildschirmdesigns und stärker auf das Detaildesign in unserem Designprozess abgestimmt. Mayhews Bemühungen sind erste Schritte dahin, wie HCI und Design zusammenwachsen. Die Design- und die HCI-Community begannen, um dasselbe Terrain beim Softwaredesign zu kämpfen: Die eine hatte die besseren Prozesse, die andere die besseren Methoden. Als beide Disziplinen dies erkannten, begannen sie, voneinander zu profitieren. Es gab Schulen wie die Carnegie Mellon University, die sowohl eine Designschule als auch eine separate Informatikabteilung hatten, und beide verliehen Abschlüsse in UX-Design (obwohl diese damals noch nicht so genannt wurden).

Schließlich entwickelten Designer Neid auf nutzerzentriertes Design und HCI-Mitarbeiter Neid auf Designer. So entstand Design Thinking, ein Bereich, der bis heute von Nicht-Designern dominiert wird, die wie jeder andere denken, nur nicht wie ein Designer. Und das bringt uns zu …

Popularisiete Vereinfachungen

Dies war der Beginn eines Höhepunkts im Design, insbesondere der Design-Institution in der Wirtschaft (die bis heute dringend benötigt wird). Stattdessen erleben wir heute eine Situation, in der der Designprozess zwar oft nur Lippenbekenntnisse erhält, im Software-Designprozess aber kaum eine Rolle spielt. Wie kam es nach diesen vielversprechenden Anfängen dazu?

Ein wichtiger Faktor war, dass Ingenieure weder die Geduld noch das Verständnis für den ganzheitlichen Designprozess hatten. Die Idee bestand also darin, die geschäftliche Seite der Software in den Softwareerstellungsprozess zu integrieren. Das war ein gutes Zeichen, da die Design-Community zu diesem Zeitpunkt eher mit der Geschäftswelt und die HCI-Community eher mit der Technik zusammenarbeitete. Der Unternehmensstratege Roger Martin, damals Leiter der Rotman School of Design, versuchte, Design als Schlüsselelement des Geschäfts einzuführen. Er war nicht erfolgreich. Stattdessen lösten Versuche von Nicht-Designern, die Idee zu übernehmen, zu vereinfachen und zu kommerzialisieren, einen Trend im UX-Design aus, der dem Design im Wesentlichen seine professionellen Standards entzog, da sich die Designpraxis von den Designgrundlagen trennte. Dies führte zu einem wilden Wachstum von „Wir zeigen Ihnen in einem Workshop, wie Sie ein UX-Designer werden“. Und genauso wie diese Ansätze bei Designagenturen zum Scheitern verurteilt waren, waren sie bei Online-Bootcamps ein noch größeres Desaster.

Es gab mutige Versuche, Design in die HCI zu integrieren. Dabei handelte es sich um Designer-Tracks, die darauf ausgelegt waren, neben der akademischen HCI-Genauigkeit auch eine strenge Designdisziplin zu schaffen. Gerrit van der Veer, Wendy Mackay, Boyd de Groot, Marilyn Tremaine, viele andere und ich versuchten, CHI dazu zu bringen, Design ernst zu nehmen.

Inzwischen wurden auf der Designseite ähnliche Bemühungen unternommen. Gemeinsam mit Elizabeth Dykstra-Erickson (und später Richard Anderson) nahmen wir Kontakt zum AIGA, dem American Institute of Graphic Artists, auf. Rick Grefe, der damalige Präsident des Instituts, erkannte die Bedeutung einer gemeinsamen Anstrengung von HCI und Design und sponserte zusammen mit ACM/SIGCHI gemeinsame Gipfeltreffen, die in der Präsentation der DUX-Konferenzreihe durch das AIGA (Terry Swack und John Zapolski) mit ACM/SIGCHI (ich und Richard Anderson) in den Jahren 2003 und 2005 gipfelten. Wie beim CHI scheiterten diese Bemühungen jedoch nach Führungswechseln sowohl beim AIGA als auch beim ACM/SIGCHI, die dazu führten, dass beide Gruppen immer isolierter und unwichtiger wurden.

Damals war das Design im Grunde sich selbst überlassen. Die HCI-Lehrpläne waren damals vor allem wirkungslos. Gute HCI-Design-Ausbildungen fand man versteckt an Orten wie der School of Library Sciences der University of Michigan, nicht aber an Orten, wo man sie vermuten würde: RISD, Parsons oder vielen führenden Informatikfakultäten.

Anfangs gab es keine klare UX-Spezialisierung. Daher übernahmen oft erfolglose Ingenieure oder Mitarbeiter anderer Fachrichtungen die Designaufgaben bei vielen Softwareunternehmen. Die Folge: Softwareunternehmen beschäftigten oft relativ ungeschulte „Designer“ ohne Design-Hintergrund. Doch wenn echte Designer eingestellt wurden, fehlte ihnen die Erfahrung dieser ungeschulten UX-Mitarbeiter. Mit zunehmender Bedeutung von UX stiegen die „erfahrenen“ Nicht-Designer an die Spitze des UX-Managements – mit verheerenden Folgen für den Designprozess. Mitarbeiter ohne Design-Hintergrund wurden für die Leitung derer mit Design-Hintergrund verantwortlich gemacht. Designprozesse wurden aufgegeben, da man fälschlicherweise annahm, sie würden den Prozess verlangsamen. Dies zwang Designer in die Defensive und sie griffen auf den einzigen Prozess zurück, den sie tatsächlich erkannten: die Befriedigung ingenieursorientierter Entscheidungsträger. Bis heute leiten Mitarbeiter ohne Verständnis für Designprozesse die Designabteilungen großer Unternehmen. Kein Wunder also, dass ihre Teams entlassen und durch standardisierte Designer ersetzt werden.

Das heißt nicht, dass Designprozesse völlig tot waren. Einzelne Teams mit visionärer Führung setzten professionelle Designprozesse ein, und ihr Produkt florierte wie eine Insel inmitten eines Software-Meeres. Es gab auch Design Thinking, das bereit war, zumindest ein gewisses Design-Gespür wieder in die Softwareentwicklung einzubringen.

Design Thinking, wie es allgemein praktiziert wird, ist strenggenommen kein Designprozess. Dieser neue Prozess wurde – und das wird Sie zweifellos überraschen – so angepasst, dass er mit bestehenden Engineering-Praktiken kompatibel ist. Diese Praktiken waren zu diesem Zeitpunkt bereits auf Agile umgestiegen und hatten einen noch geringeren Fokus auf Design als das Wasserfall-Modell. Die Folge ist eine übermäßige Vereinfachung und Vereinfachung des Design-Thinking-Prozesses.

Design Thinking

Da HCI-Experten und Softwareentwickler in der Regel keine Ausbildung in Design, Gestaltung oder Designprozessen hatten, entstand die Design-Thinking-Bewegung, die den Prozess zu etwas Einfachem und Verkäuflichem machte. Diese nicht im Design ausgebildeten Fachleute boten eine vereinfachte Version des Designprozesses an, die ihrem einfacheren Verständnis von Design entsprach.

Seine Nutzung war ein erfolgreicher Weg, Design in Unternehmen einzuführen, die noch keine Design-Erfahrung hatten. Sie wollten eine einfache und leicht verständliche Designmethode, die schnelle Ergebnisse lieferte und eine Verbesserung gegenüber ihren Prozessen darstellte (die keinerlei Design Thinking verwendeten). Auf diese Weise war Design Thinking ein gutes Werkzeug, um Design in neuen Unternehmen einzuführen, die noch nicht bereit für ein umfassenderes Design-Engagement waren. Sie möchten beispielsweise mehrere Iterationen oder Ideen? Design-Thinking-Prozesse liefern sie Ihnen, sofern sie auf einen Post-it-Zettel passen. Okay, das ist nicht ganz fair, es gibt viele Design-Thinking-Praktiker, die sorgfältig versuchen, Designprozesse zu integrieren, wie wir weiter unten sehen werden. Aber dennoch betonte ein Großteil dieser Bemühungen einen schnellen und unkomplizierten Prozess. Diese Prozesse waren eher dazu gedacht, das Produktdenken zu klären, als das kritische und systemische Denken wirklich zu fördern, das ein echter Designer in ein Softwareprojekt einbringen würde.

Es wird den Leser nicht überraschen, dass die meisten dieser Design-Thinking-Prozesse, wie die meisten frühen HCI-Prozesse, als vorgelagerter Bestandteil des Softwareentwicklungsprozesses konzipiert waren und kaum mit diesem interagierten. Darüber hinaus nutzen viele Unternehmen diese Design-Thinking-Sitzungen als Ersatz und nicht als Einführung in echtes Design Thinking. Dies hatte den negativen Effekt, dass dieser neue Designprozess isoliert blieb und zwar nützlich war, um eine bestehende Produktidee zu konkretisieren, aber weder das kritische Denken besaß, um die ursprüngliche Definition noch die übernommenen Designprozesse zu hinterfragen, um die Produktdefinition tatsächlich effektiv umzusetzen.

Versuche zur Kodifizierung des Design Thinking-Prozesses

Die Interaction Design Foundation greift den kanonischen, standardisierten Design-Thinking-Prozess auf. Der positive Aspekt hierbei ist, dass die eher präskriptiven Schritte früherer HCI-Prozesse durch zielorientiertere Beschreibungen ersetzt werden, die an die zuvor besprochenen Designprozesse erinnern.

Dieser Prozess sieht zwar umfassend aus, ist es aber nicht. Er spiegelt auch nicht die Denkweise eines Designers wider. Vielmehr handelt es sich um eine Reihe verkürzter und vereinfachter Designschritte. Diese Schritte sind nicht skalierbar. Beispielsweise behindert eine große und schwer erreichbare Nutzerschaft den Prozess von Anfang an.

Diese Abfolge von Schritten ist ein schneller, seriell durchgeführter Prozess. Die Definition der Schritte ist eng. Beispielsweise zielt die Forschungsphase auf Empathie ab (ein Mantra des Design Thinkings), ist aber eine schnelle und stark vereinfachte Version dessen, was Holtzblatt bereits in ihrem kontextuellen Design behandelt. Von dort aus fließen die Schritte ineinander, und am Ende steht ein evaluierter Prototyp (mit meist vorhersehbarem Erfolg). Man könnte argumentieren, dass dieser formelhafte Ansatz des Design Thinkings dessen eigentlichen Zweck zunichtemacht: über den Tellerrand hinauszublicken, verschiedene Perspektiven zu betrachten und einen Problemraum zu entdecken, der nicht in einer nutzerzentrierten Welt existiert, sondern ein Ökosystem, das Nutzer, Kunden, Unternehmen, den Markt, die Gesellschaft usw. umfasst.

„Design Thinking“ für agiles Design

Der Google Design Sprint empfiehlt ebenfalls Phasen, ähnelt aber anderen Varianten dieses Themas. Das Google Design Sprint-Buch erklärt ausdrücklich, dass es sich nicht um eine vollständige Software-Designmethode, sondern vielmehr um ein Ideenfindungstool handelt, das sich insbesondere für Start-ups und andere innovative Designprojekte eignet. Deshalb wird die eigentliche Entwicklung nicht berücksichtigt, da der Prototyp ein eigenständiger Proof of Concept ist.

Die Google Sprint-Methode versucht, den Designprozess für einen bestimmten, begrenzten Zweck zu miniaturisieren. Beispielsweise versucht die erste Phase, den Problembereich zu verstehen, bevor konkrete Maßnahmen ergriffen werden. Mir gefällt auch die Integrität dieses Prozesses, da er klarstellt, wofür er gut ist und dass er nur eine erste Iteration eines Designprozesses darstellt, nicht dessen Abschluss. Der gesamte Sprint-Prozess könnte als Aktivität in einen umfassenderen Designprozess passen. Die Tatsache, dass einige unkritische Designer den Design-Sprint anstelle eines Designprozesses einsetzen, verkürzt das Design und entspricht nicht dem eigentlichen Zweck eines Design-Sprints.

Der folgende Prozess ist der Design-Thinking-Prozess der Stanford Design School, der vom Stanford-Archäologen Michael Shanks geschrieben wurde.

Ihr Vorgehen ist nahezu identisch mit dem der IDF, nur dass sie den ersten Schritt statt „Recherchieren“ „Einfühlen“ nennen.

Wie der oben beschriebene IDF-Prozess handelt es sich um eine verkürzte und vereinfachte Reihe von Designübungen, die zumindest eine gewisse Reflexion über die Produktdefinition ermöglichen. Und in einem Umfeld, in dem sonst keine Designaktivitäten stattfinden würden, liefert dieser Prozess zumindest Design-Input, der besser sein kann als gar keiner. Ich sage „könnte“, weil er mit seinen verkürzten Methoden etwas als „fertig“ präsentiert, obwohl es das nicht ist. Darüber hinaus gibt es immer noch viele professionell ausgebildete Designer, die sich dem Design Thinking zugewandt haben und es nutzen, um eine tiefere Designreflexion zu ermöglichen, indem sie kritisches Denken und explorative Forschung in die Design-Thinking-Agenda aufnehmen.

Die Standardisierung des 4D-Designs

Schließlich die klassische Quelle des standardisierten 4D-Prozesses, nämlich der Double-Diamond-Prozess, der vor allem durch den Design Council populär gemacht wurde. Viele werden sicherlich anmerken, dass der Double-Diamond-Prozess eine allgemein erkennbare Sicht auf die Designmethode bietet und die Anwendung der 4D-Designprozessschritte standardisiert. Dieser Prozess vereinte, wenn auch nur vage, die besten Designprozesse mit den benutzerzentrierten HCI-Prozessen in einem einzigen Prozess für die Erstellung gut gestalteter Software.

Der Doppeldiamant sieht in seiner Design Council-Variante folgendermaßen aus:

Der Doppeldiamant unterstützt einen divergierenden und einen konvergierenden Denkprozess.

Während viele behaupten, die Visualisierung sei zu stark vereinfacht, bietet der Doppeldiamant mit seinem subtilen Einsatz von Pfeilen eine praktische Möglichkeit, Design prägnant zu kommunizieren. Er verdeutlicht die Unübersichtlichkeit des Designs und gibt dem Kunden gleichzeitig die Sicherheit, dass am Ende alles gut wird. So ist der Doppeldiamant weniger ein allgegenwärtiger Designprozess als vielmehr eine allgegenwärtige Designverpackung. Und darin ist er sehr flexibel und effektiv, da er die Sprache der Wirtschaft im Designer-Outfit zu sprechen scheint.

Es gibt noch viele weitere Quellen und Themen, die in unseren zeitlosen, skalierbaren Designprozess eingeflossen sind. Doch meines Wissens hat keiner die Ziele so prägnant von den Aktivitäten getrennt, dass der Designprozess für mich an die Herausforderungen jeder Größenordnung angepasst werden kann, wie wir es im vorherigen Blogbeitrag besprochen haben.

Es stellt sich die Frage, wie das in der Praxis funktioniert. Wie lässt sich ein Designprozess, wie wir ihn vorschlagen, skalieren und auf welche Weise? Das ist das Thema unseres nächsten Blogbeitrags. Im Folgenden liste ich zunächst die Referenzen der letzten vier Blogbeiträge, einschließlich dieses, auf. Diese Referenzen haben meine Designpraxis und insbesondere diesen Designprozess beeinflusst und geprägt. Anschließend folgt eine Liste von Designexperten, die diesen Designprozessansatz direkt oder indirekt mitgestaltet haben.

Verweise

• Alexander, C. Notes on the Synthesis of Form, 1964 
• Archer, L. B. (1965). Systematic Method for Designers. The Design Council
• Beyer, H and Holtzblatt, K, Contextual Design: Defining Customer-Centered Systems (Interactive Technologies) Morgan Kaufmann 1997
• Cross, N. (2006). Designerly Ways of Knowing. Springer
• Deborah Mayhew, The Usability Engineering Lifecycle, A Practitioner's Handbook for User Interface Design, Morgan Kaufman, 1999
• Design Council (2012). Double Diamond. The Double Diamond by the Design Council is licensed under a CC BY 4.0 license. https://www.designcouncil.org.uk/our-resources/the-double-diamond
• Design Sprint Methodology, Google Design Spring Website accessed on 5 January 2025 at https://designsprintkit.withgoogle.com/methodology/overview
• Dubberly, H. (2024) “Conversations and models: Secrets to designing great products” https://presentations.dubberly.com/conversations_and_models.pdf
• Dubberly, H. (2025) “How do you design?” https://www.dubberly.com/wp-content/uploads/2008/06/ddo_designprocess.pdf
• Dubberly, H. (2025) “Why we should stop describing design as ‘problem-solving’” from Dubberly Design Office web site, https://www.dubberly.com/articles/why-we-should-stop-describing-design-as-problem-solving.html
• Eisermann, R. “The Double Diamond design process — still fit for purpose?”  from Medium, accessed on 24 December 2024 at https://medium.com/design-council/the-double-diamond-design-process-still-fit-for-purpose-fc619bbd2ad3
• Esther Han, 4 Stages of Design thinking from Harvard Business School Online. Accessed on 3 January 2025 at https://online.hbs.edu/blog/post/stages-of-design-thinking
• Evenson, Shelley, Dubberly, H. “Design as learning—or “knowledge creation” — the SECI model” from ACM interactions, Volume XVIII — January + February 2011
• von Foster, H., World in Spectacular Light, London Review of Books, Vol. 46 No. 23 · 5 December 2024, https://www.lrb.co.uk/the-paper/v46/n23/hal-foster/world-in-spectacular-light. This is a book review of Robin Schuldenfrei’s Objects in Exile: Modern Art and Design across Borders 1930-60
• Google Design Sprint Website (2025) “Design Sprint Methodology.” https://designsprintkit.withgoogle.com/methodology/overview
• Gulliksen, J.; Goransson, B. Usability Design – Integrating user-centered systems design in the software development process. Tutorial at INTERACT 2003, Zurich, Switzerland, 2003
• Holtzblatt, K. (2012). Contextual design. In J. A. Jacko (Ed.), Human-computer interaction handbook (3rd ed., pp. 19). CRC Press. https://doi.org/10.1201/b11963 
• Horst Rittel, H. “On the Planning Crisis: Systems Analysis of the ‘First and Second Generations,’” 1972
• Interaction Design Foundation . What are UX Design Process Best Practices? https://www.interaction-design.org/literature/topics/ux-design-processes#ux-design-process-faqs
• Interaction Design Foundation (2024) What are UX Design Process Best Practices? https://www.interaction-design.org/literature/topics/ux-design-processes#ux-design-process-faqs 
• Jacobson, Ivar; Booch, Grady; Rumbaugh, James. (1999) The Unified Software Development Process. New Jersey: Addison-Wesley.
• Jones, J. C. (1970). Design Methods: Seeds of Human Futures. Wiley.
• Mayhew, D. J. (2012). Spreadsheet tool for simple cost-benefit analyses of user experience engineering. In J. A. Jacko (Ed.), Human-computer interaction handbook (3rd ed., pp. 12). CRC Press. https://doi.org/10.1201/b11963 
• Mayhew, D. J. (2012). Usability + persuasiveness + graphic design = eCommerce user experience. In J. A. Jacko (Ed.), Human-computer interaction handbook (3rd ed., pp. 13). CRC Press. https://doi.org/10.1201/b11963 
• Mayhew, D. J., & Follansbee, T. J. (2012). User experience requirements analysis within the usability engineering lifecycle. In J. A. Jacko (Ed.), Human-computer interaction handbook (3rd ed., pp. 9). CRC Press. https://doi.org/10.1201/b11963 
• Mayhew, DJ (1999) The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design, Morgan Kaufman. 
• Moholy-Nagy, L. (1947) Vision in Theobald, P Chicago, 30-32. Realization is what Moholy-Nagy calls ‘Social Biological Synthesis’
• Peart, R. (20127) Why Design is Not Problem Solving + Design Thinking Isn’t Always the Answer from AIGA Eye on Design, January 19th, 2017 https://eyeondesign.aiga.org/why-design-is-not-problem-solving-design-thinking-isnt-always-the-answer/
• Rittel, H. W. J., & Webber, M. M. (1973). “Dilemmas in a General Theory of Planning.” Policy Sciences, 4(2), 155–169
• Rosenberg, D. (2020) UX Magic, Interaction Design Foundation
• Rosson, M. B. and Carroll, J., Usability Engineering: Scenario-Based Development of Human-Computer Interaction Morgan Kaufman, 2002
• Rosson, M. B., & Carroll, J. M. (2012). Scenario-based design. In J. A. Jacko (Ed.), Human-computer interaction handbook (3rd ed., pp. 20). CRC Press. https://doi.org/10.1201/b11963
• Schön, D. (1984) The Reflective Practitioner: How Professionals Think in Acton, Routledge Press, New York 
• Shanks, M. (2022) An Introduction to Design Thinking, Process Guide, from Stanford Business School https://web.stanford.edu/~mshanks/MichaelShanks/files/509554.pdf
• Simon, H. A. (1969). The Sciences of the Artificial. Cambridge, MA: MIT Press
• The 6 Steps of the Design Thinking Process, IDEO Website accessed on 5 January 2025 at https://www.ideou.com/blogs/inspiration/design-thinking-process?srsltid=AfmBOop-CfwQVih5_qooOG1svrgnByGUAF4EZvpaz9JRwTlNlP2E6-tb
• Winograd, T., Bringing Design to Software, 1996

Danksagung

Ich möchte nur eine kurze Liste von Designexperten nennen, mit denen ich das Privileg hatte, zusammenzuarbeiten und die mich bei meiner Designarbeit beeinflusst und inspiriert haben:

Michael Arent, Hugh Dubberly, David Siegel, Iwan Cuijpers, Richard Anderson, Susan Dray, Daniel Rosenberg, Elizabeth Dykstra-Erickson, David Zeidman, Ruurd Priester, Nico ten Hoor, Gert van der Meulen, Jose Arcellana, Patrick Larvie, Irene Au, Nico MacDonald, Marilyn Tremaine, Wendy Mackay, Robert Jacobs und zuletzt Anna Wildeman und Laura Chavarria.