Having individual websites for each company franchisee meant that a lot of information was published and spread across the Internet. Without a place to centralize it, the experience of the users was interrupted and many customers and potential employees were lost.
To fix this, we needed to create a portal where we could gather all the restaurants, jobs, events and news published by an organization. An extra feature was that the content would also be displayed based on the location of the visitors.
In order to find out how big franchisors displayed all their individual units, we made a list of 30 popular restaurant chains across the US and classified them based on the existence and complexity of their portals. Some companies displayed only the address, some had a global map, while others had no centralized place at all.
Overall, all the companies that had a portal, used it more or less only as a locator for their restaurants. No extra information was provided.
We wanted to keep the portal useful and very simple, so the sitemap was very straightforward. The first version of the portal included 4 main modules: map, jobs, events and news.
The map module displayed and filtered all the units on the map, while the other 3 listed the content generated from the HQ which was available in the selected location. (More details below)
Having a clear page structure, allowed us to go deeper and build a feature map. It included all the content elements and the taxonomy and choreography for the existing features and pages.
Once the feature map was created and discussed with the team, it proved to be a very useful reference for later, for all the members of the team including designers, developers and QA.
When designing the portal, we wanted to make it more than just an aggregator. We knew that a lot of users landing here would be looking for customized information. Whether it was available jobs, new events or latest news, users were supposed to reach only relevant information with limited effort.
To do this, we introduced customized content based on location, meaning that every module of the portal would display data directly targeted to the user.
There were also multiple scenarios we had to deal with when users entered the website. Some had their browser location activated, some not but activated it when asked, while some did not want to activate it at all. In the latter case, a lightbox was prompted where they could enter an address or zip code. We also had to take into consideration the behavior when users reentered the website, which we adjusted separately.
One problem we came across when creating a location based system was that some restaurants were located so close to a city border that, unofficially, they were considered part of it, even if their actual address belonged in a different town. So, when filtering by city, some business owners complained that the results did not display their restaurant.
We had 2 solutions for the problem. One was displaying the map pins in 2 different colors that matched the restaurant status: active or inactive based on the filter. The second was setting a 5 km radius around each restaurant and whenever that intersected with an existing city radius, the restaurant would also be displayed. In the end, we went for a combination of the two.
Sketching allowed me to try different ideas. Once put side by side, the best ones usually stand out and it made it easier to make a decision. This case was no different.
My technique is to sketch progressively when dealing with interfaces. I start drawing several high level concepts, with few details and continue to filter the variations and add details until I’m left with one fully detailed sketch.
Asking feedback at different stages along the way is always recommended as there might be restrictions I’m not aware of or the requirements can change.
The biggest pain point large franchisors faced was the employee turnover, so the main goal of the portal was to increase the number of job applications for restaurants.
The homepage included the 4 modules. In order to separate them visually, each module had a hero section, that included a main call-to-action.
The map was placed first. It offered users the easiest way to get information regarding the restaurants and the pins also displayed those with available jobs. Users could also filter units by keyword, job category and facilities.
Also very important, the jobs module was connected to the map. To make it easier for all types of users, it was split into job categories, each with its available positions. Events and news were displayed next and listed the last 3 entries, that you could find out more about.
To inspire trust in the company, we also integrated a small social proof technique, showcasing real time analytics and social media metrics.
Once the users looked for more details about available jobs, they were taken to a job center where all the open positions in their area were listed. Split into categories, users could select a specific position and see all the neighboring units where it was open, sorted by distance from the users’ location. If there were more than 5 restaurants available, users were directed to a dedicated page where they could choose from all units.
We integrated 2 scarcity techniques to encourage users to apply. If there were less that 10 open positions available, we changed the labels to “Only X open positions”. Also, when users entered the page for the first time, a small card in the bottom right corner appeared for 10 seconds, letting users know how many other people were looking at the same jobs. Both were designed to inspire a sense of urgency to take action.
Involving the visual designers and developers in the UX process offered us a lot of useful feedback. It also made it a lot easier to work next to them and and let them know my opinion throughout the development process.
They designed the UI based on the the prototype I built in Axure but I was always close by to answer questions and solve small problems arising along the way.