top of page

NUSH MOBILE APP POC

SUMMARY Nush was the final project conceived at Israel Tech Challenge. This was a team project with one other person. I owned the UX/UI concept and execution.

MY ROLE 

  • Wireframes

  • UX / UI

  • Prototype

Nush-clear.gif

View Prototype

THE CHALLENGE

"What do you want to eat? I don’t know, what do you want to eat?" 

The sentence that started it all. My partner and I realized this was a common problem amongst friends, colleagues, and classmates on a daily basis. Many people either, honestly don't know what they are in the "mood" for, or they just don't really care and would rather appease their peers. But when everyone is being indecisive to please the other, time is wasted, your lunch break is over before it even started, and everyone is left dissatisfied. 

 

My partner and I experienced this first-hand as we often ate lunch together during the program. Map applications, such as Google, are only so helpful, but often a number of small, amazing businesses don’t come up when you search for something general like “food” or “restaurant”. There’s a multitude of search terms you can use and it’s exhausting to try to brainstorm synonyms just to find something remotely intriguing to eat: “cafe”, “pub”, “diner”, etc. And if you’re not sure what you’re in the mood for, then searching by food type or category is nearly impossible. And sifting through the numerous travel sites and food blogs to find suggestions and reviews is time-consuming, exhausting, and frustrating. 

 

What do you do? 

THE SOLUTION

We came up with the idea, and after researching for something similar, we saw there was a hole in the market for it.

 

Research explains that you eat with your eyes first. So why are those travel sights so verbose? Ratings are subjective, one person loves it, the next person hates it. This just leaves me more confused. Especially if the restaurant is a bit out of the way to get to at the given time; is it worth the trek to be disappointed? I don't want to read about a good meal someone had. I want to see it and see if it's what I want to eat right now. The main feature of the app would be user-generated content, photos specifically, of what users are eating right now. 

 

You're probably thinking, isn't this Instagram? Well not, quite. With Instagram, you still need to find and follow the food blogger or restaurant to see those pictures. You can search by general location or another general foodie search term, but not together. There is still that element of needing to know what exactly you want or what exactly to look for. Not very helpful for the indecisive, peer-pleaser folks.

 

Thus NUSH was born; a marriage of Instagram, Tinder, and maps.

THE OUTCOME

The concept and demo was hugely successfully based on popular opinion.

THE PROCESS

This was my first UX UI concept project. Everything is self-learned. I opted for a user experience similar to other photo-based apps (ex. Instagram and Tinder), created simple wireframes, designed a bold UI, and made a prototype that we could demo. 

Wireframes of the main screens

FOOD APP 3.jpg
FOOD APP 4.jpg
FOOD APP 7.jpg
FOOD APP 10.jpg
FOOD APP 11.jpg

Since this is just a proof-of-concept project, it was important to make sure we focused on crafting the minimum viable product (MVP) to best present our concept. Below are the key features our app needed to function.

 

MVP

  • Image upload  - This goes without saying. The entire app exists of user-generated photo content, so camera integration must function.

  • Location-based (Maps app integration for fast directions) - We wanted users to be able to search for images that were geo-tagged closest to their current location or a specified location. We also wanted users to be able to get directions to the restaurant or cafe in a single click, so integration with the native maps application on the user's phone was also necessary. 

  • Date/Time Algorithm - We wanted to make sure the content is always up-to-date and shows the user's recent content first.

  • Profile - Having a profile allows users to save their uploaded content. Login capabilities would be via email or social network integration.

  • The app will also need an algorithm to identify a photo’s metadata in order to group and sort photos by location, content, etc. This would be used to automatically categorize photos based on what is in the photo: burgers, sushi, beer, etc.

 

These features we considered "nice-to-haves" and could be added later if the MVP would be successfully developed.  

  • Ability to follow friends and restaurants, and save other photos to a "favorites" folder. Eating is a social activity.

  • Integration with the native phone app so the user can call the restaurant quickly for reservations or more information.

  • Integration with the native taxi app so the user can get a ride to the restaurant from their current location.

  • Search & filtering feature.

HINDSIGHTS & LEARNINGS

  • Even though I created wireframes, I did not first create a flow chart. This would have insightful to see a big picture of how the user would navigate through the flow and how to predict, prevent, or handle user errors.

  • Since this was the first time using the design system in production, I discovered that some component behaviors were not thoroughly thought through, such as input field validation, input placeholders, and disabled-buttons.

  • I was challenged to get buy-in from the engineers regarding the disabled button since from a developer perspective, the "disabled" button isn’t actually disabled. The user can click the button and this is how I chose to validate the input fields. However, I later learned that this isn’t correct behavior. 

  • The drag-and-drop feature isn’t as intuitive as it could have been. It was not able to be scaled to other uses.

bottom of page