D103.2 Final Iterative Design Framework and Solid Final Wireframes … · 2018-02-27 ·...

Ecosystem infrastructure for smart and personalised inclusion and PROSPERITY for ALL stakeholders

D103.2 Final Iterative Design Framework and Solid Final Wireframes

Project Acronym Prosperity4All Grant Agreement number FP7-610510

Deliverable number D103.2

Work package number WP103 Work package title Ecosystem Requirements

Authors Sepideh Shahi/ Jess Mitchell/ Dana Ayotte/ Michelle D’Souza

Status Final Dissemination Level Public/Consortium

Delivery Date 07/02/2018 Number of Pages 39

Ecosystem infrastructure for smart and personalised inclusion and PROSPERITY for ALL stakeholders www.prosperity4all.eu

Keyword List

Design Tools, Design Specifications, Survey, Feedback, Consumer Privacy Protection

Version History

Revision Date Author Organisation Description

1 27/10/2017 Sepideh Shahi IDRC Initial Draft

2 15/11/2017 Jess Mitchell IDRC Edit

3 16/11/2017 Sepideh Shahi IDRC Edit

4 27/11/2017 Doris Janssen Fraunhofer Internal Review, Results:

• Please add some more statements about the consequences of the review results on the current implementation of the Developer Space and the other results of P4A

• Add visible links (footnote) to all external content

• Link the results within the DeveloperSpace and add these links to these report

• Further minor suggestions, see inline comments

5 28/11/2017 Sepideh Shahi IDRC Edits

• Provided more clarifications regarding the title of this report in the summary

• Visible links added throughout the document

• A link to SP1 resources added to DeveloperSpace. Those links added to this report

• Responded to inline comments from the internal reviewer

http://www.prosperity4all.eu/


Revision Date Author Organisation Description

6 04/12/2017 Jess Mitchell IDRC Edits

7 15/12/2017 Gianna Tsakou SILO Internal Review


9 31/01/2018 Matthias Peissner Fraunhofer Internal Review


11 07/02/2018 Gregg Vanderheiden RTF Internal Review

Table of Contents

Executive Summary ............................................................................................................. 5

1 Contribution to the global architecture .................................................................... 7

1.1 Specific DoW and WP Objectives ................................................................................ 7

2 An overview of SP1 work for WP103 ........................................................................ 9

2.1 P4A Project Vision ........................................................................................................ 9

2.2 The Infrastructure and The Context ............................................................................ 9

3 WP103 - Updates .................................................................................................... 11

3.1 Use Model Updates (user personae and use cases) .................................................. 11

3.2 Design Specifications Updates (global and specific).................................................. 13

3.3 Inclusive Design Guide Updates (repository, content, dissemination) ..................... 13

4 WP103 – New Additions: An analysis of the protection for consumer privacy ........ 16

4.1 Methodologies ........................................................................................................... 17

4.2 Risks to Users ............................................................................................................. 18

4.2.1 General Privacy Risk ........................................................................................... 18

4.2.2 Lack of Awareness of Privacy Risk ...................................................................... 18

4.2.3 Services not Supporting Personal Privacy Policy ................................................ 20

4.3 Risks to Companies .................................................................................................... 21

4.4 Risks to the Privacy Preferences Initiative ................................................................. 21



4.4.1 Design for Privacy ............................................................................................... 23

4.5 Security Assessment .................................................................................................. 24

4.5.1 Design for Security ............................................................................................. 25

5 Review of WP103 Impact Across the Project ........................................................... 26

5.1 Methodologies ........................................................................................................... 26

5.1.1 Research, Design and Knowledge Building ........................................................ 27

5.1.2 Development and Implementation .................................................................... 27

5.1.3 Evaluation ........................................................................................................... 28

6 Moving Beyond P4A Project ................................................................................... 30

7 Annex ..................................................................................................................... 33

7.1 WP103 Survey – Review of Project Evolution from Planning to Implementation .... 33

List of Tables

Table 1: Key terms in this document ....................................................................................... 34

Table 2: Abbreviations used in this document ........................................................................ 38

List of Figures

Figure 1: Overall Picture of Prosperity4all ................................................................................. 7

Figure 2: P4A Big Picture Diagram: Infrastructure enabling an ecosystem (and its context) .. 10

Figure 3: SP4 and SP1 deliverables ........................................................................................... 32



5

Executive Summary

This document (D103.2) is the final deliverable in WP103 Ecosystem Requirements. The title “Final Iterative Design Framework and Solid Final Wireframes” includes two main components:

• Final Iterative Design Framework – refers to the creation of the Design Kit as delivered in previous SP1 work: namely, D103.1 and subsequent iterations. The Design Kit functioned as a design framework, which created a living resource whose utility in the context of Prosperity4All was merely a beginning to its many uses and applications. The Kit continues to thrive and to be used in diverse contexts as described in this report. The Design Kit1 includes three components, which can be used individually, however, together they create a comprehensive framework for designing an inclusive solution:

1. The Use model2: helped to ensure users at the margin were considered, and diverse real work use scenarios integrated in the design and development of DeveloperSpace infrastructure.

2. Design Specifications3: provided overarching as well as detailed design specifications to build inclusion and accessibility into the infrastructure right from the start.

3. Inclusive Design Guide4: demystified the concept of inclusion, and provided practical tools and activities to build inclusive products and systems within and outside of the P4A project.

• Solid Final Wireframes – The original reference to ‘wireframes’ should be contextualized in a project whose goals were unprecedented and ambitious (as described in detail in D404.1) and whose teams had to work out how to situate the work to be done collaboratively. It was neither desirable nor representative of the collaborative design process outlined in D103.1 to have one team creating visual designs that others would simply adopt and follow. Instead, in the context of SP1 work, wireframes here refer to research, design and implementation guidelines provided to the project partners to ensure inclusion and accessibility were integrated in their work from the ground up. This included SP1 providing guidance and support for the DeveloperSpace design team when needed. For instance, one of the lead

1 https://wiki.gpii.net/w/Design_Kit 2 https://wiki.gpii.net/w/Use_model 3 https://wiki.gpii.net/w/Design_Specifications 4 https://wiki.gpii.net/w/Inclusive_Design_Guidelines



6

designers of the DeveloperSpace infrastructure, joined the SP1 team for an intensive 3-week collaboration during the initial phases of designing the DeveloperSpace wireframes. The SP1 team provided feedback through daily one on one meetings, group design critiques, and community workshops to discuss the details and design decisions for the site, and to ensure the outcomes were inclusive and accessible. The current design of the DeveloperSpace and UnifiedListing has grown from iterating on those design discussions and feedback cycles. The final design has, therefore, been arrived at through deep community collaboration and continued iteration and input.

As the final deliverable, this report describes how SP1 tools evolved through the course of the P4A project, teases out the impact the SP1 tools and models had on colleagues’ design and development practice, outlines how those tools will continue to grow and be used, and situates the tools within the larger context of work they have influenced.

This document focuses on the following areas, that are briefly described below:

• WP103 - Updates: In this section (3), we focus on the final updates on the Use Model, Design Specifications, and Inclusive Design Guide.

• WP103 – New Additions: in this section (4), we discuss addition of a new piece to the SP1 framework related to the protection for consumer privacy and its associated risks. With this new content, SP1 team aims to inform users of the best practices for creation and application of individualized privacy policies that anyone can understand and express.

• Review of WP103 impact across the project: In this section, we discuss the results from the review conducted by SP1 team. In this review, project partners reflected on the impact of SP1 tools on their work.

• WP103 future uses and impact – moving beyond P4A: to conclude this document, we will report on various uses outside of the Prosperity4All project where the SP1 tools have been used, including work that has been influenced by the thinking surfaced in the context of SP1 work. In these sections, we will also outline how the tools produced in the context of SP1 will continue to grow and be used and refined as the funded project timeline wraps up – how they have become part of a larger, global movement.



7

1 Contribution to the global architecture

The contribution of this deliverable is indicated within the larger project layout to show its overarching impact in red on the right of the diagram. This deliverable provides a review of how various SP1 tools and models have evolved and been refined through the course of this project, in addition to discussing how they impacted the other SP teams work during their development and implementation and beyond P4A project completion. The findings from this report will contribute to the D404.3 deliverable as a set of recommendations for continuous monitoring and evaluation of the DeveloperSpace infrastructure. From a larger perspective, the tools created in SP1 of P4A that encourage inclusive practices from the beginning of design and development processes, could benefit any other project (in the EU and beyond).

Figure 1: Overall Picture of Prosperity4all

1.1 Specific DoW and WP Objectives

Which task / WP are source for the results presented in this deliverable?



8

• WP103

o synthesize the results of WP101, WP102, and WP103 to derive design specifications for the project delineating the necessary services, infrastructure and supports required to enable the growth of the inclusive ecosystem.

o act as a bridge between business/economics experts and participatory designers working on WP101, 102, and 103, and designers, developers and implementers working on SP2/SP3.

o translation, and cross-disciplinary communication of design criteria derived from economic modelling and user-centric design

• T103.2 o Representative stakeholders and partners within the project have

participated in this review. o Including specifications and guidelines regarding the protection of consumer

privacy

How will results contribute to the overall architecture of the project?

This report provides a review of how SP1 work has influenced the various project components through the course of this project, and how SP1 tools can continue to other projects in the future.

The findings in this report will also contributed to D404.3 report to support ongoing monitoring and evaluation of the DeveloperSpace infrastructure. Overall, the results from this report will contribute to creation of good practice guidelines that can be used for any other EU project to ensure inclusion is considered right from the start.

Which specific task / WP used the results for their activities? Which results? How?

• WP404 o The results from SP1 current and future impact contributed to the D404.3

report to support ongoing monitoring and evaluation of the DeveloperSpace infrastructure.

• WP405: Demonstration o T405.1: Results from this report and previous SP1 reports (D103.1, D103.1-2)

contributed to the planning and conducting activities during the demonstration workshops and open days

o T405.3: SP1 tools and models were used during the WP405 demonstration events and open days



9

2 An overview of SP1 work for WP103

2.1 P4A Project Vision

“Prosperity4all aims at a paradigm shift in eInclusion. It focuses on developing the infrastructure to allow an inclusive ecosystem to grow; one that is based on self-rewarding collaboration, that can reduce redundant development, lower costs, increase market reach and penetration internationally, and create the robust cross-platform spectrum of mainstream and assistive technology based access solutions required.”5 This effort will require a paradigm shift because the ‘typical’ approaches to solving these complex problems have failed and left many “at risk of exclusion from education, employment, commerce, health information, and almost every other aspect of daily living and civic participation.”6

SP1 has been focused on providing models, tools, and research to support the teams building the vision of Prosperity4All. That vision will result in an inclusive ecosystem enabled by the infrastructure to deliver the optimal matching supply or service for a user’s functional needs in a specific context for a given goal.

2.2 The Infrastructure and The Context

The diagram below shows the tools that SP1 has delivered for the various infrastructure teams to use as they built the component parts of the DeveloperSpace infrastructure. These tools have helped ensure the project achieves its overall vision as stated above. The Design Kit and Economic Model contain the initial information the infrastructure teams needed to create an infrastructure that can serve as the backbone to an inclusive ecosystem. The Design Kit includes a use model, global and component specifications, and an inclusive design guide. Although each of these components could be used individually, together they provided the project partners with user-centered and inclusive design directions and guidelines that assisted them in building more inclusive and accessible products. The Economic Model contains a business model and payment system analysis, which was presented in 102.2 and its iterations. The infrastructure teams used these models and helped to refine them as they developed and implemented their project components.

5 http://gpii.net/prosperity4all 6 ibid.



10

The models have been created from within the current context in Europe: namely the combination of the 8 areas earmarked in the EU’s Disability Strategy Goals7 and the ever-changing ‘verticals of complexity’ that make up Europe, markets, and technology.

While the models have been built from within this complex context, it was still important that as those teams were building the component parts, they understood the vision and the context within which P4A will enable this inclusive ecosystem. For a larger version of this diagram please visit this link8: large big picture diagram image

Figure 2: P4A Big Picture Diagram: Infrastructure enabling an ecosystem (and its context)

7 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0636:FIN:en:PDF 8 https://wiki.gpii.net/w/File:Big_picture_diagram.png


https://wiki.gpii.net/w/File:Big_picture_diagram.png


11

3 WP103 - Updates

As presented in previous SP1 work for WP103 (D103.19 and subsequent iterations) the Design Kit intended to guide SP2 and SP3 teams in design and development of their components to ensure the required interactions are supported by the DeveloperSpace infrastructure, and the desired values are offered to each of the stakeholders in different scenarios and contexts. The Design Kit is composed of three main components: use model (user personae, and provisional use cases), design specifications (global and specific), and the inclusive design guide. Each component of the Design Kit has been revised and updated as the project progressed and different components of the DeveloperSpace infrastructure were implemented. The most recent version of the Design Kit is available on the GPII wiki10. The updates to these tools are briefly explained in the following sections.

3.1 Use Model Updates (user personae and use cases)

o User Personae: During the implementation of the DeveloperSpace infrastructure, the SP2 team informed the SP1 team that they could benefit from additional user personae and use cases for testing and demonstration purposes. Through a collaborative effort with the larger P4A community, several new user personae were created and added to the use model. These new personae include a AT developer, mainstream developer, PhD student, end user, and a high school student. More details regarding these personae can be found in the GPII wiki (please select this link11).

o Provisional Use Cases: Implementation of DeveloperSpace and Unified Listing led to new possibilities for user interaction with the infrastructure. To address these new interactions, SP1 team partnered with SP2 to revise previously developed use cases and develop a new series of more concrete and detailed provisional use cases: Learning how to use DeveloperSpace, Using DeveloperSpace (by mainstream developer / graduate student / End users), Looking for research project/thesis topic, Using Unified Listing. More details regarding the updated and new use cases is available on the GPII wiki (please select this link12).

9 http://www.prosperity4all.eu/wp-content/uploads/P4A-D103.1-Foundational-Design-for-Prosperity4All.pdf 10 https://wiki.gpii.net/w/Inclusive_Models 11 https://wiki.gpii.net/w/Use_model#Proposed_New_Use_cases_to_incorporate_with_above: 12 https://wiki.gpii.net/w/Use_model#Baseline_Use_Cases:_Second_Iteration_.28added_March_2017.29


https://wiki.gpii.net/w/Inclusive_Models

https://wiki.gpii.net/w/Use_model#Proposed_New_Use_cases_to_incorporate_with_above:

https://wiki.gpii.net/w/Use_model#Baseline_Use_Cases:_Second_Iteration_.28added_March_2017.29


12

o End to End use case: This approach is a new addition to the use model and tries to build a comprehensive use case, simulating the cross connections among different user personae in an inclusive ecosystem. In this use case, a range of users and stakeholders are engaged with various features and services offered by DeveloperSpace and each of them is trying to achieve a specific goal (for more detail please select this link13).

The use model is a repository of live content on an open platform (GPII Wiki) where users can add to it, modify its content or use it for inspiration to create their own versions. Although the use model is built for this project, it could easily be reused or repurposed for any other project related to accessibility and inclusion.

To further disseminate this knowledge, and introduce the use model as an inclusive method for designing digital services, SP1 partnered with SP5 and wrote a short paper discussing how this method has been applied throughout the P4A project. To access this article please visit this link14.

The creation, collaborative iterating of, and now project archive of the personae used within the context of this project sketches a narrative about just how to use these tools. The SP1 team worked to ensure that team members understood the role of personae in design and development. Personas are models representing the potential stakeholders who may use P4A products/services. Although they are fictional people, their characteristics, needs, goals and motivations are rooted in the insights and feedback collected from various forms of research. They begin as early provisional sketches of users and then evolve through iterations as more user information becomes clear through research and feedback.

The P4A user personas are not meant to be exhaustive of any group of people and only represent the minimum number required to illustrate key goals and behaviour patterns. Personas are meant as behavioural models; they do not represent full demographics of complex and unique people.

As the project progressed and architectural decisions were made that altered the overall vision of the DeveloperSpace and the team had a better idea of just how it would manifest, the use model was evolved to reflect the interactions and structure intended in the resource.

13 https://wiki.gpii.net/w/Use_model#End-to-end_Use_Case_April_2017 14 https://www.ncbi.nlm.nih.gov/pubmed/28873930


https://www.ncbi.nlm.nih.gov/pubmed/28873930


13

3.2 Design Specifications Updates (global and specific)

o Global GPII design specifications: propose an overarching set of best practices and accessibility guidelines for the DeveloperSpace infrastructure. These principles are global and applicable to any future project in the same field. Since the project began, WCAG 2.1 has been released at this link15. P4A team members have been encouraged to keep up to date on developments in accessibility standards. WCAG 2.1 includes much needed additions to cognitive accessibility. For a good overview of updates to WCAG, visit this link16.

o Design specifications for DeveloperSpace and its service infrastructures: These specifications are interdependent on development of DeveloperSpace and its service infrastructures and they have been revised and updated as the project has progressed. The final version of these specifications is based on the current implementation of DeveloperSpace infrastructure (month 43) and the possibilities it provides for interaction. To access the most recent version of these specifications please visit this link17.

3.3 Inclusive Design Guide Updates (repository, content, dissemination)

o Repository: the inclusive design guide is a work in progress, and meant to be dynamic and evolving based on where, how and for what purpose it is used. To make this guide quickly available to the P4A project partners, the first version of the guide was built using a proprietary program and only editable by SP1 designers and researchers. However, the aim was to go beyond the scope of the P4A project and make this work available to everyone. After initially making the guide available to project partners, the SP1 team completed a transfer of the guides to GitHub as an open platform where anyone could edit content or contribute to creation of new guide entries. To access the guide repository please select this link18.

o Content: Over the course of this project, the SP1 team has used the inclusive design guide in various contexts outside of P4A. As mentioned above, the

15 https://www.w3.org/TR/WCAG21/ 16 http://davidmacd.com/blog/wcag-2.1-quick-guide.html 17 https://wiki.gpii.net/w/Design_Specifications 18 https://github.com/inclusive-design/guide.inclusivedesign.ca


https://www.w3.org/TR/WCAG21/

http://davidmacd.com/blog/wcag-2.1-quick-guide.html

https://wiki.gpii.net/w/Design_Specifications

https://github.com/inclusive-design/guide.inclusivedesign.ca


14

inclusive design guide is constantly evolving. Using the guide in different contexts has informed SP1 of opportunities for creating new guide entries. The following entries have been added to the guide. There are also several new entries that are under development and will be added to the guide in the near future: Design for Privacy (Practices)19 Cause and Effect20 Toddler-Grandparent Conversation (Activities)21 Co-design a hack-a-thon (Practices) - Under development Co-design warmups (Activities) – Under development Enable participation (Practices) – Under development Strengths/Interests based self-assessment (Tools) – Under

development Built in inclusion (Tools) – Under development

o Dissemination: Initially the inclusive design guide was prepared as a set of static PDF files that could be accessed on the GPII wiki or printed in card formats. In later iterations, the guides were made available digitally to ensure they are keyboard and screen reader accessible as well. Digital Guides: The most up-to-date version of the guides are available

on the Inclusive Design Guide website (Please see this link22) Print functionality for the guide: The Inclusive Design Guide's print

functionality was created from the online web version using HTML and CSS to provide the print formatting. The print version outputs duplexed on standard Letter size media (8.5" x 11"), where each page can then be cut and cropped into roughly 5.5" x 8.5" cards. In order for the duplex printing to work properly, additional semantics needed to be added to the Guide's markup to indicate the end of the front and reverse side of cards. Functionality was also added to properly order the front and reverse sides so that cards appeared properly in duplex order. There are still challenges to overcome such as formatting of lists

19 https://guide.inclusivedesign.ca/practices/DesignForPrivacy.html 20 https://guide.inclusivedesign.ca/activities/CauseAndEffect.html 21 https://guide.inclusivedesign.ca/activities/ToddlerGrandparentConversation.html 22 https://guide.inclusivedesign.ca/


https://guide.inclusivedesign.ca/practices/DesignForPrivacy.html


https://guide.inclusivedesign.ca/activities/CauseAndEffect.html

https://guide.inclusivedesign.ca/activities/CauseAndEffect.html

https://guide.inclusivedesign.ca/activities/ToddlerGrandparentConversation.html

https://guide.inclusivedesign.ca/activities/ToddlerGrandparentConversation.html

https://guide.inclusivedesign.ca/


15

and graphics, as well as better management of cards that overflow the boundaries of a print side.

Since inception, the inclusive design guide has been used in many different settings and adopted by various organizations. This link23 shows an interesting example of how a group of occupational therapists have adopted the guides and created different scenarios for using them in clinical settings. Beyond this use, the guide has been used in board meetings, in open education events, in classroom settings, in numerous workshops, presented to government officials around the world, distributed in community meetings, referenced in hackathons, and used during design and development sprints. The Inclusive Design Guide directly influenced the Microsoft Inclusive Toolkit at this link24. This Toolkit includes a manual that is a comprehensive introduction to the world of inclusive design. The main concepts discussed in this manual, such as ‘disability as a mismatch’, ‘learning from diversity’, and ‘designing for one’ are directly influenced by the insights provided in the inclusive design guides. The other part of the Microsoft Inclusive Toolkit are the activity cards that are designed to be integrated into design and development processes. These activities are also significantly influenced by practices, tools and activities provided in the inclusive design guides.

23 https://docs.google.com/document/d/1x9JaN3TKapp84dcsZ8xt58ZlOsrHuhH_43dxDOoY9VI/edit 24 https://www.microsoft.com/en-us/design/inclusive


https://docs.google.com/document/d/1x9JaN3TKapp84dcsZ8xt58ZlOsrHuhH_43dxDOoY9VI/edit?usp=sharing

https://www.microsoft.com/en-us/design/inclusive


16

4 WP103 – New Additions: An analysis of the protection for consumer privacy

This is a new piece of work completed by the SP1 team and added to our framework. In this section, we have outlined a number of risks inherent in designing and implementing systems that support the personal expression of privacy policies by individuals, and the challenges to service providers in matching those preferences. Several strategies for mitigating these risks, such as providing user interfaces and channels for negotiating exceptions to personal privacy policies have been discussed. Security has been identified as a crucial foundational requirement for protecting both personal information and the transaction of personal preferences policies, and we have outlined a set of design, software architecture, and technical strategies that may help to provide a firm basis for the security of such personalized systems.

This work is particularly relevant to P4A as the new models for marketplaces will have to address real concerns about consumer privacy and protection. While the new models expose alternative and disruptive ways to enter the marketplace, they can also create more vulnerabilities to an already vulnerable population of consumers. This initial work in privacy for consumers is meant to address some of the main concerns in this area. However, for large and international projects such as P4A and DeveloperSpace infrastructure, ongoing research is necessary to maintain and update a workable ecosystem of policy guidelines, reusable design patterns, user interface components, and infrastructural services that will support this vision. This is why the guidelines and tools mentioned here can only be considered as a good start for addressing the issue and not as consolidated security and privacy specifications that will not change over time. Continuous vigilance to unexpected risks is required to maintain the viability of the privacy preference compliance enabled through a personal privacy preference tool.

In this context, it is very important to discuss how consumer privacy will be protected by the DeveloperSpace infrastructure as it has begun to grow and attract more users. Protection of user privacy has special significance for this project as many users of DeveloperSpace and its service infrastructures are individuals at the margin who are most vulnerable to the misuse of their private information. As it is also mentioned in section Error! Reference source not found., SP4 evaluation results have revealed that one of the major concerns for service providers and end-users is the protection of their personal and financial information.

In the current technical climate, systems that collect and use personal information generally take an “all-or-nothing” approach to personal information. Individuals have the choice to either accept a service provider’s privacy policy in its entirety, or not use their service at all.



17

This encourages the overly broad collection of personal information by service providers, and limits many users’ access to convenient or necessary services. Moreover, most privacy agreements are riddled with technical complexity, lack of details about how personal information will actually be stored and used, and legalese—all of which makes them difficult to understand, consent to, or contest individually. Where users accept such broad and non-personalized privacy policies, they are put at risk of having their personal information used in ways they are not aware of.

The goal of adding this content to other resources provided by SP1 is to help create a resource about privacy and its associated risks and inform users of best practice guidelines for the creation and application of individualized privacy policies that anyone can understand and express. Similar to other tools and methods provided by SP1, a link to these guidelines and strategies have been made available on the DeveloperSpace25 to ensure anyone can access them. A concise and simplified version of privacy guidelines is explained in section 4.4.1 also available in the inclusive design guide (Please see this link26).

4.1 Methodologies

Security is of utmost importance when dealing with privacy. Without comprehensive security, there is no possibility of maintaining personal privacy. In order to evaluate the risks associated with protection of consumer privacy, three categories were investigated, individuated by who or what is at risk. These are:

1. Risks to the user,

2. Risks to the company or service collecting and using private data,

3. Risks to the privacy preference initiative

A co-design approach was applied to discuss and analyse these three risk areas in relation to the protection of consumer privacy, followed by an assessment of the security issues associated with personal privacy preferences, and a discussion of the techniques that will help mitigate these risks.

During the co-design process, technical risk and security assessments were conducted. These assessments included engaging technical security experts in analysing the designed tools for possible security issues. Strategies to mitigate risk were formed and explored. The results

25 https://ds.gpii.net/learn/bibliography/floe-privacy-needs-and-preferences 26 https://guide.inclusivedesign.ca/practices/DesignForPrivacy.html




18

and strategies from the risk and security assessments informed the co-design process to ensure that the developed guides are able to meet the highest standards for security.

4.2 Risks to Users

4.2.1 General Privacy Risk

Use of the internet often involves providing personal information to an organization or company in order to use a service they provide. An example is submitting one’s credit card information to make an online purchase in the OpenMarketplace. This is practical and convenient, but there is an associated risk that the credit card specifics will be intercepted and used fraudulently by some other individual.

Other examples of risks due to exposure of personal information include:

• Selling personal information to third parties for aggregate data collection

• Access to resources through stolen user credentials: o Bank accounts o Health records o Identity theft, e.g., impersonating users in sent emails or instant messages

• Bullying and stalking

• Use of a person’s location information to facilitate physical theft • Sharing of data that was assumed to be private with a wider audience than was

considered when the data was created (private chats, images, movies)

The convenience of using online web services must be balanced by mitigating the risks to privacy. Persons with disabilities, persons who are aging and others who face discrimination, stereotyping, marginalization or exclusion have the most to gain from smart services that respond to personal data but are also the most vulnerable to the misuse of private information (e.g. denial of insurance, jobs or services, fraud, etc.).

4.2.2 Lack of Awareness of Privacy Risk

When personal privacy risks are not well understood, users are less likely to seek out and take advantage of optional privacy protections. As a result, some or all of their personal information may be exposed to unwanted parties. Further, users may avoid the use of certain services altogether out of fear of exposing their personal information (e.g. online banking), or may agree to privacy policies without fully understanding their implications.



19

The goal of privacy preferences design is to demystify privacy and help users feel comfortable and secure in making informed choices about their personal privacy. This is a core concept of Privacy by Design27 - that privacy should be user-centric and within users’ control. The Privacy Storybuilding tool28 designed and developed by SP1 aims to mitigate these user risks through a playful and engaging approach.

Figure 3: Privacy Story Builder Tool – First three screens

The storybuilding tool employs elements of online gaming through the use of hypothetical situations, story development and a non-threatening, informal tone. It guides the user through a series of dialogues and engages the user to create a story about their privacy needs. It invites users to actively understand what privacy is, and encourages them to author their own individual privacy policy. It includes features such as an introductory video, tutorials and/or “learn more” options that users can consult at their own pace. This background material helps clarify different privacy issues to users.

The design of the tool was the outcome of brainstorming and co-design sessions with stakeholders. Further usability testing is required to study whether or not the tool achieves the goal of mitigating user risk, and is proposed in the future work plan beyond P4A project.

27 https://en.wikipedia.org/wiki/Privacy_by_design 28 https://xd.adobe.com/view/073c6a81-f6c9-4999-b838-e11295cd6662/


https://en.wikipedia.org/wiki/Privacy_by_design

https://xd.adobe.com/view/073c6a81-f6c9-4999-b838-e11295cd6662/


20

4.2.3 Services not Supporting Personal Privacy Policy

Another risk to the user stems from limitations that a company or service may have in terms of fully implementing a user’s personal privacy preferences. In this case, even though the user has declared preferences for how their privacy is to be respected, the service may only be capable or willing to match a subset of them. This risk can be mitigated by having the service inform the user of which parts of their personal privacy preferences are being followed and which are not. The user then has an opportunity to decide if they wish to proceed or, instead, reject use of that service. In order to audit our proof of concept, we looked into the PIPEDA policies, which describes an organization’s legal responsibility with respect to collecting, using, and disclosing personal information is realized through two kinds of policies -- a policy for collecting, using, and disclosing personal information, and a policy for inquiries and complaints.

Organizations are obliged to publish a policy stating the purpose(s) for which they are collecting personal information, how long they will retain the information, how they intend to use it, and if and how they will disclose it to third parties. The reason for publishing this statement is so that users can determine and evaluate the organization's privacy policy before providing any personal information. If the user is not comfortable with the organization’s privacy policy, they can decide not to provide any personal information. However, the result may be that the individual cannot use services provided by the organization.

Secondly, organizations are required to publish a policy regarding how users can make inquiries about the personal information that the organization has collected. Inquiries include:

A request for a copy of all of the user’s personal information,

Checking personal information for accuracy, and providing corrections to the organization,

Information about how the personal information has been used internally, and what has been disclosed to third parties and why, and

Registering a complaint with the organization about the organization’s failure to follow their own privacy policies.

Moving forward, we plan to look into the EU GDPR along with PIPEDA to ensure our proof of concepts are audited in different contexts and under different international policies. Since PIPEDA and GDPR are laws, failure on the part of an organization to openly publish policies or to follow the policies they have published can lead to audits by the privacy commissioners, fines, or lawsuits.



21

4.3 Risks to Companies

The risk to companies relates to legal implications. Typically, companies have a single privacy policy that covers all users. Using the Privacy Preferences Design framework implies multiple policies, one per user. That represents a greater degree of legal risk – handling multiple privacy policies – than a single policy does. On the other hand, users that have assurance that their privacy preferences will be respected has the outcome that the company and its services are attractive to more users.

There is also a risk of mismatches—situations where an individual’s personal privacy preferences can’t be fully accommodated by the service provider’s in a way that is both usable and sustainable from a business perspective. What happens when a service provider can't fully meet the needs and preferences stated by the user? What if a service provider’s business model is predicated on using personal information in a way that may not fully meet an individual’s abstract privacy preferences, but which nonetheless the individual may find the service valuable enough to accept? Or if the user experience of a service may suffer significantly if a user’s privacy policy is implemented exactly as specified?

The implementation of privacy preference setting tools must include a variety of ways to support users and service providers in negotiating specific compromises in cases where service functionality may be partially or entirely limited by the user’s privacy preferences. For example, the system could provide a dialog (with the necessary information provided by the service) that informs the user that some essential features of the service will not be available if their privacy preferences are to be met. Ideally, the service would provide options to the user, such as alternate features that can be used, or the option to apply a temporary exception to their preferences, allowing the service to access the necessary information only while the service is in use (or while certain features of the service are in use).

Part of this negotiation would include the provision of ephemeral or time-limited exceptions to a privacy agreement. This helps to ensure that access to additional personal information will no longer be available and/or will be erased after a period of time or upon quitting the service. For example, if a user has declared a general preference for blocking location tracking, and then attempts to use a mapping service that requires location tracking, the user could be given the option to only allow this time, or to only allow when the service is in use.

4.4 Risks to the Privacy Preferences Initiative

Three risks associated with privacy preferences are:



22

1. Companies/services not making use of privacy preferences, 2. Changes to privacy laws or specs and potential conflicts with the project, 3. Project failure. Implication is no privacy preferences for individuals and status quo

for users’ privacy.

One risk is that there is no uptake of the privacy policies by companies or services. When a company or organization does not implement Privacy Preferences Design, a user’s privacy preferences are not respected even though the user has declared their preferences. As a result, users might decide to not use the company’s service, or limit their use of the service to situations where their preferences are respected.

This risk is mitigated by working with companies and advocating the benefits of using the Privacy Preferences Design strategy. Benefits include improvement of the company’s brand and attractiveness to customers, and compliance with privacy laws. The cost of implementing privacy preferences is relatively low compared to the cost of failing to protect users’ privacy. Users are more likely to become customers if assured that their privacy is protected. Protection improves users’ confidence in a company’s services. In addition, companies are subject to privacy laws, such as PIPEDA29 and the European Union’s GDPR30, in order to conduct business. These laws reflect the fact that privacy is a current and popular concern of users and governments. Implementing Privacy Preferences Design is one way for a company or organization to meet these legal requirements.

Secondly, the global regulatory frameworks for privacy are complex and in a state of flux. The main differences between European and North American privacy laws are that European laws are central and stronger, imposing regulations on companies. In contrast, US laws are a mixture of federal and state legislation and prefer that companies self-regulate. Canadian legislation is somewhere in the middle, inclined towards the strength of European law, while permitting self-regulation. Privacy preferences design represents a way to cross-cut these differences. Putting privacy into the hands of users to provide companies with users' own individual privacy policies entails that privacy laws will be met regardless of geographic region, provided companies respect users' privacy preferences. The only requirement is that the privacy preferences are capable of capturing and reflecting the strongest legislation, those of the European Union.

Privacy preferences design is a complex space, and as a result there are several ways in which a project could fail. Although several designs and prototypes have been produced for privacy tools, the actual tools have yet to be built. The tools must be developed in such a

29 http://laws-lois.justice.gc.ca/eng/acts/P-8.6/page-1.html#docCont 30 https://en.wikipedia.org/wiki/General_Data_Protection_Regulation


http://laws-lois.justice.gc.ca/eng/acts/P-8.6/page-1.html#docCont

https://en.wikipedia.org/wiki/General_Data_Protection_Regulation


23

way that the user experience is simple and presents an improvement for service providers to the current approach; otherwise the barriers to respecting and responding to the privacy preferences of consumers could be too great for companies to overcome. Another vulnerable aspect designing for protection of consumer’s privacy is the bidirectional relationship between individuals and service providers. It is likely that many service providers will require incentive to adopting this strategy beyond solely meeting customer desires. Standardization will help with incentive; however, it is likely that policy and legislation will also be required—making sure there are motivations to respect privacy and to support an individualized model.

From the perspective of the end user, the final tools and workflows must be friction-free, enabling them to easily set and understand their preferences and use the services they require. Continuing with an ongoing co-design process, usability testing and broad stakeholder consultations should minimize this risk.

Finally, the possibility of security breaches as described in the security assessment section below are a concern. The strategies for addressing these security issues are outlined there. Providing guidance in implementing these strategies through the creation of a comprehensive resource which utilizes existing documents and tutorials on securing systems should help to lower this risk considerably.

4.4.1 Design for Privacy

More and more people rely on technology and “smart” services to provide convenience and accessibility in their everyday lives. For example, devices that allow voice commands to control lighting or other appliances in the home can significantly improve the accessibility of an interior space.

The use of these services, however, comes with the cost and associated risk of sharing personal information online. Those who can benefit most from these smart services, including persons with disabilities, persons who are aging and others who face discrimination, stereotyping, or exclusion, are often the most vulnerable to the misuse of private information (for example through the denial of medical insurance, jobs and services, or fraud).

Putting control of online personal privacy into the hands of the user is an important aspect of inclusive design. By designing services that provide more transparency and individual control over how our personal information is being used, we can help to educate people about digital privacy, foster a sense of entitlement to that privacy, and facilitate more informed choices. Users must be able to personalize their online experience to match not



24

only the task at hand, but also to match their acceptable level of risk. Ultimately, the burden should not be on the user to have to choose between usability and privacy.

When designing new products and services:

• Consider privacy from the beginning of your design process, so that it can be embedded in your design.

• Aim for designs that do not limit usability for the sake of privacy, or vice versa. • Don’t assume user knowledge of privacy-related issues or how to change privacy

settings. • Provide granularity in privacy policies and use clear, simple language. • Provide a way for users to opt-in to information sharing, rather than having to opt-

out.

4.5 Security Assessment

As noted above, introducing systems that gather, present, and transactionalize personal privacy preferences and the uses of personal information opens the risk of increased exposure of personal information. A user’s privacy preferences, in a number of ways, do in fact constitute information about the user – personal information – and can be used to identify aspects of online use and track the user’s online presence. Even when not directly connected with directly identifying information such as a user account or email addresses, personal privacy policies can be used to “fingerprint” or infer a user’s identity. Anonymous information, when aggregated with other data, can often be de-anonymized. If the preferences are somehow traced back to the individual, even more sensitive personal information could be discovered such as their credit card, phone number, health information, and so on.

Nonetheless, there is a notable aspect of privacy preferences that needs to be addressed. They are a single source that are to be applied across many services and contexts. As such they are meant to be shared. At the same time, the personal information they contain must be shielded. Portions of a user’s personal privacy preferences may be contextualized to a particular service provider or even a particular transaction. In these cases, such information should be used only by the service that the user has granted access to, and not shared by that service to third parties unless the user allows sharing.



25

4.5.1 Design for Security

To avoid exposure of the preferences, the architectural plan and implementation of Privacy Preferences Design needs to consider and address the following risks, which are dependent on the implementation approach, software architecture, and technologies used:

● Compromise of the server or databases that store a user’s privacy preferences ● Eavesdropping on communication of privacy preferences (“man in the middle”

attacks, where unsecured communications can be intercepted by a third party) ● Access to preferences when stored on a user’s device (including physical access such

as theft or virtual access such as via malware) ● Impersonation of a privacy-preferences consuming website or websites that are

trusted by the user ● Impersonation of the user, such as stolen user credentials (username and password

and so on) ● Risks associated with specific data that are stored in the privacy preferences (such as

list of trusted websites)

These risks can be addressed using standard security measures: ● Encrypt preferences using symmetric or public-key encryption algorithms with large

keys, such as AES or RSA ● Secure transmission of personal information; e.g. HTTP over TLS (also known as

HTTPS) ● Use multi-factor authentication such as PIN and passphrase or Yubikey ● Use access tokens to grant access to personal information in a way that the lifetime

can be controlled and revoked when compromised ● Avoid unencrypted storage of privacy policies on users’ devices, since these may be

lost or stolen ● Avoid storage on shared devices such as public workstations ● Protect servers that store user privacy policies using firewalls, intrusion detection

systems, and auditable logging/monitoring systems ● Follow standards for creating secured applications, such as the Open Web

Application Security Project’s top 10 security risks31

31 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project


https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project


26

5 Review of WP103 Impact Across the Project

Throughout this project, SP1 has produced several tools and models in order to help SP teams achieve the following goals during design and development of their work for the P4A project:

1. Being informed of full diversity of users to ensure SP teams understand and work from the perspective of real users with real needs, foresee the use cases their work must accommodate, and envision opportunities to foster interactions among different users.

2. Translating user research results into design specifications that could be understood and acted upon by SP teams in the P4A project.

3. Providing all developers and designers across the project common instructions, and best practice guidelines in order to keep their work consistent, interconnected, and inclusive.

In addition to these specific goals, SP1 also aimed to demystify the concept of inclusive design and make it more accessible and practical for the project partners, and facilitating their learning about inclusive ways of thinking, designing and developing digital solutions. Ultimately, SP1 intends for the produced tools and models that are more global and not specific to the development of the DeveloperSpace to continue to exist and evolve beyond the P4A project and be incorporated in project partners’ general practice. For that purpose, the Inclusive Design Guide32, and the Privacy Needs and Preferences33 have been added to the DeveloperSpace and are made available to the public.

5.1 Methodologies

In previous WP103 deliverables, we have assessed the use and usefulness of the first iteration of SP1 tools and models by SP2 and SP3 teams within the context of P4A project (D103.1 and its subsequent iterations for the detailed survey results). To build on previous research and also assess future impact of SP1 work, a new online survey was created and sent out to all SP leaders as well as key project stakeholders. The survey questions are included in the annex, section 7.1.

32 https://ds.gpii.net/learn/bibliography/inclusive-design-guide 33 https://ds.gpii.net/learn/bibliography/floe-privacy-needs-and-preferences



27

This survey was utilized to investigate the impact of SP1 work on SP teams’ general working processes. We have also used this survey as an opportunity to examine what important lessons/insights can be carried out from this project to other similar EU wide projects.

5.1.1 Research, Design and Knowledge Building

SP Work Evolution: Participants in this category were involved with researching and designing the initial concepts of the infrastructure and gathering knowledge throughout the project. As they described, their approach didn’t change considerably throughout the project, however, as the project moved forward, new findings and new knowledge incorporated into the process and more details added to the initial design. For respondents in this group, surveys and interviews were the main tools for gathering insight from project partners and potential end-users and building the project’s knowledge base.

SP1 Impact: participants in this category have either been involved with the creation of SP1 tools and models or helped with dissemination of them. They have utilized SP1 tools to connect different teams across the project and help them clarify and understand the goals of this project. These respondents mentioned that SP1 work and particularly the Inclusive Design Guides can be used in any of their other projects that has inclusive values and mission.

Challenges: Some of the challenges that these teams have experienced relates to their knowledge collection efforts, and they expressed having access to SP1 tools and models right from the start would have minimized these issues. They also expressed, having access to the SP1 economic models and recommended business models right from the start could have helped each partner to consider sustainability and exploitation for the DeveloperSpace infrastructure right from the initial phases of the project.

5.1.2 Development and Implementation

SP Work Evolution: Participants who were involved with developing and implementation of DeveloperSpace infrastructure and its different components (SP2, SP3) mentioned that they referred to SP1 work in different stages, and constantly solicited feedback from other SP2 and SP3 partners and SP4 evaluators to identify the gaps and refine their work. Participants in this category have also taken advantage of bibliographies, standards and accessibility guidelines extensively to improve and build their work.

SP1 Impact: These respondents expressed that the SP1 use model has influenced their work both directly and indirectly. First, they directly used SP1 ‘use model’ for their pilot efforts, product evaluation and testing. For instance, one of the SP3 teams mentioned that by going



28

through SP1 ‘use model’ they realized that there was no user group that could really benefit from their work, so they shifted their focus, and made changes to their initial design, and delivered a different working setup. Another impact that was more indirect resulted from SP4 evaluations. SP4 team used SP1 tools to evaluate DeveloperSpace and its service infrastructures with developers and end users. The results from these evaluations helped the implementation teams to identify gaps, and areas that needed improvement. None of the participants in this group has used SP1 tools for any other project outside of P4A yet, however, one of the participants mentioned that she is planning on using the use model in another project related to accessible transportation.

Challenges: Some of the partners mentioned that they were unable to find specific user persona or a use scenario related to the product or component they were building for the DeveloperSpace. As mentioned in section 3.1, a new set of user persona and use cases added to the SP1 design kit to fill this gap. However, it was always communicated with project partners that the design kit and particularly the Use Model does not aim to build an exhaustive list of users and use cases. Instead it aimed to help project partners broaden their perspective, think of a wide range of users at the margin and adapt the SP1 use model when needed.

5.1.3 Evaluation

SP Work Evolution: Respondents who were involved with evaluation efforts expressed that their understanding of the infrastructure and how it works became clearer as the project progressed. Continuous discussions with other teams across the project and the project management team was a valuable input source for this group and helped them ensure they shared the same vision for the P4A project as the rest of team.

SP1 Impact: Evaluation teams have greatly benefited from the SP1 work. The use model has driven the preparation of their evaluation scenarios particularly in the earlier stages of development of DeveloperSpace and UnifiedListing. In addition, the evaluation teams have used SP1 personae in small focus groups with developers to reveal the potential value of DeveloperSpace and the most probable interactions they might have. They expressed that SP1 work has made them more aware of inclusion and accessibility and has shown them practical ways to apply that mind set in different aspects of their work. One of the evaluation teams are in the process of adapting several SP1 use cases for focus groups related to mobility as a service for people with disabilities and older travellers.

They also expressed that, they will be referring to the inclusive design guide in the future beyond the P4A funded project. The participants who were involved in dissemination



29

activities also claimed that they will be actively using and promoting the inclusive design guides during the P4A open day workshops, conferences, events, and any other dissemination effort in order to inform the community of design for inclusion and accessibility.

Challenges: Some of the evaluation and dissemination teams expressed a need for easier access to the inclusive design guide rather than static PDF files that needed to be printed and cut in size. To address this need, SP1 team, dedicated an online website just to the inclusive design guide34. Since then, not only the dissemination teams, but also all other project partners have been able to easily share this link across and outside of the P4A project and use the guides for different purposes and in different activities.

34 https://guide.inclusivedesign.ca/





30

6 Moving Beyond P4A Project

This is the final report for WP103 as well as the last deliverable for the SP1 team. Although there will be no additional documents, the material produced by SP1 will exist beyond the P4A project and remain available in the public domain for others to use, share, and modify.

SP1 work and the “prosperity-for-all” approach it advances have also informed and made connections to several other international projects. For instance, SP1 work has significantly contributed to the overall conversations about platform cooperativism, which is a growing international movement that builds a fairer future of work. It’s about social justice and the bottom line. Rooted in democratic ownership, co-op members, technologists, unionists, and freelancers create a concrete near-future alternative to the extractive sharing economy. Please visit this link35 for further information about these cooperative projects.

This movement has largely grown out of a convergence between alternative models for work and people forming communities themselves – keeping the services they offer (e.g. car ride, babysitting, cleaning, caregiving) managed by and for themselves. This empowers workers to define their own work and form communities with others. The potential for disruption of existing services and for creating new pathways to address social justice issues is exciting and largely untapped.

Groups looking for ways to address unmet needs and to understand market opportunities across the European Union can make use of the findings of SP1. The economic models presented in D102.1 and the use model presented in D103.1 continue to tell the story of unmet needs, emerging and untapped markets, methods for inclusion, methods for designing and developing for the margins, and more.

Research, Design and Development teams in different stages of their work can take advantage of resources provided by SP1 to assess the inclusiveness of their work and improve them based on the recommended guidelines and specifications. The SP1 team (and now too the larger community of inclusive designers and developers) will also be available to provide further support and explanation regarding any of the following documents to ensure they grow and evolve over time and become accessible and available to more people.

35 https://platform.coop/


https://platform.coop/


31

• The use model36 will be available in the DeveloperSpace ready to be used in different projects. Users can continue building user personae and various use cases and contribute it back to the use model on the GPII wiki.

• The Design Specifications37 will also be in the DeveloperSpace and could be used by anyone who is building a digital infrastructure similar to DeveloperSpace. The global specifications remain a valuable resource for ensuring digital infrastructures are inclusive and accessible. Although the design specifications for DeveloperSpace and its service infrastructures are directly related to the P4A project, with minor modifications, they can offer detailed design guidelines for any other similar project.

• Inclusive design Guide38 is hosted on GitHub and linked from the DeveloperSpace39 and is open to anyone who is interested in contributing new content or modifying its existing material.

• The Inclusive Design Guide Website40 is linked from the DeveloperSpace41 and is available for anyone interested in learning about the inclusive design guide, or who wants to use them (either digital or printed versions) in their own contexts.

• Protection for Consumer Privacy42 is available on the DeveloperSpace and available to anyone interested in best practices and risks associated with protection of consumers’ privacy. This work will be revised as international laws and policies regarding consumer privacy and security will change.

As shown in the diagram below, the 103.2 deliverable is closely related to the forthcoming 404.3 document. The results from ‘SP1 current and future impact’ section in this report will inform the 404.3 report to provide tools and strategies for ongoing monitoring and analysis of the DeveloperSpace and its service infrastructures.

36 https://wiki.gpii.net/w/Use_model 37 https://wiki.gpii.net/w/Design_Specifications 38 https://github.com/inclusive-design/guide.inclusivedesign.ca 39 https://ds.gpii.net/content/guideinclusivedesignca 40 https://guide.inclusivedesign.ca/ 41 https://ds.gpii.net/learn/bibliography/inclusive-design-guide 42 https://ds.gpii.net/learn/bibliography/floe-privacy-needs-and-preferences


https://wiki.gpii.net/w/Use_model


https://github.com/inclusive-design/guide.inclusivedesign.ca


https://wiki.fluidproject.org/display/fluid/%28Floe%29+Privacy+Needs+and+Preferences



32

Figure 3: SP4 and SP1 deliverables



33

7 Annex

7.1 WP103 Survey – Review of Project Evolution from Planning to Implementation

REVIEW OF PROJECT EVOLUTION – SURVEY QUESTIONS

1. Please describe how your final work is conceptually different from what you had originally planned or envisioned (Provide examples)

2. Please describe which aspects of your work have transformed throughout this project.

3. Please describe the reasons that made you change your initial approach, or change direction during the project.

4. Please describe if SP1 tools (user personae, use cases, global and specific design specifications, and inclusive design guide) had any influence on your design and implementation approaches.

5. Please describe any other sources of feedback/input that impacted your work or made you change direction.

6. Please describe if you have you used SP1 tools (user personae, use cases, inclusive design guide) for any other project?

7. Please describe your main lessons learned as you tried to implement your component or finalize your work.

8. How do you think working on the Prosperity4All project has impacted you, your research, or your job in general?

9. Please describe what you would do differently if you were asked to work on a similar project.



34

Glossary

Table 1: Key terms in this document

Key Terms Description

Prosperity4All Project Refers to the funded project, which is comprised of the work packages carried out by various sub-project (SP) teams.

Framework Refers to the creation of an inclusive design framework (delivered in previous D.103.1, D103.1-2 work) as a living resource whose utility in the context of Prosperity4All was merely a beginning to its many uses and applications within and outside of this project.

Wireframes In the context of SP1 work, wireframes refer to research, design and implementation guidelines provided to the project partners to ensure inclusion and accessibility are integrated in their work from the ground up.

Prosperity4All Infrastructure Refers to the DeveloperSpace43 Infrastructure that is a collection of all the components, systems and software developed by the core Prosperity4All teams (SP2 teams), as well as applications made by autonomous companies in the periphery (SP3 teams).

43 https://ds.gpii.net/



35


Inclusive Ecosystem When individuals interact with the Prosperity4All Infrastructure, they participate in the creation and growth of an evolving, complex, interconnected system that adapts based on use and feedback – an inclusive ecosystem.

Functional Packages Individual services that work together to make up the primary functionality of the Prosperity4 All infrastructure.

Design Kit A set of tools (Use Model, Design Specifications, and Inclusive Design Guides) that sub-project teams can apply to ensure that they are building components that will

a. meet the needs of potential users by solving potential use cases for what they are building,

b. follow inclusive design specifications c. apply best practices guidelines to

maximize inclusion.

Use Model A number of representative users who are involved in the creation of the Prosperity4All infrastructure plus a series of use cases that capture their behaviour and interactions in the Prosperity4All infrastructure.

Design Specification Descriptions of functionality that should be supported by the P4A infrastructure to facilitate inclusive user interactions. Design specifications do not provide details on how a component should be designed and built, and they are not meant to be instructions for implementation.



36


Inclusive Design Guides Cards that give succinct descriptions of inclusive design insights, practices, tools, and activities. Sub-project teams can use these guides to develop and design more inclusive solutions from scratch or assess and improve what they have already built.

User Persona Personas are models representing the potential stakeholders who may use P4A products/services. Although they are fictional people, their characteristics, needs, goals and motivations are rooted in the insights and feedback collected from various forms of research. They begin as early provisional sketches of users and then evolve through iterations as more user information becomes clear through research and feedback.

The P4A user personas are not meant to be exhaustive of any group of people and only represent the minimum number required to illustrate key goals and behaviour patterns. Personas are meant as behavioural models; they do not represent full demographics of complex and unique people.

Use Case Descriptions of actions that a user persona (main actor) might take in a specific context in order to achieve a goal.

Main Actor A persona/stakeholder who is trying to meet a need or achieve a goal in a use case.



37


User States and Context Map A user-modelling tool for conceptualizing, designing, and evaluating the ability of a design to be operated by unique users in a wide range of states

State: personal factors that may affect the individual's ability to use a product or system.

Context: physically external factors that may affect an individual's ability to use a product or system.

Stakeholder Map An influence-interest grid that illustrates who might be involved in a scenario. The 'Interest' axis indicates a stakeholder’s likely concern regarding the main actor’s need/goal, whilst the 'Influence' axis indicates a stakeholder’s ability to help the main actor respond to that need/goal.

User Journey Map The line of actions a user might take in order to meet a need or achieve a specific goal. The map is comprised of several steps: inquiry, entry point, engagement, and post engagement. In each step, the user could interact with different stakeholders/systems and get involved with different Prosperity4All functional packages.

Entry Point User encounters service/interface for the first time. The entry experience changes as the user continues using the service/interface and gradually learns how to navigate the interface.



38


Engagement User gets involved with the interface and starts using its functions to accomplish a particular task or achieve a particular goal.

Post-Engagement User successfully/unsuccessfully completes a task or achieves a goal. At this phase user may either leave the service/interface or get involved in another interaction cycle and stay within the ecosystem.

Prosperity4All Economic Model A collection of various business models and payment systems, including the contexts within which they are most appropriately used, mapped to the functional packages for the sub-project teams. This model is the subject of the D102.2 report.

Table 2: Abbreviations used in this document

Abbreviation Full form

AoD Assistance on Demand

AT Assistive Technology

DoW Description of Work

GPII Global Public Inclusive Infrastructure

P4A Prosperity4All

R&D Research and Development

SP Sub-Project

UI User Interface

UX User Experience

WP Work Package

EC European Commission



39

Abbreviation Full form

UIO User Interface Options

FD Tool First Discovery Tool

PMT Preference Management Tool


D103.2 Final Iterative Design Framework and Solid Final Wireframes … · 2018-02-27 ·...

Documents

Transcript of D103.2 Final Iterative Design Framework and Solid Final Wireframes … · 2018-02-27 ·...