Ad Quality - Simplifying an Enterprise Product
The Problem
A new technology in the advertising market meant that small publishers were looking to work with more sources of advertisers (“demand partners”). AppNexus needed to take our enterprise product (code named “Jello”) and make it more friendly to small publishers by rethinking the work flow for managing the types of advertisements that publishers allow on their site (ad quality).
Our enterprise ad quality product was built without input from the design team, and was confusing to users. There was one case of a major client accidentally turning off most of our demand because they didn’t understand the interface. We needed something simpler.
The Jello team’s two goals for the simplification were to prevent the users from “shooting themselves in the foot” and to encourage them to allow as much of our demand as possible.
The initial ad quality page at AppNexus
Research
The Jello product presented a problem for conducting research. These new users were entirely different to our existing enterprise customers, which meant that we couldn’t use our normal research roster. Instead, I spoke to a lot of internal sources of knowledge.
Specifically I worked with the following teams:
- The sales team understood the goals of the small publishers. They mentioned that the users were not very sophisticated and just wanted to make sure that they didn’t serve annoying or offensive ads.
- The monetisation team helped our enterprise customers optimise their setups. They had a lot of best practice documentation for how to set up ad quality. Most of the settings were “This should always be allowed, this should always be banned,” and there were only a few that were really questionable.
What I learned was that we could cut out a lot of the choices from the enterprise ad quality product.
- There were some categories that users wouldn’t need.
-- Buyers - Mostly media buying companies that small publishers wouldn't be familiar with, and thus wouldn’t be able to evaluate well.
-- Ad Servers - A type of technology that was only blockable because one strategic Enterprise client requested the feature. - Within the categories they did need, we could set most of the options and only leave a few choices up to the user.
- We had to keep this as simple as possible because users were bouncing across multiple systems.
Unfortunately, we were unable to do a competitive review since many of our competitors have specific requirements that no one on my team was able to meet.
Designing
Participatory Sketching
I kicked off the Jello project with a collaborative design process called the sketch session. I share the research learnings and requirements with a diverse group of people, and everyone sketches together. It’s a modification of the Design Sprint sketching methodology. It allows us to generate a lot of ideas quickly, and make sure everyone understands the reasoning behind some design decisions is on the same page.
Sketch session ideas
After the sketch session I decided on a few directions:
- One focused on a slider of the real choice: between a good reader experience and better monitisation. This would make it clear to the user what the trade-off was.
- One focused on having a toggle for each individual section, which gives the user more granular control.
Mid-Fidelity
Mid fidelity explorations
Across both options we took a multi-step approach to encourage users to enable our demand.
- Any settings they shouldn’t touch were completely hidden from the user to prevent them making catastrophic changes. There is, for example, no way for the user to turn off ads for retail stores. They are a large chunk of the demand they would get from AppNexus, and it’s not objectionable content.
- For content that may be objectionable we set intelligent defaults. In this way a user who signed up for AppNexus demand would never need to actually touch ad quality, but if they had a special demographic they could turn off inappropriate ads.
- To encourage users not to edit the defaults we put the options behind an extra step, a toggle to “use custom settings,” to make it clear that they were deviating from our recommendation.
- Finally, once they have enabled customization we show a graph of how much ‘demand’ they will cut off for switching-off a category so they could make an informed decision. We weren’t allow to show them an exact number for internal policy reasons.
It became clear that the slider approach wasn’t as successful. When I showed the mockups to co-workers no one really understood the impact of the slider. It was too abstracted from the actual change that was occurring The design with toggles was understood by everyone. It was clear to them that if a toggle was “off” their site would not serve any ads that fit that description.
Across both designs there were some questions about the language. Initial designs just had the word “customize” for the toggle to overwrite defaults, which people found confusing. This was updated to be more clear. Since launching, we have also received some questions about what’s contained in some of the categories.
Visual Design
My goal for the Jello visual design is to be more friendly and approachable than the enterprise counterpart. This is to counter a perception of our product as “powerful but complicated.” To achieve this I’ve been using a lot more white space. For ad quality specifically I also started bringing in more iconography with a little bit of colour and larger text.
End Result
We released the ad quality screen a few weeks ago and so far users have appreciated it. Overall, feedback has been that the design is straightforward and easy to use. Few users have overwritten the default settings, which suggests that some of the design decisions have done a good job of encouraging them to stick with best practices.