Foound for iOS

Foound’s logo. Disclaimer: I did not draw it (nor did I support it ^^’)

What is Foound?

Foound is an iOS app that gives you an overview of all the restaurants around you.

It’s a meta-search engine that combines results from most major providers such as TripAdvisor, Yelp, Zomato and Foursquare.

Foound also integrates smaller, more specialised providers such as Happy Cow (for vegetarians) other diet-specific online guides (Kosher, Halal, Gluten-free).

(The founder originally had this idea because he is intolerant to gluten.)

How does it work? Users browse provider webviews for each restaurants so as to better decide where they can go.

Background info & my role

I was recruited to design Foound 1.0.

The app was being developed for over a year and its design was drawn informally.

The team consisted of the founder, Igor Schlumberger, who created Leguide.com (2006 IPO to Euronext) and Prestashop; a CTO responsible for the backend; a frontend developer and three business development teammates. I was the last addition to the team and had to work with many constraints.

During my time at Foound, user-centred design was not our mantra—we designed according to “stakeholder requirements”.

My role & responsibilities:

• UX and IA: user scenarios, designing the navigation paradigm
• UI: layout, interactions, the premise of a visual identity (I chose the green by averaging colours from an avocado image)
• Product design: which features should be included? which do not belong to 1.0 and should be sent to the backlog?
• Product management: organising sprints—before I arrived, product management was informal—and assigning dev items to the frontend developer

Design decisions

Quick note: I am going to take a “triptych” approach to explaining the design of this product.

1. BEFORE: first, how the product was when I arrived
2. AFTER: How the product looked like and behaved after I worked on it, taking into account stiff constraints
3. DREAM: And finally, how I would have liked it to be

Product and interaction design

Main flow

BEFORE

Before I arrived, the architecture of the app was very much so web-inspired. Indeed, there was a home page that was not the main list view (like websites of yore, with an “Enter” button).

Here it is:

Tap on the fork and knife button to initialise geolocation and get restaurants around you.

The problem was that this is not the behaviour people expect from iOS apps. People expect to enter an app and get content, without additional effort.

One may also interpret this problem as the app not making enough decisions on behalf of the user.

From such a home page, you could either: a) search for restaurants around an address, b) search for restaurants around you, c) get information about the company and how it works… that’s too much.

Focus, when it comes to mobile software, is the name of the game.

AFTER

I made the default page the list view and thus removed a tap from the flow.

I decided that, for such an app, most users would benefit from having the restaurants around them shown directly — since it is the main purpose of the app.

I guess product design is really about constantly juggling between what people expect from an app and stakeholder requirements.

DREAM

As you can see, the main problem here is that there is no clear added value. How is Foound 10x better than TripAdvisor? When creating a B2C app, it’s either 10x better than the competition, or it offers something radically, clearly new.

What I would have liked from the founder was either for him to get involved in defining the vision or allowing one of my coworkers ideas to be worked on seriously.

I researched what was happening in the “restaurant search & discovery” industry and I saw some interesting things, like luka.ai (conversational AI that helps you find a restaurant—a great way to solve the overabundance of information).

Perhaps we should have focused on a niche? Like providing information about places for people with dietary requirements.

Enough chit-chat, back to the nitty-gritty of this post.

Interface design

The list view

Most consumer software products are lists. Indeed, very thoughtful lists but lists nonetheless (Facebook, WhatsApp, Instagram…)

Foound’s list view is simple: display all the restaurants around the user.

BEFORE

Here’s how it looked like before I arrived:

The list view before I arrived

• The navigation bar did not look like something Apple would have approved to the App Store. The green magnifier icon was a button that led to the search menu of home screen (indeed, there was a home screen). The back button led to the home screen too. There was a difference in colour between the two icons in the navigation bar, which made me quickly realise how seriously design was taken in this company.
• The overflow of provider icons in each cell made interacting with this interface an overwhelming experience. Some interviewed people said “this takes away my appetite” — definitely not something you want to hear when designing a restaurant search app.
• Tapping on an icon opened a webview. Indeed, the sheer number of call-to-actions was a bit too much to process.

For the list view, I had a couple of constraints:

• Webviews: althought webviews are useful for news products, they damage the UX in a restaurant search & discovery service such as Foound — we got that information from beta users feedback
• Cell UI: two rows of provider icons must be kept
• Provider icons: must appear on list view, must keep icon form factor
• A geolocation button must appear in the list view: although there is a refresh controller that serves the exact same purpose.

AFTER

The list view after I arrived

• First of all, I replaced the providers’ very App Store-y overflow with a Tinder-like “block swipe” pattern. After testing with a couple of people, the interface felt “lighter”.
• (I like to do quick’n’dirty usability testing, see insight here: NNg.)
• Also, instead of a crowded navigation bar, I put a toolbar with the map on the right (further from the thumb because less often used), following inspiration from Apple’s Mail.app.
• I asked our backend dev if we could put ratings at this level of the navigation. It helps people decide faster where they want to go.

DREAM

How I would liked the list view to be

• Images! To me, a unique differentiator between restaurants… to management, a waste of resources.
• No toolbar, just the main use case: restaurants around you. Filters represent the secondary flow, they get their top-right button.
• Providers as information instead of action/links in the list view.
• A numbered list, to make sense of it and provide hierarchy and navigational breadcrumbs.
• Less on-screen results, more scrolling: people are used to scroll for hours on Instagram and Facebook. Why crowd their screens?

Page view

After tapping on a restaurant, you get to the page view, providing further information about said restaurant.

BEFORE

The page view before I arrived

• Before I arrived, the page view basically was a map with directions to the restaurant.
• You could also switch between views with a carousel at the bottom of the screen.
• It didn’t give more useful information to the user and was solving a very specific use case instead (directions to the restaurant).
• My instinct was that the people who would use such an app would prefer a more traditional page view, like Yelp’s, for instance.

AFTER

• Regrouping essential information: I put the webviews a bit further in the flow and strengthened the page view. More than 90% of tested users said they did not like or understand the utility of webviews—still, we had to keep them.
• I thought of a “block system”: first, the title block with map + the restaurant’s name and address > then essential information/actions > then providers.

Today (February 2016), Foound is still unreleased.

Thanks for reading!