Monday, 9 November 2015

Interactive Prototype III: Testing

Outcomes

Users were asked to play a basic version of the game using a modified stick to tap coloured balls of play dough and then provide feedback.  The coloured dots on the screen corresponded to coloured balls of dough.  Users had 25 seconds to complete 25 dots. The screen displayed a countdown timer, the user's high score, and the background colour changed every 5 seconds from yellow to navy to simulate sunset.

Users played the game multiple times, generally three times.  All wanted to beat their previous score by playing again.  Less than half the users (3/7) tested noticed the background colour changing.

I measured user feedback through observation, in-person questions and an online questionnaire. The data from these measures can be found here.

I wanted to know:
  • how the background colour changing simulate the change in time, specifically from daytime to nighttime (in lieu of an actual sun being on the stage), and
  • if users like being able to see their high score on the screen (they had previously remembered them).

Reflections

The format of the prototype worked well with the 'wacky stick' being a reliable game controller that allowed me to test other aspects of the game without resorting back to keyboard controls.

It was useful to be near the users when they filled out their survey to see their surprise that the background colour changed, some even went back and started playing agin just to see that it was true.  I received solid feedback and agreement that adding the high score to the stage was useful.  Users also commented on how fun the game was without prompting.

The testing protocol went smoothly, I felt much more confident at this last prototype delivering consistent instructions to users without relying on a script and talking through the various aspects of the game.Feedback received indicated that I gave clear instructions but I could have possibly asked different questions like "did the session flow in a logical way".

Effectiveness

The prototype worked really well and I received clear feedback on the use of high scores and changing colour background.  Many users did not notice the coloured background but still found the game well paced and responded to running out of time.  I am interested in whether the changing background is necessary to show the passage of time at all or if it could/should be more obvious (i.e. through other elements).

Constraints

By having an easier-to-build but more reliable controller for this prototype, I was less reliant on the input method for testing.  This meant I could successfully test the items I wanted to without interference.  It was interesting how users responded so positively to the stick controller, it has made me reconsider the input method entirely.

Implications

Changes to my concept

  • possibly add other indicators of time passing like music getting faster or time flashing
  • test different input methods (e.g. foot pads vs wacky stick)

Future prototypes

     Future prototypes
    • on-screen feedback for wrong control pressed (not just sound)
    • add movement to cat (e.g. jumping on press)
    • add sun rising and setting to stage (would this make the changing background colour more noticeable, does it need to be noticeable)
    • make start/stop easier (enter or other control)
    • add in the extra bits (power-ups, levels, etc) 

Future testing sessions

  • Wider range of users, maybe children

Interactive Prototype III: Testing Data

Here is the raw data from the testing sessions that were run for the Interactive Prototype 3 of Meow Meow Cat.  The data forms two parts, the observations recorded during the session and the questionnaire users filled out.

Testing session: 9 November, in-class session

Users:
  • 7 total
  • 4 male, 3 female

Observations
User #1 
  • played 3 games 
  • “I have to memorise where the different colour are” 
  • “oh damn, I hit the wrong button"
  • times (seconds): 
    • 8, 7, 11
User #2
  • played 3 games 
  • Do you want another go -> “Yes!”
  • On the second go, user reset game themselves which caused an error.  (Code is set up so you have to end game then reset)
  • times (seconds): 
    • 16, x, 11
User #3
  • played 2 games 
  • Body language response to being told that they have 25 seconds to complete 25 dots – apprehensive, tense, excited
  • After 1st go -> I ned to see if I can beat my time
  • times (seconds): 
    • 13, 13
User #4
  • played 3 games 
  • times (seconds): 
    • 12, 9, 13
User #5
  • played 2 games 
  • “This tech is hardcore” in response to the stick
  • “oh, this is fun”
  • didn’t notice background colour change
  • times (seconds): 
    • 8, 12
User #6
  • played 3 games 
  • “play another round? Definitely!” 
  • “see if I can beat my highest score"
  • times (seconds): 
    • 11, 15, 16
User #7
  • played 3 games 
  • “did the background change?”
  • “my first time was my best – weird”
  • Clarified how the scoring worked
  • times (seconds): 
    • 13, 10, 9

Observation overview
  • Stick/play dough combination worked really well, users seemed to find it fun to use/play
  • Many commented that they didn’t notice the background colour change until they were prompted in the survey and some even went back to check
  • Most wanted to play to beat their score
  • Game played 19 times
  • Times:
    • Highest Score: 16 seconds
    • Lowest Score: 7 seconds
    • Average Score: 11.5 seconds

Questionnaire results
Total responses: 7

Q1. Were you aware that time was running out during the game? 

Yes - 6 users

No - 1 user

Q2. What indicated this to you?
  • The number in the top left corner and by the score at the end
  • Timer at top
  • The counter at the top of the screen
  • There was a timer in the top corner. Which I did not actually look at, and then the background colour would also change. 
  • Was there a ticking clock going on in the background, that made me fele like the pressure was on? 
  • I was too absorbed in the game
  • When you told me.

Q3. Do you remember your best time?

Yes - 7 users

Q4. Was it helpful to have an on-screen record of your best time?

Yes - 7 users


Q5. Did you notice the background colour changing?

Yes - 3 users
No - 4 users

Q6. What did the background colour represent to you?
  • i was too focused on the dots!
  • I thought it stayed the same color yellow
  • Getting closer to the end of the time allowed and the end of the game - increasing urgency.
  • Stress! It made me think I was running out of time, but I was not sure how many times it would change or how much longer I had left when the colour changed.
  • I didn't notice it was changing, I was focused on the colours.
  • The questionable state of western foreign relationships within the middle-east
Q7. How would you describe the instructions for this testing session?
Scale: 1 'Clear - it was easy to understand what to do' to 5 'Confusing - I did not understand what to do'
1: Clear - 7 users
Q8. Any other comments?
  • It was very fun and made me want to keep playing to improve my score
  • Really liked your game. It was lots of fun. I tested all your prototypes and have definitely gotten quicker!
  • It was fun - a good quick game.
  • Whacky Stick! Perhaps some sort of instruction on how many colour changes there would be before time ran out or if the background music was to increase in speed to indicate that time was getting closer and closer to running out.
  • There was really fun, simple yet clean and effective. 
  • fun game
  • I loved the fact that is was so fast paced. After trying my luck the first time I definitely wanted to beat my highest my score.
Questionnaire overview

Most or all users could agree that:
  • my instructions were clear (7/7)
  • they were aware time was running out (6/7)
  • the timer showed them this (5/7)
  • they could remember their best time (7/7)
  • they liked having an on-screen record of their best time (7/7)
  • it was fun (6/7 mentions in free comments)
However, it was almost half and half about the changing coloured background.
  • 4/7 did not notice the change at all (many were surprised when they got to this question)
  • those that did notice said it added to their sense of urgency
  • Suggestions include:adding other elements to show end of time approaching 
    • increase music speed
    • graphic of sun setting over 'sky
    • flashing timer of 5 seconds to go
The 'whacky stick' interaction also seemed to be popular and successful even though it was not specifically tested in this prototype.

Friday, 30 October 2015

Week 13: Building IP3

For this prototype, I decided to keep iterating the concept and test different features.

I started by going over what I wanted to achieve from this prototype and features I had not yet developed including:

  • change in timer from counting up (record how long it takes a user to complete a level) to counting down (users only have a set time to complete the level).
  • change background colour to simulate sunset and passing of time
  • add high-scores to stage
  • add additional cue to which dot users are meant to press

I also thought about which controllers I would use and how the interaction would take place.  The floor-dots were great but unreliable and I didn't want to re-create them for this prototype.  I also didn't want to go back to using keyboard arrow controllers.  So, I looked for a simple way of having physical controllers for the game and went with playdough balls that corresponded to the colours of the dots on screen.  

When looking for colours for the background changes, I initially looked to blend yellow to navy.  They meant the 'middle' colours were really murky so I changed the colour steps to imitate sunset colours but also tried to avoid colours that were too close to the dot colours.  To help further with contrast, I also added a white outline to some dots to ensure they could still be easily seen on the screen. 

initial colour palette
final colour palette 

I was able to change the colours using a switch statement tied to the timer. The challenge I had wth adding the colours was resetting back to the start colour at the end of game.  To help me problem solve this, I had to draw out how the 'end game' functions interacted with each other as I had initially written this a few weeks ago so writting comments in code was definitely helpful.


 

Monday, 19 October 2015

Week 12: Interactive Prototype 3 - Final Prototype

What is the key function or interaction for your concept?

The user moves the character (Meow Meow Cat) forward through a series of coloured dots.  Users have a set amount of time to complete the game and are given visual cues through a timer and a changing background (from Daytime to nighttime).

I wanted to included a physical element to this prototype but without rebuilding the floor-dot-buttons from the previous prototype (or using the keyboard as an input).  Instead, I have continued to use the Makey Makey device but have substituted the dots you press with your feet for playdough you tap with your hands.

How does it work?

The user taps corresponding coloured balls of playdough to those displayed on screen.   A Makey Makey is used to connect the playdough controls with the computer.  A countdown timer is used to show users how long they have to complete a basic level (25 dots).  The background screen colour also changes colour with the timer to indicate the passage of time (sunshine to nighttime).  User's high scores are also displayed in the top left corner

What do you want to know about your prototype?

  • Does the background colour changing simulate the change in time, specifically from daytime to nighttime (in lieu of an actual sun being on the stage)
  • Do users like being able to see their high score on the screen (they had previously remembered them)

How do you want IP3 to work?

  1. A testing computer is set-up connected to playdough through a Makey Makey device.
    1. Four coloured balls of playdough have corresponding dots on them to the dots in the game. 
    2. A wire is run from each ball of playdough to the Makey Makey.
    3. A stick to tap the playdough is coated with reflective material and is connected to the grounding wire attached to the Makey Makey.
    4. When the balls are tapped,  a signal is sent from the dots to the Makey Makey to the computer.  Each four colours corresponds to an arrow key.
  2. User sits in front of the playdough and screen, ready to begin and is given verbal instruction:
    1. There are four coloured balls in front of you
    2. With the stick, tap the corresponding colour to the colour on the screen to move your character forward
    3. Level ends when you reach the end of the row of dots
    4. You only have 25 seconds to complete a level.  The background colour will change every 5 seconds to show the passage of time from day-time to night-time.
  3. There is a start button that the tester will click to begin game
  4. Game can end by either reaching the end of the row of dots or by pressing the 'end game' button.
  5. Screen includes character on far left-hand side, a row of coloured dots (four colours with patterns), timer in top left corner, 'Begin game' and 'stop' buttons on top right-hand corner, 'High score' display in top right-hand corner below buttons.
  6. User taps coloured playdough to move character forward
  7. High-scores are records on the screen at the end of each game
  8. Users can restart and replay as many times as they like 
  9. User can stop play at any time

What is not included

  • Appearance of sun or moon moving across the 'sky - only appearance of change through background colour
  • More than one level (and level progression)
  • Written instructions/walk through

Friday, 16 October 2015

Week 11: Testing IP2 videos

As the in-class testing session had some problems, here are two videos (apologies for the vertical filming orientation) of the first testing session with the two formations.

Monday, 12 October 2015

Interactive Prototype II: Testing

Outcomes

Users were asked to tap four coloured dots on the floor with their feet to play a basic version of the game and provide feedback.  The coloured dots on the screen corresponded to coloured dots on a floor.

Users played the game a minimum of four times (maximum of 7). Most user wanted to get the best time possible and kept playing until they felt they had achieved that.  Users would keep track of their best scores in their head.

I measured user feedback through observation, in-person questions and an online questionnaire. The data from these measures can be found here.

I wanted to know:
  • What formation of dots is both challenging (users need to use both feet, can't press multiple dots at once) and fun (is not so hard that user gives up early on or does not want to play)
  • How long it takes a user to complete a basic level (25 dots) and how that time improves over multiple goes.

Reflections

The physical format for the prototype was a good way to get more detailed feedback on how the game is played.  It allowed me to observe users' interaction and how physical it was as they became tired and 'puffed' trying to tap all the dots and beat their times.  It was interesting to see how competitive users were with themselves and how even though the timer was there for my benefit for tracking purposes, users manually took note of their times to improve upon.

Testing with more users who weren't from class was again useful.  It was different getting feedback from people who had no prior knowledge of the concept but equally valuable in class as I was able to get comparison feedback (e.g. this element worked better than last time).  A mix of new and previous users led to more insight.

Effectiveness

When it was fully functional, the prototype worked really well and I was able to answer the specific questions I had about the formation on the input. It was very clear both verbally and through the survey which formation was preferred (square).

The first session (not in class) was very successful but the in-class one had problems with one of the dots only working intermittently.  This was a significant obstacle in getting more users to participate in testing. I pulled apart the prototype after the session and am still not sure where the connectedness  failed.  It is a downside of quick prototyping like this that it wasn't robust enough to withstand transport and multiple testing sessions.

Constraints

The constraint of testing the physical input in the session meant that when it didn't work, I couldn't test.  There were no backup inputs as using a keyboard would not have answered the questions I was testing.  It was quite disappointing to have to stop testing because of this.

Implications

Changes to my concept

  • concept is unchanged

Future prototypes

  • Interactive Prototype 3  (IP3)
    • add high-score to screen for users to see 
    • change timer from count up to count down
    • make background change colour with timer (sunshine to night timer)
    • add additional visual cue to stage to make it clearer which dot is next
  •  Future prototypes
    • on-screen feedback for wrong control pressed (not just sound)
    • add movement to cat
    • change timer from count up to count down
    • add sun rising and setting to stage
    • make start/stop easier (enter or other control)
    • add in the extra bits (power-ups, levels, etc) 

Future testing sessions

  • possible use other input methods to test other elements of game to avoid having input breakdowns affect testing session (if inputs are not the element being tested)

Friday, 9 October 2015

Interactive Prototype II: Testing Data

Here is the raw data from the testing sessions that were run for the Interactive Prototype 2 of Meow Meow Cat.  The data forms two parts, the observations recorded during the session and the questionnaire users filled out.

Testing session: 6 & 7 October (week 10 workshop B & outside-class session)

Users:
  • 4 total
  • 2 male, 2 female
  • 2 not from class

Observations

User #1 (not from class)
  • played 4 games (2 square, 2 row)
  • startled by 'wrong button' noice
  • puffed, said "this is hard work"
  • used one leg more and pivoted to make it easier
  • "like a dancing game but not dancing"
  • square: "looks better"
  • times (seconds): 
    • 33, 25(final) - row
    • 25, 21 - square
User #2 (not from class)
  • played 7 games (4 square, 3 row)
  • changed feet a lot 
  • seemed to enjoy it
  • wanted to keep playing to get a better score
  • stopped playing when he reached a point where he didn't think he could get a better score
  • times (seconds): 
    • 27, 18, 11(final) - row
    • 19, 18, 15, 13 - square
User #3
  • played 4 games (2 square, 2 row)
  • initally sat down which made it hard to press foot pads
  • used one leg more
  • one go was really buggy (40 seconds), sometimes the buttons wouldn't fire
  • "my calves burned"
  • "best time yet" on final run (22 seconds)
  • competed with himself
  • times (seconds): 
    • 37, 22 - row
    • 40, 22(final) - square
User #4
  • played 4 games (2 square, 2 row)
  • found it enjoyable but wasn't super competitive
  • times (seconds): 
    • 22, 23 - row
    • 23, 23 - square

Observation overview

  • Purple dot foot pad was very buggy during class testing session but had worked fine 2 days earlier in aanother session.  I could get it to work for one uesr in class but 2 other users (not recorded above) were unable to finish a game because of this.  I don't know if it was the angle in which it was pressed or the force but it was unsuccessful.  I had my final user successfully play 4 games in the session after this happend.
  • Game played 19 times
  • Times:
    • Lowest time: 11 seconds
    • Longest time: 40 seconds
    • Average time: 23 seconds
  • Start/Stop/Reset button a little buggy - had to press in correct order to work
  • All users who played multiple games improved on their previous time

Questionnaire results

Total responses: 4
All questions except the last open 'Any comments?' question was compulsory.

Q1. Which layout did you prefer playing, formation A (straight line) or formation B (square)? Rate your preference on the following 4-point scale. 
Scale '1: Formation A' (row) to '4: Formation B' (square)

2 user: 3/4 on scale (mostly Formation B)
2 users: 4/4 on scale (definitely Formation B)

Q2. Why did you prefer one layout over the other?

  • The dots were closer together and made it easier to reach each one faster.
  • formation B felt like I was more in the game. It was also a bit easier to hit the different colours when they were separated.
  • The layout felt more natural in sense that it surrounded me.
  • I'm not entirely sure.

Q3. Would you suggest a different dot layout to those presented in this session? If so, please describe. 
  • No layout B is efficient enough
  • maybe a diamond like in DDR.
  • Perhaps use walls so that a player has to use multiple limbs to interact - my legs get tired.
  • No, the second layout was fine.

Q4. How would you describe the instructions for this testing session? 
Scale '1: Clear - it was easy to understand what to do' to '5: Confusing - I did not understand what to do'

3 user: 1/5 on scale
1 users: 2/5 on scale


Q5. If you could change any element of this game, what would it be?


  • Nothing
  • the dots are hard to see when looking at the screen. But, as I became more familiar with the game it was easier to remember where each colour was.
  • Maybe a count down timer to cue the player when to start.
  • I'm not sure. I really like that the cat is on the dot this time. It is an improvement from the last prototype. You could maybe deduct from score (which could be based on how long it takes you) if people first tap the incorrect button (before correct themselves).

Q6. Any other comments?
  • Nice cat.
  • Great game! I really liked it!

Questionnaire overview

  • Users definetley preferred the square formation over the row formation
  • cat on the dot improved understanding of game play
  • well liked
  • clear instructions

Monday, 5 October 2015

Week 10: Makey Makey & Prototype construction

The Meow Meow Cat Makey Makey prototype is mostly complete and is finally functional (just a little more gluing to do!).

Process and problems

The initial concept was for foot controls but I couldn't work out how to make the controls conductive without either operating it barefoot or adding conductive material to each user's shoes (neither ideal).  I was thinking about how to change it to hand controls, make it boppy or something which was a bit disappointing.  I had a chat to Peter (tutor) and he suggested making each foot control out of two dots with a spring (sponge) in between them, one that would be grounded, one connected to the control.  This would remove the need for the user to be connected/grounded to the Makey Makey.  When the user steps on the dot, the two circles connect and complete the circuit.

To help with planning out the prototype, I did a quick sketch of how I wanted to connect the components/wires.


Construction

To make the dots, I printed the colours on adhesive paper and stuck them to thick card.  I cut out the coloured circle and a duplicate of the same size.  To make them conductive, I cut out a smaller circle of alfoil to stick on each circle.  I then cut out sections of sponges to glue around the edges of the circle to make them springy (being careful not to touch the sponge to the alfoil).

I was worried that if the sponge wasn't high enough that the two circles might accidentally touch so chose a dense and high sponge. This proved to be a problem as it made it too hard to make the circles touch on step.

Sponges too high

Next I constructed the bottom layer of circles and connected them to a strip of copper tape connected to a grounding wire.  I had thought about grounding them seperately but it made sense to join them into one.

Four bottom circles connected to grounding wire


As I constructed each step, I used the keyboard input checker at http://www.keyboardtester.com/tester.html to test that set-up was working.

Next I connected the tops by using connective tape to attach the open end to the alfoil and non-conductive tape to hold it down at the edge.

Top and bottom circles connected.
I then sandwiched the top and bottom dots and tested the prototype with the game.  I had a small problem where sometimes multiple controls would fire because the wire ends attached to the Makey Makey were touching each other.  This was fixed with a small amount of electrical tape to seal off the ends.



Now that I know the prototype works, I will finish gluing it together ahead of next week's testing session.

Friday, 2 October 2015

Week 9: Concept/feature development

To help look at what I need to change and when (IP2/IP3 or other), I wrote up a list of features assigning Must/Should/Could/Won't.  This helped me work through features in order of priority, starting with Musts for IP2 and going from there.  It also showed where I had questions about features which led to what I wanted to test next (i.e. what question did I want my next prototype to answer)

Week 9: Interactive Prototype 2 - MakeyMakey

What is the key function or interaction for your concept?

The user moves the character (Meow Meow Cat) forward through a series of coloured dots.  Users are timed and are given auditory feedback for correct or incorrect moves.

How does it work?

The user taps corresponding coloured dots on the floor with their feet to those displayed on screen.   A Makey Makey is used to connect the dots on the floor with the computer.  A timer will be used to test how long it takes users to complete a basic level (25 dots).

What do you want to know about your prototype?

  • What formation of dots is both challenging (users need to use both feet, can't press multiple dots at once) and fun (is not so hard that user gives up early on or does not want to play)
  • How long it takes a user to complete a basic level (25 dots) and how that time improves over multiple goes.

How do you want IP2 to work?

  1. A testing computer is set-up connected to large dots on the floor through a Makey Makey device.
    1. Two cardboards circles (for each of the four dots) lined with alfoil are connected through a ring of sponges that make a spring.  When the circle is stepped on, the sponges compress connecting the two circles and the alfoil.
    2. A wire is run from the bottom circle of each of the four dots to a strip of copper (connecting all the bottom circles) and then to the grounding wire attached to the Makey Makey.
    3. Separate wires are run from the top circle of each dot to a control on the Makey Makey.  Each four colours corresponds to an arrow key.
  2. Dots are set-up in a set formation (two different formations will be tested)
  3. User stands in front of the dots ready to begin and is given verbal instruction:
    1. There are coloured dots on the floor in front of you
    2. Tap the corresponding colour dot on the floor to the screen to move your character forward
    3. Level ends when you reach the end of the row of dots
  4. There is a start button that the tester will click to begin game
  5. Game can end by either reaching the end of the row of dots or by pressing the 'end game' button.
  6. Screen includes character on far left-hand side, a row of coloured dots (four colours with patterns), timer in top left corner, 'Begin game' and 'stop' buttons on top right hand corner.
  7. User taps coloured dots to move character forward
  8. Time how long users take to reach end of row.
  9. Users can restart and replay as many times as they like 
  10. User can stop play at any time

What is not included

  • Winning or losing (reaching end by a certain time)
  • 'Chasing the sun' part of the concept (sunshine changing colour to night time with timer)
  • More than one level (and level progression)
  • Written instructions/walk through
  • On screen record of high scores

Saturday, 19 September 2015

Interactive Prototype I: Testing

Outcomes

Users were asked to use a modified keyboard to play a basic version of the game and provide feedback.  The coloured dots on the screen corresponded to coloured dots on a keyboard (arrow keys).

Most users played the game as expected multiple times.  One user wanted to get the best time possible and tried to manipulate the keyboard in different ways to achieve this without interacting with the game in the desired way.  They tried mashing the keys and pressing random keys.  Another user  could not see the difference between the colours on screen and had to stop part way through their first go.

I measured user feedback through observation, in-person questions and an online questionnaire. The data from these measures can be found here.

The feedback I was after was about the movement of the different elements on screen (how the dots and cat moved in relation to each other) and how the timer effected gameplay.

Reflections

The interactive format for the prototype was a good way to get more detailed feedback on how the game is played.  It allowed me to see users play the game and what obstacles they came up against.  It became apparent quite quickly that the colour similarity was a problem and even stopped one user from completing a level.  Other feedback I received about the movement confirmed that it wasn't clear what moved when (and what was the next colour) but didn't provide much of a solution to this.  I then discussed this problem further with tutors.

Testing with a user who wasn't from class was really useful, I found my discussion with them quite different as they were less limited by what they knew to be possible.  It was also more validating to get feedback from someone who knew less about the concept/background to start with.  I would like to expand upon this for the next test.  The testing protocol and questionnaire worked quite well but it seem like the questionnaire might be a bit too long.

Effectiveness

The prototype worked really well and I was able to answer the specific questions I had about movement and apply the feedback about the movement.  The main problem with the prototype was that the colours I had selected were too similar which caused problems for some users.  One user was unable to complete the session at all as they could not tell the colours apart, others had some problems but could still complete the level.

Constraints

The constraint of the testing session meant that even though I knew I had a problem early on with the colours, I was unable to change it for other users.  It would have been better if I could have changed this as soon as I knew it was a problem so users could concentrate on other elements like movement.  To be able to change this on the fly would have taken time that I did not have in the session.

Implications

Changes to my concept

  • make colours more different from each other and add patterns for easier visual identification (and accessibility) 

Future prototypes

  • Interactive Prototype 2  (IP2)
    • make colours more different from each other and add patterns for easier visual identification (and accessibility)
    • move controls further away from each other
    • add audio feedback to wrong control pressed
    • change cat/dot layout to make it clearer which dot is next
    • fix bugs in start/stop/pause
  •  Future prototypes
    • on-screen feedback for wrong control pressed
    • add movement to cat
    • change timer from count up to count down
    • make background change colour with timer (sunshine to night timer)
    • make start/stop easier (enter or other control)
    • add in the extra bits (power-ups, levels, etc) (maybe IP3)
    • add high scores/previous score
    • add exit button

Future testing sessions

  • Reduce length of questionnaire

Friday, 18 September 2015

Interactive Prototype I: Testing Data

Here is the raw data from the testing sessions that were run for the Interactive Prototype I of Meow Meow Cat.  The data forms two parts, the observations recorded during the session and the questionnaire users filled out.

Testing session: 15 September (week 8 workshop A)

Users:
  • 6 total
  • 4 male, 2 female
  • 1 not from class

Observations

User #1
  • played three full games
  • played two other games with errors (game over message at wrong point, I don't think the game reset in-between)
  • wanted to be previous time when he played
  • times: 24, 15, 13 seconds
User #2
  • I reset game in between goes due to problems with previous session
  • played three games
  • found colours hard to see
  • second go, mashed controls with fist (i.e. pressing all colours at once) to get better time
  • third go randomly pressed keys to get better time
  • times: 24, 17, 6 seconds
User #3
  • played twice
  • had problems telling red and purple colours apart
  • times: 23, 19 seconds
User #4
  • played twice
  • asked "what feedback is there if you press the wrong colour?"
  • times: 24, 22 seconds
User #5
  • played once
  • was unable to tell the difference between colours (blue and purple), had to guess
  • suggested adding pattern to colours to help
  • time: 31 seconds
User #6
  • played four times
  • tried to beat score, stopped playing when couldn't beat score (i.e. when there was no more challenge)
  • commented that it was fun to play
  • times: 17, 13, 9, 9

Observation overview

  • Limitations of prototype included the modified keyboard; user had to re-learn keyboard input
  • Survey took a long time, possibly too many questions
  • Game played 15 times
  • Playing as intended:
    • Lowest time: 9 seconds
    • Longest time: 24 seconds
  • Playing in other manner:
    • Lowest time: 6 seconds (by pressing random keys as quickly as possible)
    • Longest time: 31 seconds (user who had to guess colours because they were too similar to differentiate)
  • Average time:
    • 17.73 seconds (all goes)
    • 17.67 seconds (not including mashing keys, random selecting keys or guessing keys)
    • no real difference between averages
  • Problems with colours being too similar and making it hard to see
    • could change colours
    • could add pattern to colours
  • Start/Stop/Reset button a little buggy - had to press in correct order to work
  • All users who played multiple games improved on their previous time

Questionnaire results

Total responses: 6
All questions except the last open 'Any comments?' question was compulsory.

Q1. Describe what you did in this session

  • I played the game three or four times.
  • Played the game until I could not determine the difference between two of the colours. I then had to stop as I could not play the game.
  • Used the colour keys to move the cat along the path of coloured dots
  • I pressed the colours that came up on the screen.
  • Make sure the colour of each direction key, and try to remember it. play game as fast as possible.
  • Pressed the coloured dots in the correct order to advance the cat and try to beat my record time.

Q2. How would you describe the instructions for this testing session?
Scale '1: Clear - it was easy to understand what to do' to '5: Confusing - I did not understand what to do'

5 users: 1/5 on scale
1 users: 2/5 on scale

Q3. Describe the movement that happened during the game. 

  • The cat stayed still and the colours moved.
  • when I press the right key, the dot will move below the cat
  • The cat moved from left to right across the game screen and the coloured dots disappeared
  • the dots moved towards the cat/the cat moved along the dots. I'm not sure. I pressed the colour that matched the next dot on the screen.
  • the cat moved forward (right) one dot at a time
  • The colors shifted left each time I pressed them.

Q4. Apart from the cat and the dots, did you notice any other elements on the screen? 
  • I noticed the time and the buttons at top, but during gameplay I didn't pay any attention to them - just concentrated at looking at the dot keys and the dots on screen
  • not many, just the those functional buttons
  • not after I started playing.
  • There was a yellow background. There was a start, stop, reset button at the top. There was a timer up the top left of the screen.
  • The time on the top of the screen.
  • The Timer in the top left hand side of the game. The Buttons in the top right were also visible
Q5. If you noticed the timer, did it affect how you played the game?
3 options

3 users: Yes, it affected how I played
1 user: No, it did not affect how I played
2 users: No, I did not notice the timer

Q6. Describe how the timer affected how you played.  
  • I didn't really look at the timer during the game - only after to see if I beat my previous game's time. perhaps there could be audio reminder every 5 or ten second intervals? Might be worth trying, hopefully it wouldn't be too annoying, but will add some element of pressure!
  • I tried to beat my previous times.
  • I didn't pay attention to it until the end of the game.
  • I want to finish the game as soon as possible
  • I did not notice it. So it did not affect the way I played
  • Added stress, but also made me want to continue playing to see how fast I could complete the course
Q7. Which elements on the screen moved? 
  • the dots are moving
  • The dots moved and the timer counted.
  • the dots
  • The colours moved.
  • The colors.
  • Only the dots. It seems like the cat is moving but i am pretty sure it remains stationary
Q8. Any other comments?
  • It was sometimes a little confusing which colour needed to be pressed as. If that cat was currently on green, I wanted to press green but I actually had to press blue which was the next colour in the sequence. I was able to learn to press the correct button after a few plays but it was not immediately obvious.
  • add a key press check function, maybe, because user can press all direction, and the game will be finished very quick
  • For some reason, I kept wanting to press the color under the cat rather than the color to the right of that color. I think it would be easier to press the color under that cat because it's not between to other colors, and it's more noticeable because it's under the cat. I think if I played this game more, I would more easily press the colors instinctively rather than having to look down to see where colors were. I think this will be easier in your next prototype because you won't have the correlated instinct of up/down/left/right keys. Overall, I really liked this game! Good work!
  • The first comment is about colour. I could not tell the difference between two of the colours and as such I could not finished the game. Change the colours or add a pattern to make it easier to determine which is which. Secondly I would add a space between the colour I am on and the next colour. I was confused at times. If the colour I was on was a different size or shape I would automatically assume it was the colour I was on and look to the next number.
  • It would be good if there was a sound when you hit the wrong colour, I found it hard to know if I had pressed the wrong button, or just not pressed anything.

Questionnaire overview

  • Users understood that they were moving the cat along the coloured path even though it was the path that was actually moving
  • Users found my instructions for the testing easy to understand (Q2) but I should have reversed the scale (so 5/5 was 'completely understand' not 1/5)
  • When asked what they did, users understood the gameplay of the cat moving along the coloured path 
  • When asked to describe the movement, some (3-4/6) thought the cat moved (what I intended to be perceived), some (2-3/6) thought the dots moved (what actually happened) but when asked what element/s moved, all users reported the dots moved.
    • confusion about what moved might be clearer if the cat had movement, even if it didn't physically move across the screen e.g. 'jumped' up and down on the dots
    • users knew that the only 'moving' element was the dots but about half perceived the cat moving (what I wanted to happen).
  • Half the users (3/6) noticed the timer and used it to compete against themselves even though they were not told to, and they didn't know their times were being recorded.  One other user noticed the time but reported it did not affect how they played.
  • Players liked the pressure of the timer to compete but didn't notice during gameplay, only at end of level.
  • Give users some feedback when they press the wrong button
    • maybe sound or text/image on screen
  • Physically distance the inputs for the next prototype to make it impossible (or at least much harder) to randomly press inputs or press more than one at a time
  • Colours (accessibility) needs to be fixed
  • Game started with cat off the dots and when you pressed the first colour, dot moved underneath, then press next colour, etc. Once you had pressed a couple of colours, it was then unclear/easy to get mixed up which colour to press next.  Was it the colour under the cat of the colour next to (right of) the cat.
    • could change size of dots once they are pressed (i.e. colours under the cat and to the left of)
    • could add in a market (like a caret) underneath the dot you are to press next
    • could animate the cat so it looks more like it is jumping to the next dot
    • add more of a space between the dots I have pressed and the dots I haven't pressed yet

Tuesday, 15 September 2015

Week 8: Makey Makey I

We started using Makey Makey's this week in class.  We did a few activities to simulate different games and their controls and get us thinking about the different ways we can use them and what problems we might come across.  Our tutor mentioned at the start that one of the biggest things to remember was to ground it and I still forgot half a dozen times during the workshop.  My IP1 will plug straight into a Makey Makey because of how it was set up (using keyboard arrows).  My challenge will be to get it as physical as possible on a floor mat set-up, and hopefully to add more functionality to the prototype and fix some of the bugs from IP1.

One of the most interesting things we did was play multi-person Pacman where 4 people were each responsible for a direction.  We had to communicate a lot to make this work but it made it a lot more fun than regular Pacman.  Here are a few of the different set-ups I tried today.

Set-up for space invaders.  Alfoil bracelet grounds it.

Set-up for piano, using back letter controls (WASDFG).

Playing the online piano.

Set-up to play my game, success!

Week 8: Physical interactions

This week in class we looked at three existing digital experiences (email, Twitter and Super Mario Brothers) and had to come up with 5 new ways of physically interacting with them.



Email

Core interactions

  • new message
  • write message
  • send message
  • view inbox
  • move or delete message

Ideas

  1. Sandbox
    movements in sand associated with specific actions
  2. Physical drawers
    drawers on a desk with actions associated with drawers; interactive elements (block) do something when you transfer between drawers
  3. Coloured balls
    similar to drawers but colour indicates action; when viewing an email, the colour you choose decides action (red for delete)
  4. Physical box with coloured lights
    box is scrollable and has digital display
  5. Physical letter
    uses the tactile sensation of writing a letter that then scans image-to-text and shreds original (like a fax/shredder)


Twitter

Core interactions

  • scroll newsfeed
  • compose tweet
  • send tweet
  • quote or retweet
  • follow someone

Ideas

  1. Floor mat
    uses a floor mat that you would stand on/tap to compose tweet; layout would be like old mobile phone keypad
  2. Rollerdex
    scroll through to scroll through newsfeed; can scroll forward and backward; touch sensors on 'cards' would perform simple actions like retweet
  3. Deck of cards
    to promote slow, deliberate reading; hold card up to sensor to load next tweet in feed
  4. Chips/box
  5. Morse code
    morse code tapper, switches for actions



Super Mario Brothers

Core interaction

  • move forward and back
  • jump

Ideas

  • Bike
    pedal forward and back; get off saddle to jump
  • Semaphore flags
    different combinations for different moves
  • Box of water
    sensors on box, splash to indicate action
  • Foot pads
    two foot sensors (left and right) to simulate movement; handrail touch to move backwards; jump to jump
  • Row boat
    left row for back, right row for forward, row both to jump

Summary

This was a really interesting exercise, I was definitely running out of idea steam by the time I got to 5.  I also felt like I was repeating elements of my ideas, it was hard to think outside the box.  Super Mario was much easier as the interactions were simpler, email and twitter had so many behaviours that I found my ideas centered towards one or two interactions and not the full interaction of these applications.

Sunday, 6 September 2015

Week 7: Reviewing video prototype testing

Question Type Traps
Q1. Do you understand the concept and gameplay?
Scale '1: No, did not understand at all' to '5: Yes, understood the whole concept'
Quantitative This was a compound question.  Understanding the concept and how the game works is two different things.
Should have separated this question.
Q2. Are there any parts you did not understand? Qualitative Not specifically, it builds on the previous question which should have been separated.
Q3. Did the video format help with your understanding of the concept?
Scale '1: No, it didn't help' to '5: Yes, it did help'
Quantitative This was a bit leading.  Maybe "How did you find the video format of the prototype?"
Q4. What would you improve about the game?  Qualitative No
Q5. Do you agree with this statement?  The concept is engaging.
Scale '1: Strongly disagree' to '5: Strongly agree'
Quantitative Could be leading.  Might have been better as a semantic differential
e.g. "Rate the concept (engaging to boring)" or similar.
Q6. Was the audio of a quality that you could understand what was being said? Qualitative Probably a bit wordy "could you hear what was said" would have been simpler.  
Q7. Were my instructions clear? Qualitative Leading question, could again be a semantic differential which would have made it quantitative as well.
e.g."Rate the instructions (clear to confusing)"
Q8. Any other comments? Qualitative No

Friday, 4 September 2015

Week 6: Class Responsibility Collaboration (CRC)

In this week's lecture we looked at Class Responsibility Collaboration (CRC) cards.  First was to look at the objects.  For my game, they are: stage, player (cat), path of dots, sun, start/stop, timer.


I then created a card for each of these and looked at the attributes (variables) and abilities (functions). 




This process raised an interesting question for my game, what moves?  I had to quickly sketch it up to understand the relationship between the moving objects.  Using this, I was able to refine my goal for the next prototype (IP1) - how do the movements work and work together. 

So far, I have:
  • the player moves along the path (right) of coloured dots through keyboard inputs 
  • the path is longer than the screen so the path has to move as well
  • the path moves to the left as the player moves (e.g. it does not move independently, if the player doesn't move, the path doesn't move)
  • sun starts near the middle and moves to the end of the path
  • how fast the sun moves depends on the level
  • the sun's movement is a fixed speed and time
  • if the sun reaches the end before the player reaches the sun = game over
  • if the sun goes off screen but has not reached end yet, timer informs player of time left



Writing out all the movements, it feels a little complicated.  It might also be confusing to have the sun go off the screen.

Current:
Goal is to reach sun (location) for nap before sun reaches end of path (second location)

Suggested change:
Goal is to reach end of path (location) before sun (day) becomes night (timer)

I am going to ruminate a bit more on this change and discuss it at our next workshop for more feedback.


Restaurant Dining Experience

What is our restaurant? Generic chain-store with table service

P.O.V. of waiter

Existing experience

  • welcome
  • take to table
  • take order
  • deliver order
  • clean table
  • take payment

External factors

  • customers
  • cooking staff
  • other waiters
  • restaurant business
  • management

Internal factors

  • tired/sick
  • emotional state
  • workload
  • pay
  • work satisfaction

What could be enhanced/augmented/supported with technology?

  • ideas (reduce role of waiter)
    • ipad ordering - reduce number of tasks
    • strip lighting to seat
    • deliver order via device like sushi train or buzzer to collect food or robotic cart
    • app payment
    • self cleaning tables
  • electronic ordering to reduce errors and tie order with table

How would introducing technology change experience?

  • less for staff to remember
  • less order errors
  • wireless means order could go straight to kitchen without waiter physically going there and also that orders are already 'rung-up' for when cutomer goes to pay

What experience scenarios might you test?

  • prototype that lets wait staff record orders on an ipad but that doesn't have other funcationality included like sending orders to the kitchen.
  • waiters could interact with the interface to record orders and different interfaces could be tested to find out what elements are work/don't work

P.O.V. of customer

Existing experience

  • arrive and are seated
  • browse menu
  • order
  • wait for food/drinks
  • eat
  • maybe order dessert
  • pay
  • leave

External factors

  • wheather
  • traffic
  • parking
  • time of day
  • people you are with
  • ability to make a booking or just turn up
  • time to get seated
  • business of restuarant
  • time to order
  • tiime for food to arrive
  • experience of noise (children, loud music)

Internal factors

  • how hungry you are
  • how much time you have
  • how much money you have/want to spend
  • dietary needs

What could be enhanced/augmented/supported with technology?

  • mobile app to increase efficiency to place an order
  • show image or dish and ingredients
  • incorporate payment
  • vote on dishes
  • give quick review
  • app: allow restuarant to input all meals with ingredients that users could filter by what they didn't like or what they are allergic to

How would introducing technology change experience?

  • more accuracy on ingredients (ie vegetarian dish but uses fish sauce)
  • allows users to view and choose at leisure rather than asking wiater lots of questions
  • ease of choosing restuarnt you know will have something you can eat

What experience scenarios might you test?

  • two options, paper menu with symbols (vege, gluten free) and app that allows users to filter
  • test user opinions on ease of ordering and whether it imporves their expereince

P.O.V. of chef

Existing experience

  • get to work
  • prep
  • cook
  • some clean
  • some ordering of ingredients
  • manage multiple meals at once

External factors

  • arriving at work on time
  • number of customers
  • number of waitstaff
  • changes to menu
  • special orders
  • availability of ingredients

Internal factors

  • tired/sick
  • emotional state
  • workload
  • pay
  • work satisfaction
  • expereince

What could be enhanced/augmented/supported with technology?

  • electronic ordering
  • streamline cooking workflow
  • table tell if diners are finished one meal and ready for next
  • screen display with orders and timing and orer status (e.g. prep, pre-cooking, cooking, plating)

How would introducing technology change experience?

  • streamlined workflow
  • quicker turn around on orders
  • greater tansparency of time needed and order status
  • ease to serve whole table at once
  • reporting 
  • can track meal inventory (and when they will run out)

What experience scenarios might you test?

  • small setting test with reduced cutomers and menu
  • increase load to see if there is a point of business where it is not helpful

Monday, 24 August 2015

Week 5: Interactive Prototype I - ActionScript

What is the key function or interaction for your concept?

The user moves the character (Meow Meow Cat) forward through a series of coloured dots.  Each level increases in complexity and speed, so user speed is a factor.

How does it work?

The user uses the keyboard arrows (up, down, left, right) to move the character.  The keyboard will be modified so each arrow direction represents a different colour.  A timer will be used to test how long it takes users to complete a level.

What do you want to know about your prototype?

  • How the player moves (player moves with input, path moves in response to player)
  • How long a user takes to complete a level
  • Does viewing a timer affect user performance

How do you want IP1 to work?

  1. A testing computer is set-up with a modified keyboard.  Coloured dots are blu-tacked on to arrows.
  2. User sits down at a testing computer ready to play
  3. User reads on-screen instructions:
    1. Your keyboard arrows have been replaced with coloured dots.
    2. Press the corresponding colour from screen to keyboard to move your character forward
    3. Level ends when you reach the end of the row of dots
  4. There is a start button that users click to begin game
  5. Screen includes character on far left-hand side, a row of coloured dots (four colours), timer in top left corner, start, stop, and reset buttons on top right hand corner.
  6. User presses 'coloured' arrow keys to move character forward
  7. Time how long users take to reach end of row.
  8. Users can restart and replay as many times as they like 
  9. User can stop play at any time

What is not included

  • Exit button to close program
  • Winning or losing (reaching end by a certain time)
  • More than one level (and level progression)

Friday, 21 August 2015

Video Prototype: Testing

Outcomes

Users were asked to view the video to provide feedback.  They could pause, rewind, scrub and re-watch.  Users were also encouraged to ask questions at any time.

For the most part users watched the video through.  One person watched twice and a few people stopped at the credits, but for the most part they watch in a linear fashion.

I measured user feedback through observation, in-person questions and an online questionnaire. The data from these measures can be found here.

The feedback I was after was about the concept (was it clear, easy to understand, fun, engaging) and the prototype format (video and audio quality).

Reflections

The video format for the prototype was a fairly quick way to get feedback about the concept without having to code anything.  It was more detailed and controlled than simply telling someone my idea and also allowed for engaging visuals.

I received a number of pieces of useful feedback on the concept through the video prototype. Things I hadn't considered (e.g. how do you start/stop) and extensions of existing ideas (e.g. power-ups).

Testing in class provided a number of willing participants but I know this is not indicative of testing prototypes with 'real' users.  The testing protocol I laid out worked well but I know I was much more informal with users than I have been in other usability testing situations or if they hadn't been my classmates with a similar background to developing the concept (i.e. we all knew it would be a game mash-up or a wearable).

Effectiveness

The protoype was very effective and achieved the goals I set out to assess whether the concept is entertaining and engaging, the gameplay is clear and logical, and to facilitate feedback on the concept.  All three of these goals were achieved.

Constraints

The constraint of the video format meant that users could not interact with the concept, only take in information.  This meant that I had to show how users would interact in the video protoype (i.e. show feet stepping on mat).  I had a number of bits of feedback to say this was clear so I think this constraint was able to be overcome.

The constraint of the testing session was that it was an artificial testing environment.  This meant that users were already prepared with background knowledge (negative) and very willing to give feedback (positive).

Implications

Changes to my concept

  • need a start/stop/exit button (or method)
  • walkthrough/game instructions might be helpful
  • extra 'fun' could be added through power-ups (tuna) or traps (catnip)

Future prototypes

  • Interactive Prototype 1  (IP1)
    • I will add a start/stop/exit button on screen 
    • verbal instructions
  •  Further prototypes
    • start/stop/exit could be implemented by another method e.g. jumping or double tap on mat??
    • think about best way to display instructions, maybe a walkthrough/video/intro
    • add in the extra bits (maybe IP3)

Future testing sessions

  • Run testing in addition to class session
  • Act more formal in-class session (i.e pretend they are real users who know nothing about the background) and print out testing script

Video Prototype: Testing Data

Here is the raw data from the testing sessions that were run for the video prototype of Meow Meow Cat.  The data forms two parts, the observations recorded during the session and the questionnaire users filled out.

Testing session: 19 August (week 4 workshop B)

Users:
  • 7 total
  • 5 male, 2 female

Observations

User #1
  • nodded head as watching 
  • bored at credits and stopped
  • watched twice through
  • second time turned up volume (video volume ok, room background noise was competing)
  • comments
    • easy to understand explanation
      this is what happens (screen animation) and then this is how you do it (floor mats)
User #2
  • laughed at GIFs
  • thought character could be anything (changeable) so did not see link between intro (cat GIFs) and the game
  • clear on concept
  • concentrated on viewing
User #3
  • concept was clear
  • loves cats so loves concept
  • smiled a lot
  • interface
    • how do i exit?
    • how to start/try again?
User #4
  • no questions
  • smiled, seemed happy at end of video
User #5
  • laughed at cats
  • had trouble understanding gameplay, said it might be English comprehension
  • didn't initially understand how screen and floor-mat related to each other
  • had trouble reading and filling out questionnaire
  • would like a how-to-play screen
User #6
  • lots of concentrating
  • no questions about gameplay
User #7
  • laughed at cat GIFs
  • nodded when floor mat was shown (understanding?)

Observation overview

  • GIFs/cat videos were well received, many laughed, lots of smiling throughout, showed engagement with idea
  • 6/7 thought concept was easy to understand
  • showing the floor mat after the interface screen seemed to be crucial in understanding how the gameplay worked
  • instruction/walk-through screen might be helpful
  • need to add start/stop button to begin play, allow players to exit and replay.

Questionnaire results

Total responses: 7
Less than 7 responses to an individual question are noted

Q1. Do you understand the concept and gameplay?
Scale '1: No, did not understand at all' to '5: Yes, understood the whole concept'

All - Yes, understood the whole concept (5/5 on scale)

Q2. Are there any parts you did not understand? (4 responses)
  • no
  • No .. it was all very clear.
  • Are there multiple levels?
  • Not really no. I guess more information about levels and difficult? But that's something that could always be added later.
Q3. Did the video format help with your understanding of the concept? 
Scale '1: No, it didn't help' to '5: Yes, it did help'

2 users: 4/5 on scale
5 users: 5/5 on scale

Q4. What would you improve about the game? (4 responses)
  • Nothing, it seemed good to me.
  • It would be interesting to have a two player game where you race your own meow meow cat against others. And there are 'traps' along the way that push your cat backwards. For example, land on catnip and your cat takes a nap for a while. Or gets distracted by a laser pointer.
  • Based on the video, i have a clear understanding about how the mechanics work in the game, however, i might miss the part that explain the end for the game(like where to quit?)
  • Power ups? Some sort of added fun mechanic to diversify the gameplay.
Q5. Do you agree with this statement?  The concept is engaging. 
Scale '1: Strongly disagree' to '5: Strongly agree'

1 user: 3/5
1 user: 4/5
5 users: 5/5

Q6. Was the audio of a quality that you could understand what was being said?  
  • Yes, but maybe a little bit fast
  • audio is clear and easy to understand.
  • yes. It was very clear.
  • Yep. Audio fade at the start was good. Only one part where it was talking about Cats and Experience not sure if it said Catsperzience or not.
  • Yes I could understand everything.
  • Yes!
  • Absolutely
Q7. Were my instructions clear?  (6 responses)
  • yes
  • Crystal clear
  • Yes!
  • Yes instructions on how to play the game were very clear. Good Visual representation made it easy to understand.
  • Yes
  • Yes.
Q8. Any other comments?
  • Really cute drawings, cute cat, cute sun, cute concept :)
  • the game doesn't have many connection with cats. cats can be changed to anything animal
  • None. It looks like a fun concept.
  • Not really. Just interested to know about multiple levels.
  • Maybe it better to display the game as an example
  • That is a great game at all aspect
  • Meow ^.^

Questionnaire overview

  • Concept was easy to understand
  • Video format was helpful
  • sound levels were good
  • game instructions were clear
  • add in more info/details about levels
  • add power-ups or traps for more fun
  • need an exit button

Monday, 17 August 2015

Week 4: Prototyping Exercises

For the contact class this we were given two exercises to demonstrate our knowledge of different types of prototypes.

Exercise 1: Car Interface

What are the functional components? 

Components relevant to driving behaviour are bolded.
  • Dashboard
  • Air vents
  • Rear view mirror (and flip)
  • Air vents
  • Side mirrors
  • Side console
    • side mirror adjusters
    • fog lights
    • headlight adjusters
    • air vents
    • window controls
  • Steering wheel
    • cruise control button
    • bluetooth phone buttons
    • music control buttons
    • window wipers
    • indicators
    • headlights
  • Main console
    • odometer
    • speedometer
    • petrol level
    • engine temperature
    • gear display
    • tachometer
  • Center console
    • hazard light buttons
    • cd player
    • sound system display
    • air-con knobs (temp, in/outside air, on/off)
    • air vents
  • Center area
    • cigarette lighter
    • gear knob
    • handbrake
  • Below steering wheel
    • brake
    • accelerator
    • clutch (manual)

What are the interactions of those components with the driver when driving?


  • Rear view mirror (and flip)
    Check before driving, adjust during driving if needed
  • Side mirrors
    Check before driving, adjust during driving if needed
  • Steering wheel
    Turn left and right while in motion to direct car 
  • Cruise control button (steering wheel)
    Set a constant speed when driving on highway
  • Bluetooth phone buttons (steering wheel)
    Answer and end calls while driving
  • Music control buttons (steering wheel)
    Adjust music type and volume while driving
  • Window wipers
    Turn on and off, adjust intensity if raining
  • Indicators
    Push up or down to turn on left or right indicator to signal change in direction
  • Headlights
    Turn on or off as light levels indicate
  • Speedometer
    Look at to ascertain driving speed
  • Petrol level
    Look at to ascertain current petrol levels
  • Engine temperature
    Look at to ascertain engine temperature
  • Gear display
    Look at to ascertain which gear you are in (in concert with gear knob)
  • Tachometer
    Look at to ascertain engine rev
  • Air-con knobs (temp, in/outside air, on/off)
    Turn on/off and adjust settings
  • Gear knob
    Change gear and tell you what gear you are in
  • Handbrake
    Pull on or off to apply handbrake, generally while car is stationery
  • Foot brake
    Apply pressure with foot to brake while in motion
  • Accelerator pedal
    Apply pressure with foot to accelerate while in motion
  • Clutch (manual)
    Apply pressure with foot to assist in changing gears

What would you test? How would you test?

One idea to replace an existing component would be to change how indicators are turned on or off.  Currently, there is a level attached behind the steering that you move up or down to indicate left or right.  Which way is left/right depends on where the car is made. Instead of a lever on one side of the steering wheel, the indicator could be incorporated into the steering wheel itself.  There could be a button on each side of the wheel (left = left, right = right) that would flash when on.  Having a flashing light on the steering wheel may also help when people forget to turn their indicator off.

One way to prototype this would be through an existing car with paper buttons on the wheel.  The user could drive through a set course (like a learning to drive area, not in real traffic) and try pressing the buttons with their thumbs to indicate.  The tester would look at how easy the button is to reach and access.  One problem with this testing is fighting against the ingrained behaviour to use the indicator stick.

Exercise 2: Alarm clock app

Features:
  • Set, edit, delete multiple alarms
  • daisy chain alarms
  • set different tones for differnt alarms
  • shake phone to snooze
Types of prototypes:
  • Horizontal (wide range of features but no depth - can't tap to another screen)
  • Vertical (can go down one action path, many screens but only one task)
  • Diagonal (more functionality, multiple paths)