EECE 418: Pass 2 Portfolio – Homing Pigeon April 9, 2009 

Nicholas Jakobsen ‐ nicholas.jakobsen@telus.net – Student #: 38253027 

Steven Liu ‐ skliu_ubc@hotmail.com – Student #: 76763994 

Tylor Sherman – tylorsherman@gmail.com – Student #: 82968066 

Will Motz ‐ will.motz@gmail.com – Student #: 90396045 

Section A: Redesign and Prototypes 

Redesign Rationale 

It is safe to say that we learned a lot from our first pass of the project. The feedback from our evaluators suggested that we came up with a design that tries to accomplish too much and confuses our users. After the discussions we realized that we were trying to target both the house finding and the social aspects of a traditional rental website. This meant that some features such as the “nudge me” feature had little place in our design but crept in due to a desire to appeal to both groups. 

After much reflection, it became apparent that we would need to choose one target audience and attack this target with a more effective set of features. This targeted approach called for a redesign and prototyping of our low level designs. We realized that renters looking for housing are only interested in a short experience without the hassle of profile creation and login. 

Another important discovery that we made was the conceptual model of finding a house. House hunting is basically a search; it requires multiple filtering processes that narrow down the results from a large set down to a smaller one. There are a few traditional methods associated with searching; just like how you would go about narrowing down the choices associated with purchasing a laptop, you would go through a similar process of narrowing down a rental. The most obvious process is the filtering process, people like to enter a criterion and continue to tweak that it until there is a manageable number of results left for the next stage. Our user studies showed that the next natural stage for the users is the comparisons stage. They like to line up the postings that they like and compare them by sorting using a column like way. While they are comparing, additional information is likely needed for some of the postings, so they need to make contact with the landlords to schedule a viewing of the properties. 

Knowing all this information about the mental model of a renter has greatly helped us in narrowing down our design. We need to associate our design so that our system model is consistent with this method of filter, contact, and finally compare. This provides a natural transfer to the application. We planned that we would have a filtering page with a map and various search elements that would assist the user in narrowing down what they want for their new home. Following this page, there would be a sorting page that uses the results from the previous page as the data for the sort. Users can sort according to criteria such as number of bedrooms, rent, and floor area, allow pets, etc. Finally, there would be a page that allows us to contact the landlords through a quick message interface that uses your email. 

In our discussions we realized that there are a few additional features that can greatly add to the user experience to help them while filtering the search results. For example, users foreign to a city will likely need to know information such as the nearest shopping centers, bus stops, and other areas of interest. We can add this to the filter page where we can adjust the map according to the areas of interest. Normal map search interfaces can also be greatly improved and instead of searching for all listings within say 2.5 km of a point of interest, we can give the users an option to turn on automatic map searching. This will only carry over the results of all listings visible on the current map and is a more intuitive way of visually searching for information. In addition, there are a few useful overlays such as crime rate and property value that might be of interest to the renter. So having an eye catching way of displaying this information such as by colouring certain areas red if it has high crime is another effective way to accomplish this goal. 

Finally, I think the greatest change from our pass 1 portfolio is the realization that we are not going to tackle a social networking site. We analyzed the need very carefully and our intuition suggested that house finding is a rare event that may only happen once every couple of years. Because of how dynamic the rental housing market is, it does not lend itself well to social networking. Roommate finding was another one of our original ideas, but after some carefully conducted user interviews, we found that the time it would take for a renter to find a roommate would greatly slow down the rental process. This slow down hampers the renter’s ability to react to listings and the place might be rented by the time they are ready to look. We thought it was impractical to design an interface that would target this audience and this is the main reason why our design is greatly focused on the house renting process itself. We strive to give users an efficient way of narrowing down their search and a tool to compare the results which we believe will result in a far more optimized house searching process. 

Additional Analysis and Evaluation In refocusing our design we worked through a few paper prototypes; they are included here along with some discussion surrounding them. 

Following is our master prototype, showing our intending flow for the site and detailing some of the features we would like to include: 

 

The first row of boxes shows the intended path the user takes through the site. First, they use a map to select areas of the city that might be desirable to live in. They can add points of interest, filter by price, add tags, and look at overlays with data for things like crime, population density, and housing prices. The main purpose of this mode is for the user to select an area they would like to live in and from there they can find houses. In the second mode, the review mode, they are given the list of place that they chose. They can then evaluate each place in a table with the available data. Data included is price, services, neighbourhood, and distance to each point of interest selected in map mode. Here is an example page: 

 

After the user has determined which places they would like to pursue further, they can then switch to contact mode. In contact mode they work through the list of places sending a message to each place. Our initial vision of contact mode looks like this: 

 

Prototype Illustrations Our final medium fidelity prototype brought together all of our ideas and helped to test real users with our system. Here is the homepage of our site: 

 

The user then enters in their search criteria to help narrow down their search and as they do this their results are dynamically updated. Also available are overlays to provide additional information about the neighbourhood they are looking at: 

 

Once a user has found results that they like they click ‘Continue’ to move on to the review screen. Here they can look at more specific information related to each place and review the distance to each of their points of interest. They can also sort this information by clicking the column headings to drill down into what is important. 

 

The user then chooses a couple places by selecting them in the ‘Contact Listing’ column and clicks “Continue”. They move onto the contact screen and here they can review their selected places and send out messages to each of them: 

 

The user can move backward or forward to any step by choosing the links to each step at the top. They can also bookmark their session by choosing “Bookmark this session to return to it later”. This generates a unique URL that they can also share with others. 

Section B: User Evaluation Plan 

Background We planned a series of user tests along with a questionnaire to help us answer some of our questions regarding design choices. We needed to find out whether our conceptual model of a shopping cart system can truly help people sift through the listings faster than the traditional Craigslist way of doing things. To do this, we needed to find out what are the most important things for people when it comes to finding a place then use this information to drive what we are going to test on. As such, we went about conducting a questionnaire first which allowed us to find out the top priorities of the renters. Then we designed a series of tests that mostly focus on these top priorities as comparison between our site and doing rental searching using Craigslist. 

Type of Study The study was a questionnaire and a user test. The questionnaire contained four questions and the user test contained four tasks. 

 

Hypothesis Our hypothesis is that the users will be able to achieve their objectives faster with Homing Pigeon than their alternative preferred method of conducting housing searches. 

Our other hypothesis is that a design with icons is easier to use than one without icons. 

Size / Makeup Of Group We had mostly users between the age of 20 to 30 in our group, there was also one user who was over 40 years old. The users were largely proficient with the internet and knew how to search for things rather easily. For the questionnaire, the users were spread out a little bit more between the age of 20 to 35. We conducted the study on 8 users and questionnaire on 20 respondents. 

Tasks In order to do the study and take out any of the learning effects, we had to train the users on our interface. This also served as a test to see whether icons made it easier for users to perform the various tasks. So our first test was for the users to enter a few simple search criteria such as “check off balcony and parking spot” using the website search. We turned the icons on and off for the different users and observed how long it took them to complete the test. 

After this, the next test they were given is to find a place that fits a specific search criteria, such as being very close to SFU and between a certain amount of money. The users did these two tests using both Homing Pigeon and also whatever preferred method of search that they had. The results are used as comparison. 

Finally, the users were given a way to use the overlays such as crime rate and property value. They were asked to find a place that was far away from crimes. This test was used to see how the users interacted with the overlays. 

Variables Independent Variables: 

• Number of listings that you can choose from. • The ability to sort listings. • Availability of marker info window. • Number of points of interests. 

Dependent Variables: 

• Time for users to find the points of interest. • Total time of test. • Number of page views that they do before they figure out what to look for. • Nuisance Variables: 

• User’s ability to use the system. • User’s age and IQ in general. 

Section C: User Evaluations 

Subjects Our subjects were mainly between the age of 20 to 30 years old of all different ethnicity and both male and female. For the questionnaires we had some subjects who were slightly older between the age of 20 to 35. The rationale of choosing the subjects this way was to ensure that we would target the core audience of our product. Our initial market research showed that renters tend to be younger than home owners and thus the age group was appropriate for the study. We focused mostly on the student population; but for our test we were able to get a couple of non‐student users to try it out. This represented our more professional users. Due to a lack of access to older participants, we weren't able to find many subjects who are over 40 years old. Perhaps next time an improvement would be to find subjects who are more in this range so that we can cover the whole range of our customer base. Another assumption of subjects is that they are relatively proficient with the internet. This should theoretically be a sound assumption; if you aren't great with the web, then you wouldn't really use our service in the first place. 

To give a better idea of our subjects, here is a typical example of a subject, please note that this is simply a fake representation of a subject and not an actual subject: 20 something year old female student who is doing her master studies and who tends to look for places that are in safer areas. Another example would be someone who is over 30 years old, a business professional and tends to look for higher scale apartments in the downtown areas. 

There were some subjects who were used once before in pass 1. We thought that tainting the subjects might be an issue; however, upon further examination, it became apparent to us that the design between our pass 1 product and pass 2 product was sufficiently different that this would not interfere. The subjects were recruited from our personal contacts, we did not do any cold calling or cold meetings to do the experiments. So in a way, this may have been a problem that they were biased toward our design as they do know us. But it was hard to recruit subjects who were totally strangers to us. One advantage of knowing the subjects is that we had a good understanding of their background and was able to better decipher the feedback. 

Evaluation Results To evaluate our design, we used a questionnaire and a set of observational tests. The results we gathered can be grouped into three categories: 

• Feature Desirability: Which features do users actually want? • External Comparison: How does our solution compare to others? • Internal Examination: How well are our features used? 

Our participants were personal acquaintances between the ages of 20 and 35, and for the most part are, or recently have been, students. This introduces a significant bias toward the young student demographic, where price and proximity to school and transit play a significant role. Unfortunately we did not have more subjects available. 

Feature Desirability Assessing feature desirability was accomplished with our questionnaire.  The first question asked the participant to rank price, location, number of bedrooms, and available facilities in order of most importance to them. By assigning 9, 7, 4, and 0 “points” to the 1st, 2nd, 3rd, and 4th choices respectively, each quality we were asking about would then have a corresponding number which we could easily compare to the other options. Our results for this test can be seen below. 

Location  178 

Price  107 

Number of Bedrooms  68 

Facilities  54 

 

Using this method of evaluation, Location is a clear winner (19/20 participants chose it as #1), reinforcing our decision to follow a map centric interface. 

Our second question asked users how many points of interest (ie. school, downtown, grocery store, liquor store, etc..) they generally consider when looking to rent. The purpose of this was to see if our POI feature would even be desired by our users. A plot of the frequency of each POI value is provided below.  

 

The mean and median are both four, suggesting that our users would generally be concerned with their proximity to multiple locations. Also, no participant indicated they were concerned with one or none POIs, with the minimum received value being 2, providing further evidence for the desirability of this feature. 

Our next question asked participants how many landlords they usually contact when house hunting. This was asked to determine if a streamlined messaging interface would actually help users. This would be the case if multiple landlords are usually contacted. The average of the results was 6.8, suggesting that users do typically contact many landlords, justifying our decision to provide a streamlined mass‐email interface. 

Our final questions asked users to specify how useful uncommon information about a location is. These included Crime Rate, Popularity, Traffic, Night Life, Distance to Transit, Property Value, and Average Age of the local population. This was too see what kinds of overlays a user would be interested in when looking for a place to rent, the practicality of obtaining this kind of uncommon information was not a concern. Our results showed that participants were primarily interested in popularity, with some additional interest in Crime Rate and Distance to Transit. The other available options had such a low response that we suspect those data points are simply outliers. 

External Comparison For our external comparison, we performed an observational test and timed the participants run. The participant was given the task of founding a rental unit with certain criteria, first on our site, then using a method of their choosing. We performed two tests in this manner, labelled Test 2 and Test 3. The first set of criteria was: 

Test 2: You are a new student at Simon Fraser University, find and contact the closest house to Simon Fraser University that costs no more than your $1000 / month budget that includes internet. 

The second set was: 

Test 3:You are a successful businessman, find and contact the most expensive listing in the downtown area so you can brag to your friends 

The times for both of these comparison tests can be seen below. The red dot marks the average in each group. 

                 

In both tests our design proved faster, but to a lesser extent in Test 3 than Test 2. A more useful quantity to investigate is something we call Proportional Improvement in Performance (PIP). To obtain this value, we normalized each of our data point pairs so that the “other” data point corresponded to a value of 1. One minus the average of the “Homing Pigeon” data points gives the PIP. For Test 2, the PIP was 10.23%, while the PIP for Test 3 was a close 9.78%. 

The advantage of this method is it allows us to easily compare separate tests which could take significantly different amounts of time. Also, with the assumption that users will have a similar proficiency with both methods of house hunting, this method scales well to a wide range of skill levels. 

We can say with 82% certainty that our design provides a ~10% improvement in performance over current methods. 

Internal Examination We conducted two internal examinations, each of which was an observational test. The first examined whether the use of icons to indicate features proved to be helpful to users, as opposed to just plain text. The participant was asked to carry out a specific set of tasks using our interface, and the time they took to accomplish it was recorded. Depending on the participant’s ID, they were either shown an interface with icons or one without. The results of this test (Test 1) are shown below: 

 Icons proved to improve users performance, but without more subjects we were unable to find a statistically significant correlation between the presence of icons and the time to complete the test. 

Our final test sought to see if users would take advantage of the features provided to them. Similar to our external comparison tests, the participant was given a set of criteria to find in a rental unit: 

Test 4: You are a single woman new to the city, find and contact 5 listings with a concierge, a maintenance attendant, in a part of town with low crime. 

This is a trivial task when combining the crime overlay, a POI marker, and our sort features, but is a difficult task to accomplish with current methods of searching for housing. This test was qualitative, as the area of interest was how the participant would attempt to solve the problem when presented with these new and unfamiliar tools. We found that while most participants understood how to use the overlays, POIs, and sorting separately, they did not consistently make the connection that these could be used together. This would suggest that further training in the interface is required or that some more visible hints be present in the interface. 

State of our Design At this point we have some valuable ideas but also think there are some ideas about our design that need improvement. We thought that the map worked very well for finding places to rent. Users found it both intuitive and powerful and they were able to do complex searches not normally available. Interacting with this data visually was very useful. All of our users could see the value of this representation and it helped them to excel on our user tests. The point of interest plotter was another feature we thought was very valuable.  We didn’t see this available on any of the competitors we looked at and it was great to be able to compare places this way. We felt that most people look for a place that is near all of their points of interest and seeing exactly how far away they are would help greatly in finding a neighbourhood or place to move into. The overlays were another distinguishing feature that 

we thought worked well. Our user feedback indicated that this was a nice way to see what places were actually worth taking a look at. All of this combined and updated dynamically as input is received became a great way to look for places to rent. 

There were a number of features that still need a lot of improvement. One specific example was the point of interest finder, a little search box to help plot points of interest. In our user tests we purposely chose some points of interest that our users might not know. We then found that this feature was extremely underutilized and we only saw one user touch it. This was surprising and we think it would need to highlighted in some way in the next design iteration. Other places we still think need improvement are the review and contact screens. We thought that there was a lot of duplication between the two and wondered if this could be simplified. Also, on the final contact screen we found that the ‘Currently mailing’ organization of this was confusing. Most of our users expected that all of the places would be selected and simply entering an email address and message would send it out to all of the places. The problem is that since none are selected at the start, they also need to select which places to send the message. We thought this was a good way send different messages to different places but found that overall it was confusing. 

We think that at this stage we have a lot of good features but it still needs a lot of refinement. We were happy with the design but found that it was often confusing and difficult to understand for our users. It would be great to have another round of design and testing, and we think this would help to iron out some more of our problems. At that point we think that our system would work well for our identified users and tasks. 

Design Reflection 

Improving our methods We saw our design change due to feedback we received during the heuristic analysis and review sessions with the professor. As a result we simplified our design, deciding to focus strictly on the process of finding rentals and contacting their owners, instead of incorporating a social aspect into the site. This left us with a fairly barebones product so, during a meeting with the TA, we decided on a number of features we could provide that would make our product unique. These features were designed in time for the heuristic analysis phase of the project, but at this point we hadn’t completed any user studies to support their inclusion in the prototype. 

Our medium‐fidelity prototype was fairly functional, because the tools we used allowed us to construct it fairly quickly. However, this may have led us away from the particular lessons this course was trying to teach. Since low‐fidelity prototype was significantly different from our medium‐fidelity prototype in terms of features, we didn’t have much feedback on the overlay feature, and we had no information on our point of interest system. Had we been in industry and not in our graduating year of university, we would immediately have devised some low‐fidelity tests to determine whether or not users wanted overlay and the ability to specify points of interest. Due impending delivery date of 

the medium‐fidelity, we put these features into the new prototype and decided to perform the related user tests in Pass 2. 

In order to gather some feedback about the features in Pass 2 that we hadn’t done low‐fidelity prototyping for, we created a questionnaire that we distributed to potential users. We wanted to know what types of information people might want to see represented on overlays and how many points of interest users consider when deciding where to live. From the feedback we realized that our questionnaire could also use a bit of design work as some of the responses had checkmarks in fields we had intended for numerical ratings to be entered. 

Though our tests showed that users did prefer the ability to specify exact locations they were interested in living near, the most reliable data on this topic was gathered from user commentary rather than a specific tests. The three of the four tests that we devised involved the POI feature, however, there were a number of factors that may have affected the results of our tests. In retrospect, the tests in which we asked users to find the closest or most expensive listing matching certain criteria may have biased our tests towards our system. Since our main competitor product, Craigslist, does not have a way to sort by price, our tests could have heavily favoured the Homing Pigeon system. To avoid forcing users to search through hundreds of listings, we tried to make the test more realistic by instructing users to find a house, similar to the one they found in tests two and three. 

Given the opportunity to redo the user‐testing portion of the process again, we would ensure that we had sufficient background study using low‐fidelity methods to justify each of the features we included in the medium‐fidelity prototype. We would also take more time to ensure our tests were representative of actual use cases, instead of being tailored to observe how users interact with the features of the prototype. Instead of giving the user a specific task to complete and then comparing how long the same task takes on Craigslist, we would include more general tests that time users just using Craigslist to find some houses. We would then use this baseline as a target for our system to beat. We would also include more realistic data in our system in order to match listings typically posted on competitor services. After a set of typical use cases was determined, then we could have devised more specialized usability tests to measure the performance of the features our low‐fidelity tests. 

Reflections what we learned Definitely the most valuable activity we were asked to do was the user‐testing phase. It not only provided us with important feedback about our product, it showed us numerous ways in which our process was flawed. It is definitely important for students of HCI to have some practical experience, no matter how well or poorly our initial attempts were, the lessons we’ve learned through performing the tests and through meetings with the professor and TAs has exposed numerous ways in which we would improve our process given another chance. Ironically, it was also the user‐testing phase that was the least valuable in terms of the measured data. After we had begun testing we realized that the tests we had devised were not necessarily answering the right questions about our product design. 

Many of the usability topics like menu designs and visual perception have influenced design decisions in projects members of our group are currently working on. One member of the group has started using paper prototypes in his work, though still finds that sometimes implementing the actual functionality is faster than breaking out the tape and scissors, and has the added benefit of being as functional as the rest of the interface it is a part of. 

Section D: Resource Management 

Nicholas Jakobsen Nicholas is our Ruby on Rails expert of the group, he is the chief architect from a technical perspective. His main contributions included coding of the main prototype, building of the test suite, and coming up with various user tests to be conducted. 

Pre‐pass 2 time spent: 27.5 hrs Prototype Building: 6 hrs Test Suite: 4 hrs User Test conducting: 4 hrs Report Writing: 4 hrs Test Analysis: 2 hrs Redesign Meetings: 5 hrs 

Total: 52.5 hrs 

Will Motz Will helped out on conducting user tests, made many suggestions for our redesign, and participated in the evaluation of our test results. 

Pre‐pass 2 time spent: 28.5 hrs User Test Conducting: 5 hrs Report Writing: 8 hrs Test Analysis: 2 hrs Redesign Meetings: 5 hrs 

Total: 48.5 hrs 

Steven Liu Steve helped out on conducting of user tests, redesign meetings and evaluation of test results. He also assisted to put together the final report as well as the demo work. 

Pre‐pass 2 time spent; 27.5 hrs user Test Conducting: 5 hrs Report Writing: 8 hrs Test Analysis: 2 hrs Redesign Meetings: 5 hrs 

Total: 47.5 hrs 

Tylor Sherman Tylor was mainly responsible for fixing up the prototype and making it all run on his server. He also was responsible for the presentation preparations and delivery of final report. 

Pre‐pass 2 time spent: 27.5 hrs User Test conducting: 4 hrs Report Writing: 4 hrs Presentation Prep: 4 hrs Redesign Meetings: 5 hrs Prototype Writing: 4 hrs 

Total: 48.5 hrs 

 

Total time: 48.5 + 47.5 + 48.5 + 52.5 = 197 hrs spent on the project.