Problem DefinitionTablets 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 PhaseGoals for Phase 1:
- Establish Project Management as foundation for moving forward
- Define Requirements and Constraints
- Specify Target User
- Become familiar with project background
- Interview Primary Customer
- Project Planning Calendar
- Risk Assessment (part of the Requirements document)
- Initial Function Decomposition
Meeting with customer to be scheduled in the following week.
Project SummaryOur 1-Page Project Summary can be found here.
Use CasesTarget User:
- Age: 3-5 years
- Diagnosis: Autism and Sensory Processing Disorder (SPD)
- Fine Motor Skills: Low
- Sensory Processing: Hypersensitive to tactile stimuli
- 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
- Working Prototype - Manufacturable and Marketable
- Test Data - Gathered from thesis project, to prove usability, efficacy, safety, etc.
- Documentation - Including Detailed Design Drawings, Schematics, Bill of Materials, etc.
- Final Model Rendering - For Communicative Purposes
- Process Book - Documentation of Design Process
Customer RequirementsCustomer 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
CR10: Provide user upper limb stability
CR11: Positive user experience
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 MeetingOur 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:
- Portability is a major issue- better portability would help sociability.
- 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.
- 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.
- As such, the product must also be customizeable, as our cellphone cases are. It should be something they want to use.
Quality (Engineering) Requirements
PurposeCreate a contract between the engineer and the customer where indisputable satisfaction of the engineering requirements equates to customer satisfaction
Inputs and Source
- Customer Requirements
- Phase I benchmarking
- Standards, regulations, or other industry guidelines
- Selected concept list
- System Design
- Guide & other stakeholders
Outputs and Destination
- Function Decomposition.
- Concept Generation & Development.
- System & Detail Design.
- Test Plans.
- Poster & Final Report.
- 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
- Confirm that satisfaction of the Engineering and Design Requirements implies that all of the Customer Requirements are met.
- Facilitate design trade off decisions
Updated as new information is gathered.
- Importance Value
- Why requirement is important
- How to tell if requirement has been fulfilled
- "See also" indicates related customer requirements
- "Will comply to" and "Covered by" (see House of Quality)
Quality RequirementsQuantitative metrics, tested or simulated
- Feature that requirement relates to (from Functional Decomposition)
- Target Value
- Details (of testing, test conditions, etc.)
- "Applies to" or "Fulfills" (see House of Quality)
Inputs and Source
- Template and Example.
- Customer Requirements.
- Engineering Requirements.
- Benchmarking Data.
Outputs and DestinationProvide input to the risk management process.
Risk Assessment and Management
Risks associated with using product
Risks experienced internally
Risks of execution of solution
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.
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
Actions: Develop, Model, Analyze, Begin Testing Preparation
Aside: Meet our customer
Further Aside: Develop in-depth detail for Requirements and Cosntraints
Full calendar can be found here