D102.1 Map of Modelling Methods and Approach...D102.1 Map of Modelling Methods and Approach . Project Acronym . Prosperity4All . Grant Agreement number . ... process used in SP1, where

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 Final Dissemination Level Consortium

Delivery Date 07/08/2015 Number of Pages 38

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

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

9 03/07/2015 Stolarick, Mitchell JIBS/IDRC Addition of Figure 2 and Section 2.3.4 to clarify Models being created, tools being used to create them, approach to using the tools, and the value to the various SPs in the project. Restructured document to clarify delivery of models from SP1 for use across the project with a focus on the 3 models being created.

10 06/07/2015 Jess Mitchell IDRC Final for submission

http://www.prosperity4all.eu/


Table of Contents

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

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

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

2 An Inclusive Design Process ....................................................................................... 5

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

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

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

3 Building the Models: Design in SP1 ............................................................................ 7

3.1 Models (Infrastructure, User, and Economic Models) .................................................. 9

3.1.1 Infrastructure Model ............................................................................................... 9

3.1.2 User Model ............................................................................................................ 13

3.1.3 Economic and Market Models .............................................................................. 17

3.1.4 Chart of models, goals, and tools: a summary ...................................................... 27

4 Communication/Coordination Plan...........................................................................30

4.1 Mailing list .................................................................................................................... 30

4.1.1 Related research projects ..................................................................................... 32

5 Co-design process .....................................................................................................33

5.1 Creating the Conditions for Innovation ....................................................................... 34

6 Appendix A ..............................................................................................................36

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



List of Tables

Table 1: Proposed Actor Hierarchy .......................................................................................... 21

Table 2: Payment Systems and Approaches ............................................................................ 23

Table 3: Payment System Complexity and Anonymity ............................................................ 24

Table 4: Models, Design Tools, Approach, and Value .............................................................. 29

Table 5: Project Plan/Milestones (next 6 months) .................................................................. 36

List of Figures

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

Figure 2: Design Models, Components, and the SPs they most strongly link to ....................... 8

Figure 3: An example mindmap showing "Value Proposition Clustering" as a complex and overlapping concept mapped to prosposed functionality in P4A ............................. 11

Figure 4: 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. .......................................................................................... 12

Figure 5: Sample use case developed for P4A where assumptions, functions, and nuggets for innovation are presented ........................................................................................... 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. ........ 16

Figure 7: A sample of an environmental scan conducted within Prosperity4All ..................... 19

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. . 31



1

Executive Summary

The following document describes the schedule for the remaining SP1 deliverables in the Prosperity4All project, provides an explanation of the design models being created 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 models satisfying the SP1 requirements. The models that are being created are an Infrastructure Model, a User Model, and an Economic and Markets Model. The Infrastructure Model that will contain mindmaps and wireframes that show points of entry for end users, flow through the interface, and interrelationships among the various components in development in SP2 and SP3. The User Model will be made up of a number of use cases, visual representations of users’ needs using user states and contexts, as well as user feedback from iterative and frequent testing. The packaging of these design artefacts into a User Model will help the Prosperity4All team keep the full diversity of users in mind while building and designing the platform. It will help the team understand and work from the perspective of real users with real needs, measuring success against the platform’s ability to meet those needs. The Economic and Markets Model is a packaging of environmental scans into what exists plus some ideas for how the platform could support innovations within business models, payment systems, and stakeholder interactions.



2

1 Remaining SP1 Deliverables

1.1 Delivery Schedule

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



3

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) will be written concurrently. 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 (associated directly with WP 201 System Architecture and Unified-Listing/Marketplace and with WP 303 Assistance on Demand Service)

2. Business/Market Models (broadly relevant to SP2, SP3, SP4, and SP5 as well as specifically to WP 206 Sustainable Meaningful Consumers-Developer Connections (Pull vs RTD Push))

3. Unified Listing (Finding) (associated directly with WP 201 System Architecture and Unified-Listing/Marketplace)

4. Assistance on Demand (associated directly with WP 205 Assistance on Demand Services Infrastructure and WP 303 Assistance on Demand)

5. Trust, Feedback, Sustainability, Recognition (relevant to the entire platform and especially to WP 205 Assistance on Demand Services Infrastructure and WP 303 Assistance on Demand as well as WP 302 Education eLearning, Business and Employment)

6. Developer Space & Developer Market (associated directly with WP 201 System Architecture and Unified-Listing/Marketplace and WP 203 Collaborative Development Tools/Environments)

7. Education, Training, Capacity Building, Gamification (associated directly with WP 201 System Architecture and Unified-Listing/Marketplace and WP 502 Dissemination and Training)

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



4

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 deliverables D102.2 and D103.1 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 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.



5

2 An Inclusive Design Process

The following section describes the process being used in the delivery of SP1 models 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.

Prosperity4all is adopting an inclusive design process to address the needs of a diverse population and at the same time create an infrastructure that allows for innovation. Prosperity4All will enable a new ecosystem and marketplace to grow – one that encourages collaboration, reduces redundant development, lowers costs, increases market reach internationally, and addresses diverse and currently unmet needs. The goal is for this new infrastructure to create an opportunity for yet unrealized technical innovations that lower the bar for participation in development, promote accessibility as a ubiquitous service, and integrate auto-configured features that lower the barrier to access and use mainstream products. To accomplish those goals, the project needs to take an approach that encourages openness (of process and of end-product), one that reflects on diverse and unique use cases, and one that embraces a realization of a platform that meets the end-user’s needs.

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

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



6

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.

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 – a requirement for the Prosperity4All platform. This shift in perspective 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.

By sharing this shift in perspective alongside the various models being developed, SP1 is equipping the Prosperity4All team with the design foundations to make a system that is highly usable, adaptable to diverse user needs and goals, and that allows for growth and innovation prompted by unique uses.

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.



7

3 Building the Models: 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. On such a large, complex project, one of the only ways to ensure the entire team is in sync is to iterate often, building in many opportunities for input and feedback.

The artefacts that result from SP1 design activities will include:

• Infrastructure Models o mindmaps showing the breadth and depth of interactions, entry points, etc; o wireframes;

• User Models o use cases of realistic users of the system; o user states and context maps (described below); o user input and testing; and

• Economic Models o an environmental scan or competitive analysis of existing, related systems.

The figure below shows the relationships among the various models, the primary components of Prosperity4All, and the subprojects. All models will be created for all of the identified components. However, the models for a specific component may be more useful to a specific subproject. For example, the modeling for all three kinds of models on Trust, Feedback, Sustainability and Recognition will be most important for SP4 (Validation and Evaluation). The connections among components and subprojects that are shown are the most important ones. All models and all components will have some value for all subprojects (as indicated in the chart on the next page). This figure focuses on the strongest connections.



8

Figure 2: Design Models, Components, and the SPs they most strongly link to

Go to section 2.3.3 to see how the modeling discussed here links to the specific objectives and subprojects of Prosperity4All.



9

3.1 Models (Infrastructure, User, and Economic Models)

SP1 is producing various models described above to help the rest of the Prosperity4All team develop, design, and evaluate the overall work of the project. Below is an explanation of the Infrastructure, User, and Economic Models.

3.1.1 Infrastructure Model

The Infrastructure Model will provide an overall map or picture of the Prosperity4All platform: how the various component parts being developed in SP2 and SP3 are related and connected and how the system works for end users (from point of entry, to flow, to accomplishing tasks, to discovering features, and more). This model is made up of a number of design artefacts, namely, mindmaps and wireframes. These artefacts will serve as a guide to developers across the project – providing an overall map or vision for the platform plus providing tangible wireframes for the various components shown in Figure 1 throughout their creation and maturation.

The creation of the infrastructure model begins by examining the breadth and depth of the context and problem. As this research continues, patterns or opportunities for simplifying the problem space might emerge. For example, two types of actors might have similar entry points within a common component 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. Two tools that are particularly useful during the exploration phase are mindmaps and early wireframes. Both help to see the problem space holistically and from multiple perspectives. Once a mapping of the landscape has been clarified, design wireframes help participants imagine something real to then iterate on collaboratively.

3.1.1.1 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.

Sketching out these mindmaps allows the design team and the various SP teams to begin to visualize interface flows and to identify open questions related to workflow of the tools. A mindmap for the Developer Space, for



10

example, might enumerate the various points of entry for a number of hypothetical developer end-users. There might be developers interested in finding help or developers interested in providing help. Mapping out their points of entry, their goals, and their paths through the system will help the development team conceptualize how to architect a system to meet their needs, to do so in a highly usable way, and to build in flexibility for ways the developer community might adapt the system to their needs. Mind-maps serve as pre-wireframes in this way – they map abstractly rather than attempt to show interaction designs which come later in the design process.

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.



11

Figure 3: An example mindmap showing "Value Proposition Clustering" as a complex and overlapping concept mapped to prosposed functionality in P4A

3.1.1.2 Wireframes

Building on the early mindmapping of various actors in the Prosperity4All system, 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 use cases like those described below), and slowly moves toward user interface designs and flows.



12

Figure 4: 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.

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.

Together, mindmaps and wireframes will make up the Infrastructure Model that SP1 is developing for the rest of the Prosperity4All team to use. The Infrastructure Model will help facilitate conversations across the various SPs, keeping the project in sync and moving forward with a common overall vision. The mindmaps and



13

wireframes will further help the various SPs consider the breadth and depth of the landscape while developing.

In addition to the Infrastructure Model, SP1 is designing a User Model that is made up of use cases, user states and contexts, and user testing. All of these design tools help further evolve the wireframe designs and development across the project by grounding the work with increasing levels of specificity for user interactions, affordances, and user interface flow.

3.1.2 User Model

The User Model will help ensure that the Prosperity4All team is keeping in mind a range of diverse users. By packaging use cases, user states and contexts, and user testing SP1 will deliver a user model that developers and evaluators in the various SPs can use to understand the scope, uses, and success criteria of their deliverables. This will help the team validate their efforts and keep the larger project in alignment with respect to inclusion and diversity and accessibility. The user model will also help the team anticipate weaknesses in the architecting and development of the platform – if the system cannot meet the needs of diverse users, then the team will be able to address the limitations early.

3.1.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.

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 real 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 needs4,5.

4 Treviranus, Jutta (January/February 2014). The Value of the Statistically Insignificant. Educause Review. Retrieved from http://www.educause.edu/ero/article/value-statistically-insignificant 5 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



14

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.

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



15

3.1.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 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.” 6

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. The insights gained from this tool further reinforce the perspective shift of inclusive design, inspiring development solutions that meet diverse needs rather than just “common” needs. With visual outputs from user states and contexts, it is difficult to hold onto a notion of a “common” need since even an imagined “common” user will have a complex constellation representing their movement through time, to different devices, and within different contexts.

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



16

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.

3.1.2.3 User Testing

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 is 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.



17

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.7 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 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).

3.1.3 Economic and Market Models

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 Cloud4All8, the FLOE Project9, Preferences for Global Access10, Project Outside-In11, 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

7 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/ 8 http://cloud4all.info 9 http://floeproject.org 10 http://wiki.fluidproject.org/display/fluid/Preferences+for+Global+Access 11 http://outside-in.idrc.ocadu.ca/



18

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.

3.1.3.1 Environmental Scan

Early research into what already exists in the domain area helps contextualize and inform new work. 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.



19

Figure 7: A sample of an environmental scan conducted within Prosperity4All12

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.

3.1.3.2 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:

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



20

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 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.



21

3.1.3.3 Prosperity4All - Actor Hierarchy

Table 1: 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



22

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.



23

• 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 2: 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:



24

Table 3: 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

3.1.3.4 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.



25

For each of these, the following will need to be done:

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

3.1.3.5 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?



26

• what are potential threats or risks to successful completion of transactions and how can these be addressed?

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?

3.1.3.6 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.)

3.1.3.7 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.



27

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 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.

3.1.4 Chart of models, goals, and tools: a summary

Below is a chart that pairs the various models to be created, the design tools to be used in creating those models, the approach to be taken using that tool, and the value of the models/design tools for the other Prosperity4All subprojects. The tools help the design team create the models that live as the project archive after the work is done. The values identified show the utility provided by the models and tools for the subprojects.



28

Models Design Tools Tool Approach Value for Other Subprojects

Infrastructure

-Entry Points

-Interaction Flows

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

Encompass entirety of infrastructure space

Reveal and document complexity

Show relationships among pieces

Specify design goals and approaches

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

User

-Users

-Stakeholders

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.

Understand range of users

Document usability and accessibility needs

Identify opportunities for new products and services

User States and Contexts

Search for cross-cutting patterns (i.e. digital curb-cuts).

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.



29

Economic

-Business Model

-Payment Systems

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.

Present business model and payment options

Provide recommendations

Identify tradeoffs

Document limitations

Table 4: Models, Design Tools, Approach, and Value



30

4 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.

4.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.13 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.

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


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


31

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.



32

4.1.1 Related research projects

The work on Prosperity4All is additionally informed by work on a number of other active projects that bear a direct impact on both the process and outcomes of Prosperity4All. Each of these projects has substantial representation from the SP1 Prosperity4All team.

4.1.1.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.

4.1.1.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.

4.1.1.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.


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

http://www.cloud4all.info/

http://www.floeproject.org/


33

5 Co-design process

The SP1 design effort will be based on a co-design process14 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

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



34

This co-design process will be paired with an Inclusive Design approach15 (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.161718 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.

5.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 happen19. These include:

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

15 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

16 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.

17 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).

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



35

• 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.



36

6 Appendix A

6.1 Detailed Project Plan/Milestones (next 6 months)

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

Description Responsible 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



37

Description Responsible 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 Deliverables JIBS 28-Aug



38
