When I first started at New York many years ago, restaurant and bar listings were among our most popular products. They helped define our online identity before we were known for anything else. The combination of authority and comprehensiveness in our listings made us a great resource that our local readership could rely on.
The Problem
With advances in Google search results and the saturation of the listings market, the company saw a steady decline in consumer engagement. In August of 2012, there were 1.6 million visits per month to listings. By 2018, that number had dropped to around 250K.
There was little benefit to maintaining such a comprehensive group of listings (at the time we were supporting over 6,000 restaurants and bars), but our authority was still quite valuable to our brand, to our readers, and to search engines. Basic info (hours, location, contact info etc) is easy to come by; meaningful, trusted insights into experiences, less so.
With all of this in mind, the business decided to lean into the idea of recommendations as the focus for the next phase of listings. The project scope consisted of three central design tasks: a stand-alone listing page, an improved search experience, and a section front for our food content.
“NYC listings shows the most consensus for why people use nymag.com.”
Team and Role
I worked with another product designer, the project's product manager, and several engineers throughout the process. Although the designer was more senior than me, my institutional knowledge and company familiarity meant that I was often the point person for stakeholder check-ins. We met weekly with our CCO for feedback or to work through any blockers and shared frequently with the larger product design team.
While I helped gather competitive research and provided recommendations for the stand-alone listing page, my primary focus was on the search experience. When my coworker had to go on maternity leave mid project, I ended up taking over all remaining design needs.
The Search Experience
What Does Success Look Like?
First and foremost, don’t make anything worse. With such poor numbers already, it was essential that getting rid of so many listings didn't affect our SEO equity and therefore our company revenue.
Upgrade the underlying tech. Modernize the platform by moving the tool into our latest CMS and incorporating Elastic Swiftype to handle data storage and output.
Go where our users are. With over 70% of site traffic coming from mobile, we need a mobile-first design approach.
Emphasize that we are knowledgable about New York’s food and bar scene. Features such as autocomplete and trending show we know what what the user is looking for even if she doesn't.
Always provide clarity. Our categorization of filters must be user friendly and the UI should help illustrate why certain filters narrow and others expand results.
Competitive analysis - search
Because the search experience was more about functionality than features, I felt screenshots of competitor user flows were the best way to gain insight. I thought if I could solve for the hierarchy of information on a smaller mobile screen first, especially with 70% of our users coming from there, desktop would more easily fall into place.
Unnecessary friction between searching and seeing results. Try to avoid additional slideout, but nice to see some of the filter.
Too often complex filtering led to zero results. Which filters should increase results and which should limit?
Display selected filters for maximum clarity.
Implementing typeahead autocomplete promotes idea that we are knowledgable and helpful.
Categorization of filters should make sense to our users.
After she went on maternity leave midway through the project I took over her design responsibilities. While the initial design had been implemented by our development team at this point, there was a lot of design QA and additional concerns to address.
The main challenge was defining a stronger content hierarchy.
Search tool
On the tech side, we used Vue to build the search tool framework and Elastic Swiftype for results and autocomplete capabilities. These third party implementations allowed for more control over how the filter types interacted with one another - whether they narrowed or expanded the results - as well as flexibility for future scaling needs.
I worked with my product manager to establish the three core user flows - free text search, simple filter search, and complex filter search. The biggest challenge was designing a seamless flow between multi filter selection and the list of results. I wanted to avoid any confusion over whether a filter request had been submitted, which meant both states should always be visible unless the user chose to hide one. Working through mobile first, I began my sketching with pencil and paper to get a three dimensional feel for the product. I could more easily play around with the moving elements and it helped me understand what felt the most natural and intuitive.
Exploring the concept of a tray interface, I moved my sketches to the computer where I could separate out the flow and go step by step through each state. I then used InVision to create a rough prototype to share with users for feedback. We were able to validate that users understood our grouping types and filtered by neighborhood and cuisine first. Pain points included confusion over scrollability of filters and results list. Lastly, users requested more restaurant info be displayed within the autocomplete dropdown.
Feeling generally solid about the mobile interface, it was time to address desktop. If I could do this project over again, I would have considered desktop at an earlier stage. I felt that to accomplish the same seamless transition between states, we should organize our filters along the left side rail of the page. The company, however, has a long standing ethos that mobile should flow completely fluidly into desktop and vice versa. While I normally agree with this position - and understand the cost of managing two distinct sets of html code - in this particular situation I don’t believe it provided the most beneficial user experience. Unfortunately I was overruled by upper management and so moved forward with an interface that matched the mobile experience.
After much refining and researching UI options and exploring different animations to arrive at the best combination of elements, the final design came together. Everything displays within the same screen and yet it is still clear and easy to use.
