Design Development
Posted on 16 Oct, 2011
The Subletter
Introduction:
Our team is currently in the process of redesigning the process of exploring and searching for sublets. The proposed system consists of a website called “The Subletter” which allows users to perform searches, based on a simplified list of criteria, for sublets in a specified city. This product is intended to scrape data from Craigslist and other sublet listing sites and preset it in a form which is easily searchable and visually appealing. The system employs graphical search tools which allow users to contextualize their search queries with regard to physical metrics. This provides the user with real time feedback and allows them to refine their queries in an interesting and intuitive way.
We have created a paper prototype to help us develop our proposed interface. The prototype contains many the possible scenarios a user could find themselves in while using our application. This both allowed us to further develop and refine our understanding of the system while giving potential users a very clear representation of what the system will look like and what functionality it will contain. After creating the prototype we brought in prospective users to interact with the system and gave them several tasks to accomplish using our prototype. We were able to clearly see which aspects of our prototype were clear and intuitive and which were confusing or incomplete. With this knowledge we were able to modify our application to make it more intuitive and effective for potential users.
Prototype:
Our prototype for the “The Subletter” consists of various removable elements which can be easily modified to reflect the changing queries to the system. Initially the user is presented which a main search screen which makes it very clear what interaction the user should have with this portion of the interface.
After the user types in their city they would like to live in they are brought to a new screen which contains an interface to further refine their results. The results space is initially populated with results after the initial search and dynamically changes as various filters are applied.
The search window has four main search criteria: location, price, number of bedrooms, and dates. These are the four key sections we feel our persona's would require to effectively sublet an apartment. To allow our user to specify these fields we created live icons to make the experience more intuitive and give real time feedback.
Some of the icons lead to sub screens which give the user a way to specify their criteria with a real-time feedback.
Since many of our persona's also have requirements outside of the four main categories we integrated an extras tab where they can specify other criteria which is important to them.
As the user refines their search space the listings continually change to reflect their criteria. Some listing which fit their criteria well will have icons on the main listing viewer indicating that they meet a specific criteria well. This allows the user to quickly see which listings are good for them so they do not have to sort through a seemingly endless list of apartments. If they user would like to get more information on a listing they just click on the listing and an extras tab appears with more information on the listing, a link to the website the listing was pulled from, and a tab to email the potential landlord.
With all these options a potential user will be able to adequately search a large pool of listings for apartments they want.
Method:
- Participants:
We picked a broad range of users all with varying degrees of experience searching for a sublet. We attempted to pick individuals who were most similar to our personas since our design decisions were based on their needs. Before showing the prototype to our selected users we tested it with another member in the class. This brought out any obvious things which we left out which were critical to the use of the application. This allowed us to revise our prototype so our feedback from our target users could be more constructive.
One of our users had significant experience searching for apartments online and had experience with various other apartment searching applications. For the last two summers he sublet an apartment in Seattle and San Fransisco. We choose him since he has a strong grasp of current apartment searching tools and would provide useful feedback on features we are missing in our design.
We also interviewed a pair of college students who did not have the prior experience of looking for a sublet. They did imagine that they would need to look for future internships. The reason these participants were chosen is because they most closely modeled the user group of people finding their first sublet. Although they did not have the experience and insight of interviewees who had searched for sublets before, they were a great way to watch an unfiltered first experience with the process.
Another one of our test users had significant experience in the DC area, which was a different perspective than we had gotten from other users. His experience was largely similar to the others we had talked to.
We also re-interviewed a number of users who we had talked to in the earlier stage of our design. This gave us an early chance for feedback on how we iterated through some of the ideas they had mentioned in our discussions.
- Task Scenarios:
- Procedure
A task we presented to some of our interviewees asked them to look for an apartment a month in advance using our application. This followed what we outlined in our user script. This task is consistent with something our personas Look Ahead Larry or Particular Phoebe would do. Since this task requires extensive use of our search tools we were looking for how clear and easy they came across to the user and how they met their search needs. Also since the user needs to compare apartments with this task we were looking for how our apartment listing representation conveyed the features of the apartment.
To test our prototype we asked the user to sit down and act as if they were using a computer. We had a team of two people at every interview to be the computer and take notes. We limited our interaction with the user while they were searching to see which features were obvious and which were not intuitive. A revision we made after our first proof of concept test run was adding transparencies to our screens to make it easier to customize the interface to the users changing searches. As the user selected various things the person acting as the computer would reflect those changes on the prototype using a marker on the transparencies.
After we got a sense that they were done experimenting with our prototype we opened up a discussion with them about the prototype. We focused our question on two main areas: what we were missing and what we did wrong. Because most of our users have had experience searching for sublets they are familiar with what features are most useful to them. We had a list of potential features which we made decisions to exclude based on our personas and we were wondering if those decisions were valid or if our actual users needs were different. The second subset of questions helped us refine our prototype and fix any of the main problems we had.
Results
Users loved the date selection feature. A number of them said that this had been the most annoying part of searching for a sublet online. For a longer-term apartment, the exact start date on the lease, beyond the scale of a few weeks, is usually not important. But if an internship that is only 10-12 weeks long, 1-2 weeks on either end can be a big hassle. Almost all users said that the date availability not lining up would be a dealbreaker, and it wouldn’t be worth seeing them in the results. One user said it would be good to have the option for the start or end dates to be flexible.
Overall, users thought the visual map for selecting the location of the apartment was more uniform than having to type in the name of a district in the city manually. They also perceived it as more reliable. One user was confused by the button, and thought that it would provide a visual map of all the listed apartments. Another user, who in a previous internship commuted to his work by a shuttle, wanted to have finer control over the location than by an overall district. One user was looking for an apartment in an unfamiliar city, and would have liked to see data and statistics on the site, to help them decide where they would want to live.
Rather than traditional boxes for “maximum price” and “minimum price”, we decided to just put a box for “target price”, and have it algorithmically decide which apartments to show based on their closeness to the target and matching of other criteria. The users like that idea in theory, but some said they had a price in mind that they weren’t willing to pay more than, and wanted to have that option.
We had the “computer” for the prototype reorder and remove listings every time the user changed any of the criteria. Users liked that the results were “live”, but weren’t always sure how the listings were being ranked. Some assumed that they were listed chronologically, like on Craigslist. It also wasn’t immediately clear what it meant for a listing to be labeled as “Fresh” or “Hot”.
Some of the users said they would like to loosen up the sorting and ranking criteria, such that it showed more responses rather than more “accurate” responses, because they weren’t always sure what they were looking for. Because the listings weren’t listed chronologically, some users said we needed to add something to show which listings they had already looked at. On Craigslist they can just check every day and only look at the new days listings.
The “extras” tab did not get used as much as we expected. One user was so unconcerned about filtering out apartments that he didn’t even bother clicking on it. Even most of those that did click on it didn’t add any criteria, saying that they would rather see more results than risk filtering a good apartment out. One wasn’t sure how the filtering process would work.
Test Measures
One of our big design decisions we made was to go with four key search criteria for apartments: Location, Price, Number of Bedrooms, and Date Range. We wanted to see how the users interacted with these search criteria, and to see if they were actually the most important things users wanted when searching.
In case users wanted finer control over the search, we added an “Extras” tab where they could specify their own criteria. We wanted to observe if the users interacted with this tab, and if so, to what extent they used it.
We also wanted to observe our users response to our ranking system, which does not sort the results chronologically like most other sites. They is a key distinction, and we want to see if users adapt.
Discussions
During a preliminary dry run, we realized that our paper prototype was not fully refined and interactive enough to create a realistic simulation for our test users, and would hinder our ability to collect quality feedback. In our initial prototype, we didn’t have things like a “back” button or the ability to change a date after the user had entered it. As designers, we fully understood how to work our system, but didn’t consider that others would need to play with it to fully explore its capabilities. For our actual tests we went back and added these features.
One of the things that our test could not tell us is how the user would have interacted had it been a true web application. In a number of cases, the users we were testing with got confused over whether certain features were interactive or not. One thought that an indicator icon we were displaying on a listing actually was a button, and tried to press it. On in actual website we’d have the graphical ability to make it clear that it wasn’t interactive, but doing that with paper prototypes was harder.
For most users, apartment hunting is a significant time investment over many weeks, but we were only able to spend a short amount of time with our test users. Some positives or negatives of our design would not become clear from one 45 minute session, but there isn’t a feasible way for us to collect usage data over a longer period of time.
From our initial user interviews, we found that finding a sublet was in many ways an emotional experience. The significant amount of money at stake and the fast turnover on sites like craigslist can all lead to feelings of stress. It’s difficult for us to replicate that in a prototyping environment.