P17005: Assistive Tablet Case
/public/

Problem Definition

Table of Contents

Problem Definition

Tablets are often used as modes of Augmentative and Alternative Communication (AAC) with the help of type-to-speech and picture-to-speech applications. Commercial tablets, as they are currently produced, are not equipped to meet the needs of individuals with gross motor difficulties or Sensory Processing Disorder. Therefore, for individuals on the Autism spectrum with these coupled conditions, an assistive tablet case is necessary for efficient and effective communication. The main components of this tablet case would be motor skill support system which could potentially include a supportive strap for for gross motor skill assistance and a grid screen overlay to assist with fine motor skills and providing tactile feedback for positional information as well as stability components such as a handle and a table stand that are easy to open or set up, and interchangeable textures incorporated to improve user experience.

The goals of this project are to explore different screen interaction mechanisms and develop a marketable prototype that has been tested for durability and ease of use. The resulting design must not contain electronic components and must be less than 100 square inches in footprint, similar to that of a standard tablet.

Team Vision for Problem Definition Phase

Goals for Phase 1:
  1. Establish Project Management as foundation for moving forward
  2. Define Requirements and Constraints
  3. Specify Target User
  4. Become familiar with project background
  5. Interview Primary Customer

Accomplished:

  1. Requirements
  2. Project Planning Calendar
  3. Risk Assessment (part of the Requirements document)
  4. Initial Function Decomposition

Meeting with customer to be scheduled in the following week.

Project Summary

Our 1-Page Project Summary can be found here.

Use Cases

Target User:
  1. Age: 3-5 years
  2. Diagnosis: Autism and Sensory Processing Disorder (SPD)
  3. Fine Motor Skills: Low
  4. Sensory Processing: Hypersensitive to tactile stimuli
  5. Communication style: Nonverbal

This target user was chosen because the team agreed that early intervention provided the best opportunity for children to find their 'voice' and for encouraging further development.

Project Goals and Key Deliverables

  1. Working Prototype - Manufacturable and Marketable
  2. Test Data - Gathered from thesis project, to prove usability, efficacy, safety, etc.
  3. Documentation - Including Detailed Design Drawings, Schematics, Bill of Materials, etc.
  4. Final Model Rendering - For Communicative Purposes
  5. Process Book - Documentation of Design Process

Customer Requirements

Customer Requirements:

CR01: Contains a stand - to rest tablet upright on table

CR02: Contains a handle - so user can easily hold tablet while using it

CR03: CANCELED - Linear motion when interacting with touchscreen (movement in a grid) - to help user select desired icon

CR04: CANCELED - Quantifiable motion for positional feedback - to help user select desired icon

CR03a: ADDED - Tactile Position Feedback (in place of CR03 and CR04)

CR05: Involve textures - must be replaceable, for better user experience with SPD

CR06: Needs to be simple to open for people with limited motor control

CR07: Support 1 lb weight

CR08: 5 year material life

CR09: Portable

CR10: Provide user upper limb stability

CR11: Positive user experience

Customer Requirements

Customer Requirements

Requirements, Risks, and Features will continue to be updated based on new information from research, tests, interviews, etc. - The live Requirements document can be found here

Results of First Customer Meeting

Our first meeting with our primary customer, Felicia, was not until 9/18/2016 (after Week 4.) This was due to a persistent conflict in schedules and difficulty with email communication. To prevent this in the future, the team has been ending each meeting by scheduling the next one. The first meeting was very helpful for better understanding our users and the unique combination of challenges that this project faces. The full document, in the form of shorthand notes from during the meeting, can be found here.

Key takeaways from this meeting, aside from an understanding of the users' condition, were:

  1. Portability is a major issue- better portability would help sociability.
  2. Another major issue is the user's stability when simultaneously holding and using the tablet. Stability in space is an difficulty in general for the user.
  3. Product must not make the individual stand out as "a person with a disability." They are, after-all, just "a person" who happens to communicate differently from you. The product shouldn't look like a medical device.
  4. As such, the product must also be customizeable, as our cellphone cases are. It should be something they want to use.

Quality (Engineering) Requirements

Purpose

Create a contract between the engineer and the customer where indisputable satisfaction of the engineering requirements equates to customer satisfaction
Quality Requirements

Quality Requirements

Inputs and Source

  1. Customer Requirements
  2. Customer
  3. Phase I benchmarking
  4. Standards, regulations, or other industry guidelines
  5. Selected concept list
  6. System Design
  7. Guide & other stakeholders

Outputs and Destination

  1. Function Decomposition.
  2. Concept Generation & Development.
  3. HoQ.
  4. System & Detail Design.
  5. Test Plans.
  6. Poster & Final Report.

Constraints

- Device: iPad (Most commonly used tablet for this purpose)

- App: Proloquo2Go (Most commonly used app for this purpose)

- Normalcy: Our solution can not further distance the child from peers

- Low Cost: We strive to make this device financially accessible to a wide range of families

House of Quality

Purpose

  1. Confirm that satisfaction of the Engineering and Design Requirements implies that all of the Customer Requirements are met.
  2. Facilitate design trade off decisions

Updated as new information is gathered.

Customer Requirements

Requirements Defined

Requirements Defined

Quality Requirements

Quantitative metrics, tested or simulated
House of Quality

House of Quality

Inputs and Source

  1. Template and Example.
  2. Customer Requirements.
  3. Engineering Requirements.
  4. Benchmarking Data.

Outputs and Destination

Provide input to the risk management process.

Risk Assessment and Management

User

Risks associated with using product

Team

Risks experienced internally

Design

Risks of execution of solution

Risk Assessment

Risk Assessment

Each Risk is given a value for Severity and Likelihood, and these values are multiplied to obtain a Final Value. This Final Value is totaled, and will be tracked over time. The ideal Total is zero, which would suggest we had mitigated all possible risks. Values are to be updated with design changes, test results, etc.

Risks over Time

Risks over Time

This graph shows how the total number of risks, and the value of those risks, has changed over time. With each customer meeting, and with testing and research, requirements and risks are reassessed and updated based on new information. This graph shows those changes. Remember, the end goal is for a Total Value of 0. The number of risks being assessed can go as high as it needs; that just means the team is preparing for any possible risk of the device to the user.

Plans for next phase

Focus: Concepts

Actions: Develop, Model, Analyze, Begin Testing Preparation

Aside: Meet our customer

Further Aside: Develop in-depth detail for Requirements and Cosntraints

Planning Calendar

Planning Calendar

Full calendar can be found here


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