Zettel, Zettel an der Wand..
Nachdem ich die Methoden auf sechseckigen Kärtchen ausgedruckt und sortiert habe, missfallen mir 1. ihre qalitativen Unterschiede in der Beschreibung der Methoden und 2. die Referenz zu den "Quellfächern" und oft ewiglange Links zu "Quelldaten". Vielleicht sollte ich sie einfach weglassen, da das Ganze ja keine wissenschaftliche Publikation sondern ein Spiel werden soll:
In diesem Spiel soll es darum gehen, die Vorgehensweise des Designs zu verstehen/nachzuvollziehen, dass Designer nicht irgendetwas aus dem Bauch heraus entscheiden, sondern durch methodische Vorgehensweise in ihrem Tun und Ergebnis legitimiert sind.
Auch soll herauskommen, dass Methoden nicht starre Korsetts sind, sondern fallbezogen anwendbare Hilfen, die ein Design/eine Designentscheidung nachvollziehbar machen. Im besten Fall ist ein Designprozess mit Hilfe der Methoden so gut dokumentiert, dass Fehler bei Designentscheidungen nachvollzogen werden können bis zu dem methodischen Schritt welcher Ursprung des Fehlers ist. Kann man nämlich diese Stelle wiederfinden, ist meiner Meinung nach eine Korrektur schneller und klarer möglich, als in einem nicht aktiv methodisch strukturierten Designprozess.
Zum Beispiel wurde in den 80ern bei der Entwicklung objektorientierter Programmiersprachen wie Java und C++ eine objektorientierte Methodologie definiert. Ein Standard der strukturiertes Programmieren ermöglicht 1. durch die Verwendung von Ablaufstrukturen (z.B. bedingte Anweisungen und Schleifen) statt rein sequentieller Reihung von Anweisungen und 2. der Lösung von Teilaufgaben in abgegrenzten Modulen. Die Hoffnung war, mit der Objektorientierung eine bessere Wiederverwendbarkeit und damit geringere Entwicklunkgskosten bei der Softwareproduktion zu erreichen.
Nun ist dies nicht 1:1 auf meine Problematik übertragbar.
Bei diesem Methodenspiel geht es nämlich nicht darum einen maschinellen, starren Prozessablauf zur Bearbeitung von Abläufen/Routinen zu konstruieren, sondern um einen geführten, von bewährtem Wissen unterstützen, kreativen Prozess.
ABER: Das systematische und das kreative Herstellen von Lösungen für ein Designproblem müssen Hand in Hand gehen, sich so ergänzen, dass das Eine zwangsläufig aus dem Anderen erwächst und sich bedingt.
Aus diesem Grund muss dieses Spiel nicht nur Wahlmöglichkeiten zwischen den Methoden im Raster der Prozessschritte bieten, sondern auch Routinen und Zwänge, wie z.B. Reflexion des Ergebnisses der Methodenanwendung (trifft das Ergebnis noch mein Ziel? Welche Faktoren habe ich aus welchem Grund vernachlässigt und zu welchen Eigenheiten meiner Lösung hat das geführt?).
Sobald ich umgezogen bin, werde ich meine Methodenzettel an die Wand arrangieren.. habe nämlich den Eindruck, dass es "Über-" und "Unterkategorien" der gesammelten Methoden gibt, die nicht auf einer Ebene behandelt werden können..
Solang aber exzerpiere ich noch was auf meiner Leseliste steht.. falls jemand mir etwas zu Lesen empfehlen möchte, der tue sich keinen Zwang an!
In diesem Spiel soll es darum gehen, die Vorgehensweise des Designs zu verstehen/nachzuvollziehen, dass Designer nicht irgendetwas aus dem Bauch heraus entscheiden, sondern durch methodische Vorgehensweise in ihrem Tun und Ergebnis legitimiert sind.
Auch soll herauskommen, dass Methoden nicht starre Korsetts sind, sondern fallbezogen anwendbare Hilfen, die ein Design/eine Designentscheidung nachvollziehbar machen. Im besten Fall ist ein Designprozess mit Hilfe der Methoden so gut dokumentiert, dass Fehler bei Designentscheidungen nachvollzogen werden können bis zu dem methodischen Schritt welcher Ursprung des Fehlers ist. Kann man nämlich diese Stelle wiederfinden, ist meiner Meinung nach eine Korrektur schneller und klarer möglich, als in einem nicht aktiv methodisch strukturierten Designprozess.
Zum Beispiel wurde in den 80ern bei der Entwicklung objektorientierter Programmiersprachen wie Java und C++ eine objektorientierte Methodologie definiert. Ein Standard der strukturiertes Programmieren ermöglicht 1. durch die Verwendung von Ablaufstrukturen (z.B. bedingte Anweisungen und Schleifen) statt rein sequentieller Reihung von Anweisungen und 2. der Lösung von Teilaufgaben in abgegrenzten Modulen. Die Hoffnung war, mit der Objektorientierung eine bessere Wiederverwendbarkeit und damit geringere Entwicklunkgskosten bei der Softwareproduktion zu erreichen.
Nun ist dies nicht 1:1 auf meine Problematik übertragbar.
Bei diesem Methodenspiel geht es nämlich nicht darum einen maschinellen, starren Prozessablauf zur Bearbeitung von Abläufen/Routinen zu konstruieren, sondern um einen geführten, von bewährtem Wissen unterstützen, kreativen Prozess.
ABER: Das systematische und das kreative Herstellen von Lösungen für ein Designproblem müssen Hand in Hand gehen, sich so ergänzen, dass das Eine zwangsläufig aus dem Anderen erwächst und sich bedingt.
Aus diesem Grund muss dieses Spiel nicht nur Wahlmöglichkeiten zwischen den Methoden im Raster der Prozessschritte bieten, sondern auch Routinen und Zwänge, wie z.B. Reflexion des Ergebnisses der Methodenanwendung (trifft das Ergebnis noch mein Ziel? Welche Faktoren habe ich aus welchem Grund vernachlässigt und zu welchen Eigenheiten meiner Lösung hat das geführt?).
Sobald ich umgezogen bin, werde ich meine Methodenzettel an die Wand arrangieren.. habe nämlich den Eindruck, dass es "Über-" und "Unterkategorien" der gesammelten Methoden gibt, die nicht auf einer Ebene behandelt werden können..
Solang aber exzerpiere ich noch was auf meiner Leseliste steht.. falls jemand mir etwas zu Lesen empfehlen möchte, der tue sich keinen Zwang an!
Juliane Münch - 7. Mär, 20:05