Design as interactions of problem framing and problem solving: a formal and empirical basis for problem framing in design

In this thesis, I present, illustrate and empirically validate a novel approach to modelling and explaining design process. The main outcome of this work is the formal definition of the problem framing, and the formulation of a recursive model of framing in design. The model (code-named RFD), represents a formalisation of a grey area in the science of design, and sees the design process as a recursive interaction of problem framing and problem solving. The proposed approach is based upon a phenomenon introduced in cognitive science and known as (reflective) solution talkback. Previously, there were no formalisations of the knowledge interactions occurring within this complex reasoning operation. The recursive model is thus an attempt to express the existing knowledge in a formal and structured manner. In spite of rather abstract, knowledge level on which the model is defined, it is a firm step in the clarification of design process. The RFD model is applied to the knowledge-level description of the conducted experimental study that is annotated and analysed in the defined terminology. Eventually, several schemas implied by the model are identified, exemplified, and elaborated to reflect the empirical results. The model features the mutual interaction of predicates ‘specifies’ and ‘satisfies’. The first asserts that a certain set of explicit statements is sufficient for expressing relevant desired states the design is aiming to achieve. The validity of predicate ‘specifies’ might not be provable directly in any problem solving theory. A particular specification can be upheld or rejected only by drawing upon the validity of a complementary predicate ‘satisfies’ and the (un-)acceptability of the considered candidate solution (e.g. technological artefact, product). It is the role of the predicate ‘satisfies’ to find and derive such a candidate solution. The predicates ‘specifies’ and ‘satisfies’ are contextually bound and can be evaluated only within a particular conceptual frame. Thus, a solution to the design problem is sound and admissible with respect to an explicit commitment to a particular specification and design frame. The role of the predicate ‘acceptable’ is to compare the admissible solutions and frames against the ‘real’ design problem. As if it answered the question: “Is this solution really what I wanted/intended?” Furthermore, I propose a set of principled schemas on the conceptual (knowledge) level with an aim to make the interactive patterns of the design process explicit. These conceptual schemas are elicited from the rigorous experiments that utilised the structured and principled approach to recording the designer’s conceptual reasoning steps and decisions. They include the refinement of an explicit problem specification within a conceptual frame; the refinement of an explicit problem specification using a re-framed reference; and the conceptual re-framing (i.e. the identification and articulation of new conceptual terms) Since the conceptual schemas reflect the sequence of the ‘typical’ decisions the designer may make during the design process, there is no single, symbol-level method for the implementation of these conceptual patterns. Thus, when one decides to follow the abstract patterns and schemas, this abstract model alone can foster a principled design on the knowledge level. It must be acknowledged that for the purpose of computer-based support, these abstract schemas need to be turned into operational models and consequently suitable methods. However, such operational perspective was beyond the time and resource constraints placed on this research

Just-In-Time Design in a Fast-Paced Product Group

In real world development environments where deadlines are fixed, a designer must craft a process that works with the team and within the constraints of a project. The traditional waterfall method of writing a detailed specification for each feature before development begins is often not realistic. Instead, by using a “just-in-time ” design method, the designer understands how much design direction is needed at each stage of the development process, and delivers that. The larger components must be well defined initially, while other parts can be left sketchy. The designer can spread the workload over the entire length of the project, using different steps to refine the design. Delivering the design in stages gives the design a chance to mature. Often there are many developers and few (usually 1) designers on a project. The designer is often on the critical path. To avoid being a bottleneck, the designer should use good tools and leverage the strengths of a multi-disciplinary team. The case study documented here should prove useful to other user interface designers facing resource and time constraints. A design process derived from this experience is summarized at the end