The fourth and last phase of the Creative Technology Design Process is the evaluation phase. Now that a functional prototype is realised, it will be evaluated against the functional requirements from previous phases. All requirements in the “Must” category of the MoSCoW categorisation have to be met by the prototype. Any requirements from the “Should” category will need to be met as well, but failing to do so will still result in a successful evaluation. Any met requirements from the “Could” category add to a positive evaluation, but really do not have to be met. Requirements from the “Won’t” category are not expected to be met. If all functional requirements are met, stakeholder input or user testing can determine whether Nonfunctional requirements are met as well. User testing can also tell whether the user experience is as desired. At last, the entire project will be evaluated, including a commentary of proposed improvements for further research.
3.2 STAKEHOLDER IDENTIFICATION AND ANALYSIS
Part of the ideation phase is the stakeholder identification and analysis. To identify the stakeholders of this project, the stakeholder identification method of Sharp et al.[49] will be used. Sharp et al. propose a method that divide stakeholders into four groups:- Users - Developers - Legislators - Decision-makers
Users are the people that actually end up using the product. The developers are stakeholders because they influence the development, but will not use the product once it is finished. Legislators do not have to be individual people, but can also be any instance that command and control any regulations. Lastly, the decision-makers are people in charge of the development process, like managers
or supervisors. All identified stakeholders will be mapped on Mendelow’s power versus interest matrix[50], shown in Figure 3.2.1. This makes clear which stakeholders are important for the development of the new product.
Figure 3.2.1: Mendelow’s Power vs Interest (Dynamism) matrix [50]
3.3 INTERVIEWS
To obtain preliminary requirements from the stakeholders, they will be interviewed. Interviews can be done in five different ways[51]: structured, semi-structured, unstructured, informal, and focus groups.
Structured interviews make use of questions that are created prior to the interview. During the interview, a guide is used to steer the discussion. This leaves little room for open answers, but leads to very efficient interviews producing consistent data that can easily be compared across interviewees.
Semi-structured interviews are also steered by an interview guide, with earlier created questions. However, when a researcher senses a user can give more helpful response when following a different trajectory, they can deviate from the interview guide.
An unstructured interview is conducted in a formal setting. However, no prearranged questions or guides are used during the interview. The interviewer has a clear plan in mind regarding the focus and goal of the interview.
An informal interview takes place in a casual setting. During an informal interview, the interviewer talks with the interviewer in a normal way, resembling a regular conversation. This allows the interviewee to really speak their mind openly.
Focus groups is a data collection method. Data is collected through a semi-structured group interview process. Focus groups are used to explore new research areas, or to explore topics that are difficult to observe.
used. Doing so will ensure that important aspects are considered by every stakeholder, while the possibility of exploring interesting answers is available.
3.4 USER-CENTERED DESIGN
User-centered design is an iterative design approach, in which the developer is focussed on the users and their needs[52]. This is different from participatory design, where users are also closely incorporated in the development process. Their respective differences are visualized in Figure 3.4.1.
In this project, user-centered design is implemented by getting feedback of stakeholders for each iteration in the ideation phase. Firstly, preliminary requirements are retrieved from stakeholders, in the case of this project using semi structured interviews, from which dashboard concepts are developed. These concepts are discussed with stakeholders again, to select the most, the best ‘matching’ concept. During the Ideation phase, these steps are repeated until all stakeholders are happy with the dashboard concept. During the specification and realisation phase, stakeholders are not involved.
Figure 3.4.1: ”The current landscape of human-centered design research as practiced in
3.5 REQUIREMENT ELICITATION
After identifying the stakeholders and obtaining the preliminary requirements in semi-structured interviews, it is important to categorize them. This project has a limited timespan, and so it might occur that there is not enough time to implement all preliminary requirements.
MoSCoW
One method to categorize requirements is MoSCoW[53]. The MoSCoW method does so by using four categories:
- Must Have - Should Have - Could Have - Won’t Have
Requirements that are vital for the project are marked as Must Have. If the project does not meet those, it might as well be cancelled. Requirements that are not vital to the product but still very important are marked as Should Have. When requirements are still desired, but do not affect the success of the product, they are marked as Could Have. Any requirement that will not be implemented this development cycle will be marked as Won’t Have. This means work effort has to focus on Must Have requirements, while also trying to complete as many Should Have requirements as possible. Any spare time will be dedicated to Could Have requirements.