3.3.4 Designfallen

Hierarchie von Problemen
Strukturierung über Ebenen

Lawson schreibt: »…Design problems do not have natural or obvious boundaries but, rather, seem to be organised roughly hierachically. It is rarely possible to discern precisely how far above the stated problemone should begin and how far below one should call a halt…«. Ausgehend von diesem Zitat kann man Designprobleme also hierarchisch strukturieren. Dabei wird von einer Ebene in die andere das Problem analysiert – die Ebenen determinieren bzw. bestimmen die Lösung der darunter liegenden Ebene. Welche Hierarchie die Ebenen haben, muss der Designer festlegen. Diese ergeben sich aber meist logisch aus dem jeweiligen Kontext. Allerdings sollte auch hier auf die richtige Hierarchie der Ebenen geachtet werden, sonst können Zusammenhänge nur schwer erkannt werden und der Entscheidungsfindungsprozess bzw. Designprozess verkompliziert sich unnötig. Designprobleme sind also multidimensional und in wie auch zwischen den Ebenen interaktiv.

 

Probleme, die auf einer höheren Ebene angelegt sind

 

Die Vier grundsätzlichen Formen des Designprozess

 

Anekdote zu Problemebenen

Eine kleine Anekdote von Lawson beschreibt diese Fehlerquelle beim Problemlösen sehr gut: Lawson, der Architekt ist, sollte für einen Freund einen Anbau an dessen Haus entwerfen. Allerdings war das Haus groß genug und bot auch noch Raum für ein Extrazimmer – trotzdem wollte der Kunde unbedingt einen Anbau. Allerdings war dies kaum möglich, ohne den Garten zu verkleinern oder das Dach zu entfernen – jede Lösung war also mit erheblichem Aufwand und großen Investitionen verbunden. Lawson wunderte sich doch sehr über seinen Kunden, der eigentlich unbedingt mehr Platz wollte, obwohl er eigentlich schon genug Räume hatte. Seine Lösungen würden neue, große Probleme entstehen lassen und eines Tages redete er mit seinem Kunden über die Möglichkeit, dass die Eltern des Kunden einen Schlafplatz in seinem Haus finden, wo sie nicht gestört werden von der lauten Musik des auch im Haus wohnenden Teenagers. Und hier ging Lawson auf einmal ein Licht auf: Das Problem war nicht der Platz, sondern die akustische Dämmung des Hauses, bzw. die laute Musik des Kindes des Kunden. Anfangs als Witz von ihm geäußert, wurde diese Bemerkung jedoch vom Kunden sofort umgesetzt: Das Kind bekam Kopfhörer und so spart der Kunde Geld, Lawson Zeit und alle sind glücklich.

Briefing dekonstruieren

Hier haben wir es gleich mit zwei Fehlerquellen zu tun: Zum einen, dass die Problemeruierung, die vom Kunden vorgenommen wird, nicht unbedingt auf das eigentliche Problem zeigt, sondern manchmal nur auf die Symptome des Problems. Deshalb sollte das Briefing des Kunden dekonstruiert bzw. zerstört werden, um die einzelnen Teile genauer analysieren zu können. Das Briefing des Kunden sollte genau analysiert werden (auch die Verschiebung des Problems kann hierbei eintreten) und der Designer sollte auch keine Scheu haben, das Briefing umzuformulieren, wenn es nötig ist. Natürlich muss dies immer richtig kommuniziert werden. Wenn das eigentliche Problem nur ein Symptom eines höher angelegten Problems ist, erzeugt die Lösung meist neue, gleichwertige oder größere Probleme und kann das Symptom meist nur verlagern oder kurzfristig lindern. Das Briefing sollte anfangs möglichst divergent untersucht werden.

Analyse (Recherche) begrenzen – Wissen wann Schluss ist

Allerdings muss mit dieser divergenten Vorgehensweise sehr vorsichtig umgegangen werden – schnell steigt man in den Problemebenen weiter nach oben und entfernt sich immer weiter von der eigentlichen Intention bzw. vom eigentlichen Briefing, was nicht unbedingt schlecht ist, aber irgendwann landet man in Systemebenen, auf die man als Designer keinen Einfluss mehr hat. Außerdem sollte auch das Modell von Bill Newkirk bedacht werden: Die Analyse und Synthese befinden sich in Wechselwirkung zueinander.

Kein natürliches Ende von ISPs

Lawson bemerkt hier, dass es kein natürliches Ende des Designprozesses gibt. Auch das Problem wird niemals absolut gelöst sein. Es wird immer Zweifel geben und hier muss der Designer aufgrund seines Wissens und seiner Erfahrung entscheiden, wann er aufhören muss. Dies sollte der Fall sein, wenn es die Bedeutung nicht mehr hergibt. Viele (junge) Designer verlieren sich im Detail- bzw. Mikrodesign. Problematisch hier ist, dass mit sehr viel Aufwand nur noch wenig zur Lösung beigetragen werden kann.

Ressourcen im Auge behalten

Schnell kann sich der junge, unerfahrene Designer in der Analyse bzw. Recherche verlieren und sich so ewig im Kreis drehen, das Problem immer neu formulieren ohne jemals anzufangen »zu machen«. Mann sollte hier auch immer die Ressourcen (Zeit, Geld, Personal) im Hinterkopf behalten, die eventuell bei einer Neudefinition des Problems mit dem Kunden auch variabel sind, aber eben nur, wenn dem Kunden klargemacht werden kann, dass seine Investition auch wirklich nachhaltige Auswirkungen haben.

Probleme richtig hinterfragen – Blindes losarbeiten vermeiden

Newkirk hin oder her, bevor man mit der Synthese anfängt, sollte man das Problem, soweit wie es die Komplexität des Problems zulässt, verstehen. Das blinde Drauflosarbeiten hat meist zur Folge, dass man für den Papierkorb arbeitet. Leider wird dann erst bei der Evaluation der Lösung klar, dass Teile des Problems nicht oder nur unzureichend gelöst wurden. Es wurde bereits beleuchtet, dass komplexe Probleme es nicht zulassen, den gesamten Problemraum am Anfang des Prozesses zu konstituieren und dass die Evaluierung diesen Problemraum auch noch verschieben kann.

Das ist aber kein Freischein für den Designer, blind los zu arbeiten und dann auf seinem Weg zu merken, dass er in eine völlig falsche Richtung gearbeitet hat. Lawson benutzt hier das Gleichnis eines Puzzles. Puzzles, Kreuzworträtsel oder auch Sudokus sind bei den Menschen sehr beliebt, weil es ihnen innewohnt, Aufgaben zu lösen und dadurch Befriedigung zu erfahren. Allerdings haben wir ja bereits festgestellt, ist ein Designproblem von sehr komplexer Natur und ein Puzzle kann in die Kategorie »eindeutige Probleme« eingeordnet werden. Dennoch haben Designprobleme teilweise Puzzlecharakter. Die Gefahr, wenn ein Designer ein Problem wie ein Puzzle zu lösen versucht, ist, dass Regeln und Elemente sehr schnell akzeptiert werden können (man will ja auf dem schnellst möglichen Weg das »Rätsel« lösen) und nicht kritisch hinterfragt werden.

Als Beispiel kann hier das angefügte Bild herhalten

 

Beispiel für falsche Problemannahmen

Die Aufgabe ist, alle neun Punkte mithilfe von vier Linien zu verbinden. Der Stift darf dabei nicht abgesetzt werden. Viele Menschen, denen dieses Rätsel gezeigt wird, orientieren sich automatisch an Rastern und versuchen, es nicht zu verlassen. Diese Regel wurde jedoch nie genannt. Die Lösung ist, wenn man nicht von dieser ungenannten, unbewussten Regel beeinflusst wird, relativ einfach und im Bild dargestellt. Wenn man jedoch von der Regel ausgeht, die nie genannt wurde, nämlich dass das Raster nicht mit dem Stift verlassen werden darf, ist das Rätsel unlösbar.

Alles hinterfragen

 

 

Dieser Umstand illustriert gut, dass alles hinterfragt werden muss. Man kann sich damit helfen, indem man Regeln aufschreibt, dann wird genau klar und nochmal reflektiert, was man nicht darf bzw. darf und daraus kann man einfach erschließen, was man nicht darf bzw. was man darf, also was zulässig ist.

Die Bildfalle

 

Simulation und Realität

Durch den Computer, aber auch durch andere Neuerungen haben wir heute viele Möglichkeiten, Systeme und Sachverhalte zu simulieren. Das Problem solcher Simulationen ist, dass es immer nur Simulationen bleiben werden und diese somit auch nicht unbedingt in der Realität funktionieren müssen. Simulationen unterliegen immer gewissen Grenzen. Oft wird simuliert, um etwas darzustellen – z.B. 3D-Modellierungsanwendungen. Das Problem bei solchen Anwendungen ist, dass es eben nur ein Bild ist und physikalische oder andere Gegebenheiten nicht simuliert werden können. Insofern sollte sich ein Designer im Schaffungsprozess nicht so sehr auf Simulationen zur Überprüfung verlassen, sie sollten nur für die Darstellung (des hoffentlich vorher Überprüften) genutzt werden. Als Simulation kann schon das einfach gezeichnete Bild gesehen werden. Und nur, weil man etwas abbilden kann, heißt es noch lange nicht, dass es so in der Realität existieren könnte.

Kluft zwischen Designer, Auftraggeber und Kunde

 

Es wurde bereits die Anekdote des Architekten über das zu laute Musikhörverhalten des Kindes des Kunden beschrieben. Die Geschichte, in der der Kunde auch gleichzeitig Nutzer ist, trifft bei manchen Designproblemen nicht zu. Der Designer arbeitet zwar für den Kunden, also den Auftraggeber, allerdings versucht der Auftraggeber seine Produkte wiederum an den User zu verkaufen. Man hat es hier mit drei Parteien zu tun. Der Designer kommt anfangs nur mit dem Auftraggeber in Kontakt und muss sich mit ihm über die Wünsche des Kunden auseinandersetzen. Denn der Designer arbeitet zunächst für den Auftraggeber, aber indirekt auch für den Benutzer des Produktes, also den / die Kunden des Auftraggebers. Eine natürliche Lücke ist auf der einen Seite zwischen dem Auftraggeber und Designer, aber es befindet sich noch eine weitere Lücke in diesem System: Die Kluft zwischen Auftraggeber und Kunden des Auftraggebers, also dem Endnutzer. Das Problem oder die Herausforderung für den Designer ist hier die beiden Lücken zu schließen bzw. so klein wie möglich zu halten. Hierfür sollten, besonders bei sehr komplexen Problemen, auch Soziologen oder Psychologen eingebunden werden.

Fruchtbare Diskussion

Weiterhin sollte beachtet werden, dass, wenn der Auftraggeber über seine Kunden redet, das auch nur eine subjektive Sicht ist und die Lücke zwischen dem Auftraggeber und seinem / n Kunden eventuell sehr groß sein kann. Das Problem kann man als Analogie zur stillen Post sehen. Aus der Interpretation des Auftraggebers über die Wünsche seines Kunden wird eine Interpretation des Designers über die Interpretation des Auftraggebers über die Wünsche seiner Kunden. Und am Ende kommt beim Designer eventuell ein sehr verzerrtes Bild über die Wünsche des eigentlichen Kunden an. »User Requirment Studies« und andere Methoden, die direkt dem Endnutzer durchgeführt werden, können hier helfen, Lücken zu schließen. Das Briefing mit dem Auftraggeber sollte deshalb aus Kommunikation und fruchtbarer Diskussion bestehen. Hierfür werden dem Designer auch sehr viele Social Skills abverlangt, da diese konstruktive Kommunikation nicht im Feld des Auftraggebers liegt, sondern allein dem Designer zugeschrieben wird, der als Dienstleister für den Auftraggeber auch auf diesen eingehen muss.

0 Kommentare

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlasse uns deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert