Personal User Experience (PUX) Recommendations and
Lessons Learned
Guidelines for manufacturers and developers of Active and Healthy Ageing solutions aiming for a Personal User Experience
EIPonAHA, Action Group C2
Version 1 ·
Feb. 2018
Video on Youtube: PUX Guidelines - Overview
Table of contents
Annex: Contributors to this document
Foreword
The Personal User Experience (PUX) working group of the European Innovation Partnership on Active and Healthy Ageing (EIPonAHA) and its Action Group C2 on interoperable independent living solutions has charged itself to “contribute to the development of knowledge for Personal User Experience, building on the results available” (see C2 Action Plan). As a result, the PUX working group has produced this document as guidance for the development of AAL solutions that support what we call a “Personal User Experience”.
The PUX working group has defined “Personal User Experience” (PUX) and a “PUX-enabled solution” as follows.
A Personal User Experience (PUX) is a positive user experience for an individual user, taking into account the following:
● A positive PUX is when the solution matches the user’s goals, needs and preferences.
● Different users may have different wishes, needs, and preferences.
● An individual user’s wishes, needs, and preferences may be specific to the context of use (including their goals, their equipment and the environment), and are subject to change.
● An individual user’s needs and preferences may include preferences regarding the collection and sharing of personal data (privacy).
● Accessibility for persons with disabilities and older persons is a prerequisite for PUX.
PUX-enabled solution:
● A PUX-enabled solution accommodates an individual user’s specific wishes, needs, and preferences in a specific context of use, as much as possible, even when those wishes, needs and preferences change dynamically.
● In consequence, a PUX-enabled solution development requires dedicated user involvement (user-driven design).
● A PUX-enabled solution will significantly contribute to the individual user’s empowerment, by supporting and training the individual user to better understand and express their own current and future wishes, needs and preferences.
PUX-enabled solutions provide the following benefits:
● Users find it easier to use the solution because it meets their expectations. They have a better user experience, more joy of use and make less errors.
● Users with disabilities and older users (who often experience a slow degradation in sensory and cognitive abilities) can fully use the solution, optionally with the support of assistive technologies.
● Service providers (including caregivers) find it easier to use the solution, are more productive and make less errors.
● Manufacturers need to spend less time and costs on the training of the users and service provider personnel.
● Manufacturers can more easily comply with accessibility regulation.
The recommendations in this document have been collected by the PUX working group in a collaborative effort. The developers of the PUX showcase competitions in Nov. 2016 and May 2017 (competition report) contributed the initial statements of advice; these statements were then merged and further edited by the PUX group coordinators, and finally discussed and refined by the PUX working group. A list of contributors is available in the annex.
We (the PUX working group) hope that you (and ultimately the users of your solutions) will benefit from reading this document. If you have any feedback, please make a post to the PUX working group forum.
In this document, we refer to your product or system as a solution. We expect that - by following the guidelines in this document, you will make your solution more valuable to your customers.
Recommendations
1.
General recommendations
1.1 Make adaptable solutions: Allow users to adapt your solution
The user should be able to adjust the look & feel of your solution. And the user should be able to adjust the functionality of your solution (including parameters such as thresholds for monitor alarms). Example: The user includes a doctor or clinician who is responsible for monitoring a client.
1.2 Make adaptive solutions: If the system actively adapts to a user, allow the user to overwrite the system's choices
There are two ways of letting the user overwrite the system’s choices: (1) ask the user to confirm or reject a proposed adaptation; (2) allow the user to undo the adaptation. Make your solution learn from the user’s overwrites: do not propose a rejected adaptation again under the same circumstances.
1.3 When the user changes user interface settings, update the user interface immediately and continuously
The user gets immediate feedback whenever they change the user interface settings (for example, change the font size as the user moves the “font size” slider). If the new user interface does not fit the user’s expectations, they can abandon the last changes, or revert to the default settings (reset).
1.4 Remember the user's settings and adaptations
Users prefer to store their settings and do not want to configure them every time when using the solution. User preferences should be remembered even across different devices and hardware or software platforms. For example, if a user chooses a large font on their tablet, fonts should also be enlarged on their TV.
1.5 Store the user's preferences rather than their (dis)abilities
Respect the privacy of the user’s data. It is not necessary for a solution to know the user’s disabilities, if any. It is sufficient to know about the user’s interaction preferences. For example, a person who is hard of hearing may want system messages to be spoken in a low frequency, or displayed as text, or both.
1.6 Do not stigmatize your users
Make sure that your solution looks attractive and is meaningful to everyone. Do not exclude any sub-group of users.
1.7 Design simple and easy-to-use solutions
Your solution should be easy-to-use. Hide the system’s complexity from the user, and provide a smooth and comfortable user experience. This includes the whole lifecycle of the solution (“customer’s journey”): information, buying, installing & mounting, using, maintaining, updating, uninstalling, disposing & recycling (hardware).
1.8 Design human-friendly technology
People should feel comfortable with the technologies they are using. They want to communicate with them in a way that they consider most natural and intuitive. For example, provide interaction modes for touch and voice. When using avatars, have them show facial expressions.
1.9 Provide information in different formats and by redundant navigational means
Different formats include text, images and videos (with captions* and audio** description). You may also provide a printed “getting started” or “user manual” booklet. Typical navigational means include navigation menus, toolbars, step-by-step dialogs, a search textbox, and speech input.
* See W3C Web Content Accessibility Guidelines 2.0, Success Criterion 1.2.2, https://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-captions.html
** See W3C Web Content Accessibility Guidelines 2.0, Success Criterion 1.2.5, https://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-audio-desc-only.html
1.10 Design in a way that the user can recognize rather than remember.
Use icons that are easy to recognize. Use a consistent look-and-feel for your user interface components. Make components that require user input (e.g. buttons) easy to recognize as such.
1.11 Single sign-on for all apps
The user should be able to access all functionality of your solution by logging in once rather than multiple times.
2. Development process
2.1 Start defining user profiles, real needs and true expectations
Use personas (i.e. the CURE personas) and analyse the context of use (expectations of the user, characteristics of the task, the equipment, and the environment). Think about the social character of your solution - rather than its technological features.
2.2 Consider your users’ characteristics
Make sure that you take into account the following: (1) demographics (e.g., age, location of residence, educational level, cultural background), (2) technology usage (ownership of devices, technology skills, attitudes towards technologies), and (3) health status (diseases, attitude towards care professionals, medical skills and knowledge).
2.3 Focus and meet the needs and expectations of your user groups
Consider both individual users and homogeneous sub-populations (e.g. represented by personas).
2.4 Consider different personalisation strategies for different groups of users.
Personalisation strategies can include: automatic adaptation, letting the user choose from a set of pre-defined profiles, and manual configuration by the user.
2.5 Use an iterative development process, following a user-centered design
Involve as many users as possible and use clear and persistent explanations supported by tangible resources.
2.6 Perform a triple validation
Validate your solution and its design in three ways: (1) Technical validation, (2) inspection by relevant stakeholders and (3) validation by a wide variety of identified real users in the lab and in the field. Note that relevant stakeholders include the service providers (acting as “social mediators”).
2.7 When evaluating your solution with users, respect their rights on information and privacy
When involving users in trials and tests, explain well the conditions of participation and make sure that their data are treated in a confidential and secure way.
2.8 Make your solution responsive
A responsive solution adapts itself to the user’s selected preferences, their behavior, and their devices (e.g. size of user interface components, color schema).
2.9 Build modular solutions like LEGO® bricks
Separate frontend from backend, so that the user may have a choice between multiple user interfaces. Allow the user to extend your solution by adding additional modules, if needed. Use a standard protocol (e.g. REST) for communication between the modules.
3. Applying Standards
3.1 Avoid proprietary solutions
Use software libraries based on standards. Apply hardware standards such as USB. If no appropriate standard exists, publish an external interface for your component so that other vendors can connect to it.
3.2 Identify relevant general and sectorial regulations and guidelines for your solution and follow them
For example, apply ETSI EG 202 487 “Human Factors (HF); User experience guidelines; Telecare services (eHealth)” if your solution belongs to the telecare services sector.
3.3 Build personalisation on top of Design for All (DfA) standards
As a baseline (i.e. default user experience), follow the principles of Design for All, to be generally accessible to all users of your solution: (1) ISO/IEC 29138-1 to address the basic user needs of various user groups; (2) Web Content Accessibility Guidelines 2.0 for a minimum level of accessibility; and (3) ETSI EN 301 549 to apply accessibility requirements suitable for public procurement of ICT products and services in Europe. On top of Design for All, build personalization features to further improve the user experience for the individual user.
3.4 Use a standardized format and vocabulary for user profiles
ISO/IEC 24752-8 “User Interface Resource Framework” defines JSON and XML formats for user profiles. ISO/IEC 24751-1 "AccessForAll framework for individualized accessibility" defines a registry for a user profile vocabulary (terms for the description of user preferences and needs).
3.5 If your solution employs the concept of exchanging user interface resources at runtime: Use a standardized format and vocabulary for describing resources and components of user interfaces so that they are easily discoverable
User interface resources and components include icons, videos, audio clips, help texts, and other parts of user interfaces that can be adapted and exchanged. ISO/IEC 24752-8 “User Interface Resource Framework” defines JSON and XML formats for user interface resource descriptions. The DCMI Metadata Terms define a vocabulary for describing user interface resources and components.
4. Privacy & Security
4.1 Make your solution private and secure
Protect your user's privacy (make your solution “private”), and protect your user from harm (make it “secure”). Encrypt if you can, anonymize if you cannot. Make sure your users’ data are handled, transmitted and stored securely. See also: European General Data Protection Regulation.
4.2 Explain what data are collected by your solution, and how they are going to be used and how this benefits the users
Users have a right to know what data are collected (e.g. a user’s movements in their home, their heart rate over time, etc.). Specify whether the data stay in the user’s home or are uploaded and stored in the cloud. Explain why this is necessary for providing functions that the user wants.
4.3 Allow the user to control their (data) privacy settings in a usable manner
Provide an explanation and examples for each privacy setting. Consider providing a step-by-step dialog to identify a user’s preferred privacy settings. Consider allowing the user to choose from a set of pre-defined profiles which are described in easy language. Include the privacy settings dialog in your usability tests.
4.4 Users provide their consent to their data being collected and used by your solution.
Follow the European General Data Protection Regulation.
5. Business model
5.1 Consider developing multiple (personalized) business models for each user group
Identify the specific values of your solution for every user group, and consider developing multiple (personalized) business models for each of them, or one business model that is flexible enough to accommodate different user groups.
5.2 Design your business model in a structured and systematic manner
When accommodating multiple user groups, consider using a tool like business-model-canvas.
5.3 Consider all stakeholders in the purchase and usage processes of your solution, including buyer, payer, user, prescriber, and service provider
For each stakeholder group, look at their expectations along the complete value chain.
5.4 Make your solution affordable for each of the user groups
Some users may not be able to pay for the solution from their own budget. Consider supporting your users in applying for medical and health insurance funds, or using leasing models, for example.
5.5 Use mainstream technologies as much as possible for economic sustainability and easy replacement and updates
For example, use off-the-shelf hardware (e.g. smartphones, tablets, mini servers) rather than building your own hardware.
Annex: Contributors to this document
Editors and PUX group coordinators:
● Javier Ganzarain, Innjoy Agency for Innovation and Development
● Ana González Segura, everis
● Gottfried Zimmermann, Stuttgart Media University
Content contributors:
● Ana Arroyo, TECSOS
● Gianfranco Borrelli, eResult
● Giorgos Kostopoulos, Gluk Advice
● Thanos Stavropoulos, CERTH-ITI
● Lex van Velsen, Roessingh Research and Development
● Gottfried Zimmermann, Stuttgart Media University
Active members of the PUX working group (Action Group C2.3) at the time of drafting this document:
● Javier Ganzarain, INNJOY
● Brita Gjerstad, IRIS
● Ana Gonzalez, everis
● Giorgos Kostopoulos, Gluk Advice
● Thomas Kubiak, University of Mainz
● Maria José Lumini, ESEP
● Cristina Machado Guimaraes, INESC TEC
● Teresa Martins, ESEP
● Juan Montalvá, UPM
● Hugo Paredes, INESC TEC
● Sebastian Peek, Tilburg University
● Marisa Picornell, Atienza
● Alvaro Sanchez, TECSOS
● Francesca Scocchera, COOSS Marche
● Pietro Siciliano, INNOVAAL
● Thanos Stavropoulos, CERTH-ITI
● Lex van Velsen, RRD
● Gottfried Zimmermann, Stuttgart Media University
License
This document is provided to the public under the CC-BY 4.0 license.
Note: Reference this document as follows:
● EIPonAHA Action Group C2 (2018). Personal User Experience (PUX) Recommendations and Lessons Learned. Guidelines for manufacturers and developers of Active and Healthy Ageing solutions aiming for a Personal User Experience. Feb. 2018. Available online at: http://gpii.eu/pux/guidelines.
Contact / Imprint
Prof. Dr. Gottfried Zimmermann gzimmermann@acm.org
Stuttgart Media University
Nobelstr. 10, 70569 Stuttgart
Germany
