Versions Compared

Old Version 46

changes.mady.by.user Unknown User (saqib@mit.edu)

Saved on

compared with

New Version 47

changes.mady.by.user Chong-U Lim

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

User

Presented with the Tutorial Screen

Finding a friend in your Friend List or on the Map

Adding an individual into your Friend List

Creating and Inviting Friends to an Event

Responding to an Invitation by Proposing a Change in Time

User's General Comments

1

  • The user had no problems with the tutorial.
  • User exhibited no difficulties identifying the correct icon in the action bar, thanks to both the the tutorial and the correct affordance provided by the button.
  • The on-screen message said "Friend has been Added". The user was then surprised to find his friends list still empty.
    (Confusing the User)
  • When the notification bar displayed the counter, the user then understood that he had actually sent a request and had just received confirmation.
    (Good Visual Variable)
  • Expressed an interest in being able to specify a place by name, which would then pan the map to the location.
    (Efficiency)
  • The user hit the Back button instead of the Done button, losing his selected location.
    (Safety)
  •  Did not exhibit difficulty in performing the task -- found it intuitive to follow based on the application's general workflow.
    (Internal Consistency)
  •  Generally found the overall interface useful and intuitive.

2

  • The user was tapping on the arrow image pointing to the next button, as opposed to the next button itself, in trying to proceed to the next step in the tutorial. 
    (Confusing the User, Unclear Affordance)
  • The user wanted to have a way to search for a friend, either through the friend's list or a search bar. This would improve the efficiency of locating someone as opposed to manually tapping each marker.
    (Efficiency)
  • Upon receiving the notification that his friend had added him, the user proceeded to tap on the notification, as he saw the ">" arrow.
    (Good Affordance)
  • The user was tempted to press the "Delete Friend" button, and he said that it was the first thing that came to his mind when he saw the profile page.
    (Safety)
  • Expressed a wish to have free text area to add a some comments to the event invitation, much like most applicaitons that send invitations to others.
    (Matching the Real World)
  • Hoped for a way to be more specific in selecting a location (i.e. Room Number or a particular floor).
    (Matching the Real World, Efficiency, Visibility)
  • Expressed a wish to have free text area to add more information as to why a change was being proposed.
    (Matching the Real World)
  • Wanted to view events which he/she had proposed a change for in the Events List with some sort of indicator that they were pending.
    (Visibility)

  • Expressed a wish to be able to prevent users from proposing a change too close to an event.
  • Was generally interested in conveying more information with regards to his action to his friends.

3

  • The user had no problems with the tutorial.
  • The user expressed concern that in the event that many of his friends were clustered close to one another, that it would be hard to locate a particular friend. He later discovered that the map's zoom levels implemented direct manipulation for panning and zooming, and expressed satisfaction.
    (Learning by Exploring)
  • The user wanted to know where his newly added friend was after adding him. However, the friend took a while to locate where his friend was.
    (Efficiency)
  • Expressed an interest in being able to specify a place by name, which would then pan the map to the location.
    (Efficiency)
  • Did not not realize that the propose change button was there. Proceeded to RSVP "Yes" without making the change, thinking that the part where a suggested change came after the RSVP.
    (Visibility, User Model of System)
  • Initially thought ">" in the notifications list meant that the notification was new.
    (Visibility)
  • When asked about how he/she was able to distinguishing whether notifications were read/unread, user realized that the beige tint in the background was already triggering that knowledge unconciously.

Reflection

the The most important lesson we learned thougth this project is that when you are a part of the development team of a system, it is hard for you to make a unbiased critical review of that system in terms of learnability and usability even if you consider yourslef part of the userbase. 
while going through the design iteration we have learned a lot about the diversity of the behaviour and thought processes of our user base, and their feedback at different stages of design and implementation was criticle ingredient in achieving the final userfreindly version.
To evaluate the results of our observations at each iteration of testing, we did another iteration untill finally we started receiving consistent positive responses from the users.  we

We tested all design alternatives for major tasks in paper prototyping, and requied to do only minor affrodance refinements in later testings. and therefore the number of iteration we did in paper prototyping was greater than the number of iteration we needed to do for computer prototype before achieving consistency in users' response. 
however  However we noticed that on each iteration of testing, as the interface became more polished than before, we found new usibility concerns through user testing which went unnoticed in the previous iteration. therefore if given another chance, we would use more realistic yet low fedelity sketches for paper prototyping. there are many such open source mobile app paper prototyping software available which we didn't know about at that time. 
by using these software we could increase the clearity of different views and provide a polished view for users feedback at much earlier stage, further reducing the iteration cost of computer prototyping. 
the most important lesson we learned thougth this project is that when you are a part of the development team of a system, it is hard for you to make a unbiased critical review of that system in terms of learnability and usability even if you consider yourslef part of the userbase. 

while going through the design iteration we have learned a lot about the diversity of the behavior and thought processes of our user base, and their feedback at different stages of design and implementation was critical ingredient in achieving the final userfreindly version.

To evaluate the results of our observations at each iteration of testing, we did another iteration untill finally we started receiving consistent positive responses from the users. 

We tested all design alternatives for major tasks in paper prototyping, and there required to do only minor affrodance refinements in later testings. Consequently the number of iteration we did in paper prototyping was greater than the number of iteration we needed to do for computer prototype before achieving consistency in users' response. 

However we noticed that on each iteration of testing, as the interface became more polished than before, we found new usability concerns through user testing which went unnoticed in the previous iteration. therefore if given another chance, we would use more realistic yet low fidelity sketches for paper prototyping. There are many such open source mobile app paper-prototyping softwares available which we didn't know about at that time. By using these software we could increase the clarity of different views and provide a polished view for user feedback at much earlier stage, further reducing the iteration cost of computer prototyping.