Prescriptive Study: Developing Design Support
5.5 Conceptualisation
5.5.3 Introduction Plan
suitable set of building blocks? What are methods for exhaustively combining these? What form should exploration take? How should the ideas be presented so that the user has an overview?
Figure 5.8 Impact Model with alternative support concepts for the synthesis example
The answers to these questions will have consequences for the support, resulting in additional functions. This enforces further refinement of the Impact Model. Take for example the above question about how the ideas should be presented. This was raised because the fulfilment of the function ‘provide wide range of ideas’ was considered necessary but not sufficient to encourage designers to consider a larger number of ideas. The range should be presented such that it allows an overview, thus introducing an additional function: ‘provide overview of ideas’. Both functions might have particular effects that are not yet represented in the Impact Model. Such effects thus lead to additional factors and links, namely those that are influenced by these functions. The first function, for example, affects a factor that can be called
‘quality of overview’; the second function affects the factor ‘range of ideas’. These factors, together, are responsible for influencing the ‘number of ideas considered’
in the original Intended Impact Model and should be added to the model (not illustrated here).
customisation, use and maintenance, and to document these together with any organisational, technical and infrastructural pre-requisites in what we call an Intended Introduction Plan. This involves exploring questions such as: How is the support supposed to be introduced, installed and used? Is customisation required and how is this done? Who is involved in each life-cycle phase and in what role?
Do the contexts in which the life-cycle stages take place put specific constraints on the support that must be accounted for, such as the type of users, the circumstances and other available support?
The visualisation of the various processes in the life-cycle of the support, e.g., in scenarios or flow charts, is a useful way to identify additional functions and features of the support, necessary to realise these processes. The following questions can be asked for each step in each process:
• Who is involved in this step and in which role? For instance, in the reliability example, who creates the component-interface diagrams (henceforth called CI diagrams) necessary for assessing clarity, simplicity and unity? What interfaces are commonly used by these users?
• How is the step executed (note that this may reveal additional steps that were originally not anticipated)? For instance, if the CI diagram is to be created manually from a CAD model or an engineering drawing, a procedure to verify the correctness of the CI diagram against the CAD model or drawing may be needed. If a support needs customisation, a separate interface may be required to support the various steps in the customisation process.
• How difficult is the execution of the step in the intended context, what is involved? For instance, a CI diagram for a large system might require an enormous effort to generate and might be difficult to use. Hierarchies of diagrams may be required.
• How error-prone is the step? For instance, manual creation of the CI diagram may be highly error-prone, potentially influencing the quality of the outcome as crucial components or interfaces may be left out by mistake, or translated incorrectly into the diagram.
One difficulty in support development is that the effectiveness and efficiency of a support depends on the characteristics of the users and the support, as well as of the nature of their interaction. The higher the degree of freedom for the user as to how the support can be used and the more the support allows different interpretations, the more difficult it will be to ensure that the support will be effective and efficient.
Therefore, it is important to identify possible alternative uses and interpretations of the support during the life-cycle phases, while answering the questions listed in the previous paragraph. These considerations can be used to:
• make explicit how the support should and should not be introduced, installed, customised, used and maintained;
• improve the support so that alternative uses and interpretations that are detrimental to the impact of the support are minimised;
• ensure that the evaluation of the support (in DS-II) can be planned and executed such that the observed impact is primarily due to the support and not to other circumstances.
The Intended Support and the Introduction Plan together should ensure that the life-cycle phases can take place as intended and reduce the chances that alternative uses and interpretations have a large negative impact on the effectiveness and efficiency of the support.
Note that the Intended Impact Model assumes that customisation, installation, introduction, use and maintenance are carried out as planned, since no factors are introduced to represent deviations from the envisaged plan. Such deviations can affect the impact of the support and thus result in a situation that differs from the desired situation represented by the Intended Impact Model. For this reason, the Introduction Plan is an important input for the evaluation of the support in DS-II.
The concept for the Intended Support, the Intended Introduction Plan and the Intended Impact Model are developed together. As for any other step, it is important to keep note of the rationale behind the decisions that were taken, such as the problems envisaged, proposals considered, the arguments behind the decision, etc.
Reliability Example
In the reliability example, the analysis of the life-cycle processes resulted, among others, in the following. The main users are experienced mechanical designers from the company involved, who would use the support individually. The most effective introduction of the support in the particular context is considered to be a workshop led by the researcher, and potentially by a representative from the company trained by the researcher. The workshop should include an explanation of the support and allow the participants to solve example cases. The alternative to develop a paper- or computer-based tutorial for self-learning was considered to require too much effort.
The available systems within the company require organisational and technical procedures for the introduction and installation of the support as well as specific functionalities within the support.
The analysis of the processes through scenarios and using the questions listed above provide:
• a more detailed picture of the processes involved and of the necessary features and functions of the support; e.g., the possible elements in the CI diagram based on the available information in the CAD models or drawings of early embodiments, and the possibility to reuse CI diagram elements and sub-systems;
• an evaluation of the weak points of the support: e.g., the manual creation of a CI diagram task is potentially error-prone and tedious, and every modification of the embodiment requires a modification of the CI diagram.
The accuracy of the CI diagram was therefore considered an important issue to be addressed.
The greater clarity of the functions, the concept and introduction of the Intended Support allows a further improvement of the Intended Impact Model. In our
example, the above and other results of the analysis are used to update the Intended Impact Model as shown in Figure 5.9.
Figure 5.9 Lower part of the Intended Impact Model for the reliability example after the Conceptualisation step in PS
User Issues
Particularly relevant in this stage of support development are user issues. In many dissertations, support concepts are described without any clear indication of who the users are: are they designers, administrators, information maintenance personnel, a combination of these, etc? It is often also not clear what is done by the user(s) and what is provided or done by the support, or who takes the initiative for a particular interaction. In this section we focus on how to determine the type and amount of interaction required. This is necessary to clarify the kind of support intended, which in turn is essential for developing the right concept. Further details about user-interface design can be found in Appendix B.3.
In the case of tool development different types of interaction are possible. The types of interaction in the interaction diagram in Figure 5.10 are based on who initiates the interaction process and who transfers data or information.
• The user initiates interaction as well as transfers data, i.e., the user provides data.
• The user initiates the interaction while the support provides the data in response, i.e., the user requests data of the support.
+
reliability of embodiment
level of unity
+ +
+ +
support early assessment
of C, S
knowledge of unity level support early assessment
of U (existing)
+ + + +
++
+ +
+
+
support creation of CI diagram
+
++
Key Factor
+ +
+ +
++
use of DfR methods
+
% of project time left
to improve
+ +
Upper part of IM (Fig. 4.9)
level of clarity
level of simplicity
quality of modification quality of
modification knowledge
of clarity level
knowledge of simplicity level
reliability of detail design
accuracy of CI-diagram
+ +
reliability of embodiment
level of unity
+ +
+ +
support early assessment
of C, S
knowledge of unity level support early assessment
of U (existing)
+ + + +
++
+ +
+
+
support creation of CI diagram
+
++
Key Factor
+ +
+ +
++
use of DfR methods
+
% of project time left
to improve
+ +
Upper part of IM (Fig. 4.9)
level of clarity
level of simplicity
quality of modification quality of
modification knowledge
of clarity level
knowledge of simplicity level
reliability of detail design
accuracy of CI-diagram
+
• The support is the initiator while the user transfers data in response; i.e., the user replies to a request.
• The support initiates interaction as well as transfers data; i.e., the user receives data from the support based on a decision taken by the tool that this interaction is necessary.
Figure 5.10 Interaction diagram from a user’s point of view
Various variants of this diagram exist, both from a user point of view as well as from a system point of view. The labelling of the types of interaction in Figure 5.10 is based on a user point of view, with an increasingly active role of the support.
Depending on the proportion of initiative taken by the support, the support can be:
• manual, where the user initiates interaction and also transfers data (comprising ‘provide’ interactions);
• passive, where the user is the initiator and the interaction is a combination of ‘provide’ and ‘request’ types of interactions;
• interactive, which would involve many types of interactions. Depending on the amount of initiative taken by the support, this can be more tool-initiated or more user-initiated;
• automated where interactions are mainly of the ‘receive’ type, with some
‘requests’ and ‘replies’ in particular at the beginning and end of the interaction.
These types of interaction should not be taken as rigid divisions. In any one support, several types of interaction can take place. However, it is important to indicate the dominant interaction characterising the type of Intended Support.
Synthesis Example
In Concept A of the synthesis example, the aim is to provide a range of ideas, but not to support their exploration. This reduces the complexity of interaction considerably compared to Concept B in which both range and exploration must be supported. Concept B requires a more intensive user interaction, and strategies for supporting this function have to be developed. It was decided to first develop concept A, as this alternative is simpler and is part of Concept B.
Receive Request
Support
Reply Provide
Human (user)
Support Human (user)
Who initiates interaction Who transfers data
Receive Request
Support
Reply Provide
Human (user)
Support Human (user)
Who initiates interaction Who transfers data