nez social

Researching and designing an entirely new evening & weekend experience for nez users.

What

iOS and Android app

When

July 2019 - October 2019

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 PM, Dan Greane the CTO and the developers Adam Lyth and Osama Rahman. Thanks also to Jon Lane, Head of Partnerships at nez, who helped us assess the commercial viability of some of the ideas we tested in this project.

The Challenge

| How might we bring the nez brand promise to new revenue-generating food & drink propositions?

The core nez proposition entails users browsing a list of lunchtime offers in the app, choosing one and then walking to the shop. On arrival a bluetooth beacon in the shop activates their digital coupon allowing them to get the discount when they pay at the till. Now that this proposition was well-established across most of Central London with tens of thousands of daily active users, the founders wanted to see if nez could push into new areas with the same brand promise of saving money and discovering new food & drink spots.

There was a strong business imperative underlying this new initiative. The core nez business model is based on a percentage commission from each coupon redemption, paid in arrears. This results in high gross profit but low revenue. The founders were aware that to put the company in the best possible light for the next funding round, then the company would need to find ways of increasing overall revenue. 

New lunchtime propositions - a survey

With all that in mind, we worked with the founders to survey our users with two groups of new potential product ideas to see if there were any clear directions to pursue. The only limitation was that the ideas needed to be food & drink related — both the founders and the product team felt strongly that nez needed to stay focussed in this area to keep our brand proposition clear.

The first group consisted of ideas that we had heard our users mention to us over the last year and a half of research. It contained ideas that included being able to make restaurant or bar reservations in the app, being able to pay for food in advance to pick up, being able to pick up samples of new food & drink products and even an idea to show editorial content in the app from influencers

The second group consisted of ideas that had come out of commercial conversations with restaurant partners and were variations on a theme of paying in advance for multiple items to save slightly more money eg. 5 lunches at a range of local partners for £5 or 10 coffees for £20.

Survey Results

We made the survey on typeform and left it running for a few days until we had got 500 responses from our users. Overall most of the ideas faired quite averagely, averaging a score of around 6/10. The most popular idea (8.1) was to pick up samples of new food & drink products, followed by being able to pay for food in advance to pick up (7). The strong result for the samples idea gave the green light for the partnerships team to start trying to find suitable content as it required little new product design work. The founding team were reluctant however to follow up on the ‘pay in advance and pick up’ idea as the operational changes required to make this work across the entire nez network were too daunting.

In spite of this apparent enthusiasm for paying in advance, out of the second group of ‘pre-pay’ ideas we had devised with restaurant partners, the highest scoring was the ‘5 lunches for £25’ idea, which earned only 6.3/10. We were interested however that nearly 15% had awarded it 10/10. In order to be a success commercially we knew that only 3-5% of our users had to use a service like this, so the idea still seemed on balance to be worth progressing.

Prototyping lunchtime ‘pre-pay’ propositions 

To better understand the viability of the ‘5 lunches for £25’ idea, my PM Guillaume and I had a whiteboard session to sketch out the various ways this could work. In one potential version the user would buy all five lunches in advance, whereas in an other the user would buy just one lunch at a time. In this second version the user would need to pay by a certain time in the morning to achieve the extra discount. 

There were different UX challenges for each. In the ‘bulk-buy’ option we needed a way to target only the users who had been to a particular shop and might therefore be interested. Once these users made the purchase, they would also need a way to see how many lunches they had left. In the ‘on the day’ option, it was most important to communicate urgency, so that the user knew they must buy the offer by 11am in order to get the extra discount. In the end, we prototyped 2 versions of this type, one where the user could pick up their offer at any time and another (slightly more commercially viable) where they could only pick it up at off-peak times.

Working from these sketches I quickly pulled together three mid-fidelity prototypes in Flinto, which you can see above. 

User testing the lunchtime ideas

We tested these three versions with 5 users. In the testing, we described the ideas first and asked users to score them both before and after seeing the prototypes. Lowest scoring was the off-peak pick-up version as users felt the additional 10% discount they would get was not worthwhile for the inconvenience. Next came the ‘bulk-buy’ option, though this also suffered from user disappointment at the amount of extra discount  paying in advance would unlock. The highest-scoring was the ‘on the day’ option when a user could pick up any time, though even this suffered when users realised it would not allow them to jump the queue – something that competitor lunch apps Ritual and Mealpal offer.

Across the board scores went down significantly between idea and implementation and so we couldn’t help but feel that none of these propositions were going to resonate in the way we would be able to deliver them commercially. We were also concerned about the potential we had observed for them to seed confusion about how the app worked generally. Having taken great pains to make the lunchtime coupon redemption UX simple and universal, some user comments implied this could be endangered with a new lunchtime proposition. We relayed these findings to the founders and after a lively debate we took the decision to change tack completely.

An opportunity at evenings and weekends

So instead of adding a new proposition at lunchtime, we decided instead to properly investigate how we could add a successful evening & weekend proposition. Whilst we had a few offers at these times we knew from the low take-up that the current proposition didn’t quite work outside lunch. A better proposition for this different time of the day (and week) could sit alongside what we had already without running the risk of confusing users. Evening and weekend eating and drinking out of home was also a big market, significantly larger than the lunch market in fact and with a higher average transaction value.

Looking at competing offer aggregators that had a strong presence in this market – companies such as Groupon, TimeOut and Fever we felt that there was space for us to make the experience better. We already had tens of thousands of users visiting our app everyday to help us find lunch, it seemed only a small leap for them to start helping them to make their next dinner or brunch plan too.

New evening propositions - a survey

The founders wanted quantitative feedback to validate this problem space and understand the context for a solution, so we once again sent out a survey, being careful not to hit the same group that had been surveyed before. 

The focus was on what we termed evening and weekend experiences - from brunches and dinners out to cooking classes. There were two sections to it, the first part aimed to establish to what extent our users were already engaged in these kinds of experiences and whether they would be interested in using nez to help plan & buy them. The second part aimed build up a picture of what was important to people when they were making this kind of plan. This would inform the early design work.

Insights

Over several days we collected nearly 350 responses to the survey. A few of the key insights are listed below:

| 90% of surveyed users said that they would be interested in purchasing a food and drink experience in the nez app.

This overwhelmingly positive response validated the opportunity for us. If we could get the UX and the offering right there was clearly a large group of our users who trusted nez enough to try a new service like this out.

| People plan much further in advance when making a dinner, brunch or experience plan.

Over 80% of surveyed users said that they had purchased this kind of experience between 1 and 4 weeks in advance. This was quite a different journey to the core proposition, which had been optimised for decisions made less than an hour in advance. The UX would have to be rethought for this new timescale.

| When making an evening or weekend plan, users tended to start with a category (brunch/dinner/experience) in mind, rather than a specific location. They also wanted to be inspired.

Being category led was also different to the core nez proposition where being within 10 minute walking distance is paramount. Similar to lunchtime however not everyone knew precisely what they wanted so getting some inspiration would still be valued.

| Dinner, brunch etc are almost always sociable occasions.

Unlike lunch which many people pop out to buy alone, when going out for dinner or brunch users would rarely be buying just for themselves. 95% of users we surveyed who had used other platforms like Groupon had bought an offer for more than 1 person. This insight would go on to strongly inform how we pitched and even named the new proposition.

Task Flow

Armed with the initial set of insights from the survey, we began to plot out how users might browse and buy this new type of offer. The journey for purchasing one of these offers would be more akin to a conventional e-commerce flow, with a user completing checkout in the app rather than going to a shop and paying at the till. The task flos highlighted four key areas for design work. These can we summarised under the following themes:

Discover - How would we get users our users to visit this new part of the app, introduce it’s value proposition and make them aware of the range of content?

Inform & select - How would we communicate the extra information associated with these kinds of offers? Additionally, how would we allow users to make customisations to their choice (eg no. of people, venue, package type or date & time)?

Purchase - How could we provide a reassuring and secure checkout experience?

Keep & validate - Where would users coupons be kept once purchased and how would they be validated at the venue when the time came to use them?

There were some notable exclusions from the scope at this stage. We knew from the survey that precise location was a less important factor in users choosing this kind of offer, so we excluded the ability to browse offers on a map from the MVP.

We also made the decision to avoid building a full booking engine as the integrations required with partner systems would make add huge complexity to the scope. How we designed workarounds to some of the issues that led from this decision is described in later sections.

The Design Process

We took the design for this new part of the app through 5 rounds of user testing over about 6 weeks, testing with between 4 and 6 users per round. I prepared the interactive prototypes and discussion guides for these and facilitated whilst my PM took notes. Every week we would present the latest designs and our findings from research to the founders for further feedback. I used Sketch, Flinto and good old pen and paper for prototyping our developing ideas.

Discover - evolution of the design

This new proposition would need to fit into the app alongside the existing one and so we took the decision very early on to house it in its own tab. This raised the question of how users would discover it in their normal lunchtime use, scrolling through offers.

We initially tested a prototype where we highlighted the new tab with an announcement tile among the offers, a design pattern we had used for another project, but this was ignored by users. So we evolved this single tile into a ‘top picks’ carousel of offers. These offers were very different to the usual lunchtime fare and so intrigued many users enough to tap it. 

 As for the layout of the new tab itself, we pitted two versions against each other in testing. One stuck close to the layout of the existing offer list, with a carousel at the top, then a vertically scrolling list. Whilst the other organised the content by category (brunch/dining/experiences/drinks/etc) in a series of carousels. 

User testing emphasised the importance of a distinct visual identity for this new part of the app which pushed us towards the second solution. Users also liked the way the carousels showcased the variety available, a long list of very different offers felt like harder work to look through.

| "I like to see the clear category carousels, as you scroll down you quickly get a feel for the category you might be interested in…

– Marina, a nez user, during an interview.

In our research sessions we also noticed users would talk about choosing a brunch or dinner spot based on its ‘vibe’ - eg whether it was for example ‘fancy’, ‘fun’ or ‘quirky’. Based on this insight we decided to add a horizontal carousel of icons that gave quick access to offers grouped in these categories. This would give users another way of exploring the content and hopefully inspire them.

Inform & select - evolution of the design

The new evening and weekend offers had significantly more information associated with them so updates were needed to the existing offer details screen. Beside new sections showing a menu and offer availability, we did a lot of work creating a custom ‘how to get this offer’ section. This explained how to get in touch with a venue in the event the user needed to reserve themselves. Because we knew we would not be able to put in a full booking system, laying out the steps clearly for making a reservation (and providing a link/number/email) was the next best thing. Refining the language of this section was a key focus of user testing.

Crucially, we made this page fully customisable in the CMS so that the content team could lay it out depending on what made most sense for a specific offer.

As well as being more information dense, the offers in this new part of the app were also likely to have more SKUs. Besides selecting how many offers to buy, a user might need to select between different food or drink options, or different venues. I designed a flexible interstitial overlay that allowed users to do this smoothly, breaking down the steps to minimise cognitive overload.

We also made this overlay system customisable so that users could, for example, choose from a list of dates and times. Once again this was not as optimal as a full booking engine, but a high-functioning workaround for the near-term.

Purchase - evolution of the design

We did not reinvent the wheel when it came to the checkout screen. This is the most sensitive moment in the purchase journey and not a moment for big innovations that might spook a user. The key challenge here was to clearly summarise what the user would be purchasing and make it easy to edit any of the parameters.

We did spend time refining the language explaining they may need to make a reservation, as this was the part of the screen where users had the most questions in testing. We integrated with Stripe and Apple/Google Pay for payments so those flows came out of the box. 

Keep and validate - evolution of the design

The ‘pouch’ tab already existed as part of the original UX so it was fairly straightforward to repurpose this to also show this new kind of offer. We added a one-tap shortcut here  to the venue’s contact details for offers where a reservation was required. This also appeared on the coupon along with a link to the full offer details in case of last-minute queries in the restaurant.

nez lunchtime offers are validated by a bluetooth beacon in the shop premises. However because of the larger sums of money involved we knew we needed a more robust method for validating that user had used their coupon. Of course, it still needed to be quick and usable for both parties. Over the course of several weeks Guillaume my PM and I met with the Floor Managers of several of the initial partners to show them a prototype of our developing ideas. With them, we developed a system where waiters could either scan a QR or enter a short code into a website to validate the coupon. This was a deceptively complex part of the overall requirements and involved a lot of potential edge cases. I won’t go into too much detail here however.

Naming the proposition

There were two competing approaches towards the name of this new part of the app. One approach was to emphasise that this part of the app required users to pay in advance with a name like pre-pay or book. The other approach was to build on the kinds of content it would contain with names like good times, with friends or social.

I advocated for the latter approach as I felt it was more important to capture imaginations initially rather than communicate the precise details of how things worked. Paying in advance was the means to an end, but the excitement of making a plan with friends or family would be why the users felt compelled to come to this part of the app at all.

My argument held sway with the founders and a decision was made to go with the name nez social for the new proposition – emphasising the sociable dimension of these kinds of experiences. In distinction, the existing lunchtime proposition was renamed nez on the go.

Visual Design & iconography

You can see the final design of the key app screens in the images above. To distinguish the app from the ‘on the go’ proposition we developed a dark blue theme. This also gave the new part of the app a more night-time feel – more appropriate for the kind of content.

The key visual flourish was an icon set for the new categories which I designed in the nez house 'neon' style. Some examples are shown below.

Build

I began the process of handing over designs to our development team around mid-September. We used a combination of Zeplin and interactive Flinto prototypes for design documentation. These references would be attached to Jira tickets and the development workflow was managed from there. Dan our CTA and Adam the senior dev and Osama the QA were based in the office so it was easy for me to pop round to their desk to resolve any design questions that cropped up. Our junior dev John (mainly responsible for front-end) was based in Manilla but we were in semi-constant Slack communication during the build period!

Having used this process for everything else we have built at nez, there were few hiccups during this period. The one change I made due to the increased UI bug count during the build period was to combine bugs into single giant tickets to prevent Jira being overwhelmed with individual tickets.

Beta launch

We launched nez social internally to the team in late September. We needed to check for any serious bugs the QA process might somehow have missed and also to give nez staff members the ability to secret-shop the first crop of offers to identify any issues with the redemption process at partners.

There were some changes we made at this stage to how the coupon validation worked, but because this was built on web it did not affect the app rollout of nez social.

Public launch & results

We launched fully in late October, letting users know with an email and push notification campaign. User interest was high, and within a week more than half of our user base had visited the new part of the app.

By November 2019 weekly revenue had surpassed that in the lunchtime section of the app, effectively doubling company revenue. Since then strong growth has continued and nez social has become a key plank of the company’s growth strategy for the future.

What would I do differently next time?

The challenge of this project was to add another proposition to an already successful app without leading to confusion. If there had been more time and budget available I would have liked to test more with new users to get a fuller picture of how the ‘social’ and ‘on the go’ proposition were perceived during early use of the app

I’ve learned personally that one really can’t spend enough time working out how to communicate a proposition concisely and well. It solves so many problems down the line.

As ever the challenges of combining a waterfall research and design process with an agile development process were present in this project – particularly given the short timeframes involved. The main learning here was to continuously identify parts of the UI and UX that were nearly resolved from a design perspective and thus where development work could start. We made sure developers understood that there may be changes late in the game due to the compressed timescales and kept notes of these so that they could be done all at once in designer/developer pairing sessions.

• Copyright Benjamin Strak 2023  •