Goals of the Challenge

This page aims to help you understand the goals of the Challenge - what they are and what they are not.

Learning Objectives

The Challenge is comprised of two parts: an online course (with some live, guided activities), and a practical project component. 

The most important learning objective of the challenge, before all others is this: Students will be able practice caring for people in their communities, to understand their values, lives, and goals, with special consideration for the challenges they face due to disabilities.

Everything else is secondary, including everything around engineering, product design, interviews, design reviews, etc. Everything that follows is in support of the primary learning objective.

The secondary learning objectives are as follows:

Introduction - Disability, Assistive Technology, and Co-Design

• Describe the medical and social models of disability, and how they compare and contrast.

• Describe the properties of assistive technology, and some difficulties faced by engineers and designers in this field.

• Provide examples of assistive technology products and their use cases.

Design Processes

• Describe the co-design process and compare and contrast it with other product design processes.

• Describe the product design cycle.

• Plan, conduct, and review a user interview to extract user needs and product specifications.

• Develop a product test plan, utilizing quantitative and qualitative feedback where appropriate.

Maker Skills

Maker Skills is an extremely broad category of engineering and design skills that may be helpful for your students' projects. This section is provided more as a set of resources than as a formal educational curriculum.

Project

• Brainstorm and document initial product directions.

• Downselect potential ideas based on factors of safety, time, and cost.

• Incorporate co-designer feedback and risk mitigation concerns into successive prototype iterations. (See below for co-designer role definition.)

• Give an oral presentation of the results of your design process to peers and staff in a formal setting, utilizing appropriate language, visuals, and presentation flow to convey your ideas.

• Document your product designs in such a way that addresses how the product will be used, how it is appropriate for your co-designer, and how it might be replicated by others.

Non-Objectives

Here's what the Challenge is not particularly about. Some of these items that might happen along the way, but are not goals of the Challenge. If you are specifically aiming for any of these objectives as your primary targets, the Challenge may not be for you.

• Beating other teams (we purposely have minimal competitive elements; you should be looking to help other teams during this process, the most "competition-focused" teams we have had in the past have often not done well)

• Adding a line to your resume (this will probably happen anyway, but the Challenge is too much effort for just something like this)

• Winning a prize from MIT (we give out very few prizes, and they are typically just laser-engraved acrylic plaques; in complete seriousness, your prize in the Challenge is solving your co-designer's problem)

• Launching your startup (we do not evaluate the scalability or marketability of your solution; please focus your solution on your co-designer)

Project Expectations

Student projects during the spring semester of the CRE[AT]E Challenge can vary widely, from pure software to pure hardware, and wearables to adaptive furniture, we've seen quite a variety. In general, we expect the following:

• The CRE[AT]E timeline allows for roughly two and a half iterations of the design cycle (lo-fi iteration, hi-fi iteration, and small tweaks before the final event). Specific instances may vary.

• Projects presented at the final event do not have to be finished projects, but they should also not just be ideas and sketches. Some kind of prototype (e.g. physical product, running code, etc) must be present. The Challenge is not a pitch competition.

• Projects should be entirely (or nearly entirely) new at the beginning of the Challenge. This property helps students take advantage of the user understanding phase of the course. As a general rule of thumb, if a project has more than about two weeks' worth of serious work behind it before the Challenge, it is probably too mature.

• Projects do not have to be entirely new inventions. If a product exists out there but needs to be adapted to the co-designer, whether by modification of features or reduction of cost, then a project can tackle this kind of idea. Many assistive technologies exist, but are unaffordable, so making a cost-effective version is an important part of accessibility!

• Projects should not tackle safety-critical activities. If product failure during intended use leads to a significant risk of injury to the user, the project should not be considered for the CRE[AT]E Challenge.

Challenge Roles

Co-Designer

The co-designer is the heart of the project component of the Challenge. The co-designer is often a person with a disability who presents a specific problem to the team to work on together. Sometimes, co-designers are the parents, caretakers, or others working with people with disabilities who may be bringing up the problem. They are integral to the design and testing process. Co-designers must be actual people - not an abstract "class" of people (e.g. "Tony, who lives at 123 Elm Street, and is legally blind" is a co-designer. "People who are legally blind" are not co-designers). If a project could have reasonably been done without the co-designer, then it is not well-suited as a CRE[AT]E project.

Student

Students form the bulk of the CRE[AT]E teams, and drive the design and engineering process. They should be taking the course in parallel with developing the product. Students on a team should be able to physically co-locate with each other and with the co-designer whenever possible, though they do not all have to come from the same school.

Coach

Coaches are adults who are local to the student teams and take on primary responsibility for each team. They are responsible for making sure that teams are on track for the course and the project, and for any safety, logistics, and financial considerations that come up during Challenge. They are the primary point of contact for CRE[AT]E staff. Coaches may also deliver some course content to students when provided as guided, in-person exercises. Coaches are often teachers, but are not required to be.

Technical Mentor

Mentors (or Technical Mentors) are non-local adults who provide feedback and assistance to multiple teams, and communicate with CRE[AT]E staff about team progress. They provide expertise in one or more engineering and/or design disciplines to supplement coach expertise. Mentors are matched with teams in the late fall or early spring semester based on teams' projected needs, and meet with teams to decide how they will work together (meeting cadence, communication, etc). For working with teams directly, our rough expectation is that mentors are meeting with their teams about one or twice a month from January to April, and correspond with teams asynchronously (~3 hours per month per team if meeting twice a month). More mentorship time will likely be required leading up to the design reviews. Mentors are also responsible for helping review submitted Design Review videos from teams.

Staff

Staff run the Challenge logistics, course development, Challenge community, fundraising, etc.