Table 2 Proposed user interface design recommendations for mobile health applications
Theme | Sub-theme | Design recommendations | Description |
|---|---|---|---|
Privacy & security | Social privacy | Password protection | App-level password or passcode protection should be implemented every time the user accesses the app or after a certain period of inactivity |
Privacy settings | App-specific privacy settings should be available; default settings should err owards providing higher levels of privacy | ||
Discreet design | Logos, icons and terminology used should be subtle and not draw attention to sexual health | ||
| Â | Institutional privacy & security | Assurances & disclaimers | Information should be provided on the reason for requesting any sensitive data |
Just-in-time disclosures | Disclosures should be provided before allowing the app to access sensitive content (such as geo-location information) through APIs | ||
Confidentiality & security policy | A clear policy on how information will be collected and stored should be provided and should be available to view in a number of formats (e.g. online, or download and read offline). | ||
Credibility & Legitimacy | Explicit Credibility | Assurances of medical content accuracy | Apps should provide information supporting their adherence to established medical guidelines including references/links to trustworthy third party material or resources |
Identification of ‘app operator’ | Apps should disclose information about the legitimate organisation behind the application, including how to contact them; web apps and online support should use a culturally relevant domain name and support information should be up to date | ||
Affiliations | Any affiliations with existing respected providers (such as the NHS) should be clearly displayed, for example through the integration of relevant logos within the app design | ||
| Â | Implicit credibility | User community cues | Accompanying website / social media / app store presence should include user reviews and/or case studies |
Visual aesthetics | Culturally relevant and conventional health-related colour schemes and typeface should be used | ||
Language | The language used should have a serious and professional tone; sentences should be concise and use uncomplicated structures; a glossary of medical terms should be available | ||
User journey support | Â | Simplification of complex healthcare journeys | Provide graphical representation of progress made for multi-step interactions; give overview of steps to be completed at the start of the task |
Content relevance and logic | Where the app includes a decision support system (such as a medical consultation to decide if it is safe to prescribe) the questions should be relevant and dynamic, using logic to filter out irrelevant questions based on the information already provided | ||
Specific and appropriate feedback | Visual (or audio) cues should be used to indicate erroneous data entry and also proactively indicate once a user has entered acceptable data in a field; error messages should support error recovery | ||
Reassurances | Take steps to reassure users that there are no catastrophic consequences of making errors in completing an online consultation; provide opportunities to change erroneous inputs | ||
Flexibility in the delivery of support | Provide flexibility to users in terms of how they can access support (e.g. online and offline; web, telephone and face to face) | ||
Task-technology-context fit | Â | Ubiquity | Design should accommodate different contexts of use, supporting platform independence and the ability to switch seamlessly between contexts of us |
Mobility | Design should support mobile context of use which may include interruptions due to concurrent activity or lack of connectivity; design should thus accommodate short bursts of interaction, allowing user to save interaction with app and not lose progress | ||
Customisation | Users should be able to customise parameters of the app to accommodate their own preferences, particularly for system notifications |