**5. Deriving sustainability quality requirements from UX assessment**

In this section we present the results obtained following the NUX-based discovery process introduced in Section 3.

#### **5.1 First stage: UX assessment for understanding user needs**

According to our demographic data collected at the beginning of the study, we found that most of our participants worked more than 40 hours per week. The distribution is as follows: 5 subjects reported to work more than 45 hours per week. 5 subjects worked between 40 and 45 working hours. Only 2 subjects worked between 38 and 40 weekly hours.

Regarding RSI symptoms, most of the participants indicated felt fatigue, aching or shooting pain. 3 subjects did not experience none of the symptoms shown in **Table 4**. One of these 3 subjects decided to drop-out from the study after experiencing with the RSI software for 1 day.

Nine of our subjects considered stress as the main trigger of their RSI symptoms, followed by a bad ergonomic posture (8 subjects). Surprisingly, we found that omitting breaks and maximum exposure to technology were considered by less than half of the subjects that experienced RSI symptoms.

#### *5.1.1 First impressions*

At the beginning of the study we found that the RSI software was not enjoyable enough and pleasant. The most positive answers were given by 3 participants using Workrave, who indicated have enjoyed -more or less- with the software. However, despite this non-positive feeling, 7 of out 11 participants felt that using an RSI software was somewhat useful ("more or less" and "significantly high") to support their own wellness (body and mind). Over half of the participants reported that they understood how to prevent RSI during their first interaction with the software. **Figure 5** shows the frequency distribution of the responses in detail regarding these three items that concern about enjoyment, usefulness, and awareness respectively.


#### **Table 4.**

*RSI symptoms experienced by participants.*

#### **Figure 5.** *User experience after day 1 (N = 11).*

#### *5.1.2 UX based on the need's fulfillment*

A total of 9 participants completed the study and filled in the final questionnaire after day 5. **Table 5** shows the answers' frequency to the user experience questionnaire items and the weighted average. After several days of use, it is confirmed that the extent of "enjoyment and pleasant" is low. The "safe from uncertainties" score reinforces the idea that participants were not fully sure on how the break reminder and monitoring features work (e.g. how the breaks based on the stress level is determined by SmartBreak).

Most of the participants perceived that the software provided "a bit" support for items related to the physical and mental well-being. This feeling was confirmed by the last two items, where participants did not show to have the impression that the software was supporting their commitments and supporting behavior change in a natural way; therefore, more feedback from the software could be needed along with a different strategy to communicate how the software works and help to attain goals. Overall, it seemed that participants have got a moderate belief of "doing

*Negative UX-Based Approach for Deriving Sustainability Requirements DOI: http://dx.doi.org/10.5772/intechopen.96535*


#### **Table 5.**

*UX based on the needs fulfillment on day 5 (N = 9).*

something good for their body and mind", and have been developing some moderate understanding on how to prevent RSI.

#### *5.1.3 UX variation analysis*

In order to understand the possible variations of the user experience reported after the first day, we carried out an individual analysis with the participants (S1, S2, S5, S6, S9, S11, S12) who finished the study.

What stands out in **Table 6** is that there was not any variation in enjoyment and pleasant from day 1 to day 5. Similarly occur for the other two items concerning


#### **Table 6.**

*User experience variations along the study.*

usefulness and awareness. However, what we can remark is that there were two few positive variations (colored in green), which correspond to subjects S2 and S9. Both subjects started rating negatively, but at the end of the study, they considered that the software was good for their own wellness, and to understand better on RSI prevention. Both continued considering their level of enjoyment as negative though.

This was mainly because breaks used to be considered as interruptions. (S2) *"Interruptions while typing, and (interruptions) of the reasoning flow while working"*. But then these breaks were understood as a time for resting. (S9) *"It reminds me that I must relax"*. Unfortunately, this change of attitude occurred only in these two subjects.

We observed also a negative variation (colored in red) that was detected in subject S1, and subject S12. (S1) *"When focusing on a task, being required to take a break resulted to be from time to time counterproductive".*

#### *5.1.4 Subjective rating of positive and negative UX*

Participants rated the four items of in second part of the UX questionnaire that correspond to positive/negative feelings and experience (i.e. "I had a positive experience", "I had a positive feeling", "I had a negative experience", "I had a negative feeling"). The collected responses at day 1 and day 5 (see **Appendix A**) have been processed to facilitate their assessment, leading to overall indicators of UX presented in **Tables 7** and **8**. **Table 7** depicts the frequency for both positive and negative UXs, in such a way that the overall UX is calculated by aggregating the experience and feeling single items. It reports the distribution of the overall UX at the beginning and at the end of the study. It clearly shows that there were a mix of positive and negative user experiences.

In order to calculate the overall UX scores, we averaged the values assigned by the respective participants using Workrave (WR) or SmartBreak (SB) along the study, which are depicted in **Table 8**. It shows the corresponding overall UX of both RSI software was somewhat negative.

On the overall positive UX, data revealed that software applications did not manage to raise a significant or very positive UX. At the end, the ratings for positive experiences suggest that systems were better considered than they were at the beginning, low to moderate though.

Overall negative UX frequencies suggest that at the beginning there were not much negative UX (notice that 46% replied *Not at all*), but participants manifested that negative experiences and feelings became more intense at the end of the study.


**Table 7.**

*Frequency distribution for overall positive and negative UX.*

*Negative UX-Based Approach for Deriving Sustainability Requirements DOI: http://dx.doi.org/10.5772/intechopen.96535*


**Table 8.**

*Overall UX scores on day 1 and day 5.*

### **5.2 Second stage: translating user needs into requirements**

In order to discover requirements that should be addressed by a persuasive software application (RSI software in particular) designed for helping people change their behavior to achieve healthier habits, our analysis focuses on the UX results and open-ended descriptive user responses (comments and suggestions).

By mapping user needs (first step of second stage) that were not fulfilled and what people would like to have (results presented in Section 5.1), we found that the premises P1 (Useful), P2 (user friendly), P3 (Unobtrusiveness), P4(Open), P5 (Cognitive consistency), P6(Incremental) were affected, which were accordingly translated into usefulness, pleasure, unobtrusiveness, transparency, cognitive consistency, and awareness requirements. For instance, from the questionnaire (I4, I5) some participants showed their perceptions that the RSI software was not so useful for keeping them more physically active and less mentally tired. It is also important to remark that the usefulness perception of a software system could vary along the time. (i.e. at the beginning some users expected the system would help to change their habits positively but at the end this did not happen).

Analyzing these unfulfilled user needs, we found that both RSI software apps lack some features related to dialog support, primary activity support and credibility categories (second step of second stage). For example, **Table 9** shows the discovered requirements like transparency, awareness, and consistency, which are helpful for implementing features from the *dialog support* category (i.e., providing relevant, motivating and adequate feedback to its users). Other important requirements from the primary activity support category are pleasure, usefulness and unobtrusiveness. And transparency that helps also to the features from the credibility category.

#### **5.3 Third stage: deriving sustainability-quality requirements**

Considering the relations of the SQ model for each NFR(attribute) identified in the previous stage, we found out other relevant requirements that contribute to the sustainability dimensions.

For example, regarding the *primary activity support*, pleasure is positively affected by adaptability. This attribute is relevant for contributing to the social and technical sustainability of the RSI software. But as shown in **Table 9**, this requirement was not adequately addressed. If the RSI software had more information about the current situation, an adapted modality of breaks reminder could be delivered, which could influence positively on UX too.

It similarly occurred for usefulness, a key quality attribute that contributes to the economic, social and technical dimensions (see **Appendix B**), and it is positively related to learnability and effectiveness attributes (both from social dimension). From the UX assessment (**Table 9**), we corroborated that learnability and effectiveness were not satisfied by users. For instance, although Workrave provides an animated coach to teach a series of body movements, the UX could be affected if the content itself was not easy to learn/understand (learnability), or users were not able to change some of the exercises proposed by the system (tailorability).


#### **Table 9.**

*NFR found from the UX assessment.*

Given preferences can vary significantly over users with different profiles (ages, interests, etc.), tailorability is an important requirement that must also be considered. From user suggestions, we found that this requirement was not fully addressed. We also found that the break reminder could have a negative effect on

*Negative UX-Based Approach for Deriving Sustainability Requirements DOI: http://dx.doi.org/10.5772/intechopen.96535*


#### **Table 10.**

*Example of candidate features and sustainability dimension covered by discovered NFR.*

the user's experience due to that this reminder sometimes occurred in a not favorable time (lack of timeliness).

Finally, the third category, *credibility*, consists of two requirements that relates to the confidence on software systems that behave as intended (trust) and transparency of the system (implications and consequences of functionality such as skipping or postponing breaks or when they will be offered should be clear to the user regardless of the internal details on how they are being handled or implemented). Trust, an attribute from the social and technical dimension of the SQ model, was derived thanks to the positive relation with the pleasure attribute from the social dimension.

**Table 9** presents the 6 NFRs discovered at the second stage (text in bold in the last column) and 7 NFR derived from the SQ model at the third stage. By means of our approach, in this stage we can also determine (i) the new potential features that should be considered in further versions of the software for RSI prevention, and the sustainability dimensions that can be covered with the implementation of the discovered NFRs. Some of the identified features as potential improvements are shown in **Table 10**. For example, the self-monitoring feature might help to address the usefulness of applications because the system would be able to provide other means to track user status through self-monitoring.

### **6. Threats to validity**

In this section, we discuss the threats to the validity of our user study.

#### **6.1 Internal validity**

A threat related to the *instrumentation* could be caused by the questionnaires used during the study. Aimed at mitigating this threat, the online questionnaires were carefully reviewed and tested before running the user study. Given the type of collected data (e.g. actual number of working hours), we decided to make responses anonymous (IP were not recorded) and participants were informed of such anonymity. But for our study, responses traceability between the first and second questionnaire was required. Thus we asked participants to create a fictitious username that still kept their responses anonymous.

Considering our user study took five working days and it was conducted in a real setting with a null control, the threat of having a high number of dropouts (*mortality*) could not be reduced. But we tried to reduce it, by informing to the potential participants beforehand about the length of the study, and the existence of a final questionnaire that should only be filled in if the study rules were met, regarding

duration and having worked with the computer normally during that time. We got twelve participants from thirty invitees, who accepted our invitation. Once the study was running we sent a couple of emails to remind deadlines for completing the respective UX questionnaires. At the beginning of the study we had one participant who dropped out from the study. And two more at the end of the study.
