The purpose of this study was to investigate the design processes of a collaborative design team at a local software engineering firm. Specifically, we observe the interactions between an expert and a novice designer during design meetings as a means of exploring how they navigate designing a cloud-based tool they envisioned while in a software designer mentor-protégé relationship. The research question we attempt to answer is “How do software engineers interact when designing a software application, when their expertise levels vary?”

We find that our approach to this project is interpretivist which is derived from an ontological belief that reality is socially constructed and cannot be separated from the mind of the individual [34]. The interpretivist tradition also acknowledges that these individually constructed realities are also socially constructed as these perspectives interact with the language and thought of the wider society. These ideas align with our purpose for conducting this study as we use naturalistic data collection methods typically used within the interpretivist tradition to access the perspective of several members of the social group (i.e. design team) and understand common patterns and themes of thought and action for that group [34].

According to Yin [35], a case study design should be considered when: 1) the focus of the study is to answer “how” and “why” questions; 2) you cannot manipulate the behavior of those involved in the study; 3) you want to cover contextual conditions; or 4) the boundaries are not clear between the phenomenon and context [36]. Furthermore, Yin asserts that case study design arises out of the need to understand complex social phenomenon in real-life context. Because collaborative design is a multifaceted process that is difficult to understand out of the context in which it occurs, the flexibility of a case study design seemed appropriate for our purposes [37].

Hence, a descriptive single-case study design [35] was employed in this study to provide an in-depth description of the interactions and behavior of designers during a software design meeting. The unit of analysis for this study was the interactions and conversation between the two members of the design team.

We recruited employees from web design and software engineering firms to participate in this study. Due to constrained project schedules, traveling distance, and the timeline for this project, only one company matched our scheduled work plan. This software engineering company has already begun the design of an in-house project and welcomed participation. We were not aware of the dynamics of this design team, until our first meeting for observation.

Experienced Software Designer (aka EXPERT): EXPERT is a 38-year-old male with 18 years experience at the time of this study as a software engineer. He has created and sold two startup companies and founded, Code Theory, seven years before this study took place.

Novice Software Designer (aka NOVICE): NOVICE is a 29-year-old male with 5 years experience at the time of this study as a software engineer. Most of his work experience was as a consultant.

Both have undergraduate degrees in Computer Science.

Data sources for this study included an online questionnaire, observations, and one focus group. Online informed consent forms were provided to members of the design team and participants provided an initial electronic signature and a confirmation consent code of “YES”. The same design team members who completed the online questionaire, were observed in a team meeting, and participated in a focus group. The observations and focus group were recorded via still image, audio, and video. Design team members were given a chance to confirm and/or clarify research notes via a focus group after the initial round of data analysis occurred, to confirm design practices, interactions, and procedures. The design team was also provided with a final copy of the design report. Detailed description of the procedures is provided in the following sections.

Online questionnaire. Both design team members received a pre-observation questionnaire online (hosted by Google Forms) before the observation took place to understand individual design preparation and practices before a design team meeting occurred.

Observations. An observation of one design team meeting was conducted and lasted for one hour and fifteen and a half minutes (1:15:36). This meeting took place during a business day at 1 pm within a local bakery and soup restaurant, a company tradition for meeting space since its founding. Both researchers took observation notes of the design space before the meeting started, while project design is in progress, and of the state of the design space upon completion of the design meeting. Still and video images of the design space were recorded at these time periods as well.

Focus group. A focus group of all participating and consenting design team members took place 5 days following the observation to gain more insight into individual and collective roles throughout the design process. An initial set of questions were prepared prior to starting the focus group, however, some questions emerged because of the what was observed during the design meeting as well as the responses and discussion that takes place during the focus group.

Data collected including observation notes, still images, audio, and video recorded meetings and focus group are kept confidential by the researchers. All participant and site names were converted to pseudonyms to protect the privacy of the participants.

Data analysis was based on previous work in design studies of team collaborations. Most notably, we took cues from Cross and Cross’ [38] and Kvan’s [39] work. Kvan [39] provided a solid roadmap to follow which explains what really happens when designers collaborate, Figure 6. He points to Gero and McNeil’s [40] assertion that design consists of a series of distinct events that occupy discrete and measurable periods of time, which is typically remarkably short, and that the level of expertise affects the way these events are completed. Designers work together for moments and then divide up and go their separate ways. Based on the results of this individual work, design direction and understanding may take a different turn. The occurrences of these distinct events are illustrated in Figure 6, a model of design collaboration. Moreover, Kvan [39] found that collaboration happens in multiple forms: 1) mutual collaboration, where designers are busy working with each other, 2) exclusive collaboration, in which designers work on separate parts of the problem, negotiating occasionally by asking for advice or feedback from the other, and 3) dictator collaboration, where the designers decide who is “in charge” and that person leads the process. Dictator collaboration seems to be most fitting when mentorship and design training might occur, so we attempted to use these distinctions to identify when these three types of collaboration occurred, if at all, paying attention to dictator collaboration to signal when EXPERT might be mentoring NOVICE.

Additionally, Cross and Cross [38] recorded and analyzed a three-person team design session for the following social occurrences: 1) roles and relationships (RR), 2) planning and acting (PA), 3) information gathering and sharing (IGS), 4) problem analyzing and understanding (PAU), 5) concept generation and adopting (CGA), and 6) conflict avoiding and resolving (CAR). We coded these instances within the transcription of the interaction initials specified above. We then identified which of these occurrences represented roles undertaken when EXPERT played the mentor role vs. when he played the collaborator role.

As mentioned previously, because of the exploratory nature of this study, inductive analysis of the data to determine categories and themes seemed more suitable and in line with our purpose. Data analysis began in the field as observation notes were recorded, initial analytical insights emerged, tentative interpretations and themes were generated during team discussions immediately following the observation, and hypothesis were confirmed during subsequent focus group with design team members. All data were analyzed inductively line-by-line in search for categories and themes that emerged from data [41].

Following the discussion of these initial insights and the follow-up focus group with participants, we read through the transcripts, highlighted meaning chunks, underlined some interesting terms, and jotted down memos and questions that jumped to mind while reading. A second reading of the transcript and analysis of the images captured followed this and initial codes, or what Attride-Stirling [42] refers to as basic themes, were created. These initial codes were derived from participants’ own responses and were not established prior to the analysis. Initial labels were then developed by grouping codes with similar attributes and properties together. Finally, these initial labels that together present an argument or a position within the context of the analysis and with the research questions in mind were grouped together to form the emergent themes [42]. Within each iteration, themes were compared to the actual data, which resulted in either expanding or collapsing of themes. Continued review of the literature resulted in the location of observation research done very similar to this work, which resulted in theme categories that heavily matched our emergent themes [42]. We then adopted and used these themes instead, as data analysis continued.

This design team had begun the design process of this cloud-based software application approximately 6 weeks before our observations began. They met after and during work hours, when convenient, as this project was a tool they envisioned to help their clients, and not one commissioned by clients. They had an internal deadline in mind, which coincided with the release of an Amazon software service, but only worked on it when time allowed. Both designers already had a high-level understanding of the design to date and the design meeting we observed began to flesh out more details. EXPERT already had an idea of how to implement these details, but opted to use elements of this project as a teaching tool, as we later found out in our focus group. A statement of by EXPERT supports this during our observation—“I am just guiding you. You do it and I’ll let you know what you’re doing wrong.”

Internal design projects such as this, emerged from employees and were not commissioned by a client and could therefore not be focused on during work hours or at client sites. Therefore, for projects they envisioned themselves, employees of Code Theory would often meet at a local restaurant to have their design meetings. EXPERT and NOVICE set up their laptops and worked side by side. When asked if this was their normal setup, they confirmed and referred to a common software design practice (within Agile Programming) called “pair programming”, which is a setup where two programmers work on one computer. In this case, one computer displayed design notes, while the other displayed the code in question. This side-by-side setup can be seen in the image of Figure 7.

As the design meeting progressed, the designers often moved from low-level to high-level design vocabulary as it related to the project. When discussing low-level design elements, they were writing code bits and contemplating literal command names, and when discussing high-level elements, they were thinking of how the user would interact with the tool being designed and the elegance of execution of the anticipated code.

Combining Cross and Cross’ [38] social occurrences with Kvan’s [39] distinction of design events, there were a total of 183 distinct design events observed, depicted in Table 1. Most of these events were of the type PAU: problem analyzing and understanding (84% or 46%) and 34% or 40% of the CGA events, which occurred during dictator collaboration events. These dictator collaboration events entailed EXPERT using questions to elicit more thought from NOVICE and/or wanting to understand NOVICE’s rationale about the idea or

approach he presented at the time of the design event. Some examples of these questions and elicitations include statements like the following:

“I don’t understand this.”

(repeatedlystating this while point to the object of discussion,a diagram,a piece of code,etc.)

“I don’t understand…I’m lost.I still don’t understand.”

“What is a config file here? → How does it work? →How will we use it?”

“What are the inputs and how with they [the user]issue the command?”

“But let’s start back further,how do you plan on...”

“Alright,this is too low-level,let’s back up.”

“Forget the drawing,let’s start over.”

At times, NOVICE issued a few PAU events, but this was rare—“What is confusing, this portion of the drawing or the way the drawing was created?” and some CAR: conflict avoiding and resolution events (7), such as “I thought we agreed.”—to which EXPERT responded, “Good point.” However, then NOVICE would often agree with EXPERT. But it was not clear if he was avoiding conflict or agreeing because he understood. This relates to the CGA: concept generation and adoption events. As a result of EXPERT using the dictator collaboration events as “teaching moments”, he would often ask NOVICE to close his laptop and would further explain a concept. NOVICE would indicate his understanding, as if to adopt or agree, and the design session would continue. These explanations occurred 34 times and Figure 8 illustrates those occurrences when EXPERT asked NOVICE to close his laptop and listen.

There were 19 IGS: information gathering and sharing events. Most of these were initiated by either designer who simple began searching for a programming term or practice, or referencing a concept to be reminded of from a past design drawing. Once found, they would resume the design conversation and include the found understanding in the conversation. There were 16 RR: role and relationship events, where it as clear EXPERT was “in-charge”. These events confirmed and were initiated by EXPERT’s dictator collaboration events. This initiation came from statements like the following:

“OK,what’s the command? Write it.”

“I don’t understand.Draw it out.”

Figure 9 shows different instances when both EXPERT and NOVICE draw and used boxes to illustrate, explain, and/or share a design idea.

Several (23) M: Mentor collaboration events occurred as well. These were evident from statements made by EXPERT to NOVICE, some of which are listed below:

“Design is assigning intelligence to code.”

“This is design,don’t take it personal.”

“Design is about drawing boxes,not writing code.”

“That is not the way I would do it,so let’s back up.”

“What I was looking for was….”

(referring to the way he would have preferred an answer to one of his questions)

At times NOVICE confirmed his protégé status with statements like “I feel like I’m back in school.” As a result, we introduce a new design event to the Cross and Cross’s [38] list called the Mentor design event, and a new design collaboration type called Mentoring to Kvan’s [39] Model of Design Collaboration.

It was clear that many of the design collaboration events which occurred during this design meeting indicated that EXPERT was in-charge and often directed portions of the design discussion and many design decisions as teaching or mentoring moments or caused the direction of the conversation to elicit more thought and understanding from NOVICE. Initial analysis might suggest these moments fit the description of dictator collaborative events. However, the role and actions of the designer in charge reach beyond simply controlling the activities of the collaboration. They extend instead into gestures of teaching,

nurturing, mentoring, and guiding, as stated by EXPERT during one of the collaborative events and therefore suggested in the title of this article. As such data analysis suggests a fourth collaborative event be added to Kvan’s Model of Design Collaboration and that is Mentoring. However, unlike the three types of collaborative events introduced by Kvan [39], the Mentoring relationship is optional. Therefore, we have chosen to represent it with a dotted-line at the various points in the diagram where it can occur as can be seen in Figure 10. Following from this, we also suggest a seventh potential type of collaboration be added to Cross and Cross’ [38] list of social occurrences in design and that is Mentoring (M).

In summary, design is a social and collaborative process and receives an abundance of attention from researchers to understand how it is done, what interactions support it, and how it can be optimized. As software technology becomes more and more ubiquitous, it is crucial to understand and optimize the software design process. This is especially important to inform more smooth transitions from training to become a software engineer (design, code, test) to being hired with the objective of applying the software engineering skills learned. As can be seen by the case study presented here, guiding and mentoring plays a huge role in the interactions between novice and expert software engineers. So much so, that this interaction should be distinctively present in the models and descriptions of collaborative software design events and within collaborative design

interactions more broadly. The data analysis described above provides a foundation for this addition and paves a way for more future work in this area.

As mentioned previously, due to time constraints we were only able to find one firm that had a scheduled group meeting at the time we were ready to collect data. This limitation also affected the amount of data we could collect. We were only able to conduct one observation and one focus group in addition to the data from the online questionnaire and have enough time to analyze and synthesize our findings. Finally, as is the case with case study designs, the findings and explanations reported here do not necessarily reflect the behavior and interactions of other entities even though it may be suggestive of what may be found in similar organizations and design teams.

Empirical evidence of software design teams adds to the literature on how design teams function in general. Uncovering the details of this functioning when mentoring is involved is a profound subject of exploration. We have only scratched the surface here and would like to continue observing this and other design teams from Code Theory. Our recruitment efforts for this study exposed us to many additional design companies, some who focus on web design, while others focus on animation and graphics. We would like to observe these teams as well and compare our findings. Additionally, Gero and McNeil’s [40] suggested the design events (e.g. making a design decision) may take very discrete events lasting shorts amounts of time, mere seconds, and that experts may take half as much time as a novice to conduct the same event. We would like time to compare these events in continued data analysis. Mentorship is extremely important to the culture, development, and success of individuals and the companies for which they work. It is our hope to further this exploration and contribute to their growth and achievement.