Year 3 / Module 23 Professional practice and the HCI profession / Unit 8 / Research operations is the infrastructure that makes findings reusable

Research operations is the infrastructure that makes findings reusable

HCI3107 · Unit 8 of 10

Research that depends on one person's goodwill and a local spreadsheet does not survive staff changes, so a research function treats panels, repositories, consent records and ethics arrangements as infrastructure rather than overhead.

Research operations is the infrastructure that makes findings reusable

Research does not usually fail for want of a method. It fails because the participant panel lived in one researcher's inbox and the consent record sat in a folder only she could find. When she leaves, the research leaves with her. What keeps research usable is infrastructure rather than individual virtue.

The claim borrows its justification from a premise the profession treats as settled, that involving users makes systems better. The evidence is modest. It is strongest where the outcome is how people feel rather than what the system does. The infrastructure argument inherits both the premise and its limits. This eighth of ten units, after the seventh settled the arguments, makes what research produces reusable.

Research operations is a function, not a person, and small teams show what its absence costs

Kaplan (2020) defines research operations as the orchestration and optimisation of people, processes and craft so that research has value at scale. He names six focus areas: participants, governance, knowledge, tools, competency and advocacy. It names recruitment, consent, storage and reuse as a function rather than a personal habit.

Towsey (2024) codifies the same territory at book length. He sets out eight elements of research operations and a research knowledge management strategy, and argues that a practice must be designed to scale rather than improvised. Two details carry weight. Recruitment and consent belong inside operations rather than beside it, and ethics and privacy must be more than a checklist of prohibitions.

Neither source is peer reviewed. Both describe what practitioners recommend, not what has been tested.

Martinelli, da Silva and Zaina (2024) conducted a multiple-case study of five software startups. The startups were chosen because they share the two conditions that strain research: small teams and time pressure. They interviewed ten practitioners and coded the transcripts. They identified eight challenges, six concerning user experience research and two concerning long term experience. The finding is structural. In a small team, research is pushed out unless something in the organisation holds it in place.

The premise underneath is weaker than the profession treats it

Ives and Olson (1984) reviewed the research linking user involvement to the success of management information systems. They found much of it poorly grounded in theory and methodologically flawed. The benefits of involvement had not been convincingly demonstrated, and until better studies existed, intuition would remain the practitioner's guide.

The premise has an older and more ambitious test. UTOPIA ran in Sweden from 1981 to 1986. The Nordic Graphic Union paid half the wages of six graphic workers from Stockholm and Aarhus. Those workers designed newspaper page make-up tools alongside researchers from three institutions: the Centre for Working Life in Stockholm, Aarhus University and the Royal Institute of Technology. Data-flow diagrams meant nothing to typographers. The team therefore worked the job through with a wooden mouse and a cardboard laser printer. What came out was a requirement specification, a pilot installation at the newspaper Aftonbladet, and a method. The union's gain was knowledge of the new technology at least as good as the employers'. The pilot tool counted for less than the experience. The arrangement needed a union able to fund six half-time members.

Bano and Zowghi (2015) reviewed the question again, following the guidelines of evidence-based software engineering. They selected 87 empirical studies published between 1980 and 2012. Of those, 52 reported a positive contribution to system success, 12 a negative one and 23 were uncertain. Their conclusion is that involvement does contribute positively, but as a double-edged sword that can cause more problems than benefits if unmanaged.

The concept had to be cut apart before the effect could be measured

Part of the inconsistency has a conceptual cause, which Barki and Hartwick (1989) named. The field had used one term, user involvement, for two things. One is the activities users perform during development. The other is the psychological state of finding a system personally relevant. Separating the first, user participation, from the second generates testable hypotheses instead of confusion. Barki and Hartwick (1994) went on to validate separate measures of participation, involvement and attitude.

Hwang and Thorn (1999) meta-analysed data from 25 studies to test the separate effects of participation and involvement on six success variables. Participation correlated moderately with system quality, use, user satisfaction and organisational impact, and only minimally with individual impact. Involvement correlated more strongly still. Both are beneficial, they conclude, but the size depends on how the terms are defined.

The effect is real, moderate, and mostly an attitude effect

He and King (2008) synthesised 82 empirical studies of user participation. They classified outcomes as attitudinal and behavioural on one side, and productivity on the other. They found participation minimally to moderately beneficial. It was stronger on attitudes and behaviour than on productivity. They add a pointed explanation. The attitudinal effect may reflect the emphasis academics and consultants have placed on participation.

Kujala (2003) reviewed the same territory and reached a slightly warmer conclusion. She found involvement generally positive, especially for user satisfaction, and some evidence that taking users as a primary information source captures requirements effectively. She adds that the role of users must be considered carefully. She also argues that cheaper ways are needed to gather implicit needs.

Value is added in the analysis, not in the collection

If the benefit is modest, where does it come from? Kujala (2008) gives the most specific answer. She developed an early user-involvement process from seven case studies, showing how gathered user needs can be analysed and turned into input for product development. She evaluated it in two industrial cases. The resulting requirements were judged more successful and of better quality than average.

Damodaran (1996) supplies the counterpart from the participant's side, writing for users required to take part in information technology projects who are unclear about what that requires. Organisations brief them little on their role. The participant, not only the researcher, depends on operations. A panel, a briefing and a defined role turn a person into a usable source of evidence.

A repository is infrastructure only if its contents can be found and reused

The knowledge component is the easiest to test, because it has an external standard. Wilkinson, Dumontier and Aalbersberg (2016) set out the FAIR principles: research data should be findable, accessible, interoperable and reusable. They argued that these properties must be designed into stewardship rather than added afterwards. Written for scientific data, they apply without strain to a research repository.

A repository that cannot be searched fails the first principle. A consent record that blocks lawful reuse fails the second. Findings in a tool no successor can open fail the fourth. Towsey (2024) makes the same argument from practice, treating a knowledge management strategy as a designed system. The test is whether a colleague who was not present can find and reuse what is in it, and the same test applies to the participant: a panel recruited online assumes a reader at home in English on a shared device and a slow connection.

Contested question: does involving users improve the system, or how people feel about it?

The literature does not agree on what involvement reliably delivers. The disagreement decides how an operations function may justify itself. One position treats the benefit as real and usable. Hwang and Thorn (1999) found moderate positive correlations between participation and four success measures, with involvement correlating more strongly. Kujala (2003) finds involvement generally positive, especially for satisfaction.

A second position treats the benefit as small and confined to attitudes. Ives and Olson (1984) found it not convincingly demonstrated. He and King (2008) found participation minimally to moderately beneficial and stronger on attitudes than productivity, warning that the attitudinal effect may be an artefact of professional emphasis. Bano and Zowghi (2015) found the relationship neither direct nor binary, with 12 of 87 studies negative and 23 uncertain.

The UI-SS relationship is neither direct nor binary, and there are various confounding factors that play their role. (Bano and Zowghi, 2015)

A third position holds that the dispute is partly an artefact of measurement. That is the point of Barki and Hartwick (1989, 1994). Until participation and involvement are measured separately, the two camps pass each other indefinitely, each citing studies that used the other's definition.

What would settle the disagreement is a study that measured participation and involvement separately and fixed the stage of development. It would control the analysis step Kujala (2008) shows to be decisive, and report productivity outcomes rather than only satisfaction. A pre-registered comparison of similar teams, with and without an operations function, would begin to attribute any difference to the infrastructure itself. No such study appears in this unit's list.

The operations case is practitioner text, not tested: Kaplan and Towsey describe a recommended function rather than a measured one. The evidence it inherits is meta-analysis that splits, with He and King finding the benefit mostly attitudinal. While the dispute is open, a designer should justify operations by the research it keeps reproducible. The strongest objection is the reverse of the unit's own: if involvement mainly changes how people feel, operations may improve satisfaction surveys while leaving the product unchanged.

Where the argument is heading

The direction of travel is from improvisation to a named function with a standard. Kaplan (2020) gives the function a definition and a model, and Towsey (2024) turns the model into eight elements and a knowledge management strategy. Wilkinson, Dumontier and Aalbersberg (2016) import a data-stewardship standard, and Martinelli and colleagues (2024) show what small teams lose without it.

The sources this unit rests on

  • Bano, M. and Zowghi, D. (2015). A systematic review on the relationship between user involvement and system success. doi:10.1016/j.infsof.2014.06.011 Selected 87 empirical studies published between 1980 and 2012, finding 52 positive, 12 negative and 23 uncertain, with the relationship neither direct nor binary. Concludes involvement contributes positively but is a double-edged sword if unmanaged, which sets the contested ground for the unit.
  • Barki, H. and Hartwick, J. (1989). Rethinking the Concept of User Involvement. doi:10.2307/248700 Argues for separating user participation, the activities users perform, from user involvement, the psychological state of personal relevance. The distinction generates testable hypotheses and is the conceptual fix later meta-analyses depend on.
  • Barki, H. and Hartwick, J. (1994). Measuring User Participation, User Involvement, and User Attitude. doi:10.2307/249610 Develops and validates separate measures of participation, involvement and attitude. Reports the three constructs reliable, valid and distinct, the measurement evidence behind the separation.
  • Damodaran, L. (1996). User involvement in the systems design process: a practical guide for users. doi:10.1080/014492996120049 Writes for users required to take part in IT design, who are often unclear about what that requires because organisations brief them little on their role. Differentiates the roles of the players, showing that the participant depends on operations too.
  • He, J. and King, W. R. (2008). The Role of User Participation in Information Systems Development: Implications from a Meta-Analysis. doi:10.2753/mis0742-1222250111 Synthesised 82 empirical studies, classifying outcomes as attitudinal and behavioural on one side and productivity on the other. Found participation minimally to moderately beneficial, the strongest caution that involvement may improve satisfaction without improving the product.
  • Hwang, M. I. and Thorn, R. G. (1999). The effect of user engagement on system success: A meta-analytical integration of research findings. doi:10.1016/s0378-7206(98)00092-5 Meta-analysed data from 25 studies to test the separate effects of participation and involvement on six success variables. Found participation moderately correlated with system quality, use, satisfaction and organisational impact, with involvement correlating more strongly, the positive side of the contested question.
  • Ives, B. and Olson, M. H. (1984). User Involvement and MIS Success: A Review of Research. doi:10.1287/mnsc.30.5.586 Reviews the research linking user involvement to MIS success and finds much of it poorly grounded in theory and methodologically flawed. Concludes the benefits had not been convincingly demonstrated, the founding caution against treating the benefit as settled.
  • Kaplan, K. (2020). ResearchOps 101. Nielsen Norman Group. https://www.nngroup.com/articles/research-ops-101/ A practitioner definition of research operations as the orchestration and optimisation of people, processes and craft to amplify research at scale, with six focus areas. Distinguishes running research from doing it, and is the unit's working definition.
  • Kujala, S. (2003). User involvement: A review of the benefits and challenges. doi:10.1080/01449290301782 Reviews three streams of research on the benefits and problems of user involvement in early development. Finds generally positive effects, especially on satisfaction, and a need for cheaper ways to capture implicit needs, the warmer of the two reviews in the contested section.
  • Kujala, S. (2008). Effective user involvement in product development by improving the analysis of user needs. doi:10.1080/01449290601111051 Presents an early user-involvement process developed from seven case studies and evaluated in two industrial cases. The resulting requirements were judged more successful and of better quality than average, locating the value in analysing user needs.
  • Martinelli, S., da Silva, T. S. and Zaina, L. (2024). Challenges of UX research and long-term UX: A multiple case study with software startups. doi:10.1145/3679318.3685381 A multiple-case study of five software startups, chosen for small teams and time pressure, with ten practitioners interviewed. Identified eight challenges, six on user experience research and two on long term experience, showing what research loses without organisational support.
  • Sundblad, Y. (2010). UTOPIA: Participatory Design from Scandinavia to the World. History of Nordic Computing. doi:10.1007/978-3-642-23315-9_20 Reconstructs UTOPIA, the 1981 to 1986 project in which the Nordic Graphic Union funded six graphic workers to design newspaper tools with researchers. Reports that the results were the method and the union's knowledge rather than the pilot tool.
  • Towsey, K. (2024). Research That Scales: The Research Operations Handbook. New York: Rosenfeld Media. https://rosenfeldmedia.com/books/research-that-scales/ A handbook codifying research operations into eight elements and a research knowledge management strategy. Argues a practice must be designed to scale, and that ethics and privacy must be more than a checklist, the founding practitioner text for the role.
  • Wilkinson, M. D., Dumontier, M., Aalbersberg, I. J., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. doi:10.1038/sdata.2016.18 The first formal publication of the FAIR principles, that research data should be findable, accessible, interoperable and reusable, designed into stewardship rather than added afterwards. Gives the repository component an external standard.

Check your understanding & apply it · 4 questions, 1 essay

1A researcher leaves an organisation. The participant panel lived in her inbox and the consent record sat in a folder only she could find, so both left with her. Which option states what the unit says this failure is?
2A team's research repository cannot be searched, its consent terms block any reuse of the data, and the findings sit in a tool no successor can open. Which option states what the unit's standard says about the three faults?
3A team writes a business case for a research operations function that promises product improvement through user involvement. Which option states what the unit's evidence allows the case to claim?
4Two colleagues disagree about what involving users delivers. One cites moderate positive correlations and the other a review in which 12 of 87 studies found a negative relationship. Which option states the positions, the study the unit names and the strongest objection?
5Essay A product team of about twenty people has just hired its second researcher. The first researcher has left, and the organisation discovers that the participant list was in her personal account, the consent forms were never templated, and two years of findings sit in slide decks no one can search. The manager asks for research to be 'fixed' before next quarter's studies begin. Using this unit's argument, say what you would build first and why, how you would decide which parts are infrastructure rather than overhead, what you would promise the organisation about the benefit of more research, and what you would record so that the next departure does not repeat the loss. Name the sources you rely on at each step, and state plainly what you would not claim.