2.1. Hackathon Events

A hackathon is a short-term collaborative event that typically spans 24-48 hours, during which small groups, on average composed of 4 to 5 members, work continuously on a project, usually software in nature (Reference BriscoeBriscoe, 2014). The hackathon format is often also adopted into other hackathon-like events (e.g., 2-day curricular hackathons (Reference Rennick, Litster, Hulls and HurstRennick etal., 2023)) and shares similarities with other short-term competitions (e.g., entrepreneurial pitch competitions (Reference Watson, Gowan and CunninghamWatson etal., 2018)). Hackathons and hackathon-like events tend to vary based on many factors, including participant demographics (e.g., hackathons targeted at novices), expected outcomes (e.g., workbooks to capture process instead of a product), aims (e.g., design learning in curricular hackathons, innovation in organizational contexts), modality (e.g., in-person versus online hackathons, which rose in popularity during the COVID-19 pandemic), duration (e.g., participants may work over an extended period rather than overnight), and host (e.g., academic or community-based) (Falk Olesen & Reference Olesen and HalskovHalskov, 2020). While these formats may alter some elements of hackathons, the spirit of hackathons as short-term and accelerated design-centered events remains. In this work, we focus on tech-oriented hackathons that attract a primarily young audience and follow the traditional hackathon format of continuous collaborative design sprints over a few days.

2.2. Design Activity at Hackathons

In a previous systematic review of the literature, we surveyed studies on hackathons and abstracted a high-level description of how design unfolds at these events, identifying a pattern of design behaviour at hackathons that follows the Double Diamond design process (Reference Flus and HurstFlus & Hurst, 2021a). The hackathon design process begins with team formation and identification of a project topic. Then, hackers work to define the problem and establish a plan within their team. The next phase involves developing the solution, followed by rounds of evaluation and testing. Hackathons end with a pitch competition in which teams present their projects to a panel of judges in hopes of winning financial or in-kind prizes (Reference Flus, Litster and OlechowskiFlus etal., 2025). While these activities are not necessarily unique to hackathons (e.g., developing a design and presenting it to a client is necessary in most design projects), the hackathon format, especially the highly restricted time frame and competition, introduces constraints on design processes and decision-making (Reference Flus and HurstFlus & Hurst, 2021b; Reference Olesen, Hansen and HalskovOlesen etal., 2018). The high attendance of hackathon participants across numerous events provides new authentic data sources to capture design activity and support powerful design research beyond the hackathon context (Falk Olesen & Reference Olesen and HalskovHalskov, 2020), for example, investigating how design processes are adapted under tight deadlines.

2.3. Collaboration in Hackathon Teams

Hackathon participants typically work in multidisciplinary teams. While team composition varies across events and reflects the type of hackathon (e.g., hardware versus software solutions), most hackathons are software-focused and teams typically comprise front-end and back-end developers, designers, and those with business knowledge (e.g., see team composition in Reference Ferraz and GamaFerraz and Gama (2019)). A multidisciplinary team composition such as this requires the integration of knowledge from multiple disciplines to contribute to a common goal (Reference BronsteinBronstein, 2003). Diversity of knowledge and perspective have been shown to be indicators of team success (Reference Jehn, Northcraft and NealeJehn etal., 1999). In fact, team size and composition, including skills diversity and alignment, impact the likelihood of a project’s continuation after the hackathon (Reference Nolte, Chounta and HerbslebNolte etal., 2020).

The interdisciplinary composition of hackathon teams could be a critical aid in the development of a promising idea into a product within the short hackathon timeline. Yet, while interdisciplinarity advantages teams with a diversity of knowledge, it presents additional barriers to collaboration. Differences in attitude, communication, structures, and norms are greater when the collaborators do not share a “home” discipline (Reference Pellmar and EisenbergPellmar, Eisenberg, et al., 2000). Therefore, it becomes more challenging to develop shared mental models and overcome differences in personal and professional norms, both necessary conditions for successful collaboration. Such barriers are likely to contribute to conflct within a team and negatively affect team performance.

2.4. Study Objectives

As hackathons continue to grow in popularity, there have been efforts to grow their appeal beyond the traditional software/tech audience, broadening their scope to other knowledge/settings and mak-ing participation more inclusive of participants with diverse backgrounds and experiences, including design. Design expertise informs effective design processes, which, in turn, may positively impact hackathon outcomes; yet, participants with design experience have not been the traditional audience for tech-centered hackathons, and their role remains understudied. The research presented in this paper is motivated by an interest in understanding the designer role at hackathons and their experience of design as hackathon attendees. Design is a social process (Reference BucciarelliBucciarelli, 1994), and the role of the designer is dependent on their relation to the rest of the hackathon team. Therefore, we anticipate uncovering find-ings related to how designers negotiate role responsibilities within the social dynamics of their teams (Reference Liu and HindsLiu & Hinds, 2012). Specifically, our study seeks answers to the following research questions (RQs):

RQ1: How is the designer role defined in hackathon teams?

RQ2: How do designers experience collaboration in hackathon teams?

3.1. Participant Recruitment

The interviews analyzed in this study were conducted as part of a larger study exploring design processes at hackathons. Some earlier findings from the study were reported in Reference Flus and HurstFlus and Hurst (2021b). The study received institutional research ethics approval (University of Waterloo ORE #42385) and recruited a diverse mix of participants who assumed various roles in their hackathon teams, including designers, front- and back-end developers, and business leads. Recruitment was open to any person who had participated in at least one hackathon, taking a “big net” approach to learning about experiences at different hackathons from participants in different disciplines. Participants were recruited via social media posts and networking channels, as well as through snowball sampling.

In total, ten of the 16 interview participants acted in the designer role in their hackathon teams and comprise this study’s sample. Table 1 presents their demographics and some details about hackathons attended and assumed role. While recruitment was not limited to a specifc type of hackathon (e.g., software, hardware, design), all participants spoke to experiences at software hackathons that followed a more traditional hackathon format (24-72 hours, overnight, competitive, etc.).

4.1. Hackathon Roles and Designer Responsibilities

Since hackathons are collaborative events, team formation and task delegation are critical activities at the beginning of the events. Five of the study participants described prioritizing team formation based on skill diversity. They recognized a need for expertise - “the first step is to have people in your team with essential skills” (P9) - and would specify the skills they needed to complement their skills: “I [was] looking for a front-end developer, back-end developer, and a database person” (P2). Following such a process enabled building hackathon teams with diverse knowledge, skills and experience, which they deemed beneficial: “If there are teammates with different expertise, it is easier to delegate tasks and have all the tools necessary to finish the project” (P4). Team members’ skillsets mapped to the responsibilities they assumed in their teams. While few study participants reported that their hackathon team identified formal roles, three prominent roles emerged from the interviews: developer, designer, and business analyst, and every participant in this research study self-identified as their team’s designer. In hackathon teams of four, it is typical to have two developers (front-end and back-end), one designer, and one business analyst, although the exact composition greatly depends on the expertise of team members. Despite this role differentiation, participants reported that collaboration extended beyond task coordination. For example, in P8’s team, those with more advanced and relevant skills in software development completed the majority of coding, but when needed, P8 (the designer) “would often step into [the role of developer] and support the process in that way.”

Figure 1. Example of coding process of two excerpts into one theme

The developer role involved writing code for software projects and was typically split, such that “a few people handled the front-end while a few others did the back end” (P7). The business role championed the pitch, understanding of the market and “[developed] the business plan of [our] money making strategy” (P2). This work situated the project in a greater social context, which sponsors and judges often appreciated. Designers in hackathon teams validated the problem, informed the aesthetics of the build, and considered how users may experience and interact with their designed solution. Study participants had different experiences designing, and thus different understandings of “design.” For example, for P4, who has an interdisciplinary background and worked as both a visual and UX designer in industry, “design means a variety of things. It can be design thinking, visual design, graphic design, user interface design, ...[user experience] design.”

We classified two emergent descriptions of design and the designer role from the interviews. The first interpretation of design operationalizes design as art, pertaining to the project’s aesthetics - the “visual aspects and not the software” (P9). P9 was the user-interface designer in their hackathon team, responsible for creating the wireframes of the user interface using Figma, a prototyping tool. The second interpretation considers design as a process. P3, designated as the user-experience designer on their hackathon teams, offered this overview of design work:

The designers on hackathon teams whose work aligns with the latter definition of design were responsible for problem validation and user research, among other design activities. P2 works as a designer for a software engineering firm, so has a strong understanding of how designers and developers collaborate in industry. While their hackathon duties included aesthetic design tasks, such as drafting wireframes on Figma, they also expressed how their primary responsibility was to facilitate problem formulation and user verification tasks with their team, emphasizing the need to contextualize their hackathon projects with real-world examples and users:

To validate their work with users, P2 consulted subject matter experts who attended hackathons as sponsors. Similarly, P8 attended a workshop offered by their target users, asking questions like “what can I learn about specific users in this space and how they actually use this product” to “inform both the design and the development work.”

Since hackathons typically run overnight, it is unrealistic to have access to potential users at all hours. Instead, P4 led their team through a series of activities to capture user experience, mainly persona development and user journey mapping. They emphasized that despite not being able to meet with users, they still sought to develop user empathy:

Instead of using design methods in place of speaking with users, P6’s team chose a project topic for which their team comprised part of the target population: users of Fitbit (wearable fitness devices). Therefore, they were able to conduct user validation internally.

Despite the limitations imposed by the timeline of hackathons, teams still engaged in research into the design problem, albeit to varying extents. P7 detailed perhaps the most comprehensive research process, going so far as to add “researcher” as a descriptor of their role in hackathon teams. They viewed their main responsibility as limiting false or biased assumptions they and their teammates could make:

Participants lamented their inability to complete comprehensive research to their satisfaction; the format of the hackathon events placed pressure to “build a product to show the judges...so we don’t have enough people or time to continue research” (P13). While designers pushed for extended periods of research, they recognized the need to expedite the process:

As a result, research was often limited to the beginning phases of the design process when researching a problem and during the ideation process to identify a solution. Once building began, research ended.

4.2. The Perception of Design Work at Hackathons

Participants noted that differences in background knowledge, while bringing diverse skills, often led to disagreements in the hackathon teams, especially between developers and designers. Developers tended to prioritize coding over thorough problem formulation, validation, and research, requiring designers to advocate for following design processes. For example, when P4 expressed an interest in completing user experience research activities, they were met with resistance from the developers on their team: “It was really tough convincing the developers on the importance of doing the persona mappings because they just wanted to start building.” P4 was not alone in this experience. P8 wished for two rounds of ideation to narrow down the project scope but was only able to complete one round because the developers were eager to begin coding: “Developers, as soon as they know roughly what the idea is, want to start developing and building out the system . . . they would start building the functionality of the project but in the absence of any information” (P8).

P2 reported a similar experience to P4 and P8, but detailed how the hesitancy from their teammates to engage in design activities created a hostile team environment. As the designer on their teams, P2 felt their skills were often overlooked in favour of the technical skills of developers. They reported frequently observing the developers “go[ing] in the corner [away from the rest of the team] to build the thing” without verifying if the solution met the problem specifcations. Refecting on this experience, P2 said,

Due to this experience, P2 felt hackathons were not accessible to those with “soft skills” and as a result, are “missing a lot of really valuable voices, like true interdisciplinary collaboration” (P2). Other study participants expressed that there is a “preconceived notion that in order to be a useful member [at a hackathon], you must write code” (P4), which is a skill designers may lack. The origin of hackathons as tech-centric events targeted to software developers has created an environment where designers feel disconnected and unwelcome: “I think for most people, a hackathon implies the attendee must be a developer, but meanwhile, hackathons actually need a much broader set of skills” (P3). This difference in approaches - building quickly at the beginning of the event versus dedicating time to thoroughly understanding the problem to inform the development - led to tension within the hackathon teams. Participants reported three methods of resolving arising conflict. First, teams had honest conversations to share the reasoning for approaches and reach a compromise:

Second, teams identified a member who had interdisciplinary expertise to act in a mediator role, aiding in the communication between team members with different knowledge bases:

Finally, participants reported working independently to explore the beginning phases of the design process to the extent they wished while other team members began the building of the project:

P2, P4, and P8 recounted having to explain to their teammates the importance of design work; although only P4 and P8 reported their teams successfully recognizing the value of design:

As such, hackathon participants, even those who are not designers, likely understand the importance of conducting a complete design process, but have to limit the extent to which they dedicate resources to design activities due to constraints of the event. Collaboration at hackathons requires teams to communicate effectively but is made more difficult by the diversity in background knowledge and short duration of the event, which restricts the time available to establish group norms and effective working relationships.

5.1. Adapting User-Centered Design under Hackathon Constraints

In other design contexts, teams may rely on models such as the Double Diamond Design Process and user-centered design methods (Reference Hanington and MartinHanington & Martin, 2019) in their design process. However, our interview participants emphasized that the nature of hackathon events limited their ability to thoroughly engage in user validation and research activities, key steps in most design processes. In design, and particularly in user-centered design, the involvement of the user is critical. Designers are often encouraged to design with the user, rather than for the user, as a form of “co-creation” (Reference Sanders and StappersSanders & Stappers, 2008). At hackathons, however, the ability to consult with prospective users is limited and decisions are more likely to be driven by second-hand experiences of team members (Reference Falk, Frauenberger and KannabiranFalk etal., 2022). Within hackathon constraints, designers in our study used various techniques to incorporate user perspectives, such as consulting experts present at the hackathon, sending surveys, building personas, and role-playing as users. Each method had trade-offs and was subject to personal biases.

The first strategy, consulting subject-matter experts, helped teams identify problems from event sponsors. While stakeholder interviews are a common and useful user research method in design, hackathon time constraints likely limited their depth and sponsor input alone cannot replace insights obtained from conducting user interviews. The second strategy, user surveys, is also common in design. Questionnaires are a primary tool for collecting user information, however, verbal responses can be limited in depth, therefore, survey methods are often complemented by other research methods (Reference Hanington and MartinHanington & Martin, 2019). Due to the time limit at hackathons, the teams received fewer survey responses than preferred in practice, and it was the only method employed. The third strategy identified, user personas, is effective in framing the problem and solution for the user (Reference Hanington and MartinHanington & Martin, 2019) but is dependent on the knowledge of the team generating the personas; therefore, the maps are limited by what the team knows and their personal standpoints. Finally, the strategy of defining a problem such that the team acts as the user means the user is readily available, but the findings may be significantly biased. Personal bias is often difficult to identify and can have a large impact on the results.

While not ideal, employing alternative methods for incorporating user perspectives to inform major design decisions was an approach used by designers at hackathons to overcome the challenge of limited access to users. The ways in which the strategies were adapted demonstrate how the responsibilities of designers at hackathons align with those of designers in other contexts, but the nature of the events impose additional limitations that require flexibility.

5.2. Developer-Designer Tensions

The interviews revealed that hackathon participants actively establish teams with members who have a diverse set of skills. Much research positions interdisciplinarity as advantageous to collaboration, describing how a diversity of knowledge and skills increases team performance (Reference Jehn, Northcraft and NealeJehn etal., 1999). While an interdisciplinary team composition offers performance benefits, participants described a tension between designers and developers arising from disagreements pertaining to how to complete the task, a type of conflict often studied in design research (Reference Hanington and MartinJehn, 1997): developers wanted to begin their (coding) work immediately, but designers felt it was important to answer some key questions prior to beginning development. These two conflicting approaches may have been driven by differences in their training; that is, developers were drawing from their computer programming backgrounds and wished to begin coding, whereas designer team members prioritized understanding the problem, determining constraints, and solution ideation and iteration, among other typical design activities, with the intention of validating a problem and determining an impactful solution.

Unproductive conflicts, such as the tension described by P2 which made them feel unwelcome in their team, are detrimental to successful collaboration and could possibly hold a greater impact at hackathons when teams have less time and resources to dedicate to conflict resolution and as such, tensions may be “glossed over” (Reference Falk, Frauenberger and KannabiranFalk etal., 2022). Recent research on conflict in hackathon teams found one team experienced predominately task conflict (Reference Attai, Flus and OlechowskiAttai etal., 2024), defined as disagreements about the job at hand. Task conflict has been shown to encourage a consideration of alternatives and well-informed design decision (Reference JehnJehn, 1997), a phenomenon akin to introducing a “devil’s advocate” in a team. The conflict reported by our study participants, however, suggests the difference in opinions extended beyond what the team should do, or even how to do it, to a point where the designers may feel unwelcome in their teams. This fnding suggests more supports are needed in interdisciplinary teams to support knowledge translation and effective teaming. Therefore, hackathon teams are urged to employ resolution strategies before conflict related to a task escalates to interpersonal conflict.

The interview participants described what Reference Pellmar and EisenbergPellmar, Eisenberg, et al. (2000) define as intellectual turf, meaning pride in one’s discipline causes one to view another discipline as less important. To effectively work together, team members must understand and appreciate the value others provide. The developer-designer tension may indicate a larger issue in collaboration at hackathons: mainly, an undervaluing of design work. Interview participants expressed that coding - not design - is the primary activity at hackathons and many expressed feeling unwelcome as designers due to their lack of coding knowledge and the team’s perception that a valuable hackathon team member should be able to code. This posed an additional challenge of explaining to developers in their teams the need for their design contributions. Some interview participants expressed great frustration regarding this phenomenon, and a few said they would be reluctant to attend another hackathon because developers made them feel insignificant. As hackathons become more popular, their attendees become more diverse. While hackathons are no longer solely targeted at software engineers, our findings suggest old attitudes stemming from a perceived superiority of software engineering at hackathons may still persist and may be negatively affecting designers at these events. Design is a central activity at hackathons (Reference Falk, Frauenberger and KannabiranFalk etal., 2022; Flus & Reference Flus and HurstHurst, 2021a; Reference Olesen, Hansen and HalskovOlesen etal., 2018), affirming the role of designers on hackathon teams. However, their role in this context may differ from that of designers in other, more traditional design settings. As discussed in Section 5.1, design activities are adapted to the time-limited nature of hackathon events. Perhaps, then, to collaborate effectively in hackathon teams, designers may need to adjust their process to prioritize early development, expand their skills beyond facilitation, or seek alternative hackathon-inspired events that are targeted to designers, such as design-a-thons (Reference Artiles and WallaceArtiles & Wallace, 2013; Reference Goudswaard, Kent, Giunta, Gopsill, Snider, Valjak, Christensen, Felton and RealGoudswaard etal., 2022) or entrepreneurial idea pitches (Reference Watson, Gowan and CunninghamWatson etal., 2018).

Communication between team members and the ability to understand project directions while navigating differences in opinions is not a new challenge in teamwork. However, it can be argued that the hackathon environment places more pressure on participants, resulting in higher levels of stress and fatigue, contributing to increased sources of conflict between members. The uncovering of the developer-designer tension in hackathon teams is a novel contribution and invites future work on extending strategies from design teams to the hackathon context.

5.3. Limitations and Future Work

Our findings were based on ten participants who, while collectively had participated in 41 hackathons, likely do not fully represent the entire hackathon population. Further, the research team in this study has a diverse background in design, engineering, and organizational science, among other domains. Such a background shapes perspectives and influences decisions in the research process, including the interpretation of results. However, asReference Nickel, Hurst and Duimering Nickel etal. (2024) recently argue, the goal of qualitative research is “not to obtain conclusive evidence to support claims that become more robust with a larger sample size”, but rather to “[identify] relevant new themes and factors, or clarifying relationships between variables that were not previously recognized or sufficiently investigated”. In our case, the results suggest a pattern of relationships between designers and developers in hackathon teams that can be the focus of future studies. As hackathons become increasingly popular, there are more opportunities to conduct design research in this setting, particularly to explore different dimensions of teamwork, for example how conflict emerges in interdisciplinary, high-pressure project experiences.