Anmerkung: Die erste Fassung dieses Textes wurde von Röbi kritisiert. Jetzt habe ich sie überarbeitet. Ich habe aber auch ein Replik zur Kritik von Röbi geschrieben.
| Design zeigt sich in einem Sitzmöbel, das man besitzen aber nicht besitzen kann. |
Im konventionellen Design-Verständnis sind die Designer die Lieferenten von konkreten Produkte-Ideen. Stillgeschwiegen (impliziert oder vorausgesetzt) wird in diesem Verständnis die eigentliche Erfindung des Produktes. Design beruht auf Optimierungsüberlegungen, in welchen das konkrete Produkt aus einer prinzipiellen Idee, die dem Erfinder zugeschrieben wird, entwickelt (designed oder gestaltet) wird. Natürlich kann der Designer auch der Erfinder sein, die eigentliche Design-Phase setzt aber nach der Erfindung ein, sie ist Gestaltung von Etwas, was im Prinzip schon da ist. Im Industriedesign ist das weitgehen unproblematisch, die Designer einer Autofabrik designen Autos. In der Architektur - wo es seit längerem nichts mehr zu erfinden gibt - ist das Design die Paradediziplin. Architekten sind Designer im engeren Sinne des Wortes. Sie bringen das ausgestaltete Produkt einer Gebäude-Idee, der Bauingenieur und der Handlanger realisieren die Idee.
Industriedesign und Architektur sind Leitbilder eines Designverständnisses. In diesem Verständnis erfindet der Architekt kein Gebäude, sondern die Form eines bestimmten Gebäudes. Das Gebäude selbst ist als Idee bereits erfunden und ideell im Kopf des Architekten, wenn er zu zeichnen beginnt. Und Design lässt sich in diesem Sinne sehr wörtlich nehmen: eine Zeichnung machen, ein Abbild von etwas, was bereits existiert und in dieser Form auch durch den Anweisungscharakter des Bauplans existieren soll.
Dieses Verständnis von Design ist die Lösung eines praktischen Problems: Wenn ein Produkt neu gestaltet wird, ist zunächst ungeklärt, ob es dasselbe Produkt in neuer Gestalt ist, oder ob es sich um ein neues Produkt und mithin um eine Erfindung handelt. In unserer Praxis entscheidet das Patentamt, ob etwas ein Erfindung ist. Es behandelt (oder verdrängt) dabei immer den Unterschied zwischen Erfindung und Design. Ein Auto oder ein Haus kann man - in unserer patenten Rechsauffassung nicht mehr erfinden - deshalb muss man sie designen. Design steht in diesem Verständnis anstelle von Erfindung. Wenn ein konventioneller Konstrukteur etwas, beispielsweise einen Heizkessel oder einen Automotor konstruiert, dann weiss er, vorweg was er konstruiert, und wir sprechen deshalb nicht von einer Erfindung. In der Informatik werden die Produkte häufig (inbesondere, wo die Industriealisierung noch gering ist) als Erfindungen aufgefasst. Im Konstrast dazu steht allerdings die Patentierbarkeit von Programmen. Patentrechlich erscheinen alle Applikationen als Design von Computern im Sinne von verschiedenen Ausgestaltungen der Hardware.
Im einschlägigen Designer-Spruch "Form follows Functon" wird nachgeliefert, dass das Design die Funktion bestimmt - und mit gedacht wird nicht nur "schön ist, was gut ist", sondern ebenso sehr, dass Design der eigentlich kreative Akt des Schaffens ist, also Erfinden schlechthin.
Konrad Lorenz hat in einem ganz abwegigen Zusammenhang ein anschauliches Beispiel gegeben: Die ersten Wagons der Eisenbahnen sahen aus wie Kutschen. Im Laufe der Zeit wurden sie umgestaltet zu dem, was wir heute als Bahnwagon empfinden (etwa pro Wagen mehrere Abteils mit gemeinsamen Wagon-Eingang, während die ersten Eisenbahnwagen noch pro Abteil einen Eingang hatten). Dabei kann man sich fragen, ob die neuen Wagen neu designt oder erfunden wurden.
Bei der Entwicklung des Motorrades weiss man seit langem, dass die Achsschenkellenkung der Gabel im Prinzip überlegen ist, obwohl das bisher noch nicht praktisch ausgewiesen werden konnte. Wenn man das Motorrad betrachtet, ist die Achsschenkellenkung (die beim Auto schon lange verwendet wird) eine typische Design-Idee, zu etwas, was schon da war, weil damit das Motorrad eine neue Form erhält. Man kann die Achsschenkellenkung aber auch als Erfindung auffassen, wenn man nicht das Motorrad, sondern die Art, wie das Vorderrad eingebunden wird, betrachtet. In diesem Sinne ist Design immer eine Frage der Auflösung (Granularität).
Ein Dilemma - das in unserer Praxis die Designer reklamieren, die nur noch etwas "verschönern" oder "ergonomisieren" sollen - besteht darin, dass jede Erfindung immer schon eine Form hat. "Das" Haus oder "die" Waschmaschine lässt sich nicht erfinden, sondern immer nur ein konkretes Beispiel (eine Instanz von). "Das" Haus kann man nicht zeichnen, aber jedes Haus lässt sich zeichnen. Was ich sprachlich mit "Haus", "Maschine" usw. referenziere, kann ich mir nicht vorstellen im Sinne von gedanklich vor-mich-hin-stellen. Vorstellen kann ich mir nur konkrete Häuser oder Maschinen.
Wenn man Produkte designen will, muss man zuerst die Erfindung vom mitgebrachten Design unterscheiden, damit man der Idee eine neue Form geben kann. Was wir in der Informatik diesbezüglich kennen, sind verschiedene Formen von Textbearbeitungs- oder Buchhaltungsprogrammen. Word wird kaum als Erfindung verstanden, sondern als spezielle Form von etwas. Ebenso verstehen wir Windows als Formvariante von RankXeroxs Icon-Oberfläche. Ob die graphische Oberfläche eines Betriebssystems als Design-Variante zur befehlsorientierten "Oberfläche" verstanden wird, oder ob sie eine Erfindung ist, können wir nur via Patentamtentscheid entscheiden.
Wenn man Produkte designen will, muss man zuerst die Erfindung vom mitgebrachten Design unterscheiden, damit man der Idee eine neue Form geben kann. Was wir in der Informatik diesbezüglich kennen, sind verschiedene Formen von Textbearbeitungs- oder Buchhaltungsprogrammen. Word wird kaum als Erfindung verstanden, sondern als spezielle Form von etwas. Ebenso verstehen wir Windows als Formvariante von RankXeroxs Icon-Oberfläche. Ob die graphische Oberfläche eines Betriebssystems als Design-Variante zur befehlsorientierten "Oberfläche" verstanden wird, oder ob sie eine Erfindung ist, können wir nur via Patentamtentscheid entscheiden.
Im klassischen Engineering geht es darum, Systeme zu entwerfen, die irgendwelche Menschen so gut brauchen können, dass die Systeme sich am Markt bewähren. Ein Leitsatz in diesem Zusammenhang lautet: Das System soll sich nicht erklären! Dieser Leitsatz ist eine Reaktion auf die Forderung, Systeme sollten selbsterklärend sein. Damit war gemeint, wenn man ein Handbuch oder eine Anleitung braucht, ist das System schlecht designt. Auf der neusten Stufe sagt man, wenn ein System sich selbst erklären muss, ist es schlecht designt.
Trivialerweise sagt man das bezüglich Design, nicht bezüglich Erfindungen. Gemeint ist damit, dass Design immer etwas schon bekanntes betrifft. Wenn man im Bereich der Benutzerschnittstellen eines Computers designt, dann kann und soll man an die gängigen Applikationen anschliessen, weil die den meisten Benutzern bekannt sind, resp. sogenannte Leitbilder oder Metaphern verwenden, die den Benutzern bekannt sind.
In unserem Ansatz geht es darum, Systeme zu "erfinden", die uns Auskunft über uns geben. Deshalb entfallen konventionelle Designstrategien. Wenn wir das Ding bauen, wissen wir zwangsläufig, wie wir es benutzen und am Markt orientieren wir uns nicht, weil wir nicht glauben, dass "der" Markt irgend etwas sagt, geschweige denn etwas relevantes voraussagt.
Wir konstruieren Werkzeuge als externe Gedächtnisse, um besser zu verstehen, wie wir konstruieren. (Wir entwickeln so unsere Theorie des Wissens). Das Werkzeug (und was wir damit verbinden) ist quasi eine Geschichte unseres Konstruierens.
Der Gewählte Ansatz bestand darin einzelne Teilsysteme oder Blackboxes (Marco's Aion-Funktionen) zu konstruieren, die uns sinnvolle oder nötige Funktionen erfüllen. Unterhalb der Funktionen liegt das Konzept der Objekte, mit welcem die Funktionen beschrieben (programmiert) werden. In der Entwicklung von MailTack orientieren wir uns an einer Texte-Verwaltung (e-mail-Segmente), von der wir noch keine abschliessende Vorstellung haben, die es aber erlaubt, Texte zu verknüpfen und zu kategorisieren.
Nachdem wir nun mehrere Teilsysteme programmiert haben, stellt sich die Frage der Integration. Diese Frage stellt sich, weil unser Augenmerk zunächst im Sinne eines bottom-up auf einzelnen Teilfunktionen ruhte. An diesem Punkt beginnen wir quasi mit einer neuen, höheren Konstruktion. Jetzt geht es - wie in jeder Konstruktion - darum, wie wir die Teile, die wir jetzt haben, zusammenfügen.
Dies ist auch der Zeitpunkt, an welchem wir komerzielle Partner suchen. Natürlich könnten wir an diesem Punkt mit bewusstem Design beginnen - und kommerziell denkende Partner werden das zweifelslos tun. Ansätze dazu habe ich bereits gesehen: Julia Dietsch von der Firma pRe-view in Berlin hat schöne Ideen gezeigt, ich hoffe, dass ich sie bald herkriege. Unter anderem hat sie in ihrem Ansatz Kapseln an einer netzartigen Kette verwendet, die unseren noch nicht gestalteten Streams ein Bild geben könnten. In den Kapseln sind Textelemente, die sich beim Anklicken der Kapseln zeigen. Die Kette entspricht einem Stream, man kann weitere Kapselketten an jeder Stelle der bestehenden Kette einfügen.
Ich stelle mich auf den Standpunkt, das jede Veränderung von MailTack einer Neuerfindung entspricht. Die Frage ist, wie erfinden wir MailTack konkret. Nachdem wir beachtliches Knowhow zusammenhaben, könnten wir in einen evolutionären Prozess einsteigen. Wir können uns treiben lassen und unterwegs jeweils prüfen, wo wir sind - ganz nach dem Motto unter welchen wir mit MailTack segeln:
Protokolliere (trace) deinen Wissenskurs im Laufe der Fahrt (knowledge on tack), um im Wissens-Ozean auf dem richtigen Kurs zu segeln!