• Created by Unknown User (emoore24@mit.edu), last modified by Unknown User (tarakris@mit.edu) on May 15, 2013 13:13

GR6 - User Testing

Design

Design Overview

The idea of the design was to mobile focused because of the touring and moving aspect of the application. Most of the interface was reduced to just tapping and sliding, which were very easy operations to do with just one's finger or thumb. The only times where the user would have to use more would be when typing in the Search or Feedback sections.

Home Page

 

The home page and the checkin page represent two design structures that we use throughout the interface with the aid of jquery.mobile. The home page shows a very familiar list of options with big buttons to press. During paper prototyping every user was able to dive right into the application because getting to other pages was very intuitive. 

Question Queue

The question queue was the focus of our application in the interaction between tourists and tour guides. In our computer prototyping design, each asked question was labeled with a time-since stamp, however most users were confused by this. i.e. "How many students go here?   10min" means the question was submitted 10 minutes ago, but it was confused with "will be asked in 10 minutes" and "The question was answered 10 minutes ago." For our final design, we removed this. Having the new questions drop to the bottom of the queue was enough to show the user how the system worked.

Stories/Profile Pages

 

The story page is very similar to the home page in that it is essentially a list of items. In paper prototyping, users frequently weren't sure if you could click on the stories to go somewhere else, but this issue was solved in computer prototyping. In earlier designs we also had an excerpt from the story instead of the whole story, but in computer prototyping, most users didn't seem to mind it too much as they were still able to skim stories quickly. 

The profile page is very simple, with only the student's photo and various facts about themselves. Users varied between wanting the profile information already expanded or if they wanted it expanded when clicked.

Events Page

Like the stories page, the events page is essentially just a scrollable list. However the events page allows for changing the date and does not allow you to click on the events. The idea of only having a "Previous Day" and a "Next Day" buttons came by in paper prototyping because most tourists would only be in town for a few days and could thus find only relevant information. The URL was descriptive though and used the ISO standard of YYYY-MM-DD, so more advanced users that wanted to jump to specific dates could just type them quickly and simply into the URL.

General Stats/FAQ

The design for this page showed the differences between Paper Prototyping and Computer Prototyping. During paper prototyping, very few users understood how to move the graphs around and would end up either stuck or would try to click on the small grey circles below the graphs. However, during computer prototyping everybody understood how to slide the graphs from left to right without any direction at all. This shows us how you have to take paper prototyping results with a grain of salt and should retest design decisions on the computer if you have doubts abut their learnability.

Feedback

The feedback page was very simple. We used sliders for all three inputs because of their easy entry on mobile devices. Users asked for discrete sliders though, because they found it would be easier to decide on a rating if they were given a discrete range instead of a continuous range.

Map

The Map page ended up being very simple, with just a map zoomed in on one's current location. Originally there were going to be additions to the map design, but they proved too ambitious for the scope of this project. This page became useful just because of the accessible map even though it was empty otherwise.

Implementation

Back-End

The back end of the web site was built using Node.js and Express. The decision to use Node was mostly for self-improvement purposes, as no one in our group had used node before and wanted to learn something new.   In addition, Socket.io was used to build the event driven portion of the app, mainly the Question Queue.  The database used was Postgresql, interfacing via the 'pg' module.

Front-End

The front end of the web site was built using HTML, CSS, and Javascript at its core.  However, many frameworks were involved.  For one, the javascript was served using Embedded Javascript (EJS), which is a templating system.  In addition, Jquery Mobile was heavily used, which provided us nice ajax animations and mobile widgets.  The decision was made because we figured the biggest use case was on a mobile phone.  Other frameworks include Swipe.js for the Stats page, and jquery-rate-it for the stars on the feedback page.  

Implementation vs Usability

The main problem with our implementation versus the usability of our system was in the time aspect.  By attempting to build our system on a new infrastructure that we were not familiar with (node), there were many speed bumps and getting up to speed to do usability fixes proved very difficult.  Much of our time was spent trying to generate data dynamically and setting up the database than usability fixing.  In hindsight, it would have been preferable to do a framework we were all familiar with (i.e. rails) as opposed to something new, as that would have allowed us time to make more usability changes.  The technical learning curve was our biggest obstacle.  

There were other usability fixes that we just didn't know how to do. For example, we were unsure how to augment the Question Queue to include upvotes and to allow the tour guide to remove questions. The latter would have required a tour guide portal that we did not have time to do.  The Maps page initially was going to include a path indicating the current tour, current location pin, and a color overlay across the buildings so that the tourist would know what type of building they were walking by (for example, coloring all administrative buildings red, all computer science buildings blue, etc.).  This would require a lot of customization with the Google Maps API, which would have been tricky.  The 'schedule meetup' feature was supposed to notify the student via email, however that was not fully implemented due to issues getting email to work with node.js .

Evaluation

To evaluate our implementation of the ConnecTour UI, we crashed a tour being conducted on Monday and asked three tourists to test our interface. The three users we found to conduct this round of user testing were tourists, although they were unfortunately not all prospective college  students. Early on in this project, we determined that our target user population would be what we called "story tourists": prospective students who were interested in hearing specific and detailed stories from college students about what the college was like. However, as it was already hard enough to find students who were prospective students, let alone "story tourists," our user population was the closest we could find to our desired target population.

Our user test was conducted on the user's mobile device on some modern browser (e.g. Chrome, Safari, etc.). The users were given the briefing and tasks to do below.

Briefing

Problem:

Our group is trying to solve the following problems for college tourists:

  • College tourists often have trouble finding campus events/activities, accessing current students for more specific inquiries.
  • Tour Guides tend to spend time repeatedly answering common questions from tourists which detracts time from the tour.
Goals:

Our goals for the ConnecTour UI are the following:

  • Find out about events on campus
  • Facilitate interaction between tour guides and tourists
  • Facilitate student-tourist interactions
  • Find out about general stats/frequently asked general questions easily
Information about you, the user:
  • You are a tourist at MIT (if possible, put yourself into the shoes of a prospective student).
  • You are about to check into a tour in the application before the tour begins.

Tasks

  1. Check in to a tour and Ask a question to the tour guide.
  2. Find a fact that interests you about MIT.
  3. Find a dance related event happening either today or tomorrow.
  4. Find where you are on the map.
  5. Find a story that interests you and schedule a meetup with a student who wrote a story.
  6. Leave feedback for your tour guide.

User 1 Problems

  • The user enjoyed the color scheme and found it aesthetically pleasing
  • The user found difficulty understanding what types of questions could be asked to the queue.
  • The user had no way of removing from the queue.
  • The user did not understand what was on the General Stats page until clicking on it.
  • The user pressed back on the events page expecting it to bring them back to home, but it brought them to the day they were previously on (unexpected).
  • The user did not like all of the text on the stories page. 
  • The user would have liked a place to add events to a calendar.
  • "Previous" and "Next" were slightly confusing. Would have preferred "Previous Day" and "Next Day"
  • The user pressed on the story expecting to see it again in an "expanded" view, not the profile page.
  • The profile schedule meetup button does not give feedback after pressing submit.
  • Stars were missing from page when user visited.  

User 2 Problems

  • The user liked the font for ConnecTour.
  • The user didn't like that they had to refresh the page to see their question added to the queue.
  • The user would have liked to see something more in terms of ordering, such as time or numbering.
  • The user didn't know that the General Stats page was going to be general stats/FAQs about MIT specifically.
  • The user had trouble reading the graphs in the General Stats page.
  • The user initially thought events were clickable on the Events page
  • The user would have liked to see his own GPS location on the map.
  • The user found the Stories page overwhelming with the amount of text.
  • The user would have liked to see suggestions of what they could search, or filters they could use to look up stories (didn't know what kinds of stories were available)
  • The user didn't like that Schedule Meetup was a popup. He would have liked to see it as a separate page.

User 3 Problems

  • His tour guide wasn't listed under MIT which was confusing. We used canned information bc we didn't know who would run the tours.
  • Wasn't sure if the Map page was supposed to do more than it did.
  • Wanted to focus on the school and looking around, so he would only use the app in uninteresting or quiet places.
  • Didn't know what the Star rating on the feedback page was for.
  • Didn't know where his feedback was going to go (to the tour guide or to their boss.) and seemed concerned.
  • Would prefer if the feedback page had discrete sliders. Continuous ranges were hard to choose from

Reflection

The main thing we would do differently in the class would be to try and focus on a more specific problem for our project.  We think it would have been fruitful to work on just the Question Queue and use that as our application, rather than trying to satisfy every need of our target user group.  We think the final product would have been a lot more polished, and we would have had more time to work on usability issues, which is the focus of the class. We may have even had time to focus on catering our UI to another one of our other user groups: the tour guides. We also made the decision to use node.js for this project. However, since none of our members had prior experience with node, we spent a lot of time trying to learn node on the fly while coding our application. Since every member on our team did know Rails, if we had coded our application in Rails we could have spent less time on the back end of the application and we wouldn't have had to compromise on our UI and everything we wanted to accomplish with it.

This course was a very interesting introduction into the world of usability testing.  We all came into this class with high expectations, and the we feel as though the whole the class delivered.  The lectures were engaging and interactive and we learned a lot.  More specifically, we learned how to effectively user test, complete heuristic evaluations, methods of prototyping and the iterative design process, the 3 main principles (safety, efficiency, learn ability) of design, and the importance of typography and color schemes.  We also had a brief introduction to the internationalization and accessibility of design. The project gave us a chance to implement and experiment with many of these ideas. We feel that the process allowed us to grow a great deal as computer scientists and helped develop the way in which we view UI design. Two members from our team do regret not making it to the panel in class this semester as well (they were late each time), as they felt as though they would have gained a lot as active participants. However, overall our experience in that class has been fantastic. We had great support from our TA Chong-U along the way and we would like to thank him for his patience and help in every step in this project! :)

  • No labels