I have conducted user testing with my initial version of the project. The user tested my game twice, without instruction and with instruction later. Videos are attached below.

1. Are they able to figure it out? Where do they get confused and why? Do they understand the mapping between the controls and what happens in the experience?

On the first trial, the user had trouble understanding the point system and the order of the very first two mini-games. In my opinion, this happened due to the lack of a button/indicator that would instruct what to do next. Control mapping was understood, and the user has managed to figure out that the game is mouse-controlled, which is pretty straightforward, as he happens to be a frequent laptop/technology user. Yet, in a case where a person is not familiar with technology, control mapping can be difficult, which means that in further versions, I need to be clearer on the intent and instructions of the game.

2. What parts of the experience are working well? What areas could be improved?

I feel like the overall design of the game works pretty well, in user’s opinion it is aesthetically pleasing. What could be worked on, both from my brainstorming and user’s feedback, is the back/forth buttons that let you progress through the game, and more clarity of instructions, as well as clarity of the point system.

3. What parts of your project did you feel the need to explain? How could you make these areas clearer to someone who is experiencing your project for the first time?

After the initial testing, I had to explain that as soon as the user is done with the mini-games in that particular scene, the user has to click the bottom right button in order to progress to the next scene. In my opinion, I need to be clearer on the instruction of the game, for example including a brief overview of how the game works on the introductory page, or having a mini-tutorial on how the control works. It is also worth noting that the user took 1 minutes and 30 seconds to complete the game on the first try, while on the second try, after my instruction, the user took only 30 seconds to complete all of the tasks. The efficiency/time of completion increased x4, which means that providing valuable instructions is extremely important for a smooth user experience.

First trial of the game:

IMG_2807 2

Second trial of the game:

IMG_2809

My game is a two-player game, so I tested it on my younger brother and my mom. I gave them only brief instructions to give them some context, I informed them that it’s a two-player game, that they would use the buttons for the first 2 mini-games and the joysticks for the last game. For the first game, I just read out the text on the screen (TAP FAST) and they found it easy from there. I think what helped here is the feedback from the LEDs as well as their score going up live on the screen. Having some kind of responsive feedback reassures the user that they’re doing it correct. For the second game, I also read out the text on the screen (REACT FAST) and explained what they were reacting to (the LEDs lighting up). This explanation was sufficient for them to get the idea of the game. In addition, the responsive feedback from the LEDs and the text on the screen did guide them through the game.

The final game, and the one that probably needs the most improvements, is the maze. For this game, I did have to explain a bit more, specifically that they would need to move their characters using the joystick. A problem I’ve been having with the joysticks is that when they’re not held correctly, the movement direction is all messed up. That’s something I hope to fix by fixing how my project is presented, and manually orienting the joystick correctly so that it works as expected. Despite this, my mom was able to cross the maze and get to the other side. One other thing that I need to fix is the p5.js sketch for this specific game, I think the maze needs to be a lot bigger in size and probably have just one valid path so that it’s a speed-based competition to match the vibe of the other games.

I think adding brief instructions on the p5.js screen would guide my users better. Overall, my p5.js sketch is not fully complete yet, I’m still planning to change the aesthetics of the game and make the whole experience more seamless. There’s also some miscoordination between the which player is on which side, depending on how I orient the breadboard. So, in addition, changing the presentation of my arduino would also solve a few issues and make the game look more fun and less intimidating.

Video of my mom and brother attempting my game, I’ve just included short clips from each mini-game: user testing

I tested my project by asking my younger sister to try it out. I just opened the Tinkercad simulation without giving her any instructions. I just told her to explore it while I observed to see if the interaction was clear without any required instructions.

The first thing I noticed was that she pressed on the board and on everything randomly -this is because she doesn’t have any experience with Arduino or Tinkercad which is interesting because I haven’t thought of that. Her confusing and randomly clicking made it clear to me that not everyone understands these things. Anyways while she was experimenting she clicked on the dial and started experimenting with it and when she turned it on the LCD screen changed between the different stations of the cafe, rain, etc. So then she figured out everything overall.

She was also confused when experimenting because the RGB LED wasn’t very obvious to her at first. She saw it change color based on the different locations but she didn’t immediately connect it to the mood of each station she just thought it was light. Also the piezo buzzer was also a bit unclear because the sound is very basic and kind of weird on Tinkercad, so she was kind of confused… which makes me wonder if I should change my project a bit to make it sound differently.

Overall  this experiment allowed me to reflect and realize things I would have missed. I realized that the LCD screen is the strongest part of my project because it gives clear and direct feedback in which they can easily understand. I also think that it guides the entire experience but the sound and lighting need improvement because they are supposed to support the mood, not confuse them. So I’ll try to make the sounds better and try to make the colors more intentional so the user can understand the atmosphere without relying only on the text. Also I think adding the project name would be beneficial for participants to know at least what is happening or get a hint. Since it’s on Tinkercad of course it’s sad to know that I can’t really decorate and design it because while the actual product works I think design plays a huge role overall.

Video

• My main users are cats; they seem very intrigued by the shape and the way the 3D-printed cat feeder works. They were able to figure out that they should go to it when the food gets released. I am not sure whether they fully understand the mapping between the controls and what happens in the experience, but they seemed very invested in the process of me wiring and testing everything before gluing it together.
• 

  The servo works well. I discovered that my LCD display pins might have been misaligned by one pin, which caused the vital parts—GND and power—to be connected incorrectly, and it took me a while to figure out what was wrong. However, I switched to an LCD display I had from an older kit.

  For the human users, it is quite clear: they have a remote with an “OK” button on it. It was obvious that this is what they needed to click to dispense the cat food. The cats also seemed to understand that it dispenses food, but they are not that excited about it.

I decided to interview my cats to see their understanding between their controls and their experience, and their overall experience.

Cat 1: Bella: Refused to interview with me

The demo with people user: My sister was able to figure out it used when she saw the remote by clicking the “OK” button to release the food from the cat feeder.

Cat 3: Oreo: Provided a demo

User Interaction with project

For this exercise, I had my friend test my project without explaining the concept of project to him and recorded his reaction, asked his thoughts after the testing, explained the concept to him and he made some suggestions on how to improve the project.

The goal of the game was to match the sequence of the LED lights by pressing push switches. He struggled to find which LED corresponds to which switch because all the switches were of the same color. TinkerCAD does not give the option to change the color of the switch. I wanted to use colored switches to indicate which switch controlled which LED by matching the color of the LEDs but that was not successful. One he figured out which switch corresponds to the color of LED though he went on playing with the game.

Another thing my friend struggled with when playing my game was the feedback from the switch buttons. Since the game was virtual and done in TinkerCAD, he could not tell if he had successfully pressed the switch or not. This led to him pressing the buttons more times than he should have, giving him wrong outputs. This was a problem that run throughout the testing phase.

There was a potentiometer controlling the speed and level of the game but the user did not interact with it at all. It look isolated from the game system and his mind did not go to it at all. He was more focused on matching the pattern of the LEDs. He only interacted with it when I pointed it out after the testing.

Overall, he liked the idea of the game and the system behind it but struggled with the colors and the virtual interface of the project. He also suggest I used sound and light feedbacks when the buttons are pressed to alert the user.

I am glad the functionality of my project works, now for the final project, I need to find a way to direct the users attention to the levels possible and provide feedback of the the buttons with sound and light. For the colors of the switch, I am not sure of what to do of it next, but I need to find a way to let the user know the specific LED controlled by the switch if I cannot use colors of the LED.

User Interaction

User Interaction with my Project

For this stage, I had my brother test my project without explaining anything to him beforehand, and I recorded the interaction to see how he would naturally use it.

Overall, he understood most of it pretty quickly. He was able to figure out how to record audio, switch between modes, and use the buttons to trigger sounds. That made me feel like the core idea and interaction design are working well.

One of the main issues he noticed was with the sound samples, especially the piano and drums. They felt delayed when pressing the buttons, which made the system feel unresponsive. I realized this was because the audio files had a bit of silence at the beginning, so I went back and trimmed each sound manually so that they start exactly when the note or drum hit begins. That made a big difference in how responsive everything feels.

Another thing that confused him was the layout. The recordings were too close to the waveform visualization, which made the interface feel messy. Based on that, I moved all the recordings into a separate tab that you can open and close. That made the interface much cleaner and easier to understand.

He also tried to record the piano, drums, and bass directly, which wasn’t something I had implemented yet. At that point, the system only recorded audio from the microphone. This helped me realize that I needed to clearly separate those two types of recording. So I added two different options: one for recording voice through the mic, and another one for recording the full loop so it can repeat.

Another issue was that recordings kept accumulating and there was no way to delete them. He expected that to be possible, so I added a delete function inside the recordings panel.

In terms of understanding the system, everything else was pretty clear. The only thing he didn’t really understand was the potentiometer, mostly because he didn’t know what it was. The instructions explain it, but it’s still something that depends on the user’s familiarity with hardware.

Overall, his feedback was really helpful. It helped me fix small but important details like responsiveness, layout, and clarity.

At this point, the functionality is working really well. For the final version, I want to focus more on the design and make it feel more intentional and artistic, because right now it still looks pretty plain even though the interaction itself is solid.

Full p5js code till now

////// MUSIC PRODUCER FINAL //////

//INPUT FROM ARDUINO
let port;

let button1 = 0;
let button2 = 0;
let button3 = 0;
let button4 = 0;
let potentiometerValue = 0;

//STATE
let screen = "menu";
let mode = "piano";

//AUDIO SYSTEM
let mic, recorder;
let recordings = [];
let selectedRecordings = [];
let recordingNames = [];

// RECORDING STATES
let micRecording = null;
let loopRecording = null;
let isMicRecording = false;
let isLoopRecording = false;
let showRecordings = false;
let newRecordingAdded = false;

//SOUND LIBRARIES 
let pianoSounds = [];
let drumSounds = [];
let bassSounds = [];

//ACTIVE SOUND TRACKING (for button hold)
let activeSounds = {};

// UI ELEMENTS 
let connectButton, instructionsButton, startButton;
let bliseyFont;

// FFT VISUAL
let fft;

//LOAD ASSETS 
function preload() {

  bliseyFont = loadFont("Blisey.otf");

  pianoSounds[0] = loadSound("pianoC.mp3");
  pianoSounds[1] = loadSound("pianoD.mp3");
  pianoSounds[2] = loadSound("pianoE.mp3");
  pianoSounds[3] = loadSound("pianoF.mp3");

  drumSounds[0] = loadSound("kick.mp3");
  drumSounds[1] = loadSound("snare.mp3");
  drumSounds[2] = loadSound("hihat.mp3");
  drumSounds[3] = loadSound("clap.mp3");

  bassSounds[0] = loadSound("Bass1.mp3");
  bassSounds[1] = loadSound("Bass2.mp3");
  bassSounds[2] = loadSound("Bass3.mp3");
  bassSounds[3] = loadSound("Bass4.mp3");
}

//=== SETUP ===
function setup() {
  createCanvas(windowWidth, windowHeight);
  smooth();
  textFont(bliseyFont);

  port = createSerial();

  mic = new p5.AudioIn();
  mic.start();

  recorder = new p5.SoundRecorder();
  recorder.setInput(mic);

  fft = new p5.FFT(0.9, 128);

  setupMenu();
}

//=== MENU ===
function setupMenu() {
  removeAllButtons();

  instructionsButton = createButton("INSTRUCTIONS");
  instructionsButton.position(width/2 - 80, height/2);
  instructionsButton.mousePressed(goToInstructions);

  startButton = createButton("GET STARTED");
  startButton.position(width/2 - 80, height/2 + 50);
  startButton.mousePressed(goToMain);

  connectButton = createButton("CONNECT");
  connectButton.position(20, 20);
  connectButton.mousePressed(() => port.open(9600));
}

//== NAVIGATION ===
function goToInstructions() {
  removeAllButtons();
  screen = "instructions";

  let backButton = createButton("BACK");
  backButton.position(20, height - 60);
  backButton.mousePressed(setupMenu);
}

//=== MAIN INTERFACE ==
function goToMain() {
  removeAllButtons();
  screen = "main";

  // recordings tab toggle
  let recordingsTab = createButton("RECORDINGS");
  recordingsTab.position(20, 100);
  recordingsTab.mousePressed(() => {
    showRecordings = !showRecordings;
    newRecordingAdded = false;
  });

  // mic recording (voice only)
  let micButton = createButton("🎤");
  micButton.position(40, height - 180);
  micButton.size(70, 70);
  micButton.mousePressed(toggleMicRecording);

  // loop recording (full system)
  let loopRec = createButton("REC LOOP");
  loopRec.position(width/2 - 100, height - 100);
  loopRec.size(120, 50);
  loopRec.mousePressed(startLoopRecording);

  let loopStop = createButton("STOP LOOP");
  loopStop.position(width/2 + 40, height - 100);
  loopStop.size(120, 50);
  loopStop.mousePressed(stopLoopRecording);

  // mode selection
  let pianoButton = createButton("🎹");
  pianoButton.position(width - 100, 100);
  pianoButton.size(60, 60);
  pianoButton.mousePressed(() => mode = "piano");

  let drumsButton = createButton("🥁");
  drumsButton.position(width - 100, 180);
  drumsButton.size(60, 60);
  drumsButton.mousePressed(() => mode = "drums");

  let bassButton = createButton("🎸");
  bassButton.position(width - 100, 260);
  bassButton.size(60, 60);
  bassButton.mousePressed(() => mode = "bass");
}

//=== CLEAN BUTTONS ===
function removeAllButtons() {
  selectAll('button').forEach(b => b.remove());
}

//=== SERIAL READ ===
function readSerial() {
  let data = port.readUntil("\n");

  if (data) {
    let values = data.trim().split(",");

    if (values.length == 5) {
      button1 = int(values[0]);
      button2 = int(values[1]);
      button3 = int(values[2]);
      button4 = int(values[3]);
      potentiometerValue = int(values[4]);
    }
  }
}

//=== MIC RECORDING ===
function toggleMicRecording() {
  userStartAudio();

  if (!isMicRecording) {
    micRecording = new p5.SoundFile();
    recorder.record(micRecording);
    isMicRecording = true;
    port.println("LED:1");
  } else {
    recorder.stop();
    recordings.push(micRecording);
    recordingNames.push("Recording " + recordings.length);
    newRecordingAdded = true;
    isMicRecording = false;
    port.println("LED:0");
  }
}

//=== LOOP RECORDING ===
function startLoopRecording() {
  userStartAudio();

  loopRecording = new p5.SoundFile();
  recorder.record(loopRecording);

  isLoopRecording = true;
  port.println("LED:1");
}

function stopLoopRecording() {
  recorder.stop();

  recordings.push(loopRecording);
  recordingNames.push("Recording " + recordings.length);
  newRecordingAdded = true;

  loopRecording.loop(); // auto loop after recording

  isLoopRecording = false;
  port.println("LED:0");
}

//=== MAIN DRAW LOOP ===
function draw() {
  background(0);
  readSerial();

  if (screen === "menu") drawMenu();
  if (screen === "instructions") drawInstructions();
  if (screen === "main") drawMain();
}

//=== MENU DRAW ===
function drawMenu() {
  fill(255);
  textAlign(CENTER);
  textSize(40);
  text("MUSIC PRODUCER", width/2, height/3);
}

//=== INSTRUCTIONS DRAW ===
function drawInstructions() {
  fill(255);
  textAlign(CENTER);
  textSize(18);

  text(
`You are a DJ.

Record your voice and build music on top of it.

• Mic = voice recording
• Loop = full system recording

• Modes:
🎹 piano
🥁 drums
🎸 bass

• Buttons = trigger sounds
• Potentiometer = pitch control
• LED:
Red = idle
Green = recording`,
  width/2,
  height/2
  );
}

//=== MAIN DRAW ===
function drawMain() {
  noStroke();
  fill(255);
  textAlign(CENTER);
  textSize(30);
  text("MODE: " + mode, width/2, 60);

  drawWave();

  // recordings panel
  if (showRecordings) {
    
    noStroke();
    fill(20);
    rect(0, 150, 250, height);
    
    noStroke();
    fill(180);
    textAlign(CENTER);
    textSize(12);
    text("double click to rename a recording", 125, 170);

    textAlign(LEFT);

    for (let i = 0; i < recordings.length; i++) {
      let y = 200 + i * 40;

      fill(selectedRecordings.includes(i) ? "#00ff99" : 255);
      text(recordingNames[i], 20, y);
    }

    // delete button (panel only)
    let deleteX = 200;
    let deleteY = height - 60;
    
    noStroke();
    fill(120);
    rect(deleteX, deleteY, 30, 30, 5);

    noStroke();
    fill(255);
    textAlign(CENTER, CENTER);
    textSize(8);
    text("delete", deleteX + 15, deleteY + 15);
  }

  // new recording indicator
  if (newRecordingAdded) {
    
    fill(255, 200, 0);
    ellipse(140, 115, 10);
  }

  // pitch control for selected recordings
  let speed = map(potentiometerValue, 0, 1023, 0.5, 2);

  for (let i of selectedRecordings) {
    recordings[i].rate(speed);
  }

  handleButtons();
}

//=== AUDIO VISUALIZATION ===
function drawWave() {

  let waveform = fft.waveform();

  noFill();
  strokeWeight(3);

  stroke(255); drawLine(waveform, 0);
  stroke(0,255,200); drawLine(waveform, 40);
  stroke(255,100,100); drawLine(waveform, -40);
  stroke(100,100,255); drawLine(waveform, 80);
}

function drawLine(wave, offset) {

  beginShape();

  for (let i = 0; i < wave.length; i++) {
    let x = map(i, 0, wave.length, 0, width);
    let y = height/2 + wave[i] * 150 + offset;
    curveVertex(x, y);
  }

  endShape();
}

//=== HARDWARE BUTTONS ===
let p1=0,p2=0,p3=0,p4=0;

function handleButtons() {

  handleHold(1, button1);
  handleHold(2, button2);
  handleHold(3, button3);
  handleHold(4, button4);

  p1=button1; p2=button2; p3=button3; p4=button4;
}

//=== SOUND TRIGGER ===
function handleHold(n, state) {

  let sound;

  if (mode === "piano") sound = pianoSounds[n-1];
  if (mode === "drums") sound = drumSounds[n-1];
  if (mode === "bass") sound = bassSounds[n-1];

  if (state && !activeSounds[n]) {
    sound.play();
    activeSounds[n] = true;
  }

  if (!state && activeSounds[n]) {
    activeSounds[n] = false;
  }
}

//=== MOUSE INTERACTION ===
function mousePressed() {

  if (!showRecordings) return;

  for (let i = 0; i < recordings.length; i++) {

    let y = 200 + i * 40;

    if (mouseX < 250 && mouseY > y - 20 && mouseY < y + 20) {

      if (selectedRecordings.includes(i)) {
        recordings[i].stop();
        selectedRecordings = selectedRecordings.filter(r => r !== i);
      } else {
        recordings[i].loop();
        selectedRecordings.push(i);
      }
    }
  }

  // delete button click
  let deleteX = 200;
  let deleteY = height - 60;

  if (
    mouseX > deleteX &&
    mouseX < deleteX + 30 &&
    mouseY > deleteY &&
    mouseY < deleteY + 30
  ) {
    deleteSelected();
  }
}

//=== RENAME RECORDINGS ===
function doubleClicked() {

  if (!showRecordings) return;

  for (let i = 0; i < recordings.length; i++) {

    let y = 200 + i * 40;

    if (mouseX < 250 && mouseY > y - 20 && mouseY < y + 20) {

      let newName = prompt("Rename recording:");
      if (newName) {
        recordingNames[i] = newName;
      }
    }
  }
}

//=== DELETE RECORDINGS ===
function deleteSelected() {

  selectedRecordings.sort((a, b) => b - a);

  for (let index of selectedRecordings) {
    recordings[index].stop();
    recordings.splice(index, 1);
    recordingNames.splice(index, 1);
  }

  selectedRecordings = [];
}

Context beforehand from my side:

For this IM Project, as I wanted to emulate the vibe of an Escape Room I deliberately didn’t make it as obvious what was supposed to be done. When you try to solve a puzzle, obviously you’re not supposed to spoonfeed the answer so I kept it kind of vague as to what was needed to be done. For my user testing, I asked my sister to try it out and see how she felt about it. But what I also should mention is that, she didn’t have really any knowledge of what Tinkercad is and its various components, so she went in completely blind.

Video of the User Testing (My sister):

Feedback from The User Testing:

In the end, she was able to figure it out on her own. From her feedback to me, she mentioned that she didn’t understand what each component meant. She understood the keypad and from prior knowledge, knew she needed to enter a code, however she did not know what the LED was or what its function was. She did in fact understood that she could twist and turn the potentiometer, but after she played around with them a little bit.

I think the experience overall is working well. The connections between components worked out and all of the components reacted on time. In terms of any imporvements, if I’m honest I think you could definitely add something that’s much more visually appealing like an LCD screen, however I faced issues with it and also didn’t understand how to connect all of it to the Arduino Uno so I omitted it in place of the serial monitor. And another thing, I think if there were more components added, then the experience wouldn’t be as mysterious for it’s own little puzzle to solve.

From parts I needed to explain, it was mostly grounded in telling her what each component was as she did not have any idea what they were. For any new user that might not be well versed in Tinkercad, that would definitely be a common problem. But I think the best way to mitigate this, is to simply have speech bubbles or a list of instructions (most likely in the description of the Tinkercad Project), explaining the main goal and the options the user can do to reach it. In this case of this, the end goal would be to figure out the code, and the user will be told what each component does and that they’re able to twist the dial and enter a code on the keypad.

Building a Theremin-Style Musical Instrument with Arduino

For this week’s assignment, I built a simple musical instrument using an Arduino SparkFun RedBoard. The goal was to make something you actually play in real time, not just a melody that runs on its own.

The Idea

I wanted the instrument to feel intentional. You turn a knob to pick a pitch, then press a button to sound it. Release the button and it goes silent. It is a small but satisfying loop that mimics the feel of a real instrument. The design was loosely inspired by a theremin, where pitch is continuous and the player decides when to trigger sound.

Components

The build uses five parts: a SparkFun RedBoard, a piezo buzzer, a 10k ohm potentiometer, a tactile push button, and a breadboard with jumper wires. The potentiometer is the analog sensor and the button is the digital sensor, which together satisfy both requirements for the assignment.

Demo

The Code

The sketch reads the potentiometer value on every loop, maps it to one of 22 notes across a C major scale from C3 to C6, and plays that note with tone() only while the button is held down. No extra libraries are needed beyond pitches.h for the note frequencies.

#include "pitches.h"

const int BUZZER_PIN = 8;
const int BUTTON_PIN = 2;
const int POT_PIN    = A0;

int scale[] = {
  NOTE_C3, NOTE_D3, NOTE_E3, NOTE_F3, NOTE_G3, NOTE_A3, NOTE_B3,
  NOTE_C4, NOTE_D4, NOTE_E4, NOTE_F4, NOTE_G4, NOTE_A4, NOTE_B4,
  NOTE_C5, NOTE_D5, NOTE_E5, NOTE_F5, NOTE_G5, NOTE_A5, NOTE_B5,
  NOTE_C6
};
const int SCALE_SIZE = sizeof(scale) / sizeof(scale[0]);

void setup() {
  pinMode(BUZZER_PIN, OUTPUT);
  pinMode(BUTTON_PIN, INPUT_PULLUP);
  Serial.begin(9600);
}

void loop() {
  bool buttonHeld = (digitalRead(BUTTON_PIN) == LOW);
  int  potValue   = analogRead(POT_PIN);
  int  noteIndex  = map(potValue, 0, 1023, 0, SCALE_SIZE - 1);
  int  currentNote = scale[noteIndex];

  if (buttonHeld) {
    tone(BUZZER_PIN, currentNote);
  } else {
    noTone(BUZZER_PIN);
  }

  delay(20);
}

How It Works

The potentiometer outputs a voltage between 0V and 5V as the knob turns. analogRead() converts that into a number from 0 to 1023, and map() scales it down to an index between 0 and 21, selecting a note from the scale array. The button uses Arduino’s built-in INPUT_PULLUP setting, so it reads HIGH when open and LOW when pressed, with no external resistor required. While the button is held, tone() drives the buzzer at the selected frequency. Letting go calls noTone() and the sound stops immediately.

Reflections

The trickiest part was getting comfortable with the breadboard layout. Once that clicked, the wiring became straightforward. If I were to extend this project, I would add a second button to switch between different scales, which would open up more musical variety without much added complexity.

This text was fun to read, especially as someone somewhat interested in creating disability tech in the future. I agree with Barnes’ statement that “design depends largely on constraints.” We design projects to work around human problems. E.g. chairs are made of different heights because humans come in different heights, and want a chair they can sit on comfortably (which is their purpose). Headphones come in different styles because some people prefer overhead while others prefer buds that go inside your ears instead. So, when we go into designing for problems, we can’t just look at the surface level problem. We need to dig deeper, which is what a lot of designs fail to do, especially in relation to disability and accommodation. I found it interesting that disability inspired good design and not the other way around, because I would have expected it to be the other way.

Regarding the paragraph titled “discretion,” I have also wondered about this. I liked this quote a lot in the text too: “mediocrity can result in people being further stigmatized by the very products intended to remove barriers.” Having a disability is already so frowned upon, so it is heartbreaking to see that design can further perpetuate this. A disability is a part of you, so why are we hiding that aspect and promoting shame? I’m glad today that we are going against this, for example, in making prosthetic limbs customized and flashy. I saw someone make their prosthetic leg look like a gun (not that I’m endorsing violence, but it’s cool nonetheless to customize and make statements with your disability that aren’t just statements related to that).

As a glasses wearer myself, it’s funny for me to see people wear fake glasses for the sake of fashion, or as the text puts it, wearing glasses as a “medical necessity” to a “key fashion accessory.” However, that also made me reflect that maybe, in my head, I have this belief that is actually supporting the incorrect belief that disability has to be something isolated. By encouraging glasses as a fashion statement, we are normalizing a disability, which is a thing we need to do more often, especially with other disabilities. I liked the point in the text where it states, “brightly colored frames exist, although they are still a minority taste.” While this is slowly decreasing today with the rise of “cool girls wearing funky frames,” I do agree that this was much more prevalent when I was younger (I was, in fact, victim to wireless rectangle glasses that made me look at least 5 years older than I actually was.) Hearing aids is actually something I wanted to talk about before I completely finished reading the text, because people did try and hide the fact that they were wearing hearing aids earlier, but now, singers use earplugs that look similar to hearing aids all the time to prevent becoming deaf. Interesting. (Another thing I find intriguing as a person with disabilities: there are many times where things aren’t socially acceptable until a person (or multiple) of a high social standing do something.)

When you design something, it is highly unlikely that your product is accessible to every single person on Earth, whether it be for people with certain disabilities, or even people without. I liked the example of the flying submarine, or any product that has so many features but become overburdened. It reminded me a lot of apps that have way too many features to be accommodative, but end up becoming overwhelming instead. By trying to solve one problem, you cause another problem instead. I never thought that by removing features you can make things more accessible, so I liked reading that point.

Disabilities are very complex, and the word itself is an umbrella term for so many things. Thus, disability is not monolithic, and not heterogeneous. Ultimately, there is no fixed way to decide how to design to accommodate, so the best thing we, as designers, can do is understand who our product aims to benefit, and whether this product would benefit from a more simplistic, complex, bright or subtle design. That’s what makes every designer and their work different to others: how we decide to think when we face a problem.