Dealerfox

Overview

Dealerfox is a digital automotive specialty group implementing advanced SEO and CMS optimization for car dealerships in the Chicago area. They are developing a tool called DMAPP (Digital Marketing Automation Partnership Portal) for Business Development Centers within car dealerships. DMAPP's proposed functionality is to automatically push approved, relevant marketing content to third-party leads and dealership web traffic. My team was tasked with designing the user experience of DMAPP over the course of a three week engagement.

dealerfoxheroimage.png
 

 

Research

 

During our kickoff meeting, our client, Dan, presented us with wireframes and the proposed information architecture. There were two main design directions Dealer Fox was interested in exploring:

1. Automated marketing notification system: One proposed functionality of DMAPP, and what really sets it apart from its competitors, is its ability to match third-party leads with pertinent, approved marketing content and push that content out as soon as the lead comes in. This eliminates the time gap between lead generation and first contact from the dealership, ensuring they have contacted the lead before their competitors. The first proposed scope was to explore the user experience of receiving a notification that the automation had occurred and the follow up actions that might generate.

2. Social media library: Dan was also interested in exploring the user experience of pushing automated marketing content to social networks and synced contacts. He saw this as a way for BDC representatives to leverage their personal networks to book more appointments. Users could track the reach of their content and the number of appointments it generated.

We left the kickoff meeting without a concrete sense of which scope we planned to focus on. However, my team was hopeful that we could surface a more specific need in domain and user research.

Our client gave us several competitors to look at. We looked at the technical scopes and capabilities of these competitors in hopes of surfacing a potential competitive advantage. We identified several design patterns consistent across our competitors, specifically the presence of prioritized lead scoring (often called “Hot Leads”), calendar integration or appointment scheduling functionality, and marketing campaign effectiveness metrics.

We then turned to the users for a series of exploratory interviews, but the narrowness of our target audience presented many challenges. Our end users were managers and representatives who worked within a dealership BDC. We struggled to find a sufficient number of people who met that criteria and therefore decided to extend our interviews to include a dealership general manager and a subject matter expert in automated marketing.

In total we conducted five user interviews with our target audience including:

  • 2 BDC Representatives
  • 1 BDC Manager
  • 1 Dealership General Manager
  • 1 SME (Automated Marketing)
 
 

Although our sample size was small, there were several trends. BDC reps and managers reported that existing CRMs were incredibly cumbersome and frustrating to use. They reported only using a small fraction of the available features and having to weed through a high volume of information to identify the problems they should be tackling.

Along similar lines, we saw that multiple users were recording notes about customers outside the system on scrap paper. The process for recording notes in the CRM was simply too cumbersome. Additionally, the BDC manager we interviewed kept an external spreadsheet of team performance statistics. Performance metrics presented in the CRM did not allow her to view her team’s progress as a whole, and as a manager she needed to know how individuals were performing.

Finally, we saw from our interviews that users were facing a substantial amount of rejection every day. The BDC reps we spoke with were required to make 100 phone calls per day. Most of these were cold calls from a list of third-party leads. Reps had little information about who they were calling and where that person was in the buying cycle. As a result, representatives were constantly facing rejection over the phone and reported their work being highly emotionally draining.

At this point the problem we were solving for began to take shape. BDC managers and representatives were wasting valuable time and were emotionally defeated by working in multiple decentralized systems that fail to prioritize leads and daily tasks, provide transparent and reliable reporting, and utilize existing marketing opportunities.

We began to wonder, given that DMAPP is a strategic lead targeting tool that leverages data-driven, automated marketing, how might we design a simple, holistic interface that will optimize user productivity?

With this problem in mind, to we used a set of guiding principles to ensure the issues uncovered in user interviews were addressed:

Empower through knowledge: Provide key customer insights and relevant information to help users attack the right problems at the right time.

Holistic: Provide information from multiple systems in one view.

Celebratory: Reframe rejection by creating positive interactions that display incremental progress towards a collective goal.

  Measurable: Provide clear, informative metrics to gauge individual and team performance.

Together these design principles gave us a framework that would allow us to design without recreating the existing CRM issues.

 

 
 

Finding our cupcake

At this point we were still not clear on which of the proposed scopes we wanted to pursue, but we knew out solution had to streamline the user's workflow within the CRM. More specifically, users needed a way to quickly see key customer insights and use that information to make a strategic plan of attack. Given that our users were juggling so many leads at one time, they also needed a way to prioritize these individuals.

In other words, what users really needed was a better CRM. We raised this concern with Dan and he agreed with our conclusion. However, he also expressed little interest in competing directly with existing CRM companies. Instead, he saw DMAPP as a tool that could be used alongside CRMs to save BDC reps time reaching out to newly generated leads.

With this in mind, we looked for ways that DMAPP could address our problem statement and stay within the client’s constraints of the two proposed scopes we were given in the kickoff meeting. We discussed the possibility of our MVP being a desktop app, a browser extension, or something that could actually be embedded within the CRM itself.

 
 

At this point we were feeling slightly overwhelmed by the multitude of forms our MVP could take. We approached this conundrum by asking ourselves whether we wanted a “cake-base MVP” or “cupcake MVP”. In other words, did we want to start with something broad in scope but low in quality, or something small but highly desirable? We chose to prioritize quality over scope.

In order to narrow our focus to the most valuable scope, we referred back to our problem statement: our main goal was to leverage DMAPP’s automated marketing capabilities to increase user productivity. We chose to pursue the first proposed scope - the notification system - because it had more potential to increase user productivity, specifically by leveraging CRMs more effectively.

 

Working alone together

We conducted several rounds of group and individual brainstorming to quickly ideate potential notification system designs. We identified several core concepts to test:

  1. Browser extension with popup notifications

  2. Desktop app with persistent panel notifications

  3. Desktop app with dashboard style notification manager

Each member of the team was responsible for prototyping one concept in Axure. We purposely worked alone to create more natural divergence between our concepts. I focused on prototyping our second concept:

Concept 2  - I was responsible for prototyping our second concept in Axure, which was a desktop app with persistent panel notifications.

Concept 2 - I was responsible for prototyping our second concept in Axure, which was a desktop app with persistent panel notifications.

After completing the Axure prototypes, we completed a round of usability testing with 3 BDC employees. Several notable findings were surfaced:

  • Users preferred the browser extension prototype because it did not require them to leave the CRM. They also liked the ability to call, text, email directly from the extension, even when the CRM was also open in front of them.

  • The desktop notification manager (Prototype 3) was a great tool for people with two monitors. These individuals could view the CRM and the notification manager simultaneously. However, single-monitor users found the desktop apps obtrusive.

  • In terms of frequency, users preferred being notified as soon as a lead received the automated marketing content

  • Users responded positively to push notifications

We chose to go with the browser extension design because it met users where they were (in the CRM) and in the context where they would actually need DMAPP. We saw the extension as being the most basic, core experience of DMAPP given that most individuals were working on a single monitor where they needed the CRM open most of the time. However, we also wanted our design to progressively enhance for edge-case users who did have more than one monitor. We kept the dashboard/ notification manager as a larger, more holistic view for those users whose technology supported it.

 

Browser extension vs desktop app  - In order to make sense of our user insights, I lead my team in creating a pro/ con chart that helped us decide which design direction to pursue.

Browser extension vs desktop app - In order to make sense of our user insights, I lead my team in creating a pro/ con chart that helped us decide which design direction to pursue.

 

We were able to create a converged prototype by the end of usability testing, creating a hybrid browser extension/ dashboard view notification system.

This converged prototype was presented to Dan at the end of the second week. Once we had his buy in on the design, we created a higher fidelity prototype using Sketch. This version was different in that focused on the extension as the main touchpoint and expanded to the dashboard concept for a more holistic, detailed view. I focused on wireframing the dashboard view and worked with my team to combine our flows in InVision:

Converged prototype   - Our converged prototype combined concepts 1 and 2 to create a browser extension with persistent panels for call, email, and SMS workflows. The dashboard view was made accessible through the extension window as a larger, more detailed view.

Converged prototype - Our converged prototype combined concepts 1 and 2 to create a browser extension with persistent panels for call, email, and SMS workflows. The dashboard view was made accessible through the extension window as a larger, more detailed view.

A final round of usability testing was conducted to evaluate the usability of the converged, high-fidelity prototype. We used this test to identify lingering issues related to information hierarchy, notification content, and notification categorization.

There were several key findings from this round of usability testing that resulted in minor tweaks to our final design:

  1. Users wanted notifications to be categorized by Ad Source (the name of the third-party company who provided the lead, such as cars.com)

  2. Users responded positively to the performance statistics on the dashboard view. They requested seeing even more detail on team performance, as opposed to individual performance.

  3. Users responded positively to having the ability to call, email, and text leads directly from the browser extension. They requested having the ability to customize the call scripts and email templates themselves.

These changes were implemented in our final design, where I once again focused on the dashboard view:

Final prototype  - The image above shows the refined dashboard view I was responsible for building. This iteration more prominently featured team and individual performance statistics.

Final prototype - The image above shows the refined dashboard view I was responsible for building. This iteration more prominently featured team and individual performance statistics.

Unfortunately we were not able to address everything in our final prototype. We knew from testing that users wanted the ability to filter notifications, but our research did not produce a clear understanding of what that filter functionality should look like. We suggested this as an area of future exploration to our client.

Along similar lines, our research did not produce a clear understanding of users’ existing paradigm related to lead categorization and how our design could most successfully organize notifications. We recommend our client invest in further exploratory research aimed at refining notification taxonomy.

 

What I learned

During the ideation phase of this project, I was tempted to make DMAPP a replacement of the CRM, but our client was not comfortable becoming such a direct competitor with other CRM companies. His business strategy was to address a gap within the industry without ruffling any feathers. This required me to redirect my thinking from a solution that would replace existing technologies to one that would mitigate their pitfalls. Regardless of whether or not I agreed with Dan’s “less bad” approach, this project was a great exercise in learning how to quickly read an organization and adapt to its constraints.