Restaurants Plus is a loyalty and rewards program by LivingSocial. Customers benefit by receive varying percentages cashback on their credit cards for dining at restaurants. Restaurants benefit from this program as it brings in new customers and allows them to drive traffic to their establishment during down times.
A mobile website already existed for the R+ program in a couple test markets including Atlanta & San Diego. It was passively informational in its structure and lacked anything further to incentivize and engage customers. The challenge was to discover, define and design an engagement strategy for a native app version of Restaurants Plus.
A Restaurants Plus native app that provides restaurant information based on immediacy and location by neighborhood, while that emphasizes the post-transaction cashback experience.
Lead UX designer and researcher for the native app. Collaborated with many people & teams including Business Intelligence, Marketing, Engineering, Product, Visual Designers and my fellow UX Designers.
Sketch, Flinto, Invision, Excel
HOW IT WORKS
Sarah is a 29 year old Assistant Marketing Director who lives in the Bay Area. She loves eating out with friends but it can get pricey and doesn't want to put the time into finding ways to save money. She also gets frustrated with knowing where to eat because online reviews aren't always reliable.
"It can be hard to tell how good a restaurant is. I’ll check Yelp reviews but usually I go to a place that someone recommends."
Native App Browse
RESEARCH & DISCOVERY
Interviews & Surveys
Before we could start to brainstorm ideas for the app, we needed to understand who our customer was and what problems we were solving for. We approached this in two ways:
Compiling findings from previous internal surveys, as well as research from our partner for the card linking technology.
Conducted additional surveys and interviews about eating habits and loyalty programs.
In addition to acquiring new customers, the most immediate target Restaurants Plus customer was the extensive LivingSocial customer base. Restaurants Plus had launched in two test cities so we had some early feedback from early adapters to compare the two customers.
People most frequently find a place to eat from offline sources - a consumers’ own knowledge of a restaurant, & personal recommendations.
Customers then used online resources such as Yelp or Foursquare to check the menu as well as ratings & reviews.
People tend to eat at the same places over & over again. Those restaurants tend to be in close proximity to peoples’ work & home.
The exception to this is weekends when people are more willing to travel to restaurant (a destination experience), especially when recommended by family or friends.
The most common search filter is “distance from me” followed by ‘neighborhood’
Restaurants Plus users tend to be searching for a place to dine now and are concerned with proximity of the restaurant. LivingSocial users tend to plan in advance.
"I saw it [the restaurant] on my way home from work. Then I looked at the Yelp rating."
"I had a doctor's appointment in the neighborhood. My sister had told me about a good lunch place close to there so I decided to check it out."
Primary Pain Points
Needing something physical, like a card, to use program
Feeling like the program benefits the company more than the customer
“They just want to get my information.”
“I always forget my card.”
"What do 'points' really mean?”
To focus and humanize the data we collected from the interviews & surveys, we created personas as a guide for our design process. The current Restaurants Plus customer was a different age and income demographic than who LivingSocial wanted to target for this app, so we made a secondary persona the focus of our work.
We needed to discover and learn about our competition. Our first objective was to understand the how others approached the food and loyalty spheres in order to figure out the opportunity for Restaurants Plus. Our second objective was learn about the tools and strategies used to sell these apps to customers. For this second objective, we expanded our research to business models in other industries.
We’re not going to win on merchant volume & density
We’re not going to win on browse alone
We’re not going to win on social alone
From the research and interview findings, we were able to articulate the problems & pain points that were opportunities that could be solved by the Restaurants Plus native app. Starting with those needs, we brainstormed ways to approach and solve the problems that we had identified.
Problems to Solve
A social component for friends & recommendations
Validation - ratings & reviews
AND......What is the hook?
We played around with a variety of approaches but they all lacked the ‘hook’ that we were looking for. Finally, as we sketched out the steps involved in finding and transacting at a Restaurants Plus restaurant, we realized the emotional impact of receiving the ‘free money’ from your transaction cashback. This was the ‘hook’.
You just got free money. What are you going to do with it?
Restaurants Plus Engagement Cycle
VISUALIZING & TESTING
Now that we had discovered the emotional ‘hook’ of the post-transaction cashback, we held design studios and starting to sketch, test and iterate on ways to visually solve the the pain points, research findings and post-transaction cashback ‘hook’.
Post-Transaction 'Hook' Concept
Post-Transaction is the primary native app use case.
What does this post-transaction 'hook' look like? We decided on an approach that appealed to both sides of human nature. Each time a user transacts, they have three options for what to do with thier 'free money':
Donate it to a local cause
Bet it in a raffle
Get the cash back on thier credit card
And users need to have the app installed to manipulate your cashback.
With the post-transaction cashback experience being the focus of the Resturants Plus native app, pre-transaction browse becomes a function of the cashback. It places urgency on the cashback as a decision criteria and, in response to our research findings, is immediate and neighborhood-focused.
Sketching & Iterating
First Browse Iteration
Revising & Refining
To discover the best way to display how to browse for restaurants we created multiple combinations of map and list views. The hybrid map and list view tested best, followed by a full list view and a full map view. The view that was least sucessful was the map view with a single restaurant tile so we eliminated that from the app.
Map View with single tile
Revising & Refining
When designing the map and list view, we researched how other leading applications structured their browse screens, focusing primarily on Google and Apple maps. The screens that tested best mirrored the structure of Apple maps so those were the views that we handed over to the engineers. The feedback we received from the Android team was that several of our requested interactions were not technically possible.
To solve this, we brainstormed and mocked up various potential browse screens and interactions with both the Android & iOS developpers, trying to balance the feedback we received from user testing with what was technically feasible.
The comprimise we ended up with eliminated the hybrid map & list view as this was the primary technical challenge for the Android team. We replaced the hybrid view with a single restaurant tile map view, a view and interaction that mirrored Google more closely. This balanced the need for a map view with the need for a quick view of restaurant information.
In retrospect, I would have shared the browse wireframes with the Android and iOS Developers at an earlier stage so we could have accounted for the technical limitations in the design process.
The browse experience is only one aspect of the LivingSocial Restaurants Plus native app, we continue to build out this experience for iOS and Android.