Driveway

Our Goals

Driveway connects people who own a parking space with people who need to use one. If a homeowner isn’t using his driveway from 9:00am to 5:00pm while at work, then he can monetize its downtime by letting a nearby worker park there. If someone from out of town wants to park near a stadium for the game day, she can rent a local’s driveway for a few hours.

Design challenges

The first issue we had to resolve in our design process was choosing what aspect of this service to focus on: helping a driver find a parking space or letting a host manage the spaces they would offer on Driveway. We decided on the latter, since the interface for drivers would be too difficult to implement sufficiently for the evaluation to be useful. The two aspects would be separate experiences, since their context of use would be quite different, and we have shown that split in the first few screens of our prototype. However, we do need to consider the drivers’ experience in some design choices for the host, such as whether a driver would make an appointment in the future for a space or if the service would only allow instant, timed use like a parking meter. Since the latter is already a common way of implementing parking services, we decided on that. The driver would claim a space for a certain amount of time, pay the host, and need to leave or ask for an extension by the end of that time.

Another set of issues we had to consider were legal and security questions. Most importantly was how a host would deal with a driver who didn’t follow the rules like leaving the space on time. The best way to avoid that situation would be for the agreement to occur in person before the driver leaves the car in the host’s space. If someone were to park in someone else’s driveway and leave, then it’s likely that the only recourse for the host would be to call the police; whereas, if that person’s driveway or street front were posted then they could simply call a towing company to remove it without involving the police. If avoidance was not possible, then it would be best for each party to have the other’s personal information like license number and home address. This was more in the domain of service design and business issues than interface evaluation, so we did not include these in the design we will evaluate. However we will bring up this issue in a general questionnaire with our users to glean more insight to their preferences and concerns. There is also the possibility that hosts may try to use this service to profit from parking on the road next to their driveway, which is often public property in suburban and urban areas. Without having an approval process by legal experts, this would be difficult to prevent in our design.

Finally, we wanted to know the most reliable but socially acceptable way of directly connecting our hosts and drivers in case they need to ask a question or announce something. The most direct way of doing this would be for users to see each other’s phone numbers, completely separating Driveway from that experience. However, people may not want to have their phone numbers and addresses publicly available, although that was the norm when phone books were in common use. We considered also using an internal messaging system that many popular social networking sites use. Sites like LinkedIn even allow users to accept and respond via email without the user’s actual email being released. That would make it more difficult, though, for instant contact that may be necessary in our already short-term service objective. So we took a middle way of allowing hosts and drivers to see each other’s listed contact information (phone number and email address) only while they are engaged in their current parking agreement. There is no user lookup or persistent public profile for people to simply browse for that information, so it reduces users’ exposure. However, users cannot be prevented from saving that information manually once viewed. We will confront this issue in our evaluation.

The primary problem we are tackling is lack of parking choices for commuters to busy areas. Our service’s design remedies that by making use of personal parking spaces left vacant during people’s business hours, which increases access for others and monetizes the spaces’ downtime for hosts. The part of the design we are evaluating is the interface for the hosts’ interface, which borrows heavily from standard parking technologies like meters, simple cash boxes for lots, public parking signage, and more robust systems for parking decks. We combine this workflow with the user experience often found in services like AirBnB and Couchsurfing. We designed for the transaction experience of the former and the asset management of the latter.

Combining the two experiences to also handle the ubiquity of personal parking spaces led us to design for a mobile smartphone application. Since two of the three of us doing this project do not have a background in mobile app design, but are comfortable with iOS devices, we used a simple iOS prototyping tool to build the model to be evaluated. The service is not necessarily only meant for iOS devices, and it may even be best implemented as a web app depending on our evaluation results.

Some design decisions were made with assumptions based on our research, a few already mentioned. Most importantly, we must assume that people who manage a parking space like a driveway would want to host someone in the first place. We assumed that people would expect their space vacant again when they needed to return, so we provide the option of a time period in which people can park there similar to existing parking management technology. From a more personal perspective, we assume hosts and drivers would want to be able to contact each other immediately more so than they would want to keep their phone number private. We should consider the consequences of both in our evaluation. A minor design decision was to allow hosts to offer more than one parking space, such as driveway and lawn. This way hosts can take more advantage of how their property can be chunked into usable spaces. Our design should scale well regardless, with the exception of commercial operations for whom we did not design. That is, our app’s design is not optimized for handling all the spaces in a parking deck.

Prototype

Driveway is intended to be a mobile application. Our prototype for evaluation is a conditional series of interactive screens using Wizard-of-Oz techniques to provide sufficient feedback for the participant. The prototype was built in App Cooker, an iOS prototyping tool that’s easy for inexperienced designers and front-end programmers to use, so the interface was designed in this case for iOS. The final system would not necessarily be only for iOS, though.

Evaluation

Users were generally very interested in the idea and overall satisfied with most of the app. Our results show that our experience design worked well with their mental model of the service, judging by the task completion time and follow-up interview.

Our interface design had a few glaring flaws, notably the two buttons discussed previously. Correcting those flaws would be our primary technical concerns moving forward with actually implementing the prototype as a fully functional application. It would also benefit from having a web app interface, since the user is not necessarily mobile. Incorporating both the hosting and space-seeking user experiences was the primary motivation for designing this as a mobile app in the first place. However, hosts may prefer to administer their open spaces from their laptop at home, so a non-mobile interface may be more useful.

Since our service’s interaction design seemed to be well-received, improvements to the service would be largely concerned with payment and better discovery options. For example, we may integrate a payment method like Paypal that would allow hosts to associate a history of people parking in their spaces with a Paypal transaction receipt. Otherwise, payments would happen in a separate system, handled entirely between the host and parker.

Our prototyping software, AppCooker, scaled well for our complex user journeys, but it required the prototyper to be well in control of its organization. It was a very useful tool for the two members of Team AR that did not have a design or user interface programming background, but it did get somewhat complicated to manage the many different interactive affordances and how they changed the user journey.