Supporting Engineering Design Communication using a custom-built Social Media tool - PartBook

Engineering Design Communication is the main tributary for the sharing of information, knowledge & insights, and is fundamental to engineering work. Engineers spend a signiﬁcant portion of their day communicating as they ‘ﬁll in the gaps’ left by formal documentation and processes. Therefore, it comes as no surprise that there is much extant literature on this subject. The majority has been descriptive with little prescriptive research involving the introduction of either a tool or process. To begin to address this, previous work reports a Social Media framework to support Engineering Design Communication and this paper builds upon this previous work through the instantiation of the framework within a custom-built Social Media tool hereto referred to as PartBook. This has been prescribed within an eleven week race car design project. The study addresses the validation of the requirements that underpin the Social Media framework as well as investigating the impact the tool has/may have on engineering work, engineering artefacts and engineering project management. In order to do so, data has been captured through user activity, system usability, questionnaire, semi-structured interview and informal feedback.


Introduction
"Communication is an essential part of any design process" Clarkson and Eckert [1] Engineering Design Communication (EDC) is intrinsic to the "fundamentally socio-technical" activities that form the basis for the engineering work within Engineering Design [2,3,4,5]. Engineering Design has also been referred to as a "knowledge intensive process of communication", which further demonstrates its importance [6]. Maier et al. [7] discuss the highly-contextualised nature of engineers' communication processes and how they enable the transmission of considerable amounts of technical information during the design process. Thus, it is self-evident that Engineering Design Communication plays a pivotal role within Engineering Design.
Engineering work is defined here as the activities performed by engineers in their day-to-day work, which have been categorised by Sim and Du↵y [8] as analysing, decomposing, defining, evaluating, information gathering, planning and scheduling. These are often highly collaborative and require considerable communication, and use of shared resources between the engineers involved [9]. Studies have shown that a high proportion of an engineers' time is spent communicating. Tenopir and King [10, p. 30] found communication to represent around 58% of engineers time and their review states that: "Numerous studies corroborate the claim that engineers spend a majority of their time communicating [11]. Estimates usually range from 40 to 60% of their work time [12], but may be as high as 75% [13]." Tenopir and King [10] approaches is also being adopted by Product Lifecycle Management (PLM) vendors who have implemented well-established Social Media features to existing products (see for example, Dassault SmartTeam & Siemens Teamcenter) [34]. This reliance on generic commercially available approaches brings advantages in terms of cost and standardisation but potentially significant disadvantages in terms of the utility and applicability of tools, and the success of their implementation. Hence, there remains an important and under researched challenge surrounding the creation of dedicated tools to support Engineering Design Communication that are based on a fundamental understanding of the requirements. In order to overcome this, Gopsill et al. [35] developed a Social Media framework that has been specifically designed to support Engineering Design Communication and is grounded by results from over 100 previous studies. This paper builds upon this research by developing a Social Media tool -PartBook -that instantiates the aforementioned framework. Thus, the initial research -Gopsill et al. [36] -is heavily referred to throughout this paper. The tool has then been applied to an eleven week Formula Student race car design project.
The aim of this paper is two-fold. First, to test & validate the requirements through the use of the tool. Second, to evaluate the impact of the tool in relation to three perspectives: Engineering work (the activities performed by engineers in their day-to-day work), engineering artefacts (the various types of documentation/objects that are generated during a design project) and engineering project management (the coordination of tasks between engineers and groups of engineers). The following sections provide an overview of PartBook (2), summarise the race car design project and study that has been conducted (3), and finally presents results and discussion with respect to the aim. First, the testing and validation of the requirements (4) and second, the evalution of the tool (5). The paper then concludes with a summary of the key results and discussion points that have arisen from the validation and evaluation of the tool (6).

PartBook
PartBook is a Social Media tool that instantiates a Social Media framework to support Engineering Design Communication (EDC). This framework consists of three elements and is reported in detail in Gopsill et al. [35]. A summary of the framework alongside its instantiation within PartBook is discussed here. The framework consists of:   The creation of a communication within Part-Book is a four step process ( Figure 2).
Step one of creating a communication requires the engineer to upload an image (for example, a screenshot or photograph) of the artefact to which the communication pertains, with an additional feature enabling the engineer to provide the URL/real-world location of the artefact. The role of the image is to provide a 'temporal snapshot' of the artefact at the time the engineer wishes to initiate the communication. This enables participating engineers to further understand the engineering context surrounding the communication. The URL/real-world location enables quick access to the artefact.
Moving to step two, the engineer is required to tag the communication with respect to the type of artefact (for example, a CAD file) that has been selected alongside the 'focal point' on that artefact (for example, Error Message). Options appear as a drop-down menu and engineers are able to add new types to the list. Again, this is building the engineering context that surrounds the communication and also enables the aggregation and filtering of communications based on these dimensions.
Step three is where the engineer enters the content of their communication. There is a 250-character limit to maintain conciseness and thereby prevent 'wa✏e' [3]. The appropriate limit for a communication is still to be determined but has been set at 250-characters as it is argued that engineering terminology typically contains more characters yet the principle is to have a similar length of message as seen in the 160-character limited SMS and Twitter messages. The engineer is then required to select the purpose of the communication (for example, idea, clarification or decision). This plays an important role as it depicts the type of responses that participating engineers can make and focuses the communication towards a limited number of possible outcomes (Please see the Engineering Design Communication matrix in Gopsill et al. [35]).
Finally, step four provides the opportunity for the engineer to position the communication with respect to the project, activity, product, part, concept, feature and lifecycle stage to which it pertains. The main role of these tags is for search & retrieval, and to be used by the Awareness part of the communication process, which is discussed later. Once completed, the engineer can click 'Create' and this generates the communication within PartBook and enables engineers to Respond to it. Once created, the engineers are able to access and Respond to the communication from the within tool. Figure 3 shows the input the engineer uses to reply to a communication within PartBook. This option appears when an engineer selects one or more elements within the communication to respond to. This enables multiple threads to be generated within a single communication and thus, engineers are able to present various perspectives concurrently as well as enabling the divergence and convergence of ideas/discussions (see Figure 1b).

Responding to a Communication
The response is character limited and the engineer is required to select the type of response that they are making (Examples include, opinion, experience, observation). The type of response uses a drop down menu containing common types of response, which is based upon the Engineering Design Classification matrix [35]. Engineers are also able to generate new types of response as it is contended that the current list may not be exhaustive. The aim of the response type is to enable other participating engineers to understand the perspective of the responding engineer. This is typically demonstrated through the mannerisms and body language of an engineer during Face-to-Face discussions [16]. The engineers are also able to add supplementary information through the upload of an image, which might for example, show the e↵ect of changes they have made to an artefact (e.g. showing the code that fixes a CAD error). The engineer can also place a URL link or location of a file within their response. The communication remains within this stage until the originating engineer determines that it has reached its conclusion (Conclude).

Concluding a Communication
The originating engineer determines whether the communication has reached its conclusion. At this point, the originating engineer selects one or more elements in the communication and selects the option to conclude the communication. The reveals an input similar to that of respond ( Figure 3).
The engineer is required to select the type of conclusion that has been reached (for example, problem solved) as well as providing a final comment detailing the result of the communication, which is again character limited. They are also able to provide a final image of the artefact with its location, which could be used to record the consequence/impact of the communication on the Engineering Record (e.g. the modified CAD drawing). Thereby, associating the rationale to a change made to an Engineering Record. The engineer has to link the conclusion element to either one or more of the previous communication elements to show where the conclusion has come from. By concluding the communication, the engineer e↵ectively moves it from the current real-time active state to an archived search & retrieval state. This leads to the Hindsight stage.

Hindsight within Communications
The communication is now in an archived search & retrieval state that can be recalled and re-used. Hindsight facilitates this by enabling engineers to place comments and refer back to past elements of the communication. Examples could be to highlight redundancy, best practice and/or make amendments ( Figure  1b). As with the previous stages, the engineer is required to direct these comments to particular elements of the communication, highlighting the type of hindsight being made, as well as making their comment, which is again character limited. The input for hindsight is of the same design as the respond input ( Figure 3).

Awareness of Communications
Throughout the communication process, PartBook provides functionality that is aimed at ensuring the right engineers are made aware of communications to which they could potentially contribute. This functionality comes in the form of tags that can be applied within any textual element (referred to as #tags). The engineers are able to notify one another through the use of @(Joe Bloggs) for example, thereby supporting the use of the engineers' social knowledge to send the communications to right engineers [37,38]. There are also a number of #tags that enable the grouping of communications in relation to personal bookmarking, tasks and expert groups. Engineers have the opportunity to #tag other communications, which enables the sharing of rationale and the ability to monitor traceability of communications that influence other communications. The final aspect is the ability to take advantage of all the tags being used within the system so that engineers are able to generate so called 'interests'. An interest is a selection of tags chosen by the engineer and it enables the customisation of the communication feed they see ( Figure 4). The aim is to present the right communications to the right engineers. In order to notify engineers of changes within PartBook (such as a communication that has been directed to a particular engineer), a notification in the form of an e-mail is sent to the respective engineer(s). To summarise, this section has provided a brief overview of the SM framework and a user perspective of generating a communication within the PartBook, which instantiates the aforementioned framework. A detailed discussion of the SM framework is given in Gopsill et al. [35].

Formula Student Race Car Design
In order to assess the validity of the SM framework and also evaluate the impact of introducing a SM tool on a team and engineering project, PartBook has been introduced to a Formula Student race car design project (2013). The importance of such a project within the education of young engineers has been discussed by Davies [39], who highlights that Formula Student is the closest to a real-life project that the students have throughout their education as it involves the delivery of a product, justification of design choices, collaboration within a team and the management of stakeholder expectations. The Formula Student project has been previously used in research to evaluate and validate the implementation of new tools or development of knowledge models (See for example, Jamshidi and Jamshidi [40], Qin et al. [41], Langer et al. [42]). Also, Formula Student provides a design project that is repeated every year by approximately 100 university teams 1 , and thus, aids repeatability, and enables comparison and contrast of Engineering Design Research within a consistent context. This section provides a summary of the Formula Student project and provides more details regarding the study method itself. Formula Student (FS) is a Motorsport educational programme aimed at developing the next generation of race engineers. Competitions are held worldwide in the UK, US 2 , Australia and Europe. Teams of students from their respective universities are placed in charge of designing, developing and manufacturing a single-seat race car to compete within the various challenges set-out by the competition. It is also a highly multi-disciplinary and collaborative environment involving the expertise of students undertaking various engineering courses such as aerospace, automotive, electrical, manufacturing and mechanical. The judging of the competition is not only based upon how the car performs at the event but also how the team can provide and deliver the design rationale 'why the car they have designed is the way it is'.  In the case of the team at the University of Bath, hereby referred to as Team Bath Racing (TBR), a group of third year students are selected to participate in the Formula Student Competition, who are then tasked with the design and development of the car. The 2013 is made up of 33 engineering students from various courses as shown in Table 1, thus revealing the multi-disciplinary nature of the team and project.

Formula Student
The Formula Student project is primarily run at the University and in the case of the TBR team, there is allocated workspace. Therefore, it may be argued that the study is not one of a distributed team but of a collocated team. However, Figure 6 shows the main flows of internet tra c through PartBook over the period of the study and reveals that there must have been cases where some members of the team were working away from their allocated workspace. It is interesting to note the 30% of the tra c has come from the London area although one has to recognise that the tra c is passing through main network hubs and therefore this may be tra c for the South East region of the country. Notwithstanding this, it does provide evidence to show that the project has an element of geographical distributed working. The primary objectives of the study are two-fold. First, to validate the SM framework and this is to be achieved by assessing the validity of the underlying requirements that the framework has been built upon ( Table 2, [35]). Second, to evaluate the impact of introducing a SM tool on engineering work, engineering artefacts and engineering project management.

Study Description
To meet the two objectives, five complementary means of evaluation were undertaken. These were a questionnaire, semistructured interviews, user activity, assessment of tool usability and informal feedback. Robson [43] highlights the importance of using multiple methods of data capture as the study is one of the 'real-world' where many outside influences might a↵ect the results. The use of multiple-methods of data capture enables triangulation of results and therefore provide enough evidence to conclude the requirements validity and also evaluate the impact of the tool on the engineers and project [44].
For the first objective of the study, the questionnaire, semistructured interviews and informal feedback were used to elicit the validity of requirements from a user opinion perspective. This has also been combined with the communication activity that has been captured within PartBook to provide the validity of the requirements from an user activity perspective. The second objective uses the communications captured by the PartBook tool alongside the E-Mails that were sent & received, with the latter providing a comparative measure of the impact on the engineers' communication behaviour. Finally, the results of the tools usability provides a valuable insight into the likely impact the usability of the tool may have on the other results gathered and thus, the discussion of the results will highlight this accordingly.

EDC
Requirement Requirement: 1 To capture a high quality representation of the originating engineering artefact relating to the communication. 2 To record changes to the engineering artefact as a consequence of the communication. 3 To enable contributing engineers to embed a representation of an engineering artefact in their responses. 4 To provide a text based description of the engineering artefact. 5 To record/capture the foci of a communication with respect to the engineering artefact. 6 To provide an electronic or physical reference to the engineering 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. 12 To define the type of response for each contribution to the communication. 13 To align the response types to the appropriate purposes. 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. 18 To enable engineers to reference responses in past communications within current communications. 19 To enable engineers to comment on past communications. 20 To classify communications by the the Company, Product and phase of the Product Lifecycle. This study has been one of full disclosure, whereby the students are fully aware of the research project and this has been performed by presentations given before the start of their project [45]. The study took place over an eleven week period with the first two weeks reserved for showing the students the features of the tool. Weekly feedback sessions were held to discuss the use of PartBook and whether there were any technical issues. The following sections provide a more in-depth description of the five means of evaluation.

Questionnaire
The questionnaire was provided to all the engineers involved and had been designed to elicit user feedback on the functionality provided by the tool. The development of the questionnaire followed the methodology set out by Peterson [45]. As the user-group were unaware of the requirements and rationale behind the requirements, it is important to elicit responses to the requirements with respect to the context of using PartBook. Table 3 provides an example of some of the questions that relate to a specific requirement and is placed within the context of using PartBook.
The analysis of these results provides an indication as to the validity of the requirements from a general user perspective. Some additional background information concerning the participants with regards to their usage of Social Media tools was also collected in order to elicit their level of experience with such tools. The questionnaire can be viewed in its entirety in Appendix A and totals 47 questions.

PartBook Questionnaire
Refers to Requirement Type The purpose tag helped me understand what the engineer wanted from the communication.

RQ11
Lickert Scale (1-9) The response tags helped me understand the statements being made within the communications.

RQ12
Lickert Scale (1-9) The conclusion tag helped me understand the outcome of the communication.

RQ17
Lickert Scale (1-9) The images aided my understanding of the communication.

Structured Interviews
Structured interviews were conducted with a subset of engineers, namely the Project Leader, PartBook Liason Engineer 3 and a PartBook user who had a high level of engagement with the tool and its implementation. Each worked closely with the researcher to implement PartBook within the project and therefore had a deeper understanding of the requirements that related to features present within the tool. Therefore, these participants are able to provide a di↵erent perspective to the validity of the requirements when compared to the wider group. In order to take advantage of this, a structured interview process was employed where each of the three participants was given an opportunity to rate the 'validity' of each requirement through a Lickert Scale measuring 1-5, and provide a reasoning for their rating. In addition, they were also able to provide potential amendments to the requirements/considerations or explicitly request new requirements/considerations.  As PartBook has been built upon web technologies, all activity on the site has been recorded within a MySQL database and thus, provides a rich dataset of user activity that has been timestamped and stored. In addition, all e-mails sent pertaining to the project were stored in a shared mailbox so that a comparison between E-Mail and PartBook could be made. The additional background questions asked the engineers to state the methods by which they communicated and the results are presented in Figure 7. Thus, it highlights that there were communications that were not captured within this dataset.

User Activity
In addition, the evolution of the file structure of their shared workspace was captured using a Raspberry Pi and separate RAID storage. The python code checked the file structure of the shared drive every 20 minutes and it would note any changes to the structure and files. If a file had changed, a copy of the file would be made to the RAID storage. Thus, enabling comparison of the files as they evolved during the project. This enables insights to be drawn between the potential relations communications and changes in the artefacts being generated. The analysis of this large dataset provides the ability to assess the impact of the tool with regards to engineering work, engineering artefacts and engineering project management. As this study is dealing with the implementation of a tool into a project, it is also necessary to consider its usability as this may have an impact on the results of the study. This has been performed by using the System Usability Scale (SUS) as a means to assess those tools usability and has been widely used within computer science [46]. The engineers answered the SUS questions alongside the questionnaire at the end of the eleven week period.

Usability Assessment
PartBook received an average score of 56.3 which places the tool in the 20th percentile, thus it can be concluded that there is currently a lack of usability with PartBook. However, Figure 8 shows a box plot of the respondents SUS scores, which vary greatly. This may be an indicator that the tool's functionality may not have been explained fully and coherently to all the engineers. Figure 9 show how the overall summation of the scores from the PartBook questions (with the higher number indicating greater agreement with the requirements) varies in relation to the SUS score. There appears to be some level of correlation between the two values indicating that the usability of the tool did impact the responses given. However, no statistical significance could be determined due to a relatively low n number even though it is considered reasonably high in this field (33). Although, having this analysis and insight provides a clear indication that usability may be a significant factor on the questionnaire and interview results.

Informal Feedback
As the study involved the implementation of a tool within an engineering project, weekly meetings were held to highlight any technical issues and also provide feedback about the tool. Minutes were taken for each meeting and development of the tool continued in order to amend any technical issues that were raised. The sessions were well attended with average attendance of 91% as the feedback session followed the weekly project meeting.

Summary
This section has provided the context of the study and highlighted the primary objectives of the study which are the validation of the requirements and evaluation of the framework through the impact it has/may have upon engineering work, artefacts and project management. This has been followed by a discussion of data captured during the study in order to meet these objectives. Five means of data capture have been employed in order to triangulate results from user opinion and user activity. This is important in a 'realworld' study as there may be many influences that are out of the researchers' control. The five means are:   Table 4 provides a summary of the dataset that has been generated. The following sections provide the results and discussion relating to the validation of the SM framework and also evaluating the impact the tool has had on the engineers and the project.

Exploring the Validity of the Social Media Framework
This section presents the results in relation to the validity of the requirements underpinning the Social Media framework. From the analysis of the results, the requirements are deemed to lie within one of four categories of validation defined as:

Valid
Both results from the user activity and user opinion indicate that the requirement should be met in order to support Engineering Design Communication.

Partially Valid
Either the user activity or user opinion results gathered provide an indication that the requirement should be met in order to support Engineering Design Communication. The results may provide a potential amendment to the requirement.

Not Valid
Neither the user activity or user opinion results indicate that the requirement should be met in order to support Engineering Design Communication.

Insu cient Data
The user activity and user opinion did not provide su cient data to assess the validity of the requirement.
The results relating to each requirement (Table 2) are organised in relation to these categories. Ahead, of the discussion of the results, three figures and one table are presented as these are used throughout. Figure 11 presents the box plots produced by the feedback given with respect to each statement in the questionnaire, whilst Figure 10 shows the highest and lowest rated Social Media features. The engineers were asked to provide their top three highest and lowest rated features and to order them by preference. Figure 12 provides an insight into which tags the engineers would use if they were to search & retrieve communications. Finally, Table 5 presents the matrix of purpose-response tags that were used in the communications held within PartBook.

Valid Requirements
This section highlights the requirements that have been deemed valid based upon the results of the study. Table 6 provides a summary of survey results, which are used throughout the discussion. Each of the requirements that have been deemed valid are now discussed.    Table 6 highlights that two out of the three participants in the interviews felt that requirement 6 was valid by providing the Lickert score of 5 and did not have any further comments to make. The project leader noted that if one were to attempt to search for communications against a particular artefact, it was not possible to do so easily within the tool. Thus, indicating a usability issue with the tool as well as providing evidence to show that there may a number of perspectives that an engineer would wish to search communications against.
Looking at the analysis of the user activity, Table 7 provides some details on the provision of an electronic or physical reference to an artefact. Almost a third of communications contained a reference to an artefact through either using the 'add URL' feature or by simply placing the link within their response. This is a particular a↵ordance arising from using a web-based tool. Thus, it is important for the purpose of validating requirement 6 to say that it was used by the engineers.
Therefore, it is argued that requirement 6 is a valid requirement. The results have also highlighted potential future work in how the capture of these communications could be re-used in Engineering Design.
To enable engineers to 'push' communications to one another (Requirement 7) Two of the three participants of the structured interviews felt that requirement 7 was a particularly valid requirement in order to support Engineering Design Communication ( Table 6). The project leaders' score of three may be justified against the need for the tool to provide a list of names to ensure that no miss-spelling occurs and therefore this can be seen as a usability issue within the tool.
Considering the questionnaire results, the ability to provide a notification to an engineer of a communications' existence proved to be one of the most favoured features of PartBook ( Figure 10). 76% of the communications within PartBook contained at least one @(engineer) tag and 29% of all the creation and response elements within the communications used the @(engineer) tag. This further highlights its utility within the tool. The response to the statement directing a communication with the @ feature was useful for ensuring I get a response to my communication had a highly positive agreement with a positive skew, which confirms that the engineers felt it was a crucial feature of the tool. During the use of PartBook, a response element termed response request & notification was generated, which was used to notify and encourage a response from other engineers. Taking these results into account, an additional requirement could be proposed: To direct the communication to at least one other engineer during its creation. This is to ensure that an engineer is more likely to receive a response once they have created a communication.
Therefore, it is argued that requirement 7 is a valid requirement. The results used to discuss its validity may also have generated a new requirement concerning the need to direct the communication to at least one other engineer.
To enable to solicit responses from core competency (expert) (Requirement 9) Expert Group Names dynamics business powertrain example competitor analysis composites cad design manual oil (an engineers name) simulation fault sponsorship combustion imaginary maginary @(name maginary @(name (an engineers name) gearbox trb14idea ses Reflecting upon requirement 9, 25 expert groups were created during the eleven week project and were used in 89 communications (18% of the total communications). This shows that expert groups o↵er the potential for categorising Engineering Design Communications. Looking at the list of 'expert groups', it can be seen that some were erroneous tags but many could be seen as plausible expert groups for the given design project (for example, powertrain, composites and CAD).
The results from the survey ( Table 6) revealed that although the groups were created, the size of the project meant that the group actually referred to a small subset of engineers (2 or 3, for example). Hence, it may have been the case that the engineers would have 'pushed' it directly to them rather than assign the communication to a specific group. The PartBook Liaison highlighted a limitation of the tool that the experts were not made aware of the communication being added to a group (i.e. no notification).
Thus, it is argued that this requirement has been validated by the study although its implementation within the tool led to issues in the engineers being able to solicit responses by grouping the communication by expert.
To define the purpose of the communication (Requirement 11) Table 5 presents the purpose-response matrix, which has been generated from the actual purposes and responses within PartBook from Gopsill et al. [35]. 60% of communications used the standard set of purposes, which is consistent with the feedback from the questionnaire highlighting that purposes-responses require further definition and refinement ( Figure 11). This could also be an indicator of the current limits of understanding of Engineering Design Communication.  Sixteen additional purposes were generated by the engineers although most of them were hardly used (< 1%) of the time (see, Figure 13). By far the most used purpose is Discussion (24%). Feedback from the engineers indicated that they would use this when they were not entirely sure what they wanted from a communication and therefore, not looking for any particular conclusion. Action Required was also used relatively often and this was used to deliver tasks to others, which is interesting as it had not originally been intended as a task management tool. Another interesting purpose was meeting and informal discussion and the engineers revealed that the tool had been used to manage the agenda and discussion within their internal meetings. This shows that users of a tool will also find other uses for it in addition to its original intention.
Looking at the feedback from the question (Figure 11), 'The purpose tag helped me understand what the engineer wanted from the communication.', there is a large spread of opinion on whether it did help the engineers understand the statement made by the engineer creating the communication. Although, there is a negative skew to the box plot in Figure 11 indicating that many found it useful and only a few did not. Although this division in its utility is futerh indicated in the results from the high-rated/low-rated features of PartBook further show there is a divide on its utility ( Figure 10). However, it has also been indicated that it may again be useful in terms of future search & retrieval, which may have not been considered in the previous questions ( Figure 12). Finally, the interview results (Table 6) indicate that this is indeed a valid requirement for supporting Engineering Design Communication and they also highlighted the importance of making this mandatory for all communications.
To define the type of response for each contribution to the communication (Requirement 12) Analysing the user activity, 30 additional response types to the original 13 were generated although there were a few that could be classed as repetitions and others generated for the purpose of testing improvements to the website. These have been highlighted through superscript numbering in Table 5. This leaves a total of 33 di↵erent types of response made by the engineers. It is also the case that many response types were re-used across the various purposes of communication. This is interesting to note as it does indicate a level of completeness to the number of response types and also that there could potentially be a limited set of response types within engineering communications. Table 6 shows that both the PartBook Liaison and User agreed that this is indeed a valid requirement for supporting Engineering Design Communication. Although, the Project Leader commented that too much information is being requested at each stage of the communication process. This comment may not simply refer to this requirement but suggests there is too much tagging required in the tool. Therefore, future work should consider the most important aspects to capture.
Looking at the purpose-response matrix (Table 5), it can be seen that it is very sparse. The fact that this matrix is not vastly populated and that the engineers had the opportunity to do so may indicate that there is a inherent structure given the purpose of the communication. 88% of the responses made by engineers used the original response types, which as previously stated is a possible indicator of a relatively high-level of completeness in the responses associated to those purposes. It is also promising to see that some of the original response types proposed by Gopsill et al. [35] were also used by the engineers in their newly generated purposes. Overall, 62% of the responses were of the standard set or derivations thereof. This is encouraging given the limitation of past research not being able to analyse the full extent of responses made by engineers during communications.
To align the response types to the appropriate purposes (Requirement 13) Looking at the association matrix, it can be seen that it is very sparse (Figure 5. This result may indicate that there is a inherent structure given the purpose of the communication as this has occurred given that the engineers had the opportunity to add any number of additional response types.  Looking at the original set of purposes, 88% of the responses made by engineers used the original response types thereby indicating a relatively high-level of completeness in the responses associated to those purposes. It is also promising to see that some of the original responses were also used by the engineers in their newly generated purposes. Overall, 62% of the responses were of the standard set or derivations thereof. This is encouraging given the limitation of past research not being able to analyse the full extent of responses made by engineers during communications. The feedback from the students is in surprising contrast to the quantitative metrics provided above. Figure 11 shows the results to the question The initial set of purpose/response & conclusion tags were complete, which indicates that they did not feel it was complete and is a place for future work. It is also the case that the response tags was one of the least favoured features on PartBook ( Figure 10). Finally, the feedback from the interviews assessing the validity of the requirements (Table 6) further highlights its incompleteness and need for clearer definitions between the types of response.
Interpreting these results, it is argued that this is a valid requirement for supporting Engineering Design Communication although more work is required on the definitions and increasing the completeness of the response tags.
In contrast, the results from the questionnaire feedback contradict the quantitative metrics. Figure 11 shows the results to the question The initial set of purpose/response & conclusion tags were complete, which indicates that they did not feel it was complete. It is also the case that the response tagging was one of the least favoured features of PartBook ( Figure 10).
Through consideration of these contrasting results, it is proposed that this is a valid requirement for supporting Engineering Design Communication although more work is required on the definitions and increasing the completeness of the response tags.
To enable multiple-threads within single communication episode (Requirement 15) Table 6 highlights the validity of this requirement in order to support Engineering Design Communication with a high score averaged across the participants. The PartBook User did highlight that the current instantiation of this can be ine cient in terms of space used on the screen. Therefore, a potential amendment would be to provide a consistent method of structuring multi-threaded communications.
Looking at the results from the questionnaire, 62% of communications within PartBook used multiplethreads and was the top rated feature on PartBook. The responses to the statement the multi-threaded feature helped the team to express di↵erent perspectives received a reasonably high and consistent score by all respondents. Thus, it is argued that this is a valid requirement and a potential refinement would be to enable multiple-threads within a single communication episode that are structured in a more consistent manner.
To formally conclude a communication (Requirement 17) Table 9 shows the list of conclusion types alongside associated purposes. The break within the table designates the transition from purposes that were the original set and those that were created by the engineers during the study. 95% of the conclusions used the original associated conclusion types. This suggests that there is a high-level of completeness, which is promising given that many were logical suggestions due to the lack of extant research [35]. These were based upon always providing an engineer with either a positive or negative outcome to the communication. The results from the table show that few new conclusion types were introduced to the original set of purposes, which provides some evidence to support this logical proposition.
Also, the additional generated outcomes for the original set of communication types by the engineers were mainly of action required or derivation thereof. Informal discussion with the engineers revealed that some communications led to the creation of a task that needed to be completed and therefore used action required to highlight this. The relationship between communications and generation of tasks is an area that could be further investigated.
Reviewing the results from the interviews (Table 6) received the highest possible score and the engineers felt that it was important to capture and understand the actions taken after a communication. However, the PartBook Leader did highlight that it was not possible to assess whether the following action(s) were ever performed. Therefore, a possible further requirement is for the originating engineer to provide a result of the concluded actions. Thus, based on both the quantitative and qualitative evidence, it is argued that this is a valid requirement and a potential additional requirement is to ensure the engineer provides results from potential actions in the conclusion.

Partially Valid Requirements
This section highlights the requirements that have been deemed partially valid. Table 10 provides a summary of the survey results, which are used throughout the discussion. Each of the requirements that has been deemed partially valid is now discussed.
To capture a high quality representation of the originating artefact relating to the communication (Requirement 1) Table 10 details the results from the survey for the partially validated requirements. Requirement one achieved an average score of just over 3 and indicates that the engineers were unsure how valid the capturing of a high-quality representation of the originating engineering artefact relating to the communication was. Taking a look at the questionnaire, the result from the statement 'the upload of an image helped me frame my discussion' shows that the engineers neither agreed or disagreed although there is a slight positive skew potentially meaning that a minority found it useful. Upon informal discussion and feedback, it was highlighted that it was the time taken to create & upload the image that proved the greatest distraction and better usability would improve this.
Therefore, it is argued that this requirement has been partially validated in that the capture of a representation of the artefact does support Engineering Design Communication but is not essential. Usability issues may be a reason for it not being favoured by the engineers. Therefore, further work is required to understand how representations of artefacts should be used to support Engineering Design Communication.
To record changes to the Engineering Record as a consequence of the communication (  Looking at the survey results for requirement two, the PartBook Liaison and User present a consistent viewpoint highlighting that representing the communication in the manner that PartBook requires, does help them understand the work that has occurred on the artefact of interest. Although, the Project Leader highlights that due to limited participation by some of the team, not all communication pertaining to an artefact was recorded. This issue leads to the conclusion that this requirement has been partially validated as the tool was able to record the changes, however, issues with participation meant that the potential in understanding the entire evolution of an Engineering Record was not possible. Although, it is contended that no communication tool will ever record all forms of communication and therefore one has to be aware that the dataset is only a subset of the rationale and information shared within a project.

(Requirement 3)
Analysing the comments and amendments from the survey, all participants mentioned that there may be cases where more than one representation would be required in the response. The Project Leader also highlighted a usability issue with the tool that may have skewed the result. It is also interesting to note that approximately 30% of the communications within PartBook included a reply containing an additional representation even though there was not a requirement to do so. It is argued that this shows that there is indeed a need for engineers to present supplementary representations as they did so, even though they had to overcome the time barriers in the creation and uploading of the representation.
Therefore, it is argued that this requirement is partially validated as the results show that it is important to provide additional representations despite the usability issues. Notwithstanding this, a potential amendment would be to 'enable contributing engineers to embed one or more representations of an Engineering Record in their responses' as highlighted by the PartBook user.
To provide a text based description of the artefact (Requirement 4)  Figure 10 shows the feature 'to tag the representation by its type' proved to be one of the least favoured features of PartBook. This is further highlighted by the responses to the statement, 'the artefact tag helped identify what the image was when creating the communication', which received a relatively low-level of agreement as well as a negative skew thereby highlighting that very few found it useful. The informal discussion of these results led to the outcome that in this case, the representations were enough for them to understand the type of record they were looking at and therefore they did not see the need to explicitly indicate the type. However, Figure 12 does reveal that some of the engineers would use it as a means to search & retrieve communications. Thus, highlighting its potential re-use value.
Reviewing the feedback from the interview results (Table 10), the comments made by the engineers are more related to the creation of the statement text and not the creation of a tag related to the engineering artefact. Therefore, it is deemed that there was confusion over this area and therefore, the information cannot be used to validate the requirement.
It is also noted that the list of artefacts became large very quickly and therefore di cult to use as the number of terms quintupled during the study (Figure 14). A suggestion was that the file type indicated by the URL provided for digital representations could be used to constrain the types of representation listed (i.e. a .par file already provides a good indication that the representation is of a CAD part). Therefore, it is argued that this requirement has been partially validated and should be amended to: To provide a semi-automated predictive text-based description of the engineering artefact.
To record/capture the foci of a communication with respect to the artefact (Requirement 5) Recording the foci of the communication was achieved in the same manner as the engineering artefact tags. They appeared as a subset of tags once the artefact tag was selected. The use of the focus tag to capture the foci of the communication with respect to the engineering artefact received a similar although less negative response when compared to the previous record tag. The responses to 'the focus tag helped me identify the key point of the image when creating a communication' showed the majority were indi↵erent with the statement although the negative skew suggests that a minority disagreed (Table 11). Informal discussion of these results highlighted that in contrast to the 'artefact tag', the engineers understood the reasoning for this tag and that there could be no automation. As with the 'artefact tag', the growth of terms also quintupled during the study, which raises issues about its potential utility as a filter for future search & retrieval ( Figure 15). In addition, 187 foci tags were generated and 167 tags were unique, which highlights that there are considerable di↵erences in the types of foci between the various artefacts.
The results from the survey (Table 10) further highlights the issue of categorising by foci, and mentions the issue of a large set of tags being user created. The results also suggest that the tags should be predefined before the start of a project, possibly during the project planning stage.
Also, rather than a description of the foci, it was suggested that the ability to highlight specific areas on the artefact would have been su cient for them to deduce the focal point upon the artefact. As well as reducing the burden of generating a suitable tag to describe it. Thus, the requirement should be changed to: To highlight the specific area upon the representation relates to the foci of the communication.
To enable engineers to group communications by task (Requirement 8) Task Group Names cockpit tshirt weeks. i suggest a better foc (error from tool) powertrain castle combe 00g (error from tool) Only six task groups were created throughout the study and for each task created, only one communication was assigned to it. This reveals that task groups were not used within this study. In addition, it can be seen that two of the six tasks were generated out of error by the tool. Although, the results from the interviews (Table 10) contain no comments, yet high scores were given. This hints that it could be a potentially useful method of categorisation for larger projects. This is also supported by the fact that the engineers felt that group tags would be a useful means for searching and retrieving past communications (Table 12). Thus, it is di cult to assess its validity due to lack of use, although it could be said that it is partially validated as the participants have noted its potential utility in supporting Engineering Design Communications.
To ensure an appropriate limit is imposed on the size of a response (Requirement 14) The scores from the survey show that there is no consensus to its validity thus leading to the average being neutral. The comments show that the character limit that was initially set at 255 characters, gave rise to a number of issues and led to some engineers having to reply multiple times in order to get their point across. This is further indicated by the use of response types such as Addition and Additional Information, and the feedback provided by the engineers during the study. This led to 28% of the communications having the initial engineer replying to their communication in order to provide more information. Therefore, in week five, the character limit was increased to 400 characters although it remained an area of contention. The responses to the statement the character limit helped focus the discussion on the topic of interest received the greatest disparity and therefore it is di cult to draw any conclusions ( Figure 11). Figure 16 shows the responses to the statement 'The character limit should be', where three options were given: decreased, increased or not exist. It can be seen that the majority favoured increased and therefore, it is argued that a limit should be imposed although further work needs to be done in order to determine an appropriate length.
Thus, it is deemed that this has been partially validated, however the use of a 'hard' limit may not be appropriate. Rather, a potential warning system that indicates when the length of a message is becoming too long (for example, a pop-up warning if a message is > 400 characters). Therefore, the requirement should be amended to ensure a method is in place to encourage concise responses.
To enable engineers to reference responses in past communication within current communications (Requirement 18) The feature to reference past communications within new communication was only used seven times although, it did appear in the top features of PartBook ( Figure 10). Feedback from the engineers revealed that they felt they were too early in the design phase to really use this feature and it was the case that they were using past engineering records as supporting evidence as opposed to their recently generated communications. It seems that they understood the potential value of the feature and hence that some believed it to be a top feature of PartBook, however, a dataset of past communications would be required to investigate this requirement fully.
The feedback from the survey ( Table 10) further supports that the engineers felt this is a valid requirement for supporting Engineering Design Communication. However, the PartBook Leader did highlight the di culty in usability in the current tool and that this would need to be improved. Therefore, it is argued that this requirement has been partially validated as more use cases are required.
To enable engineers to comment on past communication (Requirement 19) Considering that the study was of the first eleven weeks of a new design project, it comes as no surprise that only 4% of the communications generated within PartBook contained a HINDSIGHT element. This is not too discouraging as it is acknowledged that this a reference feature primarily for future projects referring back to communications from past projects. Therefore, it does give an indication that engineers would like to use this feature but more investigation is required.
The feedback from the survey ( Table 10) further supports that the engineers felt this is a valid requirement for supporting Engineering Design Communication. Therefore, it is argued that this has been partially validated due to the lack of use in this study.

To classify communications by the Company, Product and phase of the Product Lifecycle (Requirement 20)
The last requirement was not assessed within this study as the engineers believed that the feature was too much of a burden on the creation process of the communication. This is because there was no pre-defined structure or process in place for the project and therefore, the engineers would have to define it. Therefore, in order for PartBook to be used, this feature -step four of the creation process -was disabled. Figure 10 shows that although it was not used in this study, the engineers could see such a classification as potentially useful for search & retrieval purposes. The results from the survey did receive positive feedback on the validity of the requirement given a larger engineering project. The PartBook Leader highlighted that a simplified version of these categories would have been more suitable for their project. Therefore, it is argued that this is partially validated based on user opinion but a use case is still required. In addition, further work is required on how this classification should be structured for di↵erent types of engineering project.

Insu cient Data
For the two remaining, requirements, there was insu cient data to assess their validity.
To enable engineers to assign personal bookmarks to communications (Requirement 10) To enable engineers to respond to one or more threads within a communication using a single response (Requirement 16)

Summary
Of the twenty requirements proposed by Gopsill et al. [35], eight requirements have been validated, ten partially validated and two had insu cient data to be validated from the results gathered. In addition, four potential amendments and one additional requirement were established. In addition, four key insights from the analysis are highlighted: 2. The significant use of images to aid understanding of the statements being made despite the usability issues present within the tool (30% of replies contained an image). 3. The importance of enabling engineers to use their own engineering social knowledge to identify the right engineers for a communication with 76% using the feature at least once. 4. The relative completeness of the tags used to describe the evolution of the communication. Where: • 60% of communications used the original purpose types • 88% of communications used the original response types • 95% of communications used the original conclusion types

Evaluation of the Social Media Framework
This section presents the results from the evaluation of the Social Media Framework. Here, evaluation involves exploring the impact of the implementation of the tool/process/method (i.e. PartBook) within the context of the engineering project. In order to achieve this, a secondary -exploratory -analysis of the dataset has been performed to investigate the potential impact that the tool has/could have on three areas; engineering work, engineering artefacts and engineering project management. Figure 17 shows the impact on the instances of communication between E-Mail and PartBook during the project. Clearly, E-Mail was used substantially in the first few weeks but as the project progressed, the use of PartBook increased and E-Mail decreased. As the total level of communication does not vary greatly over the weeks, it is argued that the Engineering Design Communications that would have been held within E-Mail are actually occurring within PartBook. Thus, there is a transference of communications to the new tool and as the total instances of communication across the weeks is fairly consistent, it provides some evidence to suggest that the addition of new tools does not necessarily increase the workload of the engineers in terms of the total number of communications. To understand the impact upon an engineers' work further, Figure 18 shows the distribution of the time taken to generate a communication within PartBook over the eleven weeks. This time was calculated from the time an engineer opened the new communication page to the time it takes it to be submitted. The box plots are fairly consistent over the eleven weeks with the majority of the communications taking between 2-4 minutes. This consistency suggests that the engineers became instantly familiar with the generation of a communication within the tool. Although, there were a few outliers that see some engineers taking more than 10 minutes. Informal feedback from the team suggested that these were cases when an  individual would start the 'creating communication process' before having the image of the record available to them. Thus, this extra time was where they were creating that image to upload to the tool. Even though, the fact remains that it took a relatively short time to create the communications within PartBook especially when one considers that the average length of an original E-Mail (i.e not a reply or forward) for the team consisted of 118 words on average and with a typical speed of 19 words per minute for composition, this leads to an average creation time for an e-mail of around six minutes [47].

Engineering Work
The final aspect that has been considered with respect to engineering work is the e↵ect of the tool on the collaborative nature of the engineers. Figure 19 provides a visual depiction of the communication network generated by both E-Mail (a) and PartBook (b). Each node is representative of an engineer with the size determined by the number of connections to that node (degree). It can be seen that E-Mail appears to have a few highly connected engineers, whilst the level of connectedness is more evenly distributed in PartBook. This is further shown by the average degree values of eight and 23 respectively. However, it has to be noted that E-Mail was the method used to communicate with people outside of the engineering team, although that does influence the result as they would not be connected to all the engineers within the team. The magnitude of di↵erence between the two levels of degree does therefore highlight the potential for Social Media based tools to provide a more collaborative method of communication. As mentioned in the introduction, communications are closely related to the engineering artefact being generated by the engineer. This can be confirmed by Figure 20, which presents a matrix of the ratio of various purposes of communication with respect to the artefact that it pertains to. It can be seen that within this project, most of the 'issues' and 'actions' primarily concerned CAD files and many 'ideas' and 'decisions' were related to the physical parts of the product. This appears to be a logical result as the team had last years' car to learn from and analyse, therefore many of their ideas could be seen as potential improvements on last years model. This may be a potential indicator of the level of re-design being undertaken from a previous product. In respect to having a high number of issues and actions relating to CAD parts, this could be due to the fact that one of the key outputs of the project is to have a digital mock-up of the car. It is logical to assume that the engineers would potentially be focusing on this aspect even more so than other areas of the project hence the greater number of issues and actions being generated. This could be potentially useful in identifying key areas of focus during the evolution of and engineering project. Confirmation can be seen across all the artefact types apart from part, this may be due to the fact that parts are more likely to be related to parts from the previous car and are thus, not objects generated by the engineers and leads us to the potential conclusion that confirmation is used by engineers for their own work and records they generate. Figure 21 shows how the generation of communications related to their record type changed over time. It can be seen that many discussions at the initial stage were related to parts and as discussed previously, this seems a logical result as the engineers may be discussing last years' car and how they might improve upon it. CFD communication has a steady accumulation over time, which may be an indicator of a steady level of work being performed within that area. This is in stark contrast to records termed 'aero design', which appear much later in the process. As the engineers had little or no experience of CFD or fluid dynamics, this trace potentially demonstrates a learning curve where the engineers are familiarising themselves with the tool before presenting any concepts of the car design in relation to its aero performance. Looking at the CAD related communications, it appears that there is a slight increase in the rate of communication as the project progresses. This may indicate the increasing importance of the CAD work with respect to other record types. Although not conclusive, this graph provides some indications that communication related to its record type has the potential to give insights into the state of a project.  Figure 22 shows the typical length in terms of number of replies (analogous to e-mail thread length) for the various purposes of communications used within PartBook as well as showing the average number of people involved in these communications. The box plots show that there are distinct di↵erences in the distributions between the various purposes. For example, idea shows a high number of responses whilst action comprises very few. The box plots of Decision and confirmation have similar distributions in which the majority of the communications contain a low number of replies but they also have a strong positive skew (indicated by the top whisker) showing that there are a minority of responses in the region of 10-15. This is potentially indicative of a bi-modal distribution may indicate whether engineers are in early agreement upon particular subjects or whether it is a possible area of uncertainty. It is also interesting to note that 80% of the purposes had an average number of participants being greater than two indicating the collaborative nature of Engineering Design Communications. Figure 23 shows changes in the instances of various purposes of communication across the duration of the study. Firstly, di↵erences can be seen between the various purposes of communication and that the occurrences of some appear to coincide with events in the project schedule. Thus, it presents the opportunity for trends to be identified that could be of potential use to engineering project management in understanding how the project is developing and further confirms past research showing that this may be the case [24]. There is a high-level of idea generation at the conceptual design phase and the number of instances drop considerably as the project reaches the design freeze milestone. This could indicate the convergence of a   Noting that there is a likely association between the two features, if one were to have a number of these events, it may be possible to associate the outcome of the design freeze to the trend observed in idea generation. Therefore, the trend in the instances of idea generation before the design freeze meeting could provide a useful indicator to the likely outcome. Engineering project management could use such information to provide intervention when required. One example may be altering the dates of review meetings to better coincide with the completion of work. Figure 23 shows the occurrence of particular purposes of communication throughout the 11 week period, which also highlights the key stages of the projects design process. Two peaks can be seen in the instances of information request and both occur early on in each phase. A potential explanation for this is that at the beginning of the conceptual design phase, the engineers firstly seek to understand the problem that they face and then seek information in an attempt to solve it. This can be also said for the detailed design phase although the problem is now greatly constrained. It is also unsurprising to see that decisions rise in conjunction with the arrival of the design freeze although it is confirmation that rises with the technical report hand-in. It is argued that this is because the technical report hand-in is part of the individual assessment of the engineers and therefore confirmation is the most suited purpose of communication as the project leaders wish to ensure that everyone is ready to hand them in. In contrast to considering the overall project status, Figures 24 & 25 show the potential for di↵erentiating engineers within an engineering project based upon their communications in relation to purpose, response types and against the engineering record that the communication is related. Looking at Figure 24, it can be seen that both engineer 1 & 2 generate the most information requests whilst engineers 3 & 4 start the most discussions. Then there are engineers 2, 3 & 4 who have presented the greatest number of ideas. It is di cult to draw any conclusions from this directly, although it is contended that this may relate to the role, personality, expertise and/or capability of the engineers involved. The key point is that one engineer can be di↵erentiated from another based on these dimensions. The same is true for the types of reply an engineer makes. For example, where engineer 9 can be seen to make many opinion based statements independent of the purpose the communication, whilst engineer 1 makes opinion statements to information requests and discussion statements in discussion communications rather than opinion statements.  Figure 25 provides a bipartite graph that relates the engineers to the engineering records with the weighted edges that represent the number of communications with respect to the engineer and record. For example, an engineer creates and/or responds to five CAD related communication and thus, would have an edge weight to CAD of five. The figure clearly demonstrates that there are key members for each type of artefact. Engineer 20 is highly associated with CAD, for example. This is the same for engineer 10 and Sponsorship. Engineer 11 is highly-related to both CFD and Aero Design. Such a view on the engineering project has the potential to highlight the knowledgeable/key influential engineers on the various facets of the project. It can also distinguish potential integrators or engineers with a wider breadth of knowledge such as engineer 24 & 13. Such information could be used to automatically assess engineers' skill sets, enable appropriate engineering work to be sent to the right engineers and as a monitor of collaboration activities between various departments.

Conclusion
This paper has highlighted the importance of Engineering Design Communication in relation to almost all facets of the Engineering Design process and in particular engineering work, artefacts and project management. Yet, there is a significant lack of prescriptive research that looks to support Engineering Design Communication, which is required if one is to move on from the current plateau of understanding.
To address this, this paper presents results from a prescriptive study that supported Engineering Design Communication through the creation of a bespoke Social Media tool known as PartBook. PartBook instantiates the Social Media framework for supporting Engineering Design Communication proposed in previous research [35]. The purpose of the study was two-fold: 1) to validate the requirements that underpin the SM Framework and 2) evaluate the Social Media tool in terms of its potential impact in relation to engineering work, artefacts and project management. Of the twenty requirements proposed by Gopsill et al. [35], eight requirements have been validated, ten partially validated and two had insu cient data to be validated from the results gathered. In addition, four potential amendments and 1 additional requirement were established. In addition, four key insights from the analysis are highlighted: 1. The positive feedback for having the ability to have multi-threaded communications with 62% of the communication using the feature. 2. The significant use of images to aid understanding of the statements being made despite the usability issues present within the tool (30% of replies contained an image). 3. The importance of enabling engineers to use their own engineering social knowledge to identify the right engineers for a communication with 76% using the feature at least once. 4. The relative completeness of the tags used to describe the evolution of the communication. Where: • 60% of communications used the original purpose types • 88% of communications used the original response types • 95% of communications used the original conclusion types In addition, five key insights have been arisen from the evaluation of the study:  This appendix contains Table 12, which contains the questions asked in the questionnaires used during the Formula Student Study.

PartBook Questionnaire
PartBook was easy to use Lickert Scale (1-9) The purpose tag helped me understand what the engineer wanted from the communication.
Lickert Scale (1-9) The response tags helped me understand the statements being made within the communications.
Lickert Scale (1-9) The conclusion tag helped me understand the outcome of the communication.
Lickert Scale (1-9) The initial set of purpose/response & conclusion tags were complete Lickert Scale (1-9) The character limit helped focus the discussion on the topic of interest.
Lickert Scale (1-9) The character limit should be Select From : decrease, increase, not exist The uploading of an image helped me frame the question I was asking.
Lickert Scale (1-9) The artefact tag helped identify what the image was when creating the communication.
Lickert Scale (1-9) The focus tag helped identify the key point of the image when creating the communication.
Lickert Scale (1-9) The images helped me search and retrieve communications in PartBook.
Lickert Scale (1-9) Please explain how/how not the use of images was useful to you.
Free Text The multi-threaded feature helped the team to express di↵erent perspectives.
Lickert Scale (1-9) Please explain: Free Text The communications on PartBook made me more aware of what was happening within the project and the progress being made Lickert Scale (1-9) I took part in communications that I would otherwise not have known about Lickert Scale (1-9) There were communications that could only have occurred easily within PartBook when compared to E-Mail