Ethics statementThis study was approved by the Ethics Committee of the Medical Faculty (approval number 22-10814-BO for CI and survey) and the Faculty of Engineering (approval number 2111SPKA9493 for TA) of the University of Duisburg-Essen. All procedures were performed in accordance with the ethical standards of the institutional research committees, the 1964 Helsinki Declaration, and its later amendments or comparable ethical standards. All subjects provided their informed consent for inclusion on the TA in written form. The CI and survey protocols did not include any personal data.ApproachFor the definition of requirements, user phrases obtained by the TA method, CI, and continuous feedback regarding derived context descriptions were collected to serve as foundation of an AD revealing the topics most important to the context (Fig. 1). The requirements were then drafted and subsequently ranked regarding their priority by three experts. Physicians with various levels of expertise from the Department of Dermatology at the University Hospital Essen (UME) in Germany participated in these qualitative methods. Senior physicians, specialists, and residents who had just begun working in this department contributed their domain knowledge and personal input (Table 1). Finally, the requirements were reviewed with regard to their relationships to the hospital and excluded if not generally applicable.Figure 1Pipeline derivation and evaluation requirements with a combination of qualitative user-centered methods.Table 1 Methods used to derive and evaluate requirements in the context of melanoma patient treatment, their purposes in the information-processing pipeline, the numbers of participants, and the methods used to collect the data.Think-Aloud methodThe TA30,31 method is common in user-centered approaches and has been used frequently to reveal problem areas and factors important to an inspected context32. It is conducted by asking participants to fulfill a task and at the same time express their thoughts verbally. These actions and thoughts are recorded and analyzed to depict the context and build designs based on this knowledge. This method is applicable to any scenario33, has been shown to be highly effective, and allows modeling and design based on voices of real users rather than external interpretations33.The TA method was conducted with 10 participants from the UME in the field of melanoma treatment. The explored task was the preparation of a fictitious tumor board for a patient in a possibly metastatic setting. Task execution was captured via computer screen and voice recording. To simulate real-world circumstances, this process occurred in the clinic using real patient data from the hospital information systems. The time was limited to 15 min, and no interaction with the conductors occurred other than reminders to think aloud.The TA provided deep insights into the interactions with the software, the relevant data, how they relate to one another, and how physicians translate the information into decisions. Nevertheless, the time required is very high, especially in this time-critical context. The setting and the task were as realistic as possible, and the participants were informed in advance that the study focused on their interaction with the software and not on their medical decisions. Despite this, some physicians were nervous, felt uncomfortable expressing their professional thoughts out loud, and maybe filtered their statements.The data gathered was anonymized by voice alteration and transcription of the recorded voices. Afterwards, relevant phrases were extracted from the transcripts and used anonymously as part of the AD.Contextual inquiryCI16 is a participatory method in user research, which involves the user in the development process and takes an entire context into focus. By accompanying physicians in conducting the tasks supported by software and observing their interactions, the nature of situations can be revealed. With this approach, direct insights into the setting, intents of usage, and utilization of available IT systems can be gathered2. This knowledge enables the design of software that uses context-specific wording and helps to identify standard solutions that might cause conflicts in this context. Even facts that are subconscious and difficult to articulate can be revealed using this method17. Revealing true needs is a strong basis for deriving requirements based on real insights rather than interpretation by external factors28. Conducting a CI is relevant for a holistic view of the context15,34,35.CI was conducted with two participants each for the tasks of outpatient care and the initial presentation of new patients. The information gathered was documented in prepared protocols that focused on the setting, interruptions, and interactions with IT systems or colleagues. No personal information regarding the participating physicians was documented.The CI gave an unfiltered view of the observed tasks, usual settings, and interactions with the medical staff and patients without impacting the physician’s time. The physicians were used to introducing new colleagues to their tasks and being accompanied, which made the CI very realistic and unvaried. Observations were only limited if the patient felt uncomfortable with an observer, or the observer did not want to accompany the medical treatment.To facilitate empathy during the AD modeling process, user phrases were extracted from the protocols by rephrasing the insights in the first person. In addition, any questions that arose during the modeling phase were collected and discussed in semi-structured interviews with two dermato-oncologists. These insights were similarly extracted from the protocols and inserted into the AD.Affinity diagramAs part of contextual design, the AD35 was developed to reveal the topics important to an explored context. Building an AD begins with sorting user phrases and insights gained from qualitative methods according to their content. Obtaining a maximum number of statements per group leads to critical reflection, discovery of deeper insights, reorganization, and rephrasing of the groups. Afterwards, these groups are clustered into sub-topics, which again are grouped into topics. The specified groups, sub-topics, and topics are called affinities, from which the name of the diagram originates. During the modeling process, all groups, sub-topics, and topics are given descriptions in I-perspective, which supports empathy during the design process. This structuring of messages leads to the identification and clarification of areas of interest separated into manageable groups36,37 and serves as a solid foundation to derive user-founded requirements38.RequirementsIn computer science, it is important to formulate a need that software must fulfill under given circumstances and known limitations39 in order to ensure the quality of the implementation and determine the purpose of the task. These needs and limitations are defined as requirements and exist in a hierarchical order with more specific sub-requirements. A distinction can be made between FRs, which define a functionality a software must provide, and NFRs, which describe characteristics a software must integrate. To differentiate their importance, a requirement can be prioritized into three levels. Functionalities or characteristics that are necessary to fulfill a task supported by the defined software have the highest priority and shall be implemented. Useful features that are not essential for task completion are requirements that should be included. Aspects facilitating work but not necessary for reaching the set goal may be supported by the software40.Using these user-centered methods, we have derived a set of requirements for patient dashboard development and optimization in the context of melanoma treatment.Deriving requirementsTo derive requirements based on qualitative data, the transcriptions of TA sessions and CI protocols were split into shorter phrases containing only one message. The user statements were then grouped into three hierarchies and labeled in I-perspective regarding their shared content by modeling the AD. Requirements were determined based on the resulting topics, sub-topics, and groups. Starting with the most abstract level (topics) of the AD, each level down to the very practical user statements was considered individually. The core message of the affinity was extracted and its influence on the dashboard was evaluated. In the next step, this insight was phrased as a new requirement or assigned to an existing one. Afterward, all requirements were examined to determine whether they described a functionality or a feature. Finally, the requirements were grouped by their focus in a hierarchical order, with more specific sub-requirements. The majority of requirements were derived from sub-topics and groups. In very few cases, general requirements were linked to single phrases or specialized sub-requirements referred to a topics.Evaluation of derived requirementsThe derived requirements were evaluated for generalizability; those directly tied to the organization and its specific workflows were excluded. Furthermore, during a survey, the requirements were either prioritized or excluded to ensure correct interpretation of the user phrases by the derived requirements. In this process, two physicians and an IT specialist rated the requirements regarding their prioritization. The following four options were available to classify the requirements, the corresponding values of which are given in brackets: Functionalities or characteristics necessary to fulfill a task supported by the defined software have the highest priority and shall (3) be implemented. Useful features that are not essential for task completion are requirements that should (2) be included. Aspects facilitating work but not necessary for reaching the set goal may (1) be supported by the software. Participants could also mark a requirement as not necessary (0) to check for or add missing aspects. After adding the priorities, the arithmetic mean of the prioritization was finally applied to the list of requirements.Overall, this study combined the TA method and CI to collect user-statements during the work process. These statements were subsequently sorted in an AD regarding their shared topics. These topics and statements were used to derive requirements that were directly related to the context. To prevent misinterpretation of these statements within the requirements, they were finally ranked regarding their prioritization or filtered out by conducting a survey.
