User and stakeholder perspective taking in novice design teams

Abstract

Taking the perspective of users and stakeholders can help designers incorporate human-centricity in their practice. However, we know relatively little of the dynamics of perspective taking – a cognitive facet of empathy – in design processes as a situated cognitive and behavioural activity, rather than as an overall orientation. To illuminate how perspective taking is used in design, we carried out a longitudinal multiple case study of 49-month-long graduate-level product and service design projects, exploring differences between high and midscale performance in different design phases. Through thematic analysis of review session discussions, we find that perspective taking in high-performing sessions involves three aggregate dimensions: gathering data to form perspectives, scoping and making sense of perspectives and using perspectives in creative processing. We identify phase-dependent characteristics for the scope and emphasis of perspective taking in concept development, system design and detailed design. We also describe different ways in which novice teams struggled to create and apply user perspectives. As a result, the current study sheds light on perspective taking and the changing nature of effective perspective taking across the design process.

1. Introduction

Understanding users is a foundation for design (Sharrock & Anderson 1994; Redström 2006). User-identified problems and workarounds enable the design of better solutions (Hyysalo 2006), user-related innovation is important for product success (Saunders, Seepersad & Hölttä-Otto 2011; Hölttä-Otto et al. 2018) and expert designers give high priority to user- and context-related knowledge (Atman 2019). Still, many product launches fail in the market due to lack of user acceptance (Schneider & Hall 2011). To start, the reasons for this can be attributed to differences in designers’ and users’ points of view (Chamorro-Koc, Popovic & Emmison 2008) and the complexity of design processes making user-centricity challenging to practice (e.g., in architecture: Van der Linden, Dong & Heylighen 2019).

Perspective taking (Surma-aho & Hölttä-Otto 2022) by adopting another person’s point of view (Davis 1983) is a way to improve user understanding. It represents a cognitive dimension of empathy, with the degree to which one can imagine ‘putting oneself in another person’s shoes’ measuring the capacity to engage in perspective taking (Davis 1983). Active attempts at perspective taking lead to, for example, reduced bias in assessing the causes of others’ behaviours (Galinsky & Moskowitz 2000). Designers use varied perspectives (Smeenk, Tomico & Turnhout 2016), analogous experiences (Johnson et al. 2014) and abductive reasoning (Oygür 2018) to develop user understanding and explore potential solutions (Dorst & Cross 2001). Studies show that taking the perspectives of users aids interpersonal understanding, both in design practice (Both & Baggereor 2009; Kelley 2015; Hanington & Martin 2019) and in design education (Zoltowski, Oakes & Cardella 2012; Walther, Miller & Sochacka 2017).

However, accurately understanding user perspectives and incorporating these insights into designs can be challenging, particularly for those with limited experience of design. Novice and student designers tend to find constructing user understanding challenging and may fail to consider a broad enough context (Zoltowski et al. 2012; Björklund 2013) and struggle to balance multiple user and stakeholder perspectives (including those of producers, suppliers and retailers; Scott 2008). They may also respond too simplistically to complex feedback on their designs (Sugar 2001). Yet research also suggests that some novices are able to form in-depth understanding by developing genuine relationships with users and stakeholders (Zoltowski et al. 2012). Without prior experience and insights from user-centred projects (Popovic 2004; Oygür 2018; Van der Linden et al. 2019), how do novice designers attempt to understand and leverage user and stakeholder perspectives in their work?

In response to this research question, we investigated how different novice design teams used perspective taking to understand users and stakeholders, and how this understanding was used in designing solutions. The results shed light onto perspective taking processes in novice design teams and suggest how novice designers can cultivate and leverage user understanding in their work. We find evidence that perspective taking is tied not only to understanding users but also to the process of design itself.

2. Background

User-centred design (Sanders 1992) involves significant perspective taking efforts. Designers regularly consider the perspectives of users and other stakeholders to inform not only their understanding of the extant situation but also novel solution development. Overall, empathy for users is seen as a key process in design practice (Cross 1982) and design thinking (Micheli et al. 2019). While there is a wealth of studies on designer–user interaction (e.g., Luck 2007; Hess & Fila 2016) as well as human-centred design cognition (Cross 2004; Gero & Milovanovic 2021; Cascini et al. 2022), we propose that the psychological construct of perspective taking (Davis 1983) can provide a valuable additional lens on user-centred design.

Perspective taking represents a (a) cognitive and (b) purposeful form of empathy that is (c) influenced by a wide array of situational factors, such as observer-target similarity, the observer’s respect for the target and the perceived need of the target (Cuff et al. 2014). Perspective taking has been described as a personality trait, while state perspective taking refers to intentionally taking others’ perspectives at specific moments (Clark, Robertson & Young 2019). In this study, we examine designers’ perspective taking at specific moments.

Design presents a unique context for perspective taking. Design practice emphasises a wide range of behaviours for interpreting others’ experiences (e.g., Hanington & Martin 2019), whether they be the others’ knowledge, feelings, decision making logic or any such cognition. To take end-users’ perspectives, designers talk with users, imagine users and synthesise their needs, as well as test solutions with users (Hess & Fila 2016). Also, taking part in users’ experiences and purposeful reflection can support more in-depth understanding (Kouprie & Visser 2009; Smeenk et al. 2016).

The understanding that designers develop through perspective taking is constructivist in nature, meaning that it is person-bound, subjective and malleable (Oygür 2018; Van der Linden et al. 2019). Designers use user understanding in formulating the problem (Ball & Christensen 2019) and in the generation and elaboration of solutions, that is, creative processing (Oygür 2018; Van der Linden et al. 2019; Pedersen 2020). In user understanding, perspective taking supports both nonstereotypical (Ku, Wang & Galinsky 2015) and nonegotistical judgements of others (Epley et al. 2004). As such, we might expect ‘deep’ understanding of a user group to avoid stereotypes and to be independent of the designer (e.g., a confident designer should not view all users as confident). Perspective taking also assists in negotiating contrasting points of view, such as conflicts in romantic relationships (O’Connell Corcoran & Mallinckrodt 2000) and sales negotiations (Galinsky et al. 2008). In practice, we might expect perspective taking to balance understanding of users and other stakeholders, such as suppliers or retailers.

How such balance may be achieved, however, remains unclear. Designers can struggle in correctly interpreting users’ perspectives (Heylighen & Dong 2019; Chang-Arana et al. 2020a, b; Li & Hölttä-Otto 2020; Li et al. 2021), and increased evaluation may be needed for a more accurate basis for perspective taking. The intentional nature of perspective taking (Zaki 2014) may help novice designers to balance design concerns. First, designers may consider when, how and to what degree they conduct perspective taking. Second, designers decide to pay attention to others’ perspectives and appraise them as valuable. Third, sufficient information is gathered to enable constructing an accurate perspective. These three steps may shape the quality of user understanding.

Designers also need to determine the appropriate degree and format for perspective taking to inform their creative solutions. Perspective taking can influence the problem frames adopted by designers as they formulate problems and solution conjectures (Beckman & Barry 2007; Paton & Dorst 2011). Perspective taking goes beyond understanding to influence evaluating and generating constraints, value and working principles (Dorst 2011). The problem frame adopted initially will shape the direction and quality of subsequent design efforts (Walz, Elam & Curtis 1993; Chakrabarti, Morgenstern & Knaab 2004). As such, the impact of initial perspective taking may influence the complete design process (Walz et al. 1993; Chakrabarti et al. 2004). In practice, perspective taking may, for example, influence which groups of stakeholders are solutions tested with, how designers present the value of a solution and how they respond to feedback (McMullen 2010). Perspective taking may also play a continuous role through iteration in design processes (Hess & Fila 2016; Smeenk et al. 2016; Heylighen & Dong 2019; Xue & Desmet 2019).

Thus, this study explores how novice design teams acquire and leverage understanding of users’ and stakeholders’ perspectives in different phases of the design process.

3. Methods

We carried out a multiple case study on how novice design teams develop and use understanding of users’ and stakeholders’ perspectives during product and service design projects.

3.1. Case context and participants

This study focuses on a convenience sample of four student design projects at a North European university taking part in a 9-month multidisciplinary graduate product and service design project course across multiple collaborating institutions. Each of these projects had a different client company and tackled a distinct design brief, differing in the degree to which the target user group(s) and usage context had been specified at the onset by the client company (Table 1). As all four projects had distinct design briefs in different industries, with different clients and design teams, we consider these as separate cases despite the shared course context (similar to other multiple case studies, such as Van Echtelt et al. 2008). An open-ended, ill-defined design brief required the teams to explore a wide variety of data and interact with both the client companies and the instructor team. Still, the teams made all design decisions about project scope and solutions.

Table 1. Team composition and project brief of the four cases

The graduate students taking part in the course had worked in design jobs (summer and/or part-time) and had completed undergraduate degrees in their respective fields. Each team, comprising three to four students, had at least one student from product development (studied under engineering) or industrial design (studied under arts and design) and other students without previous product or service design experience, which emulates the diversity of many real-world design teams. As such, we consider the student teams to represent novice design teams with limited design experience and skills.

3.2. Data collection

The primary data source was observations of design review sessions during the design projects, supported by intermittent project documentations and handouts from the teams. The studied project course was structured around roughly 2-week design challenges, with seven deliverables during the course. Each challenge ended in a design review session, held separately for each student team. The first two review sessions (T0) involved needfinding and focused on problem space exploration (e.g., benchmarking), and were excluded from the data collection (see Figure 1). Data were collected from five subsequent review sessions spanning five prototyping challenges focusing on solution space exploration (labeled T1–T5, see Appendix). In each design challenge, the student teams were expected to demonstrate a tested prototype considered complete for that project phase, and new project-related insights learned during the challenge.

Figure 1. Course structure, data collection points (in gray) and grade scores averaged from three sub-grades. Note that this visualisation omits time dedicated for an initial rehearsal project, holidays and dedicated documentation writing and presentation preparation.

3.3. Review sessions

Each review session lasted on average 41 minutes (ranging from 37 to 51), during which students presented their decision making and received feedback on their prototype, the design choices made and the methodologies used. The 20 observed review sessions (T1–T5 for four teams) were audio and video recorded. They were transcribed verbatim by the first author, resulting in on average 6500 words of transcribed discussion per session (ranging from 3600 to 8500).

3.4. Outcome measures

Additionally, the grades of each review session were collected and used to identify high- and midscale performers in each design challenge and phase. The grading was carried out independently by the instructional staff, consisting of a product development professor, the course coordinator (M.Sc. in engineering from product development) and three graduate course assistants from different fields (computer science, industrial design and innovation management). The design review grading rubric included three distinct sub-scores (scale 0–5) assessing the team on (a) completeness of the prototype and testing, (b) the depth and relevance of their learning and (c) their understanding of the current design challenge (see descriptive statistics per design challenge in Appendix). The review session at T5 was graded using only one general grade rather than the rubric. Overall, the grades reflect the teams’ performance both in following a useful design process and in showing project progress.

3.5. Data analysis

The design review session transcripts were analysed with a constructivist framing and with the aim of identifying how end-users’ perspectives were considered by novice design teams. The qualitative analysis process (see Figure 2) was based on thematic analysis (Braun & Clarke 2006). The process made frequent use of the constant comparative method, where codes were iterated upon by comparing them to each other, and as a result, new codes were created and old ones split and merged as necessary.

Figure 2. Data sources and analysis process.

The data were qualitatively coded in multiple phases (Saldaña 2013), with individual arguments made during the review sessions as the unit of analysis. First, the first author familiarised with the dataset by making free-form notes during observations and by transcribing the audio files. Next, the review session transcripts were coded using line-by-line holistic coding, to identify self-standing excerpts referring to users or other stakeholders (such as potential suppliers, distributors or collaborators for the novel solution) and their perspectives. These segments were then clustered into codes based on semantic-level thematic similarity of the empirical content (Braun & Clarke 2006) to form the first-order categories in Figure 3. Next, focused coding was applied to identify salient processes in the design teams’ perspective taking within the descriptive categories, clustering similar themes together into the second-order categories in Figure 3.

Figure 3. Hierarchical organisation of qualitative codes developed in this study.

Throughout this process, coding and categories were discussed jointly by the authors to improve the reliability and validity of the analysis, discussing any differences in interpretations until agreement was reached (similar to, e.g., Crilly & Moroşanu Firth 2019; Lauff et al. 2020). This type of group analysis practice is commonly used in qualitative research where the aim is to formulate new hypotheses about phenomena, instead of testing hypotheses through more quantifiable and replicable coding (Saldaña 2013). As with all research, the positionality of the authors can be considered to have influenced coding choices. In this case, all authors have advanced degrees in engineering, have experience in teaching project-based design courses with multidisciplinary teams, including engineering design and industrial design students, and have practical experience from product and/or service design.

To supplement understanding of the design process and support full understanding of the references made in the review sessions, the teams’ handouts, reports and prototypes were examined. Overall, coding of the review session transcripts formed the main analysis of this study, with other documents further enriching our view of the four cases.

After coding the review sessions, aggregate dimensions of perspective taking were formed through cross-project-phase and cross-performance comparisons. To create these groupings, firstly, the data were grouped into three distinct project phases (concept development, system design and detailed design) based on the design goals advocated for by the course. Changes in design goals could be seen as changes in the teams’ behaviour, with them primarily striving to understand the project context and develop preliminary solutions in the concept development phase, then moving onto developing a more holistic solution in the system design phase, and finally to developing a functional proof-of-concept prototype in the detailed design phase. Second, the review session grading was used to categorise the performance of each design team in each design review session as either high or midscale. The three sub-grades were averaged into an overall grade for each review session for each team. Based on the overall grades, the review sessions were assigned into either high-performing or midscale groups by splitting at the mean overall grade. The resulting assignments were checked with the teacher-in-charge to provide further validity for the grouping. The categorisation resulted in 12 high-performing sessions and eight mediocre-performing sessions (Table 2).

Table 2. Design phase and performance categorisation

Thus, perspective taking was analysed in a 3-by-2 matrix, by project phase and design-challenge-level performance. Even though the teams’ performance changed across design challenges and even within project phases, their perspective taking patterns in each design challenge adhered to the respective performance category, regardless of their performance in previous or following sessions. For example, Teams Tennis and Finance were both midscale at T2 and exhibited similar perspective taking patterns to one another. However, at T3, the patterns of Team Tennis were similar to the other teams in the high-performing category in the system design phase, while Team Finance continued to display midscale category patterns. Further, while Team Tennis and Team Finance stayed in their respective performance categories in T4, both of their perspective taking had changed to reflect patterns of the detailed design phase.

4. Findings

Examining the review sessions of the four design projects, we saw different facets of gathering data to form user perspectives, scoping and making sense of perspectives, and using perspectives in creative processing. Furthermore, we observed clear differences across different design phases and performance.

4.1. Gathering data to form user perspectives

Table 3 shows an overview of how gathering data to form user perspectives was carried out and changed through project phases and performance categories.

Table 3. Overarching patterns and developments in gathering data to form user perspectives

Concept development: looking to understand user cognition, emotions and behaviour

While cases in both performance categories engaged in user and stakeholder research, reported behaviour in high-performing and midscale sessions differed in the scope of information sought. Teams in high-performance T1 sessions had focused on understanding user cognition and affect in addition to user behaviour and other project factors, laying the foundation for more in-depth perspective taking. This focus was expressed through inquiries about users’ cognition, such as ‘what would they want’, ‘are they interested in this’ and ‘what do they feel’. Further, the focus was shown both when exploring the value of a specific solution conjecture (‘what would [users] prefer to have for visual cues [in our solution conjecture]’), and when more generally aiming to understand users (‘what would [users] want to know if they could anonymously, non-traceably [sic] ask anything [about businesses]’).

In contrast, the goals reported in midscale sessions in T1 were primarily centred on how users behaved around solution conjectures, comprising phrases like ‘would they do it spontaneously’, ‘would they post about this on social media’ and ‘will they buy this’. Cases in the midscale category also recounted research goals that did not support learning directly, such as team building (‘it was fun to make’) and making the deadline (‘at least we have something to show you [the reviewers]’). Explicit techniques to understand users’ and stakeholders’ cognition and emotions were largely absent, suggesting focus on understanding the utility of solutions more than users’ and stakeholders’ perspectives.

These differences in foci were mirrored in the methods chosen for user research. In the midscale category, Team Tennis had only observed users and Team Farming had observed signs that their prototype had been used. These methods resulted in quantitative data, such as how many prototypes had disappeared since the team last saw them. This did not stimulate holistic perspective taking. In the high-performance category, teams had complemented observations with interviews. For example, while Team Water named user behaviour as their primary focus, stating their main goal for prototype testing as ‘[wanting] to know the minimum way of having anyone contribute to water quality monitoring’, they also showed interest in the users’ cognition and affect by interviewing users after having them interact with a prototype.

System design: targeting relevant users and stakeholders

In the system design phase, cases in both performance categories expressed user-centred data gathering patterns akin to the high-performance category in the concept development phase. Cases in both performance categories focused on learning about user cognition, emotions and behaviour alike, making this no longer a differentiating factor across higher and lower design output and process quality.

Despite capturing user cognition and emotions in addition to behaviour, some midscale-performance cases targeted users and stakeholders that were less relevant to understand given the team’s current solution conjecture. For example, Team Finance was working on a business foresight and planning tool in T3, and tested it on established small and medium enterprisess, despite having already learned that ‘many of these small companies don’t see value in long-term planning, because their work is so day-to-day and week-to-week’ and heard that ‘this might be helpful for someone who is new to business or someone who is bigger and has more resources’. However, as the team failed to target their data collection to these promising user groups, their learnings were limited to reinforcing earlier understanding of whose problems the solution conjecture might be fit to address: ‘this appeals more to those who are starting up their business’. In contrast, Team Farming in a high-performing T3 session had been able to find suitable proxies for large-scale farmers to test their prototypes with: agriculture students whose families had large farms, and the caretakers of large farms.

Detailed design: rare and focused user research

In the detailed design phase, cases in the high-performance category discussed users and their perspectives less, increasing instead discussion around feasibility and technical implementation. For example, in T4, Team Farming described an intricate database structure for a digital solution to help farmers learn from each other, and Team Tennis had coded a camera application that could recognise and modify views of tennis courts. As extreme cases, Team Water in T4 and Team Finance in T5 had not done any user research in favour of building a functional and integrated solution. When gathering further data to form perspectives was discussed, the high-performing cases focused on more specific topics than before. For example, Team Water in T5 focused on strengthening their solution conjecture by interviewing managers instead of end-users (‘[our client company] helped us interview the head of a citizen science group’) and by expanding its use case (by inquiring whether citizen scientists would be willing to verify water quality measurements from strangers to supplement the measurements of certified individuals).

The midscale cases, in contrast, still inquired users about more fundamental matters, such as Team Farming in T5 asking how often farmers use agricultural consultants’ help in decision making when their solution was partly focused on connecting farmers to consultants. Similarly, Team Tennis in T5 continued asking users ‘if they would use’ the team’s solution. Overall, while midscale cases were still trying to find overall solutions to deliver value, high-performing cases were assuring that the detailed design of their chosen solution delivered value.

4.2. Scoping and making sense of perspectives

Table 4 shows an overview of how scoping and making sense of perspectives were carried out and changed through project phases and performance categories.

Table 4. Overarching patterns and developments in scoping and making sense of perspectives

Concept development: sensemaking by moving between generalisations and data

The high-performing cases in T1, enabled by the user data that they had gathered, moved between generalisations and data in their reasoning. They grounded higher-level interpretations in direct and less-ambiguous learnings. For example, Team Water found that laypeople valued seeing water quality being measured in their local area: ‘people really wished for and liked the fact that something is going on locally, that ‘hey, they are actually measuring the water quality’. This generalisation was supported by less-abstract inferences and observations, such as quoting specific users (‘this one lady in particular was very delighted to see that ‘oh, they are measuring it here’, ‘oh, it’s really nice and I really want to help because it’s happening here in my local area’) and describing tangible behaviour (‘even a cyclist stopped to look at it and then moved on’). The team also used a metaphor to further elaborate on the generalisation: ‘it’s not something like, you are reading the newspaper and it’s only at the end, only if you’re bored you get to the part where they say that there was water quality measuring going on. Here, they could see’. The combination of generalised insights and tangible learnings gave user-centred arguments more transparency.

The midscale-performing cases did not move between data and generalisations when discussing users and stakeholders, instead only reporting data. For example, Team Tennis recounted various observations of user behaviour around the prototype, such as ‘they were taking photos’, ‘three people actually played and ‘people just gave the racket to us and then left’, but failed to voice generalisations based on these statements. Team Farming explicitly referenced difficulties in generalising: ‘we don’t know what we learned, we don’t know what it means if no-one bought anything or if everything sold out’. Thus, cases in the midscale-performance category were less effective in building user-centred generalisations.

The midscale cases traced their inability to generalise user-centred knowledge to suboptimal method choices and goals. Team Tennis acknowledged that their test had failed to produce relevant learnings due to various reasons, such as the wrong type of participants (‘we needed people with time, so for example tourists would have been perfect’), the weather (‘the ground was wet, and I think the ball is probably still wet’) and the prototype setup (‘I guess we would’ve needed a more proper setup anyway, as this was kind of sketchy’). Team Farming expressed troubles in planning prototyping and testing (‘we didn’t know which ideas we should make a prototype out of’). While Team Farming wanted to understand users and to design valuable solutions (‘[our focus in the test was too broad] so that we could finally find the key needs so that we can start focusing on something and not go all directions’), they did not know how to do it.

System design: scoping and sensemaking by grouping users

In the system design phase, cases in both performance categories moved between generalisations and data, akin to high-performing cases in the concept development phase.

Also, all cases now grouped users and stakeholders, displaying distinct needs, problems and value propositions for each group. In the high-performance category, Team Tennis at T3 had bracketed users by age and role in the tennis community: young players, middle-aged players, tennis coaches, casual players, competitive players, and tennis club and federation representatives. Thus, the team was able to define distinct types of value that their solution conjecture, a digitally run tennis cup, could provide for each group, such as ‘the value for most casual players is this matchmaking [feature]’, ‘for younger people, the badges, points, statistics, are more motivating’ and ‘[a local club manager] is looking for solutions that would help in engaging the more casual players in the club’. Similarly, Team Water in T2 explored potential value to two user groups, planning to tailor their solution to one or the other: ‘we have to make a decision of whether we’re going to cater [the solution] to citizen scientist groups or if we are still going to try to do something with outdoor enthusiasts’.

While some user groups were portrayed stereotypically (such as younger tennis players liking gamification elements), the grouping brought structure to the design projects, thus supporting further design work. Grouping acknowledges the existence of distinct perspectives and proposes that certain group characteristics create specific cognition, emotions and behaviours in the group. For example, Team Farming in T2 had defined two target groups: ‘farmers that are planning a project, like building a new cowhouse’ and ‘farmers who already have done or are doing a similar project’. They also specified distinct values to both groups, such as the former wanting ‘more knowledge’ and latter always having ‘time for other farmers, since the days go by faster on the tractor if they’re talking to someone’. In this high-performing case, the team further specified interactions between the two groups (‘sometimes they call unknown farmers, sometimes farmers they already know’) and general characteristics beyond the groups (‘they used the old kind of phones’). Detailed user groups also helped identify knowledge gaps and target future user research efforts, with Team Water in T2 describing how they had not ‘talked in-depth with citizen scientists’, a potential user group, but would have ‘at least two video calls with [them] next week’. Overall, grouping users helped high-performing cases scope user research efforts.

However, while cases in the midscale-performance category had narrowed their focus to specific groups, they had not considered the perspectives of some user groups central to the design problem, causing challenges in solution development. For example, Team Finance in T2 had tested a system to market sustainable businesses primarily with business owners, omitting consumer perspectives. While summarising that ‘the idea of free advertising for [small and medium enterprise owners] is fantastic’ along with various aspects that business owners would wish to highlight about their companies, consumers were considered only as recipients of information rather than as a group whose perspectives should be understood: ‘we’d show this info on the window so that all customers could see it’. The team also proposed future work that repeated this stereotypical view of consumers: ‘we thought we might set up a prototype of these ads to see if people passing by look at them’. Ultimately, the team did not know if their solution was valuable or not due to having omitted the consumer perspective: ‘we still don’t know if this will actually make a difference, whether people will go and buy stuff from these stores, or if this will be just another one of those websites or stores that open and then shut down because nobody goes there’. Thus, informed solution design in the system design phase required that teams had identified groups that were central to their solution conjecture.

Detailed design: less moving between generalisations and data, and increased use of nonuser-centred arguments

In the detailed design phase, cases in both performance categories moved between generalisations and data as well as scoped perspectives through user grouping, akin to the high-performance category in the system design phase. However, high-performing cases differed from midscale performers by occasionally omitting generalisation and using nonuser-centred arguments in scoping.

First, instead of moving between generalisations and data, the high-performing cases restated users’ comments and experiences regarding detailed solution features, and immediately moved to using the perspectives in creative processing. For example, Team Water in T5 got requests for added features, which they simply listed as: ‘[a citizen scientist] wished to add some contextual data, for example, what is the weather situation, algae concentration, ….’ When new user information was focused on detailed aspects of the solution, teams may have been able to quickly assess its relevance and put it to use.

Second, instead of scoping understanding through user groups, high-performing cases used project-centred arguments. These included dismissing solution-incompatible comments as minor limitations, deferring them as aspects to work on if the solution was developed further by the client company, and ruling some areas out of scope due to time and other resource limitations. For example, Team Farming in T4 explicitly assigned boundaries to the types of user understanding needed by saying that ‘documentation is not the point of the project’.

In contrast, the midscale-performing cases in this phase adhered to patterns similar to the high-performance category in the system design phase, focusing on generalising user perceptions about the solution. While the cases now specified pertinent user groups, they did not shift their focus onto detailed design. For example, Team Finance in T4 had established the value of their solution conjecture to users by moving between generalisations and data (‘[business owners said that] this [solution] is something they’ve never seen, that it is great to have all this data in one place, and that this helps them find new market areas”), but had not resolved the specifics of delivering this value (“we are struggling with what [types of data] we should add and what [business owners] want’).

4.3. Using perspectives in creative processing

Table 5 shows an overview of how using perspectives in creative processing was carried out and changed through project phases and performance categories.

Table 5. Overarching patterns and developments in using perspectives in creative processing

Concept development: generalising, improving concepts and articulating value

The use of user and stakeholder perspectives in creative processing could be seen in generalising user-centred knowledge, planning improvements for solution conjectures and defining the value of solution conjectures.

First, high-performing cases in T1 used user perspectives to make user-related generalisations. Specifically, these cases modelled user cognition, namely their thought processes and boundary conditions for decision making. For example, Team Water outlined how to design a sign to encourage people to participate in water quality measurement: ‘first you have to capture people’s attention, then you have to show them that ‘if this happens, then do this’ and then you have to give them instructions, all in the same sign’. Similarly, Team Finance described how price and distance were key influences on how consumers make small purchasing decisions: ‘even though it’s double the price, if [the price of a cinnamon roll] is one euro or two euros it’s so little that if there’s distance [involved], the price doesn’t really affect the decision’. For midscale cases, narrow research foci and suboptimal methods limited user-centred learning, leading to limited capability in applying user perspectives further.

Second, the high-performing cases used user perspectives in improving solution conjectures. Here, the plans presented were actionable and practical, including statements about modifying the solution design (Team Finance: ‘how about we make six choices, like when you go and register your company, you’d have six different [support packages to choose from]’) or focusing on a new aspect of the solution in future work (Team Water: ‘how do we [from the user’s point of view] connect two things that would [physically] be separate’). Further, these teams came to the review sessions having already iterated on their solution conjectures based on user research. For example, Team Water had changed the wording and layout of a sign indicating water quality measurements could be done by passers-by. Midscale cases did not evidence iterations in their review sessions.

Third, high-performing cases used perspective taking to define the potential value of solution conjectures upfront. For example, Team Finance justified solution designs with hypothesised limitations of existing solutions from the perspective of the user (‘it’s not personal nor interesting [to the user]’), users’ unmet needs and frustrations (‘we have heard over and over how hard it is [for business owners] to find time for themselves) and benefits of the new solution (‘we wanted to show [users] that we care about them). In contrast, midscale-performing cases primarily described expected behaviour with their respective prototypes.

Despite their shortcomings in gathering data to form user perspectives, the midscale-performing cases tried to use human-centred reasoning in creative processing. However, rather than referencing specific user insight, these cases often resorted to egotistical or stereotype-based reasoning. For example, Team Farming highlighted a generic farmer comment on pricing, ‘it’s too expensive to buy fertilizer’, and claimed that their prototype was meant to sell fertiliser for a cheaper price in smaller quantities. When questioned by the reviewers about whether smaller containers of fertiliser would be useful for farmers, the team changed their target user on the fly into people with home plants: ‘this is enough for one flower. At least in my home we don’t have that many flowers that I would want to buy the whole package of fertilizer. So that’s why we went with a bit tinier scale’. This indicates that the team had not built a path from what they knew about farmers’ behaviour and cognition to how their solution conjecture would provide value, and were instead reverting to egotistical reasoning about their own needs. Team Tennis, in turn, reverted to stereotypical reasoning when hypothesising that ‘general tennis fans’ would get excited by a pop-up tennis court.

Both midscale-performing cases referenced the time pressure from course deadlines as a reason for limited perspective taking: ‘we didn’t have time [to iterate]’ and ‘we were so last-minute’. Together, suboptimal method choices and pressure to deliver made the midscale cases resort to making, as Team Farming put it, ‘something to show’ because ‘it is better than nothing’. In contrast, despite operating on the same timeline, cases in the high-performance category found ways to extrapolate knowledge from the user perspectives they had formed. For example, Team Finance was able to establish other-oriented value statements concisely, such as ‘we were thinking about what a personal care item would be for a business, and one of us thought it was a massage. You know, business owners are so tired, especially […] when they work on their own, they have no time to take care of themselves’. This shows generalisation of user cognition (no time to care for self) and what the team’s hypothesis for value is (a massage coupon will work as a personal care item).

System design: emphasis on improving solution conjectures

In the system design phase, cases in both performance categories referenced user perspectives in creative processing akin to high-performing cases in the concept development phase. The performance categories were differentiated by their ability to voice plans for improving solution conjectures.

Here, cases in the high-performance category voiced plausible design directions based on what they had inferred about users, such as ideas for modifying the solution design or shifting user research in a different or more specific direction. For example, Team Water in T3 pointed out not only challenges in their solution design, such as users being confused about when to look at a mobile app and when to handle the connected sensor, but also proposed concrete ways to remedy these shortcomings, such as ‘you [could] use the application in a way that you turn it on and set ‘measure now’, then you can put your phone in your pocket or leave it at the shore, then you can go and do the measurement, and then this device will indicate to you with a sound signal and a light that it has now done the measurement, and then you can just pick it up and all the data will automatically be in your phone’. This quote shows that the team had a detailed vision of how to improve their solution conjecture based on users’ perspectives.

In contrast, midscale-performing cases only made user-related generalisations or established the value of their solution conjecture, failing to voice specific plans for improving it based on user insights. This was exemplified by Team Finance in T3: ‘this [solution] would be useful for businesses who are starting up, who don’t have these established systems’. While this finding could lead the team to, for example, tailor their solution towards businesses who are starting up, the team did not describe such plans even when directly prompted, as they had not investigated such businesses. Curiously, in the concept development phase, Team Finance had voiced several promising plans tied to user perspectives. In the system design phase, the team partly resorted to binary (yes/no) statements about the solution’s usefulness rather than voicing underlying needs or structured insights. In T3, the team explained these shortcomings with time pressure (‘we had so little time that we didn’t have a chance to [test with customers] yet’, ‘this was basically created in 24 hours’). Team Tennis in T2 also echoed similar explanations: ‘we aren’t yet finished with this [testing]’. While the midscale-performing cases in this phase did not explicitly admit to doing user tests solely for the sake of course deliverables, the time pressure may have forced them to build and test new versions of the solution conjecture faster than they could decide on what aspects truly needed testing and refinement.

Detailed design: focus on specificity of improvements and value delivery

In the detailed design phase, cases in the midscale-performance category showed similar patterns as high-performing cases in the system design phase. Cases in the high-performance category instead omitted generalising user-centred knowledge, focusing on specific improvements for the solution and convincingly describing how it could deliver value.

First, generalisations were overall less numerous in the detailed design phase than in prior phases and were only made by midscale-performing cases. For example, Team Finance in T4 described how small and medium enterprises carry out social media marketing.

Second, while cases in both performance categories highlighted necessary improvements in their solutions, the high-performing cases focused solely on specific improvements. For example, in their high-performing T5, Team Water described needing to improve the audiovisual signals their device gave: ‘we haven’t exactly figured out what sound [the solution] will make, but it’ll be something less concerning for when it connects, and when you lose the connection it’ll be more annoying’. Team Farming in T5, despite being a midscale-performing case, showed similar attention to detail: ‘it’d be good to have a marker for if a pesticide is dangerous for bees, because farmers don’t want to kill them since it influences yield’. However, the midscale-performing cases admitted that significant portions of their solutions were not yet functional, making it possible that the teams would unearth new needed improvements. For example, when asked whether their prototype was using real data, Team Farming in T5 responded by listing a plethora of aspects yet to be built, including creating ‘simulated data’, ‘farmer profiles with built-in fields’ and the capability to spot pests and see live suggestions from other users. In contrast, Team Finance in T5 had a prototype of a website in which they used real statistics on consumers and small businesses from an official statistics bureau. Thus, the functionality of prototypes influenced how final and polished the proposed improvements were.

Third, while cases in both performance categories established the value of their solutions through user perspectives, the high-performing cases did so more convincingly. For example, Team Water in T5 minimised their solution’s limitations and highlighted positives (‘even though the people we interviewed saw some of these practical problems, they really appreciated the opportunity to expand the usability of the product’) and expressed what users can get from the solution (‘[with this product] they can keep track of and capture data in a more meaningful way’, and ‘[this product] could help the citizen science group reach level two, where their data will be accepted by [country]’). Similarly, Team Finance in T5 had specific taglines (‘it’s a toolkit guiding small businesses to success in a changing environment’) along with positive feedback from the client company. In contrast, Team Tennis in T5 had a bleaker outlook: ‘people said they would use it maybe, well, once or twice. Maybe with extra features they’d use it more often, but it depends on what those features are…’.

5. Discussion

This study investigated how novice design teams used perspective taking to understand users and stakeholders and how perspectives were used in solution design. Despite perspective taking being a central part of human-centred design (Hess & Fila 2016), its mechanisms are not yet fully understood. Especially, novice designers have been reported to both succeed and falter in their perspective taking efforts (Sugar 2001; Scott 2008; Smeenk et al. 2016), suggesting that a more nuanced understanding of their processes is needed. In this study, perspective taking patterns were analysed under three dimensions: data collection to form user perspectives, scoping and making sense of perspectives and using perspectives in creative processing.

5.1. Summary of findings

Perspective taking patterns differed across project phases and novice design teams’ intermittent performance. In data collection to form user perspectives (Table 3), in the first two project phases, cases in the high-performance category focused on understanding user cognition, emotions and behaviour. In turn, midscale performers struggled to investigate user cognition and emotions as well as to find the right users to study. In the detailed design phase, cases in the high-performing category collected increasingly specific user data and focused on solution implementation, while midscale performers collected more general data on user cognition, emotions and behaviour.

In scoping and making sense of perspectives (Table 4), in the first two project phases, high-performing cases moved between user-centred generalisations and data (in the concept development phase) as well as scoped future design efforts by defining user groups along with their specific cognition, emotions and behaviour (in the system design phase). In contrast, midscale-performing cases presented only pieces of data (in the concept development phase) and omitted key user groups. In the detailed design phase, high-performing cases omitted moving between data and generalisations and used nonuser-centred argumentation in scoping decisions, while midscale-performing cases showed patterns akin to high-performing cases in earlier phases.

In using perspectives in creative processing (Table 5), in the first two project phases, cases in the high-performance category generalised user-centred knowledge, using it to plan improvements to and establish the value of solution conjectures. Midscale-performing cases, instead, used egotistical and stereotypical reasoning (in the concept development phase) and struggled in detailing plans for improving solution conjectures (in the system design phase). In the detailed design phase, high-performing cases omitted user-centred generalising, instead focusing on specific user-centred solution improvements and value statements. In turn, midscale-performing cases made user-centred generalisations, with their solutions requiring more significant improvements and their value statements being less convincing than those of the high-performing cases.

5.2. Overarching patterns in perspective taking and team performance

Two overarching observations can be made from the findings, contributing to understanding failure in perspective taking and to design-phase-specific perspective taking.

First, the current study reveals several challenges novice design teams faced in creating and applying perspectives. The performance category of three of the four teams changed throughout the design project, with only Team Water placing consistently in the high-performing category. Our findings show how the teams’ shortcomings could be traced to perspective taking – initially in gathering and building user understanding, and later in using user-centred knowledge to design and build a valuable solution. Still, the issues faced by each team were unique. For example, Team Finance was high performing in early exploratory design but struggled in using perspectives in creative processing in the system design phase. Team Farming was the opposite, struggling in early exploratory design but learning from their early mistakes, both constructing and using user-centred knowledge in the system design phase. Thus, perspective taking in design can fail in different ways. Team Farming in concept development, alone, failed in multiple ways: being unable to generalise meaningful characteristics of farmers (Dorst 2011), choosing nonimmersive prototype testing methods (Zoltowski et al. 2012), using egotistical instead of user-centred reasoning (Epley et al. 2004) and ultimately understanding users inaccurately (Chang-Arana et al. 2020a, b).

The results also suggest that initial failure in perspective taking does not necessarily compound throughout the design process. For example, Team Farming was able to recover from poor perspective taking in the concept development phase, and Team Finance delivered good results at the end of detailed design despite struggling in system design. This suggests that high-quality perspective taking at a given point in the design process can mitigate shortcomings in previous phases. Conversely, high performance at an earlier design phase did not always lead to high performance in subsequent phases. Overall, this study specified distinct ways in which perspective taking in novice design teams can fail, but more research is needed to investigate the temporal and causal processes of perspective taking failure.

Second, the results reveal interesting dynamics in the changing scope and nature of perspective taking across different design phases. Midscale-performing cases often displayed perspective taking patterns characteristic to high-performing cases in prior project phases. Such ‘lagging behind’ suggests that different phases require distinct types of perspective taking. Further, novices may struggle in either keeping up with the project pace or matching perspective taking behaviours to the design phase. Acknowledging these patterns may support design educators in guiding project-based learning.

Also, high-performance perspective taking changed at each project phase. It was connected in the concept development phase to depth and breadth exploration, in system design to in-depth exploration within a specified and purposeful scope, and in detailed design to narrowing down and ‘freezing’ the previously explored perspectives. Past research has shown that design experts will sample depth-first exploration approaches to probe for solution viability and feasibility (Ball et al. 1997). The current results suggest that in the context of perspective taking, managing tradeoffs between exploration depth and breadth on the one hand, and perspective application depth and breadth on the other hand may represent a key area of design decision making. Similarly, past studies have shown design experts to engage with preliminary evaluation earlier than novices in developing design solutions (Ahmed, Wallace & Blessing 2003). In the current study, this can be compared to the earlier manifestation of perspective scoping and sense making for higher-performing cases compared to midscale-performing cases.

5.3. Limitations and future research directions

This study used a graduate student project dataset, which limits its generalisability. Our results reflect novice design teams whose members had little project-specific knowledge at the start. The collected data are also limited to proof-of-concept-level product and service design, not including initial user research phases nor later refining of designs into market-ready offerings. More research would be needed to investigate the extent to which the found perspective taking patterns appear in professional and experienced design contexts as well as in earlier and later phases of the design process. In light of the current study, the effects of perceived time pressure – a variable that has eluded many existing research (e.g., Kouprie & Visser 2009; Oygür 2018) – could be a particularly interesting variable to explore in such studies.

Also, much of the design process happens outside review sessions. Our dataset did not include observations or documentation from the time that the teams conducted practical design tasks, such as concept generation, user interaction and prototype building. While observing review sessions provided a summary of the teams’ key processes and the final rationales they reached, more targeted studies could uncover valuable practical processes of design teams’ internal user-centred negotiations, such as selecting who to interact with and what user information to use and how. Hence, micro-level studies of perspective taking would be a valuable avenue of future work. Data from the users and stakeholders could also enable evaluating the accuracy of the generated perspectives and generalisations formed based on them. Experimental studies, in turn, might investigate how changing the amount and salience of available time influences student and professional designer perspective taking.

6. Conclusion

This study investigated perspective taking in user understanding and solution design, within the design processes of novice teams. Based on a longitudinal study of four design projects, we describe how perspective taking manifests in novice design processes, changing by project phase and by team performance. Overall, perspective taking manifests through three aggregate dimensions: collecting data to form user perspectives, scoping and making sense of perspectives and using perspectives in creative processing. In earlier exploratory design phases, high-performing cases focused on exploring perspectives in breadth and depth, while midscale-performing cases struggled in data collection and by extension in both learning and applying user-centred insights. Later, in detailed design, high-performing cases narrowed down their perspective taking in favour of implementation activities, while midscale-performing cases explored user perspectives to guide solution design. This study also showed that novice design team performance varied throughout the process, supporting the notion of different types of perspective taking being necessary at different design phases. Also, midscale-performing cases were generally ‘lagging behind’ in their perspective taking patterns, suggesting that novice designers struggle in keeping up with project pace and matching their perspective taking approaches to the design phase. These findings build nuanced understanding of perspective taking in user-centred design processes and can support project-based design education.

Relevance to design practice

High-quality perspective taking hinges initially on collecting broad user data and accurately making sense of it, whereas latter phases call for narrowing down the focus of activities and following through on the implications of prior perspective taking on the design solution.