Prescriptive Study: Developing Design Support
5.3 A Systematic PS Process
There are two areas that can provide general guidance to developing support:
product development methodologies and software development methodologies. A summary of the various methodologies can be found in Appendix B. Interestingly, no methodology for developing methods and guidelines (heuristics) could be found.
The product and software development methodologies divide the process into a number of stages, in each of which the product or software under development becomes more detailed. In each stage the basic problem-solving cycle (see below)
is applied, although not all methodologies make this explicit. This combination of gradual development and problem-solving cycle are seen as the key elements to managing complexity and enhancing success in product development. The process, it is always emphasised, is not linear: many iterations take place within and between the stages.
The most commonly used stages are:
• task clarification: specification of problem and requirements;
• conceptual design: concept development;
• embodiment design: giving overall shape to the concept;
• detailed design: finalising the details of the embodiment and prototyping;
• testing is sometimes included in these stages, sometimes mentioned as a separate stage.
The basic problem-solving cycle, which takes place in each of the stages, essentially has the following four steps:
• establish need or clarify the problem to be solved;
• generate potential solutions for fulfilling the need;
• evaluate solutions by comparing them with each other and against the problem or need;
• decide if a suitable solution is found; if not, return to the first or second step, depending on the results.
Based on the existing methodologies, we have developed a Systematic PS process with five main steps to aid support development. It is important to note that – as in any methodology – iterations between steps will and have to take place, as the development of support is a continuous process of generation and evaluation, frequenting between various levels of abstraction.
An important feature of the proposed process is the distinction we make between Intended Support and Actual Support. The Intended Support is a description of the complete support as envisaged by the researcher. The Actual Support is a realisation of the Intended Support that may cover only a part of functionality of the intended and may be implemented in a different way, but can still be used as a proof-of-concept for the purpose of evaluation. The focus of the Actual Support should be on the core contribution of the research project, i.e., the core functionality of the Intended Support (see discussion in Section 5.7.1).
In order to be able to develop the Actual Support, it is necessary to start developing an Outline Evaluation Plan, as the intended evaluation will determine the comprehensiveness of the Actual Support. Hence, a second feature of the proposed Systematic PS process is the parallel development of the support and the Outline Evaluation Plan: the DS-II stage starts during the PS stage.
A third important feature of the proposed Systematic PS process is its emphasis on developing a strong concept and generating variants before detailing the concept. This implies that the type of implementation (paper-based, software, etc.) is not selected until the end of the conceptualisation, that is, until it is clear what type of support is most suitable for achieving the goal of evaluating the concept.
When software is to be developed, this implies that the concept is developed on
paper before actual programming is initiated. Although this seems obvious, considering the recommendations of design methodologies, too often we have seen research projects setting out to develop software to address a particular issue, without considering or investigating whether software is the best solution: maybe a workbook or checklist would be sufficient. Similarly, we have rarely seen researchers consciously generating variants (even in those cases in which the tool itself was intended to help generate variants to support designers). Developing support should follow the same best practice recommended for developing products and software. Many aspects of design methodologies can be applied for support development. The process we present here blends the characteristics of several of these methodologies.
Note that while we primarily focus on the process aspects for carrying out support development, gathering domain knowledge plays a crucial role in design research in general, and support development in particular. This was emphasised earlier in Chapter 3, when determining the scope of research: specifying the domain in which the results are applicable is necessary, and must be kept in mind all through the research process. The domain provides the content of the support and the context for use and application and thus has an influence on the focus of each DRM stage: where data is gathered; in what context the support is to be used; what functionality is to be included; which knowledge to incorporate; in which context to evaluate the support, etc. In Appendix B.2.5, some methods for knowledge acquisition are described.
The steps of the Systematic PS process are shown in Figure 5.1.
Figure 5.1 Main steps in the PSstage; stars (*) indicate steps of an Initial PS
1. Task clarification (details in Section 5.4):
- The results from earlier stages and earlier projects, such as goals, findings from DS-I or DS-II, the Reference Model, the Initial Impact
Task clarification
Conceptualisation
Elaboration
Realisation
Support Evaluation Outline Ev
aluatio n Plan
(details in Ch
apter6)
*
*
Task clarification
Conceptualisation
Elaboration
Realisation
Support Evaluation Outline Ev
aluatio n Plan
(details in Ch
apter6)
*
*
Model and the associated Criteria are gathered. A full Impact Model might be available if the PS stage follows a DS-II stage.
- Using the Initial Impact Model as the preliminary focus, the literature on existing support with similar goals, i.e., with similar expected impact, is reviewed in order to identify the extent to which current support fulfils the goals, and where scope exists for developing support.
- With this information, alternative Key Factors, Measurable Success Criteria and relevant links are identified from the Initial Impact Model to create Impact Model alternatives for the Intended Support. These are compared and evaluated to create the Impact Model representing the desired effects of the Intended Support (Intended Impact Model).
- The Intended Impact Model, the project goals and the results from DS- I or DS-II are used to formulate a list of requirements for the support, covering the whole life cycle.
2. Conceptualisation (see Section 5.5):
- The functions and sub-functions of the Intended Support are identified.
- Concepts of how to fulfil these functions are proposed, evaluated, compared and selected.
- Based on the selected Intended Support concept, a concept plan for introducing the Support (Intended Introduction Plan) is developed.
- The Intended Impact Model is updated to take into account the consequences of the chosen concept and the Intended Introduction Plan.
3. Elaboration (see Section 5.6): This and the next step are carried out only in Review-based and Comprehensive PS:
- (in the case of tool development) Existing literature on technologies with which the Intended Support could be realised is reviewed.
- The Intended Support is fully described.
- The Intended Introduction Plan is elaborated.
- The Intended Impact Model is finalised.
4. Realisation (see Section 5.7):
- The core functionalities of the Intended Support are identified and an Outline Evaluation Plan is generated (see Chapter 6).
- (in the case of tool development) The literature on development platforms and technologies suitable for the realisation of the Actual Support are reviewed (note that these are not necessarily the same as for the Intended Support).
- The Actual Support is developed to such an extent as to enable the evaluation of the core functionalities with the available resources.
- An Actual Introduction Plan is developed.
- An Actual Impact Model is created to reflect the limitations and particular features of the Actual Support and the Actual Introduction Plan.
5. Support Evaluation (Section 5.8):
- The Actual Support is evaluated for completeness, internal consistency, etc, and modified if necessary.
- Based on the results of the Support Evaluation and the modifications to the Actual Support, the Outline Evaluation Plan is updated for use in DS-II (Chapter 6).