Design Refinement
Posted on 11 Nov, 2011
Prototype Changes:
Removal of favorites list and comparison feature
One of our original design decisions which we chose to exclude in our prototype implementation was a favorites list to store sublets of interest. After analyzing our personas and talking to potential users we realized that the utility provided by a favorites list would be minimal when shopping for sublets. Individuals interested in getting a sublet have little interest in comparing sublets and just care about finding a place to live. This can clearly be seen in Stressed-Out Stan who wants to find a sublet quickly. He is more concerned with communicating with a large number of perspective landlords rather than attempting to communicated with the best two or three sublets. This is one example clearly illustrates how individuals looking for sublets would rather focus on breath rather than quality of results. On a similar note we planned to develop some sort of comparison feature between different apartments, but for the same reasons as the favorites we decided to abandon the idea. Since sublets do not just want to contact the best places comparing sublets is unnecessary.
The design changes manifested themselves in our prototype by removing the shopping cart icon we planned to have in each of our listing results.
Although never fully implemented we also decided to remove any kind of comparison feature from our prototype.
Date Entry
In our implementation of our prototype we chose to not include the expandable date selection icon. Our paper prototype incorporated an expanding date selection screen with selectable calendar icons to make it easy to visualize the amount of time a user selected for a sublet. We realized that this feature was not really necessary for our users since they have very defined dates provided by their jobs or internships. As a result uses only require a start and end date and do not need any additional visualization tools. With this in mind, and the goal of consistency in our main "dealbreaker" search fields, we implemented a simple text entry start and end date search icon.
This implementation makes our design much simpler and minimalistic. This makes it easier to use and reduces unnecessary pop-ups which detract from the users train of thought.
Price Entry
Much like our date entry feature we decided to simplify and clarify our price entry method. In a revision of our paper prototype we incorporated an interactive slider into our price search feature. This would allow the user to interactively move the high and low price range around and see how the results changed. This idea, while very interesting and easy to manipulate, had severe limitations which the selectable range and resolution of the slider. The edge cases for prices less than $1000 and more than $3000 would be very difficult to support with that method and the users we inter vied did not like the idea of a perceived limitation. To address this issue we simply made two entry fields for minimum and maximum price. This keeps our interface consistent with our date selection method and makes it very easy and clear to understand how the search function operates.
Sort by Most Recent
Something we realized was very important in our prototype implementation was sorting of the search results. In our paper prototype we used dummy listings which were placed in an arbitrary order. We focused mostly on how information was presented to the user and not how that information was sorted. Because our personas will frequently visit our website to check on new listings we decided to sort all of the listings by date posted.This would allow our personas to view the most up to date listings which would be beneficial for both people looking far in advance (Look Ahead Larry) and people searching at the last minute (Stressed out Stan).
We made a conscious decision to increase simplicity and not give various options to sort by price and start or end date. This is because the probability that a listing is most relevant to a user drastically increases if the listing is closer to the current date. If a user refined their price search they could be looking at very old listings which would have a low probability of still being available.
Got rid of badges and mini-icons
In our paper prototypes we included various badges and mini-icons to clearly indicate which listings fit the users search criteria best. These icons matched the "dealbreaker" search categories but only contained a picture. We also included icons which were intended to tell the users quickly which listings were "hot" and should not be overlooked.
After preforming our cognitive walk-through we found that these icons were not clear and made the listings cluttered. We instead decided to put the relevant information for each listing in plain text so that the user could easily see and interpret the data associated with each listing.
Focus on the "dealbreakers"
In our paper prototypes, we had built our design around giving the user many criteria that they could use to search for listed apartments. Users had said that the apartment search process was tedious, and that they had to look at many listings before they found one that was worth visiting. But upon reflection, we realized that there really was just a small set of criteria that was absolutely crucial, and that other things like "distance to a bus stop" were much more flexible. When people are searching for a long-term important, users would be willing to take more time and make sure that all of their secondary criteria were fulfilled, but for a three month sublet these were much less important. Users found the first apartment that worked, and just went with that.
We identified location, number of bedrooms, price, and dates as the most important, or "dealbreaker" criteria in the search. If any one of those didn't match, there was no reason to show it.
Simplified side panel
In our paper prototypes, the side panel that popped out when a user clicked on a listing was quite complicated, and included multiple tabs each with its own separate information. In our paper setup this worked fine, because the users usually only "clicked" on one or two listings, and they spent around 30-60 seconds on each one and read all of the content. On a computer prototype though, because the side panel loads instantly, it is very efficient to click on many listings and only read the side panel for a few seconds each. This wasn't clear from the paper prototype because we were limited by our speed in manually swapping the pieces of paper around. Because of this, we decided to simplify the side panel and only include one screen, with all the content easily. We also found that users often judge a craigslist post, and the poster himself, by the way the post is written. Conveying that information to the user is helpful in their decision to contact a poster for more information. By putting the actual listing itself in this side panel, users can quickly click on many listings and read all of the posts. This ties into our other decision to show more listings to a user and allow them to narrow them down themselves.
Prototype Instructions:
The Subletter prototype is intended to provide a improved search experience of scraped Craigslist sublet data. The prototype assumes that you are searching for a sublet in the Boston area. The website allows you to specify four main search categories to search for a sublet: location, number of bedrooms, price range, and date range. Once a user is done entering any number of the specified four search categories they can click the search button and see the corresponding results returned sorted by posting date. If the user does not specify any fields all the results are returned.
Each listing contains the basic information about the sublet including a general title description, photo, address, price, number of bedrooms, and posting date. If the user is interested in more detailed information about the listing they can click on it to bring up a more detailed listing window. This window contains additional pictures, the actual add taken from Cragislist, and a button which links the user directly to the Craigslist page where the listing was taken from. Clicking on another listing will replace the current expanded window with a new one corresponding to the newly selected listing.
This primary task which this site seeks to improve revolves around the searching process. The following tasks all represent possible usage scenarios of the Subletter.
Task 1:
Assume you have 3 weeks until your internship at a web start-up begins. You are looking for a place to live in the Boston area and you do not want to spend a lot of money since you need to live on a start-up salary. You want to email a large a large group of sublets and just be done with your searching experience. Use the Subletter to do this.
Task 2:
You have 1 week before you job at a marketing firm in Boston. You need to find a place to live. You don't care where you live, who you live with, or the price of the apartment. Your job is only for 3 months at which point you will move to a new city. Try to find a reasonable apartment using the Subletter.
Task 3:
You are going to move in with your significant other in Boston. They have a job and you do not. The place you live is very important to you since you will most likely be spending large amounts of time there. Search for an apartment which fits your needs.
Contributions
Matt B - Most of the programming on the prototype, and 100% of the work on the class website.
Scott - Some of the back-end work on the prototype, and work on the design refinement document.
Matt A - Images and visual work on the prototype, and most of the work on organizing and collating the design refinement document.