DogPack - GR6 User Testing

Table of Contents

Design

As expected, our design has changed drastically from how we first envisioned it. Through the many evaluation stages, a common theme amongst our feedback was the need to simplify the interface. As a result, our majority of our focus through the various iterations of the design was on simplifying the interface while still offering the functionality wanted by the user.

Home Page

Current Home Page : 

In our paper prototyping stage, the home page contained separate sections for upcoming meetups and previous meetups, and invitations had to be viewed via a dropdown which was triggered by clicking a button in the navigation bar. After performing user evaluations on the paper prototype, we quickly realized that separate sections made the home page too crowded, and users had trouble recognizing the invitations button in the navigation bar. In the computer prototyping stage we tried making the sections smaller and adding more affordance to the invitations button, but feedback from heuristic evaluations were still negative. As a result we did away with the sections. During our GR5 implementation, we tried using a Carousel, since it lets the user view multiple items within each section quickly. But we realized, while this might have been good to scroll by items within a section, it was crowding the homepage with multiple sections, each with a separate carousel. So for our final version we replace it with a tab view for viewing invitations, upcoming meetings, and past meetings. Because upon login the invitations should be attended to first, the notifications tab is set as the active tab when the home page is loaded. We also added a header to point out how many pending invitations a user currently has right below the greeting headline, and fixed the sizes of the images in each tab to increase internal consistency.

Rating Feature

In the paper prototyping stage users felt the affordance of the rate buttons wasn't good enough, and in the computer prototyping stage users brought to our attention, a lack of feedback and safety with clicking the negative or positive buttons.  As depicted in the screenshot, we addressed the users concerns by using colorful buttons with better affordance, and using a confirmation dialog when performing negative ratings to increase safety. We also provide feedback by disabling the buttons once a review is submitted.

Profile Page

During the paper prototype stage, the design of this page was cluttered with attributes about the dog and comments left by reviewers. We simplified the design by first reducing the amount of attributes that are shown about the dog, and using white space to properly group items. We also made sure to only show positive reviews versus listing every single review that the dog has received. Because we fixed these major problems, feedback regarding this page from heuristic evaluations was generally positive. The only major change from the computer prototype to the final design for this page was making the meetup button more descriptive by replacing "Meetup" with "Let's Meetup!".

Schedule Page

The schedule page has undergone many subtle changes that have made it much more learnable and efficient to use. During the paper prototyping stage, we allowed the user to either select time slots in the calendar, or fill out a form that contained fields for the date, time, location, and message. Almost all users agreed that filling out the form was much less efficient than using the calendar. We addressed this by disabling the time field and adding a placeholder that tells users to select a particular time slot. Users also complained about the location field, unaware of exactly how to use it. We dealt with this by adding a placeholder that tells users what to enter, and also added autocomplete to the field to increase efficiency. These changes worked out well, as we received much less negative feedback regarding this page during the computer prototyping stage. Multiple users specifically commended the use of the disabled text field to display the time of the selected block. The only major change change between the computer prototyping stage and the final design is the color of occupied time slots. These were changed from red to grey, since in most cases red is associated with an actionable item.

Remaining Pages

The final design of the search page, the review page, and the respond to invitation page are show above respectively. The few significant changes to these pages, such as adding autocomplete to the search page for efficiency or listing a users schedule in the respond page, were captured early on during paper prototyping. Other then a few cosmetic issues that were fixed after heuristic evaluation, these page have not changed much since the computer prototyping stage.

Below are some of the major design decisions made during the different evaluations of our project.

Paper Prototyping:

• On the schedule page, place the date and time fields on separate lines
• On the home page, change the "History" header to "Previous Meetups"
• On the search page, add autocomplete to the location field to increase efficiency
• On the home page, replace the calendar that shows upcoming meetups with a list
• On the home page, give more affordance to the rate buttons for previous meetups
• On the schedule page, highlight the current date in the calendar

Heuristic Evaluation:

• Make photo sizes constant regardless of aspect ratio for better internal consistency
• Change all text located in the body of every page to a standard serif font
• On the profile page, change the "Meetup" button to "Let's Meetup"
• On the home page, give more affordance to the rate buttons for previous meetups
• Show a confirmation dialog whenever the negative review button is selected for better safety

Implementation

Our website backend was implemented using Ruby on Rails. We picked Ruby on Rails because it makes hosting web applications quick and easy and one of our teammates had the necessary expertise. The front end is coded in HTML, CSS and Javascript, while the back end is coded in Ruby. The application is hosted on Heroku and uses a PostgresSQL database. We used Twitter Bootstrap to style our app, providing it with both internal and external consistency.  We used Github to host our code and provide source control.

One implementation problem we encountered was the need to communicate between Javascript and the back end. This communication is necessary to populate the map view in the search page, and to populate the calendar on the schedule page. Fortunately, there is a RubyGem called gon that makes communication from Ruby to Javascript incredibly simple. Another implementation problem was integrating the static HTML, CSS, and Javascript that we developed during the computer prototyping stage to the Ruby on Rails file hierarchy. Ruby on Rails handles file includes and dependencies differently than what we implemented with the static files, so in order to properly preview the website one must install Ruby on Rails, run the server and edit the files in the Rails project. Compared to editing static web pages, navigating and editing Ruby on Rails files can be somewhat daunting if you are not familiar with it.

Evaluation

Briefing:

For our user testing, we decided not to show a demo, since our aim was to make the application as easy and intuitive to use as possible, and the best way we felt we could test this was by observing the users use the application with the least amount of guidance possible.

We personally briefed each of our users on the purpose of the application and the tasks they were required to perform.

Task 1 : Respond to the invitation from Lassy

Task 2 : Search for dogs in Beacon Hill and schedule a meetup with Cupcake

Task 3 : Review a previous meetup with Allen

Task 4 : Reschedule the meetup invitation from Tony

User Population: 

Each of our users have pet dogs and are very passionate about their dogs. Interestingly, all of them were excited to hear about our application, since they felt they did face an issue of finding ways to socialize for their dogs. Some of them have been using workarounds which we feel that our application has been designed to address in a better way.

User 1

How conducted?

We found this user in the basement of MIT Ashdown House and conducted the test using a group member's laptop. 

 Representative

• He's been a dog owner for  2 years and the dog is about 4 years old. 
• The user bought the dog from another owner because he really loves having a pet. 
• He often socializes with his dog (roughly twice a week) at MIT Ashdown Community or Boston Common Park. His dog has a "social circle" and he usually schedules meetups with friends from that circle. 
• He would love to learn how his dog could meet more friends and play at more places.

User 2

How conducted?

The user is a sibling of one of our teammates and we conducted the test on the user's personal Macbook Pro.

 Representative

• The user recently adopted a 5 year old female Golden Retriever. 
• The user takes the dog out to play almost every day to a local park. 
• The user exchanges emails with other dog owners to schedule meet ups in the evenings.

User 3

How conducted?

The user was a dog-owner we ran into in a library and offered to help test the application on his laptop. He even offered us his
German Shepard's picture for use in our application

 Representative

• The user has a 3 year old male German Shepard

Usability Problems

Reflection

Looking back on the project and the course in general, it is amazing how many preconceived notions we had. All of our team members have a technical background and
our 'right way' of developing applications is heavily biased towards a programmers point of view. Each group exercise helped us not only understand why these might
have been incorrect, but also taught us the best way to avoid such mistakes, verify our ideas, and fix our issues (different from bugs!).

The biggest challenge we faced and our most valuable lesson was - "We are not the user". To start with a major impression that we are left with is how important it
is to communicate and receive feedback from possible users every stage of the development process. Designing an interface is much unlike sketching or painting on a
canvas where the artist is at liberty to hide for days working on a masterpiece. We benefited greatly from the feedback cycle. The early paper prototyping stage
helped us sketch up multiple ideas of how the application should look like and test and verify our assumptions (such as filling up the homepage with sections with
lots of information to give the user a complete view of the application, was a bad idea). This helped us narrow down to a simpler interface in our computer prototyping
stage where we sketched what our application looked like on an actual computer. Looking back if we feel we could have come up with a few more versions at this stage
that might have helped us avoid a few issues as we went on to the next stages. Even after implementing a fairly meaty version of our application, the final stage of
user testing where we met with actual dog owners still revealed a few lingering issues in our interface. We found that not only are multiple rounds of prototyping
important, using different techniques at each stage is important too, and at each round we were able to asses which feature requirement was truly irrelevant enough
to reject and keep the interface simple.

We realize from this that it was in our own interest to design a project for a user class we did not belong to. We were extremely apprehensive about switching from our
initially intended application to this one. But picking an application about which we knew nothing is the best way to avoid assumptions. It is now clear that each stage
was indispensable and perhaps could be even more advantageous if taken further. By this we mean that we felt for example, that if even some of our early prototyping had
used actual dog-owners, we might have learnt much more earlier about the usability of our interface for our intended users.

Going further, we could have added elements for internationalization and accessibility, as both of these are important aspects which we had overlooked. For example, one
scenario could be Blind users with guide dogs.