I found that the author of this reading was able to put into very concise and understandable terms the importance of design and some key concepts that define the field. I find that this was able to provide me with a thorough overview of what designers must take into account when designing new products or experiences.
I find it very fascinating how he argues that despite engineers or developers’ thorough understanding of the product they are creating, they are not able to understand the complex emotions and behavior of people that use their product. I am curious how companies might find a perfect middle ground where their designers understand both the complex technology that they are designing, as well as the behaviour of people who use it.
I also found his discussion of feedback very interesting and thorough, as this is something that I often encounter when using products. I find that numbers and labels are arbitrarily placed and assigned on a product or interface, and not only that, there is no way to determine whether or not what you are doing is correct or nor until it is often too late. These are things I have considered, but Norman put it in simple yet effective terms that allow me to think about design in the things I interact with.
I really liked Norman’s method of breaking down design in terms of terminology used and the many different conceptions that are integrated within it.
Bad design is definitely a hassle that almost everyone has faced at one point in their life or another. However, while reading his work at first, I felt as if Norman was being a little bit exaggerated about how important design and signifiers are in daily life and objects but then I remembered being in London a few weeks ago and struggling to work the tap for a good ten minutes before asking for help (my roommates did not know either). The situation we faced was pretty disruptive and frustrating and a set of clearer indications on the tap could have definitely averted this problem; thus, I conceded that Norman is correct in identifying how crucial design is for objects – especially those that should not require too much thinking in the first place.
“The same technology that simplifies life by providing more functions in each device also complicates life by making the device harder to learn, harder to use. This is the paradox of technology and the challenge for the designer.”
Moreover, Norman’s statements about the future of design really resonated with me as well. Watching my grandmother or even my mom interact with a new phone is painful at best as they attempt to understand how each flick of their finger or movement of their face will cause a change on the screen. Even myself, having access to iPhones, Macs etc. am unable to remember sometimes how different movements can result in different results without having to look them up. Even as I write this, having become used to using a Windows computer in my class and changing back to a Mac for personal work, I continue to mistake the commands on the keyboard between the two. This makes me question, what does this mean for the future of design as electronics get more and more complicated in terms of functionality?
Before reading this chapter, I had no idea that my inability to open certain doors would be addressed as a bad design concept. I’ve noticed that I’ve walked into numerous doors only to take a step back to understand how exactly to open it. Once I genuinely thought I was locked inside the NYU Shanghai staircase because the door handle was locked when I tried to twist and pull. I had to text my friend to get me out of the staircase and when she came she told me to just push. Thanks for letting me know that my stupidity was because of bad designers, Norman!
I found the concept of discoverability very familiar. To me, it sounded like what we read about interaction. How is the agent interacting with the object. What is the relationship between these two items? The only difference to me seemed to be the fact that affordance needs to be useful. These affordances will determine what actions are possible. Norman then goes and talks about how signifiers are used to communicate where action should take place and that we need both affordance and signifiers. However, he also talks about how adding external signifiers that need to be added indicate bad design. I totally agree on the last point, but I wonder what the line is between when there is too much signifiers and when signifiers aren’t needed at all. I would think that it is very similar to when feedbacks are considered to be too much to point where it starts to annoy people.
Another point Norman made was about how engineers are bad designers because they think too logically, and not everyone can follow and interact with the product the way engineers want them to. I think this is where designers come in, but there is still a problem between what the designer want users to do vs what the user actually ends up doing with the product. There is still the burden of communication and I’m not sure where Norman would suggest to fix this problem. User testing? After all of Norman’s examples, it still amazes me how designers/companies still roll out with products like digital watches with buttons that aren’t labeled.
My mother will hate me for this, but I have to say it: I come from a loud house. So it only makes sense to let myself know how loud since I would be drowning in noise anyway. I used the following code to connect a sound sensor to a series of LEDs that light up in sequence the louder the sound. In started with three, and then distributed the hertz across 9 LEDs after I solidified my logic.
int soundSensor = A0; // select the input pin for the soundSensor
const int ledPinR3 = 13; // select the pin for the LED
const int ledPinR2 = 12;
const int ledPinR1 = 11;
const int ledPinY3 = 10;
const int ledPinY2 = 9;
const int ledPinY1 = 8;
const int ledPinG3 = 7;
const int ledPinG2 = 6;
const int ledPinG1 = 5;
void setup() {
// put your setup code here, to run once:
//declare the sounSensor as INPUT
pinMode(soundSensor, INPUT);
pinMode(ledPinR1, OUTPUT);
pinMode(ledPinR2, OUTPUT);
pinMode(ledPinR3, OUTPUT);
pinMode(ledPinY1, OUTPUT);
pinMode(ledPinY2, OUTPUT);
pinMode(ledPinY3, OUTPUT);
pinMode(ledPinG1, OUTPUT);
pinMode(ledPinG2, OUTPUT);
pinMode(ledPinG3, OUTPUT);
Serial.begin (9600);
}
void loop() {
// put your main code here, to run repeatedly:
//create an integer to sense the data from the sensor. it is an analog one, so you have to analogRead.
int soundValue = analogRead (soundSensor);
Serial.println(soundValue);
if (soundValue >= 21)
{
digitalWrite (ledPinG1, HIGH);
} else {
digitalWrite (ledPinG1, LOW);
}
if (soundValue >= 70)
{
digitalWrite (ledPinG2, HIGH);
} else {
digitalWrite (ledPinG2, LOW);
}
if (soundValue >= 150)
{
digitalWrite (ledPinG3, HIGH);
} else {
digitalWrite (ledPinG3, LOW);
}
if (soundValue >= 170)
{
digitalWrite (ledPinY1, HIGH);
} else {
digitalWrite (ledPinY1, LOW);
}
if (soundValue >= 210)
{
digitalWrite (ledPinY2, HIGH);
} else {
digitalWrite (ledPinY2, LOW);
}
if (soundValue >= 250)
{
digitalWrite (ledPinY3, HIGH);
} else {
digitalWrite (ledPinY3, LOW);
}
if (soundValue >= 280)
{
digitalWrite (ledPinR1, HIGH);
} else {
digitalWrite (ledPinR1, LOW);
}
if (soundValue >= 310)
{
digitalWrite (ledPinR2, HIGH);
} else {
digitalWrite (ledPinR2, LOW);
}
if (soundValue >= 350)
{
digitalWrite (ledPinR3, HIGH);
} else {
digitalWrite (ledPinR3, LOW);
}
}
We also read some foundational texts regarding design.
Reading Don Norman’s work on affordances and human centered design ironically made me worry about the future of the field. As someone deeply in love with design, Norman’s exceptional ideas about how to design our world expressed, at first, an end to the practice. An exhibit in London described a compelling idea along these lines: that humans are regularly creating a world that no longer requires humans. In the same way, are designers creating a world that no longer requires designers?
Although the thought sparked some initial anxiety, a few ideas in Norman’s text provided some comfort. He expresses that technology and people are constantly evolving and changing. As technology improves, as human behavior changes, the nature of affordances change. What we need as a society change. He also describes, when discussing mapping, that culture can define certain design ideas, and that although some concepts should be universal, others work best for particular societies.
Here, we reach the notion of the zeitgeist, and how we impact it as designers. If culture is constantly shifting and created by us, then maybe the norms of how we view chairs and what they are used for will also change. Changed by our own will. As someone who hopes to enter this design world, I can both be comforted in not only that design will exist and be necessary for as long as I am alive, but also that it will exist and be necessary for as long as humans are alive.
For this week’s project, I used an Ultrasonic distance sensor as my analog input to create a box that opens its lid when you are far away from it. Once you come close enough with your hands over the box, it will shut on you. The goal of the project is to tempt the user to come close, but once you come too close, it will surprise and close on you. Ideally, the cover would be much heavier so that if it shuts, the person’s hand would be trapped there.
The Ultrasonic distance sensor is faced upwards so that it can detect whether there is a hand over it or not. Depending on its distance value, I map it to the servo, which will rotate between 50 to 180 degrees. I have attached a cardboard on the servo wing so that it is heavier and strong enough to hold up the cardboard box on top. In its neutral 50 degree, the cardboard does not push on the lid, however, once a hand gets close enough, the servo will rotate and will bring the cardboard with it to raise the lid. I have also included a Piezo buzzer that beeps more and more often once a hand gets close to it and a red LED light will also turn on.
During the project, I had problem figuring out what degrees to set the servo so that it went exactly between the 90 degrees needed to lift the lid. Additionally, the distance sensor takes a while to get the correct value, so there are times when every 10ms, it would jump between 1 and 403. To stop that from happening, I added a bit of a delay, but I’m not sure if that’s the correct way to fix it.
To improve on this project, I would probably also mount the servo in a more stable way rather than just hot gluing it to the side because it kept tilting to one side.
In this chapter, Norman introduces principles of design using examples of unsuccessful everyday objects. He looks at these objects mostly from a conceptual viewpoint and attributes the most important characteristics of good design to understandability and discoverability. He then explains the different parts of design functionality using principles of interaction such as affordances, signifiers, mapping, and feedback.
I think the main challenge he presents in this chapter is the extent to which we could (and should) incorporate human-centered design (HCD) into devices. There are many different factors governing the process of design, such as functionality, profitability in the market, and usability. One ever-present challenge in designing devices is the human-machine interaction and our ability to reconcile the binarity or limitations of computers that run these devices with the complexities of humans that use them, especially when technology is exceeding at a faster speed than design.
However, I think he exaggerates the extent to which these everyday objects “complicate” our lives, as well as the extent to which designers should rely on the human aspect. Bad design is indeed harmful, especially when there are ways that we could make devices more efficient and easy to use, but in the same way that we attribute the faults of design to the designer, we could also attribute the faults of understandability to the user. Yes, Norman proposes that “human errors” are just excuses for poor design, but to what degree are we willing to extract the user’s effort from the process, and why? People are becoming increasingly critical of bad design, and that is an issue that Norman expresses clearly in the chapter, however, aside from pointing out the faults of such devices as the wristwatch or the refrigerator, for example–– he does not propose any useful solutions. That is not to disregard the importance of the frameworks he sets for designers as those are useful conceptual structures we can immensely benefit from in the field of design.
For this assignment, we were asked to control an LED in an “unexpected” way using information from an analog sensor. Going off of this prompt, I created a ‘Safeguard’ using a motion sensor, a servo motor, a buzzer, and an RGB LED light. Here is a rough circuit sketch:
The LED lights up based on readings from the motion sensor about the object’s proximity; so if the object or person is at a safe distance, the LED turns green. At a medium distance, it turns yellow. When the object gets too close to the sensor, the LED turns red and triggers sound from the buzzer along with a movement from the servo motor. Although the stop sign kind of hints at the outcome, there is a sense of ‘surprise’ in that you don’t know how or when it is triggered unless you interact with the sensor. Here is an image of the circuit:
One of the challenges I faced while making this was that I wanted the stop sign to be part of the circuit, rather than a mere cardboard cutout. However, I realized that using a servo to move the sign around reconciles that. If I were to improve this project, I would incorporate an LCD screen to use instead of the cardboard sign.
Here is a final video demonstration:
And here, you can find the code I used to make it work:
#include <Servo.h>
const int trigPin = 11;
const int echoPin = 12;
const int redPin = 3;
const int greenPin = 5;
const int bluePin = 6;
const int buzzerPin = 10;
float distance = 0;
Servo myservo;
void setup()
{
Serial.begin (9600);
pinMode(trigPin, OUTPUT);
pinMode(echoPin, INPUT);
//set the RGB LED pins to output
pinMode(redPin, OUTPUT);
pinMode(greenPin, OUTPUT);
pinMode(bluePin, OUTPUT);
pinMode(buzzerPin, OUTPUT);
myservo.attach(9);
}
void loop() {
distance = getDistance();
Serial.print(distance);
Serial.println(" in");
if(distance <= 10){ //close distance
//make the RGB LED red
analogWrite(redPin, 255);
analogWrite(greenPin, 0);
analogWrite(bluePin, 0);
//this code moves the servo and triggers the buzzer
tone(buzzerPin, 272); //turn buzzer on
myservo.write(60); //move servo to 45 degrees
delay(100);
noTone(buzzerPin); //turn buzzer off
myservo.write(150); //move servo to 135 degrees
delay(100);
} else if(10 < distance && distance < 20){ //medium distance
//make the RGB LED yellow
analogWrite(redPin, 255);
analogWrite(greenPin, 50);
analogWrite(bluePin, 0);
} else{ //far distance
//make the RGB LED green
analogWrite(redPin, 0);
analogWrite(greenPin, 255);
analogWrite(bluePin, 0);
}
delay(50); //delay 50ms between each reading
}
float getDistance()
{
float echoTime;
float calculatedDistance;
digitalWrite(trigPin, HIGH);
delayMicroseconds(10);
digitalWrite(trigPin, LOW);
echoTime = pulseIn(echoPin, HIGH);
calculatedDistance = echoTime / 148.0;
return calculatedDistance;
}
//credits: SparkFun Electronics.
When I thought of the word “unexpected”, the first cliche that popped into my head (no pun intended) was the ‘Jack in the Box’ toy every little kid knows. At first, I wanted to use a flex sensor to turn the LED on and off once the box was opened/closed but I realized that a photoresistor would do the same job. I really enjoyed creating this box from scratch, soldering the sensor and LED for the first time and then seeing it work; hence, the smile :).
int Pr = 0; // will be used for analog 0.
int PrValue = 0; // value of output
int Pr_Input = 700; // value of when light is on
void setup() {
Serial.begin(9600);
pinMode(13, OUTPUT); // pin 13 as output
}
void loop() {
PrValue = analogRead(Pr);
Serial.println(PrValue);
delay(100);
if (PrValue < Pr_Input)
{ digitalWrite(13, HIGH); } else { digitalWrite(13, LOW);}
}
Regarding analog sensors, I was curious how I can mimic one of the games where you have to tap countless times in order to win. At the same time, I thought of the idea that portrays a battery charging by tapping. So, the circuit I have made is a similar but simpler version where I utilized the pressure sensor and five LEDs to create the following experience for the users.
In the beginning, the problem I had was controlling the light of the LEDs. I was used to writing digitalWrite as an indicator for turning the LEDs on and off, but it did not allow me to control the faintness of the lights. After some research into Arduino, I figured out that I can manipulate the brightness of the LEDs by using analogWrite, where it would take the pin and the level of brightness (from 0 to 255) as arguments. By putting it together with the mapped value from the sensor, I was able to display a general fading of the LEDs.
However, the problem did not stop here. Through user testing, I realized that people can lit up the LEDs by just pressing onto the pressure sensor. So, I made a change to use the computedPressureValue, the difference between current value from the pressure sensor to the previous value, to increment the brightness. When the pressure difference is negative, meaning that the previous value is larger than the current value, it meant that the pressure is decreasing and the finger is lifted off from the sensor. Thus, only tapping on the sensor will slowly brighten the LEDs.
Below are the snapshot of the circuit, a run-through of the experience, and the code for the circuit.
The Circuit Layout of the Assignment
// Variables for LED Pin Outputs
const int ledPinOne = 3;
const int ledPinTwo = 5;
const int ledPinThree = 6;
const int ledPinFour = 9;
const int ledPinFive = 10;
// Variables for LED States
bool ledStateOne = true;
bool ledStateTwo = false;
bool ledStateThree = false;
bool ledStateFour = false;
bool ledStateFive = false;
bool ledStateComplete = false;
// Number of LED that the has lit up
int ledCount = 0;
// The number of blinking of LEDs after all five LEDs has lit up
int completedTask = 0;
// Previous value of the readings for the pressure sensor
int prevPressureValue = 0;
// Raw value for brightness
int brightness = 0;
void setup() {
pinMode(ledPinOne, OUTPUT);
pinMode(ledPinTwo, OUTPUT);
pinMode(ledPinThree, OUTPUT);
pinMode(ledPinFour, OUTPUT);
pinMode(ledPinFive, OUTPUT);
Serial.begin(9600);
}
void loop() {
// ---- COMPUTATION OF VARIABLE ---- //
// The brightness is computed by using a modulus of 200 so that it has the max-limits of 200.
int computedBrightness = brightness % 200;
int pressureValue = analogRead(A0);
// The pressure sensor has a min. and max. values of 0 and 1010, which I have mapped for conversion from 0 to 100.
int currentPressureValue = map(pressureValue, 0, 1010, 0, 100);
// In order to increase the brightness for each tabs, I have used to difference of current and previous pressure values.
int triggerPressureValue = currentPressureValue - prevPressureValue;
if (triggerPressureValue < -10) {
brightness += 2;
}
// ---- CONDITIONAL CHECKS FOR LED STATES & BRIGHTNESS ---- //
if (ledStateFive) {
analogWrite(ledPinFive, computedBrightness);
if (computedBrightness > 190) {
ledStateFive = false;
ledCount += 1;
}
}
if (ledStateFour) {
analogWrite(ledPinFour, computedBrightness);
if (computedBrightness > 190) {
ledStateFour = false;
ledStateFive = true;
ledCount += 1;
brightness = 0;
}
}
if (ledStateThree) {
analogWrite(ledPinThree, computedBrightness);
if (computedBrightness > 190) {
ledStateThree = false;
ledStateFour = true;
ledCount += 1;
brightness = 0;
}
}
if (ledStateTwo) {
analogWrite(ledPinTwo, computedBrightness);
if (computedBrightness > 190) {
ledStateTwo = false;
ledStateThree = true;
ledCount += 1;
brightness = 0;
}
}
if (ledStateOne) {
analogWrite(ledPinOne, computedBrightness);
if (computedBrightness > 190) {
ledStateOne = false;
ledStateTwo = true;
ledCount += 1;
brightness = 0;
}
}
// ---- THE PROCESS AFTER ALL FIVE LEDS ARE LIT UP ---- //
if (ledCount == 5) {
brightness = 0;
while (completedTask < 10) {
for (int i=0; i<6; i++) {
analogWrite(ledPinOne, brightness);
analogWrite(ledPinTwo, brightness);
analogWrite(ledPinThree, brightness);
analogWrite(ledPinFour, brightness);
analogWrite(ledPinFive, brightness);
brightness += 18;
delay(20);
}
for (int i=0; i<6; i++) {
analogWrite(ledPinOne, brightness);
analogWrite(ledPinTwo, brightness);
analogWrite(ledPinThree, brightness);
analogWrite(ledPinFour, brightness);
analogWrite(ledPinFive, brightness);
brightness -= 18;
delay(20);
}
completedTask += 1;
}
// Reset variable values to repeat the experience
completedTask = 0;
ledCount = 0;
brightness = 0;
ledStateOne = true;
analogWrite(ledPinOne, 0);
analogWrite(ledPinTwo, 0);
analogWrite(ledPinThree, 0);
analogWrite(ledPinFour, 0);
analogWrite(ledPinFive, 0);
}
// ---- SETTING PREVIOUS PRESSURE VALUE WITH THE CURRENT VALUE BEFORE NEW LOOP ---- //
prevPressureValue = currentPressureValue;
}
