HCDE 210 Sprint 5: Prototyping

  1. The transition from my first exposure to LittleBits to my group’s prototype was quick. The first prototype I made was a simple telegraph using a button and a light. From there, my group and I explored the various inputs and outputs. One of the first outputs we tried was the motor, which confused us at first because it did not have a 360 degree range of motion. From there, we experimented with the remote control activation to turn on a fan.

We then experimented with the sound trigger after watching another group make a “clapper” light. We decided to make a sound-sensitive alarm using the sound trigger, the MP3 player, and the light for an added visual element. The transition between the stages was incredibly quick; we probably spent about five minutes at maximum working on each different prototype we made.

The sprint went well for me. The LittleBits kits were intuitive and fun; if I had the money, I’d buy one for myself. The only thing that could be better is improved access to a wider array of LittleBits elements.

2. My experience for this sprint was overwhelmingly positive. The most important question I initially thought of was “How do companies produce prototypes without LittleBits kits?” i.e. what tools do they have to produce physical prototypes of their own? My assumption is that their prototyping tools are more powerful/developed than the LittleBits kits, but they also require a higher degree of skill. The sprint made me want to participate more in physical prototyping. Andy mentioned Arduino, which is an outlet that I am looking into as a logical next step in physical computing.

3. Q:

If you were to “partner” this sprint with another sprint we have completed — that is, make a prototype and use it to complete another sprint, which sprint would you choose and why?
A:

I would choose the usability testing sprint to partner with this sprint. I think it would work well to partner these sprints for several reasons. The most difficult issue I dealt with in the usability testing sprint was my lack of knowledge regarding coffee machines. It made testing difficult because it is hard to think of good usability metrics for a machine which you do not understand fully yourself. By creating the prototype and then testing it on a user group, I would have complete knowledge of the prototype and it would be much easier to generate good usability metrics for testing. The one downside of this is that the prototypes would have to be complex enough to have different actions to measure for usability testing, which may make prototyping more difficult than it was.

4. The first question that occurred to me is “Are people aware of what providing this data to companies means for themselves?”. I believe that many people are unaware of privacy, ethics and security risks that the sharing of this data can cause. Many people do not know that they are constantly providing private data to companies at all. It is most dangerous in the smart home. The home is the paragon of privacy — privacy is a right of all people within their own homes. If they consent to giving up their data, that is acceptable. But the taking of data without express consent of the user presents severe privacy, ethics and security dilemmas. If secure data for something like a door lock were breached, houses could easily be unlocked. For products like Nest, it is disturbing how accurately Nest can monitor and detect “unusual” behavior within the home — what constitutes “unusual”? What is being done to fix “unusual” behavior? I value my privacy strongly, and I am skeptical of cloud-based repositories for sensitive data that comes from my home without my knowledge.