GrubHub | Help Experience

2015

Platform(s): Responsive Web

Live / Currently: grubhub.com/help/contact-us

Chris Grant - Product Design, visual design, user interface design, interaction design, responsive web design, competitive analysis, wireframes

Brian Gregg - Web development, engineering

Jon Nesset - Web development, engineering

Josh Aziz - Product management

Elaine Short - Product copywriting 

The new GrubHub Help Experience introduces brand updates as well as features and tools to improve the GrubHub customer care experience. Diners are now able to more easily navigate solutions to their concerns through categories, reach a customer service rep through a chat client, or call the help line. Diners are also able to see enough relevant information, such as their recent order status, to aid in help conversation. This agency and helpfulness reduced the high call frequency problems of our care department. 

I was the lead product designer for this project, which introduced live chat to our help experience and significantly decreased call traffic, where at highest, traffic between calls and chat is an even 50/50 split. 

 

It started with a great migration

For years, GrubHub as a company was focused on migrating both Seamless and GrubHub brands to new, more stable, and sophisticated engineering architecture. Last year, migration reached success, but this meant rethinking and redesigning some core experiences from the now legacy web experiences to match our new brand and product experience. One such redesign was of the GrubHub help experience. Previously, a help page with FAQs and a number to dial customer service, we saw an opportunity to produce a more sophisticated experience as well as remedy the customer care department’s high call volume via this new architecture, providing a real time chat client, as well as this redesign effort.

Evolution (Process + Iterations)

Given the importance of the new help experience, for various stakeholders (engineering and customer care departments), Josh (product manager) and I were keen to coordinate pre-kickoff meetings. The pre-kickoffs would allow me to understand the needs of our customer care department, the engineering limitations and constraints, as well as getting feedback for design iterations. 

Brian sharing pre-production builds and breakpoints as a part of QA

Brian sharing pre-production builds and breakpoints as a part of QA

Usability issues from legacy

legacyContactUs.png

First Pass

Contact US1.png
Contact US3.png
mobile1.png
 

Iterations

 

Revision 3 - Final Contact Us page

 

Active Order Status component

 

Impact And What Lies Ahead

This was a really collaborative effort. As I would explore the problems, think of solutions, and design, I would keep in close communication with engineering, product management, and members of the care department through HipChat and email, in addition to our pre-kickoff chats. It was important to do this given that some of our team members, such as Elaine and Brian, were working from our Chicago office. However, I would add that this allowed me to design in an agile fashion that worked with our sprint.

 



In addition to needing a help experience for our migration, we had to provide an improved help experience. The legacy GrubHub contact us site had a lot going on with it — there wasn’t a clear visual hierarchy of information and there weren’t too many paths a diner could follow to remedy their qualms.

It took about three iterations for the help chat and help landing, as well as two iterations for the active order status component of the help experience. 

 

On my first pass, I was focused on establishing a hierarchy to the information — reducing noise and showing information, such at the appropriate levels of prominence for the diner with relation to context. The legacy help page required a higher learnability of the diner than needed. Diners had to scan the entire page to get the information they needed. They also had to consciously categorize their concerns as either order changes or a particular issue with their order. This meant the possibility of making a wrong choice for the sake of contacting or some feelings of paralysis. In addition, data, such as phone numbers, weren't presented in means that gave the best affordances or legibility, such as presenting the numbers in dashes to aid in legibility as well as the browser being able to trigger a call to the number via a tap or click. 

I considered a hierarchy that could allow diners to read less, understand the option, as well as the scope of options that they have, via a row system with iconography (at the left), explanations (center), and clear action buttons (right). 

In terms of chat and call features, I was focusing around making it clear that the features and information were understandable and noticeable. There was also center copy and items, such as the 24/7 availability, that I followed from the care departments requirements.

Given that we had implemented a Facebook login, I started exploring identity within the help chat via a profile photo icon for the diner, as well as their name, while keeping a limited identity for the help associate. Much of the visual treatment for chat, I felt was something that could respond well to devices — going from popup window on desktop to a full canvas view on mobile, mimicking the feel of a native chat client.

 

After the first pass, the stakeholders from the care department, myself, and the rest of the team reviewed the implications, feasibility, and other concerns. The design direction was in order, but the care department wanted to explore possibilities to remedy their high call volumes through either less emphasis on the customer call phone line or hiding the number entirely.

I considered three approaches: 

1. Phone icon and service number much smaller and secondary in information hierarchy to live chat

  • maintains transparency of the number, but de-emphasizes in favor of live chat

2. Emphasizing the live help chat in the same column, whilst the phone line visible, but to the lower right. (different info hierarchy)

  • diners might not see the number or any point of access to it given order of content
  • the visibility of the number poses the same risk of call volume

3. Balancing both, but making the phone number only accessiblyviathe diner making the choice to choose to call instead of live chat.  

  • limiting the visibility of the phone number, but not taking away control from the diner

 

 

 

Upon review, it seemed that the third approach was the most well received.

In following this path, I started to see more affordances, particularly via interaction design, for selling the diner on live chat, as well as being more intentional with our display of the phone number.

The particular interaction series that we arrived at was one where in hovering over the phone icon, a popover appears by the chat bubble to encourage the diner to try live chat, but revealing the phone number when the phone is clicked. For mobile degradation, we reduce the popover to an expanded accordion interaction.

 

After the final revision of the contact-us page, the scope increased to include the Active Order Status, a widget from the legacy site used to provide recent order details for reference in help scenarios. I approached this as a matter of information design, where we could have a design with clear data groupings and better legibility for the diner’s needs.

 

The new help experience has been a major success. As a product team, it was a great example of cross functional collaboration across the company and offices. As a product offering, the new help experience significantly decreased call traffic, where at highest, traffic between calls and chat is an even 50/50 split. It would be nice to see help experience that goes beyond a contact page and takes in more varied contextual experiences. I think considering how new features and user experiences lead to help experiences will be a big step in the future. Possibilities could occur through a more nuanced site-wide messaging framework as well as navigation.