Opus: University of Bath Online Publication Store a Social Media Framework to Support Engineering Design Communication

This is an open-access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited. This version is made available in accordance with publisher policies. Please cite only the published version using the reference above. a b s t r a c t Engineering Design Communication (EDC) is fundamental to almost all Engineering Design activities as it provides the ability for knowledge and information to be shared between engineers. It is part of 'what we do'. This communication contains a great deal of rationale relating to the evolution of Product Development and is essential for understanding 'why the product is the way it is'. The need to support EDC is becoming more important due to the fact that Product Development is becoming more distributed, multidisciplinary and involving greater re-use of past designs. With the advent of Social Media (SM), it is argued that there is the technical capability to provide more effective support for EDC within a computer mediated environment. In order to explore this potential, this paper defines the requirements for the effective support of EDC through an extensive review of the literature. It then discusses the suitability of a SM approach and then presents the theoretical foundations of a SM framework to support EDC. Engineering Design has been described as an ever more multidisciplinary and highly collaborative exercise, during which substantial levels of resources and information are shared within a highly contextualised environment [1]. Törlind and Larsson [2] describe Engineering Design as ''fundamentally a socio-technical activity'' where communication is an intrinsic part [3,4]. Based on the above description, this paper considers Engineering Design to be the activities undertaken by a network of engineers (henceforth referred to as the Engineers' Network) to develop a product. As a result of these activities, a large volume of documentation and numerous representations (i.e. artefacts) that pertain to (and define) the product is generated (for example, design models, mathematical analysis, physical prototypes and notes). All of these artefacts are interrelated to one another and therefore defined within this paper as the Product Artefact Network (PAN). Engineering Design Communication (EDC) is defined as the communication between engineers that pertain to the product and its development. Fig. 1 illustrates how this communication is a mediator between the Engineers' and Product Artefact Networks. It is the challenge of …


Introduction
Engineering Design has been described as an ever more multidisciplinary and highly collaborative exercise, during which substantial levels of resources and information are shared within a highly contextualised environment [1]. Törlind and Larsson [2] describe Engineering Design as ''fundamentally a socio-technical activity'' where communication is an intrinsic part [3,4]. Based on the above description, this paper considers Engineering Design to be the activities undertaken by a network of engineers (henceforth referred to as the Engineers' Network) to develop a product. As a result of these activities, a large volume of documentation and numerous representations (i.e. artefacts) that pertain to (and define) the product is generated (for example, design models, mathematical analysis, physical prototypes and notes). All of these artefacts are interrelated to one another and therefore defined within this paper as the Product Artefact Network (PAN). Engineering Design Communication (EDC) is defined as the communication between engineers that pertain to the product and its development. Fig. 1 illustrates how this communication is a mediator between the Engineers' and Product Artefact Networks. It is the challenge of providing support for, and relating of EDC to both the Engineers' Network and PAN that is the focus of this paper.

The importance of EDC
Tenopir and King's [5, p. 30] review of communication patterns shows there is a consensus that engineers spend a significant proportion of time conversing with one another. Ellis and Haugan [6] and Wood and DeLoach [7] reveal that engineers make considerable use of communication channels to seek for information as colleagues are seen as easily accessible, trustworthy sources of information and are still preferred over search engine results [8,9]. A high proportion of communication is what is colloquially termed 'water-cooler conversations', as it is a quick informal exchange of knowledge and information between engineers [10][11][12]. Brown and Duguid [13] highlight that it is heavily relied upon to 'fill in the gaps' left by formal documentation and process manuals, as they can never fully account for every eventuality.
The relative level of EDC has also been shown to be indicative of progress being made and successful Product Development [14,15]. This is further supported by the engineering management literature showing that companies see communication as a critical success factor and that it has been shown to affect productivity and lead-time [16,17]. Dong [18] shows that almost all successful product design teams have high-levels of communication and the reasoning is that it supports the creation of a shared understanding between the engineers. Adler [19] and Daft and Lengel [20] describe how greater communication plays a key role in reducing uncertainty and what can be considered as 'needless' uncertainty as the information is available but the engineers are unable to access it, be it through not discussing it with the right engineers or not knowing of its existence. McKelvey and Page [21] also dis-In addition, these communications are often held between a small number of engineers and are rarely made visible to others. This prevents the opportunity for other knowledgeable engineers contributing to the communication [37]. It has also been the case that limits have been imposed in almost all implementations of E-Mail in engineering companies, such as restricting the size of an E-Mail and engineers' personal storage space. This can lead to issues in sharing product artefacts and the loss of potentially re-usable communications through deletion [32,38]. Thus, the development of a tool to support EDC would seem a suitable avenue for research in light of the current difficulties. However, there are a number of challenges in addition to what has been discussed.
Tenopir and King [5] and Maiden and Bright [39] discuss the need for such a tool to be able to provide a similar level of context to Face-to-Face communication and the ability for collaboration in order to solve problems, discuss issues and/or make decisions effectively. There is also a challenge in facilitating communications between the right knowledgeable engineers, and Leckie et al. [40] and Lowe et al. [41] show that there is a huge variety in how engineers seek and share information, which is often accompanied by artefacts from the Product Artefact Network (PAN) [42][43][44]. In addition, it has been shown that engineers seek information from a variety of perspectives (such as where it lies within the company, product and project). There is thus, a need to consider these dimensions when supporting EDC to enable effective search and retrieval [45]. Sim and Duffy [46] discuss how communication has a strong interplay between the engineers and the evolution of the artefacts within the PAN. Thus, it is argued that it would be key for any communication tool to consider how to incorporate these relationships. Finally, Al-Rawas and Easterbrook [47] sum up the current barriers as: The Ineffectiveness of the Current Communication Channels to support distributed EDC through lack of capturing the engineering context. The Restrictions on Expression within Communication Channels and particularly enabling engineers to collaborate in a more natural way. The Social and Organisational Barriers, which include ensuring there is awareness of the communication to enable the right knowledgeable engineers to contribute and ensure the right dimensions are captured alongside the communication to enable easy search and retrieval.

The potential benefit in improved support for Engineering Design Communication
Improving the support for Engineering Design Communication would not only look to overcome the challenges previously stated but to also provide potential benefits in understanding Product Development. Current research within the field (which includes aspects of Design Rationale and Knowledge Management) has primarily focused upon taking a descriptive approach into understanding how engineers communicate within industry. Often relying on surveys and/or interviews as a means of data capture [5]. There have also been studies that have focused upon particular communication tools within engineering, such as analysing the content of E-Mail or the use of video conferencing [48,2]. In contrast to the wealth of descriptive measures, there are few prescriptive measures to support EDC, be it through the development of a tool or process [5,49,50]. Clarkson and Eckert [49] suggest that the field is reaching a plateau of understanding and intervention research is required to further the field. Hence, the capture of communications through a tool that has been developed to support EDC has the potential to provide a rich dataset that can provide fur- ther insights into how engineers communicate, and how communications evolve and influence New Product Development.
Engineering Design Communication often contains the rationale behind decisions made and insights/conclusions drawn from the discussion and aggregation of information [51]. This can be used to describe 'why it is the way it is' [52]. Dearden [53] supports this by describing the idea of 'material utterances', which are changes within artefacts (i.e. modifications/changes to documentation) and that communication is often the cause. A number of studies have shown that engineers can use as much as 70-95% of past designs to develop new products and thus, being able to understand the reasoning 'why the product documentation is the way it is' can further aid re-use and reduce the likely occurrence of re-work [54][55][56]. It is therefore argued that capturing EDC with a view to its re-use will provide a knowledge base from which engineers can build upon.
The creation of such a knowledge base has been addressed in part by design rationale capture tools, which have primarily focused upon argumentative capture [57,58]. Implementation of these tools has often led to engineers having an increased workload as engineers post-rationalise the design process once the project/task has finished [59][60][61]. Carlile [43] discusses that knowledge gained by engineers is embedded in practice and therefore it is hard to recall and articulate, thus raising issues about the utility of current approaches for design rationale capture. An alternative is to support EDC directly thereby, capturing the rationale in real-time through the support of engineers' work.
It is this need to improve the support and build towards prescriptive research that is addressed in this paper. In order to create a supportive tool, it is first necessary to generate the requirements for such a system and to consider how it should be implemented within the context of current technology. This paper takes a bottom-up approach to developing the requirements by eliciting and synthesising them from the substantial literature concerning EDC. In addition, the paper looks at the suitability of Social Media to support EDC. Then, the paper continues by detailing its main contribution: A theoretical Social Media framework, which instantiates these requirements. It then concludes by discussing the potential implications of the approach for supporting EDC.
2. Developing the requirements for the effective support of Engineering Design Communication from the literature As previously discussed, there exists a wealth of descriptive research concerning communication within engineering. This paper draws upon some 100 research documents from key sources in the fields of Engineering Design, Professional Communication, Knowledge and Information Management, Computer-Supported Collaborative Work and Project Management. These are referenced throughout this section and the key findings in order to develop a set of requirements for the effective support of Engineering Design Communication (EDC) have been elicited and synthesised. The research has been grouped into four distinct areas and the focus is upon the role of EDC in relation to these areas. The requirements are introduced at the relevant points within the review and then summarised in Section 2.5. From herein, Engineering Design Communication (EDC) is to be referred to as communication.

Engineering Design Communication and the Product Artefact Network
''Here, sketching and drawing are the basic components of communication; words are built around them, but the drawings are so central that people assembled in the meeting wait while individuals fetch visual representations left in their offices or sketch facsimiles on white boards.'' Hendersen [62]. Almost all communications revolve around an artefact 2 [42][43][44]. Artefacts can be either digital/physical and include, sketches, calculations, Computer Aided Design (CAD) files, simulation set-ups/results, reports, prototypes and the products/parts (Table 1 provides In-service a more complete list although not intended to be exhaustive). These artefacts form what has been previously defined as the Product Artefact Network (PAN). These are the objects or documentation that have been created during the Product Development process to describe and represent the product and its process of manufacture. The effectiveness of the communication centres around the engineers ability to use these artefacts to help externalise the problem/ issue/query/statement they wish to make [63,64,27]. Having the artefacts associated with the communication also reduces equivocality during its evolution [19,20]. It can be considered that the use of artefacts has the ability to either explicitly or implicitly represent the 'focus' of the communication and/or provide the context necessary to describe it. This is especially apparent in multi-disciplinary environments [65]. Table 1 also summarises possible foci of the artefact with regards to the communication (and is discussed later). Luck [66] also highlights that artefacts are able to help achieve a 'common' understanding between the engineers due to their familiarity with them. Thus, it can be considered crucial to be able to include the artefact(s) alongside any communication. However, this may be difficult due to the need to support distributed communication through a computer-mediated tool. As the artefacts may be considerably large files or actual physical artefacts. In addition, Gopsill et al.'s [67] summary of product lifecycle information systems shows the complexity of the current information systems infrastructure 3 currently managing the Product Artefact Network and the corresponding wide variety and diversity of artefacts.
Although, a representation of the record (i.e. an image) can provide almost all of the benefits of the actual record ( [68]). In particular, the representation still contains the required context for an engineer to be able to interpret the statement being made. This would suit the ubiquity required for a distributed computer-mediated tool, although it has been noted that these representations of the artefact should be of a high quality to prevent confusion [69]. An additional affordance is that it enables the capture of the temporal state of the record. Thus, upon viewing the communication in the future, the engineers are able to interpret the communication in the same manner even though the actual record may have evolved since.
Hendersen [62] reveals that in most cases, one artefact is at the centre of the communication and having more than one at the beginning of the communication often leads to greater confusion. Although, as engineers contribute to communications, they often use additional artefacts to either support their position, present potential changes that could be made to the artefact, or show the effect of changes they have made. Zurita et al. [70] reveal that the ability to represent changes on the artefact aids collaborative design as engineers are better able to understand the meaning behind the words being used by others. From this discussion, three requirements are synthesised; (1) to capture a high quality representation of the originating artefact relating to the communication, (2) to record changes to the artefact as a consequence of the communication and (3) to enable contributing engineers to embed a representation of an artefact in their responses within a communication episode.
Referring back to Table 1, it can be seen that there is potentially an inexhaustible list of artefacts and corresponding 'focal points' within engineering. Huet et al. [71], McAlpine et al. [72] and Hicks et al. [44] highlight that the capture of the artefact only represents a weak link to the PAN and there needs to be sufficient bounding through additional textual context to enable the communication to be effective in use and potential re-use. Explicitly capturing the artefact type in the form of text prevents ambiguity in the mind of an engineer participating within a communication [42]. This leads to a fourth requirement (4) to provide a text based description of the artefact, as demonstrated in Table 1.
The 'focal point' of the artefact is defined as the subject of interest pertaining to the artefact and examples include an engineer focusing upon constraints, form, function, assembly and materials [3,73]. As shown in Table 1, 'focal points' can vary between artefacts and although a list has been developed, it is likely to continually evolve. This is due to ever-changing areas of interest for the engineers as progress is made during Product Development [74]. Lee [75] discusses how artefacts are defined by their use and this status can change over time and thus, it is argued that this 'focal point' is crucial in aiding engineers to interpret the artefact effectively within the context of a communication. This leads to a fifth requirement (5) to record/capture the foci of a communication with respect to the artefact.
Although a representation of the artefact can perform in almost the same manner as the actual artefact within the communication, there is still benefit in being able to refer to the actual artefact, (particularly if electronic) by capturing its location (for example, a URL of the file). This could enable engineers participating in the communication to be able to effect changes to the artefact as the communication evolves. In addition, it provides the means to integrate communication records with the companies information systems infrastructure. There is also potential in terms of re-use, as it will enable the association of design rationale to the record to which it pertains. Therefore, it may further aid understanding into the evolution of the PAN during Product Development [76]. This gives rise to a sixth requirement (6) to provide an electronic or physical reference to the artefact.

Engineering Design Communication and the Engineers' Network
As previously discussed, engineers prefer to seek information through informal communication channels and it can be seen that communication is intrinsically linked to the Engineers' Network as the engineers are the creators and contributors to communications [6,7]. Höllta [77], Clarkson and Eckert [49] and Maier et al. [16,78] highlight that a major contributing factor to poor communication is the lack of 'awareness', where engineers are unable to contribute due to not knowing of the existence of a communication or due to restrictions within company practices (i.e. confidentiality and/or project team segregation). The consequence of this is that the most appropriate engineers may not be contributing to the relevant communications. Thus, it is considered crucial to support the relationships that communication has with the Engineers' Network.
Milne and Leifer [79] and Zipperer [8] show that engineers make considerable use of their own social knowledge to ensure communications are sent to (and received by) the right engineers. In addition, using fellow engineers to provide the engineer with the right contacts is often the 'quickest' (in terms of time, ease to do so and least effort) route to satisfy their communication needs even when compared to modern day search tools [9]. Tenopir and King [5] are advocates of the concept of engineer 'stars' and 'gatekeepers'. These are engineers that receive the majority of the communications, who then forward them to those that are best placed to respond. Thus, there is an argument for the requirement to provide functionality that enables engineers to push communications to one another and therefore take advantage of the engineers' social knowledge. This leads to the seventh requirement (7) to enable engineers to 'push' communications to one another.
Adler [19] describes how some engineering companies are now forming task groups for specific purposes, which then disband once the task is complete, in order to better manage their human resources. This is alongside core competency groups that are teams focused upon a particular expertise and contain deep domain knowledge. Thus, there is a need to support communications associated with group work and to ensure that all within the group are aware of potentially relevant communications. Likewise, there should also be functionality to ensure engineers are able to indicate relevant core competency groups who possess the deep domain knowledge so that they are made aware and able to respond to the communication. Additionally, McAlpine et al. [72] discuss the importance of engineering logbooks and the need for personal bookmarking, as it enables quick referral to important/ key resources to support work and activities. These findings lead to three further requirements: (8) to enable engineers to group communications by tasks, (9) to solicit responses from core competency (expert) groups and (10) to enable engineers to assign personal bookmarks to communications.

Engineering Design Communication -its purpose and evolution
This section considers the creation, response and output of communications, alongside the reasoning behind why it is necessary to support this within a computer-mediated environment. As mentioned previously, the plateau of understanding of Engineering Design Communication contains knowledge concerning why engineers wish to communicate but limited understanding of how engineers respond, conclude and possibly refer back to communications. In light of this, logical propositions are made where gaps exist to the support of the evolution of the communication within a computer-mediated environment.

Purpose of communication
Although current communication channels have the potential to permit more than one purpose to be expressed within a single communication, Wasiak et al. [48], Maiden and Bright [39], Auri-sicchio et al. [80] and Gopsill et al. [29] suggest that communications almost always have one main purpose. Examples include, idea generation, highlighting an issue, asking clarification, requesting information and making a comparison. Table 2 presents ten purposes of communication identified within the literature. The ability of engineers to align their communications to one of the purposes defined within the aggregated set has been tested within a Small to Medium sized Enterprise, where it has been shown that these purposes were sufficient in representing all their communications needs [29].
Understanding the purpose and inherent context of the communication (i.e. type of communication and artefact, and its context as previously described) is expected by all engineers contributing to the communication without the need to explicitly describe it during the exchange of statements [62]. Ensuring that this context is available to the engineers is crucial for generating a 'common' understanding within a communication episode. Not achieving a 'common' understanding often leads to communication breakdown where the goal set-out is not achieved. It can also be a source of frustration for engineers and leads them to cease contributing. The likelihood of this occurring increases within a computer-mediated environment. Therefore, it can be seen that there is a need to explicitly capture the purpose of the communication in order to reduce the likelihood of communication breakdown by ensuring that engineers know what to expect from the communication [83,40]. Capturing the purpose of communication also has benefits in enabling engineers to identify the communications that they are able to contribute to as well as providing a method by which the communications can be aggregated, potentially leading to the identification of patterns in the purposes through the Product Development process. This leads to the eleventh requirement for the engineer (11) to define the purpose of the communication (e.g. Table 2). The engineer wants to solve a process problems [45]

Issue
The engineer wants to solve a product problem [48,45]

Observation
The engineer wants to highlight an artefact of potential interest [48,45]

Confirmation
The engineer wants to ensure the artefact is correct [80,79]

Comparison
The engineer wants to converge upon a solution [80,81,54]

Option Generation
The engineer wants to generate a number of solutions to a problem [80,54]

Information Request
The engineer wants to locate/receive information with regards to a particular subject [81,48,80,79,45]

Decision
The engineer wants to propose a decision that they have made and want other engineers' input [82,54]  The engineer wants to acknowledge a statement that has been made (+) 8. Location The engineer wants to provide the location of some potentially useful information [54]

Agree
The engineer wants to express a positive stance on an existing statement within the communication (+) 10. Disagree The engineer wants to express a negative stance on an existing statement within the communication (-) 11. Warning The engineer wants to highlight area/s to be wary of 12. Valid The engineer wants to highlight a valid statement without positioning themselves (+) 13. Not-valid The engineer wants to highlight and provide a reason for a invalid statement and again, not to position themselves (-)

Types of response
Engineers make considerable use of mannerisms and expressions to infer their thought process and provide the perspective of 'where they are coming from' when they respond during a communication episode [46]. This is one reason why Face-to-Face is often still preferred [84]. Again, this would have to be elicited within a computer-mediated environment and may be of even greater importance when one considers that the engineers contributing to the communication may not know each other socially [85,86]. Table 3 shows a list of response types that have been synthesised from the literature. However, the extant research has often employed surveys/interviews and therefore led to a primary focus on analysing the purpose of the communication. Research on how a communication evolves and the types of responses used is therefore limited, thus the aggregation of current understanding has been made alongside proposed positive/negative response types. This synthesis has revealed thirteen types of response.
Dong [18] highlights that the best communications are where engineers achieve a common understanding and are able to express themselves coherently. Therefore, it is argued that enabling engineers to indicate their response type will increase the coherence of the communication. In addition, this may enable further understanding into how communications evolve within Product Development and may lead to the identification of patterns associated with 'good' communications and communication breakdown. This leads to the twelfth requirement for the engineer (12) to define the type of response for each contribution to the communication (e.g. Table 3).
Stempfle and Badke-Schaub [94] also highlight that it is important for engineers to provide clear intent when they contribute to communications yet it would be 'foolish' for a system/process to attempt to structure the communications. However, there is a case for ensuring communications 'stay on the right track', hinting that semi-structuring communications may help. Perry and Sanderson [3] concluded that there should be response size limitations to reduce the chances of 'waffle' and maintain conciseness. Referring back to the purposes of communication and response types, it is argued that certain response types align themselves better to different purposes of communication and therefore in an attempt to ensure engineers maintain focus upon the communication, this paper presents a matrix of which types of response can be associated with each purpose of communication (Table 4). These considerations give rise to two further requirements; (13) to align the response types to the appropriate purposes as demonstrated in (Table 4) to ensure an appropriate limit is imposed on the size of a response.
The final aspect of the responses of communication is due to the increasingly collaborative and multi-disciplinary environment [54,87]. It is often the case that engineers from different disciplines will look at a problem from different perspectives and may develop different solutions. During Face-to-Face communications, this divergence and convergence of ideas/perspectives to achieving the purpose of the communication can occur. However, this is very difficult with tools such as E-Mail. Sim and Duffy [46] and Cross et al. [95] show that there are a considerable number of activities where divergence and convergence is essential and thus, it can be seen that it is important to enable engineers to have multiple threads within a single communication and provide the ability to direct responses to the right places within the communication. This is particularly important given the often asynchronous nature of computer-mediated communication as this direction and flow of communication could be lost. This leads to the following requirements: (15) to enable multiple-threads within a single communication episode (divergence) and (16) to enable engineers to respond to one or more threads within a communication using a single response (convergence).

Closing a communication and re-use
For the purpose of supporting communication through both use and re-use, it is self-evident that there is a need to determine the result of a communication. Given that the communication process is created by an engineer or group of engineers, it is proposed that they should also determine the result of the communication. The end of Face-to-Face communication is often clear in the minds of the contributors but cannot ever be viewed by future engineers. Table 4 Purpose and response types association matrix.  For example, although engineers have been seen to archive useful E-Mails for later, constraints on the storage capacity often placed by companies limits the potential for re-use. Therefore, it is argued that the current application of communication tools has almost solely focused on supporting the use state and thus, provide limited capacity to support re-use. A logical proposal is to assume that there is either a positive or negative outcome (similar to pros/cons used by [60]), and in a computer-mediated environment, the communication may not even receive a reply. Therefore, this paper proposes the following conclusion types for the purposes of communications (Table 5). Each purpose has its own individual conclusion types. Capturing the positive/negative conclusion can provide a useful insight into whether there is a pattern in the evolution of the communication and the resultant conclusion type. In addition, it may provide a useful index measure for the search and retrieval of communications for future engineers. This leads to a seventeenth requirement (17) to formally conclude a communication (e.g. Table 5).
Now that the communications are to be stored, there is a need to consider how the communications can be re-used. Štorga et al. [96] discuss the importance of traceability throughout an engineering system and how it enables engineers to understand 'what has happened'. Königs et al. [97] concludes that communication is a key link that can achieve traceability and be used to determine artefact dependencies. It has been previously stated (1.3) that engineers often refer back to past designs, experience and events to provide reasoning for their statements and thus, it is argued that engineers need to be able to link communications together through the statements they make, thereby using past communications as supporting evidence. In addition, this would provide traceability of information and would be highly useful in understanding how previous communications affect future outcomes. This leads to an eighteenth requirement (18) to enable engineers to reference responses in past communications in current communications.
As well as referral during new communications, the viewing of past communications can occur and engineers may find value in re-using these communications. To further understand the value of the stored communications, it is proposed that there should be functionality to enable engineers to comment on past communications. This can be thought of as hindsight as it provides information on how the communication was re-used. Table 6 highlights potential reasoning for commenting on a past communication. This leads to an additional requirement (19) to enable engineers to comment on past communications (e.g. Table 6).

Engineering Design Communication and the engineering context
Hicks et al. [98] and Grebici et al. [99] both highlight that the capture of contextual information is critical to enabling use and re-use of information within engineering. Wasiak et al. [48] and Sonnenwald [50] mention three common dimensions that align the communication to either the Company, Product, Product Lifecycle, or a combination thereof. Including these dimensions during the creation of a communication will aid the search and retrieval of communications by engineers [40,41,100]. Ahmed and Wallace [45] show that the inclusion of more dimensions enables novice engineers to search and retrieve information more easily. Finally, Wang et al. [101] shows that additional contextual dimensions reduces the uncertainty and 'fuzziness' of the communication, as the alignment to the Engineering Design environment has been explicitly made. Therefore, this leads to the final requirement (20) to classify communications by the Company, Product and phase of the Product Lifecycle.

The requirements to support Engineering Design Communication
This section summarises the requirements generated from the review of the literature (Table 7). A total of twenty requirements have been elicited from the research relating to EDC, which has revealed the relationships between EDCs and the Product Artefact Network, Engineers' Network, within its own evolution and the Engineering Context. Table 6 Types of commenting on an Engineering Design Communications.

Comment type Description
Re-Used The communication has been re-used in a future unforeseen purpose and the engineer describes how it has been re-used Redundant The communication is no longer of use to the company and the engineer explains why it now no longer of use To capture a high quality representation of the originating artefact relating to the communication 2 To record changes to the artefact as a consequence of the communication 3 To enable contributing engineers to embed a representation of an artefact in their responses 4 To provide a text based description of the artefact (Table 1)  5 To record/capture the foci of a communication with respect to the artefact (Table 1)  6 To provide an electronic or physical reference to the artefact 7 To enable engineers to 'push' communications to one another 8 To enable engineers to group communications by task 9 To enable engineers to solicit responses from core competency (expert) groups 10 To enable engineers to assign personal bookmarks to communications 11 To define the purpose of the communication (e.g. Table 2) 12 To define the type of response for each contribution to the communication (e.g. Table 3) 13 To align the response types to the appropriate purposes ( Fig. 4) 14 To ensure an appropriate limit is imposed on the size of a response 15 To enable multiple-threads within a single communication episode 16 To enable engineers to respond to one or more threads within a communication using a single response 17 To formally conclude a communication (e.g. Table 5) 18 To enable engineers to reference responses in past communications within current communications 19 To enable engineers to comment on past communications (e.g. Table 6) 20 To classify communications by the Company, Product and phase of the Product Lifecycle

The suitability and requirements for the effective application of Social Media to support Engineering Design Communication
Social Media (SM) has developed significantly over the past decade and the tools are becoming increasingly central to the digital lives of consumers, and to a lesser extent, businesses [102]. They are often web/mobile-based technologies that have been designed to support communication within a computer-mediated environment with specific focus on connecting and generating networks between individuals/groups of individuals [103]. Currently, it is evident that the research within the field of SM is very much focused upon the analysis and mining of the datasets created by such tools (see for example [102,[104][105][106]) and less on the understanding of the functionality and how it should be applied most effectively. It is argued that this may be due to the pace at which the feature sets of SM tools is changing and the difficulty one would have in assessing particular implementations.
Although there is still much research to do within the SM field, this section discusses the suitability of SM to support EDC through reference to existing literature, logical argument and reference to the previously generated requirements to support EDC. From this, the generation of a set of requirements to ensure that SM is applied effectively is elicited. References to these requirements will be in the form of R EDC : X.

Suitability of Social Media to support EDC
With reference to Fig. 2, it can be seen that the previously described Engineers' and Product Artefact Networks, and the Engineering Design Communication to which it pertains, is analogous to a system that is described as a Social Network, whereby users are uploading content and have a discussion regarding it. For example, FaceBook allows users to upload photographs and enables them to comment. Thus, it is suggested that there may be potential in applying such technology within the Engineering Design context.
Törlind and Larsson [2] express the need for any tool that supports EDC to be lightweight and SM has been described as such [107][108][109]. Further, SM tools generally support synchronous and asynchronous communication, which has benefits in enabling communications to continue independent of users' schedules, time differences and location [12]. In addition, there can be considered to be a need to support such technologies within Engineering Design, as new generations of engineers are increasingly using SM tools as their main means of social communication. For example, software developers are preferring to use SM tools to support their communication [110]. Alavi and Leidner's [111] review of communication tools to support knowledge sharing (thereby EDC) considers electronic bulletin boards and discussion forums as the most suitable technologies. It is argued that these can be considered precursor technologies to SM as they maintain a hierarchical storage structure for communications to be stored whilst SM tools tend not to. As SM does not provide this structure for its content, it can be associated with multiple-facets without issue. This aligns well with EDC as it requires association with a high-level of context as outlined in the requirements (R EDC : 4, 5, 6,7,8,9,10,11,12,17,18,19,20).
Social Media tools generally employ user and collaborative tagging functionality to increase the level of context surrounding an information object or communication within the system in addition to storing core meta-data such as author, date of creation and location due to their actor-centric nature [112,113]. For example, the popular FaceBook uses tags within photographs to identify people and link the photograph to that user. Bar-Ilan et al. [114] highlight that a SM system requires both required (structuring) tags to ensure all information is retrievable and optional (unstructured) tags to ensure that almost every potential link can be formed between the stored information items. This leads to the first three requirements; (1) to ensure core meta-data such as author, creation and location are captured, (2) to use structured tagging on meta-data that is a requirement for an information object within the system and (3) to use unstructured tagging where potential meta-data could be applied (but it is not a requirement for the item of information to exist within the system).
These tags can be considered as an evolving dictionary of terms that can be used within their domain. This provides extensibility within the system and (as long as the definition of the tag remains applicable to the information objects being stored,) provides a system context that all the users can interpret and apply in a similar manner, thereby ensuring that the user can always search and retrieve effectively [115]. Thus, in the case of EDC, engineers may create new purposes of communications, responses and conclusion types, as it is conceded that the EDC types elicited from the previous review can never be complete due to the evolving nature of communication. It is therefore argued that tagging may present the functionality required to support EDC as there are contextual requirements consistent for all communications (R EDC : 4, 11, 12, 17 and 19) and some which may/may not be applicable to the communication (R EDC : 6 and 20).
SM tools also make considerable use of free-form textual inputs that enable the user to have freedom of expression within their statements and provide rich data for search engines to be able to generate useful indexing parameters. Character limitation, which has been employed by some SM tools (for example, Twitter) can be likened to a 'psychological nudge' to ensure users provide the key information [116]. Hatem et al. [117] shows that the communications through such tools maintain their focus on the initial purpose of the communication and the common 'off topic conversations' that can occur during Face-to-Face communication become separate communications in themselves and thus, do not detract the communication from its original intention. In addition, free-form text is a ubiquitous method of data input, which enables a great variety of equipment (i.e. PCs, laptops and smartphones) to be used by users thereby, further enabling users to contribute. Therefore, there is a requirement (4) to apply character limitation in situations where focus upon the purpose of the communication needs to be maintained. It is argued that using a character limited textual input for the engineer/s statements within a communication would be beneficial as it has been mentioned previously that engineers wish to be able to express their views in their own way (1.3) and a character limit could potentially reduce the likelihood of 'waffle' within the communication (R EDC : 14).
In addition, SM tools frequently provide the ability for contributors to attach 'richer media' to the statements they make (i.e. photographs, files, videos). This aligns well with the requirements of engineers needing to provide a high-quality representation of the artefact that the communication pertains to. The technology readiness of these tools suggests that imagery remains the most suitable form of media to share within such an environment due to the ubiquity of being able to capture and view such files. In addition, the current bandwidth available within computer networks (Local Area Networks, World Wide Web, for example) enables the sharing of files to be quick and therefore enabling the tool to remain lightweight and suitable for mobile working. As there is a requirement for the capture of high-quality representations of artefacts pertaining to the communication throughout the process, it can be seen that the use of high-quality imagery would be suitable (R EDC : 1).
Hiltz and Turoff [118] discuss that a key capability of these technologies is the users' ability (in most cases) to view all the communications within the system and to then employ methods that enable users to filter the information based on the context that is most relevant to them. Being able to filter based upon what the users may consider 'interesting' to them could be highly beneficial as it has been shown to positively affect the evolution of the communication and conclusions that were drawn [119]. Therefore, it is argued that it is an requirement (5) to enable full-accessibility and user filtering based on 'interest'. Table 8 summarises to the requirements elicited from the research concerned with the effective application of Social Media. Five key requirements have been elicited from the review of the literature alongside providing the argument for SMs suitability in supporting EDC.

A Social Media framework to support EDC
Using the requirements developed in Sections 2 and 3, this paper now proposes a Social Media (SM) framework that could be used to develop a SM tool to support Engineering Design Communication. The framework consists of: (Fig. 3), which demonstrates how the communication is created and evolves within a SM tool. 2. An EDC classification matrix (Tables 9 and 10). This presents how the communication between the engineers within a SM tool should be semi-structured by the purpose of the communication, the types of response that should be permitted and the potential type of conclusion per purpose. (Tables 11-15) listing the functionality and data and information requirements for each part of the Communication Process.

A set of tables
The framework can be said to be communication-centric. This is due to communications containing both strong links between the Engineers' and Product Artefact Networks within a company. Thus, it is not deemed suitable to attempt to align the communication to one particular existing network. Referring back to 2.3, it has been made clear that Engineering Design Communications are defined by a clear purpose with engineers contributing in response to that purpose. This further suggests the idea that the communications have their own intrinsic centricity.
Each stage of the communication process (Fig. 3) is described in detail and the requirements in terms of functionality and the data and information to be captured. As is common practice within SM tools, standardised metadata will be captured alongside any information input made from the users. This information is the author, creation date and location of the event and it is often captured through an automated process (R SM : 1). Thus, throughout the communication process, this information is to be captured at any point where the engineers are putting information into the SM tool. References to the requirements generated from both the support for EDC and application of SM technology (Tables 7 and 8) are made throughout. 4

Create
The CREATE stage of the SM communication process handles the creation of the communications within the SM tool (termed Table 8 Summary of the requirements elicited from SM literature.

Requirement no.
Requirement to: 1 Ensure core metadata such as author, creation and location are captured 2 Use structured tagging on metadata that is a requirement for an information object within the system 3 Use unstructured tagging where potential metadata could be applied but it is not a requirement for the item of information to exist within the system 4 Apply character limitation in situations where focus upon the communication needs to be maintained 5 Enable full-accessibility and user filtering based on 'interest' Fig. 3. The communication process of the SM framework to support EDC. 4 References to the EDC requirements will be in the form of R EDC : X and application of SM tools as R SM : X. Affirmative: wants to acknowledge a statement that has been made I hear you, I will process this through the XX database Sure thing, I will get in contact with him Alright, gotcha. I will get onto it Alright I will read that Ok I will look into the past design stores Location: want to provide the location of some potentially useful information I hear you, I will process this through the XX database Sure thing, I will get in contact with him Alright, gotcha. I will get onto it Alright I will read that Ok I will look into the past design stores Agree: wants to express a positive stance on an engineers viewpoint n/a n/a n/a n/a n/a Disagree: wants to express a negative stance on an engineers' viewpoint n/a n/a n/a n/a n/a Warning: wants to highlight areas to be wary of n/a Make sure you're using the most recent process manual. There have been some changes to the CAD files we now use 'communication objects'). Table 11 presents the features that must be employed by a SM tool wishing to support EDC. The engineer(s) creating the communication object are required to upload one high-quality image of the artefact pertaining to the communication alongside their statement, which is to be captured through a character limited free-form input. There are also contextual requirements to be considered and the engineers are required to tag the communication with the purpose of the communication, artefact type and artefact focus, as well as providing optional tags to capture the links to the actual artefact, align to Company, Product and phase of the Product Lifecycle dimensions, which are to be applied where applicable at the engineers discretion. Finally, there is the provision for additional information that should be associated with the communication.
Upon completing the CREATE stage, the communication object becomes instantiated within the SM tool and engineers are able to contribute to the object. The communication object now moves to the RESPOND stage.

Respond
The RESPOND stage handles what can be considered the 'live communication' element of the process, whereby the engineers are able to contribute and discuss the communication object. Table 12 presents the features that are to be employed by the SM tool during this stage.
Engineers contributing to the communication object are required to make their statement through a character limited textual input alongside the need for them to tag the statement with the response type determined by themselves from the EDC classification matrix (Tables 9 and 10). Only the response types indicated for that purpose should be present within the communication object. However, it has previously been mentioned that this is not an exhaustive list and that engineers should have the option to add additional terms if required. The engineers are also required to highlight the previous statement/s that they are referring to and the RESPOND stages should handle the multi-threaded aspect of the communication object. Providing this reference will enable engineers to be able to trace the evolution of the communication within the object. The engineers should be provided with the ability to provide a representation of a supporting artefact and as before, this is to be performed through the capture of a highquality image. They should also be provided with the ability to link the artefact to its 'real-life' counterpart through either a Universal Resource Locator (URL of an electronic file) or stating the physical location. This stage continues until the originating engineer/s deem that they are able to conclude the communication.

Conclude
The CONCLUDE stage of the process arises when the originating engineers deem that they have reached a suitable conclusion to the original statement made at the CREATE stage. Table 13 presents the SM features during the CONCLUDE stage.
The originating engineer(s) concluding the communication are required to define the type of conclusion that has been reached and make their concluding statement through a character limited free form textual input. There should be the option for the engineer(s) to capture a final artefact, again, through a high-quality image and to link it to the 'real-world' artefact where possible. This can be considered as an opportunity to highlight the impact the communication has had on the artefact. Again, this has to be linked to either one or more statements, created during the CREATE/RE-SPOND stages, within the communication object.
The communication is no longer in the 'live communication' phase and is now stored for re-use. I saw this bike which has single spoke wheel and the frame bends out so that it enables them to fit the gearing within the centre of the bike wheel.
Valid: wants to highlight a valid point that has been made without positioning themselves n/a n/a n/a n/a n/a Not-Valid: wants to highlight and give reason for an invalid point made by a colleague and to not position themselves n/a n/a n/a n/a n/a  Guidance: wants to express something that the engineer should consider n/a n/a n/a n/a n/a Action: wants to inform the engineer on what he/she has to do n/a n/a n/a n/a n/a Idea: wants to introduce something potentially new to the conversation n/a n/a n/a Maybe we could try layering materials like they did in the samurai sword to provide some suspension within the arm n/a Affirmative: wants to acknowledge a statement that has been made n/a n/a n/a n/a n/a Location: want to provide the location of some potentially useful information n/a n/a n/a This is the suppliers site and our log in is this XX so we can generate an initial quote n/a Agree: wants to express a positive stance on an engineers viewpoint I have looked at the results and they look good n/a n/a n/a Yes I agree with the proposed decision Disagree: wants to express a negative stance on an engineers' viewpoint I think you may have forgotten to change the stiffness of the front fork n/a n/a n/a I do not agree because it will be far too heavy compared to its competitors Warning: wants to highlight areas to be wary of n/a n/a n/a n/a n/a

Hindsight
The HINDSIGHT stage of the SM communication process to support EDC handles the direct re-use of the communication objects that are now stored within the tool. Table 14 presents the SM features to support the HINDSIGHT stage.
Engineers are able to search and retrieve past communication objects and they are able to refer back to past communication objects and highlight how they have been re-used. They are required to specify the type of referral they are making to the communication object by adding their statement within a character limited free-form textual input and provide one or more links to existing responses within the communication object.
The communication object now lies within the state continually within the SM tool. Fig. 4 demonstrates a potential communication object created by the process.   This tag provides the opportunity to provide the location of the artefact pertaining to the purpose of the communication

Awareness
AWARENESS features should be present throughout the whole SM communication process and are summarised in Table 15. They are features that assist in ensuring that the right engineers are made aware of relevant communications to which they are most able to contribute.
Engineers should be able to refer communication objects to other engineers. This allows the tool to take advantage of the engi-neers social knowledge to ensure the communication objects are made visible to the right engineers. To ensure traceability of communication objects and their consequences, there should be an option to refer back to past communications. This enables engineers to support their statements within current communication objects and to also highlight communication objects resulting from previous communications. In addition, there should be the capability to refer to task and expert groups to ensure that the right set of engineers are made aware of the communication objects and to make  reference to personal bookmarks to enable engineers to have quick reference to key communication objects. Finally, there is a requirement for the tool to provide the functionality for the engineers to be able to search, filter and retrieve based upon the contextual meta-data that has been captured throughout the communication process. This is to ensure that engineers are able to be made aware of communications of potential 'interest' to them.

Discussion and reflection
This paper now discusses the potential of the theoretical Social Media (SM) framework in terms of how it can support Engineering Design Communication (EDC) and its re-use. Also, reflection upon the potential limitations and the next steps to be taken with this research are outlined.
Instantiating the SM framework within a tool to support EDC will also support engineers' work, due to the fundamental and intrinsic nature of this communication within Engineering Design activities. It is argued that such a tool would fill the gap within the current communication tools to enable effective support of EDC within a distributed computer-mediated environment. Therefore, providing the opportunity for communications, which might have previously remained local (Face-to-Face) to be captured and to gain visibility across a distributed company infrastructure. The communication process, EDC classification matrix and the features within each stage are there to ensure that the contextual requirements and suitable structuring of communications is met. Although it may increase the communication workload of an engineer, (as they would be better supported to perform EDC in a computer-mediated environment and thus potentially more may occur) it is argued that it would reduce the communication workload currently seen within E-Mail, whereby, a number of E-Mails are sent to seek out the right engineers with which to communicate [35].
A tool featuring the instantiated SM framework would provide re-use capability of the communications being captured. As mentioned before, these captured communications contain the rationale behind 'why the artefact is the way it is' and therefore could be useful to engineers performing a variant design for a future product. These communications can also be used to support engineers' future communications through the ability to transfer rationale and provides traceability of rationale throughout the Product Development process. The greater understanding of the previous design process may enable engineers to identify key areas to focus on during re-design/variant design development and to prevent potentially unnecessary re-work.
Taking a higher-level perspective and looking towards the aggregation of the communication objects within the tool, it has previously been stated that a communication-centric approach has been taken and this will inevitably lead to the development of a Communication Network within the tool. It will also be the case that this network will contain strong links to the Engineers and Product Artefact Network. Thus, this develops an Engineers-Communication-Product Artefact Network and can be likened to what computer science have called an Artefact-Actor Network, whereby it is possible to understand how one network drives the evolution of the other network [120]. In this case, the communication contains the rationale behind how the engineers have driven change within the artefacts of the Product-Artefact Network and has the potential to provide an unprecedented level of granularity in understanding Product Development within an engineering company. Achieving such a network is currently at the forefront of network development research within computer science. Finally, the level of support provided within each communication and the capture of its evolution has the potential to provide a dataset that can further research within the EDC field.
However, it is noted that this paper currently presents a theoretical SM framework to support EDC and thus, appropriate validation of the framework is required in future research. It is argued that the potential and key validation of the SM framework would need to occur through the instantiation of the framework within a SM tool and for it to be implemented within an engineering context. Due to the complexity of implementing such a tool within an engineering company, a number of metrics would be required to ascertain its potential. Usage patterns, engineers contributions to the tool, user feedback, analysis of the network generated, degree of referral to past communications, degree of knowledge sharing between teams and Product Development time would be some of the possible indicators to whether the SM tool is providing a benefit to the company.
Although a tool implemented within a company would be the ideal case, some controlled studies could be used as indicators as to whether the framework has potential to support EDC. Such a study could involve having two distributed teams developing a product with one using a SM tool using the framework and the other using any other means they wish to communicate through. This would provide an insight into how it affects Product Development and collaboration within the team. In addition, a study of variant design with two distributed teams in the same manner as the previous experiment, but with the addition of the past projects data and information, including communication would provide indications of whether the SM framework enables greater re-use of past engineering communications, data and information. This is on-going research for the authors and is summarised into three main areas; (1) validating the SM framework through the application of an SM tool instantiating the framework, (2) assessing the usability of an SM tool instantiating the framework and (3) analysing the affordances that are arise from capturing and recording EDC [121,122].

Conclusion
This paper has discussed the importance of Engineering Design Communication (EDC), with engineers generally perceiving Faceto-Face communications to be the most effective due to the multi-disciplinary, highly-collaborative and high-contextual nature of Engineering Design. However, the issue is raised that as engineering companies' working practices have become more distributed and mobile, computer-mediated communication is often the only viable means of communication. E-Mail is currently the most common means. It has been discussed that E-Mail and other computermediated communication tools do not possess the capability to effectively support EDC. In addition, while there has been much descriptive research in the field of EDC, little prescriptive research has been undertaken. As a result, it is believed that the field has reached a plateau of understanding. Although little prescriptive research has been performed, there is a consensus that there is great potential in effectively supporting EDC in terms of both use and reuse.
It is contended that prior to the development of any prescriptive tool or process to support EDC, there is first a need to understand the requirements for the effective support of EDC. To address this, twenty requirements to support EDC have been elicited and synthesised from the extant literature and it is argued that these should be met by any tool/process that is seeking to support EDC. The key findings are the need to be able to provide a representation of the artefact that the communication pertains to, capture the appropriate engineering context, enable expressive multithreaded discussion, and to ensure the relevant engineers are aware of the right communications. In addition, a discussion of the suitability of Social Media (SM) to support EDC has been undertaken, together with the elicitation of five requirements to ensure the appropriate application of common SM functionality is met.
From this, the paper presents a theoretical SM framework to support EDC and argues that SM provides the features necessary to meet the identified requirements. The SM framework has three components, (1) a communication process, (2) an EDC classification and (3) stage-by-stage descriptions of the functionality, and the data and information requirements for a SM tool. The potential of such a framework to support EDC is discussed, where it is highlighted that it would support engineers' real-time work and generate an Engineer-Communication-Product Artefact network. This would enable further understanding of Product Development within a company as well as a greater understanding of EDC.
Presently, the SM framework is a theoretical construct and its potential needs to be examined through a descriptive study of its use. The development of a tool and understanding its effects when incorporated within an engineering companies' communication practices is the focus of current work by the authors.