The Problem

The first and most time-sensitive issue that needed fixing was a mismatch between our targeting UI and the way our Ad-server evaluated and applied targeting settings. This was leading to misconfigured settings that were costing Users (and us) money! - Ie; in the Geo targeting UI, we allowed users to say “DO NOT serve ads in Canada, and DO serve ads in Toronto”. Our ad-server would evaluate this in a way that led to no ads serving anywhere, as the only area it was “allowed” to serve ads in, Toronto, was simultaneously within an area it was explicitly NOT allowed to serve ads in, Canada. ⁃ Include a diagram Secondly, the existing targeting UI components were not clearly indicating to users how their configured settings would actually influence their ad campaigns. Checking & modifying was a common task for users, and the poorly designed UI was leading to a mentally taxing and needlessly time consuming experience. Once applied, the settings were also difficult to find within the UI. ⁃ Include a screenshot? Finally, our understanding of the user’s mental model of targeting was flawed. This had lead to a component that catered to the long-tail of edge cases rather than the most common workflow, further increasing that mental burden anytime a user needed to make simple changes to their targeting configuration.

The Plan

1. Discover and document the backend logic of our ad-server, and redesign the UI in order to better enforce valid configurations only.
2. Improve the accessibility and legibility of selected settings, in order to increase user ability to predict what those settings will do.
3. Better understand our user’s mental model of targeting and their most common workflow when configuring these settings, in order to improve the design of the UI

The Project

I kicked off the project by conducting numerous interviews with end-users, as well as meeting with our ad-server engineers to understand those systems, and our customer support specialists to get their perspective on user pain-points. Taking my findings from our ad-server team, I documented and diagramed the several different logical models we would need to enforce in the UI, in order to accommodate the various types of targeting and related ad-server logic. ⁃ ie: Using the same example as above, once the user had specific “DO NOT serve ads in Canada”, the ability to select any regions or cities within Canada was disabled within the UI. ⁃ Include a diagram Designed a visually structured summary of various applied targeting settings while editing, and while reviewing the parent object, based on user interviews. ⁃ Include a screenshot I also discovered that for many targeting types users reliably knew exactly what they planned to target and had no need to browse a list. I learned that Geo targeting was the most commonly applied targeting setting, and that almost 80% of the time, users were selecting a single country to allow ads to serve in. This lead me to design an updated experience to better support the more common, simpler workflows uncovered during user research. This included a much simplified interaction as the default, with the added functionality necessary to support a long tail of edge-cases accessible behind one click. ⁃ Include a screenshot

The Outcome

Completely eliminated UI setup errors due to misconfigured targeting settings, saving our users and our business significant amounts of money (not to mention frustration). Significantly improved user-reported understanding of targeting settings. Reduced the amount of time and network resources dedicated to the multiple-times-a-day task of reviewing and/or modifying targeting settings.