2.10 VDI 2221 von Cross

1993 | Die Konstruktionsmethodik VDI 2221 von Nigel Cross

Computergestützer Prozess

Die Konstruktionsmethodik des Vereins deutscher Industriedesigner bezieht sich auf Christopher Alexanders und Serge Chermayeffs »Community and Privacy« (1963) – ein Buch inspiriert von dem Einzug der Computer in der Architektur bzw. im Architekturprozess. Es ging ihnen um die »decomposition and recombination« als Anforderung an die konkrete Architektur.

Komplexe Sachverhalte in einfache zerteilen

In der Konstruktionsmethodik des VDI geht es um die Erkennung und Analyse eines Problems. Um dies besser und effizienter lösen zu können, selbst bei hoher Komplexität, wird das Problem in Teilprobleme »zerbrochen«, welche dann, jedes für sich, einfacher gelöst werden können. So entstehen Unterlösungen, die am Ende wiederum zu einer ganzen Lösung zusammengesetzt werden können. Das hier dargestellte Modell ist nur ein Teil dieser VDI 2221, welche insgesamt 44 Seiten enthält und für Industriedesigner entwickelt wurde. Das untenstehende Diagramm ist jedoch insofern auch für Designer anderer Disziplinen interessant, indem es den Ansatz vieler Methodiker der ersten Generation darstellt, die damit auf eine immer komplexer werdende Welt reagieren wollten: Das Zerlegen von komplexen Problemen in einzelne, einfach überschaubarere Teilprobleme.

Was bedeutet das für den Designprozess?

Problem-fokussiert

Das hier betrachtete Modell aus der VDI 2221 wurde oft kritisiert, weil es problemfokussiert ist und damit den »typischen« Denkweisen der Designer, die lösungsorientiert sind, widerspricht. Der Ansatz, ein komplexitätsreduzierendes Modell bzw. eine Methode an der Hand zu haben, ist verlockend, muss jedoch kritisch betrachtet werden. So schreibt auch Lawson, dass die Aufspaltung in Teilprobleme und den daraus resultierenden Teillösungen nicht unbedingt zu einer optimalen Gesamtlösung führen kann, weil natürlich bei den Teillösungen der Gesamtkontext überhaupt keine Rolle spielt und sich die Fehlerquelle beim Zusammensetzen der einzelnen Teillösungen als fatal entpuppt.

Gegenläufige Teillösungen

Im Industriedesign mag dieser Ansatz noch vertretbar sein, geht es doch um die Aufspaltung von Funktionen und die Erfüllung eben dieser, kann es im Interfacedesign oder auch in anderen Disziplinen zu sich gegenläufig verhaltenden Teillösungen führen.

2.11 Divergence and convergence von Banathy

1996 | Dynamics of divergence and convergence von Bela H. Banathy

Designen von Systemen

Bela H. Banathy, Professor für Systemwissenschaften an der San Josè State University, hat, im Gegensatz zu den anderen bereits vorgestellten Modellen, eine ganz andere Perspektive auf den Designprozess. Sein Ansatz bezieht sich eher auf das Designen von Systemen – dennoch ist seine Darstellung nicht uninteressant für Designer, auch wenn sie den Designprozess in all seine Einzelheiten nicht holistisch beschreiben können.

Differenzierte Analyse

Seine differenzierte Sicht auf die Analyse (Transcend / Envision) kommt so in keinem der bisher vorgestellten Systeme vor. Hieran wird auch seine Perspektive deutlich, denn als Systemiker geht er von verschiedenen Vorstellungen der Realität aus und genau dieser Umstand, sollte auch in der Analyse berücksichtigt werden. So ist nach Paul Watzlawick die Sicht des Designers (der die Analyse durchführt) nur eine von vielen Sichten – die Subjektivität der einzelnen Sicht kann hier zu falschen Einschätzungen und Schlussfolgerungen führen. Genau diese Sichten sind dargestellt und werden von den abgefragten Grenzen, Designmöglichkeiten und einer Ansammlung von Wertvorstellung und Grundideen verstärkt.

Konvergenz & Divergenz

Die Konvergenz entsteht im ersten Teil durch das Treffen von Entscheidungen und als Konsequenz aus diesen Entscheidungen, durch die Zeichnung einer Zukunft bzw. einer Zukunftsvorstellung. Ist ein eindeutiges Bild der Zukunft entstanden, folgt die Synthese, also das Transformieren dieser Vorstellung in die Realität. Wobei auch hier wieder erst Divergenz herrscht, ausgelöst durch das Anfertigen von Alternativen (die auch alle zu dem jeweiligen Zukunftsbild führen könnten). Diese Divergenz wird aufgelöst durch die Evaluation der möglichen Alternativen und als Konsequenz daraus, die Entscheidung für eine der entwickelten alternativen Umsetzungen.

Evaluation erzeugt Konvergenz

Dieser Evaluierungs- und Entscheidungsprozess erzeugt Konvergenz im zweiten Feld des Diagramms und führt, nach Banathy, zum Modell der Zukunft. Wenn wir dieses Modell hier betrachten, bezieht sich das »Modell der Zukunft« natürlich auf das jeweilig entstandene Produkt.

Was bedeutet das für den Designprozess?

Design erzeugt Konvergenz

Banathys Modell kann natürlich nicht als komplettes Designmodell interpretiert werden, dennoch ist der Vorgang der Divergenz und die Auflösung dieser Divergenz, durch Entscheidungen und das Überführen in die Konvergenz, ein sehr charakteristischer Vorgang im Designprozess. Interessant ist auch, dass in seiner Darstellung die Linien, die offensichtlich Meinungen und Ansichten darstellen sollen, alle einen Ursprung (also ein Problem) haben und von da aus immer divergenter werden, bis es einen Punkt gibt, an dem sie zueinander konvergieren. Sicherlich muss der Designer diese Divergenz von sich aus erzeugen und als Reaktion auf die verschiedenen Meinungen /Ansichten / Interpretationen in Bezug auf die Ressourcen (Zeit, Geld und Personal) reagieren und diesen (theoretisch unendlich fortsetzbaren) Vorgang der Divergenz beenden, um dann durch Entscheidungen zu einer Zielsetzung zu kommen (The Image of the Future System). Dies impliziert auch, dass die Zielsetzung nicht durch das gegebene Problem determiniert ist.

Lösungen sind subjektiv

Das klingt zunächst ungewöhnlich. Zieht man hier jedoch den radikalen Konstruktivismus heran wird schnell klar, dass die Kompromisse, mit welchen bestimmte Funktionen integriert werden, rein subjektiv sind. Das gleiche Prinzip der Divergenz / Konvergenz tritt noch einmal bei der Transformation des Ziels in ein konkretes Produkt auf. Und auch hier muss der Designer (bzw. bei größeren Projekten der Projektmanager) die Phase der Divergenz hiner sich lassen, um in die Phase der Konvergenz und schließlich zum Endprodukt zu kommen.

»Participation is empowering and design is empowered by it«

2.12 Human-centered design process von Stewart

1999 | Iso 13407 Human-centered design processes for interactive systems von Tom Stewart

Benutzerorientierte Gestaltung

Dieses Modell entstammt der ISO-Norm der Benutzerorientierten Gestaltung interaktiver Systeme und ist ab 2011 unter dem Namen EN ISO 9241-210 bekannt. Diese Norm beschäftigt sich sowohl mit der Beschreibung benutzerorientierter Gestaltung als auch mit der Erläuterung zur Entwicklung interaktiver Systeme mit Schwerpunkt auf die Benutzerfreundlichkeit.

Iterative Entwicklungsprozesse

Die Norm steht für einen iterativen Entwicklungsprozess, bei dem der Nutzer und die von ihm zu erledigenden Aufgaben im Zentrum stehen. ISO 13407 stellt sich als multidisziplinärer Prozess dar, der verschiedene Techniken, Fähigkeiten und Einflüsse voraussetzt. Das Modell ist zirkulär und besteht in den jeweiligen Ausführungen aus unterschiedlichen Phasen bzw. Schritten. Im ersten Schritt wird das Arbeitsumfeld, die zu erledigenden Aufgaben und der Benutzer untersucht um als Abschluss dieser Phase ein Verständnis für diese Punkte zu entwickeln. Im gesamten Prozess wird der Nutzer mit einbezogen. Im zweiten Schritt werden die Informationen aus dem ersten Schritt genutzt, um Anforderungen an das interaktive System abzuleiten. Diese Anforderungen setzen sich dabei nicht aus den Anforderungen des Benutzers an das System zusammen, sondern hinzu kommt die Beachtung von organisatorischen, das Projekt betreffende Rahmenbedingungen, wie z.B. gesetzliche Vorgaben, finanzielle Mittel oder technische Umsetzbarkeit. Zwischen diesen zwei Einflüssen muss ein Kompromiss gefunden werden. Im dritten Schritt werden nun Gestaltungsvorschläge bzw. Gestaltungsalternativen erarbeitet, um diese in geeignete Prototypen umzusetzen. Im vierten Schritt wird der Benutzer mit dem Prototypen konfrontiert und aufgefordert, die vorher definierten Aufgaben zu erledigen, dabei wird sein Vorgehen überwacht (gegebenenfalls dokumentiert) und nach der Benutzung des Prototypen wird eine Befragung des Nutzers über seine Meinung und Erfahrung mit dem Prototypen durchgeführt. Der Prototyp wird so evaluiert und gegebenenfalls wird in eine frühere Phase zurückgesprungen (je nachdem, wo der Fehler zu suchen ist) und eine Verbesserung, aufgrund der Bewertung und Information des Nutzers, durchgeführt.

Sprünge in verschiedene Phasen

Während Dubberly diesen Prozess als Kreis darstellt, indem man nach einer negativen Evaluation wieder in die erste Phase zurückspringt, sind auch Versionen zu finden, die es ermöglichen, ebenfalls ausgehend von einer negativen Evaluation, in jeden vorangegangen Schritt zurück zu springen.

Was bedeutet das für den Designprozess?

Sicht des Softwareentwicklers

Dieses Modell wurde sicherlich aus der Sicht des Softwareentwicklers erstellt – jedoch lassen sich auch hier grundlegende Gemeinsamkeiten mit bereits vorgestellten Designprozessmodellen finden: Während der erste Schritt ganz abstrakt die Analyse bezeichnet, stellt der zweite Schritt die Zielsetzung ausgehend von der Problemlösung dar. Im dritten Schritt, der in diesem Model das Prototyping bzw. die Umsetzung für die Evaluation beschreibt, wird in anderen Modellen ebenfalls als Umsetzung und / oder als Synthese bezeichnet. Im vierten Schritt erfolgt die Evaluation mit dem Benutzer und aufgrund des Ergebnisses, wird wieder in den Kreis gesprungen oder das gewünschte Ergebnis / Produkt wurde erreicht.

Interfacedesign & Zirkularität

Im Interfacedesign (für diesen Zweig wurde diese Norm auch im weitesten Sinne geschaffen), ist dieser Vorgang ein sehr guter Ansatz um ein äußerst benutzerfreundliches Ergebnis zu erhalten – Stichwort: Usability. Gerade die Zirkularität, die sich aus der Evaluation bzw. im abstrakten Sinne aus dem Benutzer ergibt, legt nahe, dass es kein Masterkonzept zur Erstellung von Mensch-Maschine-Systemen gibt und, dass diese immer den Prototypen als Werkzeug braucht, um die Schnittstelle des Konzeptes zum User herzustellen.

One has to be able to describe
one’s methods before one
can assess or improve them – John Christopher Jones

2.13 design process von Cross

2000 | The design process must converge von Nigel Cross

Konvergenz & Divergenz gipfeln in eine Lösung

Nigel Cross, Professor für Design an der Technologiefakultät in UK Open University, beschäftigt sich bereits seit 1969 mit dem Designprozess und dabei besonders mit den Denkweisen, die die Disziplin Design erfordert. Er entwickelt viele Modelle des Designprozesses. Das hier vorgestellte beschreibt nur einen Umstand, der beim Designprozess erforderlich ist. Cross beschreibt in diesem den ständigen Wechsel zwischen Divergenz und Konvergenz des Designprozesses, jedoch im Unterschied zu Banathys Modell wird die »Amplitude« dieser Konvergenz und Divergenz im Laufe des Prozesses bzw. des Projektes immer kleiner, bis sie schließlich in eine Lösung gipfelt.

Zufällige Suche & vorgefertigte Strategie

Den Designprozess beschreibt er als Mischung der beiden Extreme des zufälligen Suchens (Divergenz) und der vorgefertigten Strategie (Konvergenz). Normalerweise sollte der Designer von Konvergenz geprägt sein, jedoch ist es manchmal im Prozess erforderlich die Suche wieder etwas zu erweitern (Divergenz) bzw. neue Ideen zu suchen – dies aber nur als Mittel, um so im Nachfolgenden mehr Konvergenz zu erzeugen.

Unterschiede der Denkweise

Cross berichtet in seinem Buch »Engineering Design Methods Strategies« davon, dass Psychologen herausgefunden haben, dass einige Menschen eine mehr konvergente Denkweise haben, während andere eine divergente Denkweise betreiben. Dieser Umstand bedeutet, dass einige Designer in konvergenten Phasen besser sind als in divergenten Phasen und umgekehrt. Dieser Umstand könnte auch genutzt werden, wenn man in einem Designteam arbeitet – dann würden die konvergenten Denker in Phasen der Konvergenz einen hohen Anteil an der Mitarbeit haben, während in divergenten Phasen andere (divergent denkende) Designer in den Vordergrund treten. Die Stärken der konvergenten Denker sind die Auswahl von Details, umsetzbare und optimale Lösungen und die Evaluation. Die divergenten Denker hingegen sind gut darin, Konzepte zu entwickeln und haben eine weite Bandbreite von groben Ideen bzw. Alternativen. Ingenieure sind meist konvergente Denker. Im Designprozess sollten beide Denkweisen eingesetzt werden.

Forderung nach Zirkularität

Auch wenn die Darstellungsweise des Diagramms scheinbar linear ist, wird durch den Kontext klar, dass Cross eine Zirkularität fordert – ausgedrückt durch eine gewisse Zielgerichtetheit (Konvergenz) im Wechsel mit einer gewissen Zieldiffusität (Divergenz). Dadurch wird ausgedrückt, dass der Weg durch den Designprozess auch durch Erfahrung und Informationen aus dem Prozess (während des Prozesses) determiniert wird.

Was bedeutet das für den Designprozess?

Richtungsänderung

Auch, wenn die Visualisierung von Cross eher auf eine Linearität hindeutet, ist seine Sichtweise ein klares Statement für die Zirkularität im Designprozess. Nach seiner Sicht ist es nicht nur möglich, sondern auch notwendig im Designprozess selber die Richtung zu ändern, bzw. nicht starr sein anfangs definiertes Ziel zu verfolgen, sondern immer wieder seinen bisherigen Stand in Bezug auf das Problem und die Lösung zu reflektieren.

 

»but within the process of reaching
that final designthere will be times
when it will be appropriate and
necessary to diverge« – Nigel Cross

2.14 Goal directed design process von Cooper

2001 | Goal directed design process von Alan Cooper

Funktionsüberladung

Alan Cooper ist kein typischer Designer – er kommt aus der Ingenieursrichtung und ist in der Softwareentwicklung tätig. Über seine Tätigkeit, besonders im Interface-Design, hat er bereits mehrere Bücher veröffentlicht, die eine bessere und leichter zu bedienende Programmoberfläche fordern. Der Umstand, so Cooper, dass zusätzliche Funktionen in Softwareprogrammen, im Gegensatz zu mechanischen Maschinen, kaum die Produktionskosten erhöhen, führt dazu, dass Programme mit Funktionen überladen werden und diese Funktionsüberladung machte die Software schwieriger zu benutzen – frei nach dem Motto: Viel hilft viel!

Usability

Dass dieses Motto nicht zutrifft, kann man an den neusten Entwicklungen in der Softwarebranche (und im Interfacedesign von Geräten allgemein) sehen: Cooper fordert eine stärkere Auseinandersetzung mit der Usability und Benutzerfreundlichkeit von Software und sieht hier auch den Schlüssel bzw. das Problem für die Zukunft – Programme werden immer unübersichtlicher und bedürfen einer Überarbeitung hinsichtlich der Gestaltung und Informations- bzw. Funktionsstrukturierung. Cooper nimmt kein Blatt vor den Mund und verurteilt die ganze Softwareindustrie: Sie hätten keine einheitlichen, standardisierten Prozesse, um die Qualität von Software zu verifizieren.

Kein Trial-and-Error Prozess

Ihr Prozess besteht aus Trial-and-Error, was vielleicht noch in der Vergangenheit funktioniert hat, wird in Zukunft immer schwerer bzw. führt zu kaum noch ohne Handbuch bedienbaren Interfaces. Mit seinem Prozessmodell, das sich rein auf die Softwareentwicklung bezieht, stellt er die Benutzerziele in den Mittelpunkt, um die herum sich alles andere aufbaut. Die Qualität des Softwareproduktes richtet sich u.a. auch nach den Fähigkeiten und Gestaltungsleitsätzen (und deren Anwendung während des Prozesses) des Designers. Das Diagramm von Cooper zeigt den Prozess, gelesen von links nach rechts, ohne Feedback-Sprünge, die er allerdings auch vorsieht, die jedoch hier, wahrscheinlich aufgrund von Übersichtlichkeit, weggelassen wurden.

Phasen des Modells

Im ersten Recherche-Schritt wird ein Briefing erzeugt, in dem Intention und Grenzen festgelegt werden, woraufhin eine Prüfung erfolgt, was es bereits gibt bzw. wie die Konkurrenz mit dem Problem umgeht. Das Ergebnis aus der zweiten Phase (Audit) sollte eine Zusammenfassung und eine daraus resultierende Erkenntnis sein, die man dann in der dritten bis fünften Phase weiterentwickelt, evaluiert und untermauert bzw. verschiebt. In der dritten Phase, die sich mehr mit Vermarktungsmöglichkeiten und wirtschaftlichen Dingen befasst, werden Rahmenbedienungen geklärt, woraufhin in der vierten Phase praktische Situationsrecherche betrieben wird, um zu eruieren, in welchem Umfeld und wie User interagieren könnten. Interaktiv werden nun in der fünften Phase Personas konstituiert und auch praktische Vermarktungs- und wirtschaftliche Möglichkeiten definiert. Basierend auf den in den vorangegangenen Phasen zusammengetragenen Informationen werden nun Ziele definiert, die zu einer geeigneten Software führen können. Danach folgen Phasen der Synthese. Ein einheitliches Konzept wird fixiert und Szenarios werden erstellt, in denen sich der Umgang mit der Software abspielen könnte. Danach folgt die Phase der funktionalen Elemente, die die Software ausmachen sollte und die Bedingungen werden aufgrund der vorangegangenen Informationen, ausgearbeitet. In der vorletzten Phase, die Framework-Phase, werden die Komponenten miteinander verknüpft und letztendlich, in der finalen Phase, werden Spezifikationen festgesetzt, die das Produkt bestimmen sollen.

Was bedeutet das für den Designprozess?

Prozessmodell mit Methoden

Coopers Modell ist sehr detailliert und bietet teilweise schon Methoden bzw. Konsequenzen aus Methoden als Endprodukt der jeweiligen Phase an. Sein Standpunkt ist, wie bereits beschrieben, der des Softwareentwicklers bzw. Interfacedesigners (in einer sehr speziellen Definition) und repräsentiert, im Gegensatz zu den anderen bereits erwähnten Modellen, eine sehr spezielle Sichtweise. Aber auch hier kann das Modell durch Abstraktion auf einige andere (jedoch nicht alle) Designdisziplinen erweitert werden.

Großer Anteil an Recherche & Evaluierung

Die Besonderheit dieses Modelles ist augenscheinlich der große Anteil von Recherche und Evaluierung der Recherche (Analyse). Coopers Modell kommt erst sehr spät im Prozess zu einer Zieldefinition und auch diese Zieldefinition wird nochmals evaluiert und redefiniert. Die letztendliche Umsetzung wird nur durch die letzten zwei Phasen repräsentiert.

Wirtschaftlichkeit?

Ein Kritikpunkt wäre hier die Wirtschaftlichkeit dieser langen Analyse, die sicherlich nur bei sehr komplexen Funktionsträgern, Rechnung trägt. Aber wie bereits erwähnt, wird die Zukunft, welche sich durch eine Komplexitätserhöhung auszeichnet, mehr und mehr nach einem solchen Modell (also nach einer ausgedehnteren Recherche und Analyse) verlangen. Bemerkenswert ist außerdem, weil vergleichbar mit Jones Ansatz, das Problem in Teilprobleme zu splitten. Um eine bessere Übersicht (über Lösungen der Teilprobleme) zu erhalten, ist der Umstand, dass erst sehr spät im Prozess Funktionen definiert werden und noch später die Verbindung eben dieser Funktionen (Übertragung auf Jones: Teillösungen) erfolgt. Auch dieser Umstand ist wahrscheinlich für sehr komplexe Probleme bzw. Funktionselemente gedacht. Die Wirtschaftlichkeit und Marketingmöglichkeiten bilden bei Cooper einen festen Bestandteil des Prozesses und sollten in unserer hoch kapitalistischen Gesellschaft offensichtlich auch Teil des Prozesses sein.

 

»No matter how cool your interfaceis, it would be better if there were less of it« – Nigel Cross

2.15 Feedback Loops von Pangaro

2002 | Second Order Feedback Loops von Pangaro

Multidisziplinärer Ansatz

Paul Pangaro, Doktor an der Stanford University in Kalifornien, kann als Kybernetiker bezeichnet werden, der jedoch auch anderweitige Hintergründe hat: Sprachtheorie, Designtheoretiker, technische Geschäftsleitung und Unternehmer. Insofern ist sein Ansatz ein multidisziplinärer und teilweise auch aus der Designsichtweise (wenn auch nur aus der Produktgestaltungsbetrachtung).

Goal-action-feedback-loops

Sein Modell ist sehr abstrakter Natur und eine Weiterentwicklung seines Vorgängermodells (Goal-action-feedback-loops). Sein Vorgängermodell ist ein zirkulärer, zielorientierter Aktionskreis. Nach Pangaros Einschätzung agieren Designer demnach, indem sie ein Ziel haben, bestimmte Dinge tun, um dieses Ziel zu erreichen und danach ihre erreichten Ziele mit dem gesetzten Ziel vergleichen und eventuell nochmal in den Kreis gehen, wenn das erreichte Ziel nicht mit dem definierten Ziel übereinstimmt, um das zu erreichende Ziel zu erreichen.

Einfluß der Umwelt

In diesem Modell spielt auch die Umwelt, in dem das Ziel erreicht werden soll, eine Rolle. Das sogenannte Feedback spielt in der Kybernetik, wie auch in diesem Kreis, eine große Rolle. In seinem »Second-order feedback loop« wird ein zweiter Kreis in das Modell integriert, wobei der zweite Kreis dafür sorgt, das Ziel des ersten Kreises neu zu definieren. Hugh Dubberly benutzt die Analogie eines Thermostates für die bessere Veranschaulichung dieses Modells: Während der erste Kreis, also das Vorgängermodell des »Second-order feedback loops« für ein Thermostat steht (also die »Maschine« im abstrakten Sinne, die kontinuierlich die Raumtemperatur misst und je nachdem, ob eine bestimmte Temperatur erreicht wurde, die Heizung ab- oder zuschaltet), steht der zweite Kreis für den Menschen, dessen Ziel es ist, eine angenehme Raumtemperatur zu haben. Das Ziel des zweiten Kreises ist also eine angenehme Raumtemperatur, die sich im Zweifelsfall verändern kann. Das Ziel des zweiten Kreises sorgt für die Anpassung des Zieles im ersten Kreis. Der Mensch findet also, auch wenn der erste Kreis sein Ziel erreicht hat (beispielsweise eine Raumtemperatur von 21°C), das zweite Ziel, eine ihm angenehme Raumtemperatur noch nicht erreicht wurde und verändert das Ziel des zweiten Kreises zu einer Raumtemperatur von 23°C, was wiederum das Ziel des ersten Kreises verändert.

Zweifache Abstimmung der Ziele

Insofern erfolgt eine zweifache Abstimmung von Zielen (Second Order Cybernetics) – während bei Pangaro der erste Kreis meist für eine Maschine steht, erfolgt im zweiten Kreis das Abstimmen der durch die Maschine erreichten Ziele mit der Umwelt und mit dem im zweiten Kreis (auf einer höheren Ebene) definierten Ziel.

Was bedeutet das für den Designprozess?

Kybernetik

Pangaros Modell der zwei »Feedback-Loops«, bestehend aus zwei Kreisen, ist sehr wichtig für den Designprozess, weil es noch einmal sehr eindrücklich und aus Sicht der Kybernetik darstellt, dass Design eben nicht nur ein zielorientierter Lösungsprozess ist, sondern auch damit zu tun hat, Ziele aufgrund von Evaluation im Prozess neu zu definieren. Sein Modell bedient im Grunde genommen zwei Ziele. Zum einen, ein in der zweiten Ebene definiertes Hauptziel und zum anderen, ein Teilziel, welches ständig (im zweiten Kreis) mit dem Hauptziel abgeglichen wird.

Zwei Ziele

Die Erreichung des ersten Zieles kann mit mechanischer Abarbeitung erreicht werden, ob jedoch das Hauptziel erreicht wird, muss erst im zweiten Kreis geprüft werden und wenn das zweite (Haupt-)Ziel nicht erreicht wird, muss das erste Ziel neu definiert werden. Dabei ist das Hauptziel als ein sehr abstrakt definiertes Ziel zu verstehen, das eine lösungsorientierte Hinarbeit kaum ermöglicht, weil es zu schwammig, zu abstrakt definiert wurde – es ist zu komplex und so wird ein erstes Ziel definiert, was wesentlich leichter erreicht werden kann. Hier trifft man wieder auf die prophezeite Komplexität in der Zukunft und ein Ansatz der Lösung eben dieser Komplexität.

Analogie zum Auflösen in Teilprobleme

Im abstrakten Sinne ist auch hier eine Analogie zu Jones Aufbrechen in Teilprobleme, bzw. -lösungen zu erkennen – es muss zwei Teilziele geben – wobei das erste Teilziel immer wieder angepasst und verglichen werden muss. Auch das Einbinden von zwei Evaluierungsprozessen in das Modell ist hier entscheidend und lässt einen Umgang mit komplexen Sachverhalten, die bei einer ersten Zieldefinition meist gar nicht oder nur teilweise am Anfang des Projektes erfasst werden können, zu.

Konkretisierung von Konvergenz & Divergenz

Ähnlichkeiten zu Cross Modell (Convergence – Divergence) sind erkennbar, werden hier jedoch noch erweitert und konkretisiert, indem ein (scheinbar) zwei-Ebenen-Prozess definiert wird. Insofern ist dieses Modell für komplexe Projekte geeignet, wie sie in Verbindung mit technisierten und vernetzten Prozessen oder Produkten auftreten können. Für niederkomplexe Projekte sind die zwei Ebenen eher hinderlich und können Ressourcen verschlingen, die für ein einfaches Projekt nicht da bzw. nicht erforderlich sind.

»Knowing whether you have reached your goal requires feedback, a concept that comes from cybernetics« – Paul Pangaro

2.16 Development process von Pacione

2002 | BodyMedia product development process von Chris Pacione

Interfacemodell

Chris Pacione, Gründer und CEO des LUMA Institutes, hat ebenfalls ein Modell entwickelt, welches für den Designprozess sehr interessant sein dürfte. Seine Perspektive ist dem des Designers schon näher, auch wenn er sehr multidisziplinär engagiert ist. So hat er auch Bücher veröffentlicht, die mehr Innovationen in Unternehmen bringen sollen. Sein Modell ist angelehnt an Barry Boehms Modell aus dem Jahre 1986 – welches sehr auf Produktgestaltung ausgelegt war. Pacione hat Boehms Modell etwas verändert, wobei es jetzt auch mehr auf die Interfacedisziplin abzielt. Dieses Modell wurde zwar von Chris Pacione 2002 entwickelt, jedoch erst 2009 von Nico MacDonald in seinem Buch »What is Web design?« veröffentlicht.

Zyklisches Modell

Die Spiralform des Modells soll die sich wiederholenden Zyklen darstellen – den Startpunkt hat der Prozess bei diesem Modell im Mittelpunkt und geht von da aus immer weiter nach außen. Die einzelnen Phasen werden durch die vier Felder definiert, die die Linie durchquert. Auch Pacione verknüpft seine Phasen teilweise mit Methoden, wobei diese nur als Vorschlag angesehen werden können. Die Wege zwischen den Punkten markieren die einzelnen Phasen – sinnvollerweise enden die Phasen dabei immer beim Eintreten in ein neues Phasenquadrat. Die vier Phasen des Modells erinnern dabei an verschiedene andere, bereits betrachtete Modelle: Define (Definieren), Design (designen), Delve (vertiefen), Determine (determinieren).

Vom Allgemeinen zum Konkreten

Der Inhalt der Phasen ist anfangs noch sehr generell und kaum spezifisch, es erfolgt kein Auseinandersetzen mit Details – alles ist noch sehr »quick and dirty«. Je weiter die Spirale sich vom Startpunkt entfernt, um so spezieller, detailreicher und spezifischer werden die Aufgaben bzw. die Auseinandersetzungen mit dem Produkt. Auch bei diesem Modell sieht man wieder eine Zirkularität, wobei das willkürliche Hin- und Herspringen scheinbar nicht möglich ist. Somit ist zwar der Prozess zirkulär, die Vorgehensweise jedoch linear, da beispielsweise immer auf die Phase des Designens, die Phase der Vertiefung folgt.

Was bedeutet das für den Designprozess?

Spiralförmiges Modell

Die spiralförmige Darstellung ist anfangs sicher etwas gewöhnungsbedürftig, jedoch erweitert sie die Darstellung um einen weiteren interessanten Fakt: Während um den Startpunkt herum noch alles sehr grob ist, wird es nach außen hin immer spezieller und detailreicher – hier kommt also zu den Phasen und den Wiederholungen der Phasen noch eine weitere Ebene hinzu.

Kein Zurückspringen

Dass das Zurückspringen in diesem Modell nicht angedacht ist, wäre ein Kritikpunkt, der gegen das Modell spricht. Das sehr schnelle bzw. frühe Anfertigen von Prototypen und damit das Testen der ersten groben Idee ist ein Fakt, der für die Wirtschaftlichkeit dieses Modelles spricht, da schon sehr früh auch an einer praktischen Umsetzung gearbeitet werden muss und kann und darauf basierend wieder die Analyse stattfindet. Dies erinnert etwas an das Modell von Bill Newkirk (1981), der auch damals schon erkannte, dass Analyse und Synthese schon sehr früh Hand in Hand gehen müssen und sich in Wechselwirkung zueinander befinden.

Dieses Modell ist nun eindeutig für Software bzw. Interface-Entwicklung gedacht, kann jedoch durch Abstraktion auf andere Disziplinen übertragen werden – schließlich sind die Phasen und eben die Wiederholungen dieser Phasen sehr allgemein gehalten.

»the product must be the right thing
to make, posits designers as
synthesizers and indicates the
relationship with users is on-going« – Nico MacDonald

2.17 Innovation planning von Kumar

2003 | Innovation planning von Vijay Kumar

Beobachtung der Realität

Vijay Kumar ist Professor am IIT Institute of Design, wo er strategische Designplanung und Design-Methoden lehrt. Insofern ist seine Sichtweise wohl eine der passendsten, denn er kommt direkt aus dem Design, ist jedoch auch als Unternehmensberater tätig. Für ihn startet der Designprozess im Realen – der Realität. Die Beobachtung von handfesten Faktoren und Zuständen in der Realität ist Ausgangspunkt und wird durch Abstrahierung des Gesehenen und Erstellung von konzeptionellen Modellen besser verstanden. Die Abstraktion der Realität hilft dabei, neue Konzepte zu erforschen. Auch er ist für ein Vor- und Zurückbewegen im Innovations – prozess, bzw. Designprozess.

Oszillisation zwischen Realem & Abstraktem

Dabei sollte der Prozess zwischen Realem und Abstrakten und Verstehen und Machen hin und her oszillieren. Kumar bemerkt in seinem Buch »101 Design Methods«, dass der Designprozess nicht linear ist, auch wenn die Idee eines Prozesses nahelegt, dass es eine lineare Sequenz geben muss. Sein Modell kann auch nicht als Fahrplan verstanden werden, in dem eine Phase auf die andere folgt – beispielsweise kann es in einem Projekt mit Brainstorming losgehen (also der Synthese – explore concepts) und danach kann dann zurück gesprungen werden in die Analyse und die Recherche, um die, im Brainstorming gesammelten Ideen, zu variieren bzw. zu überprüfen, um danach weiter entwickelt zu werden.

iterativer Prozess

Auch er spricht von einem iterativen Prozess und so kann auch in seinem Modell Zirkularität erzeugt werden und einige Phasen mehrmals durchlaufen werden. Sein Modell besteht zwar aus vier Quadraten – aber in diesen vier Quadraten befindet sich nochmals eine Unterteilung – insgesamt besteht sein Prozess aus sieben Phasen, die durch die vier Quadrate in Kategorien eingeteilt werden. Mit welcher Kategorie begonnen wird. Dies ist nach seinem Modell nicht festgelegt, nahe liegt jedoch, das Beginnen im »understand«- und »real«-Quadrat, ist jedoch nicht zwingend. Die sieben Phasen sind:

Phasen des Modells

1. Phase: Sense Intent (Zieldefinition)

Bevor es mit dem Projekt losgeht, sollte die Welt um uns herum betrachtet werden: Veränderungen in der Technologie, Gesellschaft, Kultur, Politik und andere Faktoren. Außerdem sollten neueste Nachrichten, technologische Neuerungen und allgemeine Veränderungen recherchiert werden (dies sollte der Designer jedoch projektunabhängig zu jeder Zeit betreiben). Diese Möglichkeiten und Informationen sollten bei der Zieldefinition herangezogen werden. Auch Kumar fordert in dieser Phase ein Zurücktreten vom eigentlichen Problem, bzw. von den Details und das Ausweiten der Sicht auf eine höhere Ebene, um das Überthema und die eventuell schon darin angelegten Grundprobleme zu erkennen.

2. Phase: Know Context (Kontextanalyse)

In der zweiten Phase wird der Kontext, in den sich die Innovation bzw. das Produkt integrieren soll, analysiert. Dazu gehören bereits vorhandene Produkte, Dienstleistungen, Erfahrungen und der Markt allgemein. Ein weiterer Bestandteil dieser Phase ist das Recherchieren, Analysieren und Untersuchen von Konkurrenzprodukten bzw. von Produkten die einen ähnlichen Ansatz und / oder Funktion haben. Interessant in dieser Phase sind auch äußere Einflüsse (eben durch den Kontext), die auf das Produkt bzw. auf seine Funktion wirken – dazu gehören z.B. politische Regulationen und industrielle Vorgaben bzw. Einschränkungen.

3. Phase: Know People (Personenanalyse)

Das Ziel dieser Phase ist, die Ziele von den Benutzern zu verstehen und auch ihre Umgebung mit Wechselwirkung zwischen ihren Zielen zu analysieren. Für diese Phase sind mächtige Methoden nötig – nur Interviews oder Befragungen reichen nicht aus, weil man davon ausgeht, dass die Reflexionsfähigkeit der meisten Benutzer nicht ausreicht, um neue Innovationen zu explorieren. Deshalb sollte man Endbenutzer auch in bestimmten Situationen überwachen und andere Methoden verwenden, die nicht auf einfache Aussagen der Endnutzer gestützt sind. Eine Wechselwirkung zwischen Analyst und den zu untersuchenden Leuten sollte und muss für eine fruchtbare Recherche entstehen.

4. Phase: Frame Insights (Analyse zusammenfassen)

In dieser Phase erfolgt die Zusammenfassung der Informationen, die in den vorangegangenen Phasen ermittelt wurden. Dabei geht es um die Strukturierung der Informationen, um das Erkennen von Zusammenhängen und Mustern und das Ermitteln von Möglichkeiten und / oder Nischen. Die Konsequenz aus dieser Analyse ist ein besseres Verständnis der Umstände und mehrere Blickwinkel bzw. Perspektiven zu erhalten. Systeme werden aufgrund der eruierten Information modelliert und Grundstrukturen ermittelt.

5. Phase: Explore Concepts (Konzepte ermitteln)

Nach den (teilweise) abstrakten Analysephasen folgen nun Phasen des »Machens«. Anhand der strukturierten, ermittelten Informationen werden nun (zum Beispiel durch Brainstorming) Konzepte erdacht. Kumar betont hier auch die Wichtigkeit von Teamarbeit, die bei der Generierung von neuen Ideen wie ein Katalysator wirkt (»…We ensure that fresh and bold ideas are generated through collaborative sessions. Team members build on each other‘s concepts while carefully postponing critical evolution…«). In dieser Phase werden auch grobe Prototypen angefertigt – um sie im Team zu diskutieren oder auch Kundenfeedback zu erhalten. Aufgrund zuvor speziell für das Projekt ausgebildeter Designprinzipien werden (allgemeine) Konzepte ermittelt und mithilfe von Hilfsmitteln (z.B. Prototypen) kommuniziert.

6. Phase: Frame Solutions (Lösungen ausarbeiten)

Nachdem nun die vorhergehende Phase der Divergenz von Konzepten beendet ist, markiert diese Phase die Auswahl und Hierarchisierung von Konzepten. Eine mögliche Kombination bzw. Vernetzung von Konzepten wird ermittelt und es wird evaluiert, welche Konzepte für den Benutzer und den Auftraggeber den meisten Wert bringen. Iterativ werden jetzt Prototypen erstellt, um dem Benutzer konkret zu zeigen, was möglich ist bzw. sein könnte. Die Methode des Prototypen ist natürlich nur Mittel zum Zweck – das Werkzeug, um seine Lösung dem Kunden und dem Benutzer zu kommunizieren muss von Fall zu Fall ausgewählt werden. Wichtig ist hier, dass der Prototyp (oder die jeweilige Darstellungsform) möglichst nah an der Lösung ist und sich zur Kommunikation der konkreten Intention eignet.

7. Phase: Realize Offerings (Realisierung)

Die letzte Phase ist die eigentliche Umsetzung. Es wird sich für eine Umsetzung entschieden, Prototypen werden auf Umsetzbarkeit, Viabilität, Details und technische Spezifikationen getestet. Kumar deutet hier auch das Entwerfen eines Businessplanes für das Produkt an und das Eruieren von Produktionsdetails und Besonderheiten. Im Dialog mit Auftraggeber und Produktion werden weiterhin auch nochmal Details abgeglichen (Umsetzbarkeit – Produktionskosten).

Was bedeutet das für den Designprozess?

Sehr abstraktes Modell

Kumars Modell ist wohl das abstrakteste hier vorgestellte Modell. Dieser Abstraktionsgrad des Designprozesses bietet Vor- aber auch Nachteile. Zum einen ist die Reihenfolge, in der die Phasen durchlaufen werden, nicht vorgegeben, was gleichzeitig ein Vor- und Nachteil ist. Dadurch entsteht eine größere Unsicherheit, welche Phase nun auf die vorherige folgen soll (obwohl natürlich durch die Nummerierung eine scheinbare Reihenfolge vorgegeben ist). Weiterhin muss in jeder Phase reflektiert werden, wie der Stand des Projektes ist und welche sich anschließende Phase die sinnvollste ist.

Universell durch Abstraktion

Die hohe Abstraktion des Modells bietet jedoch die Möglichkeit, dieses Modell auf viele Designdisziplinen zu übertragen. Kumar kommt sicherlich aus dem Interface-Feld, jedoch lässt sich durch eine geringfügige Verschiebung bzw. Redefinierung der Phasen ein Modell entwickeln, das eventuell auf alle Disziplinen angewendet werden kann.

Wirtschaftlichkeit

Bemerkenswert an seinem Modell ist auch die Integration eines Businessplanes, der in Wechselwirkung mit dem erarbeiteten Konzept angepasst wird und sich so in einem Firmenproduktportfolio optimal eingliedern lässt. Die Wirtschaftlichkeit sollte bei der Umsetzung und Konzepterarbeitung auch eine Rolle spielen, so arbeitet der Designer nicht in einer realitäts- (bzw. markt-) fernen Welt sondern designt immer auch für eine konkrete Realität und einen konkreten Markt bzw. eine konkrete Zielgruppe, die jeweils ihre eignen Präferenzen und Spielregeln hat, die bei der Umsetzung auch Rückkopplungseffekte haben sollte.