P17005: Assistive Tablet Case
/public/

Systems Design

Table of Contents

New insight during Phase 2 brought about a dramatic change in scope for this project. It was determined that children who use AAC apps are capable of pressing buttons sufficiently, so, with the approval of our customer, the team stopped pursuing the idea of a screen-interaction mechanism. It was determined that the main problem with current AAC devices is the lack of portability, so this became one of our primary focuses instead. This forced us to revise a lot of our Problem Definition documents before we could properly conceptualize, and so set us back a little. The team worked hard to catch up and refine the project requirements in order to steam forward with our concepts.

Team Vision for System-Level Design Phase

Goal from End of Phase 1:

Accomplished:

Functional Decomposition

The Functional Decomposition shows a flow down from the top function by asking the question "How?" It branches down from the top function and becomes more and more specific until the answer to "How?" is a concept.

The Problem: Using assistive communication devices requires access to the device at all times. If the child does not have a method of keeping the device on their person, they do not have a voice.

The Solution: Our device addresses these concerns by augmenting the existing communication device in order to provide easy accessibility, personalization, and protection of the device that one with nonverbal autism needs in order to have voice.

Functional Decomposition

Functional Decomposition

Full document can be found here.

Benchmarking

Purpose

Avoid redundant work by identifying already available solutions and concept options
Benchmarking Chart

Benchmarking Chart

Benchmarking will focus on the Dynavox, a popular, standardized AAC device, and the iAdaptor5, an iPad accessory for AAC apps. This benchmarking helps us develop concepts and then judge them against commercial products.

Inputs and Source

  1. PRP.
  2. Project Objective.
  3. Function Decomposition.
  4. Prior MSD EDGE sites.
  5. Customers.
  6. Vendors and users of existing or similar solutions.
  7. Literature search.
  8. Friends and associates.

Output and Destination

  1. List of best available concepts and embodiments.
  2. Criteria used for selection of best.

Concept Development

Purpose

Generate new concept options or combinations that can potentially exceed the benchmark concepts

Form Exploration

Ideas for the overall shape of the device

Form Exploration

Form Exploration

Feature Development

Ideas for different features, including handles and case
Feature Concepts

Feature Concepts

Carrying Mechanism

Several ideas exist for a carrying mechanism, including a backpack, satchel, belt, and messenger bag archetype
Backpack Concepts

Backpack Concepts

Satchel Concepts

Satchel Concepts

Belt Concepts

Belt Concepts

Messenger Bag Concepts

Messenger Bag Concepts

Input and Source

  1. Function Decomposition.
  2. Results of Benchmarking.
  3. Analysis and prototyping.

Outputs and Destination

List of multiple viable concept options to provide each function.

Feasibility: Prototyping, Analysis, Simulation

Purpose

  1. Confirm that the selected concepts can deliver functionality defined by the System Architecture.
  2. Define the optimal values of the most sensitive design parameters.
  3. Support the evaluation of your team's concepts with quantitative information.

Design Simulations

Testing

Will obtain data regarding form and appearance of device, usability, improved function, and user experience

Stage 1 Testing with neuro-typical college students

Test survey positive for “Ease of Use,” “Would you use this again” etc

Stage 2 Testing with college students/ adults on the Spectrum

Test survey positive for “Ease of Use”
Measured improvement from baseline (change in time per word selected)

Stage 3 Testing with children on the Spectrum

Test survey positive for “Liked Using,” “Looks cool,” etc
Number of instances used without prompting
Measured improvement from baseline (change in time per word selected)
Child doesn’t show frustration with device during testing

Inputs and Source

  1. Engineering Requirements
  2. Concept Selection

Outputs and Destination

  1. A list of Design Parameters, Quantified Targets, and acceptable tolerances
  2. Sensitivity analysis
  3. Concept Selection

Morphological Chart and Concept Selection

Purpose

  1. Develop multiple concept options to deliver the required list of functions.
  2. Ensure that concepts (means) are available to deliver every required function.
  3. Select the optimal set of concepts that can be integrated to meet the project objectives.

Lead Designer, Mick, created amazing sketches based on concepts the team develop through many meetings. He pinned all the drawings on the wall, categorized by function. Upon discussion, the team, including Guides, flagged different concepts based on their reactions.

Green indicated positive remarks, red indicated negative remarks, yellow meant some good and some bad things, and orange indicated neutral comments about a feature.

Analyzing Concepts and Features

Analyzing Concepts and Features

Inputs and Source

  1. Project Objectives.
  2. Engineering Requirements.
  3. Function Decomposition.
  4. Concept Development.
  5. Benchmarking criteria.
  6. System Architecture.

Outputs and Destination

  1. A complete set of concepts that provide all of the functionality required.
  2. Fall back options to substitute for the most risky concepts.

Concept Selection

Concepts were developed based on Requirements, Research, and Benchmarking.
Selecting Concepts

Concepts have been created to cover every function of the final device

Design priorities are as follows:

  1. Carrying and Holding Mechanism
    • These two functions were selected as the most complicated and most important to the success of the project. Our primary focus is to enable the child to take the iPad with them wherever they go and use it standing up in order to broaden the settings in which the child can have a voice.
  2. Table Stand
    • This function is determined to be high risk, so it is priority #2. Risks include the user’s ability to operate the stand, it’s stability against user input, and potential pinch hazards
  3. Screen Overlay
    • There are two main concepts we wish to investigate for this function. One is a grid overlay similar to market items, and the other is a series of silicone buttons. This is important for helping the user better operate the iPad, but is not crucial to the project’s success and poses low risks. This component is therefore only number 3 on our priorities list.
  4. Case and Textures
    • The physical case and the attachment of stimulating textures will be done last, since these pose the least risk to the user. They are also proposed to be the least complicated, and will be developed together to ensure the case and textures work together properly.

Concepts were narrowed down and selected in three stages

  1. Useability: Concepts will be narrowed down first based on the perceived useability for the user
  2. Feasibility: Narrowed down concepts will be subject to initial engineering analysis to determine feasibility of designs. ie. can it be stable enough, are there interfering components, etc.
  3. Risks: The last round of selection will analyze the risks posed by each concept, and will select the concept(s) with the least risk posed to the user, or a justification of why the risk is reasonable or how it will be mitigated in the final design
Combined Concept

Combined Concept

Combined Concept

Combined Concept

Combined Concept

Combined Concept

Combined Concept

Combined Concept

Combined Concept

Combined Concept

Concept has yet to be tested, though it fulfills all requirements for the user.

Systems Architecture

Purpose

  1. Ensure flow of energy, info, material and structural forces as intended.
  2. Define subsystem functions, envelopes and interfaces.
System Architecture

System Architecture

Inputs and Source

  1. Engineering Requirements.
  2. Functional Decomposition.
  3. Concept Development.

Outputs and Destination

  1. High level description of the total system that support concept selection.
  2. Interface definition for subsystem design.

Designs and Flowcharts

Purpose

Define a high-level view of the elements required to build and operate the entire system

Instructions

  1. Instructions and EXAMPLE must be deleted before the next Project Review AND Identify an owner for this document.
  2. This document will be inspected at all project reviews until the system is assembled and debugged.
  3. Identify subsystem interfaces.
  4. Define projected system operation.
  5. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.
  6. Reference: http://edge.rit.edu/edge/P15571/public/Detailed%20Design%20Documents/Data_Flow_Chart_Rev_2_0.pdf
  7. Note: This section should be started during systems design, and continued through detailed design.

Risk Assessment

Risk assessment will be updated based on final concept selected in order to reflect the risks inherent with the specific design (ie pinch hazards, etc.) Risks will also be updated to reflect risks mitigated through design (ie chocking hazard might be reduced if the final concept does not involve small parts.)

Design Review Materials

Include links to:

Plans for next phase

Phase 3 Calendar Plan

Phase 3 Calendar Plan

Update Phase 1

Revisit all user documentation
Benchmark all research
Do additional benchmarking of relatable products
Update styleguide to reflect current brand

Moving Forward

Select Concept(s) for further development (May require additional research or consultations)
Add detail to selected concepts
Complete Online Training for Research with Human Subjects
Submit IRB Paperwork
Start Prototyping
Stage 1 of Testing

Next Phase

Testing
Analyzing Test Data
Revising Concept between each Stage of Testing to optimize
Develop detailed drawings for final test product

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Integrated System Build & Test with Customer Demo | Customer Handoff & Final Project Documentation