By Roman Dubinskiy (rvdubinskiy@edu.hse.ru)
Software development and product design are dynamic areas whose development never stops. A key factor in the success of the project is the qualitatively identified functional and non—functional requirements. In most cases, this process is accompanied by a pile of documentation, infinitely long meetings and clashes between stakeholders due to misunderstandings. Fortunately, methodologies for creating and developing products do not get tired of appearing, and methods for identifying requirements are being modernized. Now the concept of Design Sprints, developed and popularized by Google Ventures in 2010 [1], is actively spreading.
Design Sprints is a five—day (and in the new version, a four-day [2]) working session that helps the team clarify the vision of a product or a separate feature, create a prototype and test it on users. After the tests, the team draws conclusions — whether it is worth continuing to work on the idea or not, formulates requirements, plans a backlog, deadlines and gets to work.
The ways of using such a method as a method of collecting requirements in business and startups are quite clear. But there are still many questions regarding the use of this method in academic projects. Namely, in what situations should design sprints be used in the work on an academic project, and when their use may not bring the expected results? This paper examines the use of design sprints as a method of collecting requirements in academic projects and explains in which cases it is impractical to do so.
Design sprints were created within the company and are actively used in the business and startup context. Before analyzing in more detail the specifics of design sprints in academic projects, it is necessary to say how the task of identifying requirements in academic projects is being solved now.
There are some types of academic projects: scientific research, applied projects (coursework or as part of an educational course) and laboratory projects. It is clear that other types of projects may appear in reality, but this is enough to simplify the comparison.
The identification of requirements in academic projects plays an important role, as it helps to determine what exactly should be achieved within the framework of the research or educational process. Traditional methods of identifying requirements in academic projects include the following approaches:
Traditional methods of identifying requirements in academic projects may vary depending on the specific field and type of project.
Design sprints are a modern framework for identifying requirements. Recently, it has been gaining popularity, and some experts note that the method is capable of:
As previously noted, academic projects can fairly be divided into several types, since each of them has its own format and requirements. For experts, academic projects aimed at scientific research are of the greatest interest, since there are most intersections with how businesses and companies approach the use of the framework. Let me show what experts think about using this method on the example of scientific research.
Some experts arguing that using Design Sprints in scientific research will not lead to anything significant. For example, Jack O'Donoghue [5] and Kevin Richard [6] consider Design Sprints are not suitable for all types of problems and may not be appropriate for small problems or problems that require significant research. Another words they say that using Design Sprints in research carries more negative, than positive result because of lack of focus, limited scope or lack of research. Other experts, on the contrary, argue that Design Sprints can be a relevant research method in scientific research work. The process can help gain a deep understanding of the problem context, needs, motivations, and pains of the users. For example, Danielle Jake-Schoffman and Megan McVay in “Using the Design Sprint process to enhance and accelerate behavioral medicine progress: a case study and guidance“ [7] examined in detail the advantages of using Design Sprints in scientific work. They also noted that the Design Sprint could be used by behavioral medicine researchers for the development of research tools, implementation strategies, and behavior change interventions. The process may encourage creative and focused thinking, speed product development, and facilitate early user input. This arguments are absolutely matched with philosophy of Design Sprints methodology.
Anyway, in my opinion, the use of Design Sprints should be dictated by context. Projects are different: some require study, focus on users, are strictly time-limited and require cross-functional teams, and some, on the contrary, carry pre-defined requirements and exclusively educational message. For example, if we consider a study on the topic of identifying vulnerabilities in a specific software system to improve its security, then the main task is to effectively analyze the software, identify vulnerabilities and develop risk mitigation strategies. With the full involvement of the team in the workflow, it is enough to realistically identify the problem, come up with a quick solution, create a prototype solution and test hypotheses. Based on the data obtained, draw conclusions and make a decision. But if we consider the laboratory work on algorithms and data structures, in which the result is predetermined in advance and the main task is to obtain it, task is not user-centred. It becomes clear that there is no point in using the Design Sprints methodology.
Therefore, it can be concluded that not all projects make sense to use Design Sprint. Even in the context of research projects, there are nuances of use. However, the use of the framework remains possible and is quite capable of bringing impressive results. According to the philosophy of the method, the project should have some attributes, for example, have a small number of stakeholders, time-limited, user-centred and include at least a few team members [8].
To sum up, I would like to note that the Design Sprints method is gaining popularity and is beginning to be used more actively in various fields, including academic projects. However, it is important to consider that Design Sprints may not be suitable for an academic project. Due to the fact that the methodology sets its own limits and limitations, in projects that require deep research or projects with pre-defined requirements, there is no point in using Design Sprints, moreover, traditional methods can show greater efficiency.
The decision to apply Design sprints in academic projects should be based on the specifics of a particular project. Thus, it can be concluded that in my point of view Design Sprints are better suited for projects focused on innovation and improvement of user products than for projects focused on basic research or the creation of complex technologies.