The Solution:
I made a responsive website design and created a completely new look and feel.  The information architecture for a couple of pages was revised to make them more user-friendly.

For the redesign it was necessary to research on the problems with the existing site. I used the site analytics, some guerrilla testing and our team’s general input which led me to discover the following issues with the current site:

1. Lack of functionalities
I noticed, while I observed the users, that on our brand listing page, they were interested in finding out brands with respect to their locations and their categories (e.g. retail brands, restaurants, etc.). When they wanted to find a restaurant, seeing something like a retail store in the listing was causing frustration.

2. Difficult Navigation
It was also clear during user testing, that the way we had arranged categories in scroll-able form within product catalogs wasn’t very useful. Most of the users would never press the left and right arrow buttons to explore more of the items. The ones who did use it, found it cumbersome to switch from one category to another. 

3. Slower Loading Times
It was a general consensus among the team that we had to shorten the load and response time of the website. To accomplish this, we had to look for viable options in terms of back-end/front-end technologies.

4. Lack of harmony with the app design
Over the course of time, we had improved the app’s look and feel. We had revised and redone some of the design elements, however, the website was still using the color schemes from the older version. Users who came to the website, could not really relate it to the app as there was a disconnect between the two. We needed to make the website more fun looking and modern, to make it more credible and convenient.

Scenarios

A study of our website analytics showed that on average the peak traffic time was around 1 pm during weekdays. Contrary to that, we saw a significant drop in the activity on weekends. From these results it was evident that most of our visitors were regular office/college going people, who were hitting our website close to their lunch times, when the work load loosened up a bit. This was our chance to throw our bait by understanding their needs, and letting them discover eateries that offered deals/discounts nearby. 

Keeping their context in mind, I came to understand two of the major needs of a working individual when deciding for an eat-out or a take away place:

1. Eateries should be in the vicinity of their work premises, so that the commuting time is as minimum as possible for lunch breaks are usually not more than an hour long.
2. The food should be in a certain budget, as one cannot afford to pay a considerable amount of money on a daily basis.

Napkin Wireframe

I quickly sketched out some low-fidelity layouts on something as ordinary as a table napkin. This always helps me out on focusing on the issue at hand, and I don’t feel burdened with the consciousness of making these ideas look neat and artistic. My initial idea was to include a location map at the top, and to clearly show venue categories on left.

Visual Mockups
Once I integrated map in the design and showed the mockup to the team, we thought to make the whole experience even more engaging by including popular places based on the number of check-ins at a venue. Also, we liked users to focus on brand categories more, so we separated them out from city selection, and took that module on the map.

Pain points in the previously existing design

1. Headings
The visual styling of heading elements, and the menu/catalog navigation was so similar, it was hard to distinguish the two elements apart from each other. 

2. Category Navigation
As mentioned earlier, the sliding navigation was really baffling for our users. Most of them did not even use the left and right arrow buttons to explore more categories.
 
3. Internal Scrolling
Due to the internal scrolling within the menu/catalog, users would miss out on using the browser’s scroll bar, skipping kicks and deals altogether which were present further down in the layout.

Remedy

Visual Mockups
Initially, I decided to show a venue’s map just beneath the cover photo in expandable form, since providing locations along with a complete menu/product catalog was our unique selling point and I intended to put focus upon on it. However, it was pushing the menu/product catalogs down the fold, and also cluttering the area, making it difficult for a user to decide which information to glean first. So in a second iteration, I made separate tabs for every piece of information associated with a brand, such as menu, map, kicks and deals etc.

In the earlier version of the website, we had built a separate and dedicated back-end using MySQL and PHP but in the revamped version we improved upon the user experience of the website by turning it into a single-page application. We already had a RESTful service running for our mobile apps so we decided to leverage it this time by using the lightweight JavaScript framework Backbone.js for the front-end and used it along Twitter Bootstrap for the responsive framework and used Google Maps API for mapping venue locations. As a result, we were able to create a seamless experience, where complete page re-loads were avoided altogether, and hence the response time of the website greatly improved.

1. Models
These were the basic entities and contained the actual data in the form of attributes that our application was using. Some of the main entities were namely, Brand, Deal and Location. To fetch more than one record from the server and to perform further operations, their corresponding Collections were also made namely BrandList, DealList, Locationlist.

2. Views
For initializing the models/collections a number of views were created such as BrandListView for the Brand Listing Page, DealListView for the Deal Listing Page, and AboutView, FAQsView etc. for static pages.These basically worked as the cohesive force between the actual HTML/CSS of the UI and between the models.

3. Routes
For routing client-side pages, and to connect them to events and actions a Backbone Router was created, for every route a corresponding handler function was written. Within these functions, the Views for the respective pages were triggered that rendered the entire HTML/CSS templates, based on the data received from the server.