Design in the academic context

Many of the projects we spoke to either are housed within academic institutions, funded by academic institutions, or their maintainers were trained in academic institutions. Academic norms, pressures, challenges, and benefits are deeply embedded in SROSS projects. As discussed in the Open Source and Open Science chapter, academia as a container for science, knowledge production, and the scientific method can be supported and furthered by Open Source practices. It can also present challenges to openness. This chapter explores further how academia’s structures and culture impacts maintenance and design work within the projects we studied.

Academic bureaucracy and norms can impede work, especially design work or projects that rely upon community- or user-driven processes.

One project we interviewed defines itself as a citizen science project, has an ethos of collaboration with its patient-users, and practices user-led prioritization and design within its maintenance structure. They shared that working within academic institutions can be limiting because of the liability and legal requirements around doing research with human participants, like IRB processes. These hurdles introduce more complexity to their work, to the point that there’s “this discrepancy between what you’re supposed to fill out in terms of paperwork to make sure people are treated properly and what you actually want to do” to ensure the community is driving the project. This manifests as timeline interruptions on a significant scale: “we make this prototype, and then you need to go back to the ethics review and say, ‘Okay, now we want to modify our protocol, because the community gave us this feedback.’ If you’re lucky it takes six weeks to get a thumbs up, or to be met with more questions.” For projects practicing human-centered design within academic contexts, these delays could become prohibitive.

Similar structural challenges make it difficult to bring design expertise into projects. Multiple participants shared that academic grants often do not provide a framework for bringing in design professionals. One shared that “people will look at you funny” if you try to contract a designer with your academic grant. One designer we spoke to shared that the concept is so foreign that they often must “find the backdoor” and be officially listed as a researcher to be hired onto projects that want their services.

While the academic bureaucracy makes it difficult for design to be officially recognized and contracted for, participants identified a real opportunity for designers to help academia do its work better by providing strategic design of research practices and programs.

Some participants encouraged that from helping researchers understand the “users” of their outputs to full service design of OSPOs, designers are needed within academic institutions. We were told that “design is super challenging to researchers, because they get in their head a problem, and they often have the solution already in it. Stepping back and going back to the basics of design means they have to completely undo all their assumptions in their structures.” In other words, this participant articulated that design is a way for researchers, who may be caught within the cultural and bureaucratic thorns of academia, to disentangle their work from structures that aren’t serving them, their projects, or the science, and start to build programs and projects from a more strategic and integrated perspective.

One place that design does appear to be happening in academic contexts is in student work.

There is a connection between student interest and university emphasis on industry-preparedness that opens the door for design with students. Participants active in Open Source Program Offices at universities provided a critical insight into how design and open practices are incentivized, adopted, and grown within these contexts.

Design is more of a norm and more an integral part of software builds outside of academia & OSS – in other words, in industry, design practices are standard. At the same time, universities are interested in their students succeeding after graduation, often in the form of industry-readiness post graduation. Incorporating design practice into student work builds professional competency. One participant noted that there’s a tension between career researchers as professors and job-focused students: “students’ main goal is to walk out with something they can get hired with. They’re really focused on the applied aspects of that. And the researchers are not in that world. They’re not up to date on the most common practices, because they don’t need to be.”

Two of our respondents shed light on how that tension is being addressed to the benefit of both students and universities. They were the founding team members of their University’s Open Source Software Center, which started less than a year ago, in July 2022. It is a club/organization where graduate students lead open source projects. While it started informally, with a professor leading it, it has already grown to have a VP, secretary, logo, and trademarks — with high demand. The idea came from a desire to give undergraduate computer science students a practical use for their capstone projects, while providing them with some more industry-like experience. That experience includes practicing more “typical” design work: usability tests, prototyping, etc. The students offer their services to science professors who need help building their research tools, and all of the projects are open source. Everyone wins: the scientists get help with their tools, the students get a practical and fulfilling use for their work with real users and “clients” to work with, and, as a participant in our research said, they are “giving back to the open source community.”