The primary goal of the user experience concerning the end user is to ensure that each one of them is able and willing to utilize the service. The ability and willingness are the design principles.
8.4.1. Design principles in nutshell #
The former of the two design principles – “how to ensure that an end user is able to use the service” – is essentially derived from the initiatives that target the maximal inclusiveness of digital services. The initiatives define the expectations and tools on how people with differing abilities are not excluded from the audience of the service.
The World Wide Web Consortium’s accessibility workgroups and specifications provide the requirements to ensure that the service shall be usable by all end users.
The latter of the two design principles – “how to ensure that an end user is willing to use the service” – is far more amorphous and entirely service-specific. The willingness builds on trust, on whether the end user considers the service to be a tool that is worthwhile and safe to use.
There is no overarching specification that specifies how an organization will be able create trust in the end user’s minds. Fortunately, many of the tools employed in the usability context are well-aligned to also advance the perceived trustworthiness of the service.
The seven principles of universal design [Universal Design] build on the two design principles listed above and further cement the requirement for services that are usable for all users.
The design principles overlap with each other, and there is a multitude of additional user experience attributes to evaluate and take into account when defining, designing, and developing the skills data space or services that utilise it.
8.4.2. Accessibility #
The Web Content Accessibility Guidelines [WCAG] form the core of Web Accessibility Initiative [WAI] of the World Wide Web Consortium (W3C), the main standardization board for Internet activities.
Despite the web-centric name, the organization’s efforts span native digital solutions (such as Apple’s [Apple-accessibility] and Microsoft’s offerings [Microsoft-accessibility] as well as Google’s Android [Android-accessibility]) alongside those utilised in pure web browser context.
While the foundation of the organization is ensuring access to people with disabilities, the majority of the requirements benefit all end users, providing methods and tools to guarantee that the content is visible and interactable on the massive variety of devices and services.
The current version of WCAG is 2.1. New versions will require non-trivial changes to user interfaces, and compliance cannot be taken for granted.
The WCAG consists of twelve guidelines organised under four principles, with each guideline containing individual success criteria. There are three levels of conformance that correspond to an increasing number of success criteria required: A (the service must satisfy this criterion), AA (… should …) and AAA (… may …).
The WCAG is used as a law in the European Union and multiple other countries. In the context of the European Union, EU Directive 2016/2102 requires websites and mobile applications of public sector entities to conform to WCAG 2.1 Level AA. The standard version in the legislation has been updated once and will most likely be updated again as new versions are released.
The four principles, defining that a service must be – perceivable, operable, understandable, and robust – provide the framework in which the elements of the user experience are considered.
Taken as a whole, the principles state that each end user, no matter if they have disabilities or other factors, shall be treated uniformly and equally.
As expected for a globally required and non-trivial compliance, the specifications are complemented with documentation, tools that measure accessibility (e.g., Lighthouse), and frameworks that assist in fulfilling the requirements (e.g. react-aria).
Accessibility is a general concern, but to comply with the requirements, each component of the skills data space that provides a user interface must take the requirements into account and be implemented accordingly.
Perceivable
The perceivability of a service requires that the end user must be able to view or otherwise perceive the content and the user interface to utilise the service.
For example:
- Since textual content can be provided through screen readers or other assistive components, any non-textual content must gracefully degrade to textual presentation.
- Colour can never be utilised as the sole differentiator between alternatives in the user interface – a combination of textual content, symbols, and colour (complemented with a full set of textual descriptions of every visual entity) provides maximal perceivability.
- Concrete skills example: As Matilda is about to share her work history from UXlife to DigiFutUX HR system, in the consent request interface a “decline consent request”-button with a stop icon and red colour needs also textual information for screen readers to understand the context.
Operable
The operability of a service requires that the end user must be able to interact with the service. The end user must be able to navigate the user interface and access the content provided by the service.
For example:
- Even if the service provides buttons and other controls that are conventionally interacted with a mouse, the interface must be fully operable through a keyboard as well.
- The service must provide a well-defined structure for all its content – headings and titles generate order and divide the content into easily understandable fragments of the whole.
- Concrete skills example: Matilda must be able to interact with DigiFutUX HR system consent request using only the keyboard, without using a mouse or a touch screen.
Understandable
The content presented by the service, as well as the interface of the service, must be understandable to the end user. The content must be clear and unambiguous. The language used in the service must be understandable to a layperson. The service as a whole must be structurally simple.
For example:
- The end user must be able to select the language in which the service is presented.
- Every error in end user’s input shall be explained thoroughly enough to enable the user to correct the issue (optimally with a valid example).
- Concrete skills example: As a SkillProfiX user, Matilda must be able to change the language of the user interface, and the language must be marked in the generated document, so a screen reader can read it in the correct language.
Robust
The content and the user interface of the service must be robust enough that it can be interpreted by a wide variety of user agents on a wide variety of devices, including assistive technologies.
For example:
- The service must programmatically identify each user interface element by name and role to present them appropriately to the user agent according to the configuration defined by the end user.
- Never knowingly generate broken or incomplete HTML (if using a web interface for the service).
- Utilise the full set of assistive functionalities provided by the platform vendor (if using a native client for the service).
- Concrete skills example: As Matilda is about to share her work history from UXlife to DigiFutUX HR system, in the consent request interface, a “decline consent”-button must be marked with the role ‘button’ so that assistive devices can understand that it can be pushed.
8.4.3. Trustworthiness #
According to the World Economic Forum’s report [WEF-DT], trust is the key foundation for any initiatives in an increasingly fragmented world. In a nutshell, digital trust is defined as:
- Individuals’ expectation that digital technologies and services – and the organisations providing them – will protect all stakeholders’ interests and uphold societal expectations and values.
Trust is, by definition, subjective; every individual has their own criteria that they apply when considering whether an entity is worthy of their trust.
Trust is, by nature, temporary; it is hard to gain, easy to lose, and much harder to regain.
The digital trust framework described in the WEF report consists of three goals to aim for and eight dimensions against which trustworthiness can be measured, as presented in the attached figure.
The three goals – security and reliability; accountability and oversight; inclusive, responsible, and ethical use – provide the framework in which the elements of the user experience are considered.
Trustworthiness is a general concern, and while there is no compliance framework, great care must be taken to ensure that the skills data space fulfils the three goals set forth in the specification.
Security and reliability
The stated target in the WEF report is: “an organization’s technology and data are well-protected against internal and external attacks, manipulations and interruptions while operating as designed” reaches much deeper than the user interface.
Security is present throughout the whole architecture, the deployed technology stack, and utilized processes. While the end users are not exposed to the details of cybersecurity, the elements of safety and privacy are commonly encountered in the user experience, especially when much of the data in the skills data space is, by definition, personal and private.
The main measurement of the reliability of a service is its availability – whether it can be fully utilised whenever needed by the end users. Availability contains performance as well – the perceived performance of the service received is subjective, and the components and dependencies must be built in ways to minimise potential performance bottlenecks.
Concrete skills examples: All the user interfaces provided by the skills data space are available only by using the HTTPS protocol, whose lock icon is displayed in the browser. Partial data space service degradation (due to e.g., maintenance of a component) is explicitly announced in the user interfaces to avoid surprises.
Frameworks to consider:
- https://owasp.org
- https://www.nist.gov/cyberframework
- https://www.iso.org/standard/27001
- https://en.wikipedia.org/wiki/Privacy_by_design
Accountability and oversight
The stated target in the WEF report places a hefty burden on the organisations providing the service: “Responsibilities are well-defined and clearly assigned to specific stakeholders, teams, or functions along with provisions for addressing where those responsibilities fail to be satisfied. Further, means are in place to ensure that rules, standards, processes, and practices are followed and performed as required”. These responsibilities concern all of the non-end user roles within the data space – and the level of accountability is determined by the weakest link in the chain. If the users are surprised by the activity in the data space, especially regarding personal data, their trust decreases accordingly.
Accountability defines that data in the service must be traceable. The origin of the data and its journey through the data space (how it has been accessed and processes within) must be transparent. Without a reciprocal methodology that provides accountability over the entire lifecycle of data, it is unfair to expect end users to entrust their personal data to the service.
Oversight ensures that incidents (e.g. attacks or infrastructural issues) experienced by the service are all taken care of transparently and properly. The users shall be informed of any incidents concerning them and their data. The effects of the incidents shall be remedied according to established processes and documented.
Concrete skills example: the user is able to view an audit trail of a consent request for the use of personal data. The audit trail reveals their own interactions as well as the identities of the services that have requested to use that data, complemented with the timestamps and statuses of those requests.
Frameworks to consider:
- GDPR
- Other European data strategy elements
- Other non-European legislative requirements
Inclusive, ethical, and responsible use
The first element of the stated target in the WEF report: “organisation designs, builds, and operates its technology and data as a steward for all people, society at large, the natural environment, and other stakeholders, with the overall intent to ensure broad access and use resulting in ethically responsible outcomes” overlaps with the top-level accessibility goal.
In the context of ethics and responsibility, they are implemented in the communications and processes of the service. Whether an end user commits to providing their personal data to the service is a judgement call and cannot be taken for granted. Much of the content relating to the ethical and responsible use is prepared by the privacy and data protection officers of the stakeholders, and the content must be always easily discoverable within the user experience.
Interoperability mandates that the service presents no meaningful differences nor obvious seams between the components. While interoperability is much more of an attribute that evolves throughout the lifecycle of the service (unlike security, which is baked in from the very beginning), it cannot be ignored in service development.
Concrete skills examples: All the user interfaces of the skills data space are accessible, allowing users who interact using a screen reader to independently utilise the content and services provided by the skills data space. The terms of service and privacy policies have been written in layman-friendly terms and are easily available both during onboarding and use of the service.
8.4.4. Additional user experience factors #
In addition to the two design principles described in preceding chapters, there are plenty of factors whose appropriate use enhances the users’ willingness to use the service. Many of these additional factors are not related to the functionality provided by the service, targeting abstract and concrete quality-related factors instead. Typically, in software development terminology, such factors are known as non-functional requirements of the specified system.
Perceived usefulness
The main consideration for any user is the perceived usefulness of the service. Whether the user is able accomplish what they set out to do. And while this builds on every other attribute of the service, it is impossible to state how a given service, especially a distributed one like the skills data space, must be implemented to provide maximal perceived usefulness. Hence, this is not a user experience concern per se, but a requirement delegated to the components that the skills data space is made of.
Generic concrete skills example: Throughout the user’s journey in the EU-DUNE dataspace the value provided by the dataspace is prominently displayed. The content is tailored to the user’s needs, based on data the user has provided and on how the dataspace components have processed that data. This allows the user to find quickly and efficiently what they need, and to easily interact with the dataspace.
Ubiquitous availability
The context in which the service is utilised is a significant factor in end user’s willingness to use the service. For most end users, a mobile device is a far more commonly used than a computer, and thus the service must provide its full set of features irrespective of screen size and other limiting attributes. According to recent statistics, the smartphone penetration rate in Europe exceeds 75% [Statista].
Additionally, as users without computers would be using shared hardware (such as computers in a library or other providers), there would be yet another element of trust – the hardware provider, an entity that is explicitly outside the data space and unable to be certified or otherwise proven trustworthy.
The need to be usable on a wide variety of devices presents a concrete user experience requirement: developing the service using responsive design [Responsive Design] methodology ensures that it is usable on both mobile devices and computers. Some features may work very differently depending on the device – for example, desktop computers may not have cameras, downloading documents may result in a suboptimal experience on a mobile phone.
Generic concrete skills example: As the state of the EU-DUNE dataspace is stored in the backend, each user is able to utilize all their devices (laptop, tablet and phone) to interact with the dataspace.
Implementation technology
A single solution does not fit every end user’s needs. While applications for mobile operating systems have many positive aspects (such as secure storage, location, and notifications), the possession of a smart phone cannot be a requirement for the service.
The plain cost factor rules out many end users. And many accessibility requirements need even more work in native applications than they do in web services, complicating the development work and significantly increasing its cost.
Additionally, the service realized as an application will be bound to the update cycle of the operating system, which complicates maintenance plans significantly. The choice of implementation technology is mainly a business requirement: whether there is enough funding to cover development of both a web service and the corresponding native applications.
Concrete skills example: An immigrant who has no other devices except a four-year-old smartphone can use the EU-DUNE dataspace without the need of accessing a computer.
Continuity
The users’ attention spans may be unexpectedly short; thus, they must not be required to complete actions in a single session. The user must be able to suspend their actions and resume them afterward. As a further complication, the user may resume their work on another device, effectively meaning that the state of the user must be stored outside the user’s device.
Concrete skills example: As noted under ubiquitous service availability, the state of the EU-DUNE dataspace is stored in the backend. Instead of being forced to complete an interaction in one go a user can complete a lengthy form over multiple sessions, the frontend application automatically storing the draft for continuation (possibly on a different device).
Consistency
The effect of the overall appearance of a service is a crucial factor in establishing trust. A consistent and coherent, even boring user interface inspires far more trust than a confusing and chaotic one [AboutFace]. In a public service, a plain look and feel that draws its inspiration from bureaucratic forms and processes feels far more natural to the end user than an alternative that is bursting with colour, and no button looks the same as its neighbour.
Concrete skills example: Despite the distributed nature of the EU-DUNE dataspace, the individual components follow the same unified and plain user experience – black text on white background, with minimal encrustation of interface bling. The calming and boring look and feel reassures the users that they remain within the dataspace.
Context
The more the context of the service and its use of data is explained to the end user, the easier it is for them to understand what is expected of them and how the service behaves [Design Social Interfaces]. Utilising explicit visualisation of context is useful as a tool for service creators, as it provides a design model that is easily replicable within the multiple views of the service.
Generic concrete skills example: The user interface components of the EUDUNE dataspace boldly display a header (stating the purpose) and a progress indicator (stating how far the user has progressed) of a multi-step form, clearly informing the user what they are doing and how much work remains.
Limited commitment during onboarding
During onboarding a new end user, the lower the barrier of entry, the more users exploring the service convert to actual users [User Onboard]. The more a user is able to explore and observe the service without being required to provide personal details or authenticate, the lower the need to escape is. A “too early need to submit credit card details” is a sure way to lose significant fraction of the interested users.
Concrete skills example: Users can explore the offerings of the EU-DUNE dataspace freely using artificial data without authenticating and providing any data of their own.
Language – localization
The language, or languages in which the service is provided, depends on localisation of the service – providing a linguistic look and feel for the targeted locale. Localisation goes beyond mere translation, as elements such as presentation of numbers differ.
Optimally, the service is localised to every end user’s language, but time and resources restrict the number of localisations. Hence, prioritising the localisations is mainly a business concern. The service must be built from the ground up to be internationalised, ready to be localised.
Generic concrete skills example: The user of the EU-DUNE dataspace can easily change the language of the user interface to ensure they understand their own commitments and the offerings of a service. The language setting follows the user from one component to another and is independent of the operating system and browser language selection.
Language – simplicity
As stated in the accessibility requirements, the language of the service must be easily understandable. It must utilise commonly used terms and words and explain words that may be unfamiliar to the end users. It is impossible to estimate in advance which views / concepts are troublesome, and thus it is better to over-explain rather than potentially confuse. User-experience-wise, the service must define a method of displaying additional information about a topic and use it liberally.
At an extreme, a localisation may be complemented with an even further simplified version (easy read, selkokieli, Facile à lire et à comprendre) to be even more inclusive, as the vocabulary and structure of the language are kept to a simple core.
Concrete skills example: As a newly arrived immigrant has limited language skills and there is no localization for his native language, the simple language (short sentences and common words) in the EU-DUNE dataspace makes it easier to use the service and request assistance from peers.
No deceptive patterns
As the evil twin of generating trustworthiness through a good user experience is the emergence of deceptive or dark patterns to deceive, mislead, and manipulate the end users using services that make them do things that they didn’t intend, like buying a product, signing up for something, or providing access to personal data. While there is deep concern about the topic [OECD Dark, Deceptive Design], protecting the end users is a constant struggle against the rapid evolution of these patterns. Multiple initiatives (such as GDPR, FTC-act [DDLaws]) have already proven their worth in providing the backbone for lawsuits costing hundreds of millions of euros to the culprits, but they are obviously reactive by nature. However, the concept of deceptive patterns and their impact is enormous, and further study is required.
Concrete skills example: The EU-DUNE dataspace states explicitly why personal data is needed, how it will be utilized, and provides an audit trail for the user to validate the scope of the use of the data.
Empowerment
The key attributes of the end user experience are explicitly defined in relation to empowerment, as described in the following visual [SkillsData].
Concrete skills example: The user creates a digital CV once and is able to distribute it to multiple parties without expending any extra effort. The user can download the generated CV and see exactly what is provided to the employment brokers.
Cohesiveness
As the data space is a distributed service, a collection of multiple individual components designed and built by different organisations, the users’ exposure to the distribution must be kept as little as possible. The user interfaces themselves must be aligned with one another, obviously allowing branding of the providing organisation to be appropriately visible. The navigation and transitions between the components must be designed to minimize the visual shock and emerging distrust in users. Cohesiveness is a horizontal concern – it affects all aspects of the user experience, including visual assets, user interface controls, and the language used in textual assets.
Concrete skills example: The user logs in once to EU-DUNE dataspace and does not need to authenticate again when moving from one dataspace component to another.
Reliability
The lack of availability of the service, especially unannounced lack of availability, is a massive red flag for users. This is more of a development operations and communications issue than pure user experience. In a distributed system such as skills data space, reliability is affected by many (if not all) components of the system, and thus this factor must be taken into account in defining, developing, and deploying the components.
Concrete skills example: Redundancy of the backend components and ability to do rolling upgrades guarantees that at least one instance is up and running at all times, even if there are major maintenance operations ongoing.
Ease of use and quality of life
The data space user interfaces must be easy and pleasant to use (in addition to the concepts listed under accessibility), and not force the user to repeat interactions or otherwise increase the user’s frustration through perceived digital friction. In this context, self-service is a key enabler – the user interfaces shall contain as much help for the users as is feasible to let them evaluate, mitigate, and remediate any issues they encounter. Additionally, if a user encounters an issue they are not able to resolve on their own, there shall be easily locatable information customer service contact instructions (the implementation, resourcing, and tracking of the customer service is out of scope).
Ease of use is an important concern in a distributed system and places a hefty burden on the identity management component and interoperability between the components. As a concrete requirement, the user should not be required to authenticate when journeying between components – single sign-on functionality should be provided by the data space to minimize unnecessary friction.
Concrete skills example: The EU-DUNE dataspace user interfaces all provide assistance in omnipresent and consistent fashion. The user can find more information on individual terms and processes by clicking a help icon prominently available in all views of all the components.
Quick evolution
As user experience is thoroughly subjective, a need to react to user feedback may manifest suddenly in order to retain users. Thus, in the context of the skills data space, the development cycle of the underlying components (services and databases) may have to differ from that of the user interface components. This requires loose coupling between the two.
Concrete skills example: Following user feedback of a hard-to-follow CV exporting interaction, the developer of the component redesigns and deploys a improved version without updates to dataspace components interacting with it. This is a counterpoint to the problems of a distributed system, where a monolithic entity would be far slower to be upgraded.
As the introduction stated, creating a good user experience is not an easy task.
A good user experience is built on the users’ ability to use the service (accessibility) and their willingness to use it (trust). And obviously, the pathway to the user experience is marketing and advertising of the solution.
The accessibility of the service is founded on standards as well as existing best practices and tools. Relying on the previous accomplishments of others is a viable strategy to create a service that welcomes all users, irrespective of abilities.
The trustworthiness of the service is far more of an open game. There are no tricks with which to ensure that end users will place their trust in the service. It is complicated by the fickleness of the users, as their trust in the service is subjective, and trust is neither guaranteed nor permanent.
While skills data space is the first data space project that has defined the playing field for user experience, it is not the only one. A cohesive and symmetric user experience across all the data spaces would be advantageous to all stakeholders up to the level of the European Commission. Hence, the sooner DSSC gets involved in the context of user experience, the better.
User experience is the first (and in many cases the only) interface the users of the data space encounter. Hence, the need to provide a smooth, cohesive, and uniform interface atop a distributed system cannot be stressed strongly enough.
