Inclusive Models

The infrastructure teams are asked to explore their practices and assumptions, note where they are falling into the ruts or misconceptions outlined in the misconceptions table below, and explore the design and economic models from SP1 to adapt their processes to achieve greater inclusion. A key part of the SP1 models is a loop of continuous feedback that leads to refinement of the models to ensure they better address the needs of the infrastructure teams while solving complex problems for unique users.

• Economic and Ecosystem Model Analysis
• Design Kit

1. Use Model
2. Design Guide
3. global and component specifications

Overview of SP1 Work

The main objective of this page is to provide the infrastructure teams with a brief and clear description of the SP1 design and economic models and their applications. The diagram bellow moves from Conceptual to Practical work on a continuum presenting a number of outputs from SP1. It is meant to help people understand the conceptual framework the team worked on (as presented in a misconceptions table minified here), then moves to a big picture image that shows the infrastructure enabling an ecosystem in minified version, followed by a minified version of a UML diagram, next showing the economic and use model tools produced by SP1, and finally showing the evaluation work that represents D404.1 and D404.2 on the practical end.

• 

  SP1 items

Complex System Framework

The ‘Misconceptions’ table contrasts the typical approaches (in various domains) that have failed with new ways of thinking and doing that are driving the paradigm shift needed for making the vision of P4A possible.

• 

  Misconceptions Table

Domain	Old Way of Thinking/Doing : Misconceptions & Ruts	New way of Thinking/Doing : Paradigm Shift	Moving from Old to New: Probing our Assumptions and Practices	Tools and Methods
Development & Design	Isolated (stand alone functions) work packages that snap together when completed	Require responsive system in quickly changing context with undefined and expanding scope Functions are entangled and interdependent Need built-in ability to incorporate early trial, error and feedback by users and iteratively respond to this Be flexible and porous Create conditions for growth, new uses and connections	How diverse is our team composition? How open are we towards changing and iterating our work particularly for the ones that seem to be at a final phase of development? How often do we consult and communicate with other teams in the larger P4A project? How do we involve end users in our design and development process? How do we prepare for unpredictable uses?	See the Global Design Specifications
Project Management	The roadmap can be predicted and controlled We can know the problem and create a solution Can be solved in a standard, linear manner We can control this and predict requirements There is an end point when the project is complete and we have succeeded	This is a complex project and so adopting a ‘complex project management’ approach is appropriate (inspired by system of systems) require ongoing transparent communication Emergent systems cannot be *known* and planned in the same way “Success” continues to evolve and change	How often do we revisit our requirement list to ensure it is still relevant to user needs and context? How flexible are we in changing direction and redefining our goals? How do we ensure our project’s output remains flexible overtime?	D404.1 for more information
Users	Working from deficit model of disabilities We can create persona categories that represent most of the possible end users - they have static needs The only end users are people with disabilities	The system is built from a perspective of inclusion and one-size-fits-one This ecosystem is built to empower users and break down barriers to access -- regardless of user ability or disability Personae are meant to help model the range of behaviours, not represent full demographics of complex and unique people	How did we identify who our users are? How did we ensure users at the margin could use our product/services? Which problems are we trying to solve for our users? How does our product stand out in solving those problems? How are we planning to integrate user feedback in our work?	See Use Model
Design	Inclusive design isn’t necessary or important -- it’s the touchy/feely stuff	Inclusive Design is design that is built upon common design practices with additional principles, practices, and tools used for the benefit of all end-users. It’s better design. We are designing for diversity, inclusive design is needed to design for diversity not the mass	How do we enable users to easier see, hear, understand and interact with our product/service? How do we make it easier for users to access our product/service on different devices and platforms? How do we help users to easier adapt our product/service and maintain it? How do we make sure our product and service is relevant to user’s context and their available local resources? How do we enable users to make an informed decision when selecting our product/service?	See Inclusive Design Guides
Economic	Accommodations represent all new costs, but not investments Prosperity is monolithic	We need “full social costing” showing macro and long-term impact of investment Prosperity is not just measured as “more money in my pocket” Prosperity should happen (and be measured) at the “micro” and “macro” levels Costing models need to incorporate collective costs taking into account sharing and collective production	What are the contextual factors that impact our product/service? How can we use these factors in our benefit? Besides our intended audience, who else can benefit from our product/service?	See economic and ecosystem model analysis
Timing	Emergence is a quick process - just a state change not an evolving one	Emergence will happen through use and feedback and adjustments	How do we enable users to connect to other stakeholders across the P4A ecosystem? How do we enable other teams and stakeholders in the P4A ecosystem to access and adapt our product/service?
Architectural	We can engineer a fix - technology can solve it all and we are smart people who know what is best	The engineers are not the only ones building this system -- it is designed to encourage feedback and adapt and grow based on end-user feedback and use We are dependent on all users/stakeholders from the demand to supply side of the system for the solutions and guidance for iterative refinement This needs to be self-healing, self-correcting, and self-refining	How do we enable users to provide us with feedback? How are we planning on collecting and integrating user feedback in our work? How are we planning on communicating our project’s updates and new features with end users?
Market	The sustainable business model is just “details” that someone else can work out There can just be one business model that will work	Business model is more than just payment systems Solutions need to adapt to users and user context and evolve over time	How did we identify which business model works best for our project? How does this business model enable users to access our product/service and adapt it? What are our projected revenue streams? What are our expected costs? How could we increase profit? How could we lower cost? How could we increase market size/share?	See economic and ecosystem model analysis

Infrastructure Enabling an Ecosystem

• 

  Big Picture Diagram

The diagram above shows the tools that SP1 is delivering for the various infrastructure teams to use as they build the component parts of the P4A. These tools help ensure the project achieves its overall vision as stated above. The Design Kit and Economic Model contain the initial information the infrastructure teams will need to create an inclusive infrastructure that can serve as the backbone to an inclusive ecosystem. The Design Kit includes a Use Model, global and component specifications, and Inclusive Design Guides. The Economic Model contains a business model and payment system analysis. The infrastructure teams are asked to both use and help refine these models as they gain experience and provide feedback on their efficacy and use. The models have been created from within the current context in Europe: namely the combination of the 4 areas earmarked in the EU’s Disability Strategy Goals and the ever-changing ‘verticals of complexity’ that make up Europe, markets, and technology. The SP1 team’s hope is that the various infrastructure teams will keep this larger context in mind and think beyond what is defined as disability and instead focus on breaking down the barriers in each of these four areas while they use the SP1 models to design and develop technologies, and provide feedback. With this feedback loop, SP1 can effectively refine the models to best reflect the needs and contexts of users of P4A while helping the infrastructure teams fulfill those needs with ever-changing complexity.

Functional Views

Below is a UML activity diagram that shows with increasing detail the path within an inclusive ecosystem of a user who has made a request, interacts with the P4A infrastructure, and ultimately is delivered a matching good or service. The figures are shown stepwise from the most fundamental function of making an initial request to a full activity diagram for Handling a Request and Delivering a Match, which shows all of the various functions at work within the ecosystem. The point of this diagram is to show function, not to determine who a ‘user’ is or what a ‘match’ looks like. We do not know all of the eventual end-users or eventual matches that the Prosperity4All ecosystem will support. We are building an infrastructure to support an inclusive ecosystem that will adapt, grow, emerge, flex, and accommodate diverse and unpredictable use cases and yet unknown users. The UML diagram shows a porous yet complete pipeline of functions that will support this emergence, growth, and change – porous because it is flexible enough to accommodate the unknown and complete because of the fundamental function of providing a match to a request.

Making an Initial Request

• 

  Making the initial request

This step shows the most fundamental function of the ecosystem: for a user to make a request and for a match to be delivered. Here ‘user’ should be understood broadly (refer to Use Model) and the “match” should also be understood broadly to represent a need, service, or solution. A match can be fully automated, delivered by a person or any combination along that continuum. For the purpose of a simple example: A policymaker (user) could enter the system looking (makes a request) for some indication of patterns of unmet needs in the marketplace. The delivery of those metrics would constitute a (match). A developer (user) could enter the system looking for resources (makes a request) to help her put a project team together. The matching of that developer with others who are interested in participating in her project constitutes a (match).

Making a Well-Formed Request

• 

  Making a well-formed request

A user will make a request and then interact with interfaces and tools that will help her refine that request further. This refinement might happen intentionally (how can I express what I really want?) or might happen as a result of interacting with various tools’ interfaces (fill in the fields to submit your request or enter your project). A request is "well-formed" when it contains complete and accurate information about the user's goal (what needs to be done?), preferences (what is the best way for me to do it?) and context (what factors influence this?)

Addressing the Request

• 

  Addressing the request

The infrastructure handles the request by delivering a match. In some cases a match is not found (which then triggers a request to fill a gap). In other cases either a partial match is found (which provides an opportunity for the match to be adapted), or a direct match is found and delivered.

Addressing the Gap

• 

  Addressing the gap

If a match is not found, a process is triggered to fill that gap. Filling a gap requires recruiting, training and supporting suppliers who could fill that gap and help delivering the required match. The ecosystem will grow and adapt to evolving uses and requests as gaps are filled and the network of suppliers expands.

Feedback

• 

  Feedback

Once a candidate match (either partial or direct) is delivered, a mechanism that is built into this ecosystem will allow users to evaluate the delivered match. This evaluation will be delivered to the suppliers who contributed to the match. It will also be delivered to the P4A infrastructure to help refine the services and tools that enable users make well-formed requests – to further grow, refine, and adapt the system and the matches to meet the needs of diverse users and use cases – to diversify.

P4A Activity Diagram

• 

  P4A Full Activity Diagram

This image shows the full activity diagram for Handling a Request and Delivering a Match, which shows all of the various steps above at work within the ecosystem.

Tools

The infrastructure teams are asked to both use and help refine these models as they gain experience and provide feedback on their efficacy and use.The tools provided by SP1 consist of:

• business model and payment system analysis
• Use Model
• Inclusive Design Guide
• global and component specifications

Return to Main Page - Item#12