People's willingness for sharing personal data with others allows designers to consider utilizing social comparison functions into behavior change support systems. Behavior change applications, which enable social comparison, seem to be gaining popularity nowadays. Usability flaws may diminish the usage and engagement of behavior change support systems, therefore attention was paid to usability issues in this particular case. Following usability guidelines early enough in the design may save time and resources.
Systems are constantly evolving towards sharing data, even personal data, and even
though the evolution can be difficult to predict, people seem to want to share data with
groups of different people [
Social comparison in fitness applications enable comparing one’s own progress and
performance with that of others, thus providing greater motivation for the user and
potentially enhancing performance [
Nevertheless, the preferences for sharing data are quite dependent on the individual
sharing [
In Promo@Work research project, a health behavior change support system
(HBCSS) [
Goal setting plays an important part in the PSD model and design principles such as
social comparison could potentially help the user to achieve personal goals by
enhancing motivation. Enabling the sharing and comparing personal data and information in a
system for the users will potentially enhance the users’ motivation to perform the target
behavior for the goal they have set for themselves. [
The social comparison theory hypothesizes that peoples’ behavior is affected by the
behavior of other people. Social influence processes and competitive behavior can be
derived from the same socio-psychological process: self-evaluation, which is based on
comparison with other people. [
The HBCSS was developed as a native mobile application for Android-operating
system. Self-determination theory [
When implementing a social comparison function into the mobile application, we had to think of a way to adapt the idea so that it would both fit the content of the application and support the motivation of the users without arousing competition between them. Before the users will gain access to the content matter, the application will inquire the users about their previous health behaviors by 52 questions. The users will be encouraged to answer the questions, but it will not be obligatory in order to proceed within the application.
After the inquiry, the mobile application will propose two different content modules for the users, which will be based on their personal answers and the users will be able to choose either one or skip the proposition altogether. An algorithm calculated the propositions and the mobile app proposed either the second best (least problems within a health domain) or the second worst (most problems within a health domain) content modules for the user.
After next login, another set of propositions will similarly be provided for the users, but this time the propositions will be based on the answers of the whole user base, thus on social comparison, which is informed for the user. The algorithm will calculate the second best (least problems in health problem domain) and second worst (most problems in health problem domain) health content domain modules from the whole user base and propose them for the user. This paper will concentrate on the usability issues of the aforementioned social comparison proposition.
Additionally, the app also had two self-monitoring tools, which were based on social comparison. The tool for stress statistics relied on user-perceived and inputted level of stress, while showing the users the average level of the whole user base. The tool for self-perceived recovery worked similarly, with the exception that a weekly reminder was sent for the users via push notification, whereas one could give input daily in the other tool. 2.3
According to Nielsen [
Each heuristic evaluation principle was compared to the social comparison proposition interface of the HBCSS. The results of the evaluation analysis will be provided within separate headlines of each principle in the current chapter, and will be discussed in the next one.
Visibility of system status. It could be said, that the users will be informed on what is going on at the beginning, as the function will be explained for them. Nevertheless, the social comparison proposition only appears once, while it could have been a better solution to make another proposition later on based on the choices of the users. Match between system and the real world. The proposition will not be presented for the users in system-oriented terms. Therefore, the social comparison proposition for a health problem domain should be a familiar concept for the users.
User control and freedom. The users could exit the proposition with a single push of a button within the interface. If they would choose the proposed health problem domain by accident, they could still exit it via ‘home’ button. Unfortunately, re-doing will not be supported by the app interface, but instead the users will have to choose the domains themselves.
Consistency and standard. The social comparison proposition could be considered consistent with the first non-social comparison proposition. Navigation functions similarly with both, while adhering design standards of similar interfaces. Error prevention. Errors were inherently prevented by the design, because the social comparison proposition would be preceded by a proposition based on the users’ personal answers on first login. Therefore, at least ideally, there should be enough answers on a group level to calculate a proposition based on social comparison before the proposition will be triggered.
Recognition rather than recall. Unfortunately, the interface (including the social comparison function and the app) will not support users in retrieving the proposition later on, which was a clear flaw in the design, because the users will have to remember the proposition, which could be easily forgotten amid the flood of information. Flexibility and efficiency of use. The proposition interface could be said to be efficient, as the propositions are differentiated in separate buttons, giving users quick access to navigate forward.
Aesthetic and minimalist design. The design could be said to be minimalist without any excessive information. The information content could be absorbed with minimal concentration, but some users might just skip the proposition without reading it, as one could push the button of either health domain proposed or skip’ button instantly. A suitable alternative might have been to delay the option for the buttons for a few seconds in order to give the users extra time to decide on their stand regarding the social comparison proposition.
face might express potential errors poorly, as in an error situation, the proposed health problem domain might be shown only as zeros to the users, instead of an error message popping out. Nevertheless, the design was planned in a way that there should be no errors, but still an error message should have been enable just in case. Help and documentation. Help and documentation regarding the social comparison proposition were scarce, or non-existent. On the other hand, the information provided on the proposition should be more or less clear for the users, therefore there would be no need in this case to provide extra information about the function for the users.
Designing functionalities into applications might at times be difficult, especially if the user-base is wide. Iteration during development process could save designers from many usability pitfalls. Overall, the interface design could be said to be functional and usable, but there were two usability flaws. The users should be allowed to re-do, in other words go back to, the social comparison proposition. It could be assumed that when using a HBCSS with extensive content for the first few times, it might be difficult to absorb and comprehend all the information provided. The other flaw was that the users could not check from anywhere what the social comparison based health problem domain proposed for them was. In case the users will accept the proposition, and remember the problem domain themselves, they will be able to navigate into the right domain module independently. Otherwise, the social comparison proposition might be lost for them. 5
Despite the usability flaws in the interface, it could be said that otherwise the social comparison proposition was relatively easy to use and comprehend. Following usability guidelines early enough in the design may save time and resources. Avoiding the reported pitfalls described in this paper may help researchers and designers in their social comparison feature implementations. Acknowledgements. We wish to thank our colleagues at Promo@Work research project, funded by the Strategic Research Council at the Academy of Finland, contract no. 303430 (Finnish Institute of Occupational Health) and contract no. 303431 (University of Oulu, OASIS).