We ran a 74-minute UCD session, using Zoom [3,19,20] and Mural [20-22], with 4 HIT professionals recruited using purposive criteria, including clinical decision support oversight and electronic health record decision authority. Participants had not previously worked together but had completed DEAN discovery interviews.

A human factors facilitator presented the 30 features on 4-quadrant MoSCoW grids (Figure 2). After brief orientation, each feature was presented, discussed (~3 minutes), and independently ranked, followed by further discussion. Features were reranked based on the discussions. If ratings were split, ties were resolved by our research team members that included a clinician, medical informaticians, and research support staff. Decisions on splits were based on multiple considerations, including timelines, cost, dependencies, and overlap with other features.

We conducted a single-case qualitative process study [23,24] to examine MoSCoW feature prioritization. The case study approach can be useful when researchers need to obtain a deep appreciation of an interaction in its real-world context [25]. More narrowly, a single-case study was the design selected because it allows evaluation of the MoSCoW process in a bound system that is influenced by hospital-affiliated informatics and HIT development process, restricted budgets, and the requirements of HIT professionals who would ultimately be doing the work in the DEAN administrative portal [26]. Therefore, the single MoSCoW interaction is our unit of analysis. The analysis aims to develop a descriptive explanation of how the MoSCoW method functions within the field of health informatics (ie, how did the interaction take place, what influenced the interaction, and what features were implemented in the DEAN system as a result of the work completed) [27].

Two researchers independently reviewed transcripts and video of the MoSCoW interaction using a descriptive approach [28,29] and rapid qualitative analysis template [30-32], iterating to consensus [33]. We counted each marker placement and any change, defined as moving a marker between quadrants during discussion, and integrated counts with consensus summaries. Nonparticipant attendees included a DEAN technical lead who addressed technical questions and a human factors expert who observed and took notes. Sessions were recorded on Zoom with Mural screen capture and transcribed, and participants received a gift card.

Regarding qualitative reflexivity, our research team—primarily the facilitator of the MoSCoW session—aimed to mitigate power dynamics within the group by selecting participants who were technical leads at different institutions with no prior relationships [34]. Facilitators had no stake in design choices, emphasized independent judgment, and minimized influence via structured, low-intervention facilitation. Furthermore, the facilitator attempted to eliminate any assumptions on what was spoken and utilized in situ member checking [35] to verify statements when needed.

This study was reviewed and approved by the Colorado Multiple Institutional Review Board (COMIRB 22‐1061). All participants provided informed consent before participating in the web-based prioritization session. Participation was voluntary, and participants could withdraw at any time without penalty. The study involved minimal risk and did not collect protected health information or other sensitive clinical data. Audio recordings, transcripts, and feature prioritization ratings were deidentified prior to analysis and stored on secure, access-controlled institutional servers. All study data were deidentified before analysis, and no information that could reasonably identify individual participants is reported in this manuscript. Participants received a $50 gift card as compensation for their time.

Our experience with the MoSCoW method was positive: it was easy to execute, intuitive for participants, and enabled prioritization of all 30 features in 74 minutes, indicating feasibility in this case. This aligns with Hatton et al [17], who found that simple prioritization techniques facilitate timely, expert-driven input with minimal burden. Table 4 clearly illustrates that not all the features that were deemed valuable (ie, received at least 2 “must have” rankings) were ultimately implemented. However, the information that was received in the MoSCoW session informed our research team of different perspectives and considerations, including considerations of other institutions. This is valuable because so often in the process of UCD sprints, many features are generated during the brainstorming phase [5]. Therefore, there is a limitation to end-user engagement when conducting discovery work for needs and requirements. Due to a potential large number of suggestions, designers and researchers need a process to identify which features should be developed. To address this, the DEAN research team applied a supplemental consensus process incorporating clinical, technical, cost, and complexity considerations.

Ultimately, the prioritization results informed actual DEAN design decisions, although not in a one-to-one fashion, that is, a “must have” ranking did not equal integration into the administrative portal. However, prioritization results were one strand of evidence that informed the team decision. Discussions during the MoSCoW session informed the research team, which was ultimately responsible for making final decisions on what features would be included in the administrative portal. This is a key point in our design process. Our team strengthened the MoSCoW prioritization by combining it with T-shirt sizing, a lightweight method for estimating implementation effort. In a multidisciplinary team, stakeholders first classified requirements as “must have,” “should have,” “could have,” or “won’t have” using the MoSCoW framework. Our technical lead (AS) then assigned a development and programming effort estimate (eg, extra small, small, medium, large, extra large) to each requirement based on the expertise of the developers assigned to this project. Considering both priority and effort enabled our multidisciplinary team to identify high-value needs and requirements to determine features that can be implemented quickly, while recognizing high-effort items that may require additional planning or resources. This combination supported transparent decision-making, balanced collaborator needs with development constraints, and facilitated decision-making during our prioritization process.

The interactive group format was critical for establishing shared understanding. HIT professionals often interpreted feature descriptions differently than intended. Group discussion enabled real-time clarification, supported less vocal participants, and improved prioritization accuracy. Beyond clarification, discussion yielded alternative design approaches and surfaced key implementation considerations, enriching the UCD process with qualitative insights unlikely to emerge from individual ratings.

We recommend using clear, concise feature descriptions, explicitly stating the pain point each feature addresses, and incorporating opportunities for clarification, particularly in live settings where domain experts can translate terminology. Evaluation of potential feature descriptions for use during the MoSCoW method may further improve clarity, especially for asynchronous formats.

Our findings are consistent with prior reports that MoSCoW is valued for its simplicity, accessibility, and ability to support rapid stakeholder engagement. Requirement prioritization reviews have identified MoSCoW as one of the most used techniques because it is easy to learn and can be implemented without extensive training or specialized analytic methods [10,11]. Similar to previous software development studies, participants in our session were able to rapidly classify features and complete prioritization within a single meeting, suggesting that the method can efficiently support early design decisions in health informatics settings. These observations extend prior work by demonstrating how MoSCoW can be incorporated within a UCD workflow involving HIT professionals rather than traditional software development teams [10,11,16].

Our results also reinforce concerns previously noted regarding category saturation and limited prioritization granularity. Consistent with the observations of Vijayakumar et al [18], a substantial proportion of features were classified as “must have,” while no features received a final “won’t have” designation. This pattern may reflect the tendency of stakeholders to focus on perceived value rather than resource constraints when evaluating proposed functionality. The presence of split ratings and subsequent discussion-based rating changes further suggests that MoSCoW alone may be insufficient for distinguishing among high-priority requirements when multiple features appear similarly important. As reported in comparative evaluations of prioritization techniques, supplemental consensus-building processes may be necessary to achieve more actionable rankings in feature-rich projects [11,16,18]. Future work should assess structured consensus steps to resolve ties.

A key contribution of this study is the observation that the value of MoSCoW extended beyond the prioritization outcomes themselves. Previous literature has primarily evaluated MoSCoW based on its ability to generate ranked requirements [11,16]. In contrast, our findings highlight how group discussion surrounding feature ratings generated design alternatives, surfaced implementation constraints, and revealed differing assumptions about real-world workflows. These observations align with UCD principles emphasizing stakeholder dialogue as a mechanism for understanding sociotechnical contexts and uncovering latent requirements [1]. The rating changes observed during discussion suggest that HIT professional interaction may be as valuable as the final rankings, particularly in HIT projects where implementation success depends on organizational workflows, governance structures, and maintenance considerations [1,17].

There were several strengths of this study. First, the study was conducted in a real-world UCD workflow in an active HIT development process. This potentially increases the practical relevance and contextual validity of the single-case findings. Second, the project leveraged the expertise of HIT professionals and therefore grounds the work in existing contexts with unique implementation considerations.

This study also has several limitations. First, group dynamics may have influenced ratings. We did not assess participants’ perceived comfort or freedom to express their opinions during the structured interaction. Study staff encouraged HIT professionals to be as transparent and open as possible. As a result, we cannot conclude that all participants felt equally able to openly share their perspectives. In future work, measures should be collected on comfort and satisfaction of the participants’ interaction. Second, while the method worked well for 30 features, scalability to substantially larger feature sets remains uncertain.

Next steps in evaluating the MoSCoW plus UCD process should include comparison against other prioritization methods. This potential work could be important to health informaticians and designers if the results support the selection of a prioritization process based on resources and skill sets available. Another area of interest is evaluating the relative merit of independent ratings compared to the discussion between HIT professionals, as observed in this study. The objective of this work would be to determine how much, and in what ways, discussion among experts impacts the prioritization outcome, potential consensus formation, and ultimate feature implementation. Findings in this area could potentially shape a distinction for MoSCoW as a stand-alone ranking approach or a framework for collaborator engagement and deliberation within UCD sessions.

We found the MoSCoW method to be an understandable approach for HIT professionals that was rapid and intuitive. The process provided structured support for research team decision-making throughout a complex UCD software development project in health informatics. The approach appeared to be potentially feasible and a practical way to involve potential end users in the feature prioritization process, while also gaining insightful input to inform the multidisciplinary research team’s design decisions.