Exercise:
Revisit Definition of a prototype:
How has your understanding of prototyping changed since week 1:
My understanding of prototyping has changed somewhat since week 1. My overall understanding of prototyping remains the same: that prototypes are creations designed to rapidly evaluate the viability of concepts, either in small parts or as a whole. I have gained a better understanding of the various ways prototyping can be gone about, and specifically which types of prototypes and prototype evaluations work for specific goals.
What would you change about your initial description:
I would not change a great deal of my initial description of prototyping. I would mostly emphasise more greatly the importance of the testers in the prototype, as well as the expectations of the type of feedback expected from a prototype and how that informs the decisions made in creating the prototype.
How is that related to your experiences:
Over the course of all of my prototypes, my experience was that I often forgot to consider what I would be asking of my testers until after I had created my prototype. Looking back on this decision now, I notice that this led to me deciding what I was testing based on what I had made, rather than making something to allow me to test specific things. In the future, I would come up with my testing methods and goals concretely before designing my prototype.
michael_deco2300_blog
Friday, 28 October 2016
Sunday, 9 October 2016
Week 11
Exercise:
Generate concepts for contently reproducing 3d movement in space that allows a musical composition to be accurately played on a theremin.
Concept 1:
A projector set up to project hand positions such that a player sitting at the theremin can line their hands up with the board the projector is positioning their hands on. Projecting different lines allows the musician to move their hands to play the song.
Record notes slowly by finding the note than recording the hand position by adjusting where the projector is projecting.
Concept 2:
Have a pair of armbands linked to the theremin. The armbands record their relative position to the theremin while playing, then use LEDs of different colours to indicate how the player should move their hands. (e.g. red for down, orange for up, blue for left, green for right).
Criteria for Pugh matrix:
- Ease to record music
- Ease to 'read' recorded music
- Accuracy of recording/playback
Pugh matrix:
Generate concepts for contently reproducing 3d movement in space that allows a musical composition to be accurately played on a theremin.
Concept 1:
A projector set up to project hand positions such that a player sitting at the theremin can line their hands up with the board the projector is positioning their hands on. Projecting different lines allows the musician to move their hands to play the song.
Record notes slowly by finding the note than recording the hand position by adjusting where the projector is projecting.
Concept 2:
Have a pair of armbands linked to the theremin. The armbands record their relative position to the theremin while playing, then use LEDs of different colours to indicate how the player should move their hands. (e.g. red for down, orange for up, blue for left, green for right).
Criteria for Pugh matrix:
- Ease to record music
- Ease to 'read' recorded music
- Accuracy of recording/playback
Pugh matrix:
|
|
Weighting
|
Basic music notes
|
Projecter system
|
Armbands system
|
|
Ease to record music
|
1
|
0
|
-1
|
3
|
|
Ease to read music
|
2
|
0
|
1
|
-1
|
|
Accuracy of playback
|
2
|
0
|
2
|
-1
|
Saturday, 1 October 2016
week 10
Exercise:
This weeks exercise was to discuss experience prototypes using a video of a payment method concept for paying for restaurant meals in a group.
Q1: What is the existing experience from different viewpoints (customers, waiters, chef, etc):
The customers experience is that paying group bills becomes easier, as the group does not have to discuss how much each individual owes, but can simply pass the device around with each member selecting their own parts to pay for. The customers can also choose alternative payment methods that best suit them, allowing for a more diverse payment system. This device makes it much easier for customers to relax after their meal, rather than worrying over the bill.
The waiters experience is that customers can sort their bills out faster, and have less chance of customers calculating the tip incorrectly. Waiters can also request certain payment methods for tips (ie, requesting reward points rather than cash), allowing them to tailor their tips to suit themselves more. This device makes life easier for waiters.
Q2: What external/internal factors impact on the experience:
The internal factors are group dynamics, such as an individual who may want to dispute what they ordered, or an individual forgetting they ordered something, leading to the full bill not being paid (leading to an argument in the group over who owes what).
The external factors would include the restaurants willingness to take reward points or other non-cash payment methods.
Q3: What aspects of the existing experience could be enhanced/augmented or supported with technology:
A device that shows the progress of their meal in the kitchen (eg, ordered... preparing... cooking... waiting on watier... on route to table... etc). The device would allow users to estimate how long they will be waiting on their food and could spark group discussions about the proceedings in the kitchen.
Q4: How would introducing technology in to this context change the experience:
Introducing technology into restaurants could improve the ease and relaxation of customers, simplify proceedings for waiters and make the restaurant more approachable.
Q5: what expereince scenarios might you test with the technology:
A good scenario to test would be during a peak time for a popular restaurant (possibly friday night for example), where lots of customers would be expected, probably coming in groups. Another good scenario to test would be during a lunch rush, where lots of customers want to be coming and leaving fairly quickly.
This weeks exercise was to discuss experience prototypes using a video of a payment method concept for paying for restaurant meals in a group.
Q1: What is the existing experience from different viewpoints (customers, waiters, chef, etc):
The customers experience is that paying group bills becomes easier, as the group does not have to discuss how much each individual owes, but can simply pass the device around with each member selecting their own parts to pay for. The customers can also choose alternative payment methods that best suit them, allowing for a more diverse payment system. This device makes it much easier for customers to relax after their meal, rather than worrying over the bill.
The waiters experience is that customers can sort their bills out faster, and have less chance of customers calculating the tip incorrectly. Waiters can also request certain payment methods for tips (ie, requesting reward points rather than cash), allowing them to tailor their tips to suit themselves more. This device makes life easier for waiters.
Q2: What external/internal factors impact on the experience:
The internal factors are group dynamics, such as an individual who may want to dispute what they ordered, or an individual forgetting they ordered something, leading to the full bill not being paid (leading to an argument in the group over who owes what).
The external factors would include the restaurants willingness to take reward points or other non-cash payment methods.
Q3: What aspects of the existing experience could be enhanced/augmented or supported with technology:
A device that shows the progress of their meal in the kitchen (eg, ordered... preparing... cooking... waiting on watier... on route to table... etc). The device would allow users to estimate how long they will be waiting on their food and could spark group discussions about the proceedings in the kitchen.
Q4: How would introducing technology in to this context change the experience:
Introducing technology into restaurants could improve the ease and relaxation of customers, simplify proceedings for waiters and make the restaurant more approachable.
Q5: what expereince scenarios might you test with the technology:
A good scenario to test would be during a peak time for a popular restaurant (possibly friday night for example), where lots of customers would be expected, probably coming in groups. Another good scenario to test would be during a lunch rush, where lots of customers want to be coming and leaving fairly quickly.
Saturday, 17 September 2016
Week 8
Exercise:
This weeks exercise was to come up with come up with 5 physical interactions for controlling 3 applications. The interactions were supposed to map onto and/or into physical objects and actions.
Application 1, Email:
1. Send email function served by placing a slip of paper into an envelope
2. Forward email served by placing an envelope into a 'outgoing' box, with the intended recipient written onto it.
3. Open attachments by removing a slip of paper from an envelope.
4. Finger print scanner to log in to email
5. Delete email by placing envelope into trash bin.
Application 2, Twitter:
1. Start a new tweet by whistling a tweet sound
2. Like a tweet by giving a thumbs up to a webcam
3. write tweet by speaking out loud
4. send tweet by clapping hands
5. search hashtags by voice recognition
Application 3, Super Mario Bros:
1. Lean left/right to move left or right (hard lean to run)
2. Jump to make mario jump
3. crouch to make mario crouch/enter pipe
4. make throwing gesture to throw fire after getting fire flower powerup
5. voice recognition on "Its-a me, Mario" to start game
This weeks exercise was to come up with come up with 5 physical interactions for controlling 3 applications. The interactions were supposed to map onto and/or into physical objects and actions.
Application 1, Email:
1. Send email function served by placing a slip of paper into an envelope
2. Forward email served by placing an envelope into a 'outgoing' box, with the intended recipient written onto it.
3. Open attachments by removing a slip of paper from an envelope.
4. Finger print scanner to log in to email
5. Delete email by placing envelope into trash bin.
Application 2, Twitter:
1. Start a new tweet by whistling a tweet sound
2. Like a tweet by giving a thumbs up to a webcam
3. write tweet by speaking out loud
4. send tweet by clapping hands
5. search hashtags by voice recognition
Application 3, Super Mario Bros:
1. Lean left/right to move left or right (hard lean to run)
2. Jump to make mario jump
3. crouch to make mario crouch/enter pipe
4. make throwing gesture to throw fire after getting fire flower powerup
5. voice recognition on "Its-a me, Mario" to start game
Saturday, 10 September 2016
Week seven
Exercise:
This weeks exercise was to revist the user-testing questions asked for the video prototype.
Specifically, which questions where quantitative and which were qualitative, did the questions fall into any previously outlined traps, and how could the questions be rephrased?
Video prototype questions:
Q1 Could you explain you’re interpretation of the concept?
Q2 Is this a game you think you would play?
Q3 How do you feel about the physical ship model as an interaction method?
Q4 Do you have any suggestions for features you would like to see added to the concept?
Which where quantitative/qualitative?:
all of the questions asked where qualitative.
Did any of the questions fall into previously outlined traps?
The questions asked where possibly too open ended, making the feedback gathered be less focused. Some of the questions could have been rephrased and given specific options to choose from as answers to provide better feedback.
How could the questions be rephrased?
Question 3 could have been rephrased to say 'how comfortable would you be interacting with the game using a model of a ship' with possible answers being 'very comfortable, somewhat comfortable, neutral, uncomfortable or very uncomfortable'.
Question 2 could have been rephrased as 'How likely would you be to play this game?' with answer options being 'Very likely, somewhat likely, if invited by a friend, unlikely, never'
This weeks exercise was to revist the user-testing questions asked for the video prototype.
Specifically, which questions where quantitative and which were qualitative, did the questions fall into any previously outlined traps, and how could the questions be rephrased?
Video prototype questions:
Q1 Could you explain you’re interpretation of the concept?
Q2 Is this a game you think you would play?
Q3 How do you feel about the physical ship model as an interaction method?
Q4 Do you have any suggestions for features you would like to see added to the concept?
Which where quantitative/qualitative?:
all of the questions asked where qualitative.
Did any of the questions fall into previously outlined traps?
The questions asked where possibly too open ended, making the feedback gathered be less focused. Some of the questions could have been rephrased and given specific options to choose from as answers to provide better feedback.
How could the questions be rephrased?
Question 3 could have been rephrased to say 'how comfortable would you be interacting with the game using a model of a ship' with possible answers being 'very comfortable, somewhat comfortable, neutral, uncomfortable or very uncomfortable'.
Question 2 could have been rephrased as 'How likely would you be to play this game?' with answer options being 'Very likely, somewhat likely, if invited by a friend, unlikely, never'
Saturday, 20 August 2016
Prototype Concept Explanation
The prototype I will be making for this course is a game mashup between 'guess who' and 'space invaders', called 'Guess Invaders'.
Players will play the game using a physical model of a spaceship, a number of physical 'feature' pieces that fit onto the ship (e.g. an antennae, portholes, a laser gun, etc), and a number of portraits of ships with different features on them.
The goal of the game is to stop the spaceship from reaching the bottom of the screen by flipping the correct ship portrait. Players figure out which portrait is the correct one by playing the physical feature pieces onto the model of the ship. If the invading ship has that feature, it will now display that feature on the screen, otherwise the game will indicate that the invader does not have that feature. Each time a feature is placed on the model, the invader ship will move towards the bottom of the screen faster, reducing the time players have to determine which portrait they should flip.
As players place more features onto the ship model, they will get a better idea of which invader they are facing, and will be able to narrow down the invaders in the portraits. Once the player has a good enough idea of the invader they are facing, they can flip a portrait of an invader down. If the flipped portrait matches the attacking invader, the player wins the game. If they guess wrong however, they will lose. Players also lose if the invader reaches the bottom of the screen before they flip a portrait.
Players will play the game using a physical model of a spaceship, a number of physical 'feature' pieces that fit onto the ship (e.g. an antennae, portholes, a laser gun, etc), and a number of portraits of ships with different features on them.
The goal of the game is to stop the spaceship from reaching the bottom of the screen by flipping the correct ship portrait. Players figure out which portrait is the correct one by playing the physical feature pieces onto the model of the ship. If the invading ship has that feature, it will now display that feature on the screen, otherwise the game will indicate that the invader does not have that feature. Each time a feature is placed on the model, the invader ship will move towards the bottom of the screen faster, reducing the time players have to determine which portrait they should flip.
As players place more features onto the ship model, they will get a better idea of which invader they are facing, and will be able to narrow down the invaders in the portraits. Once the player has a good enough idea of the invader they are facing, they can flip a portrait of an invader down. If the flipped portrait matches the attacking invader, the player wins the game. If they guess wrong however, they will lose. Players also lose if the invader reaches the bottom of the screen before they flip a portrait.
Week 4
Exercise
This weeks exercise was to discuss the differences between high fidelity prototypes and low fidelity prototypes.
Exercise 1:
Elements of a car dashboard:
Steering wheel, volume control, aircon control, radio control, speedomoter, gas meter, gps, radio controls, air vents, windscreen wiper controls, window controls, horn, air vents, hazard lights button
Which compononents are relevant to driving behaviour:
Steering wheel, speedometer, gas meter, windscreen wiper controls, horn
What are the interactions of those components with the driver when driving:
The driver interacts with the steering wheel physically to redirect the car
The driver reads the speedometer and gas meter to adjust there driving behaviour
the driver interacts with the windscreen wiper controls and horn in response to external effects
What goal is implied by these specific questions:
These questions imply the goal of getting the car from one point to another by driving it, using it as a method of transport.
Are there other goals:
Yes. There are goals like 'making passengers comfortable' and 'keeping the driver awake'.
What would you test and how:
I would test the aircon controls using a vertical prototype, being a full replication of the aircon interaction system, with a simple seat+driving wheel mockup for the driver to sit in and feel like they are in a car while interacting with the aircon controls.
I would test that the controls are within reach of the driver easily, can be reached quickly and accurately, and can be manipulated by the driver without looking at the controls.
I would also test the responsiveness of the aircon and how quickly the user reacts to it.
The method of testing would be to place the tester in the driver seat of the car, ask them to pretend they are driving and need to do various things to the air con (ie, make the car colder/hotter, switch airflow modes, etc), then observe their interactions.
Exercise 2:
Horizontal prototype:
The phone allows setting and deleting alarms
The phone rings alarms one after another if an alarm is not stopped
The phone allows 2 different alram tones
The phone has a button to end alarms and one too snooze alarms
Vertical prototype:
The phone has an interface for setting, deleting and editing alarms, whith features like a calender for setting alarms for specific dates, and 'quick change' mode that allows the timeing of multiple alarms to be quickly edited.
Diagonal prototype:
The phone allows for shaking the phone to snooze alarms that ring when the app is opened.
This weeks exercise was to discuss the differences between high fidelity prototypes and low fidelity prototypes.
Exercise 1:
Elements of a car dashboard:
Steering wheel, volume control, aircon control, radio control, speedomoter, gas meter, gps, radio controls, air vents, windscreen wiper controls, window controls, horn, air vents, hazard lights button
Which compononents are relevant to driving behaviour:
Steering wheel, speedometer, gas meter, windscreen wiper controls, horn
What are the interactions of those components with the driver when driving:
The driver interacts with the steering wheel physically to redirect the car
The driver reads the speedometer and gas meter to adjust there driving behaviour
the driver interacts with the windscreen wiper controls and horn in response to external effects
What goal is implied by these specific questions:
These questions imply the goal of getting the car from one point to another by driving it, using it as a method of transport.
Are there other goals:
Yes. There are goals like 'making passengers comfortable' and 'keeping the driver awake'.
What would you test and how:
I would test the aircon controls using a vertical prototype, being a full replication of the aircon interaction system, with a simple seat+driving wheel mockup for the driver to sit in and feel like they are in a car while interacting with the aircon controls.
I would test that the controls are within reach of the driver easily, can be reached quickly and accurately, and can be manipulated by the driver without looking at the controls.
I would also test the responsiveness of the aircon and how quickly the user reacts to it.
The method of testing would be to place the tester in the driver seat of the car, ask them to pretend they are driving and need to do various things to the air con (ie, make the car colder/hotter, switch airflow modes, etc), then observe their interactions.
Exercise 2:
Horizontal prototype:
The phone allows setting and deleting alarms
The phone rings alarms one after another if an alarm is not stopped
The phone allows 2 different alram tones
The phone has a button to end alarms and one too snooze alarms
Vertical prototype:
The phone has an interface for setting, deleting and editing alarms, whith features like a calender for setting alarms for specific dates, and 'quick change' mode that allows the timeing of multiple alarms to be quickly edited.
Diagonal prototype:
The phone allows for shaking the phone to snooze alarms that ring when the app is opened.
Subscribe to:
Posts (Atom)