Visualizations & Design
The use of good contrast was rated by the co-design team in the Got-IT showcase as one of the most important recommendations for eHealth developers. This will make the information better accessible to not only users with low eHealth literacy, but to everyone.
The below figures show an example of the result of the case study with the Activity Coach app. Figure 1 shows the old version of the 'Step' page and Figure 2 shows the same page, but with the removal of the background image to avoid confusion and to increase the contrast
In the WCAG 2.0 accessibility guidelines the minimum contrast between foreground and background is recommended to be at least 4.5:1 (or 3:1 for lage-scale tekst) and enhanced contrast should be at least 7:1 (or 4:5:1 for large-scale text).
Several contrast checkers are available online, such as:
Several recommendations regarding easy and understandable language are available in the Pharis checklist (https://checklisttoegankelijkeinfo.pharos.nl/ checklist in Dutch), the most important being:
Use short sentences and easy words on A2-B1 CERF (Common European Framework of Reference) language level. See Figure 3 for the CEFR language levels. More information on these language levels can be found here:
- Use active sentences
- Avoid difficult technical or medical terms
- Avoid non-native words
- Avoid percentages and formulas
Figure 3 shows an example from one of the co-design sessions of the show case with the Activity Coach app:
Figure 3. The result of one of the co-design sessions with end-user with low eHealth literacy, when re-designing the Activity Coach app: the most important information is placed in the center of the screen and made bigger than the rest.Figure 4 a, b and c show some more examples:
Figure 4. a, b, c. Examples of screens with the most important information placed in the centre of the screen and made bigger than the rest.
Images, icons and symbols are very useful for replacing text. When using them make sure they are clear, recognizable, simple, consistent and meaningful/understandable by everyone. Icons should be labelled with text whenever possible. See some example below:
Figure 5, a.b.c, examples of meaningful icons labelled with text as well.
The most important information should be highlighted. Use colors (signal colors) with caution, especially when there are feelings/meanings assigned to them. Save the colour red for when it is meant to signal danger. See f.e. Figure 6 where the heart rate graph in red was perceived as dangerous. Use the colour green when you want to stress that something is good, safe or positive.
Figure 6. Screen of the Activity Coach showing heart rate data.
Also, always check the color for users that are visually impaired – for example color blindness (the majority of design programs have an option to switch between the color modes), as well as older users who cannot differentiate colors too well. It’s best to always use an icon or a background highlight to accompany important notifications in order for them to be noticeable. There are online services available that let you test your interface for accessibility with respect to color blindness, like VisCheck (https://www.vischeck.com/).
The following screen from the Activity coach app was perceived as overwhelming for the end-users, because too much and repetitive information is presented on one screen (see Figure 7). Also, the black background was perceived as useless and overwhelming.
Figure 7. Screen of the Activity Coach app showing sleep data.
Another example of too much information shown on one page is the following screen of the Activity Coach app showing the Heart Rate (see Figure 8). In one screen the resting heart rate, the heart rate over time and the actual heart rate (HR) at the current time are shown. End-users perceived this as overwhelming and for them it was hard to distinguish between the actual/average or resting HR.
Figure 8. Screen of the Activity Coach app showing heart rate data.
Make sure that no scrolling is needed and everything fits on the screen.
It should be clear for all users which parts/buttons are clickable. If, for example, it is possible to interact with a graph to zoom into more detailed information this must be made clear to the user with distinct styling. Also, keep in mind that clickable buttons are often perceived as too small (see point 9 in the checklist).
Graph visualizations should be labelled, e.g., describing clearly what a data presentation means, also given people with low eHealth literacy are not always familiar with such visualizations.
Add icons or other descriptions to the graphs labels to make numbers clearly understandable (e.g., time, hours). F.e. in Figure 7 and Figure 8 it was not immediately clear that the x-axis is the time in hours.
Fonts should be a minimum of 16 px. Some sources recommend 12 px, but these were even perceived as too tiny.
Preferably, users should have the possibility to increase or decrease font sizes at will.
Sans serif typefaces are often preferred for on-screen readability.
In general, wherever there is a ‘recommended’ size or distance specified, designers should view that as the absolute bare minimum for any interface targeting older people or users with low eHealth literacy.
Given the individual differences between users in their experience of using eHealth applications, we recommend to: adaptability and personalization of eHealth applications in:
- Personalize the (health) goal(s) that the end-user can obtain via the service
- Personalize the level of details in graphs. End-users with low eHealth literacy have difficulty understanding graphs at all, for them it might be better to just show a number or a very simple graphic representation.
- Personalize interface design in terms of color, sounds
- Personalize the amount of and difficulty level of health information.
- Personalize the available functionality; only provide basic functions to keep it simple and not overwhelming, and extend functionality upon explicit request by the end-user.
Suddenly appearing advertisements and pop-ups were perceived as one of the most annoying things while using eHealth applications and websites in general, according to end-users with low eHealth literacy. It is one of the reasons people get stuck and do not understand how to proceed using the application, causing a lot of drop out.
If you need to use ads anyway, make sure that they are easily removable.
During the co-design sessions, participants were reluctant to agree with Privacy statements, without really understanding them. Try to avoid long texts explaining privacy statements, instead think of explaining them with pictures and short sentences.
Be transparent about the data that will be collected by the application, and do not collect data unless it’s necessary.
Most devices support the use of a read aloud function, or already have this functionality integrated. Make sure it can be started from the application itself.
Recommendations for development and co-design
Co-creation is a collaborative process: Always actively recruit diverse groups and include people with disabilities and of all genders throughout the design process. Acknowledge them as specialists that contribute new approaches and angles of view. Be open-minded, listen to participants' experiences and value their contributions. Remember that participants are experts in their own right.
The process of inclusive design and co-creation allows for considerable time and other resources. Take into account that getting familiar with new eHealth applications is often too time consuming and frustrating for users with low eHealth literacy. Consider one of the following solutions:
- Provide an onboarding procedure within the application.
- Provide a short, understandable video on how to use the application.
- Provide a short tutorial at the start, with the option to skip it and restart it again later.
When introducing new eHealth applications to patients, it is best to foster a bottom-up-approach, i.e. familiarize the users with the tools and raise the awareness and acceptance among the patients themselves. New eHealth solutions are accepted most, if there is a positive word-of-mouth amongst the users. It is furthermore best to take it slow with the introduction of new digital tools to ease the patients into it.
Whenever possible, care providers should be involved in the process of introducing a digital health solution to patients and clients.
Studies show that it is important to make medical information and advice trustworthy to the users, therefor evidence-based, good quality and user-friendly presentation of data is needed [8, 9, 10]. Always state the source of medical and health information, and only include information that is based on clinically validated information.
eHealth applications should be designed in an inclusive, accessible and non-discriminatory manner.
Do not reflect stereotypes (e.g. choices of color, typography, symbols, etc.) and take into account differences in physiology between genders.
If information regarding gender is relevant give more than two binary gender options or make this question optional
In many or even most cases participants do not get any refunds for participation (apart from reimbursement of travel expenses). If possible, incorporate in the budget a generous refund pot. In case a refund is offered to participants, make sure that the administration around refund claiming is made as easy as possible for participants. Facilitate prompt payment of refund and check this with the participants. Also, participants may appreciate it when they can keep any gadgets that they used to test during the project. Send your participants a brief report about the project outcomes and their contributions to these. If feasible, discuss the reimbursement options at recruitment or at the beginning of the project to make sure that the reimbursement is as preferred.
Long-term motivation is key.
In order to prevent users to stop using your application, we recommend to add a sense of accomplishment/success, f.e. using a smiley in the app or providing a reward by collecting points, when a job is well done.
Diverse kinds of gamification aspects can be used to reach a higher motivation to engage with eHealth applications. F.e. avatars and virtual coaches can support the user during navigation, and provide personalized notifications. Providing group challenges will enable peer-activities in the digital environment and increase engagement as well.
Users react in different ways to notifications about rewards, therefor we recommend to provide the option to personalize how often and in which way users would like to receive these notifications.
Technical problems and loss of data can be highly frustrating to users, even more so to users with low eHealth literacy. In most cases it leads to a situation where they will stop using the application. In these cases it is important to provide sufficient support, and to make it clear were to turn to in case of technical issues or other needed support (f.e. during installation of the application). Support at every stage is necessary. It is also recommended to provide the option to request assistance when starting with the app. In these cases group sessions could be organized to help & educate several people at once during face-to-face workshops.
With the rise of digital healthcare, the amount of available eHealth applications is overwhelming. Whenever possible we recommend to provide interfaces with other eHealth applications, and aim for central data storage.