Introduction

Since year, the Spanish university system has been modified to be adapted to the European university system, as a result of the Bologna Process. This process has been developed over a series of ministerial meetings and agreements between European countries, which settled on several accords; in particular, the Lisbon Recognition Convention (Council of Europe 1997) and the Bologna Declaration (1999). The European Higher Education System (EHES) (Sorbonne Joint Declaration 1998) has been created to ensure consistency in standards and quality of higher education qualifications. It represents the starting point of a reflection process about degrees´ contents and approaches, as well as a revision of educational strategies. One of the main keys to this renewal process in Spanish universities has been the competence-based educational approach. Competence is understood as the “dynamic combination of knowledge, understanding, skills and abilities” in order to prepare “students well for their future role in society in terms of employability and citizenship” (Tuning Project n.d). The concept of competence has been adopted in many countries as an important element of reform, both in education and also in industry, from different approaches (Chappell et al. 1995). Currently, the Spanish university system defines their bachelor’s and master’s degree programmes by assigning a set of professional competences, which have to be supported by the subjects in a 1:n-to-1:n relationship (each competence has to be supported by at least one subject, and all subjects have to support at least one competence).

In this context, the University of Zaragoza launched a process for changing its offerings in the domain of computer science and it is now offering a B.Sc. in informatics and an M.Sc. in informatics. Being focused on the degree, it has a very highly technological approach from a methodological and contents point of view. It has been configured in accordance with the curriculum proposed by the Association for Computer Machinery (ACM) (Curricula 2001), providing students with the possibility of choosing one of five specialities proposed: “Computer Science”, “Computer Engineering”, “Information Systems”, “Information Technologies”, and “Software Engineering”. It is configured by 240 ECTS units (European Credit Transfer and Accumulation System (Wikipedia 2015), corresponding with 25 h of student work), with the following configuration: common subjects, 162 ECTS; specialisations 48 ECTS; elective and complementary training subjects 18 ECTS; and final project, 12 ECTS. The common subjects include two that are related to software engineering: Software Engineering (6 ECTS that provide the fundamentals of software engineering activities) and Software Projects (6 ECTS that provide an introduction to the management of the software engineering process). The specialisation in software engineering covers deep aspects such as software architectures, AGILE methodologies, testing, Web engineering, and other topics. With this approximation, all students end the bachelor’s degree with the basics of software engineering (enough for the participation in software engineering teams), while those who select the specialisation of software engineering can manage the necessary concepts for leading software engineering process.

The competence-based educational approach presents a set of abilities and skills that are difficult to teach to students, particularly soft skills (Wilhelm et al. 2002). This is especially true taking into account that their previous background is largely technological, and that the traditional educational approach in this field, which is quantitatively inclined, often lacked this kind of sensitivity (Frank et al. 2003). In the case of the B.Sc. in Informatics at the University of Zaragoza, this degree is composed of a set of 36 competences that all students have to acquire. In addition, depending on the speciality that the students select, there are eight additional complementary competences for each of the specialities. Thus, there exists some educational objectives that demand different methodologies and strategies. In particular, concerning the common subjects related to software engineering, the following issues are being identified: (1) Working in multidisciplinary teams: This goal covers the following competences: Ability to work in multidisciplinary and multilingual teams; Ability to communicate and transfer knowledge; and Ability to understand the importance of negotiation, effective work habits, leadership and communication skills in all software development environments (Unizar n.d.). The reality of the industrial sector is that multidisciplinary skills are a necessary part of attaining success, since the team achieves its aims more effectively and efficiently than individuals working alone. The need for engineering graduates capable to design across disciplines is emphasized both from academic and professional spheres (Daly et al. 2012; Tulsi and Poonia 2015). This complex educational setting requires innovate approaches to the teaching process, being especially demanding with respect to communication abilities, and to behavioral and cognitive flexibility to stablish a common ground and shared understanding with other disciplines (Daly et al. 2012; Downing 2001; Fruchter 2001; Kleinsmann and Valkenburg 2008). (2) Requirements definition based on user knowledge: This objective covers the following competences: Ability to combine general knowledge and the topic-specific skills in engineering for developing innovative and competitive ideas in their professional activity; Ability to conceive, design and develop engineering projects; Ability to solve problems and make decisions with initiative, creativity and critical reasoning; and Knowledge and application of the principles, methodologies and life cycles of software engineering (Unizar n.d.). A requirements definition based on user knowledge is a task that has a very high degree of interrelationship with people (end users and clients). For this reason, the following abilities play a key role in success: the ability to identify the problems of users and clients (ability to empathize with them, in order to view the problem from their point of view); success in human-to-human communication processes (as opposed to the human-to-machine interactions to which the students are accustomed); a critical view of these necessities and the definition of the related product functionalities; and the humanization of the software they create (in most cases, the information system has to provide a solution to real people). Nonetheless, until this point in their education, the students have experienced a high level of relevant technical training, but lack the mechanisms to put themselves in someone else’s position, or even to understand how this matter concerns them, and therefore they risk to depart from ill-defined problems (Cross 2004). This fact seriously limits their skills to develop a good professional performance responding to real user and market needs; and being particularly critical considering certain phenomena as the Technology Generation Effect, the existing gap between current generations with a very high level of technological knowledge and digitally disengaged non-users (Batchelor and Bobrowicz 2014; Lim 2010). In other universities, this lack of knowledge has been tried to be solved for many years by developing specific master studies with high level of presence of Usability Engineering and User-Centered Design (Granollers et al. 2008). Nevertheless, this approach forces students to develop a specific master that over-qualify them.

In short, we are actually faced with a communication problem, either inside team members or between developers and the end-users and clients. And, as Brooks (1995) states, even a project having all of the prerequisites for success (e.g., a clear mission, manpower, materials, time and adequate technology), could fail as a Tower of Babel. It is in this context that professors and researchers from the Informatics Engineering and Industrial Design Engineering fields have decided to share and to integrate their experiences. From one perspective, the team coming from Industrial Design Engineering provided a high level of experience working with end-users in the identification and classification of their needs and in their translation into product requirements. They also lend a wide experience working with and coordinating multidisciplinary projects, leading a high percentage of developers in their teams. On the other side, the team coming from Informatics Engineering has had significant experience in the specification of software architectures and in the application of software engineering best practices. They had also the responsibility of teaching software engineering principles to the Informatics Engineering students. Identifying a lack in the most general software engineering approaches for improving the capacities of students, the authors decided to face this problem trying to find an answer through a shared collaboration between disciplines. In other words, taking as a starting point a Tower of Babel where a project can fail, even with all the prerequisites for success, because of software engineers and industrial design engineers speak different languages, this paper aims to provide useful tools to improve communication between them.

As a consequence, it could be possible to deconstruct this Tower of Babel during the early stages of the development of a new product. In this way, this work is constructed over the following hypothesis: It is possible to improve empathy and teamwork competences of informatics students by applying design-based methodologies not commonly used in the software product development, but usually used by industrial design engineers.

The choice of methods to be integrated into teaching was based as the constraints of on the tool being agile and precise to be easily inserted into the curriculum of the subjects; to allow short-term outcomes for students to receive full and immediate feedback; that could be inserted or combined with most of the common software development methodologies; and finally and especially, to promote simultaneously the two overarching objectives: teamwork and empathy towards the user, and, as a combination of both, the final goal of communication support. In other words, the aim is to foster a change in the students design experience, both from technology-centered to an empathic design approach (Zoltowski et al. 2012), and from individualistic to common performance. The choice was the use of “Personas” and “Scenarios”, both human-centered design methods that aim to generate user analysis and situations of use, in a useful and directly applicable way throughout the design process and easily adaptable to teamwork dynamics.

The Personas method employs the description of fictional characters—called archetypes or personas—that correspond with product end-users, to address users’ descriptive and environmental aspects, as well as emotional features including their behaviors, desires and motivations. There is extensive literature addressing this method from different perspectives, which differ in aspects such as the input type of research or baseline data from which the archetypes are generated; the number of archetypes that must be generated; what aspect of the archetype will lead the design approach; or the degree of fiction or reality that is allowed in the description, among aspects. For a deeper analysis of this method and its variants, see Nielsen (2013) or Floyd, Cameron and Twidale (2008); for applications in education, see Klapwijk and Van Doorn (2015) or Wormald (2011).

The Scenarios method represents or describes a user’s particular situation, presenting the sequence of actions to be performed in order to achieve a goal. In this way, specific needs are understood, being the starting point to explore design solutions (Nielsen 2004). Scenarios are the result of studying the needs and desires of the users, as well as the ideas that the design team generates in the analysis of such data. The limitations of the design space are also considered. Nielsen 2004 provides a comprehensive review of the use of scenarios since their inception in the 1960s to their present uses in Human Computer Interaction. Both methods complement and enrich each other in the use of this method as a whole: Scenarios are an essential complement to personas and a key element in making the persona complete (Guðjónsdóttir and Lindquist 2008) and, meanwhile, personas are more engaging than design primarily based on scenarios (Pruitt and Grudin 2003). Accordingly, both are often used in combination, under the name of “Personas-Scenarios Method”.

Concerning our objectives defined by competences, one of the main advantages of this conjoined method is precisely the positive reinforcement for multidisciplinary work, facilitating the convergence and shared understanding between team members (Blanco et al. 2014). In relation to the second objective, Personas has shown its utility in the achievement of effective requirements capture for varying scopes of requirements-gathering efforts, fostering empathy towards the user while maintaining the user as a reference throughout the entire process, from design to evaluation (Faily and Fléchais 2010; Stoll et al. 2008). Miaskiewicz and Kozar (2011) established a list of benefits that incorporating personas can bring to the design processes. Most of them fit adequately into one of these three categories, as shown in Table 1.

Table 1 Personas benefits that match our objectives

The Personas–Scenarios method is a technique with considerable potential for software product development (Pruitt and Grudin 2003). It has demonstrated its usefulness to specify, prioritise and/or analyse user-based requirements, demonstrating its adaptability and complementarity with established software methods as use cases (Acuña et al. 2012; Miller and Williams 2006; Randolph 2004); agile methodologies (Da Silva et al. 2011; Haikara 2007); nourishing methodologies (Winters and Mor 2008); or even giving rise to new methods (Aoyama 2005).

The user engagement provided by this method is especially important among predominantly young designers and developers (Morris et al. 2010). Nevertheless, the successful adoption of Personas-Scenarios in the software development process lies largely in its acceptance by the development teams, and the best way to achieve this engagement is through the training of future developers. As Nielsen (2007, p. 45) states, the way in which Personas-Scenarios can be useful for developers is in allowing them to “experience the strength of method when a persona description is put in action in a scenario () training and experiencing clear the way”. Matthews et al. (2012, p. 1226) also report team training as a crucial stage to put in practice, since those team members with this preparation “used personas more heavily () and had more positive attitudes toward personas”. In this regard, issues related to the transfer of this method to a software engineering degree are discussed, and its adaptation to particular situations in which heterogeneous groups are present. In line with the demands of Klapwijk and Van Doorn (2015), the method has been systematized so that it can be used by teachers of computer sciences without outside supervision of an industrial designer. We also address some questions regarding whether students used to highly structured and programming-oriented techniques will become interested and engaged with more flexible and open methods; and whether they will be able to empathize with the user and accept his point of view. Finally, the influences that these methods exert to stimulate the work group are examined, and the interaction and shared understanding between its members.

Materials and methods

The workshop was replicated in three different groups over 3 days. The workshop was conducted with two groups of Informatics students, differing in terms of number of students, age and year of university education (see Table 2). Both groups were given identical amounts of time to participate in the workshop, and similar environments (classrooms) were used for all groups. It is noteworthy that Group A included students in their fourth year of university having an age of approximately 22 years, while group B included students in their third undergraduate year, with an average age of approximately 21 years. This allowed us to determine how the proposed method could be adapted to different group characteristics.

Table 2 Group distribution per workshop

Initiative, creativity and critical reasoning capabilities are pursued by students in the process of earning their degrees. Prejudices influence negatively on people’s potential to think creatively within an organization, being the behaviours and “attitudes concerning creative change” that impose one of the barriers to innovation (Basadur and Hausdorf 1996, p. 23). Facing this situation, we wondered to what extent the fact that computing/informatics students were oblivious to creative techniques could influence their acceptance and engagement with the proposed method. Therefore, we decided to apply an identical dynamic in a group accustomed to these techniques, in order to qualitatively observe whether the behaviour patterns and attitudes changed and to determine whether our workshop’s design really matched the target student profile. As a control group, an elective subject of the Industrial Design Engineering Degree was selected, with students in their third and fourth years of study. The programme of the Informatics Engineering Degree has not previously addressed information systems design with end customers; on the contrary, this is just one factor leading the Industrial Design Engineering Degree subjects from the early years. There were several criteria upon which the selection of the control group was based. On one hand, design students shared common features with computing students; they were students in their final years of undergraduate study and they were similarly unfamiliar with the Personas–Scenarios method. However, their training experience made them more habituated to collaborative work; virtually the entire curriculum of the Industrial Design Engineering Degree is implemented through the methodology of Project Based Learning (PBL) (Bell 2010). As a result, design students develop skills in teamwork and collaborative learning, with projects oriented to the design or redesign of products and services in which they use methodologies of user-centered design. Design students are accustomed to defining user needs and requirements, placing the user at the center of the discussion, and performing sequence analysis application in which environmental constraints are established, comprising different situations and problems to be solved by the design. We can therefore assume that this background enables these students to act as a useful reference group. Finally, previous literature (Antunes et al. 2014; Cross 2004; Onarheim and Friis-Olivarius 2013; Razumnikova 2013) allowed us to understand the differentiation of approaches that both disciplines could have regarding design, as well as to validate our own evaluation.

Groups A, B and C were divided into teams, each of which contained a maximum of five people. This maximum group size was selected because experience and the literature demonstrate that above this number, the groups tend to split into smaller subgroups, where only a few group members actively participate (Fowler 1990). In group B, it was necessary to exceed that number, because we had to find a balance between the number of teams and the duration of the session.

The setting was the same for each of the groups: a sufficiently large classroom where all teams were provided with an area for their own work. Each room included free walls to use as slate and as support of the material and allowed fluent movement of the teams around the classroom. Teacher space was visible from every angle, in order to project different presentations needed to guide the workshop with text, inspiring images and task indexes. This is important for those disciplines not accustomed to using design tools. Simple and accessible materials were used, including colored sticky notes, colored markers, black or blue pens for writing ideas and, if possible, other colors for drawings; projector; A3 and A4-format paper; bluetack or adhesive tape to affix paper to the walls. The results were recorded through a set of mixed tools: field notes of observations were kept; the entire process was documented with photographs of the sticky notes and the sketches of each phase; and presentations from each group were videotaped.

The duration of the workshop is directly proportional to the number of participants, and time distribution must be assessed to strike a balance between the number of students, time availability, and desired depth into the topic. In this case, however, what prevailed was the time for the groups within their subject (just 2 h, since teaching periods are stipulated in blocks of 1 or 2 h). The teaching program of Informatics Engineering in the University of Zaragoza does not leave much time available to students for extracurricular activities; therefore, by delimiting the duration of the session to the limits of teaching time, we ensured a greater attendance. This compelled us to make an effort to synthesize and prioritize the transmission of knowledge rather than deepening the instruction to include solutions. Although the sizes of the groups differed significantly, the stages of the workshop remained unaltered. What we varied was a major constraint on the time for each team to present their public speeches to the class; from the management point of view, an extra effort had to be made to strictly control the timing of each presentation. A summary of the phases with the timing are presented in Table 3.

Table 3 Stages and timing for the workshop

The topic selected to be undertaken in the three workshops was the reduction of water consumption by end-users. This theme offered a very wide range of end-users (different types of families, users of different ages, etc.) and a context familiar to the students (home) with a wide range of near referents. In addition, there did not exist similar applications that could condition or “contaminate” the results. The goal that students pursued was to develop solutions for water savings in this framework, based on a mobile application. Starting from a particular user profile in a specific circumstance, students had to identify a possible solution at a conceptual level, outlining innovative features.

Phase 1: Theoretical introduction

The main objective of the workshop was the formative function, that is to say, it was not intended that the concepts generated would be fully developed or innovative, but students could apprehend and reason about the process. Thus, the introduction equipped students with the minimum resources needed to address the workshop, in two main directions: methodology knowledge and concern about water consumption. Moreover, in an underlying way, the generation of a motivating atmosphere to prepare students and to favour a relaxed atmosphere for teams was raised as a parameter of the presentation. Accordingly, the slideshow was designed in a very visual way and with several nods towards this theme.

As part of the methodological training, some basic concepts about user-centered design and the particularities of interdisciplinary work that is focused on user were introduced. The educational objectives of the workshop were also explained; these included promoting teamwork, understanding and emphasizing with the user, imagining the context of use, and finally, working with both sides of the brain. These goals were addressed in two steps: first, a stage of engagement especially designed for informatics students, which was centered around nearby examples, some of them with striking contrasts and focused to cast doubt on usual prejudices about the user and to emphasize some of the most common problems of interdisciplinary work. And second, a stage in which theoretical explanation is used in response to the problems identified above.

In the workplace, the Personas method must necessarily be based on previous research, which in this case could not be carried out with students because of the lack of time in the course schedule. Therefore, it was important that, before the dynamic begins, students had the opportunity to learn about the findings of a research project that we did carry out previously to the class work. Hence, the second part of the presentation addressed the problem of saving water, specifically in private homes, providing quantitative and qualitative data, and was conducted in a very visual way. Special emphasis was placed on the problems to solve (user unaware of the amount of water consumed; the economic savings of conscious consumption is very low; the environmental consciousness is still not a factor well embedded in society; lack of user motivation) and the specific aspirations of the workshop (developing a mobile application for different user profiles to manage the use of water in a domestic environment; the results should be leveraged to make efficient use of water).

The workshop started with the division of the students into teams. In groups A and B, students freely pooled, while in group C they were distributed randomly by teachers. As a result, we had five groups in A, seven groups in B, and six groups in C.

The Personas–Scenarios method was not explained until the groups had been formed, and from the ‘learning by doing’ method (Anzai and Simon 1979). The process is built up step by step, using explanation and practice iterations. In such a way, the student is not overloaded with excessive information at the beginning; students listened to goals as a group rather than as individuals; and the slideshow itself was also used as a dynamic tool, as a guide. Each phase was structured in a similar way: a theoretical phase, in which each method was explained and some examples of other cases studies (with different topics) were provided (so that students could visualize what exactly was expected of them); an enumeration of the objectives corresponding to the method used for the workshop; and finally, an explanation of the “rules”, explained as “do’s” and “don’ts” that were left fixed on the screen as a reminder during group work.

Phase 2: User profile definition—Personas method

Once immersed in the methodological learning process, the first aim of the workshop was to draw the students’ attention to the enormous diversity of potential users for a single product, and to the high heterogeneity of needs, motivations, desires and capabilities that the designer could find. The objective was to make them aware of the maxim “Know thy user, for he is not thee” (Platt 2007, p. 12).

The Personas method does not have to focus on the whole user character, but on the part of the character that is helpful for designing the product (Nielsen 2013), seeking for added value in the solution. This is something that we consider a challenge in novice teams. Therefore, we decided to bolster this component, predefining persona profiles a priori and assigning one to each team. The characterization of personas was unrestricted, but we set a range of mandatory attributes based on previous research and related to economic status, type of house, number of inhabitants, leisure time available, and level of environmental consciousness. Each of these attributes was measured on a scale provided to students (see Table 4), in such a way that we attempted to encompass most of the possibilities (Table 5). This secured the heterogeneity of users and the focus on those traits that we considered essential to obtaining analytical solutions. We predefined the following profiles. Persona 1, married with children aged 2 months to 7 years; middle class. Persona 2, individual middle aged couple living in a villa; high class. Persona 3, young living in a student apartment. Persona 4, adult singles; without environmental consciousness. Persona 5, elderly. Persona 6, 8 year old communicative boy.

Tables 4 Scales of archetypes that were provided to the students
Table 5 Scales overlapping

The three groups worked and developed the same personas, with slight variations due to the differences in the number of students for each class. Group C worked with all of the profiles, without variations. In group B, persona 5 was used by two groups (because this profile was less familiar to the students), and for group A, which was smaller, the profiles 2 and 4 were dropped (because this profile shares similar points with those of 1 and 3 respectively). During periods of group work, the teacher’s task was to serve as a facilitator, mingling with the groups, reviewing ideas, and exposing questions that would induce students to find their way.

The first step consisted of each student individually recording ideas on sticky notes in a brainstorming mode, and then sharing, with their peers sticking these ideas on the wall. The ideas had the objective to address general characteristics of the stereotype (name, age, and physical characteristics), familial characteristics (family, marital status, etc.), psyche (strengths, weaknesses, etc.) and occupations (labor, skills, and hobbies). Students were asked to describe the emotions of the persona, and in this activity, were guided by suggesting to them that they could express attitudes of the character’s persona towards technology, to water savings, to the character’s family, to information, to the environment, and to his/her leisure time. The elements most related to the subject would be useful to them to identify solutions to the possible problems of each profile. Following this, they were asked to group conceptually the features that had been provided by all students, without discarding any of them.

The second step was to negotiate and agree on the final characteristics of the persona, choosing from among the ideas that had been proposed individually and constructing more complex ideas. The students also had to draw the persona, as they imagined the character. Thus, students endowed the persona with a name, an image, a history and a personality. As we can see in Fig. 1, with just a quick glance at the picture of each persona, we can deduce Chema is a rather spoiled child, who is more suited for football than mathematics, or Encarna embodies a nice old lady who lives alone.

Fig. 1
figure 1

Chema and Encarna, two examples of personas designed by computer engineering students

Finally, a representative from each group presented the character to the rest of the class. After each presentation, the teacher made comments and posed questions about the character, aimed primarily at promoting discussion.

Phase 3: Scenarios

The second phase of the workshop was aimed at having students understand the influence of context on the product use, and more specifically, on the topic of water saving. Students had to learn to define situations for their apps with a user and a specific goal in mind, sketching app ideas that solved problems or weak points of their persona.

Students were asked to tell a story or situation based on the persona profile and the environment of its archetype, addressing an initial problem (goals, barriers, dilemmas of the person), exploring design ideas, tasks and interactions with the app, user experience, and the benefit that the persona obtained, always taking into account factors related to the context and the stages of use.

The process again involved working through a brainstorming session with sticky notes, achieving group consensus about the problem to be solved and the proposed solution (app), and finally, the creation and drawing of a storyboard that narrated the starting situation or problem detected, use of the app in such a particular situation, and problem resolution. In Fig. 2, two examples are shown of storyboards created by students for the persona profiles presented in Fig. 1, where Chema involves his classmates and teacher in environmental consciousness through a mobile app, and Encarna employs a system of mobile alerts. This phase also ended with a presentation to the class of the results and some discussion about the proposed solutions.

Fig. 2
figure 2

Scenarios created by the students for the personas of Fig. 1

Results and discussion

The aim of this experience is to make evident that is possible to improve empathy and teamwork competences of informatics students by applying design-based methodologies. This is achieved by the identification of the utility of Personas–Scenarios methods for the teaching of Informatics Engineering and how it should be deployed, taking into account the limitations of the class schedule, ages and disciplines of the students. This goal has been accomplished with the experiments presented above whose results are analyzed in this section by using a mixed-method approach (Borrego et al. 2009), qualitative and quantitative, by taking data from the direct observations and by using a semi-structured survey that we provided to the students participating in the experiment. The survey included both closed-ended questions scored using a Likert scale, from “strongly disagree” to “strongly agree”, and open-ended questions focused on understanding the answers to the closed-ended questions, allowing students to express their point of view, so the researchers could discover emergent issues.

In this section, we describe the results we obtained on the triangulation of the two dimensions mentioned, and we discuss the lessons learned to adapt Personas–Scenarios method for use with university Informatics students.

Results derived from the application of the method in different groups

One of the unknowns for the adaptation of Personas–Scenarios methods to a classroom was how to adapt the same methods to classes of different sizes, characteristics and personalities. Thus, in the experimentation, we placed emphasis on observing how students behaved at each level and how much learning depended on the following items: the composition and distribution of the groups, the global character/personality of the class, the students’ attitudes, and the styles of working (team interaction, ways to describe personas, and rhythms). Data recording were carried out by two teachers and conducted through field notes, video recordings and photographs. Furthermore, at the end of each session, all materials generated by students were collected for further study.

As expected, the difference in the total number of the two groups in Informatics influenced manageability when performing the dynamics. In the B group, which was larger, it was not possible to form small work groups of students, since a greater number of groups would have increased the total duration of the session beyond its limit, mainly due to the presentations at the end of each phase. These presentations alone, each taking about 3–5 min, required approximately 50 min of the workshop. At the working level, greater cohesion, cooperation and unity were achieved in the A group teams, and the outcomes were more serious and coherent. In the B group, teams were too large in size, and this led to the formation of subgroups of active and passive persons. In other cases, partitioning of work occurred, and therefore, less interaction and global vision was contributed by each student. Finally, there was a team that took the exercise as a joke. This explains why there were a couple of personas that were too caricatured, with some inconsistencies or clichés in this group and, in general, the level of ideas that emerged was lower in quality than the ideas generated by other groups. However, this does not affect the objectives of the experiment as fully viable solutions or solidly grounded requirements were not expected. Furthermore, these data, combined with the answers provided by the students in the survey (82 % felt that the ideal number of students per group should be 4 or 5) are consistent with our expectations and literature. These data led us to confirm that the ideal number of students per group is between 4 (preferable to establish a more manageable group, where everyone has an opportunity to contribute, effort is required by each member, and where it is easier to “stick together”) and 5 (with the advantage of odd number, which encourages debate and facilitates agreement, and with the disadvantage that its size facilitates eluding tasks by some participants).

Time equally influenced the two classes, proving that although the effort to condense all stages in just 2 h was effective (as we were able to achieve all objectives). It would have been much more productive to make each session 1–2 h longer; this longer duration would allow the transmission of theoretical concepts and performance of the work in a more leisurely way.

On the other hand, the atmosphere and character or group personality influenced the teaching strategies that we had to adapt in real time in each scenario. Group A, with only 12 students and 4 groups, was a quiet, thoughtful and very proper class, but initially hesitant to participate. Therefore, the task of the teacher at the beginning of the activity was to bridge the division between teacher and student, emphasizing the casual part of the activity, until the students relaxed, overcame their shyness, and became involved in the task in an uninhibited way. The students slowly loosened up, and the group activity produced remarkable results. The character of Group B, a massive class with 40 students divided into 7 groups, was diametrically opposed to Group A. We started with a congested and decentralized atmosphere, so the instructor’s initial effort was aimed at engaging and motivating the students with the subject and controlling the emotional climate of the class. At one point in the theoretical introduction, this connection was established, and subsequently we were able to develop the session successfully, with a remarkable level of involvement by the students. We believe that this differentiation between the two groups is also due to an obvious increase in maturity that occurs between students of third year and fourth year, both in learning style and intellectual development levels (Felder and Brent 2005), and had reflected both in the management of the dynamics and the survey results. These results have confirmed a subjective impression that teachers had previously formed, based on over 15 years of teaching experience working with students of this age group.

Results derived from the application of the method in informatics students

Better result by the influence of discipline and experience

Analyzing videos and field notes, and comparing the results with the control group, we found that the discipline/experience of the student influences the results to a great extent. In general, Informatics students were more succinct than design students. The descriptions provided by them were much more concrete, assigning priority to objective data, and not delving extensively into the background of the users compared with the descriptions of the Design students. Meanwhile, the descriptions provided by the Design students were much more detailed, with some isolated comic touches and stereotypes, but offering more credible and real characters. This concreteness also extended to the second phase, the Scenario. Here, design students immediately became immersed in the dynamics. They quickly began negotiating, discussing different points of view, resolving doubts that occurred to them with the teacher, and working until the last second to complete everything they had in mind (in some cases, they ran out of time). Almost all of the Design students attempted to solve those problems noted by the professor in the initial rounds of interactive evaluation, during the workshop phases. For their part, the Informatics groups spent less time engaged in the early-stage “creative” work and began implementing their ideas much earlier.

This is not a reflection of the less interest or capacities of one group versus the other, but of convergent and divergent character (Onarheim and Friis-Olivarius 2013; Razumnikova 2013): the developer is rational, using his left brain, which causes him to tend to work towards the solution and optimization. Meanwhile, the designer is divergent and emotional, using his right brain, which causes him to lean more to the imagination and to generate many solutions. The dichotomies between these disciplines described by Antunes et al. (2014) and Cross (2004) are also absolutely reflected here. When the time had expired for this phase, most of the Informatics groups (both Groups A and B) had finished the storyboard, and there were even groups that had extra time left over. Furthermore, despite having enough time, many of the students did not know or have the initiative to try to solve the questions and gaps that the teacher had presented to them in the interactive evaluation rounds. This comparison is useful when managing multidisciplinary groups; in this type of dynamics, proactivity or professional individual personality within a group may depend largely on the training that was previously received. Therefore, an interesting line of research is the analysis of how to approach joint learning activities with the aim of both characters (convergent and divergent) being nurtured in training for multidisciplinary work (Dym et al. 2005; López et al. 2013). This fact is also necessary to consider in the application of the proposed method. Depending on the educational background of the students, the teacher needs to provoke and induce ideas, especially those related to divergent thinking in the early stages, to finally conclude with convergence (see Fig. 3). In this sense, the tips related to brainstorming, such as those of OpenIDEO (2011), defer judgment, encourage wild ideas, build on the thoughts of others, stay focused on the topic, address one conversation at a time, to be visual, and aim for quantity can be useful to induce students to engage in divergent thinking. In our experiments, we included these tips in the slides in the form of “rules” to follow. On the other hand, the teacher needs to make a special emphasis in reflective thinking or reflection-in-action processes, enabling their consciousness about how they frame and approach the design activities (Antunes et al. 2014) and offering them resources to overcome their drawbacks or resiliencies. In our experience, we put in practice some techniques (indirect questioning, problem reformulation, among others) in an intentionally veiled manner, in order to let students discover the way themselves.

Fig. 3
figure 3

The process of design squiggle (Newman 2015)

Better result by working in teams

Focusing now on the Informatics groups, the survey results support our hypothesis about the validity of the method for teaching students how to work in groups. In the open-ended questions that dealt with what the workshop had taught them, 77.27 % of students highlighted issues related to this topic, such as learning to work in teams, to put things in common; respecting and being willing to listen to different opinions, and as a result, losing their self-consciousness to express their own ideas; learning to encourage debate and discussion; and acquiring the ability to reach agreements. They also stressed the improvement of their capacity to quickly generate ideas from the exercise of brainstorming, as well as the novelty of the solutions arising from the overall process of the workshop. This is precisely an intrinsic value of the workshop itself: the emergence of a large number of ideas, which are used as a starting point for discussion; students have to discuss, defend and argue, so that they accomplish better and more elaborate solutions. Hence, we can conclude that the workshop contributes to fostering the aforementioned divergent thinking, enabling students to think creatively. Another group of responses that improve teamwork are related to the joy of learning the “Personas–Scenarios” method itself, as an unfamiliar class of methodology, opening the mind to “different techniques than those taught in our classes” and “other perspectives about how to work”. This clearly prepares them for multidisciplinary work, in the acceptance of other forms and methods of work. The application of a new method also involves a change of approach and a new vision of the problem, which allows the participants to perceive details not observed with known methods, and therefore also increases their creative abilities. Finally, quantitative data corroborate the qualitative component because, for the question in which they were asked to assess the interest of the workshop to learn teamwork, 93.5 % of the students rated it positively and, within that group, three quarters rated it as highly positive (see Fig. 4). Here, we can also perceive a differentiation between the curves of students in their third and fourth years, which we attribute to the greater maturity of the latter group.

Fig. 4
figure 4

Survey results for the question related to “Do you think the workshop improved your skills to work in multidisciplinary teams?”

It should be noted that the presentations of other teams are also perceived as a source of learning. This is especially noticeable because learning “through others’ work” is in fact an intrinsic value of this workshop; other students’ presentations allow students to learn from their classmates, seeing the different approaches and solutions that other groups have found for the same issue.

Better result by pursuing a common goal

Students also suggested in the open-ended questions some advantages of the Personas–Scenarios methods as a means to reach a common goal and as a “good starting point in the development process”, applicable also in the “analysis and design phases of a software product”. We also found that through this method, they discovered the “importance of developing with the end-user in mind”, especially with respect to two points: in the multiplicity of features that the user may have, and how each member of a team can have a completely different picture of the same user. A student designated as a discovery the fact that when characterizing the user, “all five of us had different ideas of how he/she should be”. Therefore, we can conclude that we achieved our aim of generating requirement definitions through user empathy.

Special attention should be paid to the emergent items that have arisen from the open-ended questions. In a large number of responses, we perceived the effective generation of communities of practice among the participants, which also entail positive effects for the facilitation of teamwork and also of the learning experience (motivation through social recognition, interchange and feedback between students, and experience of teamwork closer to the industrial practice) (Sancho-Thomas et al. 2009). One recurrent issue in the answers was also the students’ perception of a favourable atmosphere conducive to the motivation and involvement of the class. One of the students, for example, was surprised by the fact that “our class has been able to actively participate, because not in every subject people strive so much”. The students also appreciated working together for a common purpose and developing respect for others’ ideas, and some of them affirmed to have felt closer to their peers. It should also be noted that another student confused the relaxed environment with an invitation to play, although this response was isolated, it is worth keeping this in mind in the future, and including some clarification on this point in the initial slideshow before starting the session, to prevent such misunderstandings in the future.

Better result by catching student’s interest

Two of the premises on which we designed the workshop were its role in students’ training and its usefulness for their future work. In the light of the quantitative and qualitative data described so far, it is unquestioned that the workshop provides basic skills in both fields (training and future work), which are new to these students. In addition to the above, other comments support this idea, because the workshop was perceived as a way to improve their ability to make professional product presentations; to clarify their perspective on the development of a project; and raised the possibility of implementing this method in their future work. Nonetheless, when asking students directly in the quantitative closed-ended question, as can be seen in Figs. 5 and 6, it seems that the students’ perception of the usefulness of the workshop in this sense is not categorical. Although data originating from the fourth-year students are positive in both cases, there is a wide dispersion in the answers provided by the students in their third year. We believe that several factors influenced this outcome. Once again, the difference in maturity could explain this difference between evaluation levels, and also, in general, the less experienced students’ lack of knowledge about the target competences of the degree they are studying, and about the skills that they will require in the real world, may have been a factor. This makes us ponder the previous justification in the theoretical part of the workshop, and we believe it is appropriate to add at the beginning a brief explanation of the learning points on which the workshop focuses and how the participants can apply what they learned in their future jobs.

Fig. 5
figure 5

Survey results for the question related to “Interest of the workshop for your training”

Fig. 6
figure 6

Survey results for the question related to “Interest of the workshop for your future work”

Better result by broadening knowledge

Finally, to ascertain the satisfaction and the degree of interest awakened in the students, we posed the question of whether or not they would to like broaden their knowledge or information about this type of methods in the future. Shown in Fig. 7, the positive quorum was almost unanimous, with the majority (83 %) responding that they would be interested in further training in this regard. However, among those who said yes, there was a very clear difference between the third- and fourth-year students when asked if they would be willing to attend this extra training outside of their lessons hours. Here, the difference in maturity between the two levels (see Fig. 8) is seen again, as well as the higher motivation of the students in their fourth year, perhaps due to the immediacy of their pending arrival in the professional world. Note that, despite this evident difference, in global terms the ‘yes’ responses still outnumbered the ‘no’ responses, even more notably taking into account the previous phenomenon mentioned (the very limited time that students have for extracurricular activities, due to the demanding schedule of their degree).

Fig. 7
figure 7

Survey responses to the question “Would you like to broaden your knowledge about this subject?”

Fig. 8
figure 8

Survey responses to the question “If so, would you do it outside the classroom?”

The ideal structure of the dynamics from the lessons learned

Qualitative and quantitative assessment of the experience allows us to affirm the effectiveness of the workshop for the proposed objectives, with it being possible to apply the same scheme in other classes. In addition, and as a result of lessons learned from the experiment, we have designed those we consider the ideal programme and structure of the teaching interventions, considering a suitable timeframe, without restrictions (see Table 6). Depending on the context, the average time could range from 4 to 7 h, divided into several sections.

Table 6 Phases and timing of the ideal workshop

In this case, we propose an identical activity to that experienced, but preceded by a preliminary session, which will serve to provide a richer theoretical introduction and to present to the students the general problem to be solved in the subsequent session. It is important that at this time the specific “challenge” is not yet revealed, to avoid reaching the design stage with predefined solutions. Some intermediate days shall be reserved between the two sessions in order to conduct the research needed for the workshop. This research will be conducted by the teams themselves so that they can draw some initial conclusions. It can be divided into subtopics, which will be assigned to each team. The results will be presented by each team at the start of the second day, with a subsequent discussion and a round of questions posed by the teacher.

From here, the workshop proceeds in the manner described above. In this case, as there has been previous research performed by students, it is not necessary to establish binding characteristics of personas, although it may be equally interesting to assign a profile to each group, to prevent them from all selecting the same one. If the subject warrants working with a single user profile, choosing the characteristics of personas can be left completely open to each group. At the end, it would be interesting to host a session for evaluating results and redesign solutions.

It should be remembered that the mission of the teacher should be concentrated in two dimensions: first, the teacher serves as a trainer and transmitter of theoretical knowledge, and on the other hand, as a facilitator of the debate, provoking, highlighting pros and cons, and raising questions and challenges that the groups have to address. Relying on a projected presentation to guide and mark the steps of the dynamic is essential; we have observed that while the groups are working, they tend to consult the “rules” in the presentation.

Conclusions

In this paper, we have described a successful case of applying a design-based methodology as a tool for improving abilities and competences of Informatics Engineering students, which are not yet fully covered by the recently implemented competence-based education of the Spanish university. This design-based methodology use not to be part of the “portfolio” of knowledge that software product developers applies, but is commonly used by industrial design engineers in their work with end-users in the identification and classification of their needs and in their translation into product requirements.

The experiment was carried out in three experiences that have involved three different groups of students from different levels and specialties of education, and has been evaluated following a mixed-method approach. In this sense, the comparison of students from Informatics and Design illustrates that the proactivity and group attitude may depend on the background training, which can make students tend towards convergence or divergence and is something to consider in managing multidisciplinary groups.

As a relevant aspect of this teaching intervention, we can confirm the possibility of adapting it to different group characteristics and its effectiveness to provide skills that students have lacked until now. The introduction of the Personas–Scenarios method in computer classes encourages creative thinking by students and produces a positive reinforcement of competences needed to perform the work in multidisciplinary groups, which is evident both in the observation of the dynamics and their results in the students’ perceptions. We have also noticed that it fosters students’ empathy, raising their awareness about the importance of taking the user into account, comprehending their thoughts, feelings, and worldviews, and from this perspective, enables them to define requirements that meet the real needs of the user and to propose more usable and real solutions.

In short, if we can present the issue as a communication problem either between team members or between developers and users we can assert that the application of our proposed method can help to prevent, to a some extent, Tower of Babel-like developments, and can contribute to the construction of more solid bases for team and user understanding in the training of Informatics students.