2.1.1. Design specification

The design specification process translates the requirement domain into the physical domain. In MP, this process is to construct how each user will interact with the design. The DPs forming a design template are identified in this step. Using a design template as a starting point of design, customisation or personalisation is a common practice in MC/MP literature. In product family design, the design template appears in the form of a product platform and a set of modular components in a product family architecture (Jiao, Simpson, & Siddique Reference Jiao, Simpson and Siddique2007). Aheleroff et al. (Reference Aheleroff, Philip, Zhong and Xu2019) defined adapting the design over a design template as the most important and value added part of MP. Bingham (Reference Bingham2018) refers to it as ‘seed object’ or ‘seed design’, and describes it as ‘the starting point for all subsequent transformations and is specifically created to allow some form of personalisation by the intended end-user/customer’. A similar definition is also found as meta-design, where designer acts as a facilitator by enabling the user modifications within the open design framework (Boisseau, Omhover, & Bouchard Reference Boisseau, Omhover and Bouchard2018). Lipton et al. (Reference Lipton, Schulz, Spielberg, Trueba, Matusik and Rus2018) proposed MC of carpentry products over a design template to be used by experts, where the proposed method verifies the design and fabricates by robotic systems. Shugrina, Shamir, & Matusik (Reference Shugrina, Shamir and Matusik2015) suggested a method to convert any parametric model to a seed design for online product configurators with which the user interacts in real time. The user is exposed to a few parameters to interact with, and real-time feedback of validity of the designs and valid parameter bounds are given to the user. From here on in this paper, the ‘seed design’ term is used to refer to design templates that users interact with. The definitions and examples of seed design have been highlighted by several authors, but how it should be designed for MP was not covered.

Despite not conceived for MP, axiomatic design (AD) can support the transformation process from customer domain to functional and physical domains. AD theory brings a systematic method to the design specification process (Suh Reference Suh2001). With a top-down approach, the variables of design domain (customer, functional, physical and process) are decomposed to clarify the design task. The domains are mapped to each other with the reasoning of ‘what to achieve’ and ‘how to achieve it’. According to AD, to achieve the best design solution, the independence and information axioms must be followed. The independence axiom suggests maintaining the independence of FRs by appropriate selection of DPs. Only uncoupled or decoupled design cases satisfy the independence axiom. The aim is to reduce the complexity, and thus avoid unintended consequences in the design solutions. Suh (Reference Suh2001) defines the complexity here as ‘a measure of uncertainty in achieving the specified FRs’. If multiple designs are found according to the independence axiom, then the best design with the minimum information content is chosen according to the information axiom (Brown Reference Brown2020). These axioms are utilised at each step of the decomposition.

Jiang et al. (Reference Jiang, Zhao, Yang, Zhao and Tan2007) explored the use of AD in the functional and physical decomposition of the product family architecture. Tseng, Jiao, & Merchant (Reference Tseng, Jiao and Merchant1996) adopted AD principles for product family design in MC, by introducing a product family architecture, where building blocks are defined to be configured to individual products. Marchesi & Matt (Reference Marchesi and Matt2017) exampled the adoption of AD in design for MC, with a study on the conceptual design of prefabricated housing. Salonitis pointed out the lack of manufacturing considerations in the functional and physical domains of AD, and proposed a modified method focussed on design for additive manufacturing (DfAM) (Salonitis Reference Salonitis2016). In the proposed method, process domain is also included in the zigzag decomposition process of FRs and DPs to include manufacturing guidelines in the early design phase.

As MP is strongly linked to additive manufacturing, it is often considered with a DfAM perspective. In DfAM approach, the process selection is taken as the first step prior to the design process (Zhu et al. Reference Zhu, Pradel, Bibb and Moultrie2017). Spallek, Sankowski, & Krause (Reference Spallek, Sankowski and Krause2016) categorise the development processes as standard individualisation and specific adaptation. Standard individualisation divides the product to individualised and nonindividual components, similar to modular components and common platforms in product family design for MC. While nonindividual components are developed for mass production, individualised ones are developed with a DfAM approach. Specific adaptation is a personalisation case, first the product structure is designed with an individualisation scope, then the design process is repeated for each customer within a fixed solution space, where DfAM considerations are present. However, this is not in a mass context, since the necessity of customer-specific design effort is highlighted. Although the specific adaptation is stated as true product individualisation, the authors underline the disadvantages of the difficulty in developing a seed design and the lack of corresponding knowledge in the literature. Ko, Moon, & Hwang (Reference Ko, Moon and Hwang2015) proposed a computational approach to connect DfAM with custom products. In the proposed method, the interrelations between AM considerations, CNs and product features are identified using finite state automata and affordance. Designing for AM enables integration of multiple functions and their working principles in one part. However, this is in contradiction with the design for variety approach in modularisation, which structures the variety with one-to-one mapping between FRs and components (Spallek & Krause Reference Spallek and Krause2016). Besides, the major consideration of compromising between commonality and variety becomes insignificant with the design freedom AM offers (Lei et al. Reference Lei, Yao, Moon and Bi2016). Consequently, the product family design approach is principally limited in both exploiting the benefits of AM and effective product development for MP.

Design structure matrix (DSM) is another approach to structure interdependences between different domains (Eppinger & Browning Reference Eppinger and Browning2012). Instead of the top-down approach with zigzag decomposition in AD, a bottom-up approach is taken by clustering or reordering elements in the matrix to simplify the design task. DSM is used by some product family architecture methods to decouple the design or to identify different modules by clustering the components (Seol et al. Reference Seol, Kim, Lee and Park2007; Li et al. Reference Li, Cheng, Feng and Yang2013; Bonev et al. Reference Bonev, Hvam, Clarkson and Maier2015). Yu & Cai (Reference Yu and Cai2009) employed DSM to show the hierarchical dependencies among structures and design processes in product family architecture, which is used in the configuration process to create product variants rapidly. Careful consideration of dependencies and correlations among the elements affecting design is important to avoid suboptimal design solutions (Pirmoradi, Wang, & Simpson Reference Pirmoradi, Wang and Simpson2014). Based on DSM, Loureiro, Ferreira, & Messerschmidt (Reference Loureiro, Ferreira and Messerschmidt2020) proposed the design structure network (DSN), a design specification method for MP. The method demonstrates the interdependencies of FRs and DPs visually on a network, decomposes them and suggests principles to manage the network complexity. While being the only truly prescriptive method for MP, DSN explains how to carry out the specification process up to decomposed DPs. In other terms, the DPs to realise the design becomes evident, but how to define or manage the variety is not covered. The previous studies consider the specification process from MC or DfAM perspectives mostly, or propose rather descriptive frameworks.

2.1.2. Design solution

In the design solution step, the requirements of a specific user are transferred to the DPs and a personalised design is obtained. The DPs form a solution space where different requirements can be met. To achieve mass efficiency, effective management of the solution space for the automation of personalised design generation is necessary. Gembarski & Lachmayer (Reference Gembarski and Lachmayer2018) proposed an approach for complexity management of solution space in MC, regarding two dimensions of variety and uncertainty. The approach is based on finding a balance between CNs and portfolio capabilities by increasing or reducing the complexity. The authors also proposed a solution space development tool for geometry-based design tasks (Gembarski & Lachmayer Reference Gembarski and Lachmayer2018). The tool aims to lay out the dependencies between requirements, parameters and restrictions on a matrix to support design solution decisions. Skjelstad et al. (Reference Skjelstad, Thomassen, Sjøbakk, Bakås, Blazek and Partl2018) introduced manufacturing considerations in solution space management for MC to balance the customer and manufacturing perspectives. They also identified solution space archetypes according to product form, fit and function.

The variety of the solution space result in higher design complexity, and this is one of the challenges of MP. In DfMP, the main driver of this complexity is the coupling of the design (Loureiro, Ferreira, & Messerschmidt Reference Loureiro, Ferreira and Messerschmidt2020). While this is not a case in product family design, since the dependence between FRs and DPs can only be uncoupled or decoupled (Gauss, Lacerda, & Cauchick Miguel Reference Gauss, Lacerda and Cauchick Miguel2021). Instead, this variety-induced complexity mainly arises from increasing variants in the product family (Greve et al. Reference Greve, Oltmann, Schwenke, Krause, Gebhardt and Spallek2017). Development of algorithms and approaches to handle this complexity may enhance the configuration process. Multidisciplinary design optimisation is one of these approaches for reconfiguration of the product family to obtain the desired performance and optimal configuration (Pirmoradi, Wang, & Simpson Reference Pirmoradi, Wang and Simpson2014). The literature on how to build a solution space and how to manage it is very limited and more focussed on modular architectures in MC. Besides, as also discussed below, the existing literature focusses more on manufacturing and production planning, rather than the user involvement.

In design for MC, the product portfolio is predefined by customer requirement patterns, and not by considering individual customers, which creates the risk of suboptimal fulfilment of personal needs. This is the result of a solution space with discrete options. The design freedom and production flexibility of AM enables customer-specific designs within a continuous solution space (Greve et al. Reference Greve, Oltmann, Schwenke, Krause, Gebhardt and Spallek2017). The end-product configuration in product family design requires a configuration structure. The generic bill-of-material is a common method to structure the hierarchical relationships of the components (Gauss, Lacerda, & Cauchick Miguel Reference Gauss, Lacerda and Cauchick Miguel2021). It is defined as a tree structure with common and optional nodes to obtain different configurations.

2.1.3. Limitations

The product family design methodologies for MC are mostly developed in the traditional manufacturing technology context, and they propose solutions or optimise processes accordingly (Lei et al. Reference Lei, Yao, Moon and Bi2016). Hence, their considerations or challenges are not necessarily valid for digital manufacturing context. For instance, the assumptions on how commonality and variety affect cost or complexity are no longer valid when AM is used. Similarly, the decomposition of domains and configuration structure are based on modularity and one-to-one mapping between functions and modules. However, AM allows multiple functions in a consolidated part. Hence, the platform and modular architecture is insufficient to develop a seed design for MP in AM context. Although personalised modules may offer a solution to meet individual needs, they are still within a modular architecture, which prevents exploiting the advantages of AM. Lack of customer integration and elicitation of specific CNs are also highlighted in the literature, which is a major pitfall for MP. Moreover, these methodologies do not consider coupled design cases between FRs and DPs. While this is a reasonable approach for a modular architecture, it might be noteworthy to consider coupled cases in the AM context. As decoupling a design in this context might not be as simple or restrict the variety significantly. Consequently, all these drawbacks reflect on the overall development process, and it should be adapted for MP in digital manufacturing context.

The majority of the literature on MP are descriptive frameworks of how MP should be on the system level, and they mostly focus on manufacturing perspective. In terms of guiding DfMP, to the authors knowledge, there is only one prescriptive contribution (Loureiro, Ferreira, & Messerschmidt Reference Loureiro, Ferreira and Messerschmidt2020); however, focussed on only design specification. Therefore, an overarching gap exists in guiding designers in the product development process of the MP paradigm. Different domains subjected to the DfMP process are similar to the traditional product methodologies, and sufficiently well identified. However, constructing these domains and managing their interactions to obtain personalised designs are still present challenges. The lack of knowledge in connecting these domains and structuring a seed design were previously pointed out (Spallek, Sankowski, & Krause Reference Spallek, Sankowski and Krause2016; Bingham Reference Bingham2018). The use of a seed design as a starting point for customer design is stated by several authors; however, how to develop a seed design in MP context has not been elaborated either.

The importance of real-time customer interaction with the design in co-creation is highlighted by several authors (Kumar Reference Kumar2007; Zhou, Ji, & Jiao Reference Zhou, Ji and Jiao2013; Aheleroff et al. Reference Aheleroff, Philip, Zhong and Xu2019). This especially becomes evident in a coupled design case, where the design solution should be iterated. Existing configuration structures do not cover this case, and also limited to the options of modules and components. While some methods introduce personalised components, these are independent nodes in the hierarchical structure, and their variety is not managed in the configuration (Gauss, Lacerda, & Cauchick Miguel Reference Gauss, Lacerda and Cauchick Miguel2021). Multiobjective optimisation is one solution for a coupled case to find the optimal configuration for the user. However, this results in an uninformed design trade-off for the user. For an effective and informed interaction of the user and the design, the co-creation process should link to the physical domain in a dynamic way. The literature is very limited on this; though Shugrina, Shamir, & Matusik (Reference Shugrina, Shamir and Matusik2015) proposed a description, it is limited to the dimensional parameters of the product.

The higher complexity, due to coupled requirements or parameters, in reaching a design solution in MP is another present challenge. While there is also variety-induced complexity in product family design, this is not necessarily on variant configuration, but more of a manufacturing and managerial complexity (Greve et al. Reference Greve, Oltmann, Schwenke, Krause, Gebhardt and Spallek2017). Hence, the differences in considerations is also a major obstacle in applying design for MC methods or solution space management approaches to MP. The increased design freedom that MP provides the user may result in a complexity in the design configuration structure, and this requires a particular attention.

Achieving mass efficiency is an essential aspect of MP. This is well supported by production system automation in smart manufacturing concepts. However, achieving mass efficiency requires manufacturing automation to be supported by design automation as well. Therefore, how the differentiation of personalised designs may be handled for production is rather clear, but how to reach those designs in a mass manner is an open question.

The present work addresses the following gaps, limitations and challenges:

1. (i) Developing seed design for MP in the digital manufacturing context.

2. (ii) Creating and structuring variety through the design of a product incorporating varying functions and design features.

3. (iii) Structuring customer, functional and physical domains and to manage their interactions effectively for MP.

4. (iv) Facilitating real-time user interaction with the design for effective and informed decisions.

5. (v) Managing the complexity in the solution space being inclusive of coupled design cases.

6. (vi) Achieving mass efficiency in generating personalised designs.

There are more challenges and open questions in MP, which are not covered in this work. MP relies on value creation, by not only the product, but also the personalisation process. Therefore, design of the co-creation process focussing on enhancing the user experience is necessary. The level of personalisation or the co-creation methods should be compatible with the product and customer profile. The work on these topics are very limited and, hence, the challenge in customer satisfaction with MP is still present.

3.2.1. Customer needs

Identifying CNs is an essential step in all product development processes. In the traditional means, certain generalisations on the user data are made for each market segment. These generalised needs are then organised into a hierarchy and their relative importance is established (Ulrich & Eppinger Reference Ulrich and Eppinger2012). It is necessary to highlight that ‘needs’ in this context refer to any customer need or desire for the product (Roozenburg & Eekels Reference Roozenburg and Eekels1995). While designing for MP, it is important to understand the differentiating CNs, in other terms, the specific needs. In this case, product-specific clusters of specific needs should be identified, which later define the extent of personalisation offer. The offerings of MP should be unique and personal, hence while setting the personalisable features of the product, the considerations should be inclusive of those needs. Two main pillars of MP are increased customer involvement in design, and the manufacturing flexibility allowing this; the extent of personalisation offering is strictly related to these. The value presented by MP is not only about the personalised product, but also the sensorial, emotional and symbolic values created in the co-creation process (Zheng et al. Reference Zheng, Yu, Wang, Zhong and Xu2017). For a better user experience, providing the appropriate level of personalisation is important (Ozdemir et al. Reference Ozdemir, Van Goethem, De Buysscher, Delrue, Verburgh, Van Gastel and Verlinden2020). The level or extent of the personalisation scenario is also related to the cost and manufacturing feasibility. Hence, the level of personalisation affects both customers and providers, and reaching a trade-off with affordability is necessary for both parties (Aheleroff et al. Reference Aheleroff, Philip, Zhong and Xu2019).

In this context, the CNs are categorised as generic and specific needs. Generic needs are basic expectations of performance in a product. The generic product features answering to these needs are contained in the base architecture of the seed design (Figure 2). Specific needs refer to affective, cognitive or user experience related needs, which are the subjects of MP (Zhou, Ji, & Jiao Reference Zhou, Ji and Jiao2013). The specific needs are fulfilled by the personalisable product features, which may be functional, ergonomic or aesthetical ones. The variable elements of the seed design define these features according to specific needs. The focus of this methodology is on personalisable features, which cater to the individual needs and desires. Therefore, CNs in the following sections refer to personal, specific, needs.

The first step of the process is to identify the top-level specific CNs. These correspond to very broad categories, or descriptions, of possible personal needs. For instance, considering a case of eyewear frames, comfortable fit may be a top-level CN. Here, comfortable fit does not say what will change in the product. It is translated to PRs, and then these are decomposed to more specific requirements. Then these requirements determine what personalisation options will be offered to the user. How to identify these top-level CNs are not in the scope of this work.

3.2.2. Personal requirements

The CNs are in the customer language, and these needed to be expressed in technical descriptions to achieve quantitative relations in the design space. In the transition from customer domain to functional domain, the specific needs are mapped onto PRs. Cognitive task analysis, quality function deployment and association mapping present solutions to transfer these specific, affective-cognitive, needs to PRs in the MP context (Zhou, Ji, & Jiao Reference Zhou, Ji and Jiao2013).

A difference of PR definition in this context, in comparison to FR definitions, is that they do not describe what ‘has to be done’, but rather what ‘can be done’. The point of interest is exclusively specific needs, and PRs express a range of possible requirements. Since the personalised features of the product is defined after the general features, the product has already a base architecture. Therefore, the top-level PRs do not state the design objective of the whole product, and instead they state the personalisation objectives.

The product features corresponding to specific CNs may be categorised as ergonomic, functional and aesthetical (Figure 2). Since these features are defined through the PRs, the same categorisation may also be done for top-level PRs. An ergonomic requirement corresponds to a personal fitting need in this context. Moreover, while functional ones are related to the product performance, aesthetical requirements are to define the physical appearance of the product. While PRs in one of these categories is sufficient for a personalisation case, PRs in all three might be present as well, such as in the footwear example elaborated later in the paper. Whereas, in the saxophone mouthpiece example given later, there are only functional PRs. The reason of such categorisation is to cater these requirements accordingly, to structure better the design solution process, as illustrated later in Section 3.2. For instance, when present in a given MP scenario, the prior needs to meet are the ergonomic ones. Besides, the parameters corresponding to ergonomic requirements are likely to constrain the rest, as they define size or shape of the product. Such as, in a footwear personalisation case, if personal fit option is provided, it is inherently the primary requirement to be fulfilled. Therefore, the fit requirements should be at the top of the PR hierarchy.

Top-level PRs state design personalisation context derived from CNs. These PRs are decomposed to lower levels, based on the DPs, to define more specific design objectives to personalise the design. The customer input to the design in the co-creation process is done on the lower-level PRs. Therefore, the PRs should be decomposed, at least, until the level appropriate for customer input. These PRs getting the customer input define the design space, where each PR is a dimension with a range. The customer input is taken within these ranges, which define the extent of personalisation offering. Since the customer input cannot be in the language of PRs, the selected levels of PRs are mapped back to the customer domain to be expressed in the customer language again. This last process of defining how user input is taken is a part of the design of co-creation activity, which is not covered in this work.

To illustrate the decomposition process, a hypothetical eyeglass frame is taken. Some very broad CNs can be a comfortable fit of the frame and adaptation to face shape or skin tone. Comfortable fit need can be translated to a top-level PR as fitting to facial measures. Then the corresponding top-level DP would be the dimensions of the frame. This top-level PR can be further decomposed to lower levels to requirements of specific facial measures. These are then matched with relevant dimensional DPs of the frame. Here, the user input can be transmitted to the design through either the higher or lower level of PRs, depending on the co-creation scenario. For instance, in case there is a process of face scanning, then the user input is taken at the level of fitting to facial measures. Another case might be user self measuring or using the dimensions of a previous frame, and in this case, the user input would go through the lower-level PRs of specific facial measures.

3.2.3. Design parameters

The user input through PRs is realised by DPs in the physical domain. DPs define the variable design features of the seed design, and they are selected to fulfil the corresponding PRs. In the context of digital manufacturing, these DPs may provide variety through changing certain dimensions of the product, or through varying topologies, structures, material composition and so on. DPs should be decomposed to lower levels until PRs can be implemented into the design. A DP can have a range of quantities or a set of options. In the first option, the values the parameter can take would be a continuous range, while in the latter case, it would be a value for each option in the set.

The mapping between PRs and DPs can be expressed as a design equation, where r denotes the in-between dependency:

(1)$$ \left\{ PR\right\}=\left[r\right]\left\{ DP\right\}. $$

When identifying the DPs, the ideal scenario is that each PR is satisfied by one DP, which corresponds to an uncoupled design in AD. In this case, there is one-to-one mapping, and each PR is fulfilled by the corresponding DP. Another manageable form is a decoupled design, where the dependency matrix has a lower triangle form (Suh Reference Suh2001). In this case, PRs are satisfied in a hierarchy of least dependent to most dependent. A similar solution is also provided in DSM to provide an order for the definition variable values, by sequencing the rows and columns of the matrix to form an upper triangle (Eppinger & Browning Reference Eppinger and Browning2012). In the case of MP, the proposed method based on the principles of having sufficient design space for self-expression and implementing personal priorities in the design. Achieving an uncoupled design may require architectural changes in the product. Besides, a PR dependency hierarchy for the design solution in a decoupled design naturally narrows down the range of subsequent PRs. However, customers may have different priorities for the given PRs, and these priorities should set the solution hierarchy while achieving a personalised design. Therefore, a user-centric design solution algorithm is proposed in Section 3.2, along with a dependency matrix to visualise and simplify the design cases.

While setting DPs, it is still important to aim for less-coupled design to lower the complexity of the dependency matrix. The complexity in this context refers to the number of PR–DP dependencies in the matrix. A trade-off between complexity and the range of PRs satisfied is necessary to provide an adequate personalisation experience. Another downside of high complexity in PR–DP dependencies is the possibility of radical changes in the dynamic design space provided to the user during the co-creation process. This may lead to a negative user experience, as the initial state of the design space creates expectations, the valid state may lead to disappointment.

3.2.4. Constraints (C)

Cs are the limits or restrictions on the DPs (solution space) primarily, but indirectly restricting the PRs (design space) as well. The Cs may initially be divided into two groups based on the phases they are applied. The first group is used to set the boundaries of the initial design space. There are four categories of constraints to look for, which are explained below The second is the PR–DP dependency constraints that during the co-creation and design solution phase. The dependencies between PRs and DPs result in a temporarily valid design space in the co-creation process. These Cs are handled in the design solution algorithm.

The aim of constraining the design space is to ensure that the final design is reliable and manufacturable. This is a crucial prerequisite for automating personalised design generation. The initial and broadest ranges of DPs are set according to the product architecture. This implies the natural boundaries of the products, that exceeding these would be unnecessary or impractical. An example could be the DPs regarding the ergonomic fit of a product, which would be characteristically limited by anthropometries. The second step of Cs is the interdependencies of DPs. This step is to eliminate possibly counterproductive or unfeasible DP combinations.

In traditional product development, manufacturing considerations are in the process domain, after the design is defined (Ulrich & Eppinger Reference Ulrich and Eppinger2012). Whereas, in design for manufacturing, these considerations are present since the early design phases (Salonitis Reference Salonitis2016). Manufacturing flexibility is a main pillar of MP, and thus designing for MP largely relies on manufacturing and related variables. Therefore, a design for manufacturing approach is more suitable as manufacturing processes or materials are early phase design decisions, since they are related to the personalisation offering. Consequently, the proposed approach considers manufacturing-related variables while defining the solution space. The third step of Cs is related to the manufacturing and cost feasibility. At this step, restrictions regarding manufacturing methods, process and materials are applied to DPs, both to ensure manufacturability and to eliminate unpractical results. Furthermore, depending on the cost target, design solutions potentially resulting in extreme cost variation may be eliminated.

The final step to constraint DPs is regarding the personalisation offering. Depending on the CNs and co-creation scenario, the range of DPs may be restricted again, if at this step, the DP in the solution space exceeds the personalisation target. An example of this step would be restricting any DP that goes beyond the intended level of personalisation or create a very large design space, which may get confusing for the user and lead to a poor experience.

DPs along with the Cs, form the solution space where a personalised final design is achieved on the seed design. Therefore, DPs set the dimensions of the solution space, while Cs define the size of it. After all Cs applied, the final ranges of DPs are mapped back onto PRs to form the initial design space.

3.2.5. Design space

After the Cs are applied to the solution space, the consequent ranges of DPs define the possible ranges of PRs, and as a result the design space for the user. The dependencies between PRs and DPs are shown in Figure 4. In the dependency matrix, $ {r}_{mn} $ denotes for how $ {DP}_n $ fulfils the $ {PR}_m $. Therefore, PR is a function of DPs:

(2)$$ PR=f(DP). $$

Figure 4.

Dependency matrix of personal requirements (PRs) and design parameters (DPs). r denotes for dependency.

In case it is possible, at least in a certain range, to linearise the relationship between PRs and DPs, $ {PR}_m $ can be expressed as:

(3)$$ {\displaystyle \begin{array}{rcl}{PR}_m& =& \sum \limits_{i=1}^n\Big({r}_{mi}\times {DP}_i\Big).\end{array}} $$

The extrema of the equation give the maximum range of $ {PR}_m $. The maximum range of a PR is established when all dependent DPs fulfil the PR. In the case where a DP affects multiple PRs, this creates a dependency between PRs. These dependencies would restrict the ranges of PRs. While defining the design space at any instance, these dependencies are ignored to provide the most design freedom to the user at the beginning. Since the range of each PR is set independently, they cannot have the largest ranges simultaneously, as some DPs are affecting multiple PRs. Following each user input during co-creation, the solution algorithm considers the dependencies and recalculates these ranges, and then returns to the user interface. Hence, the algorithm shows the largest range to the user at any instance, according to the DP values at that instance, but this is only valid for the following choice of the user. Hence, the PR to be fulfilled first would still have its largest range. Therefore, the user has to decide on personal priorities and reach a desired trade-off. The benefit here is that the user has the most freedom at any instance of decision and can get the most out of the desired performance aspect. How this process works is explained in the next section.

Consequently, the initial design space for customer co-creation is set by defining the maximum ranges of PRs regardless of the dependencies. With the formulation of a design space, the first design phase, seed design development, is completed.

3.3.1. Clustering

DSM is a common tool to model, visualise and analyse the dependencies between the elements of complex systems (Eppinger & Browning Reference Eppinger and Browning2012). It also offers suggestions to simplify the design cases by sequencing the rows and columns to reach a systematic order for assigning a value to each variable. One of the suggestions is clustering, where matrix elements are clustered to identify minimally interacting subsets, hence eliminating or minimising the interdependencies. In a similar way, to reduce the complexity of the dependency matrix, certain PRs and DPs may be clustered, and considered as a cluster in the iteration for design solution. The clustering is useful in the following cases:

1. (i) DPs of an independent PR.

2. (ii) In case the dependency is on a higher level of PR, clustering the lower-level PRs.

3. (iii) DPs for ergonomic fit.

When a PR is independent, this implies that the corresponding DPs does not affect any other PR. Therefore, these DPs can be clustered and considered as a single element to fulfil the PR. If there is a dependency on a higher level of PR, the lower-level PRs in its subset can be clustered and iterated as a cluster. The clustering can be only up to the level where there is user input.

The last case is when the product is made-to-measure. DPs corresponding to requirements of fit would be geometric dimensions. Since the requirements would be dimensions as well in this case, these PRs and DPs would have one-on-one mapping. Therefore, ergonomic PRs, and corresponding fitting DPs, can be considered as a subsystem and clustered to simplify the case. Since these DPs change the size or shape of the product, they may still affect the valid range of other PRs. In such case, for the sake of simplicity, this dependency should be considered as between the fit cluster and the relevant PRs.

To illustrate the use of clustering, a dependency matrix of an arbitrary design case is shown in Figure 5. In the example, there are three top-level PRs and in the lower level there are nine PRs. $ {PR}_1 $, $ {PR}_2 $ and $ {PR}_3 $ are ergonomic fit requirements, and each of them are dependent on one DP. Therefore, these can be clustered to simplify the matrix. $ {PR}_4 $–$ {DP}_4 $ and $ {PR}_5 $–$ {DP}_3 $ have one-on-one mapping and independent of the rest. Therefore, these can be clustered as well. The third case of higher-level dependency is not present in this example. For instance, if $ {DP}_3 $ and $ {DP}_4 $ were both dependent on one PR, this would imply a higher-level dependency. In the simplified matrix (Figure 5), cluster two can be handled independently for the design solution. Cluster one is still dependent to PR₆–PR₇, but since it is an ergonomic fit cluster, it is fulfilled first as explained further in the following section. As a result, only the remaining four PRs and four DPs require an iterative solution.

Figure 5.

Example clustering case on a personal requirement (PR)– design parameter (DP) dependency matrix. The matrix on the left side is the initial state, and the matrix on the right is the simplified one after clustering. Top-level PRs are marked with a superscript.

3.3.2. Solution algorithm

To manage the interaction between design and solution spaces, a solution algorithm for design personalisation is introduced in this section. The solution algorithm manages the dependencies between PRs and DPs, keeping control over the complexity, still providing an almost continuous variety. In the backend, it allows the real-time interaction of the user with the design. The algorithm dynamically controls the boundaries of these spaces and assigns values to DPs to fulfil PRs with an iterative approach. The objective is to offer the largest design space at each decision step and provide the most design freedom to the user on the preferred design aspects. The algorithm (Figure 6) works by iterating the DPs to fulfil the PR at each step. The fundamental principles of the algorithm are:

1. (i) The hierarchy of the PRs are decided by the user.

2. (ii) Least possible number of DPs used to satisfy an PR.

3. (iii) If present, independent DPs are changed first to fulfil the given PR.

4. (iv) Iteration from the most effective to the least effective DP for the given PR.

5. (v) If present, PRs of ergonomic fit are fulfilled first.

6. (vi) Solely aesthetical PRs are considered last.

Figure 6.

Design solution algorithm.

When each DP affects only one PR, the complexity of the dependence matrix becomes the lowest, thus no iterations needed, and each PR can be satisfied with the corresponding DP. For the rest of the cases, where dependencies increase the complexity, the solution algorithm is applied. The steps below are followed for the personalised design solution:

1. (i) In case where the ergonomic fit is a PR, it is fulfilled first. This is because of the assumption that the primary expectation from a made-to-measure product is personalised fit. Besides, it would have a fixed input for each user, hence it is not a CN that the user could actively state preference. Therefore, PR related to the fit is fulfilled first and in case of a dependence, design space is updated, before further decisions are made in the co-creation process. Following this, functional PRs are fulfilled where design case is more likely to be coupled. Lastly, the aesthetical PRs are fulfilled, after the right fit and suitable set of functions are provided.

2. (ii) The process starts with the user input, and a value is assigned to the corresponding PR.

3. (iii) Then, the value is checked if in the valid range. If not, the solution space is reset.

4. (iv) In the following step, the most effective DP for the given PR is identified and checked if it has already been assigned a value.

5. (a) If yes, it goes back to the second most effective DP and repeat.

6. (b) If no, the DP is incrementally increased or decreased until either the boundary value is reached or the PR is satisfied.

7. (v) After this iteration, the PR is checked if satisfied.

8. (a) If not, it goes back to the DP selection process and continues with the next DP.

9. (b) If it is satisfied, the design space is updated for the valid ranges of remaining PRs.

10. (vi) The same process continues until all PRs are fulfilled.

11. (vii) Then, when all DPs are set, a personalised final design is generated.

All DPs initially start at a median value. According to the input PR value, they are iterated towards either the upper or the lower boundaries of their ranges. Since the design space is in a feedback loop, the input to the PR would be in the valid range, and the iteration of DPs will surely satisfy the PR. In case of an input outside the valid range, the solution space goes back to the initial state, and again the fulfilment of the PR is ensured. The operation of dynamically controlling the dependencies and valid ranges also guarantees the reliability of the output final design. Hence, this process automates acquiring CNs and reflecting it to the design; and it may also provide personalised designs that are ready for manufacturing.

4.1.1. Personal requirements for mouthpiece

The personal needs of a player with a mouthpiece can be broadly grouped as desired sound and compatibility with playing habits. Top-level PRs for these can be expressed as sound features and playability aspects, respectively (Figure 8). The sound features are usually very subjective and the perception of these are studied in psychoacoustics (Carron et al. Reference Carron, Rotureau, Dubois, Misdariis and Susini2017). However, the tone colour of the sound and the loudness of it can be related to quantifiable measures (Ozdemir et al. Reference Ozdemir, Chatziioannou, Verlinden, Cascini and Pàmies-Vilà2021). The spectral centroid of the sound gives an indication about the ‘brightness’ of the sound. Moreover, the loudness of the instrument can be measured by the sound pressure level. Therefore, two of the PRs related to sound features are the spectral centroid and the sound pressure level. In terms of playability, two important and measurable aspects are resistance and pitch flexibility. Resistance implies ease of blowing the mouthpiece while playing. It can be measured by the minimum blowing pressure required to oscillate the reed (oscillation threshold), which produces the sound. Hence, the oscillation threshold indicates the resistance of the mouthpiece. The pitch flexibility is the range of possible pitch modification on the mouthpiece, and it can be measured by the interval of the highest and lowest pitch produced.

4.1.2. Mouthpiece DP and dependency matrix

The sound is produced by the vibration of the reed, that is excited by the air passing through the inner cavity of the mouthpiece. The parameters defining the inner cavity affect the airflow characteristics, and the parameters interfacing the reed affect the vibration of the reed (Figure 8). Hence, these parameters, as shown in Figure 9, define the performance of the mouthpiece. These parameters vary among the existing mouthpieces, and it is known that they affect certain characteristics. However, there was no evidence on how and what they affect exactly. Since the proposed methodology requires quantitative relations between PRs and DPs, these were identified through a set of experiments in the previous study (Ozdemir et al. Reference Ozdemir, Chatziioannou, Verlinden, Cascini and Pàmies-Vilà2021).

Figure 10 shows how each parameter affects PRs. These relations between DPs and PRs were identified and quantified through experimentation with an artificial blowing machine (Ozdemir et al. Reference Ozdemir, Chatziioannou, Verlinden, Cascini and Pàmies-Vilà2021). As seen in Figure 10, there is a highly coupled case, where all PRs are defined by multiple DPs, and five of the DPs affect multiple PRs. Therefore, it is a complicated task to tailor the performance of the mouthpiece, and as the performance aspects are dependent through the DPs, certain trade-offs may be needed.

4.1.3. Constraints for mouthpiece and solution space

To set the boundaries of the solution space, a list of previously suggested constraints are to be considered. In the case of the mouthpiece, there are a considerable number of designs available on the market. Hence, a survey of these existing designs are used to set the initial boundaries of the solution space (Ozdemir et al. Reference Ozdemir, Chatziioannou, Verlinden, Cascini and Pàmies-Vilà2021). For instance among the existing designs, the reed interface parameters, lay length and tip opening, vary within 17–25 and 1.4–2.6 mm, respectively. This is used as a starting point to set the range of these parameters. It is also important to note that the existing designs have discrete values within these intervals, and most of the possible combinations of different parameter values do not exist. Hence, there is a large unexplored space of design possibilities, and consequently, unexplored performance characteristics. The proposed approach allows fine-tuning these parameters, and exploring the complete solution space to tailor the performance of the mouthpiece.

To constrain the design space further, interdependencies of the DPs are checked. Continuing on the same two parameters, lay length and tip opening are dependent parameters, and extreme combinations of these are either unplayable or very uncomfortable to play. Therefore, these combinations are also eliminated.

In terms of manufacturing or feasibility, there are not any significant constraints in this case. Since the product has a simple geometry, and the parameter changes are at a small scale. Nevertheless, there are still such constraints regarding the basic design of the mouthpiece. For instance, the selected material should not be toxic as the product stays in contact with the player for long time. Similarly, it should be resistant to moisture as it is significantly present while playing. There are surely more constraints to these to be considered for the basic design of the product. While the constraints here, and in the context of the methodology, are related to the possible changes in the product.

The final step of the constraints are related to the personalisation scenario. In this case, the users of the product are rather experts, and hence they might benefit and appreciate the largest possibilities. For instance, if the user target was narrower, such as only beginner players or classical music players, the parameters could have been restricted further to avoid possibly undesired results. Once all constraints are applied, the final ranges of the DPs are obtained. These ranges form the solution space, within which a personalised design can be created.

4.1.4. Design space for mouthpiece

The solution space set the boundaries of how the structure of the product may change. On the other hand, the design space includes possible PR for the product. In this case, these are the four performance aspects. The solution space is mapped back onto these to set their ranges. To be more specific, the DP combinations providing the extrema of the given performance aspect give the largest range of the PR. For instance, the highest pitch flexibility is obtained with the largest baffle height and the smallest chamber size and tip opening. With the given DP ranges, the pitch variation interval (flexibility) can get a value between 41 and 129 Hz, according to the results of the previous study (Ozdemir et al. Reference Ozdemir, Chatziioannou, Verlinden, Cascini and Pàmies-Vilà2021). The same procedure is then followed for all the PRs to find what can be offered to the user, and this forms the design space. The design space initially provides the largest ranges of PRs. But since this is a coupled design case, PRs are dependent and the user can not simultaneously decide on all four PRs. Therefore, the user has to reach a trade-off considering personal priorities and can obtain the most suitable performance from the mouthpiece.

4.1.5. Personalised design solution for mouthpiece

This example briefly illustrates how the user co-creates the product through the interaction between the design and solution spaces via the solution algorithm behind. Since the PRs are very technical and their values would not be meaningful to the users, they are renamed in the user language and sliders are provided for user input. In Figure 11, pitch flexibility refers to pitch flexibility interval; brightness refers to the spectral centroid; resistance refers to the oscillation threshold and loudness refers to sound pressure level. In the user study of this example, benchmarking mouthpieces were given to the users to understand the scale and have a reference for their decisions (Ozdemir et al. Reference Ozdemir, Chatziioannou, Verlinden, Cascini and Pàmies-Vilà2021).

A user co-creation scenario is shown in Figure 11. Step 1 shows the initial design space, where all four PRs have their largest ranges available. The first decision of the user is to set the pitch flexibility, moving the slider to the more flexible side. As the most effective DP in this case is tip opening, it is iterated to its lower limit; then passing to the second DP, the baffle height is increased, and a solution is found. In Step 2, it is seen that the design space and the default state of the PRs are changed. This is due to the DPs changed in the previous step. In this step, the user changes the brightness, and this requirement is satisfied by iterating the throat shape and the lay length, respectively. In the third step, four of the DPs are already set, and the remaining design space for the other two PRs are significantly smaller. In this case, the user changes the resistance, and this is satisfied by increasing the chamber shape. It should be noted that since the chamber shape is an independent DP, it does not affect the design space in the next step. In the last step, the user sets the loudness of the mouthpiece, and this is satisfied by iterating the throat shape first, as it is an independent DP. At this point, all PRs are decided by the user, and a design can be generated with the DP values at this instance. In the case desired, the user may continue looking for further trade-offs following the same process.

4.2.1. Personal requirements for knitted footwear

In the first step of the design case, identification of top-level PRs requires broad descriptions of the specific CNs. For personalised footwear, these are identified as comfort and self-expression. The top-level PRs corresponding to these are personalised fit and shoe upper properties for comfort, and upper appearance for self-expression. These three top-level PRs correspond to ergonomic, functional and aesthetic features to be personalised in the shoe. To also exemplify the generic features, the shoe style might be given. The style, trainer shoes in this example, is predefined on the shoe last design, which may be considered as the mould in the footwear context.

Figure 13 shows the decomposition of PRs and the corresponding DPs. Flexibility, weight, permeability, and heat resistance are the lower-level PRs that define the functional features of the shoe upper. Graphical pattern and knit pattern are the lower-level PRs defining the visual appearance of the upper. The PRs framed in Figure 13 are the selected as convenient levels to get the user input. These are mapped back to the customer domain, to be expressed as design personalisation options in the co-creation process. Personalised fit and graphical pattern are decomposed one level further to be satisfied by the selected DPs. These lowest level PRs are not chosen as user input since they individually do not present any personalisation need.

4.2.2. Footwear DPs and dependency matrix

The identified DPs are shown in Figure 13. Yarn material, count (thickness) and knit pattern selections fulfil the comfort properties of the shoe upper. Yarn colour and knit pattern fulfil the upper appearance needs. Knit pattern is used both as a PR and a DP. Because it has both an aesthetic value and a structural function. In this case, it is assumed that there is a supply of yarns providing stable behaviour, and the knitting machine is able to produce some patters that behave substantially the same.

The shoe last design can be modified for personalised fit via sizing and grading parameters (Zhang et al. Reference Zhang, Luximon, Pattanayak and Zhang2012). These parameters define the geometry of the sole and the upper. The sizing is defined by the length, and the grading is by the girth measures of the user’s feet. The length and girth values are obtained from the foot measurements of the user.

The matrix in Figure 14 shows the dependencies between PRs and DPs. The length and girth requirements are clustered together since they are related to fit. The dependency between the graphical pattern cluster and the last parameters is related to dimensions. The last parameters define the size of the upper where a graphical pattern will be applied. This size information is a prerequisite for a graphical pattern input. Similarly, the sizing parameter should have a value before the grading parameter is set. Therefore, these two parameters should be clustered. The last parameters are defined by personalised fit requirements, which must be fulfilled first according to the method. Therefore, once the fit cluster is fulfilled, the graphical pattern cluster becomes independent. As a result, both clusters and the corresponding DPs are independent, and they can be fulfilled regardless of the other PRs. However, the remaining five PRs are coupled through three DPs, and this requires an iterative solution.

4.2.3. Constraints for knitted footwear and solution space

To define the solution space, the DP ranges go through the constraining steps. Initially, all DPs start at the largest intervals possible for the product architecture of the given case. For instance, the sizing and grading parameter ranges are bounded with the anthropometric foot data (Luximon & Luximon Reference Luximon and Luximon2013).

The second step is checking the interdependencies of DPs. A simple example of this is the limited availability of yarn colour and count options for a selected yarn material. In the third step, process and cost constraints are applied. Since a knitted upper is in the design proposal, the knitting parameters depend on the digital knitting machine. For instance, the range of yarn counts that can be used is limited with the machine gauge, and also the number of colours that can be used at the same time is limited with the number of carriers in the machine (Ozdemir, Cascini, & Verlinden Reference Ozdemir, Cascini and Verlinden2020).

The final step of the constraints is to limit the DPs which will define PR ranges in the initial design space. This step is according to CNs and the co-creation scenario. For instance, the number of knit patterns offered is limited to avoid over-complication for users. The boundaries of shoe sizes offered can be considered at this step as well.

Once all constraints are applied, the final ranges of DPs are obtained. These ranges, shown in Table 1, define the solution space. As stated before, yarn colour, last size and grading are independent parameters and get direct input from the customer domain. On the other hand, the options within the range of yarn material, count and knit pattern have different effects on the PRs. These effects are shown in Figure 15. To bring the effects to a common denominator, they are expressed as a value from 0 to 1. These ranges are mapped back onto PRs to define the initial design space in the next step.

Table 1.

The ranges of design parameters (DPs) for the solution space.

4.2.4. Design space of knitted footwear

The combinations of the DPs seen in Figure 15 provide the max and min possible values of PRs that form the initial design space. For instance, the highest heat resistance can be obtained by wool yarn with Nm7–Nm2/14 having a single knit structure. The sum of the coefficients of these is 3. Likewise, the lowest heat resistance can be achieved by any material except wool, Nm6–Nm2/12, and half-cardigan rib or single-pique structure. The sum of coefficients, in this case, would be 1. Therefore, we can conclude that for heat resistance, the range is 1–3, and an input within this interval can be taken. The same is applied for the other PRs as well and shown in Table 2. These ranges shown in the table define the initial design space. It is important to highlight here that the interdependencies of PRs are not considered for these ranges. For instance, it is not possible to obtain both the highest flexibility and the highest heat resistance at the same time, due to the varying effects of DPs on each PR. But the first PR to fulfil, chosen by the user, will have the largest range.

Table 2.

Final ranges of personal requirements (PRs) forming the initial design space.

4.2.5. Personalised design solution for knitted footwear

An example design solution process is shown in Figure 16. The process starts with the user’s foot measurement input. First, the available shoe sizes are iterated for the given foot length. Afterward, the grading is iterated to match the user input with the obtained size. At the end of this process, 41.5C is found as the best fit, and the design space is updated with this information. As a second input, permeability = 1 is given. DP selection function chooses the yarn count parameter to be iterated first. At the end of the iteration, Nm7 is set for yarn count and this fulfils the permeability requirement. Updating the valid design space again, now it can be seen that the weight and heat resistance have narrower ranges, since the yarn count is set. The next input is heat resistance = 2.2. The DP selection function picks the yarn material and the iteration function picks wool as the most heat-resistant material. However, at this point, the heat resistance = 2, and the PR is not fulfilled. Therefore, the DP selection function runs again and picks the knit pattern this time and the iteration results in half-cardigan rib and single-pique as equal options to reach 2.2. At this point, all DPs are set, except the two options left for the knit pattern. Therefore, flexibility and weight have only one possible value in the updated valid design space. The final input is for the knit pattern, and single-pique is chosen. In case the user is not satisfied with the final output, the input for any PR can be set again to reach other trade-offs. On this occasion, the DPs chosen are reset, and the iteration process starts again. The final personalised design in the example is a 41.5C size shoe with Nm7 wool yarn having a single-pique structure. The graphical pattern is not included in the iteration, as it is independent and can be fulfilled directly at any step after sizing and grading.