d102.1 map of modelling methods and approach fileecosystem infrastructure for smart and personalised...

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

D102.1 Map of Modelling Methods and Approach

Project Acronym Prosperity4All Grant Agreement number FP7-610510

Deliverable number D102.1

Work package number WP102 Work package title Detailed Demand-Supply Transaction

Modeling Authors Mitchell, Stolarick, Clark

Status Draft Dissemination Level Consortium

Delivery Date 03/31/2015 Number of Pages 46

Keyword List:

Planning, Iterative Design, Communications Plan, Business Models, Economic Models, Design Models

Version History

Revision Date Author Organisation Description

1 10/03/2015 Stolarick, Mitchell JIBS/IDRC Initial Draft

2 11/03/2015 Colin Clark IDRC Review and edits

3 15/03/2015 Jess Mitchell IDRC New Version

4 16/03/2015 Dana Ayotte IDRC Review and edits

5 17/03/2015 Stolarick, Mitchell JIBS/IDRC Version with edits incorporated

6 18/03/2015 Colin Clark IDRC Review and edits

7 19/03/2015 Jess Mitchell IDRC Final draft for reviewers

8 31/03/2015 Mitchell, Stolarick IDRC/JIBS Final for submission

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

http://www.prosperity4all.eu/

Table of Contents

Executive Summary .......................................................................................................... 1

1 Remaining SP1 Deliverables ....................................................................................... 2

1.1 Delivery Schedule .......................................................................................................... 2

2 Design Process & Activities ........................................................................................ 5

2.1 (Re)Framing the Design Approach ................................................................................. 5

2.1.1 Mismatch ................................................................................................................. 5

2.1.2 Design-solvable ....................................................................................................... 6

2.2 Design in SP1 .................................................................................................................. 6

2.3 Design Milestones .......................................................................................................... 8

2.3.1 Exploring .................................................................................................................. 8

2.3.1.1 Environmental Scan ........................................................................................ 8

2.3.1.2 Mindmaps ....................................................................................................... 9

2.3.2 Generating ............................................................................................................. 11

2.3.2.1 Use Cases ...................................................................................................... 11

2.3.2.2 User States and Contexts .............................................................................. 13

2.3.3 Delivering .............................................................................................................. 16

2.3.3.1 User Testing .................................................................................................. 16

2.3.3.2 Wireframes ................................................................................................... 17

2.3.4 Chart of goals and tools: a summary..................................................................... 18

2.4 Fitting all of SP1 into the design process ..................................................................... 19

2.4.1 Economic and market modeling research ............................................................ 19

2.4.1.1 Prosperity4All - Actor Hierarchy ................................................................... 21

2.4.1.2 Business/Market Meta-Models .................................................................... 24

2.4.1.3 Questions to be addressed for each Business/Market Model ..................... 25

2.4.1.4 List of Meta-Models ...................................................................................... 26

2.4.1.5 Brief Descriptions of Meta-Models ............................................................... 26

2.4.2 Related research projects ..................................................................................... 27

2.4.2.1 Preferences for Global Access ...................................................................... 27



2.4.2.2 Cloud4All ....................................................................................................... 27

2.4.2.3 Floe Project ................................................................................................... 27

3 Communication/Coordination Plan...........................................................................28

3.1 Mailing list .................................................................................................................... 28

4 Co-design process .....................................................................................................30

4.1 Creating the Conditions for Innovation ....................................................................... 31

5 A condensed design process .....................................................................................33

6 Appendix A ..............................................................................................................35

6.1 Detailed Project Plan/Milestones (next 6 months) ..................................................... 35

7 Appendix B ...............................................................................................................37

7.1 D102.2 Report on business, market and financial/ payment models, and community currency / D103.1 Foundational design for Prosperity4All; platform design, architecture and entry points to the system ............................................................................................. 37

7.1.1 Economic Modeling (JIBS) ..................................................................................... 37

7.1.2 Design Modeling (IDRC)......................................................................................... 38

7.1.3 Architecture (IDRC)................................................................................................ 39

7.1.4 Shared Responsibility (JIBS and IDRC) ................................................................... 39

7.2 D103.2 Final iterative design framework and solid final wireframes.......................... 40

7.2.1 Design Modeling (IDRC)......................................................................................... 40

7.3 All Updates ................................................................................................................... 40

7.3.1 Shared Responsibility (JIBS and IDRC) ................................................................... 40



List of Tables

Table 1 - Chart of goals and tools ............................................................................................. 18

Table 2 - Proposed Actor Hierarchy ......................................................................................... 21

Table 3 - Payment Systems and Approaches ........................................................................... 23

Table 4 - Payment System Complexity and Anonymity ........................................................... 24

Table 5 - Project Plan/Milestones (next 6 months) ................................................................. 35

List of Figures

Figure 1 - SP1 Deliverables and Update Schedule (month, 18=July, 2015) ............................... 2

Figure 2 - Inclusive Design Process ............................................................................................. 7

Figure 3 - A sample of an environmental scan conducted within Prosperity4All ...................... 9

Figure 4 - An example mindmap showing “Value Proposition Clustering” as a complex and overlapping concept mapped to proposed functionality in P4A ............................... 11

Figure 5 - Sample use case developed for P4A where assumptions, functions, and nuggets for innovation are presented ........................................................................................... 13

Figure 6 - A visual representation of Marney’s states and contexts at a particular time. This is aligned with the sample use case above that describes the user's life, habits, and needs and preferences at a particular time as she attempts a particular task. ........ 15

Figure 7 – An example of a low fidelity sketch with ideas for a user preference tool alongside high fidelity designs of an interface that shows the evolved ideas with added interaction design details. .......................................................................................... 17

Figure 8 – Communications Plan: Illustration showing the iterative and collaborative research process used in SP1, where the design and market model research is informed by both the other subproject participants and by other Prosperity4All stakeholders. . 29



Executive Summary

The following document describes the schedule for the remaining SP1 deliverables in the Prosperity4All project, provides an explanation of the design process being used to achieve those deliverables, and outlines a communication plan for engaging partners and stakeholders in participating in these outcomes. This deliverable also includes an overview of the economic and business models that are to be evaluated along with a draft listing of payment and other options to be considered.

The new deliverable schedule included here reflects the modifications to the Description of Work approved February 19, 2015 by the European Commission. The new schedule re-articulates the work that will be done in SP1, provides new timelines, and adjusts for the fact that the work was delayed in the early stages of the project. The deliverables have been reprioritized so that the changes to resources and milestones will have the least impact on the other SPs while still achieving the project goals.

This deliverable is the result of work done in WP102 Detailed Demand-Supply Transaction Modeling tasks T102.1 Inventory of Demand and T102.2 Candidate Demand-Supply Chains and WP103 Ecosystem Requirements task T103.1 Requirements, success criteria and associated technical specifications.

The communication plan describes how the SP1 team will collaborate internally and will gather feedback from a diverse group of stakeholders using a co-design process.

The design process section of this document explains the activities and milestones that the team will complete in delivery of designs satisfying the SP1 requirements.


1


1 Remaining SP1 Deliverables

1.1 Delivery Schedule

Figure 1 - SP1 Deliverables and Update Schedule (month, 18=July, 2015)


2


The diagram above illustrates the SP1 deliverables and the key milestones when they will be iteratively drafted, revised, expanded, and completed. Looking left to right, the key elements start with the deliverables, which are broken down into components, then the timing of each component’s stage of development is shown.

The remaining deliverables for subproject 1 are:

D102.2 Report on business, market and financial/payment models, and community currency D103.1 Foundational design for Prosperity4All; platform design, architecture and entry points to the system D103.2 Final iterative design framework and solid final wireframes

The first two deliverables (D102.2/D103.1) have been combined. Restructuring these deliverables between WP102 and WP103—including the specific content and timing of the deliverables as well as the project teams responsible for completing the work—allows us to better weave together the work of the actual designs with the research. Both streams, design and economic modeling, will be reflected in all documents submitted, reflecting the interdependence of research and design. This will ensure that the SP1 team is working closely and collaboratively to make certain the research outcomes are reflected in the project’s design and development results.

The Prosperity4All components that will be the focus of the economic and design modeling are:

1. Payments/Currency 2. Business/Market Models 3. Unified Listing (Finding) 4. Assistance on Demand 5. Trust, Feedback, Sustainability, Recognition 6. Developer Space & Developer Market 7. Education, Training, Capacity Building, Gamification

Each component’s models, design, and specifications will be iteratively developed through four stages:

1. Foundational – provides an overview and foundational perspective that will help to inform the project’s development and integration activities

2. Detailed – fully modeled and specified for review by other project teams 3. Revised – incorporates feedback from other teams and new ideas 4. Final – final version for Prosperity4All project.

The initial report will be the official deliverable (D102.2 and D103.1 combined) in month 18. Following that will be updated versions (at months 24, 30, 36, and 42) of that initial report for project internal use, which are not official deliverables. These stages are designed to be iterative; subsequent versions of a delivered report


3


will be updated periodically to incorporate feedback and additional detail. By month 18, the full economic modeling (markets models, business models, financial/payment options) and the overall design model for Prosperity4All will be documented. Beyond the research reports, the combined deliverable will also include pragmatic, foundational design documentation. The economic and business model reporting will have its final iteration by month 30 and the design will be finalized with full fidelity wireframes by month 42.


4


2 Design Process & Activities

The following section describes the process being used in the delivery of SP1 designs for Prosperity4All. Our approach involves many strategies common to traditional design methods such as those documented in IDEO’s Human Centered Design Toolkit,1 but is notably different in several important ways. The P4A project uses an inclusive design approach that incorporates marginalized users’ needs and preferences when designing solutions. This requires the design team to not only employ the usual design tools, but to also take diversity and inclusion into account at each step of the process.

2.1 (Re)Framing the Design Approach An inclusive design process is one that begins with a redefinition of ‘disability,’ requires a perspective shift within the role of design, and marries an emphasis on diversity of perspectives with tools and techniques to achieve highly usable interfaces. The goal of this project is to design software that is inclusive of the full range of human diversity by creating user interfaces that adapt to the needs of diverse users rather than expecting users to do the adapting2. Each stage of the design process aims to accomplish this goal.

2.1.1 Mismatch

Many definitions of the word ‘disability’ focus on a medical explanation of what someone cannot accomplish or do – a lack of their ‘ability.’ An inclusive design approach starts with a re-definition of the concept of disability. In Prosperity4All, disability is a mismatch between the needs or preferences of a user in a particular context and a technology they are interacting with3. Mismatch can lead to an inability to access information and technology, and it can also manifest as a discomfort, difficulty, or suboptimal experience with an interface. In this model, the interface is failing, not the user. With this definition of ‘disability,’ the accessibility of a user interface is measured by the ability of the interface to meet the needs and preferences of diverse individuals in diverse contexts with diverse needs and preferences.

1 IDEO. Human Centered Design Toolkit. Web. http://www.designkit.org/resources/1 2 Treviranus, Jutta. What is Inclusive Design? Web. http://idrc.ocadu.ca/index.php/resources/idrc-online/library-of-papers/443-whatisinclusivedesign 3 Ayotte, Dana et al. “Personalizing Interfaces Using an Inclusive Design Approach.” In Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice (pp. 191-201). Springer International Publishing.


5


2.1.2 Design-solvable

The redefinition of disability and accessibility leads to an important perspective shift. The reframing of accessibility puts the burden (and opportunity) on design – accessibility becomes a tractable design and development challenge that impacts us all. Since disability may be a momentary or contextual mismatch, all design work must thus consider a range of potential mismatches, and must take into account a diversity of needs and preferences. In doing this, the designs become more usable and accessible for everyone. This shift also, importantly, engages the end-user in the design of a solution that is “right” for them. Inclusively-designed interfaces allow the user to personalize their own experience – the user continues the design, making the final adjustments to meet their own unique needs and preferences.

2.2 Design in SP1 The design approach for SP1 deliverables is an iterative, feedback-driven one that will request broad participation and will be conducted openly, engaging multiple diverse stakeholders. This section outlines the processes and activities that the design team will conduct, including:

• how the SP1 deliverables will be created • what those deliverables will contain • a communication plan for achieving sustained involvement from the other SPs on the project.

The design work has been and will continue to be informed by the following: the economic and market modeling research, an inclusive design process, other related research projects, and a transparent co-design process.

The process that is being followed in this project is one that has clear milestones for achievement that are arrived at by iteratively building on early and small successes, garnering buy-in from diverse stakeholders often and early, and grounding the work in realistic use cases and with real users.

The artefacts that result from SP1 design activities will include:

• an environmental scan or competitive analysis of existing, related systems; • mindmaps showing the breadth and depth of interactions, entry points, etc; • use cases of realistic users of the system; • user states and context maps (described below); • user testing; and • wireframes.

In cycling through these design milestones, the team will conduct a full design cycle from early design research, to exploring the scope of the problem space, to generating innovative ideas for solving the “mismatch,” and finally to delivering high-fidelity end-user interfaces.


6


Figure 2 - Inclusive Design Process


7


2.3 Design Milestones The various stages of the iterative design process can be summarized as:

1. beginning with existing Research, 2. progressing into Exploring the full landscape of the problem area, 3. Generating new ideas/approaches/variations to test for meeting the needs of diverse users, and 4. Delivering interfaces that address user needs, preferences, and goals. x. Iterating until sufficient solution(s) is achieved

2.3.1 Exploring

The design process begins by examining the breadth and depth of the context and problem. As this research continues, patterns or opportunities for simplifying the problem space sometimes emerge. For example, two types of actors might have similar entry points on the platform – and this similarity might not become clear until it is seen from a broad perspective. The approach at the beginning of the design process is to remain as open and broad as possible to emerging patterns, trends, or opportunities, avoiding the impulse to leap immediately to specific solutions for individual users. The two tools that are particularly useful during the exploration phase are environmental scans and mindmaps. Both help to see the problem space holistically and from multiple perspectives.

2.3.1.1 Environmental Scan

Early design activities often benefit from an environmental scan of what already exists in the domain area. In the case of Prosperity4All, this will involve researching and summarizing:

• existing online multi-sided platforms, marketplaces, and app stores • services that match producers and consumers • sites that educate and distribute badges or some other credential • assistance on demand, transformation, and crowd-sourcing apps and services • small-market or independently-produced assistive technology software

D101.1 outlined many of these systems in “Table 1 - Preliminary list of candidate business models as exposed in D101.1.” Although there is no platform that does all of these things together (and thus the need for the Prosperity4All system), an environmental scan helps contextualize what the design team is setting out to do by first examining what already exists and the gaps that remain unfilled by existing solutions.


8


Figure 3 - A sample of an environmental scan conducted within Prosperity4All4

This gap analysis also helps to reveal the complexity of the domains that Prosperity4All is touching. To further make sense of that complexity, another design tool is used.

2.3.1.2 Mindmaps

In an effort to understand the breadth and depth of the problem space, mindmaps are created. The exact layout or manifestation of these maps varies depending on the context, but they help to conceptualize the scope, identify problem areas, and highlight points of overlap or patterns emerging in the “flow” of how a user might encounter the overall system – from a high-level. By expressing the scope of the problem from many different angles (actors’ needs, platform capabilities, value propositions, organizational priorities, etc.), a collection of mindmaps can help lay out the domain enough to spur conversations, encourage further brainstorming, and ensure stakeholders are starting from the same understanding of the problem space.

4 Shahi, Sepideh P4A Environmental Scan. Web. http://wiki.fluidproject.org/display/fluid/P4A+Environmental+Scan


9


Sketching out these mindmaps allows the design team to begin to visualize interface flows and to identify open questions related to workflow of the tools. Mind-mapping allows designers to tackle the big picture early on in the design process while also clarifying the scope of the project. Mindmaps are not interface designs, nor are they fixed or fully-enumerated solutions: they are a design tool that acts as a vehicle, moving the thinking forward. In this way, mindmaps are useful at the beginning of the design process and often outlive their usefulness as the design thinking evolves. Mindmaps, like the other design milestones outlined here, become a kind of artefact archive for the project. The mindmap below shows an example of how complex relationships can be represented. In this case it is included to simply show a mindmap and is not meant to be understood out of context.


10


Figure 4 - An example mindmap showing “Value Proposition Clustering” as a complex and overlapping concept mapped to proposed functionality in P4A

2.3.2 Generating

2.3.2.1 Use Cases

After mapping out the breadth and depth of the design problem space from a number of directions, it is then helpful to narrow in on specifics: a way to do this is by creating realistic use cases that begin to explain the behaviour of an eventual user of the system.


11


Use cases provide a way for the design team to understand the contexts and interactions of different users. Through the creation of these use cases, the team begins to flesh out an understanding of the breadth of requirements for the system as well as specifics of how the system might meet the needs of a real user.

By their very nature these use cases are limited in that they cannot cover the full spectrum of potential users, nor should they attempt to. It is not a fruitful or realistic expectation for each potential user to be understood, for each user’s needs to be enumerated, nor each interaction anticipated; this is not the goal of design. Rather, we emphasize the creation of “edge cases” that represent realistic users who are not part of an imagined “majority” of users. By solving for the edges, the team is able to accommodate the needs of the “typical” while also addressing more complex needs5,6.

Use cases allow the team to begin to think about interactions and interface ideas. Over the course of the design process the team often returns to both the mindmaps and the use cases, refining and adding details to both. This iterative process provides a mechanism for revisiting and questioning early design assumptions.

Below is an example of a use case for Prosperity4All, reflecting the goals and needs of a particular user in a particular context.

Marney has recently purchased an electric scooter. She finds it difficult to use the manual to learn about how to use its different features. She wants someone to simplify the manual for her. She goes to the P4A platform, logs into her account and makes a request for content simplification. Don is an active member within the system who receives a newsletter with content that may be relevant to him. His wife uses the same kind of scooter as Marney. He finds out about Marney's request through the newsletter and contacts her. Marney and Don negotiate the terms (timing, compensation, etc.). Don simplifies the manual's feature descriptions and shares the result with Marney. They can continue their conversation via messaging to address all Marney's concerns and questions. She compensates Don through P4A and rates his service.

This use case presents a simple scenario: a need and an opportunity. Though the version presented here is truncated, it is clear that this simple scenario contains a series of assumptions, potential functions, and seeds of innovation. All of these elements contribute to an emerging vision for a system that could address Marney’s and Don’s needs.

5 Treviranus, Jutta (January/February 2014). The Value of the Statistically Insignificant. Educause Review. Retrieved from http://www.educause.edu/ero/article/value-statistically-insignificant 6 Treviranus, Jutta (November 2010). The Value of Imperfection: the Wabi-Sabi Principle in Aesthetics and Learning. Open Ed Conference 2010. Retrieved from http://openaccess.uoc.edu/webapps/o2/handle/10609/4869


12


Figure 5 - Sample use case developed for P4A where assumptions, functions, and nuggets for innovation are presented

2.3.2.2 User States and Contexts

User States and Contexts is a tool created by the Inclusive Design Research Centre that helps to visualize the needs, preferences, and contexts of users over time. User states and contexts is a modeling tool for visualizing the particular needs and preferences of a user into a “constellation” that represents their unique needs at a particular place and time. The tool is motivated by the need to visualize the many “states” and “contexts” any user can be in.

For the purposes of the tool, state is defined as any personal factor that can affect an individual’s ability to use a system optimally, and context is something external to the individual that may affect their ability to use a system optimally. Variations in ‘state’ and ‘context’ can lead to mismatch between a user’s goals and the ability of the interface they are interacting with.

Because a user's state and context shifts throughout the day, week, and life of a user, what may be true at one moment may not be true in another. For instance, a user's needs for a given product in the morning at the office


13


may be different in the afternoon in the car. This tool attempts to capture the space of these varying states and contexts in order to make the considerations for designing all needs more transparent.” 7

Overlaying the “constellations” of many users easily shows overlap in needs regardless of individual differences. This helps reveal commonalities and differences among users. The tool can also show how an individual user’s needs evolve over time within various contexts.

7 Yoon, James. (Floe) User states and contexts. Web. Retrieved from http://wiki.fluidproject.org/display/fluid/%28Floe%29+User+states+and+contexts


14


Figure 6 - A visual representation of Marney’s states and contexts at a particular time. This is aligned with the sample use case above that describes the user's life, habits, and needs and preferences at a particular time as she attempts a particular task.

The Generating phase of the design process begins to introduce various representations of solutions for users. It is important not to jump into concrete design solutions too early in the design process – doing so can curtail lateral thinking by distracting participants with specific user interface details too early in the design process. “Go hi-fi too soon and users will focus on visual design, which is not appropriate in early stages.“8 High fidelity designs can carry an authoritative tone – a tone that could limit the feedback that is so helpful to the design process.

8 Cerejo, Lyndon (June 16, 2010). Design Better And Faster With Rapid Prototyping. Smashing Magazine. Retrieved from http://www.smashingmagazine.com/2010/06/16/design-better-faster-with-rapid-prototyping/


15


2.3.3 Delivering

The Delivering phase of the design process marks the introduction of design solutions. Sketching partial prototypes is one way to avoid the sway of the visual while beginning to explore interactions and affordances that address the scoped design problems. The SP1 deliverables are arranged to facilitate gathering feedback and working iteratively on designs with a broad, diverse group of stakeholders. One tool used to gather feedback early in the Delivering phase is user testing.

2.3.3.1 User Testing

User testing is an important activity in the inclusive design process. In Prosperity4All, informal, design-oriented user testing (as opposed to the more formal and evaluative testing process of SP4) will be performed early and often, beginning with paper prototypes. Such tests are intended to reveal strengths and weaknesses of the design, not to test the ability of the user. Gathering feedback to early design work through user testing helps reveal design weaknesses, usability problems, interaction design opportunities, and functionality.

Each individual who tests the interface is unique and therefore can help the designers understand how the interface might be unexpectedly used. The goal is not to test for particular disabilities (see section on reframing of disability above), but rather to test with diverse individuals under different contexts and scenarios of use. From testing, the design team is able to extrapolate and imagine how other users might interact with the system and to refine it according to the feedback gathered. User testing engages the user in the formation of the solution, allowing them to help shape it to meet their needs. Since this kind of testing is often done with small sample sizes and unfinished design prototypes, there is a subsequent activity of understanding, interpreting, and generalizing a particular user’s feedback and integrating it into the designs.

User testing is done by first creating a testing protocol that outlines the goals and activities of the test. The wording of the testing protocol can have an impact on the outcome, so it is essential that the designer is able to construct the protocol in a way that generates the intended interaction.9 Then the designer needs to know what to do with the outcome of the testing. The results still require interpretation and must be understood in the larger context of the user’s state and context and unique needs and preferences. In some cases, this activity can send the design team back to the Generating phase of the design process to flesh out a use case for further investigation into how a particular user will interact with the system. This is another example of how the design process is not linear, but rather iterative. User testing typically begins with simple paper prototypes and continues with all versions of wireframes (from low to high fidelity).

9 Hicken, Jonathan and Stef Miller (November 17, 2014). How to Write Great Questions for Your Next User Test. User Testing. Retrieved from http://www.usertesting.com/blog/2014/11/17/how-to-write-great-questions-for-your-next-user-test/


16


2.3.3.2 Wireframes

The design team will generate low-fidelity wireframes that will culminate in final, high-fidelity wireframes after multiple iterations. Wireframing begins the process of concretizing the ideas for the design solution. The act of creating wireframes often begins with sketchy ideas and notions of interactions (tied to functions like the ones from Marney’s use case above), and slowly moves toward user interface designs and flows. User states and contexts, use cases, and user testing help evolve the wireframe design work by giving details that manifest as increasing levels of specificity for user interactions, affordances, and user interface flow.

Figure 7 – An example of a low fidelity sketch with ideas for a user preference tool alongside high fidelity designs of an interface that shows the evolved ideas with added interaction design details.


17


The development team works closely with the designers throughout the entire process so in the end, the final wireframes are arrived at collaboratively and represent the work of the group. The developers, then, aren’t surprised by any of the interactions or features. This is in contrast to a waterfall approach where all design is completed and then handed over to developers.10

2.3.4 Chart of goals and tools: a summary

Below is a chart that pairs the goals of the design process with tools and milestones that mark the work toward and realization of these goals. The tools help the design team create artefacts for design that live as the project archive after the work is done. Those milestones tell the narrative of how the designs evolved and how the team made decisions, collaborated, and arrived at final designs.

Table 1 - Chart of goals and tools

Design Tools & Milestones Interface Value & Goal Environmental Scan / Competitive Analysis

Creating something innovative that meets the needs and preferences of users and solves a design problem in a particular domain. Knowing what exists now and questioning whether or not it is the right way to do things. Seeking inspiration from seemingly disparate places, not just the field of interface design.

Mindmaps Make sense of the complexities of the problem space as it is getting defined. Broad design conceptualizing and thinking.

Use Cases Developing “edge” cases to guide the design thinking. Describe particular scenarios that illustrate the problems users encounter – explain the context around unmet needs. Increase access to interfaces by understanding where interfaces do not meet the needs of users.

User States and Contexts Search for cross-cutting patterns (i.e. digital curb-cuts)11. Meet users where they are; address their needs

User Input & Testing Asking questions, being curious, learning from users. Gathering feedback to early design work to reveal design weaknesses, usability problems, interaction design opportunities, accessibility, and functionality.

Wireframes Actualize the design “thinking” in visual interfaces and affordances that bridge the conceptual goals with the end-result – a personalizable, highly usable interface – achieved through short iterations that build on each other, yielding simplicity for a complex problem

10 Reed, Donna. Differences between Waterfall, Iterative Waterfall, Scrum and Lean Software Development (In Pictures!). The Agilista PM. Retrieved from http://www.agilistapm.com/differences-between-waterfall-iterative-waterfall-scrum-and-lean-software-development-in-pictures/ 11 Jacobs, Steve. Section 255 of the Telecommunications Act of 1996: Fueling the Creation of New Electronic Curbcuts. Retrieved at http://www.accessiblesociety.org/topics/technology/eleccurbcut.htm


18


All design work is shared openly in real time.

Diverse feedback as a constant input to throughout the whole design process.

2.4 Fitting all of SP1 into the design process The work will be informed by the following inputs: the economic and market modeling research, an inclusive design process, other GPII-related personalization research projects such as Cloud4All12, the FLOE Project13, Preferences for Global Access14, Project Outside-In15, OmniAgora, and a co-design process.

The economic modeling, which will provide both business models and marketing models, will be simultaneously developed with the design modeling. Both will share an underlying set of stakeholders and use cases that will be at a more abstract, higher level for economic modeling and a more detailed level for design modeling. The economic models will define business models, payment systems, stakeholders, and stakeholder interactions as an inclusive set of options rather than as specific “this way only” alternatives. These models will be used and reflected in the design models that will, in turn, document the need for greater specificity in existing models and suggest other alternative models to be considered.

2.4.1 Economic and market modeling research

The economic modeling to be undertaken is focused on inclusivity. Rather than prescriptively specifying only certain models as being the only ones to be considered for Prosperity4All, the approach will be to document and clarify a variety of different approaches that could be taken by the other project teams and by the users of the system. These approaches build from the work that was previously completed in the D101.1 and D101.2 deliverables.

The focus, as shown below, will be on three dimensions of the complete system:

1. The Actors – the Actor Hierarchy shows one way that the various users of the system could interact with the system and documents the interrelationships among various kinds of user types. It provides a framework around which all the stakeholders and entry points can be more fully documented and discussed. It also provides an inclusive way to specifically document some stakeholders while not excluding other possibilities. From an economic modeling perspective, understanding the various

12 http://cloud4all.info 13 http://floeproject.org 14 http://wiki.fluidproject.org/display/fluid/Preferences+for+Global+Access 15 http://outside-in.idrc.ocadu.ca/


19


stakeholders is necessary to be able to identify markets, market size, value propositions, value chains, and numerous other economically relevant factors.

2. Payment Systems – the payment systems for Prosperity4All also must be inclusive. The system must support numerous options and opportunities rather than restrict stakeholders to a specific set of options. Some people will be happy providing services on a barter or community currency system while others will want and need currency-based payments. Many other options are possible. The link between payment and the economic modeling is already obvious, but the need to understand the relationships among various stakeholders, payment systems, and business models is not so apparent. Additionally, detailed documentation on various payment systems, how they work, and how to use them will become important information for project developers and other developers using the Prosperity4All environment.

3. Meta-Models – Understanding how the system facilitates and enables the interactions of the various stakeholders is the final dimension that must be developed in order to examine and document the possible business models for Prosperity4All. These will be the use cases that will describe the interactions and the various components of those interactions. However, as is the case with the actors, and in keeping with the iterative nature of the design and economic modeling as described throughout this document, the definition of these use cases needs to be detailed while still remaining inclusive and needs to reflect the unfolding levels of greater detail. The meta-models serve as the highest-level most abstract use cases from which more detailed use cases can be developed. The meta-models provide a framework and allow for economic modeling at the highest level of abstraction possible while still being detailed enough to be meaningful.


20


2.4.1.1 Prosperity4All - Actor Hierarchy

Table 2 - Proposed Actor Hierarchy

P4A Actor Client (user of the system)

[personalizer] Stakeholder [public, private, foundation] Client 1

Client 2

[public, private, foundation]

Client 3 [individual, organization]

[free, paid]

Individual with unmet needs

Family member Caregiver

Obligated organization; vendor of goods and services to a Client 1,

their customer; consumer of Client 3 products

Digital Resource Producer

Component Distributer Employer

Teacher/Educator

Goods or services provider

Amateur/hobbyist Accessibility Tech. Manufacturer

Tool/Application Developer Entrepreneur

Learner Preferences Server (Cloud4All)

Individual or organization with an interest in P4A or an impact

on the environment, infrastructure, policy,

financing, etc.; not a frequent direct user of the system

Policymaker

Financier Micro Investor

Group for People with Disabilities

Media Third Party Payer

- Insurance Company - Government - Foundation

- Other

Direct Client Indirect Client Services Vendor Goods Vendor Services Provider Goods Provider

Individual works directly with a Client 3

Individual customer of a Client 2 who in turn works with Client

3(s)

Provides service to a client 1

(their customer)

Provides goods to a client 1

(their customer)

Provider of an accessibility

service

Provider of an accessibility

product or design


21


Reading the Actor Hierarchy Chart:

• Each layer represents one view of the actors. The layers allow for conceptualization consistency. Use cases and other documentation can (and will) be done using these layers.

• The actors are in bold text. • The text within [brackets] is basically “type casting”. For example, a Client 2

(obligated organization) could be either a public, private, or foundation (not-for-profit) organization. It should be possible to discuss either “Client 2” when talking about all obligated organizations or “[private] Client 2” if discussing only obligated organizations that are private institutions.

• The [bracket] text can propagate downward, but not upward. A “[public] Services Vendor” would be a public obligated organization that makes it services available to a client 1 (individual with unmet needs) and provides services – so a “[public] Services Vendor” could be a government department while a “[private] Services Vendor” could be a bank or airline.

• The italicized text is just meant to be descriptive and refers to the actor directly above it.

• The other smaller text just uses the various stakeholders that have been identified in various ways so far in the project and assigns them to a specific actor type/subtype. They are not meant to be exhaustive but inclusive.

• The [personalizer] is just for re-casting the other actors at all levels to allow for the users of the system to set up their own information. “[personalizer] Client” is simply general information for any system user while something like “[personalizer] [individual] [paid] Goods Provider” would be the specific information needed for a service provider who is an individual who is to be paid for the accessible goods provided. A “[personalizer] [individual] [free] Goods Provider” might not require the same information since payment is not expected or necessary and that information would not be needed.

• The goal of all of this is to be “inclusive and detailed” which requires being specific when possible but still leaving open the option for other individuals, organizations, or ideas. The hierarchy is meant to allow for use cases, design, and economic modelling that are only as specific as necessary given the context.


22


• Consideration (Financial and Nonfinancial)

This is just the current list – could and should be added to. Not in any particular order. Just three lists.

Table 3 - Payment Systems and Approaches

Financial

Currency Credit/account Micropayment

Currency in different units Credit Card Stored value (pre-paid) card

International currency Credit Card network Direct bank transfer

Eurogiro PayPal (others like it) On-line bank transfer (like payment via email)

Digital currency; BitCoin Credit/account NFC – Mobile - Smartcards

M-Pesa (others like it)

Semi-financial

Community currency Intellectual Property rights Reward (prize)

Barter units Gift Reward (like air miles)

Equity; Stock options Payment for someone else Discount for providing review (buyer or seller)

Nonfinancial

Pure Barter Badging “Pay it forward”

Credit/Recognition Volunteer Review

Consideration (payment) systems can be divided by complexity and anonymity. Considering some of the possible payment systems, they divide along these two dimensions as follows:


23


Table 4 - Payment System Complexity and Anonymity

Complexity

Very High

Foreign Currency Transfers

High

Bank Transfers

Credit/Account Micropayments BitCoin; digital

currency

On-line Bank Transfers

PayPal

Medium Smartcards/Mobile Stored Value

Cards

Low Credit Cards Currency; cash

Gold

Low Medium High

Anonymity

2.4.1.2 Business/Market Meta-Models

Going over everything developed so far; using the actor hierarchy (above); understanding that a large number of various kinds of payment options/other considerations have to be possible; and keeping with the “inclusive and detailed” approach, the team has identified five possible business models that explain the current (and complete) set of possible interactions that P4A needs to support. Others could be identified and developed, and part of the purpose of these meta-models is that they can serve as a basis from which other more detailed models can be developed. For now, this is meant to be a complete list – all of the possible business models should fit within this framework.

Going forward, i.e. after the more detailed deliverable is completed in month 18, the iterative design process intends and hopes that other more inclusive suggestions will be made and discovered so that this can be enhanced. But, for now, this is what will be documented. Detailed, specific scenarios will be developed for each of these five meta-models. Those scenarios will be identified by looking at the various combinations and variations that would be possible given the [bracketed] actor types. While these meta-models are just that because they are at the highest levels of the actor hierarchy, the entire hierarchy is to be taken into consideration to develop more complete and realistic business models and scenarios.

For each of these, the following will need to be done: Ecosystem infrastructure for smart and personalised inclusion and PROSPERITY for ALL stakeholders www.prosperity4all.eu

24


1. Detail the meta-model scenario; write a high-level guiding use case that doesn’t include specifics (that will come) but describes the general linkage and flow (of goods, services, consideration).

2. Identify all of the possible variations of the meta-model using the actor hierarchy and [types].

3. Determine if a variation should not be realized or supported (at the time). But, by identifying all of these possibilities, a much more inclusive approach can be taken in the design and implementation of P4A.

4. Create detailed use cases for each possible variation that should be supported. 5. Address the specific questions identified in the DOW (repeated below) 6. Determine the potential market size in people and currency for both supply and

demand (and other engaged parties as appropriate). Do this for: • EC member countries (as a group) • Canada • US • Rest of the world

2.4.1.3 Questions to be addressed for each Business/Market Model

The modeling and analysis will address questions critical to recruiting appropriate stakeholders, and supporting necessary interactions. These questions include but are not limited to:

• what is the value proposition for each stakeholder? • what is viewed as “affordable” by consumers for what services and products? • how will viable cost structures be established? • what are potential revenue streams? • how will consumer demands be communicated to potential suppliers/producers? • how will candidate products/services or suppliers/producers be chosen? • who are the potential suppliers/producers that are currently marginalized and what

is needed to enable these suppliers/producers to meet marginal consumer demands? • how will suppliers/producers establish viable service entrepreneurships? • what are channels that can be used to deliver services and products? • what is the optimal role for public and social services and how are these most

effectively and efficiently deployed? • what are potential cost savings? • how can mainstream trends be leveraged? • what are potential threats or risks to successful completion of transactions and how

can these be addressed?


25


The modeling and analysis will address questions critical to recruiting appropriate stakeholders, and supporting necessary interactions. These question include but are not limited to:

• how will consumers review and provide feedback regarding services/products delivered?

• how can consumers be engaged as potential suppliers/producers? • how are volunteer networks and crowdsourcing integrated into the supply chain? • where are opportunities for reuse and bartering? • how are consistency, reliability and quality assurance supported and maintained? • how are associated services such as training, setup, repair, troubleshooting and

upgrades managed?

2.4.1.4 List of Meta-Models 1. [personalizer] Client Client 3 (preferences server) 2. [direct] Client 1 Client 3 3. [indirect] Client 1 Client 2 Client 3 4. [direct] Client 1 Client 3 Stakeholder (Client 1 Stakeholder) 5. [indirect] Client 1 Client 2 Client 3 Stakeholder

(Client 1 Stakeholder Client2)

(Forgive the confusion in 4 & 5 – trying to show additional linkages using only text – just pointing out that there are other connections.)

2.4.1.5 Brief Descriptions of Meta-Models 1. A user (any user) of the system personalizes it based on their requirements and role. 2. An individual works directly with a provider to get a needed accessibility service or

good. The individual either looks for a [free] provider or the individual will provide payment.

3. An individual seeks a good or service from a vendor who needs or chooses to use a provider to provide for the individual needs. The vendor interacts directly with the provider(s) and the individual does not have any direct interaction with the provider.

4. An individual works directly with a provider to get a needed accessibility service or good. The individual also works with another stakeholder (most likely a third party payer) that will provide payment to the provider. It is possible that the stakeholder could be something other than a payer and is providing some other help or assistance to the individual. The provider only receives payment or other information from the outside stakeholder and does not directly interact with them in any other way.

5. An individual seeks a good or service from a vendor who needs or chooses to use a provider to provide for the individual needs. An outside stakeholder is engaged either separately or jointly by the individual and/or the vendor. The outside stakeholder will


26


provide payment or something else to the provider. The vendor interacts directly with the provider and the individual does not have any direct interaction with the provider.

2.4.2 Related research projects

The work on Prosperity4All is informed by work on a number of other active projects that bear a direct impact on both the process and outcomes of Prosperity4All.

2.4.2.1 Preferences for Global Access

Funded by the US Department of Education, Preferences for Global Access is looking at entry points for “first discovery” of preferences. This project is developing and designing tools that break down barriers for entry to the digital realm for those with unique needs and preferences. Users whose needs are expected to be met by Prosperity4All will benefit from the integration of entry-point tools like those from PGA in the larger system. Getting unique users in the door is a first step to getting their participation in a larger digital system.

2.4.2.2 Cloud4All

The IDRC design team has been conducting the design within the EU-funded FP7 project Cloud4All where numerous tools are being designed and developed to allow users to explore, declare, and save their needs and preferences for use across our ever-increasing digital world. Prosperity4All plans to integrate these tools into the larger system, allowing users to personalize their experience and facilitate greater engagement among a more diverse group of end users.

2.4.2.3 Floe Project

Funded by The William and Flora Hewlett Foundation, the Floe Project is having an impact on making Open Education Resources and their consumption more inclusive. At the core of the Floe Project is a user interface options framework that allows users to transform digital content and interfaces to meet their needs and preferences. The Floe Project builds on the inherent mutability of digital objects to extend a multi-modal approach to users.


27


http://wiki.fluidproject.org/display/fluid/Preferences+for+Global+Access

http://www.cloud4all.info/

http://www.floeproject.org/

3 Communication/Coordination Plan

A clear communication plan for SP1 will ensure that the outcomes of SP1 will help the other SP leaders move forward on project deliverables informed by the design and market research. SP1 deliverables have been restructured with this goal in mind.

3.1 Mailing list

The SP1 team will communicate openly in all stages of the design and modeling process. The team will use an open mailing list hosted as part of the GPII collaborative infrastructure.16 Team members from across the Prosperity4All project and beyond are encouraged to join the mailing list and to participate in the conversations about design that will be held there. Additionally, all deliverables (from early drafts to final versions) will be shared via this list; the design team will regularly solicit feedback and edits from the larger project team.

The mailing list has a built-in archive that will allow the team to revisit conversations and decision points, ensuring that the work moves forward and as decisions are made, they are made publicly, shared broadly, and preserved.

16 http://lists.gpii.net/cgi-bin/mailman/listinfo/prosperity


28


http://lists.gpii.net/cgi-bin/mailman/listinfo/prosperity

Figure 8 – Communications Plan: Illustration showing the iterative and collaborative research process used in SP1, where the design and market model research is informed by both the other subproject participants and by other Prosperity4All stakeholders.

As the image indicates, the work within SP1 creates a cycle of feedback between the design effort and the market models research. The design team will create user interfaces and a design framework that reflects the outcomes of this feedback loop soliciting feedback and input from the larger SP1 community along the way. The larger Prosperity4All community is also asked to contribute feedback and suggestions. These communication cycles occur at all stages of design from early sketches to high-fidelity prototypes. This helps to mitigate the risk of having surprises at the end of the project. This way the entire team is involved in keeping SP1 on track and on the outcomes of SP1 with the design team leading the work and communication.


29


4 Co-design process

The SP1 design effort will be based on a co-design process17 that is an extension of traditional user-centred and participatory design techniques – one that extends participation in the full design process to the user. The advantage of co-design is that it expands the role that collaborators, stakeholders, and users can play within the design process, allowing them to make essential contributions to the scope, functionality, and “look and feel” of the resulting software. This encourages a deeper investment and participation from stakeholders, rather than positioning them only as “consumers” or “critiquers” of design. All stakeholders are considered members of the design team and their participation is considered part of the design work.

The co-design process will consist of iterative design, development and user feedback cycles. These cycles will culminate in several prototype iterations that are consistently informed by both end user input and design research.

Co-design does not shift the burden of design work onto stakeholders, but rather draws on a diverse group to conduct exploration at the beginning of the design process and to lend experience to the later phases and activities.

What co-design is not:

• Us versus Them – observing people • Expecting others to do the “work” of design • A fixed, pre-determined design process

Co-design encourages the participants to collaboratively define what specific processes and techniques to use. Design milestones like those described in the design process section above must still be achieved. However, the co-design participants can collectively define how and when to achieve those milestones. This inspires a greater investment in the end results while helping to validate designs throughout the design process, rather than leaving it until the end when the cost of change is higher.

What co-design is:

• Collaborative • Responsive • Iterative • Diverse and Broad

17 http://en.wikipedia.org/wiki/Co-design


30


This co-design process will be paired with an Inclusive Design approach18 (as described above). Here the designer serves, in part, as a facilitator for users to be involved in designing a system that meets their unique needs. Inclusive design invites the user to continue the design. This perspective shift of including more diversity in design has shifted not only the ‘how’ of design, but also had an impact on the ‘what’ of design. In this model, users are able to determine what works best for them, to declare that, and to have interfaces and content adjust to their needs and preferences.192021 This personalization approach, paired with the co-design and inclusive design processes is being used in P4A.

This open and highly collaborative approach requires communication that engages colleagues and stakeholders early, clearly communicates expectations for participation, and is able to flex to the needs of the project. Successful inclusive design results in a rich and diverse group of individuals from diverse backgrounds and focus areas participating collectively and with a sense of ownership and responsibility for the outcome. Design becomes a community-driven, collaborative process that works best when the community is clear, open, and aware of expectations.

4.1 Creating the Conditions for Innovation The above articulation of the processes the Prosperity4All community is following is meant to provide the foundation for innovation to occur. While no one knows the secret recipe for creating innovation (or else we would reproduce it all the time) we do know some conditions that seem necessary for innovation to happen22. These include:

• diverse perspectives • collaboration • open flow of ideas • exploration • out-of-box (and out-of-discipline) thinking

18 Treviranus, Jutta. What do we mean by Inclusive Design? Retrieved from http://idrc.ocadu.ca/index.php/resources/idrc-online/library-of-papers/443-whatisinclusivedesign

19 Treviranus, J. (2009) “You Say Tomato, I Say Tomato, Let’s Not Call the Whole Thing Off “in On the Horizon. Emerald Group Publishing Limited.

20 Treviranus,J., Hockema, S., “The Value of the Unpopular: Counteracting the Popularity Echo-Chamber on the Web,” IEEE TIC-STH 2009 (Recipient of Best Paper Award).

21 Treviranus, Jutta. "Making yourself at home—Portable personal access preferences." Computers Helping People with Special Needs. Springer Berlin Heidelberg, 2002. 643-648. 22 Thinking, E. D. (2007). Innovation as a learning process. California Management Review, 50(1).


31


• looking for patterns • exploring the atypical

The SP1 team will encourage these behaviours throughout the work on the deliverables. The processes used (co-design and inclusive design) aim at maximizing the conditions above while minimizing risk for the project.


32


5 A condensed design process

Below is a condensed articulation of the design process the Prosperity4All team is using.

Environmental Scan (Background Research) Conduct an “environmental scan” for the scoped area:

• What has been done to date? • Where does it fall short? • How does it or doesn’t it address edge use cases and diverse needs?

Get User Input and Feedback

Create a Mindmap

• explore the breadth and depth of the scoped area

• map the actions (verbs) of users (nouns)


Create a Persona, an Edge Case Think about various users in the domain with unmet needs, and imagine a user...

• inspired by real people • that is unique: doesn’t simply represent the norm, the average, or the typical • name them • describe their life • describe their needs and preferences • likes and dislikes


Create a Scenario • What does the user want to do? (be specific) • Describe the context, the available tools, the constraints, potential distractions, etc.


How could you meet their needs? • Imagine what would help in this situation • Think beyond known technical limitations


33


• Map out a plan for addressing the user’s needs


Tip-toe into sketching • Allow ideas to flow -- don’t try to solve everything here • Start sketching the sketchiest of ideas -- think of them as scraps that might be

stitched together in later steps -- chunks of functionality • Start with raw ideas (it doesn’t have to have a form yet!) • At this point there may be functionality that developers can start on without having

designs worked out entirely. This will help keep the work iterative and quick.


Putting it together • Start combining the scraps that fit together -- start stitching • What might an interface look like that could solve the user’s problem • Does it solve for other users too?


Iterate! again and again • Think of interactions • Think of other, unique users • Think of flow



34


6 Appendix A

6.1 Detailed Project Plan/Milestones (next 6 months)

Table 5 - Project Plan/Milestones (next 6 months)

Description Responsible Due Date

Weekly Teleconference (3pm CET; 9am EST) SP1 Team

MILESTONES

First Year Review (EC in Luxembourg) JIBS, IDRC 23-Apr

All Documents for Internal Review 3-Jul

Deliverable for P4A Review 31-Jul

Final Deliverable (D102.2/D103.1) 28-Aug

Prep for Annual Review JIBS, IDRC 23-Apr

Payments/Consideration

Payments/Consideration - List of options to use JIBS 27-Feb

Payments/Consideration - Information/form to complete JIBS 13-Mar

Payments/Consideration - Collect information for all; post to Wiki

JIBS (students)

26-Jun

Review Student Submissions JIBS 3-Jul

Business/Market Meta-Models

Model 1 - Preferences (all client types) JIBS, IDRC 13-Mar

Model 2 - Direct Client to Service Provider (includes AoD) JIBS, IDRC 10-Apr

Model 3 - Indirect Client to Obligated Org. to Service Provider

JIBS, IDRC 22-May

Model 4 - Direct with Other Stakeholder (payer) JIBS, IDRC 19-Jun

Model 5 - Indirect with Other Stakeholder (payer) JIBS, IDRC 3-Jul

Open Innovation Research

Outline JIBS 27-Mar


35


Description Responsible Due Date

First Draft JIBS 8-May

Review SP1 Team 22-May

Revisions/Final Draft JIBS 3-Jul

Inclusive Design/Business Models Research

Outline JIBS 27-Mar




Community Currency Research

Outline JIBS 27-Mar




Design Deliverables

Unified Listing (finding) - detailed IDRC 3-Jul

Assistance on Demand - foundational IDRC 3-Jul

Trust, Feedback, Sustainability, Recognition - foundational IDRC 3-Jul

Developer Space & Developer Markets - detailed RTF (IDRC, JIBS)

23-Apr

Education, Training, Capacity Building, Gamification - foundational

IDRC 3-Jul

Review/Revise

Internal Review of Documents SP1 Team 17-Jul

Revisions SP1 Team 31-Jul

P4A Review P4A Reviewers

28-Aug

Revisions SP1 Team 28-Aug

Deliver Final Deliverable JIBS 28-Aug


36


7 Appendix B

This appendix includes the original material from the Description of Work. However, all of the tasks and responsibilities have been redistributed among the SP1 various project teams. The purpose of this section is to reconfirm the activities agreed to in the DOW and clarify responsibilities in light of the replanned SP1 and the development approach outlined in this document.

7.1 D102.2 Report on business, market and financial/ payment models, and community currency / D103.1 Foundational design for Prosperity4All; platform design, architecture and entry points to the system

7.1.1 Economic Modeling (JIBS)

• Identify relevant demand-supply chains and the factors and transactional supports needed.

• Identify overall value propositions for main stakeholder groups.

T102.1 Inventory of Demands (removed)

A comprehensive inventory of current, unmet and potential demands to be met by the P4A infrastructure will be created through stakeholder consultation and other research methods. These will be prioritized through consumer consultation and tagged according to availability of potential products and services to meet the demands.

T102.2 Candidate Demand-Supply Chains

Using the basic market models identified in WP101 and the inventory of demands in T102.1, WP102 will carry out an environmental scan and data collection to identify potential suppliers or supply chains to meet the identified demands. These models will also help to identify the maturity of these supply chains, the value proposition for participants on both the demand and supply sides and other actors required to successfully complete the transaction. Relevant factors (e.g. literacy) and transactional supports (e.g. payment systems) will be identified for each chain.

Community Currency

Position paper that sets out the main points of the argument.

More in-depth report to begin the contextualization of the research (literature + original) to P4A’s themes and requirements; do in collaboration with suitable project partners.


37


Sustainability framework for P4A by Feb 2016, also co-authored. This could include a possible public-private socio-economic model, i.e. what would normally be called a ‘business model’ but becomes a ‘socio-economic model’ if the public sector is also involved.

A governance model, mapping the stakeholders and governance processes to achieve long-term sustainability and growth of the P4A methodology/approach.

7.1.2 Design Modeling (IDRC)

• Provide the user experience design criteria required by SP2 and SP3. In contrast to WP101, WP102 will help to design the variety of transactions required, the stakeholders to be recruited and the services to be linked into the infrastructure.

• Synthesize the results of WP101 –WP102 to derive design specifications for the project delineating the necessary services, infrastructure and supports required to enable the growth of the ecosystem.

• Outline initial good practice guidelines for external use.


WP102 will then analyse candidate demand-supply chains to derive user experience design criteria for the project. The models will identify potential workflows and inputs required to successfully link specific demands to the appropriate supply, as well as mechanisms that support feedback, refinement and resulting correction or adjustment. This activity will identify market-ready services plus other services that require further inputs (e.g. incubation, investment, training) to reach maturation. The models will also be used to identify factors that result in the greatest impact. These models will include all stages (e.g. search for supplier) and representative stakeholder groups in a demand-supply transaction, including third party funders and professionals, such as healthcare staff.

The modeling and analysis will address questions critical to recruiting appropriate stakeholders, and supporting necessary interactions.

A variety of scenarios will be modeled, stakeholder input will be sought and data gathered to address these and other relevant questions. Responses to these questions will be used to derive design criteria for the infrastructure and user experience to be delivered by P4A.

T102.3 Develop High-Level Requirements for P4A

The partners will aggregate and synthesize data gathered from the analysis of demand-supply chains and the responses to research questions outlined in T102.3 to develop specifications that take into account the required roles, value propositions for all participants, required functionality, necessary supportive functions and interactions. These will be compiled to create requirements for user experience design, supportive network functions, infrastructure design, and sustainability strategies.


38


WP103

The challenge of WP103 is twofold: a) translation, and cross-disciplinary communication of design criteria derived from economic modelling and user-centric design, and b) continuous iterative refinement of business models based on evaluation findings from WP405.

P4A incorporates economists, designers, developers, clinicians, users, public policy experts and private sector companies. Each partner brings a different perspective, a different vocabulary and different processes and approaches. All parties must work in concert and have a common understanding of design goals and priorities. This ambitious project cannot risk working at cross-purpose or misinterpretation of functional requirements. WP103 will act as a bridge between business/economics experts and participatory designers working on WP101 and 102, and designers, developers and implementers working on SP2 and SP3. WP103 will carefully synthesize and translate the findings of economic modelling and transaction modelling into specifications and descriptions that can be understood and acted upon by technical teams in the project.

7.1.3 Architecture (IDRC)

• Identify and review the requirements for scaling multiple individualized transactions in a cloud-based services environment.

• Identify evaluation criteria based on determinants of a prosperous and sustainable marketplace for use in WP 405.


The modeling and analysis will address questions critical to recruiting appropriate stakeholders, and supporting necessary interactions. These question include but are not limited to:

• what supports do producers/suppliers need to deliver products and services that meet consumer needs?

• what is the impact and optimal integration of intellectual property protection?

WP103

This WP will also leverage the expertise of our Advisory Board on international copyright issues, liability and other legal issues relevant to the Prosperity4All ecosystem that need to be taken into account.

7.1.4 Shared Responsibility (JIBS and IDRC)

Design/Economic


39


Identify the requirements for initiating and concluding a transaction in the P4A framework. This could include, but need not be limited to, finding the service, contracting for the service, completing the service, providing payment and quality feedback.

Architecture/Economic/Design

Identify good practice guidelines for internal project use as they pertain to business practices, infrastructure design and user experience design for required transactions.

7.2 D103.2 Final iterative design framework and solid final wireframes

7.2.1 Design Modeling (IDRC)

T103.2 Final review of specifications

This task reviews the specifications alongside the protection of consumer privacy, ensuring that the services supplied are affordable, enabling producers and suppliers to create viable businesses, encouraging innovation, supporting diversification of the range of users and products, facilitating transparent feedback loops and supporting continuous renewal and organic growth of the platform. Representative stakeholders and partners within the project and our network of collaborators and project Advisory Board will participate in the review. It is understood that the proposed ecosystem/marketplace will be dynamic and evolving. This requires flexible, responsive and adaptive processes, applications and infrastructure that can expand to accommodate and integrate as yet unknown stakeholders, demands, suppliers and transactions. This requires a departure from traditional requirements management as well as a different approach to design and development. To guard against insular thinking experts and potential users new to the project and the process will be invited to provide input as well.

7.3 All Updates

7.3.1 Shared Responsibility (JIBS and IDRC)

Architecture/Economic/Design

T103.1 Requirements, success criteria and associated technical specifications

T103.1 will gather, filter, prioritize, synthesize and organize the findings of WP 101 and WP102, carefully pairing the findings with associated user experience and technical specifications. Functional specifications for the overall infrastructure or architecture will be drafted incorporating input from economic experts, end users/stakeholders as well as designers and developers. Transparent and usable online reference documents will be


40


created that provide several required perspectives on the overall design criteria for infrastructure, user experience design, applications, processes and services. These will be living documents with provisions for broad input and feedback. The documents will include glossaries, explanatory text and illustrative examples to ensure that there is a common understanding of the requirements.

The partners will then iteratively refine the multiperspectival requirements and specification document developed in T103.1 taking into account evaluation results and feedback from WP405. Results of WP405 will be used to revise the modeling tools developed in WP 101 and 102 and gather new data regarding impact, infrastructure requirements and transaction supports required. The findings of this revised modeling will be used to refine the requirements and specifications document.


41
