You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

DESIGN

IMPLEMENTATION

EVALUATION

Method

We conducted our testing using the same briefing and 9 tasks from GR3 Paper Prototyping. Throughout GR4 and GR5 the intended purpose of our application and it's features did not change, so we decided the same briefing and tasks would still be suitable and sufficient to test our finished implementation. 

During pilot and user testing our users were given the briefing and then began completing the tasks one by one as they were dictated. There was no demo given since our testing involved tasks that highlighted every main feature of the application. Therefore, any sort of demo would have caused us to bias user performance on some of our tasks. We opted to have more thorough testing with all 9 tasks, rather than give a demo and have to omit some of the tasks from the testing process.

During user testing, in addition to the briefing users were given instructions to think out loud, to not worry about how quickly they completed the tasks, and to feel free to give up and ask for the solution to a task if they got frustrated. 

In both situations our users were completely representative our our target audience, as they were all current MIT students.

Pilot Testing Results

Pilot testing was conducted on four 6.813 / 6.831 students on Demo Day. All four users had no trouble completing each of the 9 tasks but provided feedback that brought to light the following issues.

  1. Cosmetic (graphic design): Two users pointed out that the add/delete group button looks too similar to the google maps navigation buttons. This issue however did not affect their ability to figure out what the buttons were for, so the issue was deemed cosmetic. To alleviate this issue, we could have affordances for those buttons other than a "" and "-". For example, the button for adding a group could read "+ Group" instead of just "".
  2. Minor (visibility): One user initially thought the status text field was for searching. This is because the status text field says "your status message" when it's blank, but once a status message is submitted, there are no other hints what that text field is for.  To alleviate this issue, there is enough room on the left-hand side of the status bar to include the label "Status: "
  3. Major(visibility): It was pointed out that managing friends and hiding / un-hiding from a friend is delayed with no feedback. The response time for these features are too long, and to fix this issue we would have to modify our backend. Local variables would get modified when information is submitted to the server, so that the user can see the result of their actions right away as opposed to having to wait for a response from the server before changed are made visible.

User Testing Results

 User testing was conducted on three students who have never taken either course and have never been educated in user interface design through any other sources.

REFLECTION

  • No labels