Model Bar 3.0 UI
UX | UI | Project Management
Overview
DealerOn, Inc. (link opens in a new tab) is a website hosting and digital advertising company that is focused on the North American automotive industry. The company's websites are edited via a bespoke content management system developed entirely in-house.
The homepages of DealerOn websites consist of 5-10 content blocks, which can consist of custom HTML content or preset content. To quickly display available vehicles to consumers browsing DealerOn's dealership websites, many homepages have a "model bar" widget: a content block showcasing images of the types of vehicles offered by that dealership, as well as links to inventory. Model images are populated automatically based on the vehicle features selected, pulling images from Chrome Image Gallery (link opens in a new tab).
The Model Bar Widget has responsive behavior allowing any selected number of vehicles to be output on a homepage, with configurable display of basic summary information (year, make, model, trim, MPG, and associated disclaimers) and inventory links. A second version of this tool, the Model Bar 2.0 Widget, includes more features and eases organization of models with the ability to drag to re-order models, add custom (non-vehicle) buttons, upload custom vehicle images, and create preset model bars for each automotive manufacturer.
A DealerOn platform model bar widget for an automotive group's website homepage. The widget shows a row of custom model images depicting various body styles for the user to select, such as SUV, Truck, and Sedan.
Problem Statement
Since the first model bar widget was released in the mid-2010s, client needs and design standards have evolved. A second version of the widget was released in the late 2010s with new features, though the appearance of the tool remained largely the same. The tool still has limited customization abilities, lacks a mobile display, and does not have the ability to categorize models.
A DealerOn platform model bar widget for a Ford dealership website's homepage. The widget shows two rows of seven Ford models, with each of the model names displayed below the vehicle image.
Since 2018, the Design team at DealerOn has been creating custom model bar widgets by hand-coding the widget with HTML, CSS, and JavaScript. These widgets have models grouped into categories (such as: by body type, like Trucks, Cars, or Sedans; by splitting out Popular models; or by brand for multi-make dealerships), appear on mobile, and have smooth scrolling carousel capabilities via the Slick.js library. Additionally, stricter requirements by some OEMs (Original Equipment Manufacturers) like Toyota have necessitated further features like routing model bar images to inventory Search Results Pages (SRPs) only if the vehicle is currently in stock at the dealership in question and routing inventory to a Model Research Page (MRP) if none are found, or hiding models like the California-exclusive Toyota Mirai based on the dealership's state. These kinds of settings cannot be configured in the platform model bar and so must be coded by hand.
Though hand-coded model bars have all of these new, useful features, they are output in the content block as pure HTML, CSS, and JavaScript, making them very difficult to update for DealerOn's dealership clientele who are typically not code-savvy. This requires DealerOn's Design team to facilitate updates by hand, both as the dealer requests and annually as new models are released. Over the past few years, the number of hours spent by the Design team on model bar edits alone has increased significantly, with a real cost associated with the edits.
A DealerOn platform model bar widget for an automotive group's website homepage. The widget shows a row of custom model images depicting various body styles for the user to select, such as SUV, Truck, and Sedan.
A custom model bar created manually by one of DealerOn's major agency customers. This style of model bar appears on all of the agency's 100+ sites on the platform; making any edits to the tool requires for the agency representative to do so themselves, and edits to all sites can take hours (if not days) to complete.
A major consideration is the direction of DealerOn's Design team. The Design team spends the bulk of their time on minor edits and changes that are too difficult for many users to make, as they require intimate knowledge of HTML, CSS, Bootstrap 3, and the capabilities of the platform. The Design team's goal in the coming years is to focus more on innovation and creating next-level designs to make DealerOn the front runner of the automotive marketing industry: to achieve this goal, the Design team is looking to build methods of templatizing site content so that users are empowered to make their own changes. One of the first areas of focus is the model bar due to the frequency of requests and the number of branding compliance rules associated with the tool.
While there are a number of sites that still use the Model Bar 2.0 widget, there are frequent questions about how to use the interface and how to make customizations. Issue reports are regularly sent to the Design team requesting edits to the platform model bar, as dealers and internal teams alike do not understand the tool's features or how to implement them. The interface is out of date and does not match other areas of the CMS; updates to styles elsewhere in the system have changed the appearance of some of the tool's buttons and fields, adding to the confusion.
An additional problem is that DealerOn is making efforts to branch into other product lines beyond the automotive industry. While the company's systems are still specialized for automotive inventory, there is an expectation that newly-created tools should be able to work for non-automotive inventory as well, requiring more customization features unrelated to traditional DealerOn inventory filters.
A DealerOn platform model bar widget for an automotive group's website homepage. The widget shows a row of custom model images depicting various body styles for the user to select, such as SUV, Truck, and Sedan.
Project Goals:
- Redesign the interface of the Model Bar 2.0 Widget to match the new Design System for DealerOn interface components.
- Incorporate modern and commonly-implemented features currently unavailable in the Model Bar 2.0 widget to output a sleek, stylish, up-to-date, and easdily-customizable model bar.
- Reduce the number of overall requests for the Design team to create and update custom model bars by empowering users to make complex changes themselves.
- Ensure the new model bar is "future-proofed" by building in component and templatization features that will help mitigate the need future development work.
Users & Audience
While DealerOn's automotive dealer customers have the ability to make edits to their hosted websites themselves and receive training on how to use the tools available in the CMS, most do not elect to do so, instead requesting for DealerOn's Customer Support (CS; live phone and email support) and Customer Success Management (CSM; ongoing support and point-of-contact) teams to handle site updates. As such, typical users are:
- Customer Support Specialists
- Case Managers
- Customer Success Manager
- Design team members
Outside of these internal users, there are also:
- Automotive Dealers and Internet Managers
- OEM and Agency Representatives
Based on the above, I developed the following user stories:
As a dealer, I want to:
- Be able to update model links easily on my own
- Have access to update images
- Be able to customize my tabs and display of my models
- Display additional vehicle information, such as:
- MPG
- Number of vehicles in stock
- Pricing (including lease/finance information?)
- Additional disclaimers
- Meet all compliance requirements while having additional freedoms for customizing my model bar
As a designer, I want to:
- Be able to easily create new model bar styles and layouts
- Have fewer requests come in for extracting replacement codes, making custom updates to model bars, etc.
A CS team member who is handling customer requests over the phone or by email via Salesforce. There is a need for immediate action and fast turn-around in this role, so these employees typically handle smaller requests and escalate larger ones to other teams. This role sees higher turnover and training is a near-constant requirement. These employees appreciate fast, easy-to-use interfaces that are straightforward, consistent, and informative.
- CMS Knowledge: 3/5
- Code Knowledge: 1/5
- Customer Knowledge: 3/5
-
Goals:
- Complete customer requests as quickly as possible, often while on the phone
- Meet SLA deadlines and consider compliance restrictions when completing edits
- Prevent the need to escalate requests to other teams
-
Pain Points:
- Dealers can become very angry if requests are not completed quickly enough
- Must explain, despite limited technical knowledge, why minor edits can take a long time to finish
- Edits require HTML/CSS/JavaScript knowledge and can rarely be completed without escalation
A higher-level CS team member who covers more complex customer requests. These team members oversee requests that take a longer amount of time to complete, or gather additional information in order to escalate a request to another team. These team members are very familiar with the CMS and have been with the company for longer, often using shortcuts and hotkeys to assist with repetitive actions.
- CMS Knowledge: 5/5
- Code Knowledge: 2/5
- Customer Knowledge: 4/5
-
Goals:
- Escalate requests to appropriate teams to assist dealership customers
- Develop expertise of the CMS to find and execute solutions quickly
- Educate internal teams and customers on platform capabilities and features
-
Pain Points:
- Platform tool is clunky and difficult to use, with little documentation or help text
- Compliance requirements are not always clear but can result in penalties for the customer
- Must communicate limitations to customers to manage expectations, often provoking ire
A separate team from CS, CSMs have a one-on-one relationship with dealership clients and are their primary point of contact for website updates and other needs. CSMs have regular calls with their clients to discuss expectations, successes and failures of recent campaigns, and to make note of any changes the client might request for their site. They are then responsible for executing these changes themselves, or escalating them to the correct team. CSMs are a bit of a "mixed bag": while many have been with the company for a long time and have a strong grasp of the various features available in the CMS, there are also many who are newer or whose client work has been primarily focused on other topics such as analytics. As such, training is a frequent topic with CSM teams, though to a lesser degree than with CS.
- CMS Knowledge: 4/5
- Code Knowledge: 2/5
- Customer Knowledge: 5/5
-
Goals:
- Help dealership customers manage their site and translate business goals to the web space
- Educate dealers on platform capabilities and features
- Complete requests quickly, ideally without escalation, for maximum customer satisfaction
-
Pain Points:
- Platform tool exists for making changes, but cannot be used due to compliance requirements
- No documentation available to show customers how to use the tool themselves
- Minor updates like changing a vehicle from blue to red can take days to complete
Members of the Onboarding team within DealerOn's Design department most commonly create new model bars and set them up on newly-created websites. They will create new layouts and styles for model bars as well. While naturally familiar with code, these designers do not always know what clients want, as they do not speak with clients directly.
- CMS Knowledge: 5/5
- Code Knowledge: 5/5
- Customer Knowledge: 2/5
-
Goals:
- Complete edits as quickly as possible to satisfy SLA deadlines and provide excellent customer service
- Create great-looking, high-converting designs
- Make innovative tools and webpages so that DealerOn stands out among other industry providers
-
Pain Points:
- Focus on nitty-gritty tweaks and edits eats up valuable time that could be used for innovation
- No easy way to push changes across all sites and files, or make minor edits to just one site
- Team is not customer-facing, so issues often require clarification before work begins
Depending on the size of the dealership or automotive group, the person who is responsible for website maintenance varies. Most often, there is an Internet Manager or Marketing Manager at the dealership who handles website changes. Levels of technology familiarity vary; some clients are very "hands-on" and cover website edits entirely on their own, while others reach out to their CSM or to CS for each and every update.
- CMS Knowledge: 2/5
- Code Knowledge: 2/5
- Customer Knowledge: 5/5
-
Goals:
- Provide direct links to high-converting pages and key information sources
- Be fast and accurate in showcasing the latest vehicles and best deals
- Demonstrate value to customers by making the vehicle purchasing process easy and straightforward
-
Pain Points:
- Lack of information on how to use the CMS requires a case for every update
- Unclear why seemingly small edits can take multiple days to complete
- Limited options for differentiating one site from another ("cookie-cutter" syndrome)
Some dealerships are directly managed by the OEM or by an associated advertising agency for the OEM. These representives usually have little to no familiarity with the CMS, making changes in a "brute force" manner if they cannot find the correct way to resolve the issue. These individuals typically only become involved if there are compliance guideline violations on the site, such as incorrect disclaimers or ads that violate brand Design Systems.
- CMS Knowledge: 1/5
- Code Knowledge: 1/5
- Customer Knowledge: 4/5
-
Goals:
- Ensure sites are compliant
- Accurately represent OEM/agency interests
- Coordinate marketing efforts across agency/region
-
Pain Points:
- Compliance auditing is manual and slow
- Brand/agency-wide updates can take a long time, delaying marketing efforts
- Working out of many different provider systems can be confusing
Roles & Responsibilities
As the Lead Designer at DealerOn, my primary duties were to assess ways of improving the day-to-day experience for my design teams and to seek out ways to optimize productivity. Scoping feature requests to submit to the Development team was a large part of my job.
Model bar edits stood out as a significant time-sink: many of these edits are handled daily by Design, despite an existing interface in the CMS. While the edits rarely took longer than 15 minutes each, that time adds up, and could be completed faster by customer-facing teams like CS if the existing interface was easier to use. A simple edit like changing a car from red to blue on a homepage's custom model bar could take upward of two days, depending on Design and Customer Support queues. This does not make for a positive customer experience, and clutters Design queues with smaller tasks, limiting the team from having time to work on important large-scale projects and improvements.
A request for a "Model Bar 3.0" was first submitted in 2016, not long after the previous version had been released, but languished in the backlog for a long time. In 2018, as the Design team began using custom Slick.js-based (opens in a new tab) model bars, the request was updated to include more features from Slick. In 2020, I was tasked with updating the request further to incorporate new features that had been required as part of the Toyota program, and to supply a new UI prototype for the tool.
At the time of completion, I was the only worker on this project, besides the Manager of Design who reviewed my finished work and notes. My responsibilities were:
- Investigating the current model bar tools and the usability of the existing platform model bar interfaces.
- Re-writing the existing code supplied for the Slick.js version of the model bar, updating it with additional accessibility considerations and comments to indicate where settings selected in the UI would be output on the widget.
- Providing a prototype of the redesigned UI and providing comments to outline how users would move through the application, working within the DealerOn Design System for all components.
Example of a mobile custom model bar using a Slick.js slider. Platform model bars do not render on mobile at all, so sites wanting any mobile functionality for the tool must have it re-built by hand or use one of a few preset model bars created by the Design team.
Scope & Constraints
Time was not a factor on this task, as it was not an immediate need and likely would not be able to be reviewed by the Development team for a while. As such, I was able to do a lot of research on this task to gather insights on what features would be desired and the feasibility of integrating them.
Per my early notes, some additional considerations were:
- Need to have different ways to categorize models and allow users to customize this:
- By body style
- By brand
- By condition (new/used)
- UI should be consistent with UI elements used elsewhere in the CMS (e.g. Specials)
- Should have functionality built in to hide models or change links under certain conditions (e.g. for Toyota, we need to hide the Mirai if the dealer is not located in California)
- Change the model link (ex. to a Model Research Page) if there is no current inventory for the model
- "Custom button" functionality should be more built in; people don't really know how to use it currently
For the purpose of consistency between screens, I wanted to be sure to use the DealerOn Design System, which has been used for creating newer screens and components in the CMS. In particular, I wanted users to feel like the functionality between screens was the same: if a button worked one way in the Specials screen, it would need to exhibit the same (or reasonably similar) behavior here.
One problem is that no screens in the Homepage editing section of the CMS currently use the new design system. As such, I wanted to make sure that the new UI would not necessarily rely on being built into this new design system, and that it would make sense and be usable even if it was integrated within the older layout.
An example of a screen in DealerOn's CMS using its design system. Source: dealeron.comOpens in a new window.
Process
Research
My process began with extensive research, first in Jira. DealerOn uses Jira for client requests that have been escalated to Design, Development, or IT teams. By filtering Jira issues, I was able to identify the number of model bar requests we had received in the past, as well as the amount of time spent on these issues. To support my case for prioritization of this project, I then exported this information to Google Sheets (opens in a new tab) and used it to estimate the cost of custom model bar edits per quarter and per year.
Having found that the number of custom model bar edits and associated labor cost were far higher than antipicated, I received approval to proceed with the project, accounting for as many potential features as possible to mitigate the need for manual edits.
Results from analyzing model bar edit requests in Jira throughout Q4 2019. I did a basic statistical analysis to determine average time spent editing model bars, using a combination of hours worked (self-reported by the designer completing the ticket) and the amount of time the issue was open (Created date - Resolved date) to factor in customer wait time. Outliers were excluded so that requests left open by accident would not factor into the calculations. I then used low-end estimates of designer and customer support salaries to estimate the cost of Design updating model bars, finding conservatively that these edits alone cost the company a minimum of $5,000 per year, potentially up to $40,000.
Interviews
I consulted several employees at DealerOn, both in the Design department and on customer-facing teams. As a designer, I had a grasp of the types of edits we typically made on model bars, but wanted to make sure I had a complete picture and not just that of my own experience. Through user interviews, my designer contacts provided me with additional examples of common and not-so-common edits, as well as some more complex model bars we had built for high-profile clients. I wanted to make sure the new tool would be able to be used for any type of model bar we currently offered.
My contacts on customer-facing teams provided me with further insights on features they would like to see in a new model bar UI, as well as how they use the current interface. I was able to observe one user as they made edits in the system, noting that they had difficulty understanding which sections of the interface would allow them to complete the edit they wanted to make and that they had to frequently push back on client requests for more advanced features.
All in all, the process was slow and frustrating: as an example, users often did not notice until they had added a new vehicle that they would not be able to customize the vehicle image once it had been added, and did not understand that they would need to add the vehicle via "Add Custom Model Bar Items" instead of "Add Model Bar Items" in order to do so. Two of the four users I consulted stated that they did not know what the "Custom Buttons" portion of the interface did at all.
Select Interview Questions
- What is your name and job title?
- What does the day-to-day look like in your position?
- How often do you use DealerOn's CMS in your role?
- What is your opinion of the Responsive Model Bar 2.0 widget?
- How often do you need to use the Responsive Model Bar 2.0 widget?
- Please demonstrate how you would add a new vehicle to the model bar.
- Please demonstrate how you would add a custom vehicle image to the model bar.
- Is the interface easy to understand?
- If you could change one thing about the model bar widget, what would you change?
Definition
Having completed my interviews, I sat down to refine my list of features. My main goal for this UI was to improve overall usability by providing a clear interface with an appearance and functionality consistent with other CMS tools, along with copious help text to assist the user in making the changes they desire. I also wanted to make sure the interface would incorporate all of the modern features of the custom model bars the Design team has been creating, while also emulating the old platform model bar format for dealers who prefer it.
As one of DealerOn's goals is to increase sales of "bolt-on" products beyond base websites, the model bar design should lend itself to this goal. The proposed model bar UI has toggles to support two major bolt-on products: Symphony specials and the APEX payment experience. These would allow users to generate vehicle specials based on their current inventory automatically and showcase them on their homepage, as well as allowing them to generate lease and finance offers and start the purchase process from the homepage.
Another aspect to consider was "future-proofing" model bars. As designers, we need to push the envelope year-over-year and create fresh, innovative websites and tools; however, development work is completed far slower, often taking years between rolling out iterations of an internal tool. I wanted to build in enough features and designer-controlled content to relieve additional development burden for this tool going forward. It remains to be seen whether this will be feasible, but I am hopeful that the interface I have designed will stand the test of time.
One of the model bar screens, displaying potential configurations for populating Symphony specials based on previously-set model/trim configurations. The screen also displays how to re-order tabs and how users with sufficient permissions can set a template model bar for an OEM.
An example of a product model bar for Hearth & Home Technologies. DealerOn has been exploring expansion into other industries, starting with hearth and fireplace products. This type of model bar is currently completely unsupported via the platform, as the platform tool is focused on automotive; however, it would be possible to make it via the Model Bar 3.0 UI.
Prototypes
Prototypes and sketches were created in Whimsical (opens in a new tab). My initial draft from extremely early on in the project was limited to editing the existing UI to add the new components and features, as I was concerned that there would not be significant development resources invested in the project.
However, partway through this initial approach, I determined it would be better to push for a complete rework of the UI to make it align well with other pages of the CMS, using components from our new design system and re-organizing it to be more user-friendly.
For an "MVP" approach, I focused on reworking the UI to utilize the DealerOn design system. Though I factored in many features that are not currently available within platform model bars, these can be cut temporarily and added in as development resources are available. Some concepts like advanced templatization will take far longer to build in and so have been left out of the initial prototypes until further scoping can be completed.
The prototypes I created can be viewed here:
I have since created some additional prototypes, such as for a "template selection" screen for users setting up or customizing a model bar for the first time. This also contains a walkthrough to guide users through configuring the tool, with tooltips powered by Pendo (opens in a new tab).
One of the model bar UI prototypes, showing the Model Bar Layout Settings screen. This screen allows the user to select either the "classic" layout (with models appearing in rows) or the "slick" layout, with models appearing in a carousel. Unique settings display depending on the layout chosen.
Prototype of the Model Bar 3.0 widget starting at the Template Selection screen. This would allow users to use automatically-generated or previously-created model bars as a basis for their widget, minimizing set-up time and allowing for advanced customization.
Outcomes & Results
This project is still in the process of being implemented on the DealerOn platform. Future aspects of the project will include:
- Building full prototypes in Adobe XD
- User testing via Maze to study how users interact with the tool and if they understand the features of the new UI
- Analytics via Pendo upon release to analyze how users are actually using the tool and to discover where we can make improvements
Initial reviews of the wireframes with potential users have resulted in positive feedback. Users liked the familiarity of the system due to the consistency of the UI with that of other systems on DealerOn's platform. They also liked the presence of tooltips to provide users with explanations of features and the level of customization available.
There was some confusion on how to edit the tabs, as well as the purpose of doing so; since this is not a current feature of the platform model bar, some users did not understand why they would want to do this or how to get to that editing screen. Future drafts of this UI will account for this; I believe that the "first time set-up" display and Pendo guides will also assist users with understanding the purpose and process for editing tabs.