2.009 Product Engineering Processes

Results of Technical Review

Team specific comments from David are written on this page, below the section of comments for all teams. Comments from other instrcutors, compiled for each team, are accessible through the "feedback" links below (certs required).

To view a team's prototype and write feedback, click on the links provided below.


climbing wall


communication mask


glove remover


wheelchair umbrella




ice dam breaker


guitar tab writer



General comments
Please read these comments thoroughly! 45 instructors and guests participated in the review.

All teams have shown good progress since the mockup review. The current prototypes have been great platforms for testing, and provide a concrete reference point/architecture from which one can carefully design and detail a product. While some were more refined than others, across all teams the current prototypes are closer to engineering mockups than a designed product. So good progress, and a good reference to design and implement a looks-like, works-like prototype for the final presentation. This is where the jump to being a product, as opposed to the exploration of a concept, needs to take place.

In preparing for the next design review on Monday, and working towards the final presentation, it is now critical to refine and execute your device as a coherent, integrated, elegantly-resolved product, thinking carefully about efficient use of materials, ease of fabrication, cost and user safety, overall form, and human factors (amongst many other things).

Please think about how your current prototype would need to change to be comparable to an existing product that you can already buy. It is often helpful to look at details in related, real products for inspiration at this point in the design process. We are aiming for comparable detailing to what is seen in real products.

If your team has key functional aspects or system integration issues yet to be resolved, it is very important to tackle these problems soon in order to avoid surprises a few days before the final presentation. The core, integrated functionality should be solidly resolved by the Thanksgiving break so that there is time for implementation, planning, testing, and preparation/practice for the final presentation.

Use your current prototype well to test and understand how to resolve challenges. As noted in the lab notes for next week, it is critical to keep things moving and be well on the way to resolving your next design revision before the break.

All teams should aim to have the final prototypes completely ready and available for presentation practice by the Saturday before the final presentation at the very latest. Your team will need to take a split approach during the final weeks, working on the prototype and at the same time designing/preparing materials for the final presentation. A large number of product development professionals, plus many of your peers will be in attendance and will review your product, so it is a terrific opportunity.

The Team-specific comments/suggestions that follow below from Professor Wallace are intended to help each team in preparation for the next design revision/design review on Monday. Please consider these comments and the written feedback you will receive from other instructors as you make decisions, and feel free to ask if there are questions. Finally, please contact Professor Wallace to schedule a time on Tuesday to discuss set design, if you have not done so already.

Finally, the average score from reviewers for each prototype, with standard deviations, is at the bottom of this page.

Team-specific comments and suggestions
red, green, blue, yellow, orange, purple, silver, pink

Red: Climbing wall
View the prototype and provide additional feedback

You've made really great progress, so you have a solid reference to work out the details and resolve the product!

A list of comments/suggestions follow.

  • probably the biggest user issue is pinch points at the top and bottom of the device. When I think about it, it seems like there needs to be a platform at the bottom and an overhang at the top (with a flexible brush in the gaps to the moving wall) so it is not possible to reach into the problem areas.
  • from a play standpoint, sensing where the user is and automatically deciding to speed up or slow down seems like an important next step.
  • Together, let's think through how we will get this on stage for a demo, and also out front for testing at the final presentations. It's also very relevant to the real product for thinking how the actually device would be shipped at a reasonable cost. It would really be great to make the device a bit narrower (my instinct is that won't limit the play much), and have machine-base type casters that raise/lower so the wall can be moved when needed.
  • it seems like it would be possible to have hand-holds only on every second slat as the spacing is quite close.
  • I think it would be good to design the device so that the wall could be assembled horizontally on a table top (rather than vertically) and then click into legs that hold the wall vertical. I'm happy to discuss/sketch ideas in person, and also some material choices/details for the frame. There probably needs to be a back panel for lateral stiffening and to enclose the returning slats, but much of the design can be open and clean.
  • the edges of the slats should be rounded over to avoid sharp corners.
  • the foam pad at the bottom seems inadequate, and if there is a ledge/platform detail at the bottom to avoid pinching would need to designed in conjunction.
  • wire routing! I can envision a standard slat wiring harness, and a "T" slot in the back of the slats that receives the harness and then have a cover strip that slides into the T to conceal and protect the harness.
  • the top sprockets don't need to be on the same shaft as the bottom drive shaft keeps the two chains in sync. So could have a short shafts and two bearings on each side at the top to avoid stiffness issue.
  • illuminated hand holds would be nice.
  • it seems like the slat guide rails could also be the low voltage power rails for the slats, avoiding the issues with the copper conductor strip.

Green: Glove remover
View the prototype and provide additional feedback

You have found and elegant solution and have a good opportunity to make this an absolutely real, well resolved product. Exciting!

Some additional thoughts are:

  • Cleaning! Can the device be designed so that there are no internal corners that are hard to clean? Could the splash guard be semi-circular? Could there be no internal corners or exposed fasteners on the "remover itself". Could the "remover" come off for dish washing or autoclaving? I think that if you can be fanatic and uncompromising to come up with a way to make it clean and super cleanable it will be great.
  • the 4 bar approach worked, but did not seem to resolve the concern about possible skin contact with the device, which is also the main remaining concern with the passive hook approach. I continue to wonder about not trying to catch the gloves at the wrist, but rather in the palm, as this avoids the skin contact concerns and the gloves seem to naturally fall into the waste bin. There is the concern about tearing, but has a semi-spherical (say 1/2" diameter), elastomeric (say silicone) tip on the end of the hook been tested (instead of a corner to catch on the glove)? I suspect that this would grip the glove material and not have corners to initiate tears. The shape probably would not encourage users to try to "hook" the gloves at the wrist. Might be worth a test. Happy to discuss in person.
  • a slight downward slope on all features should also help the gloves fall more reliably.
  • the insertion, removal, and emptying/disposal of the glove bin is also a critical aspect. Be sure to give these aspects the same level of detail and thinking as the hook.
  • could the device attach to a desk top surface (clamp, suction cup) instead of being freestanding?


Blue: Rolling Walker
View the prototype and provide additional feedback

The walker (or perhaps better described as "rolling walker") now has a representation of key functions that you want to incorporate. The next challenge is taking this from a rough model to product-level execution. I would recommended really working to design all of the details in fine resolution as a next step, rather than somewhat organically growing a design as it is fabricated. Think beautiful. How do you resolve and reconcile all of the needed details with the walker vision model so that it is a completely defined design—to be used for the next fabricated version?

For the design review on Monday I would really encourage a focus on this, and I would be very happy to spend some time with you thinking about some details. Just let me know.

Additional thoughts follow.

  • positive user feedback to understand which of the three braking modes is engaged seems important to avoid confusion. One could imagine having both visual and tactile feedback for this?
  • Be careful that the brakes cannot be disengaged accidentally by leaning on the walker.
  • the hinges and connection details should probably be minimal and beautiful. For non-welded joints probably injection molded fittings? As a prototype, these could like be made by either machining or pressure cast from urethane in 3D printed molds.
  • the wheels might need to be larger for rough terrain, and can be beautiful in-of-themselves. Larger wheels could help with break details too.
  • be careful about catch points that can lead to falls. The downward angle, open handle is an example that can catch clothing. The hand could return/close in a D shape to avoid this issue. The protruding brake might also catch a foot and cause tripping. Just think really hard about these issues. If you have not tried on the age suit at the age lab this might be an interesting thing to do to further build an understanding of the user's abilities.
  • I was not able to fully understand how the walker's features explicitly addressed the "roll away" concern that is one of your key goals. This is a message that would be good to be clear. As raised by a team member, I also wonder if this is partly because the walker is totally in front of the user. Is there a way to immerse the user in the walker (i.e., it is both in front and extending behind on the sides) without the possibly of users tripping on what is not in front or limiting the ability to move from seated to standing (backing up tight to something)? Perhaps this could also help with the problems associated with falling backwards.
  • some higher-end bicycles can be an inspiration for how to route cables, lever design, and possibly even tubing joint details. I would suggest finding the most elegant walker that you can buy and get it into your team area as soon as possible as a reference point/detailing inspiration.

Yellow: guitar tab writer
View the prototype and provide additional feedback

You now need to decide on your technical approach and can proceed from breadboard testing to detailing and execution as a product. A very technically challenging problem. As you know, sampling bandwidth is a critical issue.

Although not the focus of the technical review and as someone outside the team's detailed discussion, I have not been able to internalize why the teaching use case is more compelling than composing. If it is an add-on product could it not just be a cool device for folks that like playing around with composing (not professional musicians)? For teachers it is not clear (from what I have learned so far) why add-on woulld be preferred over a guitar with a specially designed neck (since I understood that once installed users would want to leave the guitar setup for the most part). A custom designed integrated neck might help with a number of the functional challenges?

Some other thoughts and suggestions follow:

  • Calibration and tuning clearly really important. Could there be an auto-calibrate mode, where a "strum" of the guitar allows the device to adjust to match how the guitar is tuned?
  • The tutorial at 5 PM Friday on UI design (see the home page) could be helpful
  • There was discussion of cross talk between strings. We had a discussion has to how each string could be mechanically isolated on the bridge by tuning the bridge stiffness. In discussing with some folks that play guitar, it seems like there might be commercial options for pickups/bridges that are isolated for each string.
  • an auto detect mode to begin recording and stop recording to avoid lots of "null tab" would be nice.

Orange: communication mask
View the prototype and provide additional feedback

A mask with a built in microphone, a nice interface to adjust volume, and an ear piece and possible connection to a phone to call out. I can see this coming together as a product! Your setup for the technical review was nicely thought out, and it seemed to me that the general approach for the technology and fabrication are in place. Now it's time to bring everything together and really nail it. Small details make a big difference and you have the opportunity to detail this product very realistically.

Some additional comments follow.

  • resolving issues related to dangling earphone wires, cables is an important step in the overall product integration. Really try to embrace this challenge.
  • I think that doing a mask that can be used generally for people with communication needs is fine, and showing what all the different use cases have in common is great. Probably also want to have a nice specific demonstration context in your presentation.
  • my instinct is that the circular volume UI will be less prone to catching on things and being adjusted by accident.
  • it seems like there is still debate about the best way to incorporate elements into the mask. Pot electronics and mount, or mold directly into the mask. Potting and mounting makes failures more recoverable (since things can be swapped), while embedded seems cleaner.
  • I probably missed it in the review, but I did not catch the vision for battery—where they will go and how they will be changed. Another important detail for making it real.

Purple: wheelchair umbrella
View the prototype and provide additional feedback

You've covered a lot of ground since the mockup review! Now it is time to make your architectural decision. Both approaches are interesting. As an outsider who has not gone through all of the learning that you have, it seems to me that the "tube" concept may have a few pratical advantages. It seems like it would be less disruptive to other things a user might want to put on a chair, and it also has a simpler, presumably 2 point interface with the chair—so accommodating different chairs seems more likely. Detailing these attachment points elegantly is really important. The approach also seems more minimal and self-contained as an add-on (but could get smaller still).

Using lighter fabric (such as rip stop nylon) and flexible fiberglass poles (instead of metal with hinges) will help with folding compactness and also robustness. Using pop up tents as an inspiration might be helpful. Nate Phipps, a mentor for green team has a lot of experience designing tents and pop-up structures, and I'm sure that he would enjoy talking to you. You can contact him through green team's page on the course website. I'd also be quite happy to discuss and sketch design details with you. Free free to ask.

Some other thoughts and suggestions are below.

  • designing the "popped up" structure to shed water to the sides (and far enough to avoid electronics mounted on the chair) and not over the front seems important. I think some sort of gutter concept would be possible.
  • I did not fully understand the rationale for having a separate energy source for the umbrella. If there is a reasonable way to get the power from the chair it seems to me like the way to go. It would reduce product cost and also greatly simply charging logistics. I don't think that the energy the umbrella would use would be noticeable relative to the what the chair consumes for propulsion.
  • it seems like the attitude of the cover might need to vary based on both rain conditions and forward speed. It seems like the elastic "hold down straps" on the cover could have a tension adjustment which, in combination with flexible poles, could adjust the shape of the cover.
  • I was focused on other things, but I missed or did not notice how the user interface of the device is being resolved. Obviously important, as is whatever routing is needed to connect to the umbrella (or would it be wireless?)
  • A clear umbrella, or translucent might be nice as it could afford communication with people standing near/over the chair.

Silver: icedam remover
View the prototype and provide additional feedback

You have been doing a lot of experiments to develop the technical approach, which is necessary and good. Now it is time to think of productizing an approach and the details that goal along with that (configuration logistics for different roofs, connectors, installation, maintenance, programming/control interface, noise in residential areas, etc.)

Without the benefit of knowing all of the things you have learned, for the airbag concept I had imagined that very small diameter inflatable tubes (maybe -1.5") that run down the pitch of the roof might clear channels for water. Different than the current approach.

The melting solution approach seems compelling in that it had a direct pattern of productization installation based on drip irrigation (perhaps 1/4" diameter), and seemed like if applied before icing has a residual de-icing effect. At low pressures a peristaltic type pump can be quiet and reliable, and deliver low flow rates that would perhaps make the emitters as simple as holes. Or it might even actually use drip irrigation (say raindrip 1/4") with an air bladder pressure tank so the pump can run very infrequently. Look at how water systems in houses with wells work (I am happy to discuss too). The color/odor is a drawback. I wonder if the material can be used diluted. Or could other additives (sugar, alcohol?) be used to make a clear antifreeze liquid?

I'm happy to discuss ideas for how one might bring the system together as a product. Feel free to ask.

For the design review on Monday, I would recommend deciding on your solution direction, and then really focusing on identifying and designing all of the different types of elements that are needed for the product system.

Related to detecting icing conditions, there may be sensors commercially available designed specifically to do this, or perhaps one could interface with something like the weather channel to infer icing conditions, and also to perhaps pre-apply materials based on forecast (pending solution approach).

Pink: Defibrillator
View the prototype and provide additional feedback

A nice visual model and demonstration of the core technical elements. Just please don't under-estimate the challenges of integrating everything into one package. Try to get a jump on this so unexpected issues can be diagnosed and nicely resolved.

The statement from Captain Vossmer was great. If she could buy these right now she would make sure that every bicycle police officer in her department would have one. A super clear use case/market from an organization with resources to buy, and probably folks that could do product testimonials for you. It's worth serious consideration.

Some additional notes follow:

  • The caps should have multiple ways to communicate what needs to be done, as the numbers might be overlooked in a panic. Color, pattern, and descriptive form are all devices you can use. Step 1 is knowing to go to your phone app (before the device). Can the device very obviously communicate to start with the phone. Caps with different things inside might look different.
  • gating the pace and level of detail in the instructions seems important. Controls on the phone are good, but imagine trying to do that right in a panic! Multiple paths again seems appropriate. Voice activation as an option, auto-detecting when to move on as much as possible, etc.
  • it may the be the case that the space used by the scissors could be better used another way. Perhaps tape to remove hair, child size pads, etc?
  • the issue with pacemakers and how to avoid placing pads over them vs. auto detection seem like it needs some resolution.


Average reviewer score
The average reviewer score is on a scale of 0-10, where 10 is highest. The score is based on prototype operation and the assessment viewpoints outlined in the technical review description. The data are averaged from rankings provided by 45 reviewers.