Help Infatuation users find the best ⚑ restaurants in their city while keeping track of their favorites ✪
Background
In 2018 The Infatuation tasked me with updating the iOS app which had previously directly referenced Apple’s Human Interface guidelines and lacked its own brand application. The app primarily focused on lists of restaurant reviews and city guides in a sortable list. In terms of map functionality, the product was limited and only included outbound links to other geo-location based apps. We wanted to introduce more features for users looking for restaurants in the moment as well as serve users looking to plan ahead for a special meal.
Our goals & REQUIREMENTS
❶ Maintain app usage, monitor user feedback
❷ Prioritizing location-based restaurant discovery
❸ Introduce a map-based search experience
❹ Allow users to save restaurants
❺ Increase MAUs and time spent on guide and venue pages
LIMITATIONS
Due to the existing API and taxonomy on our web product, we were unable to allow users to search in another city. A user needed to manually select a city in order to browse content within.
For this version, instead of a location input for search, would need to use filters to browse by neighborhood. We would, however, be able to include search using the map.
We would also not be including user accounts in the app, instead we would store user data locally. These would all be later improvements on the roadmap post-launch.
IA & NAVIGATION
At a high level, the app was city-based. Based on The Infatuation’s existing IA, the app’s core function was to funnel user’s to a review page. A guide is a collection of review pages based around a theme or situation. All reviews are tagged with cuisines and neighborhoods, allowing users to filter content using those tags.
The app would function as a layer on top of a map. Users could save restaurants as favorites and apply it as a filter/search constraint on the map which would also reflect in a list view. In addition, users could search and filter on that map to narrow their results. If a user wanted to view another city’s content, they would need to manually switch to that city.
WIREFRAME ITERATIONS
I looked at existing map-based restaurant discovery experiences, knowing our V1 scope was limited, we had to keep things simple and light. I decided to create a single view that would combine search, a user’s saved list of venues, and a feed of content.
The default view would be the map-based search/discovery experience. I considered a split map/list combined view in which we could show them relevant neighborhood restaurants as soon as they open the app based on their current location. Users could search and narrow their results using a term input and filters if they wanted to search elsewhere. They could save venues by starring them on the venue page or by long-pressing them on the list view.
After getting stakeholder buy-in for the app update, I began thinking about the UI based on our existing design language used on the site. I also started testing interactions and flows using Principle.
TESTING LEARNINGS
After putting prototypes in the hands of staff and Infatuation fans, we began to realize forcing all features into a single view was confusing to users, they saw them as separate tools and mindsets. Additionally, many asked where the latest reviews and guides were in the app. We learned many users wanted to use the product to purely browse, reading the reviews and guides for entertainment and not just utility.
At this point I included a navigational tab bar to split the views between the content feed, the map discovery view, and a user’s saved list, which the business called the “Hit List”.
FEEDBACK & UPDATES
We hired an external agency, Sneakers, to handle the development of the app. Their engineers would work in our office allowing more collaboration and immediate feedback. We also spent a lot of time tweaking the map and search logic to ensure we were displaying the proper results.
I set up a testing plan with the Product Manager in which we weekly had company staff in all of our city offices complete a series of scenarios in order to test the usability of the app in their context. We held these sessions both in person (NYC) and over Lookback, recording them and taking notes when applicable. We observed where they expressed confusion, frustration, and how they felt completing the task. We also used this opportunity to find lingering bugs. We looped critical feedback into our engineering sprints in addition to major feature work.
POST LAUNCH results
Post launch, we slightly increased our user base. More importantly we maintained our existing base. Sessions increased by 20%. Our engagement time (reading) is 9 mins which increased from ~3 minutes per session. There are plans to improve the app experience and a backlog of tickets with fixes and feature improvements slated to be tackled in Q4 of 2020.
If you’re looking for restaurants, check out the app.