1. Introduction
Design, celebrated as “creative problem solving” (Cross, 2000), entails the excruciating task of clarifying various needs and constraints to identify potent problems and functions, and generating a crisp List of Requirements (LoR), prior to the exciting activities of conceptualisation, prototyping and testing. However, requirements are ever evolving owing to changing contexts and circumstances, and are subject to technological, material and process, legal and regulatory, economic, environmental and social considerations (Reference Pahl and BeitzPahl and Bietz, 1996). The LoR serves as the bridge between the phases of problem finding and solution seeking, defining the problem to be addressed and in turn, outlining the vision of the intended solution.
During design of multi-faceted solutions, such as, assistive devices (ADs) for people with special needs, this task of need gathering and requirement generation is especially harrowing as these solutions are more than technical products, and are increasingly viewed as Cyber-Physical-Social Systems (CPSS), systemically integrated with various tangible and digital solutions and services. Furthermore, these solutions often need to cater to multiple-users, and due to the inherent complexities of the 'special need', designers struggle with accessing the stakeholders and empathising with the users (Reference Hwang and ParkHwang et al., 2018; Reference Smith, Scherer, Cooper, Bell, Hobbs, Pettersson and BauerSmith et al., 2018; Reference Teleman, Svedberg, Larsson, Karlsson and NygrenTeleman et al., 2022). Additionally, customisable solutions are sought for context-specific needs (Reference Perera and RanasinghePerera et al., 2018; Reference Santos and SilveiraSantos et al., 2020) and inaccurate or incomplete needs and requirements often result in ineffective solutions (Reference Blanco, Berbegal, Blasco and CasasBlanco et al., 2016). To mitigate this, multidisciplinary expertise and diverse lived experiences are leveraged through collaborative design with users, caregivers, therapists, rehabilitation professional, clinicians, makers and service providers to not only ideate solutions but also collaboratively analyse needs (Reference Sarmiento-PelayoSarmiento-Pelayo, 2015; Reference Aflatoony and LeeAflatoony and Lee, 2020; Reference Cash, Dekoninck and Ahmed-KristensenCash et al., 2020).
Participatory Design (Reference Baek and LeeBaek and Lee, 2008), co-Design with end-users (Reference Pires, Neto, Brulé, Malinverni, Metatla and HourcadePires et al., 2021) or key stakeholders (Reference Dursun and PedgleyDursun et al., 2021; Reference Acharya, Bhatt and ChakrabartiVenkatesh and Acharya, 2023) is the common approach, yet, the “art of eliciting (customer) needs” for people with special needs, especially children, remains unmastered.
Thus, this paper focusses on the challenges of eliciting requirements for children with special needs and presents an empirical attempt to develop a robust and comprehensive reference resource in the form of a 'Master List of Requirements' for supporting design for children with special needs. This research is a subset of a larger body of work aimed at supporting multi user co-design for design of assistive CPSS for children in resource-constraint settings.
2. Literature review
2.1. Needs, requirements and criteria
Needs are at the crux of the problem, and maybe functional or non-functional, physiological or psychological, social or technical, with regard to time or resource (Roozenburg and Eeckels, 1995; Cross, 2000). While few needs are obvious and explicit, many are implicit or latent and most are independent of the possible product outcome (Ulrich and Eppinger, 2012). Literature widely concurs that to produce better solutions, needs should be elicited and gathered, appropriately formulated into requirements, which in turn should be clarified and prioritised, as is done by 'successful' designers (Reference Pahl and BeitzPahl and Beitz, 1996; Ulrich and Eppinger, 2012; Cross, 2000). Needs are the implicit asks of the users, often captured as statements, while requirements are the interpreted needs qualified with values that enable designers to ideate, whereas criteria arise from 'interest of stakeholders' and are envisioned as the ideal against which all other requirements and solutions are benchmarked (Ulrich and Eppinger, 2012).
Roozenburg and Eekels (1995) explicate the interdependence between requirements and criteria, the latter being the benchmark to assess whether the requirements are met satisfactorily, and prescribes a checklist method outlining criteria with associated questions as prompts to help designers formulate the required standard and further, evaluate the solution variants with respect to it. With the goal to ensure that no needs are missed and to provide a “fact base for justifying the product specifications”, Ulrich and Eppinger (2016) prescribes a five-step method for comprehensively identifying needs, provides guidelines for correctly writing the interpreted needs statements, and recommends ways to establish relative importance of needs, through design teams consensus or customer surveys. Pahl and Beitz (1996) similarly, emphasises that each requirement in the list must be individually deemed as 'demands' and 'wishes', to instil the gravity of the requirement in consideration, and prescribes a layout for the LoR.
2.2. Eliciting requirements for children with special needs
While designing ADs for children, designers often prioritise technical and functional aspects over usability from the child's perspective, which may negatively impact their well-being (Reference Dursun and PedgleyDursun et al., 2021; Reference Pires, Neto, Brulé, Malinverni, Metatla and HourcadePires et al, 2022). Design for children with special needs (DfC*) is a class on its own and sits at the intersection of DfD or 'Design for Disability' (Reference Hwang and ParkHwang et al., 2018) and DfC or 'Design for children', each of which heavily relies on nuanced contextual consideration and direly lacks support. DfD focusses on the design approaches across varied disabilities, while DfC has the specific interest of children as users, whether disabled or not, as this stakeholder has unique needs and requirements to be considered as is. Interventions designed for children with special needs, whether products, services, or other solutions, are typically multi-user-centric, and must not only address the needs of the child but also consider the needs of key stakeholders, such as, family members and caregivers and clinicians (Balzan et al., 2019; Cappelen and Anderson, 2021; Cabral et al., 2022). Furthermore, designing with children, whether with special needs or not, pose unique challenges as children can't offer clear, consistent, and constructive feedback in spite of participatory approaches (Baek and Reference Baek and LeeLee, 2008).
User elicitation techniques (20. Dursun et al., 2022), tools like the Design Library for Wearables aiding modular design (Rosen et al., 2024), and the USERfit framework (Poulson et al., 2011) offers a structured approach to integrating user needs throughout the design process, but is not specific to children. Venkatesh and Acharya (2023) propose a multi-user centric co-design process, mCoDe, to design ADs for children with special needs where custodians of the child, like the clinician and therapist, who are also often secondary users themselves, behave as 'proxy primary users' on behalf of the beneficiaries and partner in the design process. However, the challenge of identifying needs, interpreting the same to requirements and enlisting a crisp, prioritised LoR continues to be a challenge for designers while designing for children with special needs (Venkatesh and Reference Venkatesh and AcharyaAcharya, 2023).
Thus, to address the various knowledge gaps pertaining to eliciting requirements for this special needs group, it is hypothesised that a knowledge support in the form of a master List of Requirements for children with special needs is a potent resource for designers while designing assistive CPSS.
3. Methodology
The objective of the empirical study is to collaboratively develop a master LoR for designers, by designers, and verify it through the lens of existing seminal literature prescriptions for requirement generation, to ensure development of a comprehensive support.
Thus, a two-phase approach was employed to emulate elicitation of requirements. First, a preliminary master LoR is generated by novice designers under the supervision of researcher/facilitator, followed by experienced designers verifying a sample of the same with respect to comprehensibility and appropriateness. Both, Phases 1 and 2, were closed with a reflection and discussion session.
Phase 1 (as in Figure 1)- Need gathering and Requirement generation by Novice Designers
Aim: To develop a preliminary master LoR for 'design for children with special needs',
Subjects/ participants: Novice designers; students in 1st year of Masters in Design (M.Des.) program hailing from varied background of engineering, architecture, industrial design, fashion and fine arts.
Number of participants: 63, in 10 teams with 6-7 members each.
Pre-requisites: The subjects were exposed to the prescriptions from literature, namely; 5-step method and guidelines by Ulrich and Eppinger (2012), ‘Checklist' of 25 Criteria by Roozenburg and Eekels (1995), and 'layout for LoR' by Pahl and Beitz (1996), and instructed to use the same.
Task: (i) To enlist 'needs' from various reliable sources, (ii) To interpret them to requirements, (iii) To tag them to appropriate Criteria, and (iv) To prioritise them either as Demand or Wish.
Tools provided: A template excel sheet with columns titled, 'Needs', 'Interpreted Needs / Requirements', 'Criteria' and 'Demand or Wish'. Additional sheets to; document the details about the special need in focus, the user context, and their corresponding sources such as, research paper, report, expert interview, market survey, etc.
The Teams also had access to researchers to facilitate and mentor through discussion throughout.
Outcome: A List of 160 unique Requirements
Phase1: Need gathering and Requirement generation by Novice Designers
Figure 1. Methodology of Phase 1 - Development of a preliminary master LoR
Figure 2. Methodology of Phase 2 - Verification of the preliminary master LoR
Phase 2 (as in Figure 2)- Requirement verification by Experienced Designers
Aim: To verify a representative sample of the developed preliminary master LoR for 'design for children with special needs', with respect to comprehensibility and appropriateness of tagging, via consensus.
Subjects/ participants: Experienced designers; students in 2nd year of Masters in Design (M.Des.) program hailing from background in engineering, and pursuing design of assistive devices for various special needs, such as, learning disability, vision impairment, motor impairments, etc.
Number of participants: 6 designers, i.e., 10% of the subjects from Phase 1.
Pre-requisites: The subjects were also exposed to the prescriptions from literature, namely; 5-step method and guidelines by Ulrich and Eppinger (2012), 'Checklist' by Roozenburg and Eekels (1995), and 'layout for LoR' by Pahl and Beitz (1996), and have used the same previously.
Task: (i) To 'modify or refine' the enlisted requirements with respect to appropriateness or comprehensibility, (ii) To map 'Criteria', up to 3 in no particular order, (iii) To prioritise as Demands and Wishes, and (iv) adding other information on design class, (DfD, DfC or DfC*), where in the context of this paper, DfD refers to The requirements for designing solutions for people with disabilities (irrespective of the age group), DfC refers to the requirements for designing solutions for children and DfC* refers to the requirements for designing solutions for children with special needs, user type (primary, secondary), user group (parent, clinician, child, etc.), intended outcome (Product, Service, system) and type of special need.
Tools provided: A template excel sheet similar to Phase 1, with a random sample of 48 Requirements enlisted, surmounting to approximately 35 % of the list generated by novice designers, with additional columns to capture other information as described above in Task.
Additional Pre-task activity: A focus group discussion was conducted with the experienced designer to ascertain their experience and understanding.
The following questions relevant to LoR generation was asked;
-
How to identify/generate various needs and requirements in the design process?
-
What are the different sources used to identify needs?
-
How to prioritise requirements?
-
What are the challenges faced in the process of generation of requirements?
4. Results and findings
4.1. Phase 1 - preliminary master LoR
A total of 160 unique requirements were generated by novice designers, and mapped to 20 out of the 25 criteria, as in (Table 1). A set of these preliminary requirements are presented with corresponding criteria mapped as an example in (Table 2).
Table 1: Teamwise data of requirements generated per criteria in phase 1
4.1.1. Findings and inferences
The 10 teams of novice designers started off the task with choosing a specific 'special need' as focus, such as, down syndrome, ADHD, hearing impairment etc.
To further narrow down the scope, each team scoped the problem, the user contexts and key stakeholders.
All teams ended up considering parents, special educators, specific clinicians such as occupational therapists, physiotherapists as the target user group and highlighted the importance of involving key stakeholders.
Designers used literature review and product/market survey as primary sources for requirements identification for the chosen disabilities.
A few teams undertook primary research in the form of interviews with stakeholders to gather needs and translate them to requirements and a few used YouTube videos, blogsites, and web sources to further understand users and their needs.
Designers found the Roozenberg and Eekles (1995) Checklist Method useful as a prompt for identifying needs and to generate requirements.
As observed, ‘Performance’ criteria had the maximum number of requirements generated (31/160), whereas, a few criteria, such as, Manufacturing facilities, size and weight, after use and product liability, did not have any requirements populated.
It was also observed that many requirements (22 requirements) were mapped to ‘others’ sections. For example; ‘The solution must prevent fatigue and promote sustained attention’ was mapped to ‘others.’
Any requirement targeting multiple stakeholders like children, parents, clinicians etc were identified as a Demand.
Requirements which are related to the growth of the child, are prioritised, and noted as a Demand.
It was also observed that all the requirements listed in the ‘installation, operation’ criteria have been marked as a Demand as well.
It may be inferred that, design being a goal-oriented activity, requires a focus with respect to the target group or special need to further develop the requirements and that a 'master' LoR is a bold dream. The prevalence of some Criteria much more in number than others may either imply that the subjects were not able to discern the Criteria, or that the sources referred to and the needs gathered were in fact ascribed to only a few Criteria. It may further be argued that perhaps DfC* has larger number of requirements pertaining to certain dominant Criteria in comparison to others.
Table 2: Requirements generated by novice designers in phase 1 - sample
4.2. Phase 2 - LoR verification with experienced designers
4.2.1. Findings from focus group discussion
The experienced designers highlighted various methods employed in generating requirements, such as, direct observations of users, discussions with experts, testing of available products in the market, and inputs from various stakeholders, along with literature review, prior art search, and product survey as secondary sources.
Designers stated that they often validated their own hypotheses and prioritized user needs based on discussion with secondary users/ proxy users, like clinicians.
Designers shared that they used tools, such as, developmental milestones charts, checklists and guidelines to assess current abilities of children with special needs to ensure it syncs with the needs.
All unanimously agreed that the major challenges faced by them included, difficulties in empathizing with users, lack of domain knowledge, and hence, the need for constant validation with experts.
4.2.2. Findings and inferences from task
The experienced designers revised certain requirements provided to them, later stating that those documented by the novice designers lacked specificity and were overtly abstract.
Experienced Designers commented that almost every requirement could be mapped to more than one criterion, however some Requirements had a high level of variability of up to 10 unique Criteria tagged, as notable in the color-coded (Figure 3) and exemplary list (Figure 4).
The experienced designers mapped all 25 criteria to the requirements in the provided list, and stated that the check-list aided them in holistically assessing the requirements across the entire product-life cycle.
Designers also commented that it helped in prioritising certain requirements, which were categorised under ‘safety’, ‘standards’, 'durability', and ‘product policy’ criteria, inherently as Demands due to the importance of designing robust solutions for children.
It was also noted that all the requirements that are about improving convenience of use of the solution were marked as a 'Wish'. For e.g: The materials should be easy to clean, and the software should allow for simple updates with minimal maintenance required'.
Requirements related to visual aesthetics were marked as a ‘Wish’, but few designers considered it to be a priority stating that visual appeal would increase the probability of solution being used by the children.
From the finding that Prioritisation had a better agreement score compared to Criteria mapping, it may be inferred that either the Requirements were abstract enough to be highly generic and widely applicable, and hence, encompassed several Criteria, or that the designers interpreted them subjectively due to varied understanding of each Criterion and its definition.
The designers also commented on a few specific criteria, based on their personal understanding, and made recommendations, as exemplified in the quotes below;
“Looking at the variations and abstractness of requirements from sample list, providing sub-groups, especially for ‘performance’ could have helped novice designers to make the requirement statements more specific”
“The list of criteria could be tailored further for designing solutions for children with special needs”
“Safety should also include safety of the solution and not just the safety of the stakeholder/user”
“Standards are constraints and Demands that the designers must consider while designing”
“Ergonomics should technically be sub-divided into physical, cognitive and organisational”
Figure 3. Variability in Criteria mapped to each Requirement in Phase 2
Table 3. List of Requirements with Criteria mapping in Phase 2 - example
5. Discussions and conclusion
Literature has prescribed methods and tools to elicit needs, interpret them to requirements and prioritise them to enable defining the 'right' problem, which enhances the potential of developing the 'right' solution (Acharya, Bhatt and Reference Acharya, Bhatt and ChakrabartiChakrabarti, 2023). DfC* has several needs at the cyber-, physical- and social- layer of the system, and to alleviate the process, the research presented in this paper undertook the objective of developing a mater LoR for DfC* to aid designers. However, the study emulates requirement elicitation in two phases, first with novice designers to elicit and then with experienced graduate design students to verify the requirements generated, indicates that there lacks a consensus in comprehension and interpretation of requirements and criteria that are key to undertake this objective.
In Phase 1, it was observed that every novice designer team started off with a specific special need (or disability) to start their gathering process, and due to the open-endedness of the task resorted to scoping the problem and use context. They even undertook a stakeholder analysis and narrowed in on a target user, though this was not asked. As the teams captured stakeholder statements from literature, they struggled in wording the needs since most papers reported on the solution and how it meets certain needs. Some teams in fact used the Criteria checklist to identify the requirements, as opposed to what was instructed. Hence, a lot of mentoring was sought, and iteratively through discussion the needs statements were further extracted and noted in the list. Yet a solution-focus has been observed in several requirements. In contrast, when the team elicited needs from primary research, through interviews, they stated that they were able to empathise better and understand the problems and concerns at hand. It was also observed that several requirements were structured such that it stresses on the priority, i.e., starting with 'should' or 'must' and here, too, some solution biases crept in at first with Requirements stated as - “solution must have..”. Another interesting revelation was the teams' outlook on the Class categorisation, unanimously sharing the view that DfC* comprises of DfD and DfC, rather than an intersection of the two as was perceived by the researchers.
In Phase 2, it was observed that every requirement was mapped to more than one criterion by experienced designers who are involved with designing ADs. Of these, some requirements showed larger range of variability than others (min. 3 to max 10 criteria), which could be attributed to the level of abstraction, i.e., highly abstract to highly concrete, at which the requirement is formulated, or to the ambiguity due to subjective interpretation of the Criteria by the designers. They commented that some of the requirements elicited for 'safety and standards' criterion could be taken at face value and applied directly, while others required a deeper interpretation and contextualization by designers, such as the term 'customisation'. Customization depends largely on contextual factors, such as, language, motor abilities, and other user-specific needs, making it inherently broad and challenging to specify. Similarly, certain criteria were found to be more ambiguous than others, like “environment”. The term appeared misunderstood, with some interpreting it as sustainability while others were unsure of what exactly it referred to - the physical, social, or natural environment. In contrast, certain criterion seemed to subsume others, such as, Ergonomics, Materials and Quality could be argued to be sub-sets of Performance. This revealed that, in spite of question prompts available in the checklist, there is a lacuna in the common understanding of the Criteria and what all it defines leading to lack in consensus. Interestingly, the experienced group of designers too took the same point of view as the novice on the Class categorisation, stating that - “if it works for DfD and DfC, it'll work for DfC* ”.
Evidently, theoretical knowledge is inadequate a pre-requisite to generate a clarified LoR, as the hands-on experience of implementing the same through the study highlighted several areas that requires support to build a common understanding. The study illustrates the need for clarifying the directives for requirement generation and the definitions of criteria, prior to clarifying the requirement statements to develop a master LoR. However, while divisive directions and concrete operational definitions may reduce misinterpretation and improve usability, the granularity should not impede the creative process of eliciting the needs and requirements. Likewise, the prevalence of variability in tagging the criteria may not necessarily be discouraging, but rather be an opportunity to explore and if needed, expand the view. In contrast, the consensual agreement on the priorities and class categorisation of requirements highlights that the designers do share objective reasoning but have had to negotiate starkly in case of criteria.
In conclusion, while the objective of the study was to present a methodical approach to developing a knowledge support in the form of a master LoR for designing CPSS for children with special needs, the findings highlight the hurdles future-designers face and necessitates revisiting available prescriptions, methods and terms. Future work entails questioning what lead to such diverse views on otherwise objective Criteria and Requirements - the open endedness leading to ambiguity or the level of abstractness, and are the two independent? The mLoR also requires to be tested and validated in real-life design scenarios.
Presently, this study was limited to designers in academic settings, and is intended to further involve expert designers and innovators who undertake DfC*, and clinicians and professionals who are users as well as potential 'proxy' for children with special needs, to gain broader insights and strive towards developing a robust and scalable methodology for requirement generation, alongwith the master LoR, for design of CPSS for special needs.
Open access
