search on nez

Researching and designing a new search experience for nez users.

What

iOS and Android app

When

November 2019 - February 2020

Role

User research, UX & UI Design

Intro

nez is a local food and drink offers app that helps people save money and discover new places. Initially just covering Fitzrovia, since 2018 the app has expanded to cover most of Central London and now sees tens of thousands of daily users. I have been UX Lead throughout this period, working closely with the founding team Dan Greane, Joe Zender and Mitch Bayer-Goldman.

For this project I worked alongside Guillaume Goujon my amazing PM, Dan Greane the CTO and the developers Adam Lyth and Osama Rahman. Thanks also to Jo Miguens and Frankie Molyneux for helping with the retagging this project required. Shout out also to all the twenty or so users who were involved in research and testing and helped us build something great.

The Challenge

| Help people find their perfect lunch offer, faster.

Over time, as the nez area had expanded the list of offers in the app had become longer and longer. At the beginning of 2018 we had fewer than 100 partners but by the end of 2019 it was close to 500. It was getting harder for users to find what they wanted. To a certain extent, the way offers get ordered by distance had limited the extent of the issue—since people don’t like to walk much more than 10 mins for lunch. But in some areas even that limit left 25+ offers to scroll, too many for a single session.

It was clear from the increasingly frequent requests on intercom (and at the end of testing sessions) that we needed to add search. Within the company, there was also concern that great new partners weren’t getting the visibility they deserved.

Previous research

My product manager and I had done a short project in late 2018 to scope out how search might work. At that time we had pitted a search experience against cuisine filters and users had felt that the then more limited range of offers meant search felt like overkill. 

They had also expressed concern that search would work better for users that knew exactly what they wanted whereas they were using nez for inspiration much of the time. This would be an important theme we would return to.

Insights

From that initial round of research we had learned a few important things:

| People nearly always want to search for a specific place or for a cuisine they fancy.

We had learned then that people wanted to search for two key things. Firstly for a specific place that they either already knew or had heard about. Secondly for a particular cuisine eg ‘Mexican’ or food type eg ‘salad’. Some users did want to search for specific ingredients eg ’houmous’, but this was much less frequent.

| Search creates an expectation of plenty. Handling searches with no results therefore becomes very important.

The ubiquity of high-quality search in digital experiences was a high bar. People are used to finding what they want when they search but we knew that in some areas we would struggle to always have enough offer content. We needed to think carefully about how we would suggest alternatives when either we did not have offers from a specific restaurant or of a particular cuisine.

| Search needed to help people who didn’t know exactly what they wanted, as well as those who did.

We knew from talking to users that the existing filter system helped inspire people as well as narrow down the list. It would be important to find another way to showcase the offer catalogue within the search experience so that it worked well for those who needed more inspiration, as well as those who knew what they wanted for lunch.

Task flow

To plan the search experience I first made a task flow to organise how the experience would work. The flow identified the way in which — if we wanted to provide some inspiration — we would need to expose users to a list of tags before they started their text search. It also made clear the amount of work we would need to do to minimise the many potential unhappy paths. 

Wireframes

The wireframes above show the two main routes to offer content. Either via a shop page or a list of offers that match a given tag. A user taps the spyglass icon to access the search screen. From here, to provide inspiration, before a user has even typed a search, we show a list of the most popular tags and a user's history.

We only start to show results when a user has typed at least 3 characters to minimise server load. These results are either shown as a tag cell, with an accompanying number of results, or as a shop cell, with more information including, walking distance, shop rating and how many offers are available there on that day. Users simply tap on a shop to go to the already existing shop page which has a list of offers, or tap on a tag to see a list of offers that match it, ordered by distance.

Technical Context

We chose to use a fuzzy search framework that would cast a slightly wider net than other types and surface more results - allowing users to choose the most relevant. This would help with both the potential paucity of content in some areas, and also with what we knew about users not always knowing exactly what they wanted.

Our CTO envisaged a system to update the tag index every half an hour to keep up with new content that was being added in the CMS. A bigger search index to update tag positions in the ‘most popular’ list would run nightly in the early hours of the morning.

Because of the server resources it would demand we had to rule out a free text search of all offer content. Although this would be useful for users who might be looking for a particular ingredient, we knew from our research that this use case would be relatively rare.

User testing

We took the search experience through four rounds of research and testing with about twenty users in 3 different areas of London. These research sessions—5 half hour conversations—usually took place a week apart on Fridays (with a break for Christmas) and we would iterate the designs every week based on our findings. For most sessions I produced an interactive Flinto prototype of the search experience for them to play with — helping to frame the discussion around something concrete.

Throughout, we tried to talk to a broad mix of user types, both users who were heavy users of the app and those whose use had declined over time.

We were aware that there is always a bias towards more engaged users in this kind of testing, but figured that this type of user would be more likely to be using search anyway. If we had had more time on the project (and more budget) it would have been helpful to talk to users about search who had never used the app at all to understand the role it would play in their first experience of the app.

New insights & improvements

 | Users will definitely search for places we don’t have.

Testing really drove home the need for a robust solution for this use case as the potential for disappointment in the app as a whole was high. I describe our solution in the next section.

| Users will definitely spell things wrong.

The hit and miss nature of on-screen keyboards means that few of us are very accurate typists. We decided that it would be important to include autocorrect in the search field, even though this might occasionally falsely correct the names of restaurants for example.

 As well as this, we knew we would need logic to recognise similar spellings of places. The fuzzy search framework we had chosen made this relatively easy.

 | You can give too many results as well as too few.

 When users were browsing a list of offers that matched a particular tag they expressed a concern that seeing so many results might be overwhelming. We were ordering by walking distance which helped, but some asked to be able to filter further by adding new tags or ordering in a different way (eg price).

The team were nervous about adding a 2nd variable  to searches as this would compound the risk of seeing no results. Likewise ordering by price was rejected by the founders because it seemed to compromise the nez brand - which aims emphasise food & drink quality over level of discount.  In the end we chose to break the list into time chunks that would vary depending on how many results there were. This meant users never saw too many at once and it also reduced server load.

Retagging

At this stage in the project, as the design was mostly finalised, we also worked with Frankie Molyneux in the Partnerships team to ensure that the tagging of all offers would be ready for the launch of search

To address the potential issue that had been highlighted by testing (where a user would search for a place we are not partnered with and want alternatives) we purchased a data set online of all the restaurants and cafes in London. We then manually tagged each of these with our own tags so that if a user typed any of them in, we would be able to show those tags as an alternative.

For example if a user typed in ‘Pret A Manger’ (who are not a partner) we would then show the ‘salad’ and ‘sandwich’ tags so that a user might still find the kind of offer they were looking for, just at a different place.

Clearing vs cancelling

In the closed beta period we had realised that people were getting confused by the cross icon in the top-right corner. This closed the search experience and returned users to the offer list. Chatting to colleagues who were in the beta we discovered that they had expected the cross icon to clear the current search so they could type something new. This had not come up in testing because the scenarios had been more tightly controlled. 

We realised that we would need to use words to make this distinction clearer. We added a ‘clear’ button to clear typing and a ‘cancel’ button to quit the search experience entirely.

Final design

The screens above show the final UI. I spent a bit of time crafting the places and a cuisines icons in the nez house style to add a bit of polish to the experience.

Launch & results

We launched search initially on an open beta for two weeks to observe how it affected overall redemptions. After several weeks we were pleased (and quite relieved!) to see that users who had made use of the search feature in a session had a significantly higher propensity to redeem an offer. On some days this was as dramatic as 40% more likely.

This gave us the confidence we needed to launch universally so we worked with the nez marketing manager Jo Miguens to come up with an email that explained the new feature using a gif. This went out to the entire nez community at the beginning of February and feedback though customer service channels has been positive. Whilst the propensity to redeem after search is not as extreme as suggested by the beta, it is currently tracking at between 7 & 8% which is a solid uplift for the business.

Post-launch tweaks

 After the launch we realised that a significant minority of users were searching for shops that had been on the app but were no longer with us. A use case that had not come up in research. To help these users we now retain all previous shops on the database and their tags, so that we can suggest alternatives.

On a weekly basis we check the search terms that result in no results, to check if we can add tags so that next time a user will see one suggestion at least. Quite often these are misspellings which we can add to our database so that users who misspell in the future find the place they wanted. We also track the percentage of searches that result in no results as a KPI. As of March 2020 it is 5.4%.

• Copyright Benjamin Strak 2023  •