The client belongs in the loop at checkpoints: involvement, co-design and the risk of design by committee

A client who first sees the product in the final week is a stranger with a veto. Involving them earlier is not about what they say they want. A disagreement surfaced in week four costs a conversation, and the same one in week ten costs a rebuild. The client belongs in the loop at a few checkpoints, each showing something that works. This is the second of ten units, and it follows the first by putting the client inside the checkpoints the agreement provides for.

The evidence is weaker than the advocacy: a meta-analysis of 82 studies found participation minimally to moderately beneficial, and stronger on attitudes than on productivity (He and King, 2008), while the one comparison close to a controlled design found that involving clients changed what a team produced and cost it feasibility (Trischler et al., 2017).

Involvement names a family of practices, not one decision

Kujala (2003) clarifies what involvement means before evaluating it, reviewing three streams of research on its benefits and problems. Effects are generally positive, especially on satisfaction, and users as a primary information source capture requirements, but the concept is too vague to prescribe.

Damodaran (1996) finds users required to take part frequently unclear what participation demands, because organisations brief them little. Keil and Carmel (1995) define a customer-developer link as a channel for exchanging information. Tapping the customer as a source of ideas, they argue, requires establishing one. Involvement, on this account, is a channel the team builds.

The boundary of the term is itself disputed. Yu (2025) argues that participatory design is conflated with the broader idea of co-design. He consolidates its characteristics into four core dimensions and positions it as a specific form of co-design, with a stronger political commitment to democracy and empowerment. Sanders and Stappers (2008) describe the same territory as a shift towards co-creation without that political condition. If Yu is right, much of what a student team calls involvement would not qualify as participation.

The benefit is real where it is measured, and smaller than the advocacy

Ives and Olson (1984) found much of the research on involvement and system success poorly grounded and methodologically flawed. The benefits were therefore not convincingly demonstrated, and when, how much, or whether to involve users remained unanswered.

He and King (2008) synthesised 82 studies, classifying outcomes as attitudinal, behavioural and productivity. Participation was minimally to moderately beneficial, and stronger on attitudes than on productivity. The authors suggest the attitudinal effect largely reflects the emphasis academics and consultants place on participation. The reliable return is a better-informed client, not a better artefact.

Bano and Zowghi (2015) reached the same border from a systematic review under Evidence Based Software Engineering guidelines, extracting data from every empirical study against nine research questions. The link was reported but not always positive, and inconsistently measured.

What may improve is the requirement, not the attendance

Hartwick and Barki (1994) separate what the word involvement covers. In a field study, participation, the behaviour, leads to involvement, the attitude, which mediates the link to system use. Overall responsibility is participation's critical dimension. A client who attends without responsibility supplies presence, not the construct that predicts anything.

Kujala and colleagues (2005) give the empirical version, from a survey of 18 practitioners in 13 Finnish companies and interviews with eight in three. Early involvement was rare but related to better requirements quality, and users as the information source related to project success. The single-country sample makes this a signal, not a measurement.

A checkpoint is a designed commitment, and its job is early visibility

A checkpoint here means a date, a working slice to demonstrate, the acceptance criteria exercised in front of the client, and a recorded response with a named owner. It also means a form the client can reach, since a fixed hour in one room selects for whoever can travel, and the materials assume a confident reader. Steen (2013) gives the purpose it serves best. He frames co-design as joint inquiry and imagination rather than a technique for gathering requirements. The checkpoint is a place to inquire as much as a place to deliver.

Steen, Manschot and De Koning (2011) reviewed the benefits claimed for co-design across three service design projects. Their conclusion is a warning: participants should align co-design activities to identified project goals, and they call for monitoring whether the intended benefits are realised.

The three projects give the goal its shape. Steen, Manschot and De Koning (2011) sort the benefits participants claimed into three kinds: for the project, for the service's users and for the organisations involved. They locate each in the creative process, the service itself, the management of the work or the longer term. A checkpoint held to improve the service and one held to build the client's ownership of it are different events with different evidence. The goal is therefore chosen before the date is set. The three projects were discussed in the paper rather than compared against a control.

One judged comparison finds a real artefact effect, and a cost in feasibility

Trischler and colleagues (2017) report a real-world comparison of design concepts in a library service ideation contest. The concepts came from codesign teams, an in-house professional team and a team made up solely of users. Codesign concepts scored significantly higher in user benefit and novelty but lower in feasibility. The outcome is judged concept quality, not a delivered service, which is why this comes close rather than being controlled.

The same paper carries the caution. The advantage appeared only in cohesive teams; where individuals dominated, the study reports conflict, less collaboration and diminished innovation as more likely. That is design by committee: not the client's presence, but a team that has not agreed how it will converge.

Design by committee is a real failure mode with named mechanisms

The failure mode follows from composition rather than from the client. Trischler and colleagues (2017) locate it in teams where individuals dominate, and dominance follows fluency in the room's language. Steen and colleagues (2011) treat co-design's costs and risks as something participants must assess explicitly. Two guards follow from the research. The checkpoint needs a decision owner on the team, because responsibility is participation's predictive dimension (Hartwick and Barki, 1994). And the client's response must be recorded and priced through the change route, not absorbed silently. Sanders and Stappers (2008) describe the shift that makes this necessary. Moving from user-centred design to co-designing with users changes the roles of designer, researcher and user. That is a claim about roles, not evidence of better outcomes.

Contested question: does involvement improve the artefact, or only the relationship?

The first position is that involvement buys a better relationship more than a better product. Its evidence is the pattern across the reviews. The effect is concentrated in attitudinal and behavioural outcomes rather than productivity (He and King, 2008). The early studies did not convincingly demonstrate the benefits at all (Ives and Olson, 1984). The constructs are so inconsistently measured that the relationship cannot be relied on as stated (Bano and Zowghi, 2015).

The second position is that involvement changes what teams produce. Trischler and colleagues (2017) find codesign teams scoring higher on user benefit and novelty. Kujala and colleagues (2005) find early involvement related to better requirements quality. The practitioner accounts in Steen and colleagues (2011) treat the change in what is designed as the point. On this reading the attitudinal finding shows the measures were chosen badly, capturing satisfaction because it is easy to survey.

What would settle it is a study that varies only the involvement regime, holding the project constant. It would measure the artefact and the relationship with independent instruments. The artefact outcome would need assessors who did not take part, against criteria fixed in advance. Nobody here runs that study; Trischler and colleagues come closest, on judged concepts.

Bossen, Dindler and Iversen (2016) give the reason the dispute cannot be closed from the record. They surveyed every Participatory Design Conference paper from 1990 to 2014, with special journal issues, and collected 143 papers, 66 of them relevant. Only 17 of those dealt with evaluation of the field's aims: mutual learning, empowerment, democracy and workplace quality. The evaluations were rare, thin on method detail and researcher-led. Settling the dispute needs explicit evaluation with stated measures, which the field reports it is not doing.

The two cases carry different evidence. The sceptical side holds a meta-analysis of 82 studies (He and King, 2008), an early review (Ives and Olson, 1984) and a systematic review (Bano and Zowghi, 2015). The optimistic side holds one judged-concept comparison with no random assignment (Trischler et al., 2017) and a survey of 18 practitioners in one country (Kujala et al., 2005). The stronger designs sit on the sceptical side, and they measure satisfaction. While the dispute is open, fix the checkpoint's goal before its date and give the client responsibility for the requirement rather than attendance at a review. The strongest objection is that a checkpoint can buy a better-informed client and call it a better product, which is what the measured effect supports.

Where the argument is heading

The direction of travel is that involvement is being converted from a virtue into a claim with a stated goal and a measure. Yu (2025) sharpens the boundary between participatory design and the broader idea of co-design. Any consultation with a client now lies outside participation's claim. Bossen and colleagues (2016) call for explicit, systematic evaluation of the field's aims, and Steen and colleagues (2011) ask the same of practice. For the student team: write down what the checkpoint is for, record the client's response, and expect a better-informed client rather than a productivity gain.

The sources this unit rests on

• Ives, B. and Olson, M. H. (1984). User involvement and MIS success. Management Science. doi:10.1287/mnsc.30.5.586 Finds the research on involvement and system success methodologically flawed, so the benefits are not convincingly demonstrated. It is the origin of the caution that involvement is not automatically good.
• Kujala, S. (2003). User involvement: a review of the benefits and challenges. Behaviour and Information Technology. doi:10.1080/01449290301782 Reviews three streams of research on the benefits and problems of involvement. Effects are generally positive, especially on satisfaction, and users as a primary information source capture requirements, but the concept is too vague to prescribe.
• He, J. and King, W. R. (2008). The role of user participation in information systems development. Journal of Management Information Systems. doi:10.2753/mis0742-1222250111 Synthesises 82 studies and finds participation minimally to moderately beneficial, stronger on attitudinal and behavioural outcomes than on productivity. It sets the unit's expectation: a better-informed client rather than a better artefact.
• Bano, M. and Zowghi, D. (2015). A systematic review on user involvement and system success. Information and Software Technology. doi:10.1016/j.infsof.2014.06.011 Reviews the empirical studies against nine research questions under Evidence Based Software Engineering guidelines. The link is reported but not always positive and inconsistently measured, so it cannot yet be relied on.
• Hartwick, J. and Barki, H. (1994). Explaining the role of user participation in information system use. Management Science. doi:10.1287/mnsc.40.4.440 Tests a field-study model separating participation, the behaviour, from involvement, the attitude; involvement mediates the link to system use and overall responsibility is participation's critical dimension. It is the unit's test for a real checkpoint.
• Sanders, E. B. N. and Stappers, P. J. (2008). Co-creation and the new landscapes of design. CoDesign. doi:10.1080/15710880701875068 Describes the movement from user-centred design to co-designing with users, and the resulting change in roles. It grounds the demand that a team state who decides, while being a claim about roles rather than outcomes.
• Trischler, J., Pervan, S. J., Kelly, S. J. and Scott, D. R. (2017). The value of codesign. Journal of Service Research. doi:10.1177/1094670517714060 Compares concepts from codesign teams, an in-house professional team and a user-only team in a library service ideation contest. Codesign concepts scored significantly higher in user benefit and novelty but lower in feasibility, and the advantage held only in cohesive teams.
• Damodaran, L. (1996). User involvement in the systems design process. Behaviour and Information Technology. doi:10.1080/014492996120049 Finds users required to participate in IT design frequently unclear what participation demands, because organisations brief them very little, and differentiates the players' roles. It fixes what a participant is being asked to do.
• Keil, M. and Carmel, E. (1995). Customer-developer links in software development. Communications of the ACM. doi:10.1145/203356.203363 Defines customer-developer links as the channels through which customers and developers exchange information, and argues that using the customer as a source of ideas requires establishing them.
• Steen, M., Manschot, M. and De Koning, N. (2011). Benefits of co-design in service design projects. International Journal of Design. https://www.ijdesign.org/index.php/IJDesign/article/view/890 Reviews the benefits attributed to co-design and discusses three service projects. It advises aligning co-design to identified goals and calls for monitoring whether intended benefits are realised, which is the unit's warning that the benefit is not automatic.
• Kujala, S., Kauppinen, M., Lehtola, L. and Kojo, T. (2005). User involvement in requirements quality and project success. IEEE International Requirements Engineering Conference. doi:10.1109/RE.2005.72 Surveys 18 practitioners in 13 Finnish companies and interviews eight in three. Early involvement was rare but related to better requirements quality, and users as the information source related to success; the single-country sample makes this a signal, not a measurement.
• Steen, M. (2013). Co-design as a process of joint inquiry and imagination. Design Issues. doi:10.1162/desi_a_00207 Frames co-design as joint inquiry and imagination rather than a technique for gathering requirements, which gives the checkpoint an inquiry purpose as well as a delivery one. No abstract is publicly retrievable; the unit rests on the article's published framing.
• Bossen, C., Dindler, C. and Iversen, O. S. (2016). Evaluation in participatory design: a literature survey. 14th Participatory Design Conference. doi:10.1145/2940299.2940303 Surveys all Participatory Design Conference papers from 1990 to 2014: 143 papers, 66 relevant, of which only 17 evaluate the field's aims of mutual learning, empowerment, democracy and workplace quality. They are rare, thin on method and researcher-led.
• Yu, J. (2025). Participatory design revisited. CoDesign. doi:10.1080/15710882.2025.2573020 Argues that participatory design is often conflated with the broader idea of co-design, and consolidates its characteristics into four core dimensions including cooperation with intended users and a political commitment to democracy and empowerment. It positions participatory design as a specific form of co-design.