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. Please be sure to read these comments. Comments from other reviewers, 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.


blink control smart home device


brick mortar joint remover


haptic game for visually impaired


tremor mitigation device


voice modulation for hearing impaired


fireman's door knob temperature sensor


search and rescue system


music page turner

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

All teams have shown good progress since the mockup review. The current prototypes are good platforms for testing, and provide a concrete reference point from which one can carefully design and detail a product. While some models 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).

One of the first things to do in preparing for Monday is to step back, look at, and discuss the prototype as a team. Regroup, and get the team on the same page about what the product is and with the same vision. Having been focused on different items/details in the push for the technical review, different team members may not be aware of how aspects of the product have changed. This was evident when inconsistent descriptions and rationales about the product were provided by different members of the same team during the review.

Please read the team-specific comments below, the written comments you will receive from other reviewers no later than 5 PM Saturday, and your notes from the review. Think about how your current prototype would need to change to be comparable to an existing product that you can already buy. 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. Core, integrated functionality should be solidly resolved by the Thanksgiving break so that there is time for implementing, planning, product testing, and preparation/practice for the final presentation.

Use your current prototype 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. 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.

The Team-specific comments/suggestions that follow below from me 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 me 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: Blink controlled smart home products
View the prototype and provide additional feedback

You've made really great progress, so now it is time to bring things together into a product!

A list of comments/suggestions follow.

  • A device like this should probably have a safety factor on the order of 10. It seemed like the signal was quite strong, so it should be possible to reduce the power. Please work with Steve B, as your very next step, to verify the geometry and safety factor for the device.
  • You could spend a lot of effort designing and prototyping a nice pair of glasses to "hold" your core technical innovation. It is suggested that you find a style of suitable frame that you like and buy them (~3 of them). You can join your blink sensing components onto the frame and, using appropriate fillers and paint, prototype the integrated frame/sensor product that you envision. I'm happy to go over techniques for how you might do this. This will allow you to concentrate on your core proposition, and to realize a much more realistic and wearable product prototype. I'm happy to discuss further.
  • Consider adding simple patterns, in addition to time of blink, as part of your command signal. This could allow for a few critical functions, such as calling for help, or a cancel/undo.
  • It was not clear exactly where the "box" would be mounted. Not worn on the user, but where does it go on a chair and how does it attach? Once this is decided you can design a product form factor with affordances for mounting or fitting such a location, and carefully refine and detail its geometry.
  • Having the device use audio/voice communication is fine, but perhaps the communication could be further refined.
  • Robustness and calibration are critical challenges. Glasses do move some over time and there is some variation when glasses are taken on-and-off. Also, as you know, lighting conditions vary widely and change over the course of a day. In addition to being important in the real product, it is really important to address robustness and calibration in order to be able to reliably demonstrate the product.

Green: Haptic game for visually impaired
View the prototype and provide additional feedback

You've have a clear direction for the product so you are now in a position where you can design a coherent game concept and product package.

Some additional thoughts are:

  • Since it is a game, think carefully about where the fun is. Develop options for rules and game play. Play test your concepts (those who have taken 2.00b should remember this!). Play the game, watch the game being played.
  • In the form at the technical review, a number of issues came up, ranging from: how a a sighted person knows what you are drawing invisibly without seeing it, the visibility of wet ink, the clarity of the UV image drawn, to how do those with vision and those without "picture" objects such as a bicycle even just draw them. The game design/game-play might address these challenging issues while providing the social skill aspects mentioned during the review. For example, the product might be thought of as a "mystery object identification game" where the goal is to guess/identify various shapes or symbols. Possibly a deck of pre-printed UV cards with simple symbols. This would address drawing consistency issues, use known shared symbols (e.g, circles, cross, etc), and actually afford different aspects of play—such as degree of difficulty ratings, shape categories, or theme packs (as examples).
  • Think about designing the game as an overall package, from the packaging and instructions to the timer, score keeping and haptic device. The items can be a coherent system with forms consistent with the game play. Since you are working on something to appeal to both sighted and non-sighted players, the form design is a rich space since it is both highly tactile and visual. You might look to other games for some inspiration.
  • Detail the geometry/parts to include all of the needed features, and structures are provided for mounting boards, charging or replacing batteries, fastening the housings together, etc. This, along with printed boards will greatly improve reliability. Also, as a game piece, it needs to withstand some degree of dropping, etc.
  • For me, the connection to the computer screen created some confusion about what the product/goal actually was. It took me time to realize that the screen visualization was just to show what the device was detecting since the vibration had stopped working prior to the review. It would have been helpful to just clearly state this.


Blue: Voice modulation for hearing impaired
View the prototype and provide additional feedback

The basic components seemed to do what they were intended to do. It's now perhaps a case of appropriately simplifying and then resolving all the geometry and details so that it all comes together in an integrated package. As you know, putting all of the pieces together is a challenge!

Additional thoughts follow.

  • The idea of preset levels is sound. I suspect three levels is fine. Perhaps not thought about in relation to the ambient conditions, but more like soft (for quite spaces), conversational (for typical talking spaces or on the phone) and projecting (for large or noisy spaces)
  • Trying to discriminate from background noise is pretty challenging, as you know. Hearing aids are quite sophisticated and still have lots of problems. Similar for Facetime (try having a conversation with a person on a computer while someone else is in the background is doing dishes). In my experience, Facetime will pretty consistently pick up the dish clanking and filter out the person talking at the computer! That said, it seems like the feedback you need might not require this level of processing. Perhaps a carefully chosen microphone (with appropriate directionality) and/or an appropriate sampling time can reduce the challenges. Since it seems like the user's speaking levels tend to slowly drift from the desired level over time (rather than spike up and down), maybe their voice level could be averaged over pretty long time constants (10s, 20s? Just a guesses, I don't know the appropriate time). This would help with sporadic background noise. High background noise is just challenging, but perhaps it's not the key use case (my hunch is quiet places and conversational are likely where modulation issues are most apparent). Further refining the use scenario/product definition could help on this. Please talk to Steve B about your implementation as he would like to help reduce complexity of the implementation while attaining your desired functionality. He'd be happy to discuss details.
  • My impression is that it would be really nice for the user if the device could be reduced to a single, lapel item that included the microphone (or microphones depending on the approach) rather than a two piece system. During use, a worn lapel is also a consistent distance from the speaker's mouth which could also be helpful.
  • The visible parts of the system seem like they should have a jewelry, or fashion apparel quality to their form and detailing. My impression is that your users are reticent to convey hearing challenges by asking if they are too loud or soft, so it's plausible that they also don't want the product to obviously be an assistive device. Perhaps you could assemble a physical collage of broaches, fashion items, etc. to use as inspiration for form development. Perhaps the device could have "skins" that allow for accessorizing in different ways. Happy to discuss further.
  • When you detail your product housing, it will be helpful to include features to mount and retain circuit boards, align and fasten components. As the internal components become clear, you'll be able to get to this level of detailing.

Yellow: search and rescue system
View the prototype and provide additional feedback

A lot of nice development work has been done, and I understand that some core technical challenges were resolving just as the technical review took place. Also, the product definition has changed a lot based on user needs and trying to match the ways real searches are coordinated, leading to the hive. This is good.

Some related thoughts follow:

  • Given the number of pieces in the system, and that various folks have been working hard on different parts of the system, and that the system itself has been changing, I wonder if everyone is on the same page as to what the system really is. It took me quite a while (into the review meeting) to really understand the product configuration and why it was that way. I think that this was the case for most reviewers. So, this is a good time to get together and make sure everyone is on the same page about the system. It seemed like some of the physical implementations of subsystems reflected prior visions for the product.
  • As you know, there are a lot of parts to the system, and it is challenging to implement the three different products it is comprised of. I think that having a few components executed really well will be more rewarding/satisfying than having more components done at a lower level of execution. Maybe it would make sense to focus on the queen and scouts, designing these elements for the "hive" system architecture but leaving implementation of the hive as future work? Could present an overall system vision and then implement a useful, meaningful subset. Trying to think about how to manage scope. At least worth consideration. There's also the carrying case system for the product, too!
  • Form exploration models were done. Good. Please be sure to get your form factors into the hands of experienced searchers to get feedback.
  • For a number of the pieces, housing printed on the objet, or machined will give you a better level of finish and detailing. It would be nice to establish a consistent form vocabulary between the different elements. Also, further detailing/resolution of bezels, controls will help to bring the prototypes to product-level implementation. Happy to further discuss in person.
  • Good effort exploring over-mould, but still aways to go on this. If you are interested, I'd like to go over the process with you and mould designs. Also, sometime in a prototype using rubberized paint can be an effective way to achieve a similar effect.
  • Try to test communication from queens inside Kresge to scouts outside ASAP!

Orange: brick mortar removal for repointing
View the prototype and provide additional feedback

You had two platforms/architectures that really are quite testable, which is great (hammer head and mason guide). It seems like several reviewers were not aware of the mason guide.

Some of opinions based on trying it out at the technical review follow.

  • for me, the mason guide was compelling. It was lighter, more balanced, and easier to work with. It was right handed (I'm a lefty) but having rotating or repositionable grips, as many tools have, might address that. The chisel of the hammer head concept was narrow, which tended to result in a narrow channel in which the fins often bound. That complicated the comparison, but a more compact, easy to handle tool is pretty compelling. It may be the case that the purchaser (contractor) only cares about how quickly the job can be done, but any user (mason) is going to appreciate a tool that is lighter and easier to handle. Can the tool make the lives of both the purchaser and the user better?
  • It seemed like the two fins rarely engaged. Perhaps a single fin and a curved sole plate for the tool that allows adjustment on the chisel angle and depth might work well? Some of the desire for adjustment was getting the chisel at the right distance for the hammer to engage.
  • A series of chisels for different width mortar joints seems to be needed so that a "square" channel is made, with the faces of the brick in the open joint clean of mortar.
  • it seems like a steel guide surface might improve ease of use, with hardened steel fins. The aluminum fins tend to gall on the mortar.
  • there was some inconsistency amongst the team on whether the device is integrally designed as an overall tool or an attachment that can be removed. And if it is an attachment, is it user installed or sold assembled (and never taken apart)? From a weight and size minimization standpoint, a more integral approach is likely an advantage.

Purple: tremor mitigation wrist band
View the prototype and provide additional feedback

This is a very compelling product case and you have experimented with a number of fabrication techniques. The product has a significant R&D aspect and associated risks (and rewards)! For myself, I see the task at hand as designing a really nice, product-like wrist band that allows you to conduct a series of thoughtful experiments to explore and quantify efficacy and configurations (and possible future improvements). A bit different than some of the other products developed in 2.009. So, your user experiments and data are a really important. When you go to work with users, have a series of test protocols so that you can quickly run through and quantify different approaches.

  • I think that having a couple members dive deeply into the physics/science of tremors would be really helpful, if this is not already the case.
  • It would be worthwhile to further refine the shape of the "box" on the top of the wrist band. Try assembling a collage of wrist-worn devices that exist as products that your intended users like. Borrow/inspire your form language from these products.
  • You explored a number of silicone moulding approaches for the band. It seems like making the band out of fabric or leather would facilitate fabrication and configuration of the device. You can heat-laminate fabrics with motors sandwiched inside, or perhaps even pockets that the motor can be slid into for different wrist sizes or positioning needs (with a wiring harness in the band to each pocket with connectors that allow you to plug and play motors in different slots? I'm happy to discuss in person. Also, Beth Sullivan has great expertise in soft good prototyping (she did the tutorial on Tuesday). If you like, I can try to arrange an individual consultation on specific fabrication techniques. Just let me know.
  • Be careful about your wire selection, as fatigue and wire breakage can happen at very inopportune times!
  • There was discussion of machine learning for automatically controlling the device. In thinking about it, perhaps a more traditional feedback/control approach might be a good fit for the problem.
  • Plugging in for charging is likely a challenge for the intended user. So, this aspect requires thoughtful attention. Are there off-the-shelf induction charging kits that might be appropriate?

Silver: Fireman's door knob temperature sensor
View the prototype and provide additional feedback

A lot of of nice work has taken place, and overall the device seems to be working quite well and achieving a nice level of resolution and detail.

  • I think that it would be good to do some modeling/simulation for what temperature at which the door knob should raise an alert. Currently, it is the fireman's judgment. With your device it's no longer thier responsibility. So, need to get it right. I was surprised how cold the knobs were on the non-fire side, but there really is a pretty small thermal circuit through the pin that connects the inner and outer handle, so it kind of makes sense. I think that modeling would help you decide on your own if the 140 mark is where the threshold should be. Maybe there ends up being three options for feedback: cold—it's definitely fine; hot—it's definitely not OK; and a can't tell—you decide.
  • there was some flaky behavior at times that was attributed to the electronics getting too hot, but the sensor and device felt pretty cold. While heat sinking and thermal issues are a real challenge, I suspect that the periodic strange behavior might have been more mechanical and related to wiring integrity and not having your printed circuit boards inside.
  • clearer feedback between not engaged vs sensing cold would be helpful. I and others recall both are green. It's green, makes contact, turns blue, and then went back to green if cold (correct?). Also, positive feedback on engaging would help.
  • multi-sensory feedback is good. Currently tactile and visual. Would it be helpful in some case for it also to be auditory?
  • extreme durability is key for this product. Can it withstand being hit by a hammer or smashed into a wall, immersed in water, etc.
  • consider compliance in the sensor to accommodate different shapes of door handles and features. It seems like an issue for the current configuration.

Pink: Page turner
View the prototype and provide additional feedback

The implementation shows real promise! Now it's time to productize. Given that the device sits on a piano in an environment that is all about an aesthetic experience, it seems like the device, while not a center piece, should be a thing of beauty when noticed, matching the environment and the magic of the page turning. Perhaps the carry case concept is more in the direction of such an aesthetic than the current form of the turner.

  • materials are a big part of the aesthetic feel of the product. For example, the arm of the gripper might be a beautifully sculpted, investment-cast, (in appearance) black anodized aluminum, or perhaps polished brass. Sitting on a piano, wood seems like a really appropriate material for the turner and book holder. Ebony, or black lacquer finish? We have people in the lab with significant woodworking experience in the lab (including myself) and are happy to help. If you would like to discuss just let me know.
  • I think the device can be quieter still, and if there is audible sound, it should be a high quality sound. Some of the material choices above will really help with this, but there are different motors (rather than servomotors) that would be appropriate. There are some mini motors in the 2.009 store that might be a good start.
  • it appears that designing the book holder as part of the turner is going to be necessary to get it to work reliably
  • the foot pedal seemed to work well, but attention to details of its form, and how it does not move while in use will improve it. Perhaps existing guitar or similar foot pedals might be inspiration.
  • sometimes when pages are turned, they may pop back unless creased in place. Does this happen often? Is there a plan for how to deal with it? Is it infrequent enough that the pianist can just correct by hand?


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 40 reviewers.