Implementation of the MoSCoW Method and User-Centered Design to Prioritize Features for a Decision Aid Navigator (DEAN) System: Single-Case Qualitative Process Study

Introduction

User-centered design (UCD) processes often generate many potential software features [1-4], making systematic prioritization essential to balance limited resources with usability goals. Prioritization serves as a key transitional step between user requirements discovery and software implementation, enabling development teams to identify the functionality that should be advanced into prototypes and production systems.

However, when designers engage collaborators to gain insider perspectives, they may encounter a well-documented phenomenon. This phenomenon, often described as a design trap, can arise in both UCD sprints focused on narrowly defined user groups and human-centered design sprints aimed at population-level users. It is known as overreliance [5]. Iteratively interacting with end users early and throughout the design process is a core principle of both UCD and human-centered design. Design solutions emerge not only from discussions with relevant users on how they view and think about the problem, but also in their perspectives on how to solve the problem. These solutions are sometimes described in terms of needs and requirements for the forthcoming health information technology (HIT). Collaborators can often go beyond the scope of a proposed solution in their feature recommendations.

When scope creep is present in the development of HIT as a result of obtaining recommendations from potential users, teams may need processes to narrow the number of proposed needs and requirements. The MoSCoW (must have, should have, could have, or won’t have) method [6-9] is a widely used prioritization approach in software development for categorizing features [10-12]. Despite its widespread use, little research has examined how MoSCoW functions within health informatics UCD workflows or how stakeholder interactions during prioritization shape design decisions. Importantly, successful designs take insights from not only users of the HIT, but also from multidisciplinary teams’ expertise and creative problem solving that those teams have developed.

We applied the MoSCoW method to the development of the administrative portal of the Decision Aid Navigator (DEAN) system [4]. DEAN was co-designed with stakeholders from 4 academic medical centers and aimed to reduce barriers to decision aid use by embedding a provider-facing SMART on FHIR application [13-15] within the electronic health record to support shared decision-making [4]. The administrative portal (Figure 1) enables HIT professionals to manage decision aid metadata and associated clinical quality language logic used to trigger appropriate tools. During the exploratory UCD process, qualitative analysis of technical expert interviews identified 30 candidate features for the portal application.

‎

The MoSCoW method’s main strength is its ability to yield insights with fewer participants. It is easy to learn and apply, enabling project teams to quickly gather meaningful user feedback and identify high-value features [16,17]. This ease of use promotes greater confidence and engagement than more complex prioritization methods [16,17]. However, MoSCoW does not distinguish priorities within categories, which can limit its usefulness for feature-rich projects or cause overuse of the “must have” category [16,18].

Evidence of its implementation in health research, particularly for clarifying priorities and limiting scope creep, remains limited. Although prior studies report widespread use and acceptability, actual application in health research is not well described [10,11,16,18]. This study provides insight on HIT professionals' engagement with the MoSCoW method in a UCD process and makes recommendations on the use of this method.

Methods

Procedure

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.

Ethical Considerations

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.

Results

Four HIT professionals completed the 74-minute group session, representing health system technology and clinical informatics roles. Demographics were as follows: for gender, 3 were male and 1 participant’s gender was not reported; for age, 3 were 41‐49 years and 1 was 50+ years; and for race, 2 were White and 2 participants’ race was not reported.

Participants grasped the feature descriptions (Multimedia Appendix 1) with minimal explanation and immediately began rating. For 28 (93%) of the 30 features, participants started group discussion to clarify feature descriptions for shared understanding, offer feedback, and share valuable sociotechnical advice. Two of the features were ranked without comments or questions.

Table 1 describes the ratings. Participants rated a mean of 12 features before any group discussion began. All participants changed their initial rating more than once (range 3‐6 changes). Participants stated they were changing their rating based on discussion and clarifications (eg, “That’s less important.”). All rating changes occurred for features where group discussion took place.

Participants rated 37% (11) of the 30 features as “must have,” 13% (4) as “should have,” 20% (6) as “could have,” and none as “won’t have” (based on majority rules). The remaining 30% (9) of the features had split ratings showing no majority, as shown in Table 2. The summary percentages are derived from majority vote, not from individual-level ratings.

Table 3 details the ranking changes and what features were implemented. Of the 30 features, 14 were implemented. There were 10 features that received all “must have” rankings; of those features, 6 were ultimately implemented into the final system; features 12, 15, 20, and 26 received all “must have” rankings, but were not developed. Of the remaining features that were not implemented but still received at least 2 “must have” rankings, feature 19 had 3 “must have” rankings and features 2 and 7 each had 2 “must have” rankings.

Descriptive analysis revealed 4 key MoSCoW insights (Table 4).

Discussion

Principal Findings

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 “musthave,” “shouldhave,” “couldhave,” or “won’thave” 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.

Comparison to Prior Work

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].

Strengths and Limitations

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.

Future Directions

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.

Conclusions

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.