The IT Design Quality - paradigmatic form and function project took as its point of departure the poor use quality of IT artefacts. Too much interest had been directed towards the technical qualities of software and systems, and too little towards the use and usefulness.

Instead of viewing this as because of flaws of systems development methods, the project focused on the skill and and abilities of the developers. According to the project they lacked or had poorly developed design ability. Ultimately it is the developers and their abilities that lead to the product quality of the IT artefact, not methods and tools (these are however important to do the job). Hence, to train the developers' design ability was viewed as more important than to devise yet another silver bullit development method.

One problem the project identified was the notion of product quality of IT artefacts and especially use quality. Often quality was uncontextual or just seen as the interaction between one user and a machine. To solve this shortcoming, the project developed a quality-in-use model based on an interpretation of Haberma's knowledge interests and quality notions in other, more mature design fields such as architecture of the built environment.

In this model an artefact can be viewed from three perspectives: the artefact aspects of form, function and structure. Form is here understood as the individual experience of using the artefact, function as the practical and symbolic use of the artefact, and structure as the artafact's material in the form of hardware and software. In order to discuss the quality of each aspect, they are connected to three quality perspectives: aesthetics, ethics, and control. Aesthetics is here understood as style, balance, and appropriateness; ethics as usefulness, value, and power; control as quality metrics and standards. A contextually suitable quality would then be a proper balance between these quality perspectives.

Another part of the project was the term "paradigmatic examples" which means exemplars. To train developers' design ability, the systems development field needed styles (with exemplars) as in other design disciplines. Exemplars could then be used to compare one's designs  to, discuss quality, be inspired by acknowledged designs, etc.

In order to make all this work, the project was meant to develop a style theory. To understand what a style theory really is and how it could be developed the concept of style was studied. It turned out that style was a very old concept and there was no common and agreed understanding that could easily be adopted and adapted. Not even in architecture, which was a paradigmatic disciplin for the project, a well agreed on and useful style theroy could be found. Thus, in a sequel project - The Qualitheque - we decided to return to the design examples and let them be the base for impression, discussion, comparison, and maybe, eventually, a style theory.