Alee – Homeowner to Parker
Team Project | Mobile Interaction Design

Alee – Homeowner to Parker
Team Project | Mobile Interaction Design

Quick Facts:

Role:

Interaction designer

Time:

Fall, 2014 (4 weeks)

Client:

Startup aims to create homeowner-parker sociology
(51-711: Designing for Interactions)

[Skills]
Methods:

Interaction design, Product/Service design, Persona & Scenario, Ideation, Storyboarding, Wireframing, Visual design, Iteration, Cognitive walkthrough

Tools:

Sketch, Illustrator, Photoshop, After effect

Deliverable:

Hi-fi wireframes, Scenario, Responsive web landing page, Dashboard design, Pitch presentation

Quick Facts:

Please see previous slide

Design brief: Imagine your team has been hired by a startup to design the interaction for their new mobile service, whose initiative is briefly described below. Besides that, the personas are also provided as a working base.

Homeowner to parker

Allows homeowners who live in popular neighborhoods to rent their driveways and off street parking spaces to people visiting the neighborhood. The app should support people with both long term parking needs and with immediate parking needs.

Our solution: Design a service accessible through mobile devices, which enables finding available parking spaces, scheduling, reservation management, and payment activities for both parkers and homeowners.

We first looked at the parking market and opportunities to enter:

so, for the startup:

Screen Shot 2014-10-25 at 6.46.22 PM

This can be done even without building any parking slots! There are a lot of unused driveways owned by homeowners around popular neighborhoods where people want to park. Alee is going to a front-runner in this market by surfacing the following:

Screen Shot 2014-10-25 at 6.26.50 PM

Here’s how Alee can address benefits for all stakeholders in the homeowner-parker social situation:

Service model

Screen Shot 2014-10-25 at 6.27.19 PM

User values

Screen Shot 2014-10-25 at 6.28.02 PM

Monetization

Screen Shot 2014-10-25 at 8.37.46 PM

A strategic focus: given that there are always more parkers need parking than people who can provide parking spaces, we decided that our main focus is to help homeowners with their driveways become more successful collecting extra earnings by using our service. This way we can expect a reliable user base to foster our service.

I enjoyed the process while starting from designing for the concept and getting down to crafting app experiences and the fine screens, I become more confident designing for a problem that is worth solving – that’s the best part I love about this mobile app.

Two apps, one solution

Parker’s alee app

Parkers can use this app to resolve parking needs all in one place: either parking around the current location or directly searching for parking that meet their time & location needs, and reserve the slot in advance.

Click the interface to interact ->
(presented using Axure RP 7.0)

 

 

presona-reb

Want a walkthrough? Let’s follow the scenario:

“Rebecca is a nurse at Good Samaritan Hospital… …She changes the length of time she wants to park from 6 AM to 4 pm and sets end repeat to 4 months from oct 6th when her morning shift will end… …she gets a list of suggested driveways sorted by price. Looking through the list, she notices… …gets a notification that her reservation has been canceled on Thanksgiving. She sees other recommended driveways that are similar to Madeline’s and reserves one of them… …”

Entire scenario walkthrough


(Click to step through scenario screens)

 

Homeowner’s alee app

Our app, Alee, makes it easy to help homeowners rent their driveways with minimum effort. They don’t need to worry about pricing, time, schedules, or collecting money from drivers, all administrative activities are intelligently processed through the app. The only thing they need to do is to indicate when the driveway is unavailable to rent to other people. Then homeowners are good to receive parking fees provided by parkers who come to the area with the need of a space to leave their car.

Click the interface to interact ->
(presented using Axure RP 7.0)

 

 



Want a walkthrough? Let’s follow the scenario (later part of the same scenario above):

“Madeline is a homeowner living in the hipster neighborhood around Good Samaritan Hospital… …realizes that her daughter and grandchildren will come celebrate Thanksgiving with her, so she needs to stay home and park her car on her driveway… …She checks if there’s reservation on Thanksgiving day by selecting the 27th. and sees that Rebecca and some more person already reserved to park… … turns off the parking availability for that day, and all reservations get canceled… … sees email sent from Alee that she earned $200 from renting her driveway this past two weeks and reminds her that payout has been made… …”

Entire scenario walkthrough


(Click to step through scenario screens)

 

Design process

1. Problem framing
At the beginning, we’re provided two personas about the homeowner and parker. We looked into it, discussed both problems for the two types of personas and opportunities for the fictional startup, as well as where, how, and from/for whom the value can be drawn from our service in the value flow diagram.

2. Ideation
With our value flow diagram we began creating potential ideas as many as possible. Maybe providing parking spaces associated with popular local merchants that lack parking facilities?

3. Scenarios
Bringing down to our focused solution, we created scenarios based on the two personas’ interactions & goals to walk through our service with stories, and to communicate with the service provider who’s making the App.

4. Wireframing
Sketched out the major screens driven from our scenarios, we wireframed out what will make the primary user interaction work in its screen structures. We chose to utilize current mobile design patterns to help navigate this new service we invented with focus.

5. Reflection & crafting
We used storyboards to inform the natural flow of people’s experiences. To tailor the design, we revised the scenario iteratively to make it much more to the point providing value for personas. Crafting the details also helped us fix places where the rules might break from the generic settings and be comprehensive delivering a meaningful UX.

6. Delivery
We delivered a pitch presentation of our concept. The pitch summarized our design process, main innovations & describes the UX by walking through example screens with our scenarios, as well as artifacts that proves the viability of this new service.

Problem framing & ideation

Whiteboard brainstorming

I am a big lover for whiteboards: this is a great starting point just to post thoughts in brains and share with the team to brainstorm together. Concept mapping: at first we tried connecting dots of the different entities in the design space, and mapped out the relationships and major information clusters, where we’ll zoom in to play around transforming that information density into organized services.

Check out real pixels of the concept mapping

Also, informed by personas provided, we are able to summarize the problems & opportunities, which helped to build a “hunt statement” that has a focus and frames out where to investigate. And based on that we started challenging ourselves how to make things people want but also make money (financially viable).

 

Initial value flow model

As the users co-creates the value through interaction with the service provider, we want to sketch the possible future from this service by seeing the ecology of value flow. Where the revenue resource might from? We initially probed on 3rd parties, and found that the local stores are connecting parkers and homeowners in a way it serves as a destination of where people want to park. This complicates the customer/service relationship, which might add value to our service.

ValueFlow initial

Scenarios, wireframing & reflection

Initial scenarios

We generate scenarios to help walk through the interaction details for the service based on the model we had from the concept ideation phase. At this point, we are still trying to incorporate local merchants into the design space.

example initial stbd

(Above: an example of one of the initial scenarios, walking through immediate parking situation)

The better scenario

As collecting feedback from the class & professor Zimmerman, we moved away from the idea that local merchants are directly associated with the service, as it seems high risk and creates much more complexity into service execution. Given the project time of 1 month, we shifted to focus on only homeowner-parker scenarios and really work on excelling those scenarios and the designs driven by that story.

Another important shift at this point is to realize the homeowner as a key strategic point to craft the experience. Parkers did not need to be that motivated to adopt a cheap parking service, and ultimately, it is the homeowner that provides resources that this service can lean on and foster the base of service success. Our goal then becomes more clear that we want to make homeowner’s experience really easy, that is, no service fee (we modified the value flow model), no adding additional burden on them regarding pricing & monitoring (we configured a pricing mechanism based on research). We even thought through what’s best to notify them with earnings they made (when, where, the context, in what notification form). In the end we decided to use email, at the last day of each two-week period to notify homeowners about payouts.

The right shows a later scenario where we’re in a good spot to walkthrough our focused solution.

Still, as long as we are iterating to meet new goals, the pitch scenario of the interface design should be different, as it is more about scenario of the app than about walking through the solution.


Wireframing

We started wireframing as early as when our initial scenarios came out, and iterated through evolvement of scenarios. After laying out the basic interactions & interface structure to navigate across the system, we chose to think increasingly critical about the set of screens that makes the service work, especially informed by user scenarios.

 

Interface design iteration

Thanks to in-class critiques, we led through a couple rounds of iteration on interface design utilizing patterns. We directed ourselves to be succinct on the logic of navigation and chose to adhere to existing mobile interface patterns (particularly iOS 8), because those patterns (calendar, creating repeatable events, tabs, lists, etc) are commonly interacted functions already performed from a day-to-day basis by our targeted users who are used to complete driveway sharing & tracking on the go from mobile devices. We chose to appropriately optimize the advantage by reducing the user’s cognitive effort to learn new things for existing mobile functions.

interface,iteration

Visual design

To communicate the design language specific to the app screens, we made sure to document the visual design (type, color, grid), the navigation, and the types of action a user can take. We ensured that by having the frame of 1136 x 640 (vertical), the embodied design language can be developed and good to be passed along to developers.

 

Responsive design

Harmony of value across devices

Our service can also be accessed via web/desktop. An example screen for homeowner’s landing page is shown. We utilized the flexibility of web screen space to show the reservation list on each day, next to the monthly calendar, where the homeowner can choose to see any day’s reservation within a month. Also, in order to help them become more successful using our app, we provide “peak time of drivers demand to use parking spaces” in the neighborhood of where homeowner lives, so that they can use that info to make more money on times that parkers demands most.

Service dashboard

To extend the story, from users to stakeholders…

We also designed a service dashboard that allows the startup to monitor if the use of the app matches the assumptions underlying the design. This dashboard includes a list of assumptions and key issues designers know the startup must monitor, generally in three aspects (laid out from top to bottom):

  • Transactions

  • Users types & revenue

  • Behaviors related to reservations

For instance, from the behaviors related to reservations monitoring, the Alee team can figure out what policies of time limits to set for posting a reservation & cancellation; in our scenario pitched before, “Rebecca can cancel a reservation no later than one day before the reservation happens”, is this a good time frame? We can gain some data via this dashboard by looking at generally when drivers cancel reservations, and really try to validate whether that’s a right design decision or not.

final_dashboard(for presentation)

Bootstrap our service

How people like “Madeline”s and “Rebecca”s get recruited to adopt our service

How to motivate people start using Alee when it’s a startup with ZERO user base? We thought about the reasons of why people are going to be recruited, as well as incentives and network effects to enable the possible future. We researched into similar business models (Uber, Airbnb, and Dropbox), and come up with the idea of getting paid through referral:

For Homeowners: if users invite friends to Alee, they both get extra money($5 per friend) when they get their payment notification. For drivers: if users invite friends to Alee, they both get a free parking up to $15. We could gain some initial users, especially homeowners, by having the marketing team goes out putting ads in popular local merchants near homes with driveways, but the merchants/stores have no parking, and then when these initial users started using Alee, in both mobile landing page and web landing page for homeowners, the prominent referral link should encourage them to recruit more people to join.

This way we can make our service viral.


(Click to see more details)