In this section we will step through an example of how to iteratively prototype towards a solution.
prototype: a model that a design team builds of a solution to test and validate ideas quickly
To do this we will be going back to the example of the arm holder for Kenzie, the child with cerebral palsy. In this scenario, Kenzie and her mom are the co-designers and you (and the AT course staff) are the design team creating this device.
Through the activities in this module, you will work through the design process and learn how to make decisions during prototyping quickly and cheaply towards the best solution.
You are a part of a team that has this mission statement:
"To design and build a mobile arm support for children and adults with cerebral palsy that will aid in arm mobilization when working on everyday movements in therapy; specifically eating and writing."
The team did some benchmarking during the concept generation phase. Some of those results are here.
The first system researched was the Medifab Dynamic Arm Support. The team discussed the pros of this product including its advantages of user-friendly clamp, flexibility in movement, and the simple height adjustment. The major disadvantages include its unwieldy size as well as a lack of tension adjustment. Lastly, it is expensive and difficult to purchase.
The second system researched was the Armon Edero which has key elements required by the co-designer, including a clamping mechanism compatible with table and chairs, portability, and all the required axes of rotation with adjustable tension at the joints. The pitfalls of this product include its expense, appearance, and overall safety of moving joints for young users.
The team did a survey with therapists and parents of potential patients who may be interested in the project to gain a better understanding of how the product will be used in the future.
The team learned these things from the surveys:
More extensive interviewing and testing was also done until all customer needs were understood by the design team. The next step is to turn these needs into requirements.
These requirements are written in technical engineering terms. The terminology may be unfamiliar, but the point of sharing these is to give an example of what real requirements would look like.
Here are some of the requirements the team defines for the product:
Given the requirements made from customer (or co-designer) needs and a rigorous selection process, the concept selected was a ball joint based system with a product breakdown shown here. This shows the components of the system and how they are connected. Level 1 is the entire system. Level 2 and 3 break the system down into the individual components.